cambridge/haggle20090529620090529200609152009-08-07cambridge/haggleTraces of Bluetooth sightings by groups of users carrying small devices (iMotes) for a number of days.

This data includes a number of traces of Bluetooth sightings by groups of users carrying small devices (iMotes) for a number of days - in office environments, conference environments, and city environments.

The trace cambridge/haggle/imote/infocom2006 was added.2009-05-292005-01-062006-04-27141516171819http://www.cambridge.intel-research.net/haggle/http://www.crawdad.org/wiki/pmwiki.php?n=Main.Dataset.cambridge-haggleBluetoothsocial networkDTNUser Mobility CharacterizationContent Distribution EvaluationbluetoothDTN (Delay Tolerent Network)Four iMote-based experiments were conducted. The first included eight researchers and interns working at Intel Research in Cambridge. The second obtained data from twelve doctoral students and faculty comprising a research group at the University of Cambridge Computer Lab. The third experiment was conducted during the IEEE INFOCOM 2005 conference in Miami where 41 iMotes where carried by attendees for 3 to 4 days. In the fourth experiment, we were interested in tracking contacts between different mobile users, and also contacts between mobile users and various fixed locations. Mobile users in our experiment mainly consisted of students from Cambridge University who were asked to carry these iMotes with them at all times for the duration of the experiment. In addition to this, we deployed a number of stationary nodes in various locations that we expected many people to visit such as grocery stores, pubs, market places, and shopping centers in and around the city of Cambridge, UK. A stationary iMote was also placed at the reception of the Computer Lab, in which most of the experiment participants are students. The sixth experiment (Experiment 6) was conducted for 4 days during Infocom 2006 in Barcelona. Mobilie users in the experiment consist of 70 students and researchers, who were attending the student workshop. The 78 mobile iMotes were used, which have a wireless range around 30 meters. In addition, the 20 stationary (long range) iMotes were deployed, which have more powerful battery and extended radio range (around 100 meters).We set up experiments making use of the iMote platform made by Intel Research. iMotes are derived from the Berkeley Mote3, with the current version based around the Zeevo TC2001P system-on-a-chip providing an ARM7 processor and Bluetooth support. Along with a 950mAh CR2 battery, each iMote was enclosed in packaging designed to be convenient for test subjects to continually carry. Two types of packaging were made available : some iMotes were made into keyfobs while others were enclosed in small boxes. Subjects were asked to pick the form factor which allowed them to conveniently keep the iMote with them at all times, with most simply attaching the iMote to their keys.iMotes contacts were classified into two groups: iMotes recording the sightings of another iMotes are classified as "internal" contacts, while sightings of other types of Bluetooth devices are called "external" contacts. The external contacts are numerous and include anyone who has an active Bluetooth device in the vicinity of the iMote carriers, thereby providing a measure of actual wireless networking opportunities present at the time. The internal contacts, on the other hand, represent the data transfer opportunities that each of our participants would have, if they were equipped with devices which are always-on and always-carried.An anonymised version of our data will be made available to other research groups on demand.1020090529200609152009-08-07cambridge/haggle/imoteFour traces of Bluetooth sightings by groups of users carrying small devices (iMotes) for a number of days.

This traceset includes four traces of Bluetooth sightings by groups of users carrying small devices (iMotes) for a number of days - in Intel Research Cambridge Corporate Laboratory, Computer Lab at University of Cambridge, Conference IEEE Infocom in Grand Hyatt Miami, and locations around the city of Cambridge, UK.

