17411
>> Ranveer Chandra: It's my pleasure to introduce Peter Steenkiste, who is a professor at CMU,
professor of computer science and, electrical and computer engineering. He's been at CMU for
more than 20 years. And this is your second visit to Microsoft, which is quite less for someone
that senior.
So he's worked on lots of stuff, including Nectar, which is high profile, had a bunch of [inaudible]
papers. And very recently on wireless networks. Today he'll be talking about some of the
innovations he and his group have done in this space.
Peter Steenkiste: Thank you. Okay. So the motivation for the work I'll talk about is basically
something that we call chaotic wireless networking. So the project started about five years ago,
and when we made the observation that a lot of the wireless networking research was looking at
what you can call wireless in challenging environments, which roughly speaking ad hoc networks
with nodes having difficulty reaching each other, very low battery types of devices. A lot of
random mobility and so on.
In reality a lot of people were using wireless but they were using wireless in what were effectively
looked to us very dense environments. They were using wireless at home, in hot spots, in office
buildings. And so the challenges in these very dense environments are really very different from
the challenges in these very sparse environments.
So we basically decided to start a research project in that space. Since the name ad hoc was
taken we figured we'd call it chaotic. So some of the characteristics of these networks are that if
you look at home networks and all of the hot spots, they're largely unplanned. People put the
access point where it's convenient.
People who set up these networks don't know anything about wireless networking. And then also
a lot of them are unmanaged, right? And there's also a lot of them that are unsecured. So these
are very different environments from, let's say, a campus environment where there are tools
available and knowledgeable people available.
So that's kind of the motivation and the background for this research. This is data from '05 and
earlier. It basically shows there are indeed very high densities in a lot of cities. And I think many
of you have experienced this yourself. If you're in a hotel somewhere, you pull up your window
and you can see a lot of access points.
So here's kind of the road map that we put up roughly five years ago. There was kind of a
three-stage plan. The first one was to say: Look, today we have a lot of WIFI hardware
available. There's a lot of parameters that are in fact exposed, so you do have some control over
how these networks operate. Let's see whether we can optimate or automatically optimize, have
the network being self-optimizing using today's hardware. So there's things like channel
selection, transmit rate selection, transmit power, CCA threshold and so on.
So that was kind of the first step. Even at the time there were some emerging technologies that
looked very exciting. So MIMO would be one. Directional antennas is be another. Software
radio was another. These were technologies that were really not commercially available or at
least not at reasonable prices but that open to potential of giving us more control than what we
have here.
So that's kind of the next phase. And then, finally, a lot of these technologies have very limited
control over the spectrum, because they have to operate in the unlicensed spectrum. So then we
at the time already we kind of say: Look, eventually we want to get to more dynamic spectrum
sharing type of access, right?
Now, we haven't really done too much here yet. We've been in this space I'm going to be super
conservative today. And I'm going to talk about these topics. So I'm going to talk about results.
So it's not this, but these yellow topics here. So I'm going to specifically elaborate on four
projects, Charm, Pro. Transmit Power Control and Directional Antennas. I'll be at a very high
level on each of these.
The reason is when I'm through this I'd like to get back through some common themes that cut
across these four classes of optimization, because ultimately these things are not completely
independent. They are interrelated. So I have a bunch of slides where I kind of look at what the
differences and similarities are between these different techniques.
Before I do that, I will actually briefly talk about another project, which is the wireless network
emulator, in part because I'll present a lot of results that were collected on that platform. So Eyor
[phonetic] is involved in the wireless network emulator. She was also part of the Charm effort.
So let me start with an anecdote. The wireless network emulator was motivated by kind of the
chaotic wireless optimization. A lot of people have looked at this particular problem. Suppose I
have an infrastructure network. I have two APs in red. I have a bunch of nodes and I have a
severe unbalance, imbalance in the load, right.
We all know what you can do. You can basically move some of the clients from the busy AP to
the under -- to the AP that does not have a lot of load and hopefully everybody will be happy.
This means that some of these clients will connect not to the high P that has the strongest signal
but the next strongest or something like that.
So the student who is looking at that at the time, worked on this, came up with this algorithm.
Then the question came up: How do we evaluate this? And so, well, we can deploy it. But it
turned out it's pretty hard on campus, but we need to modify the campus infrastructure and
people are kind of protective about this.
And we could also deploy our own infrastructure, but then we'd be competing with the campus
infrastructure. We could manage -- we could do simulation, which the student in fact ended up
doing. But this was a very honest student, and he said: Look, if we do simulation, I can make my
results look at good as you want them. If you want a factor of thousand improvement I can
probably make it work.
And so there's a problem with simulation, which is that if you give the person running the
experiments complete control over everything, including the model of the physical world, really it
becomes very hard to justify your results.
So that kind of got us going on the wireless emulator project. Where we basically observed that
there's kind of this trade-off between test beds and simulators, and I don't think I have to
elaborate too much on this. I think you know this. Test beds are more realistic but repeatability
and control are very difficult.
Also, test beds tend to be tied to a specific location. So you can only collect experiments in that
location. Simulation has a lot more flexibility. Repeatability, easy control, but you have a
question of realism that you need to address.
And so what we basically came up with was this design for something called an emulator, which
would try to achieve kind of the good parts of both of these worlds.
So here's kind of how this works. Some of you are familiar with this project. So the idea is that I
use real hardware because I am building a test bed. So I use commercial wireless devices or
custom built wireless devices. It doesn't matter. I take this device. I take off the antenna, and
then I plug a coax cable in the antenna port and I capture the signal that's transmitted by the
device.
Then I would have what looks roughly like a software radio front end which basically takes the
signal, brings it to an intermediate frequency and samples it at a high rate. So I get a digital
representation of the basement signal. And then I basically do that for a bunch of devices. And I
inject all these signals into an FBGA which models the effect of signal propagation. So it models
attenuation, fading, interference, noise, multi-path. And anything you can program you can do.
In fact, a physical word isn't really constrained here either. And then basically for each of the
target devices you kind of regenerate an input signal that you pump back into the device. So
that's roughly speaking what this looks like. There's a bunch of red stuff here which is very
important. It's very important that you isolate your test bed at the signal propagation level from
the environment.
The other thing, it's very important that these laptops can only talk to each other through your
FBGA. They cannot talk to each other over the air. Or these are two additional constraints. So it
turns out that building this, it's actually quite difficult. You need to really deal about the issues
such as fidelity of the signal, as it propagates through the test bed. One of the things is you need
a lot of flexibility because that's the whole point of the test bed. You want to be more flexible than
something that's in a specific location. And you want to have this control and repeatability
element.
Then for a bunch of computer science people doing things like system building and packaging
and so on turns out to be quite a challenge. However, the student who actually did all this initial
design and also it was the main architect here is Glen Judd. And he made this happen. Now we
have both Eyor and Kevin Boris another student continuing with the project. This is what we
ended up with, here's the devices this is what you look at an RF brings the signal into
intermediate signal. This is the digital domain this is our FPGA now we have a controller used to
control the experiments. That's the system that we built. The system we have has 15 nodes
rather than four.
>>: You mentioned a couple of slides ago like wouldn't it be nice to actually be feeding the
background interference into the emulator, like instead of all the signals coming from the
controlled experiment you're doing, if you wanted to study, is there a way to do that.
Peter Steenkiste: Yes. Can I get back to this in a minute? Actually, I think I took out that slide.
But there's a bunch of things that would be nice to have. And I'd like to talk about them
altogether.
So this is kind of what it looks like. This is what the RF front end and conversion card looks like.
You can see it. Real cards. They're both custom cards. Then basically these are combined with
a laptop, which is one way of doing it. The blue stuff is the RF isolation foam that you need to
isolate the device or isolate all of the analog parts.
Then this is the central FPGA, which is the Zylik [phonetic] FPGA. We have a lot of connectors to
connect to the end points. This is rack mounted and looks as follows.
That's what this all looks like. The question I often get is: Well, okay, this is all good. But how
does this really differ from a real test bed and a simulation?
So this is kind of a visual representation of this. It shows the protocol stack going all the way from
the signal propagation to the applications at the top. If you're running in the real world obviously
everything is real. So that's easy. Simulation, everything is simulated. There are some efforts
where you take things like real protocol stacks and embed them in simulation. So that's why
these blue wiggly lines are here.
Then in our system this is all real. And then this is basically emulated. And this gives us the
control over the signal propagation environment here. This is the antennas and the signal
propagation itself. So of course one of our things we need to be consciously aware of this needs
to be realistic for our results to be valid.
There's some related work which I've mostly touched on. And then this is actually being operated
as part of the GENI project right now. And we can talk about it off line. Off line.
But let me use the slide to briefly elaborate on two extensions that we really would like to get to.
The first one is that in the current environment that we have, the FPGA basically is controlled at
the channel level. People basically need to specify the behavior of the different channels.
It's clear from a lot of our users they don't have the background to do this properly. So what we
really need to do is raise the level of abstraction. And so what I'd like to do is build a layer on top
of that basically says: Look, a user can say I give you an office environment and give me a
vehicular environment which we were talking about before. Or give me whatever, a mountain,
whatever. Right? So that would be one thing. The other thing is that 50 nodes is kind of very
little or a lot, depending on how you look at it.
But it would in fact be nice to say: Look I have a 50-node experiment but I'd actually like to model
the interference of let's say 15 or 100 other nodes. So this is something that can be done. The
most likely way of doing this is probably to use one of the nodes attach a software radio on it and
have some software on it that plays back traces or does something to model the interference.
The more tricky thing here is that the interference observed by the 15 nodes is not going to be the
same everywhere. There's a little bit more complicated than it looks, I think. So these are kind of
the two major extensions that we'd like to look at.
>> Ranveer Chandra: So what's the scalability of this? Sorry 15 nodes.
Peter Steenkiste: Up to 15 nodes. Limited by the card.
>>: Why is it 15?
Peter Steenkiste: It's just simply what we had funding for. It's simply what we felt we could build
in a university. Also, the bandwidth of the system is very wide. It's full ISM band. It's 80
megahertz. If we would build a emulator that operates on 20 megahertz then we probably could
do a lot more.
>>: Using a vertex, better VGA, would that be [inaudible].
Peter Steenkiste: Obviously it would. But it's not the only thing. The packaging is quite tricky. If
a company built it that has experience with analog systems, I think that would be an entirely
different matter. They could build bigger systems, easily.
Okay. So let's talk a little bit about the four projects and then I can try to kind of give a more
global perspective here. So this is some work that was done by Glen Judd and Eyor. So I think
we all know the problem. If you look at WIFI, for example, and many, many technologies, they
have transmit rate adaptation where they dynamically pick the best transmit rate that they can
use. So if you have an SI and R graph here at the bottom and you have a packet reception rate,
you end up getting these curves.
If you pick a certain -- if you observe a certain SI and R at the receiver you can say which
transmit rate would be the best one. You want to be as much to the right as possible because
those are the higher transmit rates. But you obviously want to have a high packet success rate.
So you may pick 5.5. I think we know how this works.
So the visual representation here is that your received signal strength at the receiver will change
over time. This is a static pair of nodes here. This is a trace that we replay. So you can now
kind of say: Okay, over time I need to jump between these different rates here to get the best out
of my channel.
This is the easy case. This is for a mobile node. You also get attenuation in here that changes
as the node moves around. And then the G rates, there are many more of them. So you need to
do this type of a mapping. Okay. Realizing, of course, that predicting the future is always a little
bit hard.
So it turns out there's been a lot of work on this. And so most of this work relies on something
that's called trial and error probing. You basically look at the success you had at certain transmit
rates in the first last five to ten packets and try to use this to predict the future.
And so this kind of works but it tends to be slow in environments that change like the mobile
environment. Right? Because you need to see enough errors and then it's trial and error.
There's some work that has been done in the past where people use the SI and R as a way of
getting an idea on the quality of the channel.
The most notable problem you run into in that case is that the SI and R, let's assume for a second
that this is dominated by the received signal strength, the transmit rate is the transmitter is the
one that picks the rate but the receiver is the one that measures the received signal strength. So
the wrong node has the information.
So there's one I thought very good project which basically observed if you use RTCTS, the CTS
that can be used by the receiver to inform the sender what rate to use based on the R received
signal strength that it observes.
The problem now is, of course, RTCTS is very expensive. It's really not something that you want
to use. That's where we come from.
So what we basically developed is this algorithm called Charm, where a transmitter can learn
about the rate to use or get an estimate of the received signal strength at the receiver in a
passive way without actively RTCTS. And the way it does that is by using -- okay. This is going
to be interesting. Okay. We're going to see how this talk goes, because I modified this and it's
not here. So there's probably some stuff that was lost.
Anyway, the receiver basically uses channel reciprocity. Oh, there it is. Channel reciprocity to do
this. I'll explain in a second how it works. We can basically get an estimate of the received signal
strength without the RTCTS and then the transmitter can then basically dynamically pick the best
rate.
It's not quite as simple, but that's kind of the high level idea. So the way to look at this, this is our
equation. SI and R. It's the received signal strength divided by node plus interference.
What we want on the receiver is the SI and R. So we can now just -- some simple equations to
figure out how you do that. The received signal strength has to be measured by the receiver, but
using channel reciprocity you can actually estimate it on the transmitter. I have the next slide
shows this. Noise is largely constant. Something that can be measured by the receiver and it
can tell the sender what it is. Interference, we basically ignore. Because we have carrier sense
which should limit the effect of interference. So this is not a perfect solution, but it actually works
well most of the time.
So then the question becomes how can I estimate the received signal strength on the transmitter
that the receiver observed on the transmitter. And so it turns out this is actually pretty easy.
So the received signal strength is basically the transmit power minus the path loss and then you
have the antenna gains. So that's the top equation. The path loss is the one that you can get to
using channel reciprocity. So basically if transmitter A hears a packet from receiver B and it
knows these parameters and it can measure the received signal strength, it can estimate the path
loss of the channel.
That will also apply to the forward path which is what it is interested in and it can plug it into that
equation. So it actually turns out that you can measure everything, if you know the transmit
power by the receiver, which again the receiver can tell the transmitter. Turns out the antenna
gains don't matter because again that's symmetric. That folds out.
So it turns out that there are three parameters that are important. The path loss, which the
transmitter can estimate based on reciprocity. The noise and the transmit power and both of
these can basically be provided by the receiver.
So here's how kind of these pieces fit together. I have a transmitter and a receiver and a bunch
of other nodes. The transmitter and all the other nodes are sending packets. And the transmitter
overhears all these packets and for each of the nodes it will basically create a history of the
received signal strength that it observed by all these nodes.
Okay. So, for example, this would be the received signal strength history for the blue receiver as
it is overheard on the transmitter. Then using the transmit power and the noise figures, it can
actually translate that into an RSSI estimation at the receiver.
Okay. And then when it needs to transmit a packet at a certain point in time, it can basically use
this history here to kind of extrapolate what the received signal strength may be or the RSS -- the
SI and R maybe, I'm sorry.
So obviously this is a prediction in the future. This is not always going to be accurate. But it's
kind of an informed estimate. And then it can basically pick the transmit rate based on this,
based on a table.
Yes?
>>: Why don't you pick S and IR back on the X?
Peter Steenkiste: Well, you need the SI and R for the original packet, right? You need to pick ->>: Prediction rate. Obviously one packet -Peter Steenkiste: Yeah, you can. It turns out you don't need to conclude that. But because you
can use the AC to -- the AC is going to give you another data point here automatically. You don't
need to include it. You can use channel reciprocity to get it from the received signal strength of
the AC.
>>: But my point is like you only -- otherwise that would also work.
Peter Steenkiste: Yes, that would also work. That would work fine, too, yes.
>>: What we found in San Francisco, the estimates, the noise floor is pretty much the same
everywhere. But there was an ambient noise floor due to microwave ovens and other things far
away. You could represent sort of a noise floor, and that was different in each location. And that
won't show up in the path reciprocity condition.
Peter Steenkiste: So the path loss, the noise floor that you need here, each node in the system
periodically broadcasts the transmit power it uses and the noise floor that it observes. We do not
assume that the noise floor is the same every where for exactly the reason you mentioned.
So there's a lot more details here that I will not get into, because then this becomes a Charm talk
and that's not the idea. Eyor can tell you all the details. How about that? She'll probably do a
better job than I do.
So we took a lot of measurements, which means Eyor and Glen took a lot of measurements in a
lot of different environments. There's listed here. This is in homes, office buildings, library,
different environments. We compared it with the three algorithms that are deployed with the mad
WiFi driver and this shows you the performance. So purplish Charm does pretty well. Turns out
sample rate does pretty well too. It's a pretty good algorithm. And then the other two don't
always do well. Actually ONA looks pretty good here but has some problems. We don't always
do the best. So this is a case here where actually sample rate is better than we do.
So nobody is ever going to be the best also. Right? That's not how this works. But generally
speaking we actually do pretty well. We also ran experiments in the mobile environment. So
sample rate is really good. But it is a little bit slow in adapting, because it needs a lot of samples
to decide what rate to use.
And so here's Charm really does this very well. So you see sample does really well, too. But it's
very slow in going to the higher rates. So that's something that many people have observed.
This is not something that we observed. And a final point I want to make we also ran a lot of
experiments on the wireless emulator, most of which I'm not showing. But one of the interesting
things we can do on the wireless emulator we can create artificial hard traces. And one very
difficult case for any rate adaptation algorithm is hidden terminals. Because the channel is good,
right? But because of collisions that you can't avoid, you basically end up losing packets anyway,
right? And so I'm not going to go through the details here. But we can artificially create hidden
terminal situations on the wireless emulator and go and compare our algorithms. And we do
pretty well here. In part because we rely on the quality of the channel directly. And we don't rely
on the collisions.
This is not entirely true, and I will get back to that point later. So it is 99 percent true, one percent
not true. So I'll get to that one percent later.
So that's kind of a very quick high level overview of Charm. And so let's now talk about a
different project, and which is work that was done by Amy Lu who is actually defending her thesis
on Monday. This is something called Pro. And actually some people are here at Microsoft are
familiar with this.
So the idea is very simple. Suppose I have a sender forwarding, sending a packet to a
destination. Node here. The packet transmission fails. The traditional WIFI approach is to say:
Look, we will -- the source will retransmit the packet okay that we know of course. But, however,
there can be a bunch of nodes in the environment that are, in fact, closer to the destination and
have a specific better channel to the destination. They may have actually overheard the packet.
Now, those nodes may be in a better position to retransmit this packet rather than original source.
It may be for many reasons. One of them they have a better channel, so the packet success rate
is better. The other possibility is they may be able to use a higher transmit rate. So the efficiency
of the retransmission is better.
So that's kind of the idea. So we kind of have a source, send a packet. If the packet
transmission fails, one of these relays will notice that the packet was lost. Will realize that it has a
copy. And it will basically retransmit on behalf of the source.
Now, the obvious problem here is, of course, well how does the source know this is going to
happen? Also there may be five relays that overhear this packet. How do you make sure they
don't retransmit at the same time and have massive collisions. These are the type of problems
you have to deal with.
One of the things why this actually turns out to be a very potentially very interesting is that things
like channel fading and shadowing are very channel-specific. Right? So over time who has the
best channel to the source, which of the relays has the best channel to the source and has the
best channel to the destination is going to change. And it's going to move around. The best
one's going to move around over time and you really want for every packet pick the best one,
that's the whole idea.
Okay. So here's the idea. So we use -- this is really meant for infrastructure mode networks.
And you only use multi-hop if there's a transmission failure. The whole goal is that the
retransmission success rate goes up. And then the challenges here are marked in red. So you
need to efficiently identify and prioritize relays. You need to avoid increases in collision rates,
because now more people can be retransmitting these packets. And there's kind of an interesting
question of how you deal with fairness. I'll explain how that works in a minute.
So the way -- there's been some work in this area which, related work in this area that I'm largely
not going to talk about. But there's been work that has done similar things. And the way they
resolve some of these issues here is by explicitly coordinating between the relays.
So they say, somebody will say oh I have a copy of the packet I can forward it. And then they
kind of coordinate and then they do the retransmission.
Pro-on the other hand relies on the existing random access techniques that WIFI has. So there's
already a mechanism in WIFI where you have a back of window and nodes independently pick a
value in back of window to minimize collisions. There's also a notion of exponential of where this
back of window grows over time. So the way we basically do it is we basically rely on the existing
multiple access mechanism that WIFI has and the carrier sense mechanism to basically avoid
that we get too many collisions.
The second thing that we do is we actually rely on signal strength to prioritize the relays. And so
I'll explain how that works in a second. But all else being equal, we would really like to have the
relay that has the best signal strength to the destination, but the packet is the one that does the
forwarding. We don't want to have some random relay that may have a very poor destination due
to the forwarding.
Finally, turns out we can actually control fairness. I will explain that later. So here's how this
works. We basically have a background process on the left and then we have the process that is
used on after the packet failure on the right. The way the background process works is that every
node kind of listens in on traffic and basically uses RSSI as an estimate of the channel quality to
both sources and destination. So potential sources and destinations. And so they create the
spur node RSSI history which is not all that different from what Charm does in fact. Then what
they can basically use this RSSI history for, after some tuning which I will largely ignore for now,
they basically decide whether which source destination pairs they're good relays for which means
they have a pretty good channel to both the source and the destination. For those source
destination pairs they will periodically like once a second broadcast the channel quality they have
to the source and the destination. So other relays can overhear this. So that's the background
process.
So then when a packet transmission fails, a node will observe this because a relay will observe
this because it hears the packet but not the AC. So then it says, okay, there's a packet loss. And
then it says: Look, am I basically -- then it goes through its database and where it has
information about all the eligible relays and channel quality to the source and destination. And
then everybody goes independently in a distributed fashion through a process where they figure
out whether they're kind of one of the better relays.
And then when they do that, then they will also go through some kind of prioritization, where they
say: Look do I have the best channel to the destination. Then it would be a high priority relay or
do I have the second or third or fourth best channel. Then they're lower priority. Then they
basically decide whether they participate in the retransmission process. So that's at a very high
level how this works.
>>: How does this interact with Charm?
Peter Steenkiste: That's a question for later. This is a very good question. It's actually a hard
question.
So that's roughly how this works. So I'm actually going to use the picture to explain this in a little
bit more detail. So the process would be here I have four relays. Assume they both have a
reasonable channel to both the source and the destination. So they are qualified. And then
based on the periodic broadcasts, they may all observe that these three relays are actually in
pretty good position to do forwarding and this one isn't.
So this one withdraw, would not participate in retransmissions. These three would actually do,
consider themselves as good candidates for retransmission. One of the problems you now have
is that three may be too large a number because your collision probability goes up as you have
more relays.
And so now how do you trim down the set? Well, that depends on the likelihood that these nodes
receive the packets, overhear the packet. So depending on the quality of these channels, the
nodes are going to decide independently what is the best subset of people to actually participate.
So you want to keep it small but large enough that you have a good chance to get a good path to
the destination. So that's kind of the balance that we're looking at. Then the other aspect is the
prioritization.
Okay. So the way the prioritization works is actually also just by leveraging the behavior of the
WIFI in the sense that every node can basically rely on 80.211E which I'm sure some are familiar
with, but basically have different nodes, pick initial back of windows. Some nodes can pick a
back of window of, let's say, 16 slots. Others can pick one of 32 or 64 slots.
Obviously if you pick a smaller window, your chances of retransmitting first go up, right? Again,
it's statistical. It's random. So that's how Pro does that. It assigns different back of windows to
different nodes.
This is an experiment that I think will maybe bring some of this together. So I have a setup. This
was done on the emulator, a source and a destination. The relays are spaced 20 meters along
the line. And I'll show experiments where the source is fixed but the destination is placed near
different relays. So here's kind of the -- this is how it works. Very nice. And this is kind of the
results we get on the emulator. There are four graphs here.
There are graphs that only have attenuation. No fading, and then there's graphs with fading,
which are the red ones.
So what we're seeing is behavior that actually matches our intuition pretty well. If you have only
attenuation but no fading, it's a very static environment. And it turns out that Pro really doesn't
work except in the case when the source and the destination are almost out of range. Right?
Because in this case you're almost creating a mesh topology here.
So what you're seeing is that for nearby situations, Pro makes no difference. And here Pro
effectively becomes a mesh node that forwards the packet. But the picture is different for fading,
because what's now happening is we're getting a more dynamic aspect where some relays
overhear some packets and other relays overhear other packets. Now you're seeing that even
for nearby situations, which is still pretty far, what you're seeing is Pro can still help because there
are packets that just because of the fading, the destination doesn't hear but intermediate nodes
do hear.
So it kind of matches I think the intuition we have. It uses real hardware and emulated in this
environment. Some more results here the first two bars, the blue bars are Pro, let's ignore the
Pro optimal for now and then we have Charm at a rate adaptation, that was in part your question.
Sample rate has a different rate algorithm and then plain WIFI with fixed transmission rates.
This kind of confirms this. If you only have attenuation and Pro doesn't make much of a
difference. If you start to have fading then Pro actually does help and it does better than the rate
adaptation algorithms. And as the fading goes up, you really, relatively speaking, the gap also
increases.
So it matches your intuition. I'm actually going to skip the other results. We can talk about
fairness off line. And what I want to get to is we also ran experiments or Amy ran experiments in
two buildings on campus. This is one building which was Porter Hall. And so what she did was
she basically put up 10 laptops. Now what she did is for each pair of laptops, she used that as a
source as a destination, ran an experiment, and then the other eight nodes are relays.
Then she picks another source destination pair and the other nodes are relays. She went
through all the combinations. And so the results you get for this particular environment are
shown here. It's basically the cumulative probability distribution of the fraction of the nodes that
observe a certain through-put.
So through-put goes up left-to-right here. So there's a certain group of nodes here, a third of the
nodes have very good connectivity. Third of the nodes very lousy connectivity and a bunch of
them are in the middle.
These are nodes that are effectively out of range because of the environment. These are
probably have more or less reasonable line of sight path and these are in between. So what
we're seeing here is kind of three things. The first one is that for the good nodes Pro is in blue. It
overlaps with sample rate in this case. And so this is very good. It means that Pro doesn't hurt
performance, which is not necessarily a given.
Then what we're seeing here is that for the very poorly connected nodes it turns out that Pro
actually helps. This was never our intention, but it turns out that Pro can function as a range
extender. Right? Extends the range of the radio.
You can achieve better effects using or similar effects using mesh forwarding. This gap we can
talk about off line. This is a detail of the implementation. And then in the intermediate range
where you have an okay channel but not a great channel, that's kind of where Pro also helps,
right? By the way, these experiments were done in this building which has hard walls. It's
traditional office building. Also this was done at nighttime. So she also ran experiments in a
different building and this is the graph she got. So the thing that's interesting is that graph looks
completely different. Turns out that Pro almost always works. We never ever have the out of
range situation there. These results were actually taken during the daytime. There's a lot more
mobility in the building. In fact, this is in a very busy area of the campus.
There's a lot more fading here. So what we're seeing is as fading goes up, Pro basically helps.
There's also issues of line of sight that are different. But we kind of just want to give you a high
level picture here.
So this works pretty well. Interaction with rate adaptation is something you might want to make
part of the conclusion discussion. Okay. So the next two sections are actually shorter. So that
will go hopefully work. So this is actually fun. Let's do this.
So what we want to do is use transmit power control to reduce interference. This is the next
thing. This is work that was done by Chew Lu another student in our group. This is together with
[inaudible].
Okay. Here's kind of the NS view of the world. I have a transmitter. Suppose I have two other
nodes. This is my intended destination and this is the poor node that suffers interference from
me. What should we do? I think this is obvious, right?
If I reduce my transmit power then I can still reach my destination, but this node no longer suffers
interference. So the intuition here is that reducing transmit power is a good thing, right? Okay.
Very good.
Now, when I talk to people in E department or E he EC department they have a different story.
They have this SI and R equation which I already put up. When I look at that and reduce my
signal power, all else being equal, that's really not such a good thing because I'm moving to the
left on this axis. Right? And reducing my transmit power is a bad thing, right?
So now the research community is using both of these models. And so clearly somebody has to
be wrong here. Okay? So the question was: Who? Right? Well it's the hardware that decides
this. It's not us.
So we actually ran some experiments on the emulator. Very simple experiment. We have two
node pairs. I have a source and a destination and then I have an interfering source that I've
created a hidden terminal here. So they can't hear each other.
These guys send out a certain transmit rate that we change over time to create a curve like this.
And then I change the transmit power of the interferer to basically create multiple curves. So this
is basically the colorful picture at the bottom is what we end up with. Again, this is under highly
controlled conditions. There's no multi-path here. It's very clear channels.
But the thing that's very interesting is that changing the signal power at the interferer basically
moves that -- means that I shift graph by a fixed amount which turns out to be the same amount
that I change the transmit power of the interferer with. In other words, when I move from this
graph to this graph, I can basically do that in two ways.
Or from this point to this point. I can do it in two ways. I can increase the transmit power or I can
reduce the power of the interferer, right? So if I go back to my two models, this is the winner.
Because this effectively corresponds to this picture here.
There's some details about this graph that are interesting to talk about, but I will actually skip.
There are some issues here on why do we have this and so on. But those can be explained but
are somewhat orthogonal to this talk.
So basically what she did was -- actually, how long is the talk? Five more minutes, 10 more
minutes.
>>: Another 10.
Peter Steenkiste: 10, 15 minutes. So she basically then wanted to do transmit power control.
Again, there's been a lot of work in this area, fair bit of work in this area but most doing access
point transmit power control. So you're assuming you have no control over the clients and
access points control the power, which is a perfectly valid thing to do.
So she wanted to be more aggressive and wanted to basically say: Look, every link
independently adjusts its transmit power and the receive CCA threshold. So basically the starting
point for his work was a very simple observation, which is the following. I can take a transmit
receive pair where I have, let's say, AP1 talk to node, A P2 talk to a different node. Then there's
also interference that's created through the dotted lines there.
What I can now do is if I have control over both transmit powers, it turns out that you can try to
tune both of the transmit powers so these two transmissions can happen simultaneously,
because that's really what I want to be able to do.
I don't want these things to defer to each other. I want them to transmit independently. And so
using the SI and R equation and by ignoring noise, because most WIFI networks operate way
above the noise floor, so noise is not an issue.
It turns out that you will be able to tune the transmit power of AP1 and AP2 if this condition holds.
Okay? And then obviously the SI and R in both of these cases includes both the signal
transmit -- the signal strength at the receivers from both of the APs. So you can go through the
math.
It's simply based on the SI and R equation. So when you look at this, there's two conclusions. In
some cases you can't do it. But in other cases you can. And you calculate what the transmit
power is that you need to do this.
In fact, there's not just one value that is true. There may be multiple values that work. So then
what he did was he basically say okay how can I now use this?
>>: Wouldn't it be possible what exactly, when you say possible, is it just that you get reception
or is it better than sequencing or -Peter Steenkiste: So the goal here is to have the two transmissions happen at the same time.
That's the goal.
>>: Better than going one by one -Peter Steenkiste: I'm assuming it's better than doing one by one.
>>: Why do you assume that?
Peter Steenkiste: Why do I assume that? If I can do two transmissions simultaneously it's going
to take less time if I do one after another.
>>: But if you have interference.
Peter Steenkiste: The whole idea is that you pick these values so the interference doesn't
prevent reception.
>>: Arbitrary system?
Peter Steenkiste: What?
>>: Arbitrary system.
Peter Steenkiste: Let's keep that out of it. Let's assume it's fixed, small number of values. Turns
out this problem is hard enough without [inaudible] rate. But basically what we said is can we
basically improve spatial reuse and come up with an algorithm that builds on this to do this.
So it turns out you can. The way it basically works is that you -- oops. The way you do it is that
you basically build a pair-wise conflict graph for your network. And then you can use the equation
that I had before to remove links from this pair-wise interference graph. And obviously the more
links you remove, the more transmissions will be able to go on in parallel. Now, it's important to
realize that this is kind of a probabilistic optimization in the sense that it may be that you remove a
link between two transmitters who are actually transmitting to a specific destination. It may be
that they never want to do this, right? But if they do then removing that link will basically enable
that.
And so there's then also a distributed version of this algorithm that he came up with, which gets
quite tricky, because you need to have a fair bit of information sharing going on. It does not
create a global interference graph. Each node builds a local interference graph. So there is that
going on.
And it really is hard to explain in a short amount of time so I will not do that. But it can in fact be
done fairly easily. And then again he ran some experiments. So here there's a number of
different solutions. There's a manual solution that is shown with this being the individual
through-put. The orange bar is what you get if the two go on in parallel.
And then manual means manually optimized. You literally did an exhaustive search of all
combinations and came up with this. Here there's different combinations that don't use our
algorithm and here's our algorithm.
And the point is kind of that the yellow line here, there's actually very close to optimal in many
circumstances, right? It turns out there's a really big open question here this is for a particular
configuration. I can't argue it's typical. I can argue that it works. So we ran a bunch of them or
Che ran a bunch of them and they show similar results. This is for an eight node example. As
the density goes up it turns out you get improved benefits.
So this kind of transmit power control. So very high level. And I encourage you to go read the
paper. I can e-mail you the paper if you're interested.
A final point which is also work by Che is actually to go look at directional antennas. An
interesting variant on what I was just talking about. I think you know how directional antennas
work right? Turns out most have been outdoors where they're in direct line of sight environments.
Where it's entirely obvious optimization. So it's actually looking at an indoor environment.
So our initial observation was that you know this may not work because there's a lot of multi-path
going on and the interaction between multi-path and directional antennas is a little fuzzy. In fact,
it's still fuzzy for us. We're still learning over time here.
But we were actually able to at least artificially create a scenario in our head that said: Gee,
maybe indoors is a nice place to use on directional antennas because we can do interesting
things here using the multi-path. So this is a scenario. Suppose here on the left I have two
senders and I have two receivers.
Unfortunately, the receivers are close together. And so we have interference that is created by
the other sender. We can't have simultaneous transmission, even with transmit power control.
You can now say wait a second because of the multi-path the two senders can be directional
senders. They can pull in a different direction, which is not the most obvious direction. And you
get something like this. Right? So now this is a cartoon, right. I don't know if it ever works but at
least on a cartoon level this is good.
If you can't do it at the cartoon level it's never going to work. So that's kind of what we did. So he
did some experiments which I will not show where he actually experimentally tried to determine
where this was ever the case.
And, indeed, there are cases where, if you describe this path as the max SNR path, where the
max SNR path was not optimal, if you started to have multiple directional antennas.
So he then basically came with up with a solution where said look, if I now assume an
environment with directional antennas in the APs, but plain omnidirectional clients, how can I
basically use directional antennas.
It turns out if I go back to my transmit control approach even though we don't change the transmit
power here, the way you do that is by building a conflict graph and by using this conflict graph to
determine who can transmit at the same time.
And we're relying in our topology here on the fact that these APs are connected through a wired
network so we can coordinate them very easily for scheduling purposes.
Now, the problem here is that because of the directionality, the nodes in the conflict graphs are
not just the links but also the direction in which an antenna is pointing. So the conflict graph size
explodes. The number of nodes in the graph goes up by a factor of K, which is the number of
directions of the antenna.
And so it turns out that building this conflict graph is very expensive. It's an order N times K
squared problem. So building the graph is very expensive. Where N is the number of APs and K
is the number of directions. There's a lot of experiments to build this graph explicitly.
So Che said: Well this SI and R model worked very well for transmit power control. Let's try it
here. Now the idea is you're assuming that the SI and R at the receiver is going to be a
pair-wise, assuming pair-wise interference assumption can be basically calculated by the
difference between the signal strength by the intended transmitter and that of the interfering
transmitter.
And now if I can basically calculate those, or measure those, I can estimate the quality of the
channel this way. And so it turns out that the nice thing about this is that the complexity of doing
the measurements becomes NK, rather than NK squared.
And so you're basically relying on SI and R model to be able to do this. So he built this. And I
will actually not go through the details. But this actually works pretty well. It turns out that there's
another challenge here which is that you need to reduce the complexity of the scheduling
problem.
And so this is not really a networking problem. Okay. So that's kind of how that worked. Now,
okay. I've talked about four topics. And so all of them actually relied in some way on RSSI
measurements, right? Which is kind of not something that we envision when we started this
project. This is something where when I needed to put a talk together I said: Wait a second.
There's a lot of mentioning of SI and R in these slides. So how does that work.
Most of these techniques seem to work. You can question the value of an RSSI reading or not.
But it actually kind of works pretty well. And this is not entirely a surprise. If you talk to people in
E departments, they have an unwavering faith in the SI and R model. So they've been working
on this much longer than I have so you need to have some faith here.
So this is a common theme. The interesting thing if you look at the four projects -- I hope I've
given you enough details to appreciate that -- turns out there's some big similarities like the SI
and R model and RSSI readings, and also there's big differences between them. This is a list of
some of the big differences, and I'll discuss some of them in a little bit more detail.
First thing that I want to point out is that all of the four projects were implemented on WIFI
hardware. But these are not WIFI tuning projects, because they really sometimes do very weird
things, right? These are not standards compliant things. Charm is actually the only one that fits
within the WIFI standard.
Pro obviously having other nodes retransmit on your behalf, I think as a lot of people in IEEE
would be offended by this and possibly justifiably so. Here we're really not making any
assumptions about what the network is. This is transmit power control. Doesn't have to be WIFI.
Doesn't matter what the protocol is. It's protocol independent. DIRK uses a TDMA protocol with
centralized scheduling. So there's no carrier sense used, for example, in this so this is also not
WIFI.
So these are very different types of projects. But one interesting thing is that first observation
here is that these four projects actually use SI and R and RSSI readings for different reasons.
Pro and Charm to a large extent use it for agility. Very quick feedback, right? In contrast, these
two projects use these readings rather than probing, because it reduces the search space in the
optimization. So it's really maybe fundamentally there's all reducing overhead here. But there's
kind of a different motivation here. This is an agility argument to be able to very quick, and here
it's really reducing the cost of the learning about the environment that's being used. There's a
different reason for that.
The other thing that is very different between these, which as I think is kind of interesting is they
operate on very different scopes and time scales. So Pro to some extent Charm operate on a per
wireless link, source destination pair. Charm actually is clearly per source destination pair. Pro
needs to include a bunch of relays so the scope is very different. Pro is the most adaptive of the
four. It's on a per packet basis that it optimizes. Literally every packet could be relayed by a
different node. Charm is kind of on a burst of four or five packets, I would say. Be it hand
waving. But short term and very quick optimization. These are slow. These are all adapted at
the second level, right? Because -- and the reason is simply that they need to coordinate a fairly
large number of nodes in order to be able to optimize this, because of the interference issues that
need to be dealt with. So the scope here is roughly, from a node, kind of two hops away, right,
roughly speaking. That's the set of nodes that needs to be coordinated.
So we have two nodes, two nodes and the nodes in between. A node and up to two hops away.
So the scope is very different and also the time scale matches the scope to some degree. You
can be much more agile if there's only two nodes involved.
The other thing that's very different between them is that the level of precision of the SI and R
estimates that you need is very different. Charm needs by far the most precise information. If
you're off by Charm you're either going to have a different -- the rate's going to be wrong, right?
Pro actually, it doesn't matter very much it turns out. We only use this to select the relays and we
typically have several anyway. So if one of them is way off base it doesn't really matter. So we
only need very rough estimates.
Here turns out to be not particularly sensitive either, because it's one of these things where we
opportunistically, you know if your transmit power control doesn't always avoid simultaneous
transmission, then that's okay. You're no worse off than you were before, right? It's not very
sensitive.
Here, DIRK is very sensitive. This turns out to be very tricky because you don't have carrier
sense to save your hide effectively. It's a very different usage of that information and sensitivity
to the precision.
There's very different ways in which they deal with interference. So the Charm and pro-basically
rely on the existing mechanisms in WIFI or in whatever algorithm protocol you use. Transmit
power control estimates the interference and adjusts the carrier sense for that. I didn't talk about
this at all but there's an algorithm to pick the carrier sense once transmit control has been done it
accounts for that then still uses carrier sense because using the optimized carrier sense
threshold.
Here we make sure, we assume that the scheduler has eliminated interference. It's a very
different model again. This is really why the accuracy of the information needs to be pretty good
or conservative, right?
And then there's something that I have not talked about because this is a detail, okay? But the
fact of the matter is your estimate of the SI and R will sometimes be wrong. You can be as good
as you want but it will sometimes be wrong.
And the problem that you have is that sometimes these failures can be very systematic. Right?
You can just have a cart that's completely uncalibrated or weird and you don't want to be in a
permanent problem corner, right.
So it turns out that all of these four algorithms have a way of accounting for this. So there's a way
where they will basically, if something goes wrong in the estimates, they kind of have a fail safe
behavior where they will fall back to a different mode of operation or will they adjust thresholds so
that they automatically get out of that bad spot.
Pro and Charm basically do this by having the threshold tables that are used adjusted based on
observations. So there's threshold tables that tells you which relays to use or which transmit
rates to use, and these are -- there's an initial starting set of tables, but overtime these are
adjusted based on the observations. In part to calibrate to the hardware that's used and in part
for weird environmental effects.
Transmit power control has an entirely different set of problems which is that if you start playing
with your carrier sense threshold, and then the receive threshold is often pi to that, you can have
nodes that become deaf and so you need to deal with that. So there's a set of different
algorithms that periodically relies on periodic high power broadcasts and periodically increasing
that threshold to be able to participate in the protocol.
And then DIRK relies on this by using feedback. So if a node observes high packet rates, it will
report this to the scheduler and the scheduler will adjust the schedule to avoid these bad links.
But it turns out that this is a detail, but a lot of the time in developing these protocols actually goes
into getting this fail safe behavior, right? Different algorithms need to be used for different
protocols.
So conclusion. So I talked a little bit about channel emulation. I always love to talk about
wireless emulator. I think it's a great project. And so I presented four techniques which just
happened to all use RSSI readings to estimate either received signal strength or SI and R. So
these optimizations use that information but the optimizations are in fact very different in how they
use that information. It's my main point.
We also need to account for and deal with inaccuracies in these estimates. That turns out to be
actually kind of hard, right? And then there's the issue of how you combine these techniques,
right? It's very interesting. We have a little bit of experience in combining Charm and Pro. And it
turns out you can actually, we actually have a multi-rate pro that uses Charm for rate
optimization. And it actually works pretty well. You can do that. It turns out -- it's easy to prove
to you that one does not dominate the other. You need both. So I can be in an environment
where there are no relays, right? I better have rate adaptation, right? Or I can be in an
environment where I really have very high fading or something like that, and rate adaptation is too
slow. The changes in the environment are too fast and then Pro turns out to work because it's
very opportunistic on a per packet basis. It turns out it's easy to show that you need both.
Our multi-rate Pro combines the two but actually you could call it a lazy combination of the two
systems. And lazy in a good way here. Like very little work, right? So the two largely operate
independently.
The only change that we've made is that we've made rate adaptation on the source a bit more
aggressive, because there is a relay there that can back you up if you have a failure. That's kind
of the only change we've made. There's one other detail that's actually not that important. But I
think there's a big issue here. How do I combine DIRK with transmit power adaptation. That's a
great topic to look at. So hopefully we'll be able to do that at some point. So that's the end of the
talk.
Any questions?
>>: Is that available for our use in terms of hardware/software, how part of a service?
Peter Steenkiste: It's a service thing you can access over the Internet.
>>: Okay.
Peter Steenkiste: And so there's a website. There's some documentation that we're always
improving and you log into this. So if you've used MLab, very similar model.
>>: We use it for ->>: Yeah, I didn't know how you used it.
>>: Coordinate it from here.
Peter Steenkiste: Right. The biggest hurdle we had with that was you were using Windows.
That was the biggest hurdle. Now we support it, actually. Because we used MLab software it
supports Windows automatically. Eyor doesn't have to come in the middle of the night and boot
manually.
Any other questions or are people getting hungry for lunch?
>> Ranveer Chandra: Let's thank the speaker.
[applause]