22066
>>: Why don't we get started. I think we've given people the customary grace
period. So I'm very pleased to introduce David Weatherall, who is visiting us
from the University of Washington. I think David is well known to almost
everyone in the room. I think we've known David ever since he was at MIT. And
we've been interacting with him in the years since then, but now he's going to be
telling us about some more recent research, some things that have been going
on, I guess, in collaboration with folks at the Intel Research Lab and folks at UW.
Without further ado, David.
>> David Weatherall: Okay. Thanks very much, Rich. Well, it's a pleasure to be
here. Thank you for coming. Very happy to be here.
And well, I'd like to talk to you today, I'm going to tell you about some of the cool
things you can do with RFID technology basically. You know, I'm only over on
the other side of the lake, but it's been years since I gave a talk here. Many
years, actually.
Okay. So this is me in a nutshell, at least as you would gather from the titles of
my publications. I'm interested in pretty much everything to do with networks.
And I've worked on network systems fairly broadly. In particular, I've sort of
worked in Internet privacy and security, all the way from Internet denial of service
through to privacy issues today on the web and on mobile phones.
I've done a lot of work on Internet management, understanding the performance
of different parts, ISP mapping and so forth, and wireless mobile systems
[indiscernible] eleven different kinds of perceptual apps these days and all of
that.
Come right on in. Seats at the front if you're short.
So I think those are all interesting areas. And there's a lot of great future work to
do there that's particularly relevant to Microsoft. But I'm not going to talk to you
about that today.
Instead, today, I'm going to talk to you about some other work that I've been
working on in the area of ubiquitous computing and RFID systems, if you like.
Don't think of this as sort of future work that needs to be directly relevant to you.
I hope you will take this as an area that is probably fresh for most of you. I hope
you'll find it to be an interesting area in which there will be a lot more activity in
the future.
And it's also sort of indicative of a fairly broad body of research that I've been up
to for the past while.
Okay. So here's the topic area that I'm going to talk about today. It's the Internet
of Things. Now, the Internet of Things is a pretty broad and somewhat vague
vision for network systems that have been extended into the everyday objects.
You know, think light bulbs, tanks, toasters, whatever you like. And all of these
different objects that we might use in our everyday life -- maybe not tanks but,
you know, other things -- are really connected as part of our computing and
networking substrate in some ways.
This is not a new vision. This is a vision that's been around and evolving since
around about 2000. Here's a typical paper that you could read, maybe a good
one early on. Gershenfeld's article on the Internet of Things. This really sort of
proposes an Internet zero in contrast with Internet two rather than speeding up,
slowing down and going everywhere.
Now, the Internet of Things is sort of associated with two other topic areas that
we're going to hear about today. One is just RFID technology. In fact, the vision
is really attributed to the early formation of the MIT auto ID center, out of which
sprang EPC Global. And that's the body that standardizes UHF RFID tags, the
electronic product codes of today which are now beginning to take off.
So RFID is a key technology here for reaching out to all of these everyday
objects.
The Internet of Things is also pretty closely associated with ubiquitous
computing. You've got to have some reason to kind of put all of these tags on
objects. And the presumption here is that there will be ubiquitous computing cell
applications in the sort of classic Mark Weiser sense of having technologies that
are disappearing into all of the objects around the world and, you know,
accomplishing all sorts of other applications where we interact with, you know,
rooms and smart environments and objects much more naturally.
Okay. So this is the space. So now the publication in Scientific American, I'm
sort of realizing -- I don't know about you, but maybe I've overlooked a venue
here of vision papers.
So this was a fairly broad and vague vision, the Internet of Things.
What I would like to talk to you about today really is, you know, our view of the
Internet of Things and work that we have done and progress that we have made
over the past small number of years to work towards that vision. In particular, I'm
going to talk to you about some of the technology you can use to build your own
Internet of Things, some of the different applications that we have explored,
some of the systems and networking issues that we've tackled and continue to
tackle to build those new applications and drive the technology forward, and also
the community that we've been building.
And this progression also sort of parallels just where we've worked over time, you
know, from an early focus on just some of the technology and being able to get
anything going through to some of the systems issues that we're really just
beginning to tackle now.
A lot of other people besides myself worked on all of this material, and in
particular, I would like to credit Intel Labs and the University of Washington,
essentially. This work, most of this work occurred when I was running Intel Labs
Seattle and it's also joint with University of Washington. And it's now mostly
been moved over to the University of Washington. Particular, we use some
hardware here, the WISP that I'm going tell you about in a little while. Josh Smith
is really the PI on the WISP. And some of you might know him. If you don't, he's
a great guy to talk to. You should talk to him. He is now faculty at UW as of
about February. So he moved from Intel to UW. And you see that there are
other people there, UW students as well as Intel engineers who have been
building some of this technology.
Most of what I've been doing with this technology is on the reader side and
building the system, some of the software issues on these WISPs and actually
building complete applications.
In particular, I guess I would single out Josh, Alanson and Michael Buettner.
Michael Buettner is my student, and Alanson is Josh's student at UW, as well as
a number of other people have contributed to all this. And I've coauthored
papers with all of these people.
Okay. So, this is really my outline for the talk, those four points. Let me just dive
into it. And I'll take questions whenever, if you just -- if anything is not clear, just
go for it.
So technology. We want to build an Internet of Things, what do we do?
Well, you can't just use any old technology. If we're really going to push the
Internet or connectivity out into the everyday world, we really need technology
which is small and expensive, wireless, and long-lived. If you don't have those
characteristics, it's going to be very difficult to deploy it ubiquitously everywhere.
At the same time, you need more than just a barcode or something on objects.
We would really like some fairly rich sensing capabilities and even controls of
different kinds as well as the traditional computation, storage and
communication.
It's only by adding sensing to the mix that you really get to write rich applications
which understand what's going on in the real world and have a chance of telling
people what to do or altering things in some way.
Now, the interesting observation here, really, is that some of the different
technologies provide almost some of the ingredients. RFID technology provides
a lot of what you would need to get bullet point one. Sensor networks provide a
lot of what you would need for the second.
We'd like to get the best of both, and I'm sort of loosely calling that RFID sensor
networks. Other people have called this computational RFID. I don't really like
either name actually. Computational RFID is a little off because it doesn't talk
about the importance of sensing.
So -- but not only do we want the best of both, but we also want to throw out
some bits of these technologies to make it work well.
So let me just go through quickly some sensor network and RFID, you know, at a
high level and sort of say what we want to keep and what we don't want to keep
in terms of the features.
Here are some classic wireless sensor networks. I'm sure many of you are
experts on this material. You know, the notion here is that you put sensors on
everyday life as I've been describing, so it seems like a good fit really to monitor
and enable different kinds of smart environments. And the applications that have
been explored here, particularly over on the academic space are, you know, all
the ones you know, everything from monitoring your habitat, seeing what's
happening with those birds, and to hospitals and homes for different kinds of
smart environments on either the environments or on bits of the objects.
To make all of this happen, there are some sort of key features. You have small
sensor loads that are placed around the environment. There's a typical one.
This is maybe a little dated, but it's Telos mote, and this collection of devices,
these are all small devices, but, you know, they're not that small in some sense.
They're battery-powered. All right. So you know, a lot of what you can see on
there is some of the batteries. They communicate often in a peer-to-peer fashion
across one another via a chain here. And they send fairly rich data. Okay. But I
think it would be fair to say even though there's been a huge number of academic
publications in the area that on the business side, the market for these kind of
traditional sensor network applications has been fairly small. And in fact, even in
the academic space, many people now are looking towards mobile phones and
cars and so forth as really the new kinds of sensor networks for participatory just
sensing, if you like.
Okay. That's sensor networks. On the other hand, let's look at RFID.
So I'm mostly interested in classic UHF RFID technology. There are actually
many kinds of RFID. In some ways, it's almost the opposite of you know, the
academic sensor networks in that it was strongly motivated by business needs.
And RFID's been applied a lot, really, to, again, inventories and supply chain
management and so forth. Just sort of think identification, electronic product
codes, if you like.
So all of these different kinds of RFID differ a lot in their capabilities and their
technical characteristics. You sort of go from active RFIDs and these other small
things that are almost like, you know, motes. They can have batteries. They can
communicate over a fairly reasonable range. They're not that cheap. Stick it on
a shipping container, your truck or your cow, just to make sure you know where
they are.
On the other hand, there -- you know, there's very different RFID technology too.
Technology many of you must be familiar with is passive high frequency RFID.
Operates around 13 megahertz. It usually has a very short range. We're talking
centimeters because it uses induction to power things. It's passive so there's no
batteries, so it's using induction and power from a reader to be able to power
these cards.
You'd find these in your smart cards. You know, I probably have a card in my
pocket, right? This is high frequency passive RFID.
Okay. But the kind of RFID I'm really interested is passive UHF RFID. This runs
on an ISM band around 900 megahertz. This is interesting because it, you know,
it has those properties of being very small and cheap because think of it really as
a sticker. No batteries. No nothing. And it's small. Yet you can read it at a
reasonably large range -- 30 feet. You know, maybe we could cover this room,
sort of find where all the objects are in this room. You don't need to place them
right on the reader.
And this was really sort of -- there was a lot of attention on UHF RFID following,
you know, the Wal-Mart rollout or at least attempted rollout when they decided
that all of their suppliers would place UHF RFID tags on all of the pallets that
were arriving or even smaller units that were arriving at their stores.
This of course, as many of you know, didn't happen very well. It's taken a long
time to roll out for many reasons that I'm not going to go into, business reasons
as well as technical reasons.
And the industry has sort of always had a -- you know, wanted to produce tags in
the sub-five cent range. This is somewhat unrealistic. It's not the case today.
You know, it's actually very hard to put any -- to give you any pricing data on
RFID tags. Depends whether you want to buy a hundred or a hundred million.
Things are very much up in the air.
But generally, people believe that this low price point hasn't quite been reached.
Nonetheless, they're really very inexpensive compared to buying load to buying
anything else.
I guess I'm sort of drifting into some of the features of how they work. Let me tell
you a little bit about that because that matters, really, for the rest of my talk.
I assume most of you sort of know how sensor networks work, but you know,
many of you will not necessarily know how RFID works. It's a different kind of
technology.
Okay. So instead of a peer-to-peer setting, we really have, you know, a different
setting here where you have a reader that is in control that has all of the
intelligence. And then the RFID tags are simple.
These tags -- okay. These tags, RFID tags, really there's the silicone for that tiny
dot. All of the rest of the tag is just the antenna. Right. So they're going need to
be physically that big just for an antenna to pick up a little bit of signal.
These are passive. What happens is that the reader sends out a signal, quite a
large one, up to four watts IRP. It transmits. That signal will literally -- can be
literally reflected off the tag. It's radar, basically. What the tag can do is
modulate. It can change its reflection coefficient to either reflect back some of
the energy or to absorb it. And thereby, it can kind of modulate a signal which
can be detected at the reader.
This is called backscatter communication. So it's very low power. It's not even a
real transmission by the tag. You're just not going to get a lower-power method
of communicating at least on the tag.
And the range depends on technology and just how well you can receive signals,
but 30 feet is quite reasonable. You'll even get it to be a little higher.
The tags are usually just identifiers. The main standard for UHF RFID is the
circled EPC Gen2. EPC stands for electronic product code. It's an ID that you
stick on things instead of a barcode.
And Gen2 is just sort of where they're at. It's the version of the technology.
The deployment of these systems has been fairly slow actually. And there are
many reasons for this, business reasons and so forth, as I mentioned. But from
the point of view of this talk, I think one thing that's interesting that I would claim
is that to be useful, they really need to add value over bar codes. Otherwise it's
difficult to charge any more than a barcode. And so that's really what we're going
to try to do with the Internet of Things.
Somewhat ironically, I guess, it looks like UHF RFID technology deployment is
now beginning to take off. This could be the year of RFID. I think they expect,
you know, sales of these kind of tags to reach a billion this year. Yeah?
>>: As I understood, Wal-Mart was the big question that's raised by the suppliers
to use it. Do you know what their motivation was over a barcode, why they
were ->> David Weatherall: Oh, they wanted to save money, provide new functionality
and be able to -- well, I mean, it's all business reasons. It is to save money. The
tags need to be fairly cheap do that.
The main value proposition is item level tagging. So if you imagine a store -here's the classic scenario. It's like the Gap. And you go and you say: I want a
pair of jeans, size 34 or whatever. It's a big pile of things. Do they have your
size or not? Some salesperson goes through and sorts everything.
If you have RFID and you can really tag things at item level, you know what you
have around the store and where it is and that it's over there and so forth. That's
worth a lot.
It also turns out to be the case that bar codes don't -- I sort of learned a fair bit
about this, actually, talking to some of the people at MIT who drove around
forklifts and worked with Wal-Mart a lot and kind of ran into a lot of problems. But
it also turns out that bar codes actually aren't that accurate for maintaining your
inventory. And the reason is, you know, when people check things out, you'll
have a dozen different yogurts or all sorts of something, and the salesperson will
grab one and just scan it 12 times and you're done. This and a bunch of other
things when they can't read it mean that, you know, the databases of what
inventory you actually have is often quite off.
And knowing it accurately is truly worth a lot of money to businesses. So the
idea is that by electronically tagging everything, you really will be able to get an
accurate picture. We've just got to make the technology work. Okay?
But I want to go beyond simply tagging objects and knowing inventory, right? I
mean, that's very much where we're focusing. And the fusion of these
technologies that we're looking at for RFID sensor networks is this picture.
Now, in this picture, I've started from an RFID base because that's actually
closest to what we need, I think. If you really want to be able to tag objects with
things which are inexpensive, wireless, long-lived, small and all this, RFID
technology is a great base. But we need to add things to RFID technology. So
you can see in this picture I've replaced RFID tags with things we're calling
WISPs: Wireless identification and sensing platforms. So these are now small
computer platforms.
It's not a fixed-function tag that just returns an identifier and has another state
machine for storing things.
Yes?
>>: [Indiscernible] a little bit about the cost.
>> David Weatherall: The cost?
>>: The cost.
>> David Weatherall: The cost will go up a lot. What will it be when it's -- and I
would argue that's okay because it will actually provide a lot more value.
What would the cost be when these things are manufactured? I have no idea.
We have prototypes. The bond for the prototype is around a hundred dollars.
Now, it's all just, you know, goes down to that much silicone when you fabricate
it. In theory, the cost for these things should be no different than the cost for
RFID tags, modular some of the sensors. And there are actually packaging
challenges in getting all this down. Yeah.
So that's last point. Haven't got there yet.
Okay. So these WISPs, think of them as just small computers. We're going to
program them basically. They run application code. They perform sensing tasks
and have different kinds of sensors. That means they send rich data back to the
readers, not simply identifiers. That means our reader is now something that's a
little more general than we had before.
These readers really are there to provide power to all of the tags. It's still the
RFID model; the tag can't do anything by itself, the reader is sending power that
the tag is gathering and then using to be able to communicate and so forth. But
these readers, think of them much more ideally as gateways to the Internet
where other application code is running.
You now have much more of a -- this should begin to look more like an
Internet-style system.
So this is the sort of combination we want. And I'm sort of arguing really that
taking this view of the technology is going to give us the advantages we want to
realize in the Internet of Things.
Now, this picture, this mish-mash of technology is not hypothetical. It's not a
question of, well, could you do this? Could you actually turn these passive tags
into computer platforms? You certainly can because it's been done.
Yes?
>>: Maybe I'm asking ahead of time. Do you have energy storage component
on the device or it only says when you're reading it?
>> David Weatherall: Very limited energy storage. A small capacitor which is
basically, you know, orders of magnitude less than a battery on a mote, and it's
enough to kind of balance the incoming power and the outgoing power, just to
get you out of the humps.
>>: It doesn't really sense [indiscernible].
>> David Weatherall: Yes. Yes. That's right.
>>: You see limitations in terms of application size?
>> David Weatherall: Ultimately, yes. We'll see -- we've explored some
applications where you add a little bit of energy storage. But it looks like there
are many applications that you could do without long-term energy stores. And
that's because a model for all of these readers is that, you know, they're always
on. They're always kind of on and powering and asking tags to do things. And
that works for a lot of applications. Yeah?
>>: [Indiscernible] on the sensor and sending it back, or is it for doing something
else as well?
>> David Weatherall: Let me -- we'll get to applications in a while, but here's a
quick example. Maybe you -- maybe you're having some [indiscernible] and you
really want something to send messages back to you when it starts moving. It
would be processing all of those samples and deciding if it's moving or not. That
is a small program. And it would only decide to communicate to tell you that an
object is actually in motion. Can't do that with traditional RFID or without
computation to filter all of the sensor values in some way.
>>: [Indiscernible] can you get [indiscernible] can you still have some sensors? I
don't know if that's even the right question.
>> David Weatherall: You can have some sensors, and I would say that they're
probably not very useful for applications because all you can do is hardwire
functionality to send sensor values back. Right?
I think the computer probably adds a lot of that.
>>: So why can't you just do all the processing on the reader itself because the
reader has to be there sending power and you're not getting a reading back. So
in your example, there has to be a reader, right?
>> David Weatherall: Yes, there has to be a reader.
>>: You might be able to take that [indiscernible]. Why not bring all of the
readings back [indiscernible].
>> David Weatherall: The communication channel is valuable. It's bandwidth
limited. It's power and bandwidth limited. These things run at kilobits a second,
not megabits a second.
>>: In a passive case, aren't all the readers passively replying all of the time?
How do you -- how do you negotiate a channel right now?
>> David Weatherall: Maybe I didn't mention that, but here's one interesting
thing. The reader sends out a signal. The backscatter happens at the same
time, so unlike most wireless technology you're used to where only one person is
kind of transmitting at a time, if you like, the tag and the reader are transmitting at
the same time.
The tag is transmitting the power signal, usually without information -- well, it
could send information. Sorry, the reader is sending the power signal and the
tag is replying at the same time.
So those signals are all mixed up, and you actually have to -- you know, a key
job of the reader is to decouple those two different signals.
>>: Is it by code division?
>> David Weatherall: No, it's not by code division. It's literally two signals
superimposed at the same time, and the reader needs to subtract the signal it's
sending. It needs to cancel the signal it's sending from the signal it's receiving to
find out the ->>: If there are a dozen of these tags in the room or if there are hundreds of
these tags --
>> David Weatherall: Oh, yeah. And there's a multiple access protocol which
we'll get to eventually in about 20 slides for how multiple tags can [indiscernible]
for the chip. There's a multiple access problem here as well.
>>: Even in the passive devices.
>> David Weatherall: Yes. Even in the passive devices.
>>: Are the passive devices not so passive that they are not able to negotiate a
multiple access protocol?
>> David Weatherall: They are able to negotiate a multiple access protocol. It's
a well-defined state machine that's, you know, little bit of silicon. So its fixed
function is built in to allow them to continue the [indiscernible].
And sure, you could come up with alternate designs, but just wait until you see
some of the applications and then maybe you can go through in your head and
decide whether that would be a better design or not, and I would claim that the
computation is useful. So we'll see.
Okay. So let me just tell you a little bit about these devices. These are very cool
devices. There's a WISP. You can see that they're small. This is a -- you know,
a discrete device component. It's just on printed circuit board. That's the WISP
in the middle there. That would kind of shrink to just a small dot if this was an
integrated circuit. All of the width there is the antenna. And it's on PCB just
because it's easy to make them that way.
Again, this could be folded in a different way and could become some little sticker
the size of a regular RFID.
This power harvesting circuitry on this board really, you know, the reader is
sending out a signal. The tag, just think of it as rectifying that signal. And then,
you know, pumping -- using some of it to charge up a capacitor and store a little
bit of energy. That is energy harvesting. And that sort of runs whenever there's
a signal to control it.
There's a microcontroller on this. It's an MSP 430 at the very low end of the
family. There are other things there too. I think there's about 8K of program
space. You know, there's up to 32K of flash. These figures will all change over
time, but it's just to give you a sense of what these things are. These are
obviously much more impoverished than many of the sensor networks you might
be used to playing with.
This backscatter communication, right, which is basically the tag just modulating
the reflexion coefficient of the antenna. And there are sensors. So what kinds of
sensors? Things like 3D accelerometers. Everyone has to have a 3D
accelerometer. You know, whether you're a -- yeah, a Wii controller or a hard
drive or whatever. So we got to have a 3D accelerometer.
They actually turn out to be very useful for all sorts of ubicomp and mobile
computing scenarios.
We also have versions with light/temperature sensors, LEDs that you can
actually flash for a bit of output, things like that too. You can make all of your
own kinds of sensors. Audio, microphone, jitter.
>>: [Indiscernible]. I've been wondering [indiscernible].
>> David Weatherall: Yes. It's really about sensors. It's mostly about sensors.
Now, there could be other kinds of actuation controls, but the only example
you're going to see here -- we just found it to be more useful. This is not a power
[indiscernible]. [Laughter].
Okay. You can also come up with some novel sensors just so we're not kind of
constrained to accelerometers. Here's just a very quick example of capacitive
sensors. It can be used for all sorts of things, including touch. So this is a
version of the WISP that actually has a touch sensor built into it. It's actually -the novelty here is that it's combined with the antenna so you can use it both as a
touch sensor and as an antenna at the same time.
This is useful if you sort of imagine some of these things in scenarios where you
want an object to do something if someone is touching it and holding it. You
know, maybe you want a card to do some transaction if someone is actually
using it, but not if it's just in your back pocket in your wallet. That's almost
two-factor.
This is the WISP. It is -- I want to point out, this is actually a fairly mature
platform for a discrete implementation. You can see we've been working on it for
years. And these are just different models. Over time, they've gotten more
capable, although I gave you the capabilities for the latest version. You can see
it's really still quite small. But we've sort of gone in the time I've been there and
involved from Gen1 to Gen2 and changed some of the antennas so it's kind of
more easier, and the devices have just got a little more capable, and some of the
low-power components you can get have matured in the market.
And eventually it would turn down to an integrated circuit, but, you know, you
need a bit more money to make that happen.
The good point here to stress is just that these devices become more practical
and get better over time. So here's just a little bit on scaling. This is what
happens just for a -- you know, a regular WISP versus distance.
The power you can get from a reader is going to drop off fairly sharply with
distance, at least as fast as distance squared. This is just Friis, and that's going
to limit your operational range. Yes?
>>: Wouldn't it be even faster than that? It's really electromagnetic coupling. So
I would say it's DQ, isn't it? It's not RF, right? It's actually [indiscernible] coupling
from --
>> David Weatherall: Well, in the file field. So this is not in the inductive motes.
>>: Oh, I'm sorry.
>> David Weatherall: So this is file -- yes, this is file field electrically harvesting
the signals, so I think it needs to be D squared. But, I mean, D squared is
actually a little optimistic because there are other factors.
But in any case, the power you can get sharply decreases with range, and
eventually you hit your limit, so this limits operational range. If you need so much
power, you can only get it so close to a reader.
This graph -- I'm sorry if you can't see all of the details, but basically it shows you
as you get further away, approximate distance -- equivalent distance in terms of
power. If you get further away from the reader, the maximum voltage you can
charge this little capacitor up to so the energy you can harvest drops down, and
the response rate, the number of queries from a reader that it can answer
dropped down too because it has less power. It can kind of run less over time.
And eventually we get down to a point where -- the platform needs about two
volts to run, needs to be able to charge and get that much voltage and charge
things up. So the error rate skyrockets and things stop working here.
Some of this data is a little old. The range is now about four meters. So we've
got about four meters that these things will work from a reader, which is not bad
actually.
What's more, over time, this gets better. On the right-hand side there, you
basically have Moore's Law or at least that's the code underneath you can't read.
We think of that as: Wow, there's not a lot of resolution on this. It's much better
on my screen. [Laughter]. Yeah, Caleb?
>>: [Indiscernible] meter range?
>> David Weatherall: I'm sorry?
>>: How big of a transmitter is that? So your four-meter range.
>>: Depends on how big the reader is?
>> David Weatherall: The transmitter?
>>: The transmitter, yeah.
>> David Weatherall: The power from the transmitter can go up to four watts.
So this is quite a lot. So this is actually [indiscernible]. And most readers that
you will see send a watt or up to four watts. So they're already doing this. So I
mean, this is a lot more than a wireless access point.
Moore's Law, everything is getting smaller, computers are getting faster. You all
know that. But what's good for us is that this means that the energy -- Moore's
Law helps with energy efficiency too. You need less energy to run these smaller
things. That means effectively, the energy, the nanojoules per instruction is
going down over time.
So for a fixed workload, so we can either run bigger workloads over time or we
can run the same workload further out. If Moore's Law and if we're doubling
every two years, this means that our range is doubling every four years for a
fixed workload. Yeah? Did you have a question?
>>: Yeah. So what's the program model look like if -- so basically, these things
are getting powered by an external device and you can always be moving this
device around and the sensors may be -- that program on the sensor may be
coming up, may be coming down. I mean, what does that look like? These are
about things like the restartability of the state machine that's on the ->> David Weatherall: Sure. So those are some of the systems and networking
challenges. And I'll get to some of that and tell you a little bit about an energy
away scheduler that runs tasks on these just briefly, only a few slides. But we
are a long way from sort of reasoning about the programs on this space. It's
just -- you know, it actually takes a lot of effort just to get small programs to run
on this platform.
There's a lot more that could be done and that we're sort of starting to do in
terms of just the architectures for programming these things, what the
programming models are. But so far, we've really just been driven by the
technology and prototyping applications and the very first issues we've run into,
which are energy. Just how do you deal with the fact that energy is whatever
and some of the networking protocols. We've done that rather than programming
models. Yeah?
>>: If I remember correctly, different components require different [indiscernible].
Some sensors [indiscernible]. And sort of trade off [indiscernible]?
>> David Weatherall: The short answer is yes. I mean, you're right. So for
instance, we need a higher voltage to write to flash. So by the time you're about
to blackout, you have already lost your ability to lost to flash, so you just need
[indiscernible] to get there in the first place.
We have looked at that. It's not like there's a final answer though. This platform
is evolving all of the time. So right now we're trying to produce the WISP version
five. We're actually going to take some of the communications done by the micro
controller, we're going to move it down to a [indiscernible] if we can. That will
make a huge difference to the platform.
There are all sorts of things like this. You should really think of this platform as
evolve due to considerations like that, of that kind. But there are at least half a
dozen [indiscernible]. These things are really not done.
This is a brave new world and a pretty wide open space. So please don't think of
any of this as like completely baked or done.
Okay. So Moore's Law, things get better over time. We can run things further
out. This means, you know, over time, you'd expect it to be more practical to put
computation in all of these different systems in all of these different objects and
run programs over everyday objects.
I told you about the tag. It's also a reader. You've got to have something to talk
to these tags so we've also prototyped a reader. This is a very flexible reader
here. You can see it's based on software-defined radio techniques. You can see
here just a PC and a USRP. And this is sort of the output. You can actually see
here reader commands and tag-backscatter. That's a trace taken from a real
interaction by that reader.
I guess it's a fairly standard sort of software-defined radio challenge to implement
this. The channels are fairly narrow and the data rates are fairly small. So
there's actually not a lot of difficulty in terms are handling the raw samples to run
this on a low-end SDR platform.
As usual, some of the challenges are latency. Being able to turn things around
quickly, you got up to 500 markers [indiscernible] turn around between receive
and the next transmission. So that's a little tricky in just some of these platforms.
And [indiscernible] that, there's also the signalling issue, the fact that you're
transmitting and receiving an issue at one time. That's fairly unique to our RFID,
and that's the sort of thing that requires just a little bit of energy.
We were happy enough when we separated a transmit and receive antenna by
about that much, that we have enough headlamp room to do that cancellation to
be able to receive the signals.
So this -- our reader does not have the range of commercial readers, but it's still
fairly good. It will go out to a few meters.
Because it's a software-defined radio, it enables us really to change protocols at
a very low level. We can define our own physical error [indiscernible] protocols.
The EPC Gen2 protocol, it's a standard for RFID. Think of that as a starting
point. We really use that as a point of departure, look at the problems there, look
at how we can change that.
But all of these protocols we're going to use will have the features that they are
RFID [indiscernible] reader power things and the tags using backscatter
communication. That's really, you know, a hallmark of the situation.
By the way, there are all sorts of paper references. I invite you to sort of follow
up.
As well as having a WISP and a reader, we've also tried to provide a lot of EPC
Gen2 compatibility. Now, the reason for this is it helps us a lot with deployment.
We can sort of ride the wave of, you know, commercial RFID readers and tags
that are out there.
So the WISP in particular will work, can be powered by and communicate with
commercial UHF RFID readers. We like Impinj readers actually. All right.
Now, to get sensor data to and from the tag, you're going to have to do some -the RFID doesn't understand that you have to encode it in some -- either in the
identifiers or by reading and writing memory on the tag using high-level
commands and building something on top of it.
[Indiscernible] WISP reader, since we've implemented EPC Gen2 on it, we can
talk not talk not only to WISP but to commercial tags as well. So we have all of
those sort of different interactions possible. So it allows us to have mixes of
deployments as well as kind of experiment with brave new world protocols sort of
thing. Okay.
>>: [Indiscernible].
>> David Weatherall: Oh, they're like that big, that tall. It's antenna design.
Whatever antennas you want to use. You can use something else, be smaller.
Yeah. There are many RFID readers that sort of are in smaller packages. Just
depends where they are. Ceiling mounted are smaller.
Okay. So I've told you about the technology essentially. That it exists and
something about what it is. I'd like to just switch gears a little bit and talk quickly
about applications. If there's nothing we can use it for, it's a little bit of a waste of
your time. Fortunately, there are some things we can use it for. Okay. And
really, you could think of all of these as instrumenting the physical world in many
ways for different ubiquitous computing scenarios and cyber-physical systems.
They sort of leverage the wireless along with nature to be able to install these
things in locations that you just don't need to get to for a long time or which are
otherwise unaccessible. Think of this as infrastructure without wires because
you've got these tags.
And many of them also will leverage the fact that because tags are small and
inexpensive, you can deploy these fairly widely.
And I planned that all of the applications that follow are the sorts of things which
should be hard to do with either RFID alone or sensor networks alone.
I'm not going to claim that they're the best applications in the world. They're just
kind of ubi-comp scenarios. Maybe you can improve on them, in which case I
would love to talk with you.
So here's one we fooled around with a little bit. Cold chain monitoring. Supply
chain monitoring is a main motivator for RFID. And one scenario that many
people talked about is going beyond that and monitoring the status, not only
objects but their status as they move around the world.
So here, we've used cartons of milk. And we have a WISP there that's
instrumented to be able to sense the temperature of the milk and how full it is
using a capacitor sensor.
But a better analogy might be -- a better object to mention here might be a bag of
blood or something like that. Objects which have some value and they have
some requirements in how they're handled. You just don't want to leave them
out of the fridge on the counter for too long. It's not a good thing. All right.
With the kind of systems we're building you can imagine that these -- a bag of
blood is labeled with just a small little WISP sticker which can sensing things like
temperature and so forth.
You can then set up a system whereby you're near the reader. You're in the
proximity of the reader and power most of your time, just sitting in the fridge.
Everything is good. That's exactly where you should be.
When you're in transit, you're out of the fridge, this is where bad things can
happen. What we can do is use programs running on the WISP and sensors to
be able to record the experience, what happens to this.
This would require that running for a little while right from the radio. So this is the
example which actually has -- we stuck a super-cap on there. There's
disadvantages as well as advantages actually. You have to power it for a long
time before this thing gets going. But you can do things like that and monitor the
vital statistics of objects while they're in transit. Yes?
>>: [Indiscernible] the time that this can be, how long are you thinking that that
brief period is going to be? I mean because the capacity is really that small, then
it seems like you'd really need ->>: [Indiscernible].
>>: That's neither here nor there [indiscernible] thing of the past. [Laughter].
>>: [Indiscernible].
>> David Weatherall: That's a great question. In fact, this application is the odd
one out in that most of the WISPs we use, they will die within seconds if the
reader is not on. And for many objects, you only need to do things when the
reader is on there and saying do something.
In this case, we stuck a super-cap on it. It's substantially larger. Actually it would
last for like half a day. All right. And so that was ample to kind of record what
happened to the milk.
>>: Why do you need to know for the milk? What matters is what the
temperature is when you got it back and how long you've been gone from the
fridge [indiscernible].
>> David Weatherall: No, no. For a lot of things like a bag of blood, you really
want to know what that thing experienced. I mean, just knowing the temperature
of the fridge, you know, it's often in transit from one place to another. So the
sensing is done on the whatever, wherever it goes. And you know, you don't -maybe in some settings you would be able to infer it from other data, but the
safest thing you would have is actually on that object. This is one fridge to
another.
And you know, you could also maybe with a bag of blood, you basically encode
what it is and other restrictions and be able to check all these things
automatically.
>>: [Indiscernible]?
>> David Weatherall: Well, that's actually the problem with this one. So right
now it's difficult, if you add more storage, you know, it takes a long time to
recharge. Takes an hour to recharge, I think.
>>: [Indiscernible].
>> David Weatherall: No. You could do that. You could look at all sorts of other
designs which I have batteries. Yeah. And we have chosen sort of not to do
that, just to sort of say, well, we're going to look at really RFID-like stickers, which
is ultimately disposable on some objects if you like. As soon as you go to
[indiscernible] batteries and all of that, I think you're [indiscernible].
At some point though, it begs the question of what's energy storage. If we have
a capacitor that [indiscernible] some kind of energy storage. So I sort of imagine
that some of the sensor networks enhance the RFID world may actually collide.
Rather than the coin cell battery, you might have a trickle-charged battery which
you could wirelessly recharge. That would be great. Those things aren't viable
now through many charge and recharge cycles and so forth. So we're back to
exactly where I showed you the capacitors.
So you could try all of these other designs, and they all have pros and cons. It's
actually not my intent to convince you that this is the design, because this is a
work in progress. It really is my intent to convince you that this is an interesting
space for you to be thinking about. I mean, these are small computers. On your
coffee cup. Maybe not on your coffee cup, but on all sorts of objects around the
world to find out where -- you know, find out how much milk you drink
[indiscernible].
>>: [Indiscernible] I think one of the [indiscernible] think of this as [indiscernible]
to keep things embed into the car to know itself where you buy it, it sort of
already has the RFID units. Don't have the [indiscernible].
>> David Weatherall: Right. So you don't have to -- you're absolutely right.
Thank you. I should have mentioned things like that because we really sort of
imagine that some of these things could be built into objects. Actually you can
even build them into electronic objects. Imagine like a cordless power drill or
something like that. Maybe it's logging a lot of statistics of when it's used and
what's going on and what's status and whatever.
If you actually have a little RFID, something in here enhanced RFID with the
startup technology, you can communicate with it with a reader when all of these
[indiscernible] or other things are completely off and not powered and not doing
anything. So this could be a new capability built into all sorts of things in
addition, to whatever other interfaces they have.
Okay. That's one. Here's another one. Activity detection. In fact, there are
many different applications people are looking at for these things around activity
detection. The idea here is that you instrument everyday objects, and by looking
at traces of what objects are used, you can recognize what daily activities are
happening.
A prime scenario here that's come up that we have explored, and this is like a
mock apartment sort of thing, is elder care actually. So this is, you know -- by
providing technology like this, you can kind of recognize what's going on, where
the people are, you know, using cups and kettles and making tea. Whether
they're eating and drinking or exercising or getting out or just sitting on the couch
watching TV and so forth.
This is actually very using for elder care in the sense of helping elderly people to
stay in their homes for longer. Healthcare as you know is a billion dollar industry.
It's incredibly expensive.
So a limb bit of automated support like this can actually be advantageous to
some people. And you can imagine activity detection in many different settings.
This is actually quite -- and so the data here is just -- we actually compared our
system where you just recognizing what's going on from the objects to another
system, an earlier system where you had to essentially tag people with a bracelet
and, you know, UHF RFID reader to work out what objects they were near.
It's more convenient not to have to instrument people at all. People don't really
like being instrumented.
And you can see we actually have accuracy that's pretty good compared to this
other system. This earlier system the [indiscernible] bracelet there, we have the
reading. It's actually tested in an elder care facility. So a lot of these things are
quite real and will roll out to products sooner or later.
Okay. Robotics. We actually haven't really done anything in this space yet, but I
think it's ripe. Robotic navigation is sort of happening or happened. And these
days, people are moving on to robotic manipulation. Right? Recognizing what's
going on with perception and then being able to manipulate the world with robots.
It's hard. Vision is sometimes fragile. And so what's likely to happen is you're
going to use many kinds of sensors, whatever you have available. This kind of
RFID is another one which could be used in many different ways. RFID with a
little bit of sensing, you could slap on objects. You would know what objects are
roughly in the vicinity before you could perceive them with other sensors. You
could localize them in ways, not necessarily just signal strength. Actually it turns
out the phase of information, the different frequencies is quite useful for getting a
bead on what's where.
If you imagine accelerometers in objects, they can actually help you determine
the pose, all right, because you have acceleration with respect to gravity, even
for an object that's not moving. You can often gain some information about
which way around [indiscernible] it is. That's actually very useful for computer
vision and everything else.
When you have an object, acceleration, you know, if it's moving with your
whatever, your manipulator will tell you whether you have a good grasp or not.
Capacitive sensing is useful for contact events so you can tell that you actually
just touched it and you've got it and now is the right time to do it.
These may sound small, but they're all very hard problems in robotics to address
actually, so we think this has some potential we'd like to explore in the future.
And of course you can also have attributes on an object on a tag. Maybe have a
model of what it looks like that you can just read and know the 3D models in the
room to help you with your perception.
Okay. And here's something completely different. This is not my work actually.
This is work by other people more so on the E side of U-dub. These kinds of
RFID with sensing seem to be quite useful for nonintrusive physiological sensing.
So many people or rather a large number of people have devices like
pacemakers, insulin pumps and so forth and all of these sort of things that are in
our bodies.
I've never tried it, but I imagine it's not fun getting your pacemaker battery
changed. This is not a good thing, right?
Here you have sort of devices that don't have any batteries. They can be
wirelessly recharged and so forth. Maybe you would need something around on
your body to be able to charge it, but it's an interesting alternative top explore.
Here's some work in that vein. This is like a little mural preamp so this is like to
implant a moth to be able to record what's it's doing. There's the moth. And
actually there's a big wire coming from it to a WISP. This is Brian Otis. He
actually went further and they kind of came up with an IC for some bits of the
WISP. They put it there, and here's the moth flying. It has, you know, something
hooked on to it so you can get -- record its neural activity. You can actually see
it's flapping its wings.
What you can't see in that picture is there are actually wires coming off it to kind
of go elsewhere to get some of the data out [indiscernible] and the moth doesn't
fly quite right. All right. [Laughter].
But you know, it's still pretty impressive that they can do that. [Laughter].
The world is changing around us, whether we like it or not.
Okay. And there are other applications. One thing many people have been
interested to use these for security. In fact, there are been a lot of work on RFID
security protocols. Most of it on paper because where are you going to get a
programmable RFID tag to try any of these things out? Well, here. That's where.
There's also work. Someone has used it for undersea data collection. Again,
this is a problem with getting across a barrier. You have these glass spheres
that go under water, right, and you really want to send information from one side
to the other where you're sensing it to outside to the electronics, but you cannot
drill a hole through the glass thing there. Sort of has various reliability and cost
issues. So you wirelessly send the data.
And other people have used it for different kinds of activity detection. Sleep
monitoring and so forth.
Okay. So now I feel we've talked a bit about the technology. I hope you know a
little bit about it. We've talked about the applications a bit. I want to go through
very quickly -- I realize that I don't of that much time, to some of the systems and
networking issues around it that I think are fun to look at. And I'm going to talk
about two of them.
Energy is where we've done something. And you know, there are networking
protocols really is where I'll mostly tell you about the opportunities and things that
we would like to do, having looked at the issues a little bit.
Here are the two big issues that come up. I mean, the number one is just
energy. Powered energy is just very scarce in this environment. The
applications you would write are power-limited in terms of what they could do,
functionality, and in terms of the range, how far out they can actually run and do
things. There's little energy available just because this [indiscernible].
So whatever energy you get, you better use it well. The question is, the key
question is how you run a range of programs when you have this low and
intermittent sort of power.
And then the networking side, the key question really is how you design protocols
that let WISP send rich data, messages and rich data as they need to to a stream
sensor data. It's a very different workload than RFID. And it's a very strange
setting. It's asymmetric compared to 80211 or most settings we've looked at. All
right. That's because, you know, the readers really powering these WISPs,
they're in complete control of when the WISPs are on. Module [indiscernible]
period.
Not only that, but the WISPs themselves, they can hear and communicate with
the reader, but they can't hear one another. They can't directly communicate
with one another. So it's quite an asymmetric setting.
So I'll just present just a small number of slides, a few slides on each of these
areas to tell you what we're doing.
Starting with energy. Okay. So on the energy side, the goal is to use the energy
you can get well. That sounds really obvious. What exactly does it mean?
Well, you recall that the power you can get, the maximum power you could
harvest is going to fall at least as far as to D squared. Okay. So here it is falling
off. Just, you know, this is at 900 megahertz assuming four watts transmission
and you can see that we're getting in the milliwatts or maybe hundreds of micro
watts. Or less as you go out further.
So that's all the power that's available.
If you have a task, a small task that you want run, the rate at which you can run
that task is going to fall off according to that graph, as you have less power
available. But ideally it should fall off [indiscernible] faster. That is you want to
be able to run any task out to your maximum range. Maybe it will execute less
frequently and be able to sample things less frequently, but you want to be able
to run all programs in whatever situation you find yourself. That's what we are
shooting for.
To do this, you need to be able to balance the available power you get from the
reader with the consumed power that goes out because they're very little in the
way of buffer here. Turns out there are many costs of buffering I'll get to in just a
little bit.
That balancing act is surprisingly difficult, actually. Why would that be? Well,
because there's a lot of variability. The input power you get varies a lot with the
distance. You can see that graph. It also varies with the reader frequency due to
multipath fading and the reader hops at least in every 400 milliseconds
[indiscernible].
So you can have variation, you know, of order of magnitude and the power you
are getting at the time. That's quite a lot to deal with.
The amount of power you need for output here also varies a lot of it varies with
the task. You may be doing -- just gathering a sensor thing and checking to see
whether you should be doing something. You may be running a protocol which
does a little bit of crypto or activity detection on the sensors you have to decide
whether a tag has followed a certain pattern or not. You can do all of this on the
tag if you could write a program like that.
There's also nondetermism here, and a bit of variability, not only from the inputs
to the program via the sensor data, but because of the wireless protocols. There
can be contention on the wireless channel. You may need to send more
messages to finish your task.
So these factors vary a lot. And what we find here is that the RFID model, the
classic EPC model for protocols doesn't work very well in our setting. The model
there is just basically run whenever there's power. If there's any power, just turn
on and run. That works for a simple program which have a low worse case
power consumption because they'll be able to run that program out to max range
and it will [indiscernible].
Here we're not in that case. Not in that situation. So we're going to need to
adapt. What do we do?
Well, first let me tell you a little bit about the WISP power model. This is how it
works. So we said that you already know there's limited onboard energy storage.
This capacitor is much smaller than a battery. Actually by like about eight orders
of magnitude compared to a couple of AA cells.
The reader for the tag will have its power whenever your in the proximity of the
reader. How much power you get is going to vary, but you know the circuitry
there will basically harvest whatever is around. And then so this will go into the
energy buffer. You got a little bit of a store. And as you run, you sense, compute
or communicate, you expend energy fairly rapidly. Actually more rapidly
generally than you can gain it.
This means that it's quite normal to exhaust power every second or even many
times a second. It's very different than a sensor network scenario where your
goal is to maximize the lifetime of the sensor network measured over days or
months or longer. Here we're talking about seconds.
And you can see here, this graph just shows the green is the WISP voltage.
That's the proxy for energy. It's going up over time and jumping down fairly
sharply whenever the WISP actually turns on and runs any program or does
anything.
There are some reader activity messages. However, to a first approximation,
they're not affecting whether you're getting energy or not because the reader is
sending a signal whether or not it's actually sending commands. And you're
getting energy in both cases.
So here's our solution. Instead of RFID scheduling to be able to run programs on
WISPs. We have built an energy-aware runtime called dewdrop. I only have
time just to sketch it to you very briefly. I'd be happy to talk to you more about it
later and some of you may be going to [indiscernible] next week. Now you'll be
primed for the paper. You can ask Michael really hard questions.
So the job of dewdrop really is to adapt how programs are run to the RF power
that's available and the size of the task. Instead of simply proceeding with an
RFID model where you just try and run things whenever you meet a minimum
turn on voltage.
So dewdrop is really trying to ask whether there is likely enough energy to run a
particular program. The only decision it has to make here is really how long to
wait and continue to harvest power before starting to run a minimal task which
can't be interrupted.
You can imagine a big task broken into all sorts of little pieces. But at some
level, some small unit that you just want to get done. All right. How long do you
wait before you do that?
If you just turn on and try to run at any time when the input power is really low
and your task is going to take more than available, your task will fail. That will
mean you have just completely wasted all of that energy because it didn't
complete, you didn't get the result, whatever.
While it's not so obvious why, there are also penalties for waiting too long. We
discovered this from looking at platforms. This is due to not only the
[indiscernible] in platforms, it costs more to gather energy as you fill up a
capacitor, as you get -- as it gets higher, it costs more to gather it. There's also
different kinds of leakage, and there are other nonlinearities in the platform.
This was sort of a little bit of a surprise to us because we [indiscernible] sort of
imagined a bucket of energy and you just fill it up and you can use it for whatever
you like and as long as your bucket is full, it's okay.
This is not really the case I think in any real platform because of the
nonlinearities. Some of that energy costs you more or less than some of the rest
of that energy. And in general, you sort of want to enough energy just to run
what you want do and collect no more. Try and collect and storing energy is just
not that efficient in these systems.
Dewdrop worked by balancing these costs. It's actually reasonably difficult to do,
to implement on a small system. Yeah?
>>: Sounds like [indiscernible] one is where there's no energy and
[indiscernible], one is where you're running a program [indiscernible], like say
keeping memory alive but executing code in a low-power state. Would any of
that change the model?
>> David Weatherall: I'm not sure how much it would change it. Actually I've
skipped that state so we actually do have a sleep state in the middle where
memory is being maintained. So you're trying to get through something before
you kind of hit that state. So we do have that sleep state as well as active as well
as completely off cold style. The goal is really to stay in the sleep and the active
states. And you really do [indiscernible] in the active state depending on how the
energy is coming in and what the task is and just trying to make it work. That's
what you're really trying to do.
It sounds fairly simple. Hey let's [indiscernible]. It turns out to be fairly hard do in
practice not only because this is just such an energy constrained environment,
just asking the question, hey, how much energy do we have burns a lot of energy
and a lot of time. So you don't really want do that. Okay. Especially the charge
times here before we get going on a task range from milliseconds, tens of
milliseconds, so tens of seconds. So it's a very large interval. Any kind of fixed
thing that works for one end, well, for one end is going to completely screw up
the other end. So we sort of use adaptive strategies. As you would expect,
different kinds of [indiscernible] backup and so forth.
And very careful instrumentation because you can't -- you know, we're only trying
to indirectly infer where we are in terms of a balance point by looking at cues for
often it looks like it's too early and too late we're just deciding cost to this.
But if you do this, if you track these things and if you try and balance a little bit
and if you're careful to make sure that your energy scheduler really doesn't
consume very much energy, you can get a substantial win.
Here's like just a tag response rate for two different tasks, the blue and the red
line. The blue line is just, you know, the -- a lightweight task, just sensing
something, getting a data sample. It goes down, D squared.
The red line is the same one when dewdrop is on. It's the same kind of line.
That's great. It's actually what we want. It's just at a lower place because it's a
more heavyweight task and involves some transmission and so for the. So you
can do fewer of them with the available energy.
What happens without dewdrop is that you know, with dewdrop, you can run this
task out to pretty much the full range. You can run it out to 3.5 meters. Without
it, basically, before with our default hardware scheduler, where you just do
something [indiscernible] RFID, you just stop working when you hit a meter and a
half. So we have succeeded here in being able to run across a range of different
programs and a range of distances and so forth, being able to run some
programs at least.
This also helps in terms of some application scenarios. This bottom graph is
taken from that picture of the apartment. Slightly different setup but a different
apartment where we're looking at coverage. How many different tags can run a
task given one reader somewhere.
And the answer is that when you use the scheduler, you basically improve the
coverage because while there were some tags which were just fine doing any old
thing, other tags were in a place where they really benefitted from the scheduler
and so you get either an increase in coverage or you can reduce the power you
need for a given coverage. Yeah?
>>: [Indiscernible]?
>> David Weatherall: We don't predict reliability. They could move around. I
think we're assuming that things like motion is happening -- is changing the
situation relatively slowly such that you can adapt to it. And that will hold for the
apartment scenario, that's generally find. Maybe that won't work for some other
situations. But it's okay for what we looked at. Yeah?
>>: [Indiscernible] in the apartment reader's just embedded in the ceiling, do
your power problems go away because [indiscernible]?
>> David Weatherall: No. I don't think the power problems ever go away. And
the reason is, even if you got a reader in the ceiling, it's just blasting power all the
time, the amount of power you have when you are close to the reader is like ten
times as much as the amount of power you have if you're over in the corner. You
can either write all your apps to just assume they're at max range, in which case
you just can't do very much or run very slowly, or you can write your apps to run
with lots of power, in which case they will just die in the corner.
So what we're really trying do is make it so you don't have to do any of that. The
system will adapt. It will take your task. It will run it as much as is humanly
possible.
And besides just that, there are other factors which cause variation too. So you
want to be able to adapt to them.
Okay. That's mostly energy scheduling. Let me just say we are looking at some
other things. There are some complimentary strategies here. I told you about
breaking things into stages, checkpointing things in a different way. You could
even use nonvolatile memory, sending things to readers. These are all
interesting things to look at, but we have sort of gone for the problem that was
troubling us the most at the moment.
You could do all sorts of other things actually that would be interesting. Could
even coordinate with readers. There's no reason they sort of need to turn off just
when you kind of -- I just needed you know, a few more micro watts or milliwatts
to do something. Reader stopped. You can change that if you want to throw out
now protocols.
I would not claim that this is like the most important thing on the list, and that's
why we haven't explored it yet.
What we did find out actually is that some of this power debugging work is
actually very hard. What goes on in all these WISPs just before they die? Well,
who knows? You can't see. I mean, it's not like it has any power to tell you
anything or send a message. And so in fact, for quite a while -- it took us a little
while to develop power debugging tools essentially.
Here's a debug board that's powered, yet does not influence the behavior of the
WISP. And this sort of allowed us to see various interactions across WISPs as
you have more and more WISPs due to the wattage protocol and contention,
their energy consumption is changing. And we can also see the current RFID
protocols are actually somewhat demanding because when you begin to
participate in one, you need to go through a whole round to kind of keep
synchronization with all of the messages to know when you need to send. So all
of the tags are sort of burning more energy than they would need to. It's fine for
RFID if you just locked it to that extreme, but in this world, it's not necessarily
good protocol.
Okay. So I'm basically jumping ahead to protocols. And here I really just want to
tell you about some of the opportunities. And I just have a few slides left. So
hopefully we won't over [indiscernible].
So I think there are a lot of opportunities with some of these networking
protocols. It's a very different setting than 8211. So let me just tell you a little bit
about it.
Here's how the EPC Gen2 communication protocol works. It's based on slotted
Aloha. See all those randomized protocols you learned in your networking
courses long ago? They are useful. Okay. All right. Yeah, definitely was
expecting that.
It's slotted Aloha because the tags can't hear one another. So when they talk,
they may collide. Slotted Aloha is a protocol that really predates Ethernet. It's
even -- make even weaker assumptions about who can do what things.
So it works something like as follows. Okay. So the reader is in control because
it's sending the power that's letting everyone do everything. So it sets the timing
and the power. It issues the slots in slotted Aloha. Slotted Aloha is a
randomized contention protocol. Tag is going to pick a random number of slots
to wait and then backscatter its response in a random slot. If other tags pick that
slot, it may collide and then you have to go through some dance.
So you can see here, the reader is sending out query and query repeat
[indiscernible] of the slots. This tag has chosen to wait. Respond in the third
slot. The actually responds with a little handle. The 16-bit random number. And
if the reader ACKs, it then sends the whole identifier. Why does it do that? This
is just smaller for collision so you kind of balancing the costs of different things.
And at this point, the reader can now interact with the tag and ask it hey, what's
going on and get a little bit of data or store a little bit of data.
This is called singulation, to get down to a particular tag. From our point of view
though, it's -- it has some shortcomings for writing WISP apps. It's really
optimizing for identifying an unknown set of tags. Okay. You are going through
this dance to identify all the tags before you can actually talk to them and issue
any commands. Now, you then have to work out how -- where to put the sensor
data. There is no place for it. We can overload it on identifiers or use memory
read commands and pretend it's part the memory. But basically it's a poor fit for
streaming sensor data from a slowly changing set of tags.
You really just want to stream the sensor data, but you have to go through this
dance all of the time.
A second sort of defect is that the reader is logically in control because it's for an
inventory application, just seeing what tags are around. It starts all exchanges
and it goes through this identification process. This means that WISPs can't
easily in any of the protocols initiate their own messages to other WISPs in the
vicinity. So there's no sort of -- you can't easily have one WISP ping another
WISP or you know, send a message or send a message or anything like that.
The protocols just don't work that way. There's no narrow waist, if you like, on
which to build higher layer applications.
So we're looking at both of these areas to explore them because I think they
would both be interesting.
You can imagine streaming sensor data much more effectively by assuming that
you have roughly the same set of tags around and then simply changing the
values, sensor values over time.
So now, you got to make the protocol work because the set of tags will change
slowly over time and also things you need to be careful about. But basically
we're looking at reusing some of the short identifiers as handles and treating
them as address and in this way you can stream sensitive much more effectively.
We have some prototypes if you get up to five X improvement simply because
you're not using all of the rest of the channel or all of this dance. And this is the
sort of thing you might even be able to approximate when the Gen2 standard.
We're also looking to integrate WISPs with IP via reader so that you can, you
know, from your computer ping a particular WISP or it can ping you or it can send
you a message when it arrives somewhere else.
This is really [indiscernible] the reader not so much as part of an inventory
application but an AP that is simply there to help WISPs operate in the same way
that APs just help your laptop. So think of the reader there as providing power,
Internet connectivity that you need, and even delayed tolerant networking
services since some of these WISPs will often be off or in different places and so
forth. You can kind of rendezvous via the reader.
This is really an architectural change of viewpoint. That we're sort of exploring
that will let WISPs initiate all of these data transfers as well as naturally fit with
WISPs which run different apps in the same room. And it's just kind of -- well,
there's no rocket science there, but it's just fundamentally different than the way
you think about inventory apps and how they work. Okay.
I'm a little conscious of the time. And that's all I had for you on this systems and
networking protocols. Hopefully that gives you a sense of some of the issues
there, some of the interesting things to play around with.
I just have a couple of slides on the community.
We have been building -- this was community actually. So both this WISP tag
and the reader I talked about are freely available to the research community.
There's open-source hardware and hardware design, at least, and software out
there can grab. These are the only platforms that we know of this kind that are
programmable RFID or RFID readers where you can really mess with -- at a very
low level that are readily available.
The SDR readers is actually a monitor so you can use it as an RFID monitor. If
you are looking at any systems, the thing you want to know is what's going on at
a low level. But some of these monitors are incredibly expensive. You can just
get a $1,500 USRP, attach it to a PC and see what's going on.
You can look much -- there's much more detail and all sorts of pubs and things
off this URL if you would like to look. We've also sort of been, to build our
community, tried to encourage others to write applications and experiment by
themselves. We've had a WISP summit concurrent with Sensys or collocated
Sensys 2009. And we also issued a WISP challenge or a request for proposals
for other groups to say that they would like WISPs, that they would be interested
in doing things with them.
All of these efforts have been quite successful actually and we're very pleased
that there are now WISP starter kits, 36 different research groups. There's a
sampling of them there.
And more importantly for us, there's now sort of a stream of pubs. Some of these
are all pubs. Not all of these are our pubs. Other people started to use WISPs
and publish them and do some work.
We have work spread over security as well as systems stuff and some
applications, although not as much as we really ought to see.
So in conclusion, I've talked to you today about some RFID technology which I
hope we'll see a little bit more of in the future. Really I'm not going to go through
all of this. I just hope that you've heard something that would be interesting and
you can sort of imagine some of these small computational systems as part of
the every day environment. That would be an interesting area to look at.
I'm happy to talk a lot more about this or about also some other kinds of systems
and network that I do.
Thank you I'll take some questions. [Applause]?
>>: You said that [indiscernible] applications where [indiscernible]. I'm just
wondering do you have [indiscernible] where the WISPs need to have
[indiscernible] apart from whatever input [indiscernible]? I'm just trying to think of
an application scenario where there has to be complications on these
[indiscernible].
>> David Weatherall: Well, it is simply a matter of performance. Right? It could
simply be a matter of performance. If you got all the sensor data and you have
enough power to send it to the reader and run whatever you were going to run.
Now, I don't think that's likely to perform nearly as well in some cases. So some
things you could imagine doing are activity detection.
You have a stream of sensors locally. You're trying to work out if an object is
actually doing something you care about, if it matches a type of filter. You are
doing that recognition locally. You're only talking and telling people about it,
telling the reader an apps there out there on the web about it if it meets that
condition.
The alternative you're suggesting is you can just accepted all of that sensor data
back all of the time and process it elsewhere. You could do that. It's a different
architecture. It's a valid architecture. I'd be kind of surprised if you didn't run into
a lot of bottlenecks in doing that on the wireless channel when you have many -when you have many different tags around. And in addition, well, I mean, it's a
tradeoff. I'm not sure why you're looking puzzled.
>>: [Indiscernible].
>> David Weatherall: No I don't think it would be much cheaper at all. It's just a
[indiscernible]. That's not where the expense is. I don't think it would be
substantially cheaper.
The other thing I was going to say though, it's hard to know ahead of time exactly
what functionality you want in a tag. Witness all of the RFID security stuff. So
maybe you put some scheme in there and it's hard baked in and all they can do
is send the sensor data back. I guarantee you, as soon as you do that,
someone's going to want to change what's on that tag. Right? They're going to
want it to do something else. And that's what a lot of the security community are
doing. They're basically running little crypto programs and testing designs on
some of these tags.
I mean, so that's using the computation for another purpose. It may be a while
before we get to applications which really -- you couldn't sort of imagine doing a
slightly different way. Because this is just the beginning. Yeah?
>>: [Indiscernible]?
>> David Weatherall: Density?
>>: Yeah. How many of these tags -- how many tags can I put in this room.
>> David Weatherall: So we really have gone up to tens. 10, 20, that's about it.
And we can't see interactions across tags because they're all [indiscernible]
channel. The amount of time you run a task gets bigger.
>>: [Indiscernible].
>> David Weatherall: Yes. Also -- yes.
>>: [Indiscernible].
>> David Weatherall: Yeah, yeah. I agree. There are a lot of things that would
be fun to do here. You know, doing anything with WISPs unfortunately, it still
takes a while to get going. It's fairly hard to -- they're still fairly hard to work with.
I think it would be interesting to see how they scale. Right now, I don't think they
would scale very well as you go beyond, you know, 10 or 20 or whatever. And
that's because the amount of energy to run a task, because we sort of do that
communication protocol, writing for that time, it's growing with contention.
I think the challenge there is to ask well maybe that just means all of the network
protocols are broken. Could we design different protocols that in fact would not
work that way and would let us scale much more effectively? Maybe they're not
going to be perfect, but we should be able to go a lot further than we have.
I think that would be an interesting area. We just haven't done it?
>>: [Indiscernible]. I realize it's [indiscernible]. How many cycles of computation
do I get?
>> David Weatherall: You know, varies with the design of these things.
Thousands. You can have thousands of cycles. [Laughter] that may not make -you know, it's changing over time.
>>: [Indiscernible].
>> David Weatherall: No, no. But on a chart, so I mean you can do more at a
time, right.
>>: [Indiscernible]. I guess the other thing I wondered is is CPU really the right
thing [indiscernible]?
>> David Weatherall: Maybe. I wouldn't rule that out, because as I say, we're
early on the technology. I think it all depends on the applications.
>>: [Indiscernible].
>> David Weatherall: Based on the sensor network world.
>>: [Indiscernible].
>> David Weatherall: Yeah. We would like to believe ->>: [Indiscernible].
>> David Weatherall: Yes. That's with the current hardware. That could go up?
>>: [Indiscernible].
>>: You divide the numbers that you put up there, you said that the power input
to this thing looked like in the range was hundreds of microwatts and in that other
graph, it shows a hundred -- up to milliwatts. [Indiscernible] the low range
hundreds of microwatts. And those other completely unrelated graph, you said
that the -- that energy per cycle is something like a hundred [indiscernible] per
cycle. So if I divided correctly, that would say that if the all of your power
[indiscernible] processor, you'd get about a megahertz [indiscernible], right?
[Indiscernible].
>> David Weatherall: Yeah. Okay. Well, I [indiscernible] on the data. I mean,
the data from Moore's Law comes from a completely [indiscernible]?
>>: [Indiscernible]. But it makes you think that [indiscernible] ->> David Weatherall: That's well beyond ->>: Well, I mean, that's not [indiscernible] or anything else.
>> David Weatherall: I mean, over time, these things are just going to come
more viable [indiscernible] applications [indiscernible]. Okay?
>>: [Indiscernible].
>> David Weatherall: What do you mean?
>>: How do I know which [indiscernible]? [Laughter].
>> David Weatherall: Oh, I knew we forgot something.
>>: [Indiscernible].
>> David Weatherall: Come on, guys, don't be such skeptics. [Laughter].
So they have an identifier of course, like RFID does, as well as sensors and so
when you begin talking in a protocol exchange, you may not know that you're
talking to a particular one. You have to find that out during the protocol
exchange.
>>: [Indiscernible]?
>>: They can be read programs.
>>: Yes.
>> David Weatherall: I think you can even in commercial RFID tags. Well,
actually, you can't program ->>: [Indiscernible].
>> David Weatherall: Yeah. Yeah. Yes?
>>: [Indiscernible] so it cannot be reprogrammed because [indiscernible]?
>> David Weatherall: All of the cost and business considerations would really
effect what happens here. Systems like this will have to sort of justify what they
can do. I mean, they need to be applications which provide enough of a benefit
to go to the trouble of sticking sensors in their arm. And that is something that
we'll all see whether that pans out or not.
>>: What's [indiscernible] applications [indiscernible]? [Laughter].
>> David Weatherall: So the FCC tells us this is all fine. [Laughter]?
>>: [Indiscernible].
>>: There's 300 watts of much higher frequency RFs coming from those light
bulbs [indiscernible].
>>: The light bulb is producing more energy than it receives.
>>: [Indiscernible].
>> David Weatherall: I don't have anything sensible to say to that other than this
is the situation and yeah. Your mileage may vary.
>>: [Indiscernible]. [Indiscernible] recognition may or may not be feasible just
out of that [indiscernible] constant exposure [indiscernible].
>> David Weatherall: Yeah, well, sort of the [indiscernible]. And you might be
able to do some of these applications [indiscernible] just the way RFID works
today and what you need to be able to get (inaudible). But you don't need to
worry about your cell phone [indiscernible]?
>>: Call it good everyone.
>>: One last question. [Indiscernible]?
>> David Weatherall: Oh, I love this. [Indiscernible]?
>>: [Indiscernible] because that's really setting the [indiscernible].
>> David Weatherall: I know. Yes. This is not -- yeah. For the rest of you, this
is not how you normally [indiscernible]. [Indiscernible].
Okay. Thank you. [Applause]