microsoft/vanlan2007091438200709142007-12-05microsoft/vanlanDataset of WiFi-based connectivity between basestations and vehicles in urban settings.

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.

the initial version2007-09-142007-01-222007-01-26mahajan-vehiclesOriginal data websiteREADME31http://research.microsoft.com/netres/projects/vanlan/http://www.crawdad.org/wiki/pmwiki.php?n=Main.Dataset.microsoft-vanlan802.11GPSvehicular networkNetwork Performance Analysis802.11 ad-hocVehicular networkGPS (Global Positioning System)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).53200709142007-12-05the initial version.microsoft/vanlan/connectivityTraceset of WiFi-based connectivity between basestations and vehicles in urban settings.

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.

2007-09-142007-01-222007-01-26Network Performance AnalysisA. 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", );/download/microsoft/vanlan/README.txtmicrosoft/vanlan148200709142007-12-05the initial versionmicrosoft/vanlan/connectivity/2007-01-22Trace of WiFi-based connectivity between basestations and vehicles in urban settings, collected on 2007-01-22.

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

false2007-09-142007-01-222007-01-22The 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 2007The 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 precisionWhile 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'./download/microsoft/vanlan/2007-01-22microsoft/vanlan/connectivity149200709142007-12-05the initial versionmicrosoft/vanlan/connectivity/2007-01-23Trace of WiFi-based connectivity between basestations and vehicles in urban settings, collected on 2007-01-23.

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

false2007-09-142007-01-232007-01-23The 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 2007The 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 precisionWhile 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'./download/microsoft/vanlan/2007-01-23microsoft/vanlan/connectivity150200709142007-12-05the initial versionmicrosoft/vanlan/connectivity/2007-01-24Trace of WiFi-based connectivity between basestations and vehicles in urban settings, collected on 2007-01-24.

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

false2007-09-142007-01-242007-01-24The 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 2007The 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 precisionWhile 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'./download/microsoft/vanlan/2007-01-24microsoft/vanlan/connectivity151200709142007-12-05the initial versionmicrosoft/vanlan/connectivity/2007-01-25Trace of WiFi-based connectivity between basestations and vehicles in urban settings, collected on 2007-01-25.

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

false2007-09-142007-01-252007-01-25The 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 2007The 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 precisionWhile 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'./download/microsoft/vanlan/2007-01-25microsoft/vanlan/connectivity152200709142007-12-05the initial versionmicrosoft/vanlan/connectivity/2007-01-26Trace of WiFi-based connectivity between basestations and vehicles in urban settings, collected on 2007-01-26.

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

false2007-09-142007-01-262007-01-26The 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 2007The 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 precisionWhile 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'./download/microsoft/vanlan/2007-01-26microsoft/vanlan/connectivity31umass/dieselmicrosoft/vanlanmicrosoft/osdi2006uw/sigcomm2004tools/analyze/802.11/WitRatul Mahajanratul@microsoft.comMicrosoft Researchhttp://research.microsoft.com/~ratul/mahajan-vehiclesRatul MahajanJohn ZahorjanBrian ZillProceedings of the Internet Measurement Conference--10--2007

San Diego, CA, USA

http://www.imconf.net/imc-2007/papers/imc18.pdfcrawdadmeasurementwirelessmicrosoft_vanlancrawdadmicrosoft/vanlan20071001