View
214
Download
0
Tags:
Embed Size (px)
Citation preview
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