CRAWDAD tecnalia/humanet

Citation Author(s):
Jose M.
Cabero
Virginia
Molina
Inigo
Urteaga
Fidel
Liberal
Jose L.
Martin
Submitted by:
CRAWDAD Team
Last updated:
Tue, 06/12/2012 - 08:00
DOI:
10.15783/C74G60
Data Format:
License:
39 Views
Citations:
1
Categories:
Keywords:
0
0 ratings - Please login to submit your rating.

Abstract 

1 day of Bluetooth connectivity and mobility data.

Our study analyzes the limitations of Bluetooth-based trace acquisition initiatives carried out until now in terms of granularity and reliability. We then go on to propose an optimal configuration for the acquisition of proximity traces and movement information using a fine-tuned Bluetooth system based on custom HW. With this system and based on such a configuration, we have carried out an intensive human trace acquisition experiment resulting in a proximity and mobility database of more than 5 million traces with a minimum granularity of 5 s.

last modified : 2012-06-12

release date : 2012-06-12

date/time of measurement start : 2010-11-24

date/time of measurement end : 2010-11-24

collection environment : The Pilot Project was carried out at Tecnalia's headquarters with a human sample of 56 people for 6 weeks.

network configuration : We assigned a PDPD (Bluetooth customized Device) to every person in the Pilot Project with careful instructions about the procedure and the goals of the Pilot Project. 30 Beacons were distributed in strategic zones all over the building (departments, corridors, cafeteria, meeting rooms, etc).

data collection methodology : The system comprises the following components: - Personal Devices of Proximity Detection (PDPD). - Beacons, used as static references. - Central server used as repository for all the traces. - Gateways, usually PCs or similar, to transfer the information of the PDPD to the central server. - Synchronization system to have all the traces synchronized. The core of the system is the PDPD. It consists of a Bluegiga Bluetooth module and some other peripheral modules for the detection of proximities and other relevant information such as the state of the PDPD. The peripherals are controlled by the microcontroller of the Bluetooth module itself. The traces are stored in 2 non-volatile I2C FRAM memories of 1Mbit each, with almost infinite read-write cycles (this is important to solve the memory depletion problems of other papers). The PDPDs download the traces periodically to the gateways, which send them to the central server. Every PDPD is powered by two 1.2 V AAA NiMh rechargeable batteries. The PDPD has a power system that recharges the batteries through a USB connector. The PDPD is equipped with an accelerometer for detecting its state with the aim of distinguishing when the person is wearing the PDPD or has left it aside and of detecting the person's movement. The connectivity traces collect encounters between PDPDs and also with the beacons in the surrounding area. The PDPDs are nodes required to detect and be detected; hence, a PDPD needs to alternate the master and slave modes. They are configured to follow a repetitive cycle of mean duration around 5 s consisting of two consecutive periods: a master period of 1.28 s and a slave period of 3s + rand(1.5 s). On the other hand, the beacons are nodes whose positions are static and usually connected to power sockets. To avoid the laborious collection phase and considering their unlimited autonomy, they are configured in continuous slave mode with a very high duty cycle. The Pilot Project was carried out at Tecnalia's headquarters with a human sample of 56 people for 6 weeks. We assigned a PDPD to every person in the Pilot Project with careful instructions about the procedure and the goals of the Pilot Project. 30 Beacons were distributed in strategic zones all over the building (departments, corridors, cafeteria, meeting rooms, etc). During the Pilot Project, the process was repeated every day according to the following procedure: every morning each person was required to put on their PDPD, which had been plugged into their computer (gateway) at the end of the previous working day. At that moment, the PDPD starts the node discovery procedure, alternating between the master and the slave modes. Simultaneously, the power control and the motion state algorithms keep running in every PDPD. At the end of the working day and before leaving the office, each person connected their PDPD to their computer. Afterwards, at a specific time when the office was empty, the transfer of information from the PDPD to the gateway was triggered and, later on, was downloaded from the gateway to the central server, where the traces were stored initially and later transferred to a mysql database. Once the information had been downloaded successfully from the PDPD to the gateway, the PDPD got the new synchronization time stamp and entered its inactive state until the next morning, when it would be unplugged and woken up again by the person who wore it.

sanitization : Every node appears with the corresponding Bluetooth address. No person names are used in the database.

