thomson

1
(No Transcript)
2
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
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 1205 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