CRAWDAD upmc/content

This data includes a number of traces of Bluetooth sightings by groups of users carrying small devices (iMotes) at locations around the city of Cambridge, UK.last modified : 2006-12-16release date : 2006-11-17date/time of measurement start : 2005-10-28date/time of measurement end : 2005-12-21collection environment : In this 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.network configuration : 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.data collection methodology : To evaluate the different content distribution schemes we propose, we conducted an experiment in the city of Cambridge, UK, in which 20 stationary devices equipped with a Bluetooth contact logger were deployed at popular places. In addition to this, we deployed 40 similar contact loggers on a group of students from Cambridge University. Because we used Bluetooth technology, we gathered interactions not only between the contact loggers, but also with a large number of other Bluetooth enabled devices such as mobile phones or PDAs. 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.sanitization : 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.Tracesetupmc/content/imoteTraceset of Bluetooth sightings by groups of users carrying iMotes.files: imote-traces-cambridge.tar.gzdescription: This traceset includes Bluetooth sightings by groups of users carrying small devices (iMotes) at locations around the city of Cambridge, UK.measurement purpose: Content Distribution Evaluationmethodology: We 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 our experiment, iMotes were distributed to a group of people to collect any opportunistic sighting of other Bluetooth devices (including the other iMotes distributed). Each iMote scans on a periodic basis for devices, 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 tests, we observe that most of the contacts were recorded with a 5s scanning time, and this value was used in the experiment. The time granularity between two scanning is Ns. Later in this document, the exact values we chose are given. 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. Therefore, 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 one interval. 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 intervals could have been observed. 3- Manual Time synchronization. Time between iMotes is not synchronized by a central entity, and traces belonging to different devices bear times which are relative to the starting time of each device. We recorded the time at which each iMote was first powered up, which corresponds to time 0 at that iMote. After collecting the data, we then converted all times into Unix timestamps (seconds elapsed since 00:00:00 UTC, Jan 1, 1970). 4- Corrupted MAC address, and discarded mote. As in the Haggle experiments, we observed 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), should be supposed defective and ignored." We did not discard any iMotes in these data set. We recommend to remove iMotes that were seen only one time for a contact of length 1s.sanitization: - 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.upmc/content/imote Tracescambridge: Traces of Bluetooth sightings by groups of users carrying small devices (iMotes).configuration: In 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).format:========================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 manufacturerof each external device.Note that MAC devices from ID=11168 to ID=11421 should be removed becausethey may correspond to fake devices. This is the results from MACcorruption. According to the OUI (Organizationally Unique Identifier)database we could not have MAC addresses that begin with the first byteshigher than 0x08.====="*.dat"are files describing the contact recorded by all devices we distributedduring 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 thefollowing directories:- SR-10mins-FixLocation- SR-10mins-Students- SR-6mins-FixLocation- LR-2mins========================Examples taken from LR-2mins/37.dat========================9546 1130504701 113050470110536 1130505044 11305050444649 1130506372 11305063727490 1130506608 11305066155905 1130506851 11305068518996 1130506851 11305068581431 1130506970 11305069705639 1130507327 11305073276883 1130508255 11305082556540 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 andlast time when the address were recorded for the contact.- Note, again, that these contacts may not be mutual between a pair ofiMotes, because scanning period of different iMotes are notsynchronized, and because the sightings might not be symmetric.- Also, times are unix timestamps which correspond to the number of secondssince 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, 53Popular supermarket: 38Central point in the commercial center n?1: 52Central point in the commercial center n?2: 40College porter's lodge: 51Computer lab reception: 54