CRAWDAD umass/diesel (v. 2006-01-17)

The bus-based DTN (Disruption-tolerant networks) traces from UMass Amherst campus.

Note: This dataset has multiple versions.  The dataset file names of the data associated with this version are listed below, under the 'Traceset' heading and can be downloaded under 'Dataset Files' on the right-hand side of the page.

 The bus-based DTN (Disruption-tolerant networks) traces from UMass Amherst campus.

This dataset includes the real mobility and real transfers of the bus-based DTN (Disruption-tolerant-network) testbed, called UMassDieselNet, operating from the UMass Amherst campus and the surrounding county.

The following traces have been added: transfer/fall2007, transfer/ap_connectivity, and transfer/vifi.

date/time of measurement start: 2005-01-25

date/time of measurement end: 2007-12-14

collection environment: We have constructed a DTN testbed composed of 30-40 buses operated by the UMass Amherst branch of the Pioneer Valley Transport Authority (PVTA) that we have fitted with a custom package of off-the-shelf hardware. This testbed is called UMassDieselNet. The transit buses service an area sparsely covering approximately 150 square miles. The route each bus is placed on each day is chosen by the garage dispatcher and can change during the day. Buses can leave the network at any time. We did not try to automatically determine the routes of buses, though this is possible with some significant effort. We decided against this approach after finding GPS data often inconsistent or containing gaps where line-of-sight to satellites was lost.

network configuration: The testbed began operating in May 2004 with five buses. Each bus carries a HaCom Open Brick computer (P6-compatible 577Mhz CPU, 256MB RAM). An 802.11b Access Point (AP) is attached to each brick to provide DHCP access to passengers and passersby. A second USB-based 802.11b interface constantly scans the surrounding area for DHCP offers and other buses. Each bus also has a GPS device attached to the brick. Each brick runs Linux on a 40GB notebook hard drive.

data collection methodology: See the metadata of each traceset or trace for details of collection methodology.

Tracesets

umass/diesel/throwbox

• file: DieselNetThrowbox.tar.gz
• description: This traceset was collected during the throwbox deployment in Umass DieselNet in Summer 2006. The traces contain bus-bus transfer records and bus-throwbox transfer records.
• measurement purpose: Routing Protocol for DTNs (Disruption Tolerant Networks), User Mobility Characterization
• methodology: One solution for improving DTN performance is to place additional stationary nodes in the network, which increases the number and frequency of contact opportunities. We proposed the use of throwboxes within a DTN for this purpose. Throwboxes are inexpensive, battery-powered, stationary nodes with radios and storage. When two nodes pass by the same location at different times, the throwbox acts as a router, creating a new contact opportunity. To support a real-world test of the throwbox, we used our DTN testbed, the UMassDieselNet. The testbed normally consists of 40 buses covering an area of more than 150 square miles. However, when the experiments were performed, during a reduced summer bus schedule, only 10 buses were running on three routes. Each bus is a highly mobile DTN node using a small computer with an attached access point and WiFi interface. Buses constantly scan for other nodes and transfer DTN data whenever a connection can be made. We augmented the equipment on the buses with an XTend radio and added scripts to beacon the position, speed, and direction of motion of the buses once each second. We deployed three always-on throwbox prototypes in fixed locations for three weeks on the UMassDieselNet bus routes.

umass/diesel Traces

• throwbox/summer2006: Bus-to-bus, bus-to-throwbox transfer record collected from DieselNet during 2006 summer.
• file: DieselNetThrowbox.tar.gz
• configuration: The traces contains connection event between buses (in DieselNet) and buses and throwboxes placed in the network.

• format: The name of the bus nodes follow the pattern "PVTA_(bus number)". The three throwboxes placed in the network have names "PVTA_TB0", "PVTA_TB1", "PVTA_TB2". The connectivity traces have data about the duration of contact, time at which the contact took place, the amount of data transfered, the position (longitude and latitude) at which the connections happened and the speed and direction of the bus motion when the connection event took place. The filenames indicate the date on which the connection trace was collected. For example, 6-23-2006 would mean June 23, 2006.

umass/diesel/transfer

