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 inquiring Two 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# NodesDuration# Contacts Intel94 days1 190 Cambridge125 days4 228 Hong Kong (school)235 days Hong Kong (city)375 days266 INFOCOM’05413 days INFOCOM’06984 days CoNEXT days88 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 secs Add ±5 s to avoid synchronized inquiries on motes Sleep mode in-between inquiries Store “active contacts” in RAM Allow one skipped inquiry period Write 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 code Fixed buffer overflow – no software resets (that we know of) Fire timer every 120±5 secs and perform inquiry Seed random function with MAC address Write 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 mode MAC 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 differences MAC 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