umass/diesel20080914720080914200712022008-10-21umass/dieselThe 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.
umass/diesel/transfer2008-10-212005-01-252007-12-1420213133191186187188189190195http://prisms.cs.umass.edu/diesel/http://www.crawdad.org/wiki/pmwiki.php?n=Main.Dataset.umass-dieselpacket trace802.11802.11bGPSvehicular networklocationRouting Protocol for DTNs (Disruption Tolerent Networks)User Mobility Characterization802.11 infrastructureDisruption tolerant network (DTN)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.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.See the metadata of each traceset or trace for details of collection methodology.54200712022007-12-05umass/diesel/throwboxBus-to-bus, bus-to-throwbox transfer record collected from DieselNet during 2006 summer.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.the initial versionRouting Protocol for DTNs (Disruption Tolerent Networks)User Mobility Characterization2007-12-022005-01-252007-05-1418919021One 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/diesel154200712022007-12-05umass/diesel/throwbox/summer2006Bus-to-bus, bus-to-throwbox transfer record collected from DieselNet during 2006 summer.The traces contains connection event between buses (in DieselNet)
and buses and throwboxes placed in the network.the initial versionfalse2007-12-022006-06-232006-07-21The traces contains connection event between buses (in DieselNet)
and buses and throwboxes placed in the network.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./download/umass/diesel/DieselNetThrowbox.tar.gzumass/diesel/throwbox1120080914200712022008-10-21umass/diesel/transferData transfer logs between buses on UmassDieselNet, a disruption-tolerant network (DTN).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.The following traces have been added:
transfer/spring2006, transfer/spring2007, and transfer/ap_connectivityumass/diesel/transfer/fall2007umass/diesel/transfer/ap_connectivity_fall2007umass/diesel/transfer/vifi2008-09-142005-01-252007-12-14Routing Protocol for DTNs (Disruption Tolerent Networks)User Mobility CharacterizationTo 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.We excluded holidays and other occasions causing buses to run infrequently.umass/diesel266200809142008-10-21umass/diesel/transfer/fall2007Data transfer logs on UmassDieselNet, a disruption-tolerant network (DTN) in the months October-November 2007.Data transfer logs on UmassDieselNet, a disruption-tolerant network (DTN) in the months October-November 2007.the initial versionfalse2008-09-142007-10-232007-11-1118919019521The 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.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./download/umass/diesel/dieselnet-fall-2007.tar.gzumass/diesel/transfer267200809132008-10-21umass/diesel/transfer/ap_connectivity_fall2007DieselNet traces consisting of Bus-Bus and Bus-AP interactions during the Fall semester of 2007.This set of traces were collected from UMass DieselNet
during the Fall semester of 2007. The traces contain connection times and durations
between two buses and between a bus and an AP.the initial versionfalse2008-09-132007-10-222007-11-1619121186This 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 2008There 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/download/umass/diesel/mobicom-traces.tar.gzumass/diesel/transfer268200806082008-10-21umass/diesel/transfer/vifiAP connectivity from a bus in December 2007.This set of DieselNet traces were compiled in December 2007
and contains 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 initial versionfalse2008-06-082007-12-042007-12-14191311862133This 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 2008The 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 and AP 10 have
a path loss value of 84db./download/umass/diesel/vifi-release.tar.gzumass/diesel/transfer155200712022007-12-05umass/diesel/transfer/ap_connectivityBus-to-ap transfer record collected from DieselNet during the spring semester of 2007.Bus-to-ap transfer record collected from DieselNet during the spring semester of 2007.the initial versionfalse2007-12-022007-03-262007-03-3019118721186188UmassTransit's 40 busses were equipped with DieselNet equipment and a
certain portion of those operated daily as dictated by bus failures
and maintenance.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/download/umass/diesel/APConnectivitySpring2007.tar.gzumass/diesel/transfer153200712022007-12-05umass/diesel/transfer/spring2006Bus-to-bus transfer record collected from DieselNet during the spring semester of 2006.Bus-to-bus transfer record collected from DieselNet during the spring semester of 2006.the initial versionfalse2007-12-022006-01-302006-06-22This trace includes two directories:
* Bus-Bus subdirectory contains bus-to-bus transfer records
* DispatchRecord subdirectory contains bus dispatching records.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./download/umass/diesel/DieselNetTracesSpring2006.tar.gzumass/diesel/transfer154200712022007-12-05umass/diesel/transfer/spring2007Bus-to-bus transfer record collected from DieselNet during the spring semester of 2007.This set of DieselNet traces where compiled during Spring 2007 from busses
running routes serviced by UmassTransit, which lists their bus routes on
the web at http://www.umass.edu/campus_services/transit/. UmassTransit's
40 busses were equipped with DieselNet equipment and a certain portion of
those operated daily as dictated by bus failures and maintenance.the initial versionfalse2007-12-022007-02-062007-05-1419121186This 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.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/download/umass/diesel/DieselNetTracesSpring2007.tar.gzumass/diesel/transfer24200601172007-12-05umass/diesel/transfer/infocom2006Data transfer logs between buses on UmassDieselNet, a disruption-tolerant network (DTN) for Infocom 2006 paper.This set of DieselNet logs were compiled during the Spring semester of 2005
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 40 busses, approximately
30 busses were equipped with DieselNet equipment and a certain portion of those operated daily
as dictated by bus failures and maintenance.the initial versionfalse2006-01-172005-01-252005-05-22Our 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).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"/download/umass/diesel/UMassDieselNet_Spring2005.tar.gzumass/diesel/transfer20umass/dieselJohn Burgessjburgess@cs.umass.eduUniversity of Massachusetts, AmherstDepartment of Computer ScienceGraduate StudentComputer Science Research Bldg,
140 Governors Drive, Amherst, MA 01003413-545-0067http://www.cs.umass.edu/~jburgess/21umass/dieselBrian Neil Levinebrian@cs.umass.eduUniversity of Massachusetts, AmherstDepartment of Computer ScienceAssociate ProfessorRoom 346 Computer Science Research Bldg,
140 Governors Drive, Amherst, MA 01003413-577-0238413-545-1249http://www.cs.umass.edu/~brian/31umass/dieselmicrosoft/vanlanmicrosoft/osdi2006uw/sigcomm2004tools/analyze/802.11/WitRatul Mahajanratul@microsoft.comMicrosoft Researchhttp://research.microsoft.com/~ratul/33umass/dieseluw/sigcomm2004tools/analyze/802.11/WitJohn Zahorjanzahorjan@cs.washington.eduUniversity of WashingtonDepartment of Computer Science and EngineeringProfessorDepartment of Computer Science and Engineering, University of Washington, Box 352350, Seattle, WA 98195-2350206-543-0101206-542-2969http://www.cs.washington.edu/homes/zahorjan/homepage/191umass/dieselAruna Balasubramanianarunab@cs.umass.eduUniversity of Massachusetts, AmherstDepartment of Computer SciencePh.D. StudentComputer Science Research Bldg,
140 Governors Drive, Amherst, MA 01003413-545-0582http://www.cs.umass.edu/~arunab186umass/dieselArun Venkataramaniarun@cs.umass.eduUniversity of Massachusetts, AmherstDepartment of Computer ScienceAssistant ProfessorComputer Science Research Bldg,
140 Governors Drive, Amherst, MA 01003(413) 545-3651http://www.cs.umass.edu/~arun187umass/dieselYun Zhouyzhou@cs.umass.eduUniversity of Massachusetts, AmherstDepartment of Computer ScienceComputer Science Research Bldg,
140 Governors Drive, Amherst, MA 01003(413) 545-3059http://www.cs.umass.edu/~yzhou188umass/dieselBruce Croftcroft@cs.umass.eduUniversity of Massachusetts, AmherstDepartment of Computer ScienceDistinguished ProfessorComputer Science Research Bldg,
140 Governors Drive, Amherst, MA 01003(413) 545-0463(413) 545-1789http://ciir.cs.umass.edu/personnel/croft.html189umass/dieselNilanjan Banerjeenilanb@cs.umass.eduUniversity of Massachusetts, AmherstDepartment of Computer SciencePhD CandidateComputer Science Research Bldg,
140 Governors Drive, Amherst, MA 01003http://www.cs.umass.edu/~nilanb/190umass/dieselMark Cornermcorner@cs.umass.eduUniversity of Massachusetts, AmherstDepartment of Computer ScienceAssistant ProfessorComputer Science Research Bldg,
140 Governors Drive, Amherst, MA 01003(413) 545-3788http://prisms.cs.umass.edu/mcorner195umass/dieselDon Towsleytowsley@cs.umass.eduUniversity of Massachusetts, AmherstDepartment of Computer ScienceProfessor(413) 545-0207http://www-net.cs.umass.edu/personnel/towsley.htmlbalasubramanian-dtnAruna BalasubramanianBrian Neil LevineArun VenkataramaniDTN Routing as a Resource Allocation ProblemProc. ACM Sigcomm--08--2007Kyoto, Japanhttp://www.sigcomm.org/ccr/drupal/?q=node/273crawdadmeasurementwirelessumass_dieselcrawdadumass/diesel20070801balasubramanian-hybridAruna BalasubramanianBrian Neil LevineArun VenkataramaniEnhancing interactive web applications in hybrid networkscrawdadumass/dieselmeasurementwirelessMobiCom '08: Proceedings of the 14th ACM international conference on Mobile computing and networking2008978-1-60558-096-870-80San Francisco, California, USAhttp://doi.acm.org/10.1145/1409944.1409954http://doi.acm.org/10.1145/1409944.1409954ACMumass/diesel20080001balasubramanian-interactiveAruna BalasubramanianRatul MahajanArun VenkataramaniBrian Neil LevineJohn ZahorjanInteractive wifi connectivity for moving vehiclescrawdadumass/dieselmeasurementwirelessSIGCOMM Comput. Commun. Rev.38420080146-4833427-438http://doi.acm.org/10.1145/1402946.1403006ACMNew York, NY, USAumass/diesel20080001balasubramanian-searchAruna BalasubramanianYun ZhouW. Bruce CroftBrian. N. LevineArun VenkataramaniWeb Search From a BusACM Mobicom Workshop on Challenged Networks (CHANTS 07)Montreal, Canada--09--2007http://portal.acm.org/citation.cfm?id=1287803crawdadmeasurementwirelessumass_dieselcrawdadumass/diesel20070901banerjee-relaysNilanjan BanerjeeMark D. CornerDon TowsleyBrian N. LevineRelays, base stations, and meshes: enhancing mobile networks with infrastructurecrawdadumass/dieselmeasurementwirelessMobiCom '08: Proceedings of the 14th ACM international conference on Mobile computing and networking2008978-1-60558-096-881-91San Francisco, California, USAhttp://doi.acm.org/10.1145/1409944.1409955http://doi.acm.org/10.1145/1409944.1409955ACMumass/diesel20080001banerjee-throwboxesNilanjan BanerjeeMark D. CornerBrian LevineAn Energy-Efficient Architecture for DTN ThrowboxesProceedings of Infocom 2007)Anchorage, Alaska--05--2007http://www.cs.umass.edu/~nilanb/papers/banerjee06-39.pdfcrawdadmeasurementwirelessumass_dieselcrawdadumass/diesel20070501burgess-attacksJohn BurgessGeorge Dean BissiasMark D. CornerBrian Neil LevineSurviving attacks on disruption-tolerant networks without authenticationMobiHoc '07: Proceedings of the 8th ACM international symposium on Mobile ad hoc networking and computing200761-70Montreal, Quebec, Canadameasurementwirelessumass_dieselcambrdge_hagglecrawdadhttp://doi.acm.org/10.1145/1288107.1288116http://doi.acm.org/10.1145/1288107.1288116ACM PressDisruption-Tolerant Networks (DTNs) deliver data in network environments
composed of intermittently connected nodes. Just as in traditional networks,
malicious nodes within a DTN may attempt to delay or destroy data in transit to
its destination. Such attacks include dropping data, flooding the network with
extra messages, corrupting routing tables, and counterfeiting network
acknowledgments. Many existing methods for securing routing protocols require
authentication supported by mechanisms such as a public key infrastructure,
which is difficult to deploy and operate in a DTN, where connectivity is
sporadic. Furthermore, the complexity of such mechanisms may dissuade node
participation so strongly that potential attacker impacts are dwarfed by the
loss of contributing participants. In this paper, we use connectivity traces
from our UMass Diesel- Net project and the Haggle project to quantify routing
attack effectiveness on a DTN that lacks security. We introduce plausible
attackers and attack modalities and provide complexity results for the
strongest of attackers. We show that the same routing with packet replication
used to provide robustness in the face of unpredictable mobility allows the
network to gracefully survive attacks. In the case of the most effective
attack, acknowledgment counterfeiting, we show a straightforward defense that
uses cryptographic hashes but not a central authority. We conclude that
disruption-tolerant networks are extremely robust to attack; in our
trace-driven evaluations, an attacker that has compromised 30% of all nodes
reduces delivery rates from 70% to 55%, and to 20% with knowledge of future
events. By comparison, contemporaneously connected networks are significantly
more fragileumass/diesel20070001burgess-maxpropJohn BurgessBrian GallagherDavid JensenBrian Neil LevineMaxProp: Routing for Vehicle-Based Disruption-Tolerant NetworkingProceedings of IEEE Infocom 2006--04--2006Barcelona, Spainhttp://prisms.cs.umass.edu/brian/pubs/burgess.infocom2006.pdfcrawdadmeasurementwirelessumass_dieselcrawdadumass/diesel20060401zhang-bus-dtnXiaolan ZhangJim KuroseBrian Neil LevineDon TowsleyHonggang ZhangStudy of a Bus-Based Disruption Tolerant Network: Mobility Modeling and Impact on RoutingProc. ACM Annual Intl. Conf. on Mobile Computing and Networking (Mobicom)--09--2007Montreal, Canadahttp://portal.acm.org/citation.cfm?id=1287853.1287876crawdadmeasurementwirelessumass_dieselcrawdadumass/diesel20070901