CRAWDAD tecnalia/humanet

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 | |

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