The trace cambridge/haggle/imote/infocom2006 was added.2009-05-292005-01-062006-04-27User Mobility CharacterizationContent Distribution EvaluationWe tried to keep the processing of data before public release to a minimum, to allow any flexibility for possible research use. Some choices had to be made to reduce power consumption, memory use, and because of specific capabilities of the iMote prototype. Before using these data for your research, it may be important to check that it does not impact any of your findings. 1- periodic desynchronized scanning. In all our experiments, iMotes were distributed to a group of people to collect any opportunistic sighting of other Bluetooth devices (including the other iMotes distributed). Each iMotes scans on a periodic basis for device, asking them to respond with their MAC address, via the paging function. It takes approximately 5 to 10s to perform the complete scanning. After initial test we observe that most of the contacts were recorded with 5s scaning time, and this value was ultimately chosen. The time granularity between two scanning is 120s. It is important to avoid synchronization of two iMotes around the same cycle clock, as each of them cannot respond to any request when it is actively scanning. We implemented a random dephasing on [-12s;+12s] to handle this case. 2- skip-length sequence. A contact "A sees B" is defined as a period of time where all successive scanning by A receive a positive answer by B. Ideally an information should be kept at the end of each contact period. After preliminary test it became quite clear that a very large number of contact periods were only separated by two intervals. We decided, to avoid memory overflow, to implement a skip sequence of "one", meaning that a contact period will only be stopped after two successive failure of a scanning response. As a consequence, no inter-contact time of less than two intervales could have been observed. 3- Manual Time synchronization. Time between iMotes is not synchronized by a central entity, and traces belonging to different devices bears time which are relative to the starting time of each device. To read all data with the same time axis, devices were started as much as possible at the same time, and a method based on mutual sightings were used to compute manually the shift between different traces. This will certainly prove to be quite accurate for interval of time above 5mn, we cannot claim a complete accuracy for smaller time-scale. And we recommend to compute mutual sightings to check any inaccuracies that we may incur in this data. The time is expressed in seconds, the origin ( 0s ) corresponds to 12am on the first day of the experiment. Hence time of the day can be computed from it. Again, the operation was to add a constant to all previously synchronized traces, to reflect the time of beginnning of the experiment. We cannot claim high accuracy (under 5mn).- Anonymization and Address Identifier. To protect participants privacy, we choose not to release the MAC address, neither from the iMotes nor from other external devices recorded. Every device is given a unique identifier, usually called ID number in this document. Depending on which number, it might be an iMote or another MAC address that were recorded from other active bluetooth devices around.- Corrupted MAC address, and discarded mote. After the first couple of experiments, we observe that a number of MAC addresses recorded were different from a known one only by one or two digit. They were most of the time recorded once for a single time slot. It is clear that at least a part of them comes for a corrupted signal received on the link level by our devices. to ignore this artificial data, we implement the following rule: "Any MAC address that were recorded only once, for a single scanning (that is, related with a unique contact, with length 1s), are supposed defective and ignored." We did not discard any other one: a node that was seen twice, each contact being of length 1s, or a node that was seen once for two successive scanning, was included in the final datasets. Another important aspect is that some iMotes could not come up with data that can be used, mostly due to unfortunate hardware reset, or losses. These devices may still appear in the traces of other iMotes, and are difficult to interpret as they seems to follow an intermittent presence during the experiment. All of them were discarded from the final datasets, to avoid impacting the results in any way./download/cambridge/haggle/imote-traces123/READMEcambridge/haggle21200601312006-11-14cambridge/haggle/imote/intelTraces of Bluetooth sightings by groups of users carrying small devices (iMotes) for six days in Intel Research Cambridge Lab.

This trace includes Bluetooth sightings by groups of users carrying small devices (iMotes) for six days in Intel Research Cambridge Corporate Laboratory.