limitation : Up to now, Bluetooth-based trace acquisition initiatives have suffered from the following two limitations: - The granularity of the traces, i.e. the sampling frequency used to record the human activity. - The reliability of the traces in aspects such as Bluetooth discovery performance, people-device duality and synchronizing traces. In order to overcome these limitations we have designed and developed a Bluetooth-based trace acquisition system with the following objectives: - Optimal performance for the detection-consumption trade-off: Maximization of trace granularity by analyzing the performance of the Bluetooth discovery procedure in real scenarios and its power consumption implications. - Overcome the reliability problems of Bluetooth-based traces in three areas: * Control of the rate of undetected neighbor nodes (false negatives rate). In order to do so, we have implemented a power control algorithm that increases/decreases the transmission power based on the context (number of neighbors). * Synchronization of the traces coming from different devices to resolve possible time misalignments. * Differentiation between those traces that describe human behavior and those others that describe the detection of devices on an exclusive basis. In order to do so, we have developed an algorithm based on the accelerometer. - Detect the mobility of people not only to provide social proximity but also dynamics. In order to do so, we have developed an algorithm based on the accelerometer.

Traceset

tecnalia/humanet/bluetooth

1 day of Bluetooth connectivity and mobility data.

  • description: Our study analyzes the limitations of Bluetooth-based trace acquisition initiatives carried out until now in terms of granularity and reliability. We then go on to propose an optimal configuration for the acquisition of proximity traces and movement information using a fine-tuned Bluetooth system based on custom HW. With this system and based on such a configuration, we have carried out an intensive human trace acquisition experiment resulting in a proximity and mobility database of more than 5 million traces with a minimum granularity of 5 s. This is a sample of the database consisting of the activity of 56 people along one day in the office. Very soon we will upload the whole database.
  • measurement purpose: User Mobility Characterization, Social Network Analysis, Human Behavior Modeling, Opportunistic Connectivity
  • methodology: During the Pilot Project, the process was repeated every day according to the following procedure: Every morning each person was required to put on their PDPD, which had been plugged into their computer (gateway) at the end of the previous working day. At that moment, the PDPD starts the node discovery procedure, alternating between the master and the slave modes. Simultaneously, the power control and the motion state algorithms keep running in every PDPD. At the end of the working day and before leaving the office, each person connected their PDPD to their computer. Afterwards, at a specific time when the office was empty, the transfer of information from the PDPD to the gateway was triggered and, later on, was downloaded from the gateway to the central server, where the traces were stored initially and later transferred to a mysql database. Once the information had been downloaded successfully from the PDPD to the gateway, the PDPD got the new synchronization time stamp and entered its inactive state until the next morning, when it would be unplugged and woken up again by the person who wore it.
  • sanitization: Every node appears with the corresponding Bluetooth address. No person names are used in the database.

