system power to roughly 10 uA. What
we are exploring now is how to design
the operating system on the device
that allows the software to be well connected and energy efficient without
significant complexity. New language
features, for example, those found in
C++ 14, allow for more natural expression of event based programming constructs and could help reduce the difficulty of efficient firmware design.
In summary, there are a few key
challenges that need to be solved in
order to realize the IoT vision. Chief
among them are development agility,
power efficiency and communication.
In order for the IoT to flourish, the
barrier to entry needs to be low, and
this implies that we will see changes
to hardware and software appearing
in the bread-and-butter development
platforms used by the masses. Hopefully, we will see better connectivity,
better network stacks, and more power efficient operating systems in the
Michael Andersen is a Ph. D. student at University of
California, Berkeley, and part of the Software Defined
Buildings group. He works on ultra-low-po wer embedded
systems for the Internet of Things (Io T), wireless sensor
net works, and high-performance telemetry databases
for handling the volumes of data that Io T applications are
expected to produce.
© 2015 ACM 1528-4972/15/12 $15.00
What about communication? Well,
that is not doing so well either. Considering most development kits do
not come with a radio, if you find one
that does, or you find a radio module
that can plug into your development
kit of choice, you’ll find the supporting code to be rather lacking.
Remember the IoT is about connecting billions of devices together.
This is not a trivial task, and requires
a decent interoperable net work stack.
How often have you encountered an
off-the-shelf development kit with a
decent TCP/IPv6 implementation?
I would wager never. Even in the research community, essential problems like how to connect a sensor
mesh network to the IPv6 Internet
are not solved. Every group has their
own border router solution and most
of them require a great deal of baby-sitting to maintain in working order.
Even at the link layer, there are unresolved problems.
Bluetooth LE, or Bluetooth Smart,
seems to be the most popular interconnect type for devices on the market. It offers low power consumption,
cheap components, and easy connections to mobile phones. Unfortunately, it is also lacking in many ways.
Bluetooth is primarily a peripheral interconnect, meaning you need an app
on your phone to talk to your smart
devices. How do you expect to create a
large autonomous system of interconnected devices if they all require a mobile phone with a specific application
to be nearby? Can you even imagine
installing hundreds of apps in order
to interact with smart buildings and
the myriad of heterogeneous sensors
Perhaps we can shift to connecting
devices directly to the Internet and
interacting via services in the cloud.
The old machine-to-machine (M2M)
setups used in industry have every device equipped with a small cell modem
(sometimes even a satellite modem).
This is great in that they function relatively autonomously… as long as someone pays the bills. I bet it costs you $10
or more per month to get a data plan on
your mobile phone. Are you willing to
pay $120 a year to keep a $2 device connected to the Internet? Thought not.
What about Wi-Fi? If smart devices
are in a house or building, can they
just use existing wireless infrastruc-
ture? Well, remember the power effi-
ciency problem? Even the latest gen-
eration Wi-Fi modules use upwards
of 200mA to transmit and more than
50mA to receive. For perspective,
that means a 2xAA battery-powered
device has a life of two days even if it
is doing nothing except listening for
commands. Technology such as IEEE
802.15.4 is a lot more promising in
terms of energy efficiency, but has yet
to see widespread adoption past academia. It also has the disadvantage of
not being able to connect to a phone.
This may be changing though with
products like Nest and LiFX using
802.15.4 for part (but not all) of their
To investigate these challenges, a
team at UC Berkeley is working on a
platform (see Figure 3) that retains
all of the advantages of those already
on the market (rapid prototyping via
hardware expansions and easy-to-use
software environments), but also pays
a great deal of attention to power consumption and connectivity (featuring
both Bluetooth LE and IEEE 802.15.4).
Features like the USB serial debugging
or onboard sensors can be turned off
with fine-grained power domain control, allowing a reduction of whole-
Figure 3. The UC Berkeley Firestorm, an Arduino compatible Io T platform featuring
a Cortex M4, Cortex M0 and BLE + IEEE 802.15.4.