the initial versionfalse2006-01-312005-01-062005-01-11===== "table.Exp1.dat" is a file describing the contact where a certain device is seen. ======================== Examples taken from table.Exp1.dat (two first columns and first rows) ======================== ID # Class Incidence Occurence : Total ID 1 ID 2 Contact Time : 1 1 8 143 0 32 69951 0 4835 2 1 8 168 19 0 68818 1260 0 ======================== ======================== - The first column describes the ID of the device. - The second column takes value 1 or 2, it describes whether it is 1- an internal device (one of iMotes we distributed). 2- an external device (identified by his MAC address). We usually give smaller ID to internal nodes. That is the reason why all tables start with devices of class 1. - The third column describes the incidence of this device, namely the number of iMote that recorded its MAC address during this experiment. It is usually between 1 and n for an external device (where n is the number of iMotes deployed), and between 1 and n-1 for an internal device. - The rest of the table describes the number of contacts (first line) where this device were seen, and the cumulated time of these contacts (second line). Columns correspond to which iMotes recorded this devices. From the example above, node with ID 1 was seen in total 143 time during Experiment 1, and it was seen 32 time by node with ID 2. The cumulated time where 2 saw 1 is 4835 s. Node 2 was seen 168 time in total, and 19 time by node 1, the total time it saw node 1 is 1260. Note that, as we usually observe, this number may not be symmetric, as interference and the limit of our implementation can create non-mutual sightings. They are, however, usually of the same order. ===== "MAC3Btable.Exp1.dat" is a file that contains the three first bytes of the MAC address, associated with each ID. It could be useful to identify what is the kind of each external device. ===== "contacts.Exp1.dat" is a file which describes the contact that were recorded by all devices we distributed during this experiment. ======================== Examples taken from table.Exp1.dat (two first columns and first rows) ======================== 1 8 121 121 1 0 1 3 236 347 1 0 1 4 236 347 1 0 1 5 121 464 1 0 1 8 585 585 2 464 ======================== ======================== - The first column gives the ID of the device who recorded the sightings. - The second column gives the ID of the device who was seen (it may be an iMote, or another device recorded during the experiment). - The third and fourth column describe, respectively, the first and last time when the address of ID2 were recorded by ID1 for this contact. - The fifth and sixth column are here for reading convenience. The fifth enumerate contacts with same ID1 and ID2, as 1,2,... . The last column describes the time difference between the beginning of this contact and the end of the previous contact with same ID1 and ID2. It is by convention set to 0 if this is the first contact for this ID1 and ID2. - Note, again, that these contacts may not be mutual between a pair of iMotes, because scanning period of different iMotes are not synchronized, and because the sightings might not be symmetric.================================ Location: Intel Research Cambridge Corporate Laboratory Date: January 2005, Duration: Devices distributed on Thursday, January 6, at 11:30am Devices collected on Tuesday, January 11, in the afternoon (most of the traces last only for three days). ================================ Participants: 16 admin staff, researchers, interns, and admin staff. 1 iMote was left in the kitchen, as a stationary node, during the experiment. ================================ Collected datas: - Data from only 9 iMotes could be collected properly. The others suffered from too much reset. Addresses ID: ID 1 is the stationary node. ID 2-9 are corresponding to mobile iMotes ID 10-128 corresponds to external devices/download/cambridge/haggle/imote-trace1.tar.gzcambridge/haggle/imote22200601312006-11-14cambridge/haggle/imote/cambridgeTrace of Bluetooth sightings by groups of users carrying small devices (iMotes) for six days in Camputer Lab at University of Cambridge.

This trace includes Bluetooth sightings by groups of users carrying small devices (iMotes) for six days in Computer Lab at University of Cambridge.

the initial versionfalse2006-01-312005-01-252005-01-31===== "table.Exp2.dat" is a file describing the contact where a certain device is seen. ======================== Examples taken from table.Exp2.dat (two first columns and first rows) ======================== ID # Class Incidence Occurence : Total ID 1 ID 2 Contact Time : 1 1 8 143 0 32 69951 0 4835 2 1 8 168 19 0 68818 1260 0 ======================== ======================== - The first column describes the ID of the device. - The second column takes value 1 or 2, it describes whether it is 1- an internal device (one of iMotes we distributed). 2- an external device (identified by his MAC address). We usually give smaller ID to internal nodes. That is the reason why all tables start with devices of class 1. - The third column describes the incidence of this device, namely the number of iMote that recorded its MAC address during this experiment. It is usually between 1 and n for an external device (where n is the number of iMotes deployed), and between 1 and n-1 for an internal device. - The rest of the table describes the number of contacts (first line) where this device were seen, and the cumulated time of these contacts (second line). Columns correspond to which iMotes recorded this devices. From the example above, node with ID 1 was seen in total 143 time during Experiment 1, and it was seen 32 time by node with ID 2. The cumulated time where 2 saw 1 is 4835 s. Node 2 was seen 168 time in total, and 19 time by node 1, the total time it saw node 1 is 1260. Note that, as we usually observe, this number may not be symmetric, as interference and the limit of our implementation can create non-mutual sightings. They are, however, usually of the same order. ===== "MAC3Btable.Exp2.dat" is a file that contains the three first bytes of the MAC address, associated with each ID. It could be useful to identify what is the kind of each external device. ===== "contacts.Exp2.dat" is a file which describes the contact that were recorded by all devices we distributed during this experiment. ======================== Examples taken from table.Exp2.dat (two first columns and first rows) ======================== 1 8 121 121 1 0 1 3 236 347 1 0 1 4 236 347 1 0 1 5 121 464 1 0 1 8 585 585 2 464 ======================== ======================== - The first column gives the ID of the device who recorded the sightings. - The second column gives the ID of the device who was seen (it may be an iMote, or another device recorded during the experiment). - The third and fourth column describe, respectively, the first and last time when the address of ID2 were recorded by ID1 for this contact. - The fifth and sixth column are here for reading convenience. The fifth enumerate contacts with same ID1 and ID2, as 1,2,... . The last column describes the time difference between the beginning of this contact and the end of the previous contact with same ID1 and ID2. It is by convention set to 0 if this is the first contact for this ID1 and ID2. - Note, again, that these contacts may not be mutual between a pair of iMotes, because scanning period of different iMotes are not synchronized, and because the sightings might not be symmetric.Location: Computer Lab, University of Cambridge Date: End of January 2005 Duration: Devices distributed on Tuesday, January 25th, 2005 at 14:00am Devices collected on Monday, January 31st, 2005 in the afternoon (most of the iMotes last around 5days) Participants: 19 graduate students from the System Research Group. Collected datas: - Some of the iMotes did not deliver any useful data, as a consequence of accidental hardware reset. Contacts with one of them were discarded from the traces of other iMotes to avoid any consequence on the experimental results. - In total only 12 iMotes could be used to produce this trace, others were suffering from hardward resets. The contacts with these nodes were discarded from the complete - Details of ID number: ID 1-12 are corresponding to iMotes (Class 1) ID 13-223 corresponds to external devices (Class 2)/download/cambridge/haggle/imote-trace2.tar.gzcambridge/haggle/imote23200601312006-11-14cambridge/haggle/imote/infocomTrace of Bluetooth sightings by groups of users carrying small devices (iMotes) for four days.

