upmc/content2006111721200611172006-12-16upmc/contentTraces of Bluetooth sightings by groups of users carrying iMotes.

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.

the initial version2006-11-172005-10-282005-12-21929314941617UPMC Data License Dear User: Thank you for your interest in obtaining and using data from the team Networks and Performance Analysis of the Laboratoire d'Informatique de Paris6 (LIP6) of the University Pierre et Marie Curie (hereinafter "UPMC" hosted by the CRAWDAD's Dartmouth College archive (hereinafter referred to as "UPMC Data"). Data Licensing Information: UPMC hereby grants a nonexclusive, nontransferable license to use the UPMC Data for educational and research purposes only. The UPMC Data shall not be redistributed outside the scope of the terms and conditions of this Agreement without the express written prior approval of UPMC. User agrees to respect the privacy of those human subjects whose wireless-network activity is captured by the UPMC Data. Do not attempt to reverse the anonymization process to identify specific MAC addresses, IP address, telephone number, or other identifiers, or to identify their actual location. Use only the header information in packet traces; do not attempt to extract further information. (Header information specifies the type of information that is being transferred over the network, and specifically excludes the contents of the data, such as usernames, passwords, filenames, files, or URLs.) User agrees to acknowledge the source of the UPMC Data in any publications reporting on User's use of it. For example: "We gratefully acknowledge the use of wireless Université Pierre & Marie Curie (Paris6)/CNRS data from the team Networks and Performances Analysis of the Laboratoire d'Informatique de Paris 6 (LIP6) on the CRAWDAD archive." UPMC provides the UPMC Data "AS IS," without any warranty or promise of technical support, and disclaims any liability of any kind for any damages whatsoever resulting from use of UPMC Data. UPMC MAKES NO WARRANTIES, EXPRESS OR IMPLIED WITH RESPECT TO THE DATA, INCLUDING ANY IMPLIED WARRANTY OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE, WHICH ARE HEREBY EXPRESSLY DISCLAIMED. Your acceptance and use of the UPMC Data binds you to the terms and conditions of this License as stated herein. Direction des Relations Industrielles et du Transfert de Technologie Université Pierre et Marie Curie (Paris6) 19. Cité Voltaire 75001 Paris Francehttp://www.crawdad.org/upmc/content/http://www.crawdad.org/wiki/pmwiki.php?n=Main.Dataset.cambridge-haggleBluetoothsocial networkDTNContent Distribution EvaluationbluetoothDTN (Delay Tolerent Network)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.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.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.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.33200611172006-12-16upmc/content/imoteTraceset of Bluetooth sightings by groups of users carrying iMotes.

This traceset includes Bluetooth sightings by groups of users carrying small devices (iMotes) at locations around the city of Cambridge, UK.

the initial version2006-11-172005-10-282005-12-21Content 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 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.- 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/content75200611172006-12-16upmc/content/imote/cambridgeTraces of Bluetooth sightings by groups of users carrying small devices (iMotes).

This trace includes Bluetooth sightings by groups of users carrying small devices (iMotes) 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, 53Popular supermarket: 38Central point in the commercial center n?1: 52Central point in the commercial center n?2: 40 College porter's lodge: 51Computer 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/upmc/content/imote-traces-cambridge.tar.gzupmc/content/imote92upmc/rollernetupmc/contentJérémie Leguayjeremie.leguay@lip6.frthe computer science laboratory (LiP6)Université Pierre et Marie Curie93upmc/contentAnders Lindgrendugdale@sm.luth.seDepartment of Computer Science and Electrical EngineeringLulea University of Technology14cambridge/hagglecambridge/inmotionupmc/contentJames Scottjamesscott@acm.org94upmc/contentTimur Friedmantimur.friedman@upmc.frAssociate Professorthe computer science laboratory (LiP6)Universite Pirre et Marie Curie16cambridge/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

hui-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-communityPan HuiEiko YonekiShu-yan ChanJon CrowcroftProceedings of the ACM SIGCOMM MobiArch Workshop--08--2007

Kyoto, Japan

http://www.cl.cam.ac.uk/~ph315/publications/mobiarch.pdfCommunity is an important attribute of Pocket Switched Networks (PSN), because mobile devices are carried by people who tend to belong to communities. We analysed community structure from mobility traces and used for forwarding algorithms [12], which shows significant impact of community. Here, we propose and evaluate three novel distributed community detection approaches with great potential to detect both static and temporal communities. We find that with suitable configuration of the threshold values, the distributed community detection can approximate their corresponding centralised methods up to 90% accuracy.crawdadmeasurementwirelessmit_realityupmc_contentcrawdadupmc/content20070801leguay-opportunisticJérémie LeguayAnders LindgrenJames ScottTimur FriedmanJon CrowcroftProceedings of the ACM SIGCOMM Workshop on Challenged Networks (CHANTS 2006)

Pisa, Italy

--09--2006http://www-rp.lip6.fr/site_npa/site_rp/_publications/697-chants06.pdfThis paper investigates the feasibility of a city-wide content distribution architecture composed of short range wireless access points. We look at how a target group of intermittently and partially connected mobile nodes can improve the diffusion of information within the group by leveraging fixed and mobile nodes that are exterior to the group. The fixed nodes are data sources, and the external mobile nodes are data relays, and we examine the trade off between the use of each in order to obtain high satisfaction within the target group, which consists of data sinks. We conducted an experiment in Cambridge, UK, to gather mobility traces that we used for the study of this content distribution architecture. In this scenario, the simple fact that members of the target group collaborate leads to a delivery ratio of 90\%. In addition, the use of external mobile nodes to relay the information slightly increases the delivery ratio while significantly decreasing the delay.measurementwirelessupmc_contentcrawdadupmc/content20060901