• file: DieselNetThrowbox.tar.gz
• description: This set of DieselNet logs were compiled from busses running routes serviced by UmassTransit, which lists their bus routes on the web at http://www.umass.edu/campus_services/transit/. Of UmassTransit's busses, 30-40 busses were equipped with DieselNet equipment and a certain portion of those operated daily as dictated by bus failures and maintenance.
• measurement purpose: Routing Protocol for DTNs (Disruption Tolerant Networks), User Mobility Characterization
• methodology: To maintain and monitor our network, we use numerous external APs that offer free service along the bus routes hosted by third parties. We have installed only two APs - one on campus and one at the bus garage. Whenever the buses have web access, they retrieve software updates from a central server. At that time a bus provides its current GPS location and MAC address, and it uploads logs of its performance during the day, including the throughput of bus-to-bus transfer opportunities, APs contacted, a record of movement, and application records. To enable bus-to-bus transfers, the buses beacon on a single channel once every 100ms. We programmed the bricks in each bus to transfer the largest amount of data possible using TCP at each transfer opportunity. To allow us to easily test different routing algorithms in a real DTN environment, we set the UMassDieselNet buses to transmit random data to one another whenever they are within range and record the time, transmission size, and buses involved.

• transfer/fall2007: Data transfer logs on UmassDieselNet, a disruption-tolerant network (DTN) in the months October-November 2007.
• file: dieselnet-fall-2007.tar.gz
• configuration: The released traces have five directories 1. gps_logs : This is the directory which has the cumulative gps_logs for all the buses seen during the period which the traces were collected. 2. mobile-mobile: This is the collection of all the mobile-mobile contact events. 3. basestation-mobile: The traces are similar to the mobile-mobile traces but are for the AP-mobile contact events. 4. mobile-mobile-mesh-relay: these are the traces for the connection events between a mobile node and the six stationary relay/mesh boxes placed in the network. 5. xtendtrace: This has the connection events between mobile nodes over the Xtend Maxstream radio. If you use these traces in a research paper, please reference the traces as Relays, Base Stations, and Meshes: Enhancing Mobile Networks with Infrastructure. Nilanjan Banerjee, Mark D. Corner, Don Towsley, and Brian Neil Levine. In Proceedings of ACM MobiCom, San Francisco, CA, USA, September 2008. 
• format: The released traces have five directories 1. gps_logs : This is the directory which has the cumulative gps_logs for all the buses seen during the period which the traces were collected. There is a directory corresponding to every bus and within each directory for a bus there are files for every day with a set of time stamped gps locations. 2. mobile-mobile: This is the collection of all the mobile-mobile contact events. Each line includes the time at which a contact occured, the amount of data that was transfered, the duration of contact and the position where the contact took place. 3. basestation-mobile: The traces are similar to the mobile-mobile traces but are for the AP-mobile contact events. 4. mobile-mobile-mesh-relay: these are the traces for the connection events between a mobile node and the six stationary relay/mesh boxes placed in the network. 5. xtendtrace: This has the connection events between mobile nodes over the Xtend Maxstream radio.

• ap_connectivity_fall2007: DieselNet traces consisting of Bus-Bus and Bus-AP interactions during the Fall semester of 2007.

• file: mobicom-traces.tar.gz
• configuration: This set of DieselNet traces where compiled during Fall 2007 from busses running routes serviced by Umass Transit. Umass Transit's 40 busses were equipped with DieselNet equipment and a certain portion of those operated daily as dictated by bus failures and maintenance. Each bus scans for connection with other buses or access points (APs) on the road, and when found, connects to the bus or the AP. This trace contains connection events between busses as well as between a bus and an AP. All connection events occurring during a day are stored in the log file matching that date (year-month-date). Time stamps are recorded as absolute minutes and seconds after midnight. If you use these traces in a research paper, please reference the traces as Aruna Balasubramanianm Brian Neil Levine and Arun Venkataramani, "Enabling Interactive Applications for Hybrid Networks" in Proceedings of ACM Mobicom, September 2008.

• format: There are two files with the same name under two different directories called bus-bus and bus-ap. The bus-bus directory contains trace logs of bus connections, while the bus-ap directory contains trace logs of a bus-AP connections. Bus-AP ---------- We made sure to log only interactions with open APs, by pinging a well known server using the open AP connection. We do not send data during the open AP connection and use periodic ping messages to estimate the total length of the connection. The connection length excludes time taken for association and getting a DHCP address. As example entry in the log is 3204 00:12:17:c5:71:72 0:0:1 null 5.182 72.5552333333 42.2817516667 The first column is the bus ID, the second column in the MAC address of the AP, the third column is the time. The fourth column is always null and is for consistency with the bus-bus traces. The fifth column is the total duration of meeting in seconds. The last two columns are the longitude and latitude respectively. Bus-Bus ------------ Each bus are identified by an ID. In the following entry, bus 3030 sent bus 3203 at 0:27:22 transferring 2297600 bytes. The connection lasted for 33 seconds and the latitude and longitude of meeting is 72.53267 and 42.39381 respectively. Entries where the first or second column is "null" should be ignored. 3030 3203 0:27:22 2297600 33 72.53396 42.3946283333.