This trace includes Bluetooth sightings by groups of users carrying small devices (iMotes) for four days in Conference IEEE Infocom in Grand Hyatt Miami.

the initial versionfalse2006-01-312005-03-072005-03-10===== "table.Exp3.dat" is a file describing the contact where a certain device is seen. ======================== Examples taken from table.Exp3.dat (two first columns and first rows) ======================== ID # Class Incidence Occurence : Total ID 1 ID 2 Contact Time : 1 1 8 143 0 32 69951 0 4835 2 1 8 168 19 0 68818 1260 0 ======================== ======================== - The first column describes the ID of the device. - The second column takes value 1 or 2, it describes whether it is 1- an internal device (one of iMotes we distributed). 2- an external device (identified by his MAC address). We usually give smaller ID to internal nodes. That is the reason why all tables start with devices of class 1. - The third column describes the incidence of this device, namely the number of iMote that recorded its MAC address during this experiment. It is usually between 1 and n for an external device (where n is the number of iMotes deployed), and between 1 and n-1 for an internal device. - The rest of the table describes the number of contacts (first line) where this device were seen, and the cumulated time of these contacts (second line). Columns correspond to which iMotes recorded this devices. From the example above, node with ID 1 was seen in total 143 time during Experiment 1, and it was seen 32 time by node with ID 2. The cumulated time where 2 saw 1 is 4835 s. Node 2 was seen 168 time in total, and 19 time by node 1, the total time it saw node 1 is 1260. Note that, as we usually observe, this number may not be symmetric, as interference and the limit of our implementation can create non-mutual sightings. They are, however, usually of the same order. ===== "MAC3Btable.Exp3.dat" is a file that contains the three first bytes of the MAC address, associated with each ID. It could be useful to identify what is the kind of each external device. ===== "contacts.Exp3.dat" is a file which describes the contact that were recorded by all devices we distributed during this experiment. ======================== Examples taken from table.Exp3.dat (two first columns and first rows) ======================== 1 8 121 121 1 0 1 3 236 347 1 0 1 4 236 347 1 0 1 5 121 464 1 0 1 8 585 585 2 464 ======================== ======================== - The first column gives the ID of the device who recorded the sightings. - The second column gives the ID of the device who was seen (it may be an iMote, or another device recorded during the experiment). - The third and fourth column describe, respectively, the first and last time when the address of ID2 were recorded by ID1 for this contact. - The fifth and sixth column are here for reading convenience. The fifth enumerate contacts with same ID1 and ID2, as 1,2,... . The last column describes the time difference between the beginning of this contact and the end of the previous contact with same ID1 and ID2. It is by convention set to 0 if this is the first contact for this ID1 and ID2. - Note, again, that these contacts may not be mutual between a pair of iMotes, because scanning period of different iMotes are not synchronized, and because the sightings might not be symmetric.Location: Conference IEEE Infocom in Grand Hyatt Miami Date: March 2005 Duration: Devices distributed on March 7th, 2005 between lunch time and 5pm. Devices collected on March 10th, 2005 in the afternoon. Participants: 50 students, attending the student workshop. Collected datas: - 2 iMotes were lost, and 7 did not deliver useful data, as a consequence of accidental hardware reset. Contacts with any of these were discarded from the traces of other iMotes to avoid any consequence on the experimental results. - The first six hours were discarded, as people were attending the same workshop during the first afternoon. - Details of ID number: ID 1-41 are corresponding to iMotes (Class 1) ID 42-274 corresponds to external devices (Class 2)Of the fifty-four iMotes distributed, forty-one yielded useful data, eleven did not contain useful data because of various failures with the battery and packaging, and two were not returned.Preliminary tests revealed the following problem: Bluetooth devices on a specific brand of mobile phone did not show up consistently during inquiries (and increasing the inquiry period to ten seconds did not help). Therefore, a small number of nodes were causing the memory to fill too quickly. To avoid this problem, we keep a device in the "in-contact list" even if it is not seen for one inquiry interval. If it comes back in-contact on the next interval, nothing is stored. If it does not, a record is stored as normal. This solves the problem, at the expense of not being able to detect actual cases where a node moved out of range during one two-minute period, and back into range for the next two-minute period./download/cambridge/haggle/imote-trace3.tar.gzcambridge/haggle/imote66200609152006-11-14cambridge/haggle/imote/contentTraces of Bluetooth sightings by groups of users carrying small devices (iMotes) for two months in the locations around the the city of Cambridge, UK.

