Lessons from Haggle iMote Experiments

Erik Nordström

Haggle meeting 9-10 January 2007

3

Background

Investigate contact patterns (human mobility) of users Intel motes handed out to participants at conferences

– Bluetooth inquiry scan at regular interval

– Record devices in proximity

– Motes can only respond when not inquiringTwo types of iMotes

– Mobile mote (dental floss) carried by users

– Stationary long range mote, more battery, external antenna

Reset problems motivation for new experiment

4

The Intel Mote

5

Overview of iMote Experiments

Experiment # Nodes Duration # Contacts

Intel 9 4 days 1 190

Cambridge 12 5 days 4 228

Hong Kong (school) 23 5 days 11 368

Hong Kong (city) 37 5 days 266

INFOCOM’05 41 3 days 22 416

INFOCOM’06 98 4 days 170 158

CoNEXT 2006 87 4 days 88 262

6

Challenges

iMote hardware is very restricted– ARM7TDMI at 12 MHz

– 64 kB RAM

– 512 kB permanent flash storage!

– Integrated Bluetooth 1.1 (~30 m range)Software environment

– Windows + Cygwin development

– TinyOS implementation for iMote is experimental

– Proprietary ARM compiler

7

Basic iMote Software Features

Loop initiates a Bluetooth inquiry every 120 s Inquiry for 5 secsAdd ±5 s to avoid synchronized inquiries on motesSleep mode in-between inquiriesStore “active contacts” in RAMAllow one skipped inquiry periodWrite to flash when a contact ends

– Saves space

– May loose contacts in RAM upon reset

8

iMote Software Problems

Buffer overflow causing resets on nodes with many “active contacts”

Risk of long term contacts never being recorded Bug in FlashFS implementation causing headaches Unseeded random function generator

– Affects scanning de-synchronization Limitation in Bluetooth lower layers returning max 8 devices

each scan– Hence the motivation for a non-standard 5 sec inquiry period?

Inefficient timer operation – Fired every second even if nothing needed to be done– Drains battery?

9

Software Fixes

Ended up rewriting most of the codeFixed buffer overflow

– no software resets (that we know of)Fire timer every 120±5 secs and perform inquirySeed random function with MAC addressWrite contact to flash when first seen - update with

end time when it goes away– Protects against potentially lost contacts

Increase limit on returned contacts to 100

10

Observations

Few contacts were returned each inquiry scan Increased inquiry period returned more motes

– Trade-off between scan time and overlapping scans– Drains battery?

Differences between type of device– Motes are rarely recorded for more than around 1-4

periods– External devices are recorded for much longer periods

Unclear effect of sleep modeMAC address corruptions (also in old experiments)

– Noisy environment (70+ nodes in same node)

11

Implications on Collected Data

Short mote contacts– May seriously impact mobility pattern as it favors short

contacts…

– …or is this reality?

– Long external contacts indicate hardware differencesMAC address corruption

– May also explain short contacts

– False contacts?

12

Conclusions

iMote hardware limitations?– Bluetooth radio weak, favoring external devices

External contacts do not inquiry regularly

– No listen while scanning

– Impact of overlapping inquiries on sampling?Bi-mote, tri-mote experiments

– Bundle two imotes, one inquiring one listening

– Third imote only listens