• vifi: AP connectivity from a bus in December 2007.

• file: vifi-release.tar.gz
• configuration: This set of DieselNet traces where compiled from December 4 to 6th on Channel 1 and December 12th to 14th on Channel 6. The trace logs contain the connection quality between one bus and APs on the road. The connection quality is measured using AP beacons heard by the bus on a per second granularity. The bus was set in promiscuous mode when the traces were logged. The traces only includes APs found in the Amherst town center. There are 10 such APs in Channel 1 and 14 in Channel 6. We present the connection quality between the bus and APs as path loss values (in db). Apart from the connection quality between a bus and an AP, the trace also contains connection quality between two APs. Since this information is not available from the beacons, we first approximate all APs from which the bus receives beacons in a single time interval, to be within the transmission range. For two APs within transmission range, we assign the path loss values uniformly at random between 80db to 110db. If you use these traces in a research paper, please reference the traces as Aruna Balasubramanian, Ratul Mahajan, Arun Venkataramani, Brian Neil Levine and John Zahorjan "Interactive WiFi Connectivity for Moving Vehicles" in Proceedings of ACM Sigcomm, August 2008
• format: The trace directory contains 10 trace files each for Channel 1 and Channel 6. The 10 trace files are generated with different seeds. In the traces, the bus is identified by the number 1. All APs are marked from 2 onwards. The first column is the time, the second column is the first participant and the third column in the second participant. The participant is either the bus or the AP. The last column is the path loss value. A sample log from the trace is 3 1 2 92 3 4 10 84 The first line says that, at 3 seconds, the path loss value between the bus (marked 1) and AP 2 is 92 db. The second line says that, at time 3 seconds, AP 4.

• ap_connectivity: Bus-to-ap transfer record collected from DieselNet during the spring semester of 2007.

• file: APConnectivitySpring2007.tar.gz
• configuration: UmassTransit's 40 busses were equipped with DieselNet equipment and a certain portion of those operated daily as dictated by bus failures and maintenance.
• format: All connection events occurring during a day are stored in the log file matching that date (month/day/year). The buses are identified by their MAC address. Time stamps are recorded as absolute minutes and seconds after midnight. In the following entry, bus 00:09:5B:B3:51:6B met an access point at 16 minutes and 44 seconds after midnight for a duration of 36 seconds. Bus 00:09:5B:B3:51:6B with AP at time 00:16:44 for 36.0 seconds.

• spring2006: Bus-to-bus transfer record collected from DieselNet during the spring semester of 2006.

• file: DieselNetTracesSpring2006.tar.gz
• configuration: This trace includes two directories: * Bus-Bus subdirectory contains bus-to-bus transfer records * DispatchRecord subdirectory contains bus dispatching records.
• format: 1. Bus-to-bus transfer records are saved in files named as MDDYYYY, for example, file 2082006 contains transfer records for Feb 08, 2006. Within each file, each line describe a bus-to-bus transfer. For example, the following sample lines: Bus 3112 at 72.532745 42.393852 on route 1 in contact with bus 3114 at 72.532745 42.393852 on route 1 at time 418:27 for 45204688 bytes in 184792.0 ms means that the bus 3112 was in contact with bus 3114 while it's at location (72.532745 N,42.393852 W). The contact started at 418mins and 27 seconds after the 00:00:00 (i.e., 6:58:27 A.M.) of Feb 28, 2006, and lasts for 194792.0 milliseconds. Note that the "on route 1" information should be ignored. 2. Dispathcing records include two files: DA_all.txt and DB_sheet.txt. * The DA_all.txt contains the dispatching records (inputed by hand from the DA sheets, with drivers name ignored). For example, the following sample lines in the file: ---------------------------------------------------- DATE 4/3/2006 ## AM SHIFTS TIME_AT_GARAGE SHIFT BUS DRIVER In_SERVICE IN_SERVICE_LOC DRVR_CHNG 6:10 AM21 34 NA 6:55 MHC 10:30 6:10 AM42 32 NA 6:30 GRC 8:32 6:25 AM22 38 NA 6:45 HAGISMALL 11:00 6:30 AM43 42 NA 6:50 STKRD 9:05M 9:23T 6:40 AM45 12 NA 7:00 GRC 8:49 6:40 AM31 16 NA 7:10 HAMPCOLL 10:45B/11:05G 6:42 AM11 33 NA 7:12 OLDBTOWN 10:51 6:45 AMA 21 NA 7:05 STADIUM 10:35 6:50 AM23 35 NA 7:10 HAGISMALL 10:00 6:52 AM1 36 NA 7:19 CLIFFSIDE 10:52 ..... Here, DATE line indicates the following records are for the date specified. Each line follows give "TIME_AT_GARAGE SHIFT BUS DRIVER In_SERVICE IN_SERVICE_LOC DRVR_CHNG" for each shift. For example, the line: 6:10 AM21 34 NA 6:55 MHC 10:30 means that bus 34 serve shift AM21 on that day, it starts at garage at 6:10 A.M., and starts to enter service at 6:55 A.M. at bus stop MHC. The bus will be changed to another driver (also to another shift) at 10:30 A.M. ** DB_sheet.txt contains essentially similar information, dumped from a database system. Each line in the file specifies the mapping from bus to shift. For example, 03/01/2006,30,15MID,3033 means that on March 1 2006, bus 3033 was dispatched to run on shift MID15, route 30.