This trace includes Bluetooth sightings by groups of users carrying small devices (iMotes) for two months in various locations that we expected many people to visit such as grocery stores, pubs, market places, and shopping centers in and around the city of Cambridge, UK.

the initial versionfalse2006-01-312005-10-282005-12-21In the experiment we performed, we were interested in tracking contacts between different mobile users, and also contacts between mobile users and various fixed locations. Mobile users in our experiment mainly consisted of students from Cambridge University who were asked to carry these iMotes with them at all times for the duration of the experiment. In addition to this, we deployed a number of stationary nodes in various locations that we expected many people to visit such as grocery stores, pubs, market places, and shopping centers in and around the city of Cambridge, UK. A stationary iMote was also placed at the reception of the Computer Lab, in which most of the experiment participants are students. Here are the different types of iMotes that we deployed: MSR-10 : Mobile Short Range iMotes with an interval of 10 minutes between inquiries. These iMotes were given to a group of 40 students, mostly in the 3rd year at the Cambridge University Computer Lab. The devices were packaged in small boxes (dental floss boxes) to be easy to carry around in a pocket, and used a CR-2 battery (950 mAh) for power. FSR-10 : Fixed Short Range iMotes with an interval of 10 minutes between inquiries. We deployed 15 of these iMotes in fixed locations such as pubs, shops or colleges' porter lodges. We used exactly the same packaging and batteries as the MSR-10. FSR-6 : Fixed Short Range iMotes with an inquiry interval of 6 minutes. These iMotes were equipped with a more powerful rechargeable battery providing 2200 mAh so that we were able to reduce the inquiry interval to 6 minutes. We deployed 2 of these. FLR-2 : Fixed Long Range iMotes with an interval of 2 minutes between inquiries. To increase the area in which these iMotes can discover other devices, four devices were equipped with an external antenna, which provided a communication range that was approximately twice that of the short range iMotes. Furthermore, these iMotes were also equipped with 3 more powerful rechargeable batteries providing 2200 mAh so that we could reduced the inquiry interval to 2 minutes. The experiment started on Friday, October 28th 2005, 9:55:32 (GMT) and stopped on Wednesday, December 21th 2005, 13:00 (GMT).======================== Description of the files in each experiment ======================== ===== "MAC3Btable" is a file that contains the three first bytes of the MAC address, associated with each ID. It could be useful to identify the manufacturer of each external device. Note that MAC devices from ID=11168 to ID=11421 should be removed because they may correspond to fake devices. This is the results from MAC corruption. According to the OUI (Organizationally Unique Identifier) database we could not have MAC addresses that begin with the first bytes higher than 0x08. ===== "*.dat" are files describing the contact recorded by all devices we distributed during this experiment. The dat file N.dat represents the data for the iMote with identifier (ID) N. These data files for the 3 different categories of iMotes are in the following directories: - SR-10mins-FixLocation - SR-10mins-Students - SR-6mins-FixLocation - LR-2mins ======================== Examples taken from LR-2mins/37.dat ======================== 9546 1130504701 1130504701 10536 1130505044 1130505044 4649 1130506372 1130506372 7490 1130506608 1130506615 5905 1130506851 1130506851 8996 1130506851 1130506858 1431 1130506970 1130506970 5639 1130507327 1130507327 6883 1130508255 1130508255 6540 1130508606 1130508613 ======================== ======================== - The first column gives the ID of the device who was seen by the iMote 37. - The second and third columns describe, respectively, the first and last time when the address were recorded for the contact. - Note, again, that these contacts may not be mutual between a pair of iMotes, because scanning period of different iMotes are not synchronized, and because the sightings might not be symmetric. - Also, times are unix timestamps which correspond to the number of seconds since midnight January 1, 1970 UTC (referred to as the Epoch). Globally, the ID have been attributed in the following fashion: - SR-10mins-Students ( ID in [1:36] ) - LR-2mins ( ID in [37:40] ) - SR-10mins-FixLocation ( ID in [41:52] ) - SR-6mins-FixLocation ( ID in [53:54] ) - External contacts ( ID in [55:inf] ) To ease the understanding of data while keeping a sufficent privacy level, we provide here an idea of the kind of locations where fixed iMotes were deployed: Pubs: 41, 45, 46, 47, 50 Shop windows: 37, 39, 42, 43, 44, 48, 49, 53 Popular supermarket: 38 Central point in the commercial center n?1: 52 Central point in the commercial center n?2: 40 College porter's lodge: 51 Computer lab reception: 54Due to various hardware problems and the loss of some of the deployed iMotes, we were able to gather measurement data from 36 mobile participants and 18 fixed locations./download/cambridge/haggle/imote-traces-cambridge.tar.gzcambridge/haggle/imote301200905292009-08-07cambridge/haggle/imote/infocom2006Traces of Bluetooth sightings by groups of users carrying small devices (iMotes) for four days during Infocom 2006 in Barcelona, Spain.

