[Dataset] microsoft/vanlan (v. 2007-09-14)

top

the initial version

@MISC{microsoft-vanlan-2007-09-14,
  author = {Ratul Mahajan},
  title = {{CRAWDAD} data set microsoft/vanlan (v. 2007-09-14)}, 
  howpublished = {Downloaded from http://crawdad.cs.dartmouth.edu/microsoft/vanlan},
  month = sep,  
  year = 2007
}
					

We measured from VanLAN, a modest-size testbed that we have deployed, 
to analyze the fundamental characteristics of WiFi-based connectivity 
between basestations and vehicles in urban settings.

Our goal is to enable cheap and high-throughput wireless connectivity 
to moving vehicles in urban areas. The available options for such 
connectivity today fall short in significant ways. Cellular networks 
are expensive and have low throughput. Same is likely to be true of 
WiMax networks if they were to become a reality. While some exisiting 
WiFi basestations can provide opportunistic connectivity to passing 
vehicles, they are unable to support longer periods of connectivity. 
However, WiFi deployment is becoming denser and in many cases, 
entire cities are being covered. 

We measured from VanLAN, a modest-size testbed that we have deployed, 
to analyze the fundamental characteristics of WiFi-based connectivity 
between basestations and vehicles in urban settings.  Using this data, 
we investigate whether the short range of WiFi and the presence of 
many interferring sources can enable continuous, cheap, high-throughput 
connectivity, by themselves or in conjunction with cellular and WiMax networks.

Our testbed, called VanLan, currently consists of eleven BSs and two
mobile clients. The basestations (BSs) are spread across five office 
buildings on the Microsoft campus in Redmond, WA. 

All nodes have two radios. One radio is configured to Channel 1
of 802.11g and the other to Channel 11. To reduce interference, the
two antennae are separated by at least one foot. By comparing
the cases where only one radio is active to where both are active,
we have confirmed that any residual interference is minimal.
Our radios operate in ad hoc (IBSS) mode using a locally modified
device driver. 

VanLAN uses the following hardware. EnGenius' EMP-8602 modules, 
which are based on the Atheros 5213 chipset, are used as radios. 
Their output power is 400 mW at 1 Mbps and lower at higher 
transmission rates. HyperLink's HG2403MGU antennae are used 
for the vans and HGV-2404U antennae are used for the basestations. 
Both types are omnidirectional in the horizontal plane but radiate 
less energy directly above and below. 

The clients also have an externally mounted GPS unit, so we
know their locations. We use GlobalSat's BU-353 GPS unit which
is based on the SiRF Star III chipset and outputs data once per
second. The uncertainty in the location estimate of this chipset is
under three meters 95% of the time.

We have deployed a testbed on the Microsoft campus. It currently consists 
of 11 WiFi basestations and 2 moving vans that operate around the campus 
during the day. The testbed is meant not only as a research vehicle 
but will also provide connectivity to van riders. We use the testbed nodes 
to generate and log probe traffic.

The data has no personally identifiable information. it was collected 
over a tested (with fixed basestations and a moving van).

[Traceset] microsoft/vanlan/connectivity (v. 2007-09-14)

top

the initial version.

@MISC{microsoft-vanlan-connectivity-2007-09-14,
  author = {Ratul Mahajan},
  title = {{CRAWDAD} trace set microsoft/vanlan/connectivity (v. 2007-09-14)}, 
  howpublished = {Downloaded from http://crawdad.cs.dartmouth.edu/microsoft/vanlan/connectivity},
  month = sep,  
  year = 2007
}
					

We measured from VanLAN, a modest-size testbed that we have deployed, 
to analyze the fundamental characteristics of WiFi-based connectivity 
between basestations and vehicles in urban settings.

A.  VanLAN TESTBED

Our testbed, called VanLan, currently consists of eleven BSs and two
mobile clients. The basestations (BSs) are spread across five office 
buildings on the Microsoft campus in Redmond, WA. 

The network of BSs is connected, but not all pairs of BSs can 
hear each other. The mobile clients are vans that provide a shuttle 
service on and around the campus during the day. They visit the part 
of the campus where the BSs are present roughly ten times a day. 
The roads in this part are similar to urban neighborhood streets 
with a speed limit of around 40 Kmph.

Both BSs and clients are small form factor desktops. BSs are
placed on top floors of the buildings, but their antennae aremounted
on the roofs. Low-loss coaxial cables connect the radios (inside the
desktops) and antennae. Similarly, the clients are placed inside the
vans and their antennae are mounted on the roof. The client desktops
are powered by a dedicated battery that is different from the
van's main battery. This battery charges when the van is on and
powers the clients for about four hours after the van is switched off.
This time is used for software updates through a wireless connection 
with another computer located near the vans' overnight parking
space. (Basestations have Ethernet connections for this purpose.)

All nodes have two radios. One radio is configured to Channel 1
of 802.11g and the other to Channel 11. To reduce interference, the
two antennae are separated by at least one foot. By comparing
the cases where only one radio is active to where both are active,
we have confirmed that any residual interference is minimal.

Our radios operate in ad hoc (IBSS) mode using a locally modified
device driver. One modification forces the use of a fixed BSSID
instead of a randomly generated one. This prevents (temporary)
network partitions when nodes end up with different BSSIDs. It
also means that a BS and a client that come into range can start
communicating immediately, without waiting for their BSSIDs to
be reconciled. Yet another modification lets us log every received
frame along with a hardware timestamp and PHY layer information
such as RSSI while communicating normally (i.e., the radio is not
put in 'monitor' mode).

VanLAN uses the following hardware. EnGenius' EMP-8602 modules, 
which are based on the Atheros 5213 chipset, are used as radios. 
Their output power is 400 mW at 1 Mbps and lower at higher 
transmission rates. HyperLink's HG2403MGU antennae are used 
for the vans and HGV-2404U antennae are used for the basestations. 
Both types are omnidirectional in the horizontal plane but radiate 
less energy directly above and below. 

The clients also have an externally mounted GPS unit, so we
know their locations. We use GlobalSat's BU-353 GPS unit which
is based on the SiRF Star III chipset and outputs data once per
second. The uncertainty in the location estimate of this chipset is
under three meters 95% of the time.
 
B.  Positions of Basestations (supplementary information for the connectivity data)

The positions of basestations are:

our %BsCoords = (bs_1_1  => {lat => 47.6411476269696, lon => -122.125589847565},
                 bs_1_2  => {lat => 47.6406705247778, lon => -122.125589847565},
                 bs_3_1  => {lat => 47.6405584774192, lon => -122.125096321106},
                 bs_3_2  => {lat => 47.6400777553792, lon => -122.125096321106},
                 bs_4_1  => {lat => 47.6399729357003, lon => -122.125563025475},
                 bs_4_2  => {lat => 47.6394922082725, lon => -122.125563025475},
                 bs_5_1  => {lat => 47.6394054599949, lon => -122.125074863434},
                 bs_5_2  => {lat => 47.6389138837009, lon => -122.125096321106},
                 bs_5_3  => {lat => 47.6389138837009, lon => -122.125836610794},                 
				 bs_6_1  => {lat => 47.6388921964049, lon => -122.126222848892},                 
				 bs_6_2  => {lat => 47.6389066546033, lon => -122.126973867416});

The mapping from IP address to node-name:interface pair is:

our %Ip2Name = ("10.198.17.2" => "bs_1_1:5211",
                "10.198.18.2" => "bs_1_1:6211",

                "10.198.17.3" => "bs_1_2:5211",
                "10.198.18.3" => "bs_1_2:6211",

                "10.198.17.4" => "bs_3_1:5211",
                "10.198.18.4" => "bs_3_1:6211",

                "10.198.17.5" => "bs_3_2:5211",
                "10.198.18.5" => "bs_3_2:6211",

                "10.198.17.6" => "bs_4_1:5211",
                "10.198.18.6" => "bs_4_1:6211",

                "10.198.17.7" => "bs_4_2:5211",
                "10.198.18.7" => "bs_4_2:6211",

                "10.198.17.8" => "bs_5_1:5211",
                "10.198.18.8" => "bs_5_1:6211",

                "10.198.17.9" => "bs_5_2:5211",
                "10.198.18.9" => "bs_5_2:6211",

                "10.198.17.10" => "bs_5_3:5211",
                "10.198.18.10" => "bs_5_3:6211",

                "10.198.17.11" => "bs_6_1:5211",
                "10.198.18.11" => "bs_6_1:6211",

                "10.198.17.12" => "bs_6_2:5211",
                "10.198.18.12" => "bs_6_2:6211",

                "10.198.17.102" => "r_1:5211",
                "10.198.18.102" => "r_1:6211",

                "10.198.17.103" => "r_2:5211",
                "10.198.18:103" => "r_2:6211",
               );

[Trace] microsoft/vanlan/connectivity/2007-01-22 (v. 2007-09-14)

top

the initial version

@MISC{microsoft-vanlan-connectivity-2007-01-22-2007-09-14,
  author = {Ratul Mahajan},
  title = {{CRAWDAD} trace microsoft/vanlan/connectivity/2007-01-22 (v. 2007-09-14)}, 
  howpublished = {Downloaded from http://crawdad.cs.dartmouth.edu/microsoft/vanlan/connectivity/2007-01-22},
  month = sep,  
  year = 2007
}
					

Trace of WiFi-based connectivity between basestations and vehicles in urban settings, collected on 2007-01-22.

The directory contains data for a day on 2007-01-22. This is a
subset of the data used in the following paper:

Understanding WiFi-based Connectivity From Moving Vehicles
Ratul Mahajan, John Zahorjan, and Brian Zill
ACM/Usenix Internet Measurement Conference (IMC), October 2007

The name of the directory is the date. There are three kinds of files
in each directory.

A. Application-level traces
---------------------------

The workload for these traces consisted of an application broadcasting
packets periodically on each of the two interfaces. The nodes logged
all packets they sent or heard from other nodes. 

The filenames for such traces are in the following format:

<node-name>.<start-time>.<interface>.bcast-bcast<k>.gz

node-name: name of the machine where this trace was collected.
           r-1 was a van, and details on the basestations are below.

start-time: when the tracing started in the machine's local time

interface: the interface on which the trace was collected.
           ath5211 was on channel 1 and ath6211 was on channel 11.

Traces were rotated after a million packets. The filename suffix <k>
changed upon rotation.

The format in these file is:

(S|R): 2007-01-22T06:48:18.5156250-08:00 10.198.17.102 2007-01-22T06:47:43.9687500-08:00 309 1000 1

Column 1: S is for sent packets, and R is received packets
Column 2: Timestamp when the packet was logged
Column 3: Interface IP addresses of the packet source
Column 4: Experiment Id of the packet sourcing application
          This Id was simply timestamp when the application was started
Column 5: Source-specific sequence number of the packet
Column 6: Transmission rate (in Kbps) at which the packet was sent

B. Wifi traces from a van
-------------------------

These contain all Wifi packets sent and captured by the van, including
beacons from all APs in the environment and data packets from the
application above.

The filename format is:
<node-name>.<start-time>.<interface>.bcast-wifi<k>.gz

See above for the meaning of each component.

The format in these files is:  2007-01-22T06:47:45.4062500-08:00 471 2566571334 2412 0 9 1000 89 MGMT_BEACON F 00:02:6F:3E:1D:77 FF:FF:FF:FF:FF:FF 02:03:04:05:06:07 DS:00 2270 Vanlan-g2412

Column 1: Timestamp (application-level) 
Column 2 and 3: Upper and lower 32 bits of the hardware timestamp
Column 4: Frequency of the logged packet
Column 5: status of this packet. 
          0 means the packet was correctly received
          102 means the packet was successfully transmitted
          Ignore other status values
Column 6: RSSI
Column 7: Transmission rate of the packet (in Kbps)
Column 8: Packet size
Column 9: Retry?
Column 10: Source MAC address
Column 11: Destination MAC address
Column 12: BSSID
Column 13: DS field values; FromDS:ToDS
Column 14: Sequence number of the packet
Column 15: For beacons, the SSID
           For other packets, you can ignore everything beyond this column


C.  GPS logs from a van
-----------------------

GPS data was logged by the van at most once per second.

The filename format is:
   <node-name>.<start-time>.COM4.gps

The format of these traces is:
  2007-01-22T06:47:57.3593750-08:00 2007-01-22T14:47:15.0000000 47.644565 N 122.13342 W 0.13 157 2.9 1 2.7

Column 1: Machine time
Column 2: UTC time 
Column 3: Latitude in degrees, followed by N (for north)
Column 5: Longitude in degrees, following by W (for west)
Column 7: Speed in knots (1 knot = 1.852 Kmph)
Column 8: Direction of motion
Columns 9, 10, 11: Percent, horizontal, and vertical dilution of precision

While unzipping some of the files, you will get "unexpected end of file" error from gzip. 
This is a side-effect of how I was sizpping the files on the fly and terminating the program. 
The data is still readable using 'gunzip -c' or 'zless'.

[Trace] microsoft/vanlan/connectivity/2007-01-23 (v. 2007-09-14)

top

the initial version

@MISC{microsoft-vanlan-connectivity-2007-01-23-2007-09-14,
  author = {Ratul Mahajan},
  title = {{CRAWDAD} trace microsoft/vanlan/connectivity/2007-01-23 (v. 2007-09-14)}, 
  howpublished = {Downloaded from http://crawdad.cs.dartmouth.edu/microsoft/vanlan/connectivity/2007-01-23},
  month = sep,  
  year = 2007
}
					

Trace of WiFi-based connectivity between basestations and vehicles in urban settings, collected on 2007-01-23.

The directory contains data for a day on 2007-01-22. This is a
subset of the data used in the following paper:

Understanding WiFi-based Connectivity From Moving Vehicles
Ratul Mahajan, John Zahorjan, and Brian Zill
ACM/Usenix Internet Measurement Conference (IMC), October 2007

The name of the directory is the date. There are three kinds of files
in each directory.

A. Application-level traces
---------------------------

The workload for these traces consisted of an application broadcasting
packets periodically on each of the two interfaces. The nodes logged
all packets they sent or heard from other nodes. 

The filenames for such traces are in the following format:

<node-name>.<start-time>.<interface>.bcast-bcast<k>.gz

node-name: name of the machine where this trace was collected.
           r-1 was a van, and details on the basestations are below.

start-time: when the tracing started in the machine's local time

interface: the interface on which the trace was collected.
           ath5211 was on channel 1 and ath6211 was on channel 11.

Traces were rotated after a million packets. The filename suffix <k>
changed upon rotation.

The format in these file is:

(S|R): 2007-01-22T06:48:18.5156250-08:00 10.198.17.102 2007-01-22T06:47:43.9687500-08:00 309 1000 1

Column 1: S is for sent packets, and R is received packets
Column 2: Timestamp when the packet was logged
Column 3: Interface IP addresses of the packet source
Column 4: Experiment Id of the packet sourcing application
          This Id was simply timestamp when the application was started
Column 5: Source-specific sequence number of the packet
Column 6: Transmission rate (in Kbps) at which the packet was sent

B. Wifi traces from a van
-------------------------

These contain all Wifi packets sent and captured by the van, including
beacons from all APs in the environment and data packets from the
application above.

The filename format is:
<node-name>.<start-time>.<interface>.bcast-wifi<k>.gz

See above for the meaning of each component.

The format in these files is:  2007-01-22T06:47:45.4062500-08:00 471 2566571334 2412 0 9 1000 89 MGMT_BEACON F 00:02:6F:3E:1D:77 FF:FF:FF:FF:FF:FF 02:03:04:05:06:07 DS:00 2270 Vanlan-g2412

Column 1: Timestamp (application-level) 
Column 2 and 3: Upper and lower 32 bits of the hardware timestamp
Column 4: Frequency of the logged packet
Column 5: status of this packet. 
          0 means the packet was correctly received
          102 means the packet was successfully transmitted
          Ignore other status values
Column 6: RSSI
Column 7: Transmission rate of the packet (in Kbps)
Column 8: Packet size
Column 9: Retry?
Column 10: Source MAC address
Column 11: Destination MAC address
Column 12: BSSID
Column 13: DS field values; FromDS:ToDS
Column 14: Sequence number of the packet
Column 15: For beacons, the SSID
           For other packets, you can ignore everything beyond this column


C.  GPS logs from a van
-----------------------

GPS data was logged by the van at most once per second.

The filename format is:
   <node-name>.<start-time>.COM4.gps

The format of these traces is:
  2007-01-22T06:47:57.3593750-08:00 2007-01-22T14:47:15.0000000 47.644565 N 122.13342 W 0.13 157 2.9 1 2.7

Column 1: Machine time
Column 2: UTC time 
Column 3: Latitude in degrees, followed by N (for north)
Column 5: Longitude in degrees, following by W (for west)
Column 7: Speed in knots (1 knot = 1.852 Kmph)
Column 8: Direction of motion
Columns 9, 10, 11: Percent, horizontal, and vertical dilution of precision

While unzipping some of the files, you will get "unexpected end of file" error from gzip. 
This is a side-effect of how I was sizpping the files on the fly and terminating the program. 
The data is still readable using 'gunzip -c' or 'zless'.

[Trace] microsoft/vanlan/connectivity/2007-01-24 (v. 2007-09-14)

top

the initial version

@MISC{microsoft-vanlan-connectivity-2007-01-24-2007-09-14,
  author = {Ratul Mahajan},
  title = {{CRAWDAD} trace microsoft/vanlan/connectivity/2007-01-24 (v. 2007-09-14)}, 
  howpublished = {Downloaded from http://crawdad.cs.dartmouth.edu/microsoft/vanlan/connectivity/2007-01-24},
  month = sep,  
  year = 2007
}
					

Trace of WiFi-based connectivity between basestations and vehicles in urban settings, collected on 2007-01-24.

The directory contains data for a day on 2007-01-22. This is a
subset of the data used in the following paper:

Understanding WiFi-based Connectivity From Moving Vehicles
Ratul Mahajan, John Zahorjan, and Brian Zill
ACM/Usenix Internet Measurement Conference (IMC), October 2007

The name of the directory is the date. There are three kinds of files
in each directory.

A. Application-level traces
---------------------------

The workload for these traces consisted of an application broadcasting
packets periodically on each of the two interfaces. The nodes logged
all packets they sent or heard from other nodes. 

The filenames for such traces are in the following format:

<node-name>.<start-time>.<interface>.bcast-bcast<k>.gz

node-name: name of the machine where this trace was collected.
           r-1 was a van, and details on the basestations are below.

start-time: when the tracing started in the machine's local time

interface: the interface on which the trace was collected.
           ath5211 was on channel 1 and ath6211 was on channel 11.

Traces were rotated after a million packets. The filename suffix <k>
changed upon rotation.

The format in these file is:

(S|R): 2007-01-22T06:48:18.5156250-08:00 10.198.17.102 2007-01-22T06:47:43.9687500-08:00 309 1000 1

Column 1: S is for sent packets, and R is received packets
Column 2: Timestamp when the packet was logged
Column 3: Interface IP addresses of the packet source
Column 4: Experiment Id of the packet sourcing application
          This Id was simply timestamp when the application was started
Column 5: Source-specific sequence number of the packet
Column 6: Transmission rate (in Kbps) at which the packet was sent

B. Wifi traces from a van
-------------------------

These contain all Wifi packets sent and captured by the van, including
beacons from all APs in the environment and data packets from the
application above.

The filename format is:
<node-name>.<start-time>.<interface>.bcast-wifi<k>.gz

See above for the meaning of each component.

The format in these files is:  2007-01-22T06:47:45.4062500-08:00 471 2566571334 2412 0 9 1000 89 MGMT_BEACON F 00:02:6F:3E:1D:77 FF:FF:FF:FF:FF:FF 02:03:04:05:06:07 DS:00 2270 Vanlan-g2412

Column 1: Timestamp (application-level) 
Column 2 and 3: Upper and lower 32 bits of the hardware timestamp
Column 4: Frequency of the logged packet
Column 5: status of this packet. 
          0 means the packet was correctly received
          102 means the packet was successfully transmitted
          Ignore other status values
Column 6: RSSI
Column 7: Transmission rate of the packet (in Kbps)
Column 8: Packet size
Column 9: Retry?
Column 10: Source MAC address
Column 11: Destination MAC address
Column 12: BSSID
Column 13: DS field values; FromDS:ToDS
Column 14: Sequence number of the packet
Column 15: For beacons, the SSID
           For other packets, you can ignore everything beyond this column


C.  GPS logs from a van
-----------------------

GPS data was logged by the van at most once per second.

The filename format is:
   <node-name>.<start-time>.COM4.gps

The format of these traces is:
  2007-01-22T06:47:57.3593750-08:00 2007-01-22T14:47:15.0000000 47.644565 N 122.13342 W 0.13 157 2.9 1 2.7

Column 1: Machine time
Column 2: UTC time 
Column 3: Latitude in degrees, followed by N (for north)
Column 5: Longitude in degrees, following by W (for west)
Column 7: Speed in knots (1 knot = 1.852 Kmph)
Column 8: Direction of motion
Columns 9, 10, 11: Percent, horizontal, and vertical dilution of precision

While unzipping some of the files, you will get "unexpected end of file" error from gzip. 
This is a side-effect of how I was sizpping the files on the fly and terminating the program. 
The data is still readable using 'gunzip -c' or 'zless'.

[Trace] microsoft/vanlan/connectivity/2007-01-25 (v. 2007-09-14)

top

the initial version

@MISC{microsoft-vanlan-connectivity-2007-01-25-2007-09-14,
  author = {Ratul Mahajan},
  title = {{CRAWDAD} trace microsoft/vanlan/connectivity/2007-01-25 (v. 2007-09-14)}, 
  howpublished = {Downloaded from http://crawdad.cs.dartmouth.edu/microsoft/vanlan/connectivity/2007-01-25},
  month = sep,  
  year = 2007
}
					

Trace of WiFi-based connectivity between basestations and vehicles in urban settings, collected on 2007-01-25.

The directory contains data for a day on 2007-01-22. This is a
subset of the data used in the following paper:

Understanding WiFi-based Connectivity From Moving Vehicles
Ratul Mahajan, John Zahorjan, and Brian Zill
ACM/Usenix Internet Measurement Conference (IMC), October 2007

The name of the directory is the date. There are three kinds of files
in each directory.

A. Application-level traces
---------------------------

The workload for these traces consisted of an application broadcasting
packets periodically on each of the two interfaces. The nodes logged
all packets they sent or heard from other nodes. 

The filenames for such traces are in the following format:

<node-name>.<start-time>.<interface>.bcast-bcast<k>.gz

node-name: name of the machine where this trace was collected.
           r-1 was a van, and details on the basestations are below.

start-time: when the tracing started in the machine's local time

interface: the interface on which the trace was collected.
           ath5211 was on channel 1 and ath6211 was on channel 11.

Traces were rotated after a million packets. The filename suffix <k>
changed upon rotation.

The format in these file is:

(S|R): 2007-01-22T06:48:18.5156250-08:00 10.198.17.102 2007-01-22T06:47:43.9687500-08:00 309 1000 1

Column 1: S is for sent packets, and R is received packets
Column 2: Timestamp when the packet was logged
Column 3: Interface IP addresses of the packet source
Column 4: Experiment Id of the packet sourcing application
          This Id was simply timestamp when the application was started
Column 5: Source-specific sequence number of the packet
Column 6: Transmission rate (in Kbps) at which the packet was sent

B. Wifi traces from a van
-------------------------

These contain all Wifi packets sent and captured by the van, including
beacons from all APs in the environment and data packets from the
application above.

The filename format is:
<node-name>.<start-time>.<interface>.bcast-wifi<k>.gz

See above for the meaning of each component.

The format in these files is:  2007-01-22T06:47:45.4062500-08:00 471 2566571334 2412 0 9 1000 89 MGMT_BEACON F 00:02:6F:3E:1D:77 FF:FF:FF:FF:FF:FF 02:03:04:05:06:07 DS:00 2270 Vanlan-g2412

Column 1: Timestamp (application-level) 
Column 2 and 3: Upper and lower 32 bits of the hardware timestamp
Column 4: Frequency of the logged packet
Column 5: status of this packet. 
          0 means the packet was correctly received
          102 means the packet was successfully transmitted
          Ignore other status values
Column 6: RSSI
Column 7: Transmission rate of the packet (in Kbps)
Column 8: Packet size
Column 9: Retry?
Column 10: Source MAC address
Column 11: Destination MAC address
Column 12: BSSID
Column 13: DS field values; FromDS:ToDS
Column 14: Sequence number of the packet
Column 15: For beacons, the SSID
           For other packets, you can ignore everything beyond this column


C.  GPS logs from a van
-----------------------

GPS data was logged by the van at most once per second.

The filename format is:
   <node-name>.<start-time>.COM4.gps

The format of these traces is:
  2007-01-22T06:47:57.3593750-08:00 2007-01-22T14:47:15.0000000 47.644565 N 122.13342 W 0.13 157 2.9 1 2.7

Column 1: Machine time
Column 2: UTC time 
Column 3: Latitude in degrees, followed by N (for north)
Column 5: Longitude in degrees, following by W (for west)
Column 7: Speed in knots (1 knot = 1.852 Kmph)
Column 8: Direction of motion
Columns 9, 10, 11: Percent, horizontal, and vertical dilution of precision

While unzipping some of the files, you will get "unexpected end of file" error from gzip. 
This is a side-effect of how I was sizpping the files on the fly and terminating the program. 
The data is still readable using 'gunzip -c' or 'zless'.

[Trace] microsoft/vanlan/connectivity/2007-01-26 (v. 2007-09-14)

top

the initial version

@MISC{microsoft-vanlan-connectivity-2007-01-26-2007-09-14,
  author = {Ratul Mahajan},
  title = {{CRAWDAD} trace microsoft/vanlan/connectivity/2007-01-26 (v. 2007-09-14)}, 
  howpublished = {Downloaded from http://crawdad.cs.dartmouth.edu/microsoft/vanlan/connectivity/2007-01-26},
  month = sep,  
  year = 2007
}
					

Trace of WiFi-based connectivity between basestations and vehicles in urban settings, collected on 2007-01-26.

The directory contains data for a day on 2007-01-22. This is a
subset of the data used in the following paper:

Understanding WiFi-based Connectivity From Moving Vehicles
Ratul Mahajan, John Zahorjan, and Brian Zill
ACM/Usenix Internet Measurement Conference (IMC), October 2007

The name of the directory is the date. There are three kinds of files
in each directory.

A. Application-level traces
---------------------------

The workload for these traces consisted of an application broadcasting
packets periodically on each of the two interfaces. The nodes logged
all packets they sent or heard from other nodes. 

The filenames for such traces are in the following format:

<node-name>.<start-time>.<interface>.bcast-bcast<k>.gz

node-name: name of the machine where this trace was collected.
           r-1 was a van, and details on the basestations are below.

start-time: when the tracing started in the machine's local time

interface: the interface on which the trace was collected.
           ath5211 was on channel 1 and ath6211 was on channel 11.

Traces were rotated after a million packets. The filename suffix <k>
changed upon rotation.

The format in these file is:

(S|R): 2007-01-22T06:48:18.5156250-08:00 10.198.17.102 2007-01-22T06:47:43.9687500-08:00 309 1000 1

Column 1: S is for sent packets, and R is received packets
Column 2: Timestamp when the packet was logged
Column 3: Interface IP addresses of the packet source
Column 4: Experiment Id of the packet sourcing application
          This Id was simply timestamp when the application was started
Column 5: Source-specific sequence number of the packet
Column 6: Transmission rate (in Kbps) at which the packet was sent

B. Wifi traces from a van
-------------------------

These contain all Wifi packets sent and captured by the van, including
beacons from all APs in the environment and data packets from the
application above.

The filename format is:
<node-name>.<start-time>.<interface>.bcast-wifi<k>.gz

See above for the meaning of each component.

The format in these files is:  2007-01-22T06:47:45.4062500-08:00 471 2566571334 2412 0 9 1000 89 MGMT_BEACON F 00:02:6F:3E:1D:77 FF:FF:FF:FF:FF:FF 02:03:04:05:06:07 DS:00 2270 Vanlan-g2412

Column 1: Timestamp (application-level) 
Column 2 and 3: Upper and lower 32 bits of the hardware timestamp
Column 4: Frequency of the logged packet
Column 5: status of this packet. 
          0 means the packet was correctly received
          102 means the packet was successfully transmitted
          Ignore other status values
Column 6: RSSI
Column 7: Transmission rate of the packet (in Kbps)
Column 8: Packet size
Column 9: Retry?
Column 10: Source MAC address
Column 11: Destination MAC address
Column 12: BSSID
Column 13: DS field values; FromDS:ToDS
Column 14: Sequence number of the packet
Column 15: For beacons, the SSID
           For other packets, you can ignore everything beyond this column


C.  GPS logs from a van
-----------------------

GPS data was logged by the van at most once per second.

The filename format is:
   <node-name>.<start-time>.COM4.gps

The format of these traces is:
  2007-01-22T06:47:57.3593750-08:00 2007-01-22T14:47:15.0000000 47.644565 N 122.13342 W 0.13 157 2.9 1 2.7

Column 1: Machine time
Column 2: UTC time 
Column 3: Latitude in degrees, followed by N (for north)
Column 5: Longitude in degrees, following by W (for west)
Column 7: Speed in knots (1 knot = 1.852 Kmph)
Column 8: Direction of motion
Columns 9, 10, 11: Percent, horizontal, and vertical dilution of precision

While unzipping some of the files, you will get "unexpected end of file" error from gzip. 
This is a side-effect of how I was sizpping the files on the fly and terminating the program. 
The data is still readable using 'gunzip -c' or 'zless'.

[Author] Ratul Mahajan

top

[Paper] mahajan-vehicles

top