[Dataset] nist/multihop (v. 2007-08-20)

top

the initial version

@MISC{nist-multihop-2007-08-20,
  author = {Michael R. Souryal and Johannes Geissbuehler and Kamran Sayrafian-Pour and Andreas Wapf and Julio Perez},
  title = {{CRAWDAD} data set nist/multihop (v. 2007-08-20)}, 
  howpublished = {Downloaded from http://crawdad.cs.dartmouth.edu/nist/multihop},
  month = aug,  
  year = 2007
}
					

To assess the feasibility of deploying wireless relays in real
time, we conducted a series of experiments using 900 MHz
TinyOS Crossbow MICA2 Motes (MPR400CB).

When the range of single-hop wireless communication is limited
by distance or harsh radio propagation conditions, relays
can be used to extend the communication range through
multihop relaying. 

To assess the feasibility of deploying wireless relays in real
time, we conducted a series of experiments using 900 MHz
TinyOS Crossbow MICA2 Motes (MPR400CB).

A prototype system is implemented based on 900 MHz TinyOS motes 
supporting low-speed data applications including text messaging, 
sensor data and Radio Frequency Identification (RFID)-assisted 
localization.

Please see <configuration> section of each trace for the collection methodology of each experiment.

[Traceset] nist/multihop/experiments (v. 2007-08-20)

top

the initial version.

@MISC{nist-multihop-experiments-2007-08-20,
  author = {Michael R. Souryal and Johannes Geissbuehler and Kamran Sayrafian-Pour and Andreas Wapf and Julio Perez},
  title = {{CRAWDAD} trace set nist/multihop/experiments (v. 2007-08-20)}, 
  howpublished = {Downloaded from http://crawdad.cs.dartmouth.edu/nist/multihop/experiments},
  month = aug,  
  year = 2007
}
					

To assess the feasibility of deploying wireless relays in real
time, we conducted a series of experiments using 900 MHz
TinyOS Crossbow MICA2 Motes (MPR400CB).

To assess the feasibility of deploying wireless relays in real
time, we conducted the following experiments using 900 MHz
TinyOS Crossbow MICA2 Motes (MPR400CB). 

- RSS-based Link Assessment

The purpose of the first experiment was to determine whether 
the received signal strength (RSS) measurement of the motes 
is a useful predictor of link quality and, if so, to characterize 
the relationship between link reliability and RSS. Results were 
collected using a layout of 12 transmitter locations and 10 receiver 
locations on a single floor of an office building. The layout is
shown in [Figure: Layout] (Layout for RSS-based link assessment experiment),
where transmitter locations are triangles and receiver locations are stars.

The result of this experiment is shown in 
[Figure: success rate vs. RSS] (Packet success rate vs. received signal strength), 
which plots the percentage of correctly decoded packets as a function of 
the average RSS (one data point for each batch received by a mote). 

- Temporal Variability of a Mobile Link

We measured RSS from a mobile receiver to gain an appreciation for 
the extent of fluctuations of RSS at pedestrian speeds in a typical 
building environment,

The result of this experiment is shown in
[Figure: RSS vs. time] (Received signal strength vs. time at a mobile receiver),
which plots the measured RSS as a function of time. 

- Receiver Height

We measured RSS from receivers positioned at different heights,
with a fixed transimitter positioned at 38 cm above the floor.
The motivation of this experiment is that a practical consideration 
in many applications of realtime relay deployment is the effect 
of a receiver's height on the quality of the link. 
For example, if the transceiver monitoring link quality is positioned 
at a given height, we wish to know if there is a consistent degradation 
in link quality if the new relay is deployed at a different height,
say on the floor. A scenario of this type might be a first responder 
with a monitoring radio strapped to his/her belt along with a canister 
ejecting relays onto the floor as needed.

The result of this experiment is shown in
[Figure: RSS vs. receiver height]
(Received signal strength vs. tx-rx distance and receiver height),
which plots the average RSS as a function of transmitter-receiver
distance for each of the three receiver heights. The first six distance 
measurements were made with line-of-sight (LOS) links, while the last two 
(beyond 23 m) were non-LOS.

- Link Symmetry

To test RSS symmetry, we compared the RSS measured
at each end of a fixed point-to-point link.  

The result of this experiment is shown in
[Figure: Link Symmetry],
(Instantaneous received signal strength of received packets and acknowledgments),
which plots the instantaneous RSS measurements made on receipt 
of the packets and the ACKs for both links over a total duration 
of 250 s. 

- Parameter Selection for the relay deployment algorithm in [soryal-multihop]

(See Section 5 in [souryal-multihop] for details of the relay deployment algorithm.)

Implementation of the deployment algorithm requires selecting values 
for parameters including the probe period (D), the RSS averaging 
filter length (N), and the threshold for triggering deployment (Sth).  
Values for the probe period D and averaging filter length N were selected 
after studying the performance of the algorithm for different (D, N) pairs. 
The product D*N represents the duration of the observation window over 
which the RSS average is computed. 

1. Selection of the probe period

[Figure: Selection of probe period D]
(Deviation from deployment threshold for three different choices of probe period D and RSS filter length N)
shows the results of four separate trials for each of three pairs 
of (D, N). The trials consisted of two different paths, and two trials of 
each path. Results are given in terms of the difference between the 
steady-state RSS and the deployment threshold, chosen here to be Sth = -80 dBm. 

2. Selection of the RSS filter length 

We then examined different choices of the RSS filter length, N. 

[Figure: Selection of the RSS filter length N]
(Figure: Deviation from deployment threshold vs. RSS filter length N; probe period D = 100 ms)
illustrates results of trials for four different values of N and 
a fixed probe period of D = 100ms. 

3. Validation 

The choices of N = 20 and D = 100ms appears to strike a balance 
between consistency and latency.
Five additional trials of this choice of parameters were done,
and the results are shown in 
[Figure: Validation]
(Deviation from deployment threshold with probe period D = 100 ms and RSS filter length N = 20).

- Experimental Trials

The prototype for real-time network deployment was tested
in the eleven-story Administration building on the main
campus of the National Institute of Standards and Technology.
In each trial, the base node was located in the ground floor 
lobby. The mobile node was started next to the base, was walked 
to a stairwell and then up to the top floor, with relays 
being placed on the floor when indicated by the deployment 
algorithm [souryal-multihop]. After stopping at the top for
data collection, the mobile node was then walked down the
same path to the base node on the ground floor, passing the
relays that were deployed on the way up. 
In most cases, we were able to reach the 10th or 11th floor 
with 9 deployed relays. Typically, 2 relays were deployed
between the base node and the stairwell door, and the remainder 
were deployed inside the stairwell, roughly one relay per 1 1/2 
floors.

During the deployment phase, the stop phase, and the
return phase, message traffic was automatically generated
by the base node application to measure delivery rates and
round-trip delays. Specifically, a ping-like message was sent
every 4 s to the mobile node's mote, which sent a reply to
the base. While at the top of the building, the base node
application also sent automatically generated text messages
every 4 s to the peer application on the mobile node's PDA.
The PDA logged each message that was received and replied
to it with a text message. Round-trip delay and delivery
rate were measured from the ping messages, and one-way
delivery rates were measured from the auto-text messages.

The result of this experiment is shown in
[Figure: Prototype] (Ping roundtrip delay vs. time of trial 3),
which plots ping roundtrip delay over the course of trial 3.

[Trace] nist/multihop/experiments/rss_success-rate (v. 2007-08-20)

top

the initial version

@MISC{nist-multihop-experiments-rss_success-rate-2007-08-20,
  author = {Julio Perez and Kamran Sayrafian-Pour and Johannes Geissbuehler},
  title = {{CRAWDAD} trace nist/multihop/experiments/rss_success-rate (v. 2007-08-20)}, 
  howpublished = {Downloaded from http://crawdad.cs.dartmouth.edu/nist/multihop/experiments/rss_success-rate},
  month = aug,  
  year = 2007
}
					

Trace of RSS-based link assessment for the automated deployment of a multihop wireless network.

At each transmitter location, a batch of 200 packets was transmitted, 
and the receivers recorded the sequence number, CRC result and RSS 
(in dBm) of each detected packet. The transmitter repeated the transmission 
batch at six different transmission power levels, (-20, -15, -10, -5, 0 and 5) 
dBm, in order to obtain a finer range of RSS data points.

The result of this experiment is shown in 
[Figure: Packet success rate vs. received signal strength], which
plots the percentage of correctly decoded packets as a function of 
the average RSS (one data point for each batch received by a mote).

The file "rss_success-rate.txt" consists of:
- first column: avg rss (dBm)   
- second column: pkt succ rate

[Trace] nist/multihop/experiments/time_rss (v. 2007-08-20)

top

the initial version

@MISC{nist-multihop-experiments-time_rss-2007-08-20,
  author = {Johannes Geissbuehler and Michael R. Souryal},
  title = {{CRAWDAD} trace nist/multihop/experiments/time_rss (v. 2007-08-20)}, 
  howpublished = {Downloaded from http://crawdad.cs.dartmouth.edu/nist/multihop/experiments/time_rss},
  month = aug,  
  year = 2007
}
					

Trace of RSS measurement with a mobile receiver for the automated deployment of a multihop wireless network.

We placed a receiver on a small vehicle moving down an office
corridor away from a fixed transmitter at a speed of approximately
0.3 m/s. The total distance covered was 20 m.
Packets were transmitted at a rate of 50 packets/s, and the
mobile receiver recorded the RSS of each detected packet.

The result of this experiment is shown in
[Figure: Received signal strength vs. time at a mobile receiver],
which plots the measured RSS as a function of time.

The file "time_rss.txt" consists of:
- first column: time (sec)     
- second column: rss (dBm)

[Trace] nist/multihop/experiments/receiver-height (v. 2007-08-20)

top

the initial version

@MISC{nist-multihop-experiments-receiver-height-2007-08-20,
  author = {Johannes Geissbuehler and Michael R. Souryal},
  title = {{CRAWDAD} trace nist/multihop/experiments/receiver-height (v. 2007-08-20)}, 
  howpublished = {Downloaded from http://crawdad.cs.dartmouth.edu/nist/multihop/experiments/receiver-height},
  month = aug,  
  year = 2007
}
					

Trace of RSS measurement with different receiver heights for the automated deployment of a multihop wireless network.

A fixed transmitter positioned at 38 cm above the floor
of an office corridor transmitted packets to a fixed receiver
positioned at one of three heights above the floor: 120 cm,
38 cm, and directly on the floor. The experiment was repeated
at several transmitter-receiver separation distances.
At each distance and height, 250 packets were transmitted,
and the receiver logged the RSS of each detected packet.

The result of this experiment is shown in
[Figure 4: Received signal strength vs. tx-rx distance and receiver height],
which plots the average RSS as a function of transmitter-receiver
distance for each of the three receiver heights. The first six distance 
measurements were made with line-of-sight (LOS) links, while the last two 
(beyond 23 m) were non-LOS.

The file "receiver-height.txt" consists of:
- first column: tx-rx dist (m)  
- second column: average rss of a receiver at 120 cm high (dBm)
- third column: average rss of a receiver at 38 cm high (dBm)
- fourth column: average rss of a receiver at on floor (dBm)

[Trace] nist/multihop/experiments/link-symmetry (v. 2007-08-20)

top

the initial version

@MISC{nist-multihop-experiments-link-symmetry-2007-08-20,
  author = {Johannes Geissbuehler and Michael R. Souryal},
  title = {{CRAWDAD} trace nist/multihop/experiments/link-symmetry (v. 2007-08-20)}, 
  howpublished = {Downloaded from http://crawdad.cs.dartmouth.edu/nist/multihop/experiments/link-symmetry},
  month = aug,  
  year = 2007
}
					

Trace of RSS measurement in bidirectional link for the automated deployment of a multihop wireless network.

One transceiver transmitted 1000 packets at a rate of 4 packets/s, 
and the other transceiver immediately replied with an acknowledgment
(ACK) for each packet it successfully received using the built-in 
ACK of theMAC. The second transceiver recorded the RSS of each packet 
it detected, while the first transceiver recorded the RSS of each ACK 
it detected. 

In this way, we were able to make nearly simultaneous measurements
of the RSS in both directions of the link. Measurements were taken 
for a relatively strong link (approximately 2 m, LOS) and a second 
link roughly 20 dB weaker (approximately 7 m, non-LOS). Using a spectrum 
analyzer, we observed no other emissions on the same 900 MHz channel
(i.e., an interference-free environment).

To test RSS symmetry, we compared the RSS measured
at each end of a fixed point-to-point link.  

The result of this experiment is shown in
[Figure: Instantaneous received signal strength of received packets and acknowledgments],
which plots the instantaneous RSS measurements made on receipt 
of the packets and the ACKs for both links over a total duration 
of 250 s.

The file "link-symmetry.txt" consists of:

- first column:  packet no.      
- second column: rss of Link 1 Packet (dBm)   
- third column: rss of Link 1 ACK (dBm) 
- fourth column: rss of Link 2 Packet (dBm) 
- fifth column: rss of Link 2 ACK (dBm)

[Trace] nist/multihop/experiments/selection-D (v. 2007-08-20)

top

the initial version

@MISC{nist-multihop-experiments-selection-D-2007-08-20,
  author = {Johannes Geissbuehler and Michael R. Souryal},
  title = {{CRAWDAD} trace nist/multihop/experiments/selection-D (v. 2007-08-20)}, 
  howpublished = {Downloaded from http://crawdad.cs.dartmouth.edu/nist/multihop/experiments/selection-D},
  month = aug,  
  year = 2007
}
					

Trace of an experiment for parameter selection for the automated deployment of a multihop wireless network.

To implement the deployment algorithm requires, we tried to select values 
for parameters including the probe period (D), the RSS averaging 
filter length (N), and the threshold for triggering deployment (Sth).  

We tested values for (D, N) corresponding to a fixed observation window 
of D = 4 seconds. For each trial, the measuring node executing the
real-time link assessment algorithm (Section 4 in [souryal-multihop])
was carried away from a fixed relay in an office building environment 
at walking speed. When the measuring node gave the indication to deploy, 
the node was placed on the floor and a long sequence of packet transmissions 
was initiated over the fixed link to measure the steady-state RSS.

The result for selecting the probe period (D) is shown in
[Figure: Deviation from deployment threshold for three different choices of probe period D and RSS filter length N].
The plot shows the results of four separate trials for each of three pairs 
of (D, N). The trials consisted of two different paths, and two trials of 
each path. Results are given in terms of the difference between the 
steady-state RSS and the deployment threshold, chosen here to be Sth = -80 dBm.

The file "selection-D.txt" consists of:
- first column: RSS-Sth with Delt=100 N=40 (dB)
- second column: RSS-Sth with Delt=200, N=20 (dB)
- third column: RSS-Sth with Delt=500, N=8 (dB)

[Trace] nist/multihop/experiments/selection-N (v. 2007-08-20)

top

the initial version

@MISC{nist-multihop-experiments-selection-N-2007-08-20,
  author = {Johannes Geissbuehler and Michael R. Souryal},
  title = {{CRAWDAD} trace nist/multihop/experiments/selection-N (v. 2007-08-20)}, 
  howpublished = {Downloaded from http://crawdad.cs.dartmouth.edu/nist/multihop/experiments/selection-N},
  month = aug,  
  year = 2007
}
					

Trace of an experiment for parameter selection for the automated deployment of a multihop wireless network.

To implement the deployment algorithm requires, we tried to select values 
for parameters including the probe period (D), the RSS averaging 
filter length (N), and the threshold for triggering deployment (Sth).  

We tested values for (D, N) corresponding to a fixed observation window 
of D = 4 seconds. For each trial, the measuring node executing the
real-time link assessment algorithm (Section 4 in [souryal-multihop])
was carried away from a fixed relay in an office building environment 
at walking speed. When the measuring node gave the indication to deploy, 
the node was placed on the floor and a long sequence of packet transmissions 
was initiated over the fixed link to measure the steady-state RSS.

The result for selecting the averaging filter length (N) is shown in
[Figure: Deviation from deployment threshold vs. RSS filter length N; probe period D = 100 ms].
The plot shows the results of trials for four different values of N and 
a fixed probe period of D = 100ms.

The file "selection-N.txt" consists of:
- first column: RSS-Sth with Delt=100 N=5 (dB)
- second column: RSS-Sth with Delt=100, N=10 (dB)
- third column: RSS-Sth with Delt=100, N=20 (dB)
- fourth column: RSS-Sth with Delt=100, N=40 (dB)

[Trace] nist/multihop/experiments/validation (v. 2007-08-20)

top

the initial version

@MISC{nist-multihop-experiments-validation-2007-08-20,
  author = {Johannes Geissbuehler and Michael R. Souryal},
  title = {{CRAWDAD} trace nist/multihop/experiments/validation (v. 2007-08-20)}, 
  howpublished = {Downloaded from http://crawdad.cs.dartmouth.edu/nist/multihop/experiments/validation},
  month = aug,  
  year = 2007
}
					

Trace of an experiment for parameter selection for the automated deployment of a multihop wireless network.

To implement the deployment algorithm requires, we tried to select values 
for parameters including the probe period (D), the RSS averaging 
filter length (N), and the threshold for triggering deployment (Sth).  

We tested values for (D, N) corresponding to a fixed observation window 
of D = 4 seconds. For each trial, the measuring node executing the
real-time link assessment algorithm (Section 4 in [souryal-multihop])
was carried away from a fixed relay in an office building environment 
at walking speed. When the measuring node gave the indication to deploy, 
the node was placed on the floor and a long sequence of packet transmissions 
was initiated over the fixed link to measure the steady-state RSS.

The choices of N = 20 and D = 100ms appears to strike a balance 
between consistency and latency. Five additional trials of this choice 
of parameters were done, and the results are shown in 
[Figure: Deviation from deployment threshold with probe period D = 100 ms and RSS filter length N = 20].

The file "validation.txt" consists of:
- first column: RSS-Sth with Delt=100 N=20 (dB)

[Trace] nist/multihop/experiments/prototype (v. 2007-08-20)

top

the initial version

@MISC{nist-multihop-experiments-prototype-2007-08-20,
  author = {Andreas Wapf and Michael R. Souryal},
  title = {{CRAWDAD} trace nist/multihop/experiments/prototype (v. 2007-08-20)}, 
  howpublished = {Downloaded from http://crawdad.cs.dartmouth.edu/nist/multihop/experiments/prototype},
  month = aug,  
  year = 2007
}
					

Trace of experimental trials with the prototype of the automated deployment of a multihop wireless network.

The prototype for real-time network deployment was tested
in the eleven-story Administration building on the main
campus of the National Institute of Standards and Technology.
In each trial, the base node was located in the ground floor 
lobby. The mobile node was started next to the base, was walked 
to a stairwell and then up to the top floor, with relays 
being placed on the floor when indicated by the deployment 
algorithm [souryal-multihop]. After stopping at the top for
data collection, the mobile node was then walked down the
same path to the base node on the ground floor, passing the
relays that were deployed on the way up. 
In most cases, we were able to reach the 10th or 11th floor 
with 9 deployed relays. Typically, 2 relays were deployed
between the base node and the stairwell door, and the remainder 
were deployed inside the stairwell, roughly one relay per 1 1/2 
floors.

During the deployment phase, the stop phase, and the
return phase, message traffic was automatically generated
by the base node application to measure delivery rates and
round-trip delays. Specifically, a ping-like message was sent
every 4 s to the mobile node's mote, which sent a reply to
the base. While at the top of the building, the base node
application also sent automatically generated text messages
every 4 s to the peer application on the mobile node's PDA.
The PDA logged each message that was received and replied
to it with a text message. Round-trip delay and delivery
rate were measured from the ping messages, and one-way
delivery rates were measured from the auto-text messages.

The result of this experiment is shown in
[Figure: Ping roundtrip delay vs. time of trial 3],
which plots ping roundtrip delay over the course of trial 3.

The file "prototype.txt" consists of:
- first column: time (s)        
- second column: roundtrip time (s)

[Author] Michael R. Souryal

top

[Author] Johannes Geissbuehler

top

[Author] Kamran Sayrafian-Pour

top

[Author] Andreas Wapf

top

[Author] Julio Perez

top

[Paper] souryal-multihop

top

When the range of single-hop wireless communication is limited by distance or 
harsh radio propagation conditions, relays can be used to extend the 
communication range through multihop relaying. This paper targets the need in 
certain scenarios for rapid deployment of these relays when little or nothing 
is known in advance about a given environment and its propagation 
characteristics. Applications include first responders entering a large 
building during an emergency, search and rescue robots maneuvering a disaster 
sight, and coal miners working underground. The common element motivating this 
work is the need to maintain communications in an environment where single-hop 
communication is typically inadequate. This paper investigates the feasibility 
of the automated deployment of a multihop network. A deployment procedure is 
proposed that employs real-time link measurements and takes into account the 
physical layer characteristics of a mobile multipath fading environment and the 
radio in use. A prototype system is implemented based on 900 MHz TinyOS motes 
supporting low-speed data applications including text messaging, sensor data 
and Radio Frequency Identification (RFID)-assisted localization. Results of 
deployments in a hi-rise office building are presented.