• spring2007: Bus-to-bus transfer record collected from DieselNet during the spring semester of 2007.

• file: DieselNetTracesSpring2007.tar.gz
• configuration: This set of DieselNet traces where compiled during Spring 2007 from busses running routes serviced by UmassTransit. UmassTransit's 40 busses were equipped with DieselNet equipment and a certain portion of those operated daily as dictated by bus failures and maintenance.
• format: All connection events occurring during a day are stored in the log file matching that date (month/day/year). The buses are identified by their MAC address. Time stamps are recorded as absolute minutes and seconds after midnight. In the following entry, bus 00:09:5B:B3:E3:4E sent bus 00:09:5B:B5:6E:6E at 06:57:18 transferring 94240422 bytes. The latitude and longitude of meeting is 72.53267 and 42.39381 respectively. The last column is true if the satellite reading is current and false otherwise. 00:09:5B:B3:E3:4E 00:09:5B:B5:6E:6E 06:57:18 94240422 72.53267 42.39381 true.

• infocom2006: Data transfer logs between buses on UmassDieselNet, a disruption-tolerant network (DTN) for Infocom 2006 paper.

• file: UMassDieselNet_Spring2005.tar.gz
• configuration: Our testbed is subject to the real schedule of the UMass campus - many fewer buses run on weekends and holidays. To realize some uniformity, we used 60 traces from weekdays between January 25, 2005 to May 6, 2005; we excluded holidays and other occasions causing buses to run infrequently. On average, about 28 buses are active each day, and each days lasts from about 7AM to 7PM. In all, the traces consist of over 720 hours of recorded data for each of the 30 buses (about 20,000 bus-hours total). Busses are assigned a route semi-arbitrarily each day. Some routes require short busses, some routes require long busses, and some vary by their passenger capacity needs: - Routes 30, 31, and 38 must use long busses - Routes 34, 35, 37, and 39 must use shot busses - Routes 32, 33, 36, 45, and 46 may use either Bus numbers beginning 30xx are long busses, bus numbers beginning 31xx are short busses. Though not present in these logs, prefix numbers other than 31xx and 30xx indicate a test unit or other non-bus based unit (which often show up on the Umass DieselNet web site).
• format: All connection events occurring during a day are stored in the log file matching that date (month/day/year). Log events are entered by the bus receiving the data, which is the first bus listed on each line. Though events would ideally be symmetrical, they, in reality, are not. Whichever sending connection begins first will reach maximum speed and slow the "ramping up" of the TCP connection going in the other direction (over time they will equalize). Additionally, a connection in one event may succeed while a connection in the opposite direction may not be established due to network configuration hiccups (the linux network stack and wifi drivers were not targeted toward an environment where interfaces are rapidly reconfigured). Time stamps are recorded as absolute minutes and seconds after midnight. In the following entry, bus 3123 receives 277512 bytes from bus 3102 at 6:55:11 AM. Routes and GPS coordinates should be ignored because GPS information was not accurate when these logs were being generated. "Bus 3123 at 72.53236 42.3933 on route 1 in contact with bus 3102 at 72.53236 42.3933 on route 1 at time 415:11 for 277512 bytes"