This trace includes Bluetooth sightings by groups of users carrying small devices (iMotes) for four days in Barcelona, Spain.

the initial versionfalse2009-05-292006-04-242006-04-27This file contains information on Experiment 6, which was conducted during Infocom 2006 in Barcelona Location: Princesa Sofia Gran Hotel, Barcelona Date: Monday, April 24th to Thursday April 27th, 2006 Duration: Devices distributed on Sundary April 23rd, between 7:00 and 9:00 pm. Devices collected back starting from April 26th and on April 27th during the day. Origin of time: All times indicated in the files corresponds to the seconds elapsed since the motes were turned on. The motes had been all turned on on Sunday April 23rd at 5:01pm (which is 61260 seconds after midnight on that day). Participants: 70 students and researchers, attending the student workshop. Collected datas: - 2 iMotes did not deliver useful data, as a consequence of accidental hardware reset. Contacts with any of these were discarded from the traces of other iMotes to avoid any consequence on the experimental results. Participating nodes: - Nodes with ID#1 through #17 are static long range iMotes iMotes deployed throughout the area. - The three nodes with ID#18-#20 are long range iMotes that have been placed in lift of the hotel. - Nodes #21-#98 are participants of the Infocom student workshop. - Nodes with ID larger or equal than #100 are external devices. Note that the 20 stationary (long range) iMotes have more powerful battery and extended radio range (around 100 meters). The 78 mobile iMotes have a wireless range around 30 meters.Details of the files contained in this dataset: ===== "infocom06floormap.pdf" Precise the approximate location and range of the static iMotes deployed. Please note that among the static nodes Mezzanine: ID #6, #8 (wrongly indicated on the map as 87239), #9, #10, #12, #17 Floor -1: ID #3, #14, #16, Floor -2: ID #1, #4, #5, #7, #11, #15 Others: ID#2 (Bar) #13 (Concierge) Lifts: ID #17, #18, #19 ===== "MAC2id.dat" is a file that contains the MAC address, associated with each ID for the static motes only (others have been removed to preserve participants privacy). It allows in particular to relate the node ID and the location as mentioned on the floormap. ===== "table.Exp6.dat" is a file which describes the amount of contacts between the different pairs of devices (Please see the General README for the detailed description of this file). ===== "contacts.Exp6.dat" is a file which describes the contact that were recorded by all devices we distributed during this experiment. ======================== Examples ======================== 1 8 121 121 1 0 1 3 236 347 1 0 1 4 236 347 1 0 1 5 121 464 1 0 1 8 585 585 2 464 ======================== ======================== - The first column gives the ID of the device who recorded the sightings. - The second column gives the ID of the device who was seen (it may be an iMote, or another device recorded during the experiment). - The third and fourth column describe, respectively, the first and last time when the address of ID2 were recorded by ID1 for this contact. Note that the time were computed in seconds, with the zero starting on Sunday at 5:01pm (Please see Origin of time above). - The fifth and sixth column are here for reading convenience. The fifth enumerate contacts with same ID1 and ID2, as 1,2,... . The last column describes the time difference between the beginning of this contact and the end of the previous contact with same ID1 and ID2. It is by convention set to 0 if this is the first contact for this ID1 and ID2. - Note, again, that these contacts may not be mutual between a pair of iMotes, because scanning period of different iMotes are not synchronized, and because the sightings might not be symmetric. ===== Profile of participants. During the experiments, we ask each participants to fill a questionnaire with a number of information about this person. We give the full results (unfortunately not complete as many participants did not answer the questionnaire fully). NB: To preserver participants privacy the answer has been reassigned to numbers, so that the file allows to know, e.g., which participants are from the the same affiliation without disclosing the name of this affiliation. The folder forms contains: - The Questionnaire.doc document used for fill the form by participants. - the answers of each participants in the file corresponding to its ID: "<ID>.txt" Please refer to the Questionnaire for the exact formulation of the question. Here is a summary of what the file contains: Row 1, 2 - corresponds to name and email addresses. For confidentiality reasons here they only present the ID of the node. Row 3 - indicates nationalities of the experimentalist. Row 4 - the school where the participants completed her or his study Row 5 - the languages spoken by the participants Row 6 - the current affiliation(s) Row 7 - Position: Student/Researcher/Professor Row 8, 9 - indicates the city and the country of residence Row 10 - please ignore this field (project membership that was not included) Row 11 - airport the participant is flying from. Row 12 - please ignore this field (cellphone/PDA carried, not filled by participants) Row 13 - please ignore this field (number of Infocom conference attended before) Row 14 - indicates the hotel where the participant is staying during the conference. Row 15 - please ignore this field (roommate during the conference, not indicated) Row 16 - please ignore this field (subway station while in Barcelona, not indicated by participants) Row 17 - please ignore this field (presenter or not, not indicated by participants) Row 18 - indicates membership of ACM, IEEE, ComSoc Row 19 - indicates the list of topics of interest (selected from those of the CFP) which are relevant to the research of the participant2 iMotes did not deliver useful data, as a consequence of accidental hardware reset. Contacts with any of these were discarded from the traces of other iMotes to avoid any consequence on the experimental results./download/cambridge/haggle/Exp6.tar.gzcambridge/haggle/imote14cambridge/hagglecambridge/inmotionupmc/contentJames Scottjamesscott@acm.org15cambridge/hagglecambridge/inmotionRichard Gassrichard.gass@intel.comIntel Research Cambridge