tecnalia/humanet/bluetooth Traces

  • sample: 1 day of Bluetooth connectivity and mobility data.
    • configuration: The system comprises the following components: - Personal Devices of Proximity Detection (PDPD). - Beacons, used as static references. - Central server used as repository for all the traces. - Gateways, usually PCs or similar, to transfer the information of the PDPD to the central server. - Synchronization system to have all the traces synchronized. The Pilot Project was carried out at Tecnalia's headquarters with a human sample of 56 people for 6 weeks. We assigned a PDPD to every person in the Pilot Project with careful instructions about the procedure and the goals of the Pilot Project. 30 Beacons were distributed in strategic zones all over the building (departments, corridors, cafeteria, meeting rooms, etc).
    • format:

      The data is saved in a SQL database.

      The humanet database contains the following three tables: "t_encounters",

      "t_nodeList" and "t_states".

      Table "t_encounters" contains all the events detected by nodes throughout the

      experiment. It contains 7 fields, which are explained in the sequel:

      - dev1 -> Bluetooth LAP address of the device that generated this entry

      - dev2 -> Code identifying which type of entry this is:

      a) "eeeee0" -> Transmission power reduction (-5dB)

      b) "eeeee1" -> Transmission power increase ( 5dB)

      c) "beac11" -> Device starts functioning in beacon mode

      (slave mode, when the device is left aside by its

      owner)

      d) "beac00" -> Device starts functioning in normal mode

      (alternating master (detecting) and slave (being

      detected) modes)

      e) "ffffff" -> Device rebooted

      f) In all other cases, dev2 equals to the Bluetooth LAP

      address of the device detected.

      - init -> Time of day when the event described by this entry started

      - date_init -> Date when the event described by this entry started

      - end -> Time of day when the event described by this entry finished

      - date_end -> Date when the event described by this entry finished

      - state -> Additional info regarding this entry (table "t_states"

      describes the meaning of used numerical codes):

      a) If dev2="eeeee0" -> New transmission power in dBm

      b) If dev2="eeeee1" -> New transmission power in dBm

      c) If dev2="beac11" -> New transmission power in dBm

      d) If dev2="beac00" -> New transmission power in dBm

      e) If dev2="ffffff" -> Error code 255 as reboot

      indicator

      f) In all other cases, "state" reflects device's

      position:

      - "state"=0 -> Device is horizontally

      - "state"=1 -> Device is vertically and static

      - "state"=2 -> Device is vertically and moving

      Besides, and to identify more easily each device, table "t_nodeList" provides

      the list of the devices (and their Bluetooth address) that took part in the

      experiment:

      - id -> unique numerical identificator of a device (in range [1,56] for

      people and [57,86] for beacons)

      - nap -> Bluetooth NAP address of the device

      - uap -> Bluetooth UAP address of the device

      - lap -> Bluetooth LAP address of the device

      mysql> show tables;

      -------------------

      | Tables_in_humanet |

      -------------------

      | t_encounters |

      | t_nodeList |

      | t_states |

      -------------------

      mysql> describe t_encounters;

      ----------- ------------ ------ ----- --------- -------

      | Field | Type | Null | Key | Default | Extra |

      ----------- ------------ ------ ----- --------- -------

      | dev1 | varchar(6) | YES | | NULL | |

      | dev2 | varchar(6) | YES | | NULL | |

      | init | time | YES | | NULL | |

      | date_init | date | YES | | NULL | |

      | end | time | YES | | NULL | |

      | date_end | date | YES | | NULL | |

      | state | int(3) | YES | | NULL | |

      ----------- ------------ ------ ----- --------- -------

      mysql> describe t_nodeList;

      ------- ------------ ------ ----- --------- -------

      | Field | Type | Null | Key | Default | Extra |

      ------- ------------ ------ ----- --------- -------

      | id | int(3) | YES | | NULL | |

      | nap | int(4) | YES | | NULL | |

      | uap | int(2) | YES | | NULL | |

      | lap | varchar(6) | NO | PRI | NULL | |

      ------- ------------ ------ ----- --------- -------

      mysql> describe t_states;

      ------- ------------- ------ ----- --------- -------

      | Field | Type | Null | Key | Default | Extra |

      ------- ------------- ------ ----- --------- -------

      | id | int(3) | NO | PRI | 0 | |

      | state | varchar(20) | YES | | NULL | |

      ------- ------------- ------ ----- --------- -------

Instructions: 

The files in this directory are a CRAWDAD dataset hosted by IEEE DataPort. 

About CRAWDAD: the Community Resource for Archiving Wireless Data At Dartmouth is a data resource for the research community interested in wireless networks and mobile computing. 

CRAWDAD was founded at Dartmouth College in 2004, led by Tristan Henderson, David Kotz, and Chris McDonald. CRAWDAD datasets are hosted by IEEE DataPort as of November 2022. 

Note: Please use the Data in an ethical and responsible way with the aim of doing no harm to any person or entity for the benefit of society at large. Please respect the privacy of any human subjects whose wireless-network activity is captured by the Data and comply with all applicable laws, including without limitation such applicable laws pertaining to the protection of personal information, security of data, and data breaches. Please do not apply, adapt or develop algorithms for the extraction of the true identity of users and other information of a personal nature, which might constitute personally identifiable information or protected health information under any such applicable laws. Do not publish or otherwise disclose to any other person or entity any information that constitutes personally identifiable information or protected health information under any such applicable laws derived from the Data through manual or automated techniques. 

Please acknowledge the source of the Data in any publications or presentations reporting use of this Data. 

Citation:

Jose M. Cabero, Virginia Molina, Inigo Urteaga, Fidel Liberal, Jose L. Martin, tecnalia/humanet, https://doi.org/10.15783/C74G60 , Date: 2012061

Dataset Files

LOGIN TO ACCESS DATASET FILES
Open Access dataset files are accessible to all logged in  users. Don't have a login?  Create a free IEEE account.  IEEE Membership is not required.

Documentation

AttachmentSize
File tecnalia-humanet-readme.txt1.62 KB

These datasets are part of Community Resource for Archiving Wireless Data (CRAWDAD). CRAWDAD began in 2004 at Dartmouth College as a place to share wireless network data with the research community. Its purpose was to enable access to data from real networks and real mobile users at a time when collecting such data was challenging and expensive. The archive has continued to grow since its inception, and starting in summer 2022 is being housed on IEEE DataPort.

Questions about CRAWDAD? See our CRAWDAD FAQ. Interested in submitting your dataset to the CRAWDAD collection? Get started, by submitting an Open Access Dataset.