[Dataset] tecnalia/humanet (v. 2012-06-12)

top

the initial version

@MISC{tecnalia-humanet-2012-06-12,
  author = {Jose M. Cabero and Virginia Molina and Inigo Urteaga and Fidel Liberal and Jose L. Martin},
  title = {{CRAWDAD} data set tecnalia/humanet (v. 2012-06-12)}, 
  howpublished = {Downloaded from http://crawdad.cs.dartmouth.edu/tecnalia/humanet},
  month = jun,  
  year = 2012
}
					

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.

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

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

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.

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

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.

This is a sample of the database. The sample consists of the activity of 56
people during 1 day, which is around 200.000 connectivity logs. The whole
dataset will be upload soon (with around 5 million connectivity logs monitoring
the activity of 56 people during 6 weeks).

[Traceset] tecnalia/humanet/bluetooth (v. 2012-06-12)

top

the initial version

@MISC{tecnalia-humanet-bluetooth-2012-06-12,
  author = {Jose M. Cabero and Virginia Molina and Inigo Urteaga and Fidel Liberal and Jose L. Martin},
  title = {{CRAWDAD} trace set tecnalia/humanet/bluetooth (v. 2012-06-12)}, 
  howpublished = {Downloaded from http://crawdad.cs.dartmouth.edu/tecnalia/humanet/bluetooth},
  month = jun,  
  year = 2012
}
					

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.

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.

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

[Trace] tecnalia/humanet/bluetooth/sample (v. 2012-06-12)

top

the initial version

@MISC{tecnalia-humanet-bluetooth-sample-2012-06-12,
  author = {Jose M. Cabero and Virginia Molina and Inigo Urteaga and Fidel Liberal and Jose L. Martin},
  title = {{CRAWDAD} trace tecnalia/humanet/bluetooth/sample (v. 2012-06-12)}, 
  howpublished = {Downloaded from http://crawdad.cs.dartmouth.edu/tecnalia/humanet/bluetooth/sample},
  month = jun,  
  year = 2012
}
					

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.

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

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

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

[Author] Jose M. Cabero

top

[Author] Virginia Molina

top

[Author] Inigo Urteaga

top

[Author] Fidel Liberal

top

[Author] Jose L. Martin

top

[Paper] cabero-acquisition

top