Intel Research Cambridge, 15 JJ Thomson Avenue, Cambridge CB3 0FD, UK

+44-1223-767404+44-1223-763456http://www.cambridge.intel-research.net/~rgass/16cambridge/haggleupmc/contentJon Crowcroftjon.crowcroft@cl.cam.ac.ukUniversity of CambridgeComputer LaboratoryProfessor

University of Cambridge Computer Laboratory William Gates Building 15 JJ Thomson Avenue Cambridge CB3 0FD, UK

+44-1223-763633+44-1223-334678http://www.cl.cam.ac.uk/users/jac22/17cambridge/haggleupmc/contentPan Huipan.hui@cl.cam.ac.ukUniversity of CambridgeComputer LaboratoryPh.D student

University of Cambridge Computer Laboratory William Gates Building 15 JJ Thomson Avenue Cambridge CB3 0FD, UK

18cambridge/hagglecambridge/inmotionChristophe Diotchristophe.diot@gmail.comParis Research Lab, Thomson

Paris Research Lab, Thomson 46, quai A. Le Gallo 92648 Boulogne cedex, FRANCE

19cambridge/haggleAugustin Chaintreauaugustin.chaintreau@thomson.netaugustin.chaintreau@gmail.comParis Research Lab, Thomsonchaintreau-diameterA. ChaintreauA. MtibaaL. MassouliéC. DiotProceedings of ACM Sigcomm CoNext2007--12--also available as Thomson technical report CR-PRL-2007-07-0001also available as technical report CR-PRL-2007-07-0001http://www.thlab.net/~chaintre/pub/chaintreau07diameter.pdfwireless-meas,crawdadcambridge/haggle20071201chaintreau-opportunisticAugustin ChaintreauPan HuiJon CrowcroftChristophe DiotRichard GassJames ScottProceedings of the 25th IEEE International Conference on Computer Communications (INFOCOM)--04--2006

Barcelona, Spain

http://www.cambridge.intel-research.net/haggle/pubs/Studying transfer opportunities between wireless devices carried by humans, we observe that the distribution of the inter-contact time, that is the time gap separating two contacts of the same pair of devices, exhibits a heavy tail such as one of a power law, over a large range of value. This observation is confirmed on six distinct experimental data sets. It is at odds with the exponential decay implied by most mobility models. In this paper, we study how this new characteristic of human mobility impacts a class of previously proposed forwarding algorithms. We use a simplified model based on the renewal theory to study how the parameters of the distribution impact the delay performance of these algorithms. We make recommendation for the design of well founded opportunistic forwarding algorithms, in the context of human carried devices.crawdadmeasurementwirelessdartmouth_campuscambridge_hagglecrawdadcambridge/haggle20060401chaintreau-pocketAugustin ChaintreauPan HuiJon CrowcroftChristophe DiotRichard GassJames Scottmeasurementwirelessdartmouth_campuscambridge_hagglecrawdadUCAM-CL-TR-617--02--2005University of Cambridge Computer Laboratoryhttp://www.cl.cam.ac.uk/TechReports/UCAM-CL-TR-617.pdfOpportunistic networks make use of human mobility and local forwarding in order to distribute data. Information can be stored and passed, taking advantage of the device mobility, or forwarded over a wireless link when an appropriate contact is met. Such networks fall into the fields of mobile ad-hoc networking and delay-tolerant networking. In order to evaluate forwarding algorithms for these networks, accurate data is needed on the intermittency of connections. \par In this paper, the inter-contact time between two transmission opportunities is observed empirically using four distinct sets of data, two having been specifically collected for this work, and two provided by other research groups. \par We discover that the distribution of inter-contact time follows an approximate power law over a large time range in all data sets. This observation is at odds with the exponential decay expected by many currently used mobility models. We demonstrate that opportunistic transmission schemes designed around these current models have poor performance under approximate power-law conditions, but could be significantly improved by using limited redundant transmissions.wireless-meas,crawdadcambridge/haggle20050201hui-bubblePan HuiJon CrowcroftUCAM-CL-TR-684--05--2007University of Cambridge Computer Laboratoryhttp://www.cl.cam.ac.uk/TechReports/UCAM-CL-TR-684.pdfIn this paper we seek to improve understanding of the structure of human mobility, and to use this in the design of forwarding algorithms for Delay Tolerant Networks for the dissemination of data amongst mobile users. Cooperation binds but also divides human society into communities. Members of the same community interact with each other preferentially. There is structure in human society. Within society and its communities, individuals have varying popularity. Some people are more popular and interact with more people than others; we may call them hubs. Popularity ranking is one facet of the population. In many physical networks, some nodes are more highly connected to each other than to the rest of the network. The set of such nodes are usually called clusters, communities, cohesive groups or modules. There is structure to social networking. Different metrics can be used such as information flow, Freeman betweenness, closeness and inference power, but for all of them, each node in the network can be assigned a global centrality value. What can be inferred about individual popularity, and the structure of human society from measurements within a network? How can the local and global characteristics of the network be used practically for information dissemination? We present and evaluate a sequence of designs for forwarding algorithms for Pocket Switched Networks, culminating in Bubble, which exploit increasing levels of information about mobility and interaction.crawdadmeasurementwirelesscambridge_hagglemit_realityupmc_contentcrawdadcambridge/haggleupmc/content20070501hui-conferencePan HuiAugustin ChaintreauJames ScottRichard GassJon CrowcroftChristophe DiotProceedings of the 2005 ACM SIGCOMM workshop on Delay-tolerant networking--08--2005244-251

Philadelphia, PA, USA

http://www.acm.org/sigs/sigcomm/sigcomm2005/paper-HuiCha.pdfcrawdadmeasurementwirelesscambridge_hagglecrawdadcambridge/haggle20050801