>> Jie Liu: Welcome, everyone. It's my pleasure to welcome Souvik Sen from
Duke University. Souvik is graduating. And his research has been focusing on
the PHY layer of wireless communication, both for improving the communication
quality as well as using it as an interesting way to sense what's around the
wireless devices.
So today he will give a talk on his research, Rearchitecting Wireless Systems
Using PHY Layer Information. Thank you.
>> Souvik Sen: Thanks for the introduction, Jie. It's a pleasure to be here at
Microsoft Research. As a student I've seen so many things that have come out
of Microsoft Research. It's a honor to be able to give a talk here. Thanks a lot.
And I see that the weather is changing, and it's probably going to become worse.
I hope my talk is also not in that direction. So hopefully -- hopefully you'll go out
of my talk with a good feeling.
So today I'm going to talk to you about how we can rearchitect wireless systems
using physical layer information.
So wireless is becoming ubiquitous. If I say wireless and if you go back five
years ago, you'll probably think about your wireless router or your laptop, which
has a wireless interface, or your phone which connects wirelessly.
But now if you look around, you see that so many of these devices are becoming
wireless. And this includes your wireless speaker, your wireless mouse, your
iPads and I ports, your wireless streaming device, for example the Apple TV,
your wireless car receivers. And we are also seeing wireless coming to medical
devices.
So with all this, demand has skyrocketed. And we have seen a 25 times
increase in wireless usage over the last five years. And Cisco is predicting that
this explosion is going to continue.
So from a network service provider's perspective, how does this become a
reality? And they are spending billions to solve this problem. We don't see
unlimited data plans anymore as our good old days. Now these providers are
trying to solve the data crunch problem. They are forcing us to pay per byte.
FCC is trying to solve the problem. They're calling for better use of the available
spectrum. So, in other words, the problem is not of spectrum alone but
underutilization of the available spectrum is a major issue.
And we, as researchers, have looked at this problem for quite some time. So if
you look at our communication community, we have made significant leaps in
achievable physical layer capacity by using techniques like MIMO, OFDM,
coding, et cetera. And then if you look at our networking community, we have
made advancements in distributed algorithms and protocols scheduling,
coordination, and things similar to that.
But then if you bring them together, this is what you get. The MAC layer or even
the network layer throughput is only a fraction of the physical layer bitrate. Now,
why is that the case? Particularly in the case of wireless, because of the layering
separation between the MAC and the physical layer, lot of useful information is
lost.
So if you can co-design these two layers together, it's possible that this useful -this lost information can help us in solving this challenge.
Now, this is not a new observation. In fact, researchers have recognized the
need to share information across layers. But this observation was instantiated
mostly using simulation and port experiments. There was no experimentation
platform available, and, hence, it was difficult to build practical working systems
and understands practical implications from this direction of research.
Now, when I started my PhD four years ago, software radios were gaining
popularity. And since then they are changing the landscape of wireless systems.
These devices essentially gives us a transparent physical layer and enables
networking researchers like us to experiment in a more holistic manner.
And recently we are seeing this trend to continue. Chip set designers like Intel
and Atheros are giving us more and more wireless physical layer information to
play with in the higher layers.
So if you think about broadly, we as network researchers, we have been working
with abstractions, and we have treated the physical layer as a black box. And we
have tried design protocols and primitives around this black box. And we can go
ahead and improve performance only to a certain extent if you work with the
black box. At some point you have to open this black box, look deeply and come
up with more subtle abstractions that can be used in the higher layers.
These software radios gives us a transparent physical layer and intervals that
kind of experimentation in a holistic and sometimes in an unconventional
manner. And our intention has to be -- has been to contribute in this space.
So in our research, we find that physical layer information and capabilities can be
used -- can be used to solve challenges in wireless networking. And these
problems includes contention resolution, interference management, rate control,
and enterprise networking.
And as we are doing this research, we also find it interesting that physical layer
can be viewed as a sensor. And the sensing information can be used in the
application layer helping emerging areas of mobile and pervasive computing.
So in the later half of my talk, I'll talk about how we could use physical layer
information to address challenges in indoor localization.
Let me first start with wireless networking. At this point, I would like to state that
we'll instantiate our ideas through WiFi purely from a platform consideration. But
some of the core ideas are generalizable to other wireless technologists.
So let's start with the WiFi functionality called distributed channel contention.
Now, contention is a very general problem. It happens whenever there is a
resource and multiple parties are interested in sharing or accessing that
resource.
In case of wireless, channel is a shared resource. Why? Let's -- let's think about
that through this example. Let's say AP1 is your router at home who wants to
talk to your laptop R1, and AP2 is your neighbor's router, which wants to talk to
its client R2. Now, since these two access points are nearby, they cannot talk
simultaneously. Because if they do, R1 will not be able to hear any of them. And
this is analogous to two people talking together.
If I'm talking to you and someone else starts talking in the middle you will
probably not be able to understand any of us. Now, of course you can control
who talks when. But that is not possible in a distributed system like setting like
WiFi. So let's see what WiFi does.
WiFi implements a academia called randomized backoff. And the idea is that
aisle select some random number and you'll select some random number, and
whoever has the lowest random number will win the contention. Let's see how
that works in this example.
Let's say AP1 has selected a random backoff value of 15 and AP2 has selected a
random backoff number of 25. Now, observe that these access points know
what random numbers they have chosen. But at this point they do not know is
the random numbers of other access points.
So to do that, WiFi says let this these access points count down from the
respective random numbers. And the idea is whoever hits zero first has the
lowest random number and, hence, he's the winner of contention. So let's see
how that works here. AP1 is going to count down from 15. And AP2 is going to
count down from 25. AP1 has a lower number than AP2, and, hence, it will hit
zero before AP2. It will know that I'm the winner. And it will go ahead and
transfer its packet. While AP1 was transferring, AP2 will sense AP1's
transmission and freeze its backoff value at 10.
Now, let's say AP1 has finished its transmission. It has maybe more packets to
send to its client. So it will say select a new backoff value. Let's say that is 18.
AP2, on the other hand, will start from the previously frozen backoff value of 10.
And in this instance, since AP2 has a lower backoff value, it will hit zero before
AP1. It will win the channel, go ahead and transmit its packet. This is great, and
this is what is running in all our laptops now.
But there's a problem. The problem is during all those red intervals of backoff,
the channel has to remain idle. And that causes a considerable amount of
channel overhead. And to give you some perspective of how much overhead we
are talking about, at 54 Mbps, almost one-third of the time, the channel has to
remain idle due to backoff.
So if you look back in our community, we have been trying to solve this overhead
from contention resolution for quite some time. And this goes back to 1971,
where the first ALOHA systems were first proposed.
And still we see a lot of research to optimize the wastage from count-down. So
we can think about contention estimation, where researchers have proposed that
we can pick lower versus larger backoff values, depending on how many access
points are there in the network.
Now, contention is difficult estimate, particularly in case of mobility. I might be
here now, and I might go out in the next second. And whatever information you
have regarding me and my tracking and topology might be still.
Of course you can control who transmits when. But that is -- that requires
synchronization. And it does not scale well in QWERTY networks like WiFi.
So let's take a step back and think about what we are really trying to solve here.
Backoff is not fundamentally a time domain operation. It's a concept which says
that let people choose random numbers and whoever has the lowest random
number will win the contention.
Now, WiFi implements this concept in the time domain by counting down in time.
Since time and frequency are interrelated, we ask the question, can we
implement backoff in the frequency domain? And if it can, are there any benefits
in doing so?
So we find a score in current WiFi physical layer which documents OFDM. Now,
OFDM is a physical layer design in which the wideband channel is divided into 48
narrowband data subchannels called subcarriers. And this is done purely from a
physical layer motivation because it copes better with fast frequency selective
fading.
We find a MAC opportunity here. We can pretend these OFDM subcarriers as
integers. And I'll propose system called Back2F, backoff to frequency, which will
try to emulated randomized backoff in the frequency domain.
So before I make you more confused with this complicated slide, let's move on to
the key idea. Let's say, as before, AP1 wants to talk to R1 and AP2 wants to talk
to R2. Like WiFi, we'll let them select random numbers. So AP1 has selected a
random backoff number of six and AP2 has selected a random backoff value of
34.
Now, WiFi will make them count down from these numbers. Instead, we'll make
them transmit these backoff values on their corresponding subcarrier. So AP1
will transmit a signal on its six subcarrier because its backoff value is six. AP2
will transmit a signal on its 34 subcarrier because its backoff value is 34.
Now, observe yet these access points do not know what backoff values other
access points have chosen. So that is why they cannot conclude whether they
are the winner. To do that, we'll introduce a listen antenna. And let's focus the
listen antenna and think about what these access points will see at the listen
antenna. So for AP1 it will see that six is active because AP1 itself is transmitting
on six. But apart from six it would also see that 34 is active because AP2 is
transmitting on 34. AP2, on the other hand, will see a very analogous figure on
its listen antenna. It will see 34, its own backoff is active. But apart from 34, six
is also active. And that means some other access point have a lower backoff
value. Give that lower backoff gets more priority, it will know that it has lost the
contention.
AP1, on the other hand, will look at its listen antenna and see that six is the
lowest backoff value it can find, is the same as its own backoff value, and, hence,
it will know that it is the winner. It will go ahead and transmit its packet on all the
48 subcarriers by taking the entire band.
Now, observe we have a -- we have a difference with WiFi here. And one of the
difference is on your listen antenna, by looking at your -- what you are seeing of
a listen antenna, it is possible to know what backoff values we have chosen in
the network. And can we leverage this farther? We can. And let me show you
through this example how.
Let's say that a black access point is seeing these backoff values on the listen
antenna. So the red spike is its own backoff number. It has chosen a backoff
value of 12. And the black spikes are backoff values of other access points in its
neighborhood. But since active subcarriers imply backoff chosen by other
access points, by looking at this listen antenna, this access point will know what
is rank in a sequence.
Since the red spike comes after two other spikes of other -- of other people, it will
know that it -- its rank is three. And if other access points are seen as very
similar picture on the listen antenna, it's a global consequence and, hence, this
enables a back-to-back TDMA like transmission.
Now, this is -- this sounds good. But is there a benefit from frequency domain
backoff versus time domain that is implemented in WiFi? We believe this is
because while conventional packet transmissions can take 250 microseconds,
average temporal backoff can take about 100 microseconds. Frequency backoff
will happen in orders of one OFDM symbol, which is four microseconds.
>>: But what [inaudible] problem in your previous slide?
>> Souvik Sen: We don't. We don't. So backoff is -- has been designed for
coordination. So if you think about WiFi, backing off in the WiFi, it was designed
for coordination. It was not designed for green terminal. So we have not tried to
solved the green terminal problem in this -- in this project.
You have tried to solve the coordination problem in this project. We'll talk about
how we can solve the green terminal problem in the next project I'll talk about
today.
>>: [inaudible].
>> Souvik Sen: Sure.
>>: So how about a transmission from the mobile [inaudible]. Do you have
these [inaudible].
>> Souvik Sen: [inaudible].
>>: So you assume that AP is actually contending with each other and use an
additional [inaudible]. So if that happens on a mobile device, it also [inaudible].
>> Souvik Sen: Yes.
>>: [inaudible].
>> Souvik Sen: Yes. Yes.
>>: And this seems to be not very efficient use of [inaudible] as a resource for
both power and error time. So if you [inaudible].
>> Souvik Sen: So, we are actually complementary with MIMO. If there is a
MIMO internal, you should probably use our system more. Because we are
doing contention while there is no transmission going on. So there is a second
antenna, backoff happens when there is no transmission. So you can use these
two antennas intelligently to reduce the coordination overhead, and after you had
won the contention you can transmit just like MIMO transmitter transmits uses
both the antennas.
So we are trying to use the MIMO antenna more intelligently.
What was your second question? Sorry?
>>: [inaudible].
>> Souvik Sen: Okay. So but this sounds too good, right? I mean, there should
be -- there should be some problems here. So what are the side effects with
this? And let's look at them.
Firstly, will there be lot of collisions with this scheme? And observe, this is a
pertinent question because we have only 48 numbers to choose from. Because
there are 48 data subcarriers. If there are 50 access points or choosing numbers
from one to 48, there's a high probability that two of them will choose the same
number and, hence, they will try -- both of them will think that they are the winner.
They will cause a collision.
For example, here the red and the green access point, they have both chosen a
random number of two. They do not know that some other access point is on the
-- on that same subcarrier. They will go ahead and transmit in parallel causing a
collision.
So to solve this problem, we always prescribe a second round. And the idea is
the winners of the first round will come to the second round and they will choose
another said of random numbers. So the red and the green access points, who
are the winner of the first round, came to the second round. They chose a
number of three and five. And depending on what numbers they choose, will
give them priorities.
Now, this will reduce collisions because the number of winners in the first round
will be less. And, hence, the number of people who are contending in the second
round can -- will also be less.
But there is still a problem. The problem is that if you have only a few access
points in the second round, TDMA that we proposed earlier will not be effective.
Why? Because the number of access points participating in the TDMA depends
on the number of access points in the second round. If you have only one
access point in the second round, that's no good, because a [inaudible] is
essentially one.
You really want five or six of them in the second round so that they can all
transmit back to back like TDMA without doing another round of backoff.
So we optimize for TDMA also. Instead of the red and the green access point,
we also bring the purple to the second round. And how do you do that while
keeping in the interest of time? But this is done using local decision. These
access points observe how many subcarriers are active and what kind of collision
probability is fine for the network. And depending on that, they decide whether
they should come to the second round and pick backoff values.
The idea is we want as many access points in the second round as possible,
given that it does not cause a lot of collisions. So in the second round, by looking
at the listen antenna, these access points will know their rank in the sequence.
And this will enable a back-to-back TDMA like transmission.
For example, the red access point will know its rank is two. It will wait for only
one packet transmission. And then without doing another round of backoff, it will
transmit its packet in a back-to-back fashion, saving channel air time.
So let's see how this compares with WiFi. Because of WiFi we do one backoff
per packet. So if you think about this sequence, purple is going to back off and
then transmit, followed by red and then green. In case of Back2F, we'll do one
frequency backoff followed by back-to-back packets in a TDMA fashion. And by
cutting down all those red intervals of time domain backoff or WiFi, we are trying
to save channel air time.
But whatever I've told you until now assumes that these access points, the
purple, red, and green can hear each other. And they have a -- they have a
similar picture on the listen antenna. But there is not the reality. In reality you
will have scattered access points and you will have multiple collision domains. I
might be able to hear Jay, and Jay might be able to Atul [phonetic], but I may not
be able to hear Atul.
So this -- I'm showing you an example which is analogous to what happens.
Let's say that the blue and the purple access points are in one collision domain.
That means they can hear each other. And the purple, red, and the green
access points are in some other collision domain. They are able to hear them.
But the blue and -- cannot hear the red or the green access points.
Now, let's say that these are the backoff values that I've chosen. Okay? So if
you look at them carefully, green, purple, and blue's order are in sequence. Now,
let's think about what happens when green is transmitting in when green is
transmitting, purple has to wait for green because it has a lower priority. But then
blue has to also wait for purple to start and finish transmission. It has a lower
priority than purple, it can only start transmission after purple has accessed the
channel and transmitted.
This is no good. If you are the blue access point, you will sit there, you will not
see anything in the channel going on because it cannot green, and it will think
why am I not being able to transmit although there is nothing going on? This is
like a lost transmission opportunity for me. Yes?
>>: [inaudible] right? So purple we'll believe is number two, purple, green,
consensus, right, and the blue guy we'll believe is also number two through that
blue circle, right? So the two of them will essentially transmit at the same time.
>> Souvik Sen: The ranking is relative, right? So purple knows both blue. So
essentially blue doesn't know green, but it knows that its ranking is after purple.
>>: But I thought in the TDMA mode this says I know my ranking is two.
>> Souvik Sen: Right.
>>: So I'm going to wait for a packet and transmit.
>> Souvik Sen: Yes. But you will not hear the green packet.
>>: Right.
>> Souvik Sen: Because you are in a different ->>: But if they don't transmit, purple is also transmitting because purple also
make a local decision on number two I'm going to transmit -- I'm going to wait for
a [inaudible].
>> Souvik Sen: Right.
>>: The two of them were transmitting at the same time.
>> Souvik Sen: No. Unless you -- both of you are here, the same packet.
So in this example, for example, when green is transmitting, red will -- blue will
not count that as one packet, right? Because blue cannot hear green.
>>: Right.
>> Souvik Sen: It only knows that purple is the one I should wait for. Purple's
transmission is the one I should wait for. Right? So purple -- after purple starts
and finishes transmission then blue will co-participate.
>>: It only knows the time. It knows I'm the second one in line.
>> Souvik Sen: Right.
>>: [inaudible] purple. It doesn't monitor the purple guy.
>> Souvik Sen: Yes. Yes. Absolutely not. Yes.
>>: The purple says I'm also the second guy in some other ->> Souvik Sen: Other ranking, yes.
>>: Right?
>> Souvik Sen: Yes.
>>: And they will essentially transmit at the same time, won't they?
>> Souvik Sen: No. Because when purple is saying that he's the second guy,
he's looking at someone else and hence saying that I'm the second guy. Right?
So that person will transmit. When that person is transmitting, blue will not count
that. Okay? So after that purple is transmit, and when purple is transmitting,
then blue will know, okay, so this is the first transmission that I was waiting for.
And then blue will transmit.
So this is -- this is an order that is happening implicitly.
>>: Probably take it offline, but I probably missed something in there.
>>: So [inaudible] this point, right, let's from it about the red one and let's
assume you can only have the purple, the blue and the red -- and the green,
right? So let's say the middle one becomes number one. And then the other two
guys, assume that they are number two in the order. But they don't hear each
other, so they don't know they're number twos.
>> Souvik Sen: Yes.
>>: So number one transmits, then both coverages are going to transmit, right?
At the same time.
>> Souvik Sen: Oh, yeah. So that is true. That is true. And that is what the
order says, right? Essentially green knows that there is one person, one person
ahead of me. And that is purple. So after purple finishes, green will transmit.
And the same thing will happen for blue also. Yes?
>>: [inaudible] right?
>> Souvik Sen: Depends on where the receivers are. So if the receivers are in a
different place, if green refer is here and blue's receiver is over there, it will not
cause a collision. But if the receivers are in the middle, they will cause a
collision. This is very similar to a green terminal collision. So we are not solving
the green terminal collision problem here. Because backoff -- backoff is not
designed to solve the green terminal collision, it is designed to solve the
coordination problem. That is what we are trying to address.
So we have the same problem as WiFi has in terms of green terminals. Okay.
So let me move on. So here we have a problem that blue will keep waiting for
purple and hence when green is transmitting, it will not transmit and it will keep
thinking that there is nothing going on in the channel, why am I waiting for
someone else?
So observe WiFi does not have this problem. And while WiFi does this, blue, as
a WiFi access point, will wait for purple for a while and if it sees that purple is not
transmitting, it will keep counting down and it will go ahead and transmit it back.
So our Back2F solution is to emulate WiFi. And let me show you through this
chart here how we do that. So let's say initially everyone does a frequency
backoff and they have these backoff values. If I'm participating in that backoff
and if I'm the winner, it's my turn, I can go where I'm transferred. After the
transmission, I'll pick a new backoff value if I have more -- if I have more packets
to send.
Now, if I'm not the winner, and if I'm waiting for someone else to transmit, I will
sense the channel for a while. I will listen for that person to transmit. And if I see
that that person is not transmitting, I can go ahead and transmit my packet.
Now, let's see how that works in this example. Initially green is the winner and,
hence, it will transmit. While green is transmitting, blue will wait for purple and
listen for a while. It will see that there is -- purple is not transmitting. It will lock
off from this backoff, will do its own frequency backoff, and it will see the channel
is still idle, it will go ahead and transmit.
Now, after green has finished its transmission, observe that red is waiting for
purple. But red cannot sense blue. So red will also listen for a while for purple to
transmit. Purple will not transmit because it is waiting for blue to finish. And,
hence, red will do its own backoff and go ahead and transmit. And this will be
followed by purple's transmission.
Now, the thing to note here is that if you look at the sequence of backoff values,
that sequence and the way it was executed are different. And it's the same
sequence that will happen in case of WiFi. We are trying to do the same exact
thing. We are trying to emulate WiFi here. But we are also trying to cut down on
all those red intervals of backoff [inaudible] that WiFi has.
So given I have explained to you our key ideas, let's move on to performance
evaluation. The two key questions that we need to answer here. First, can
Back2F detect subcarriers reliably? Because if we cannot, then it's not possible
to know what backoff value other access points have chosen, the schedule will
be all wrong and, hence, we might have lot of collisions.
And second, if we canning detect subcarriers reliably and do frequency backoff,
how much throughput gain can we have over WiFi?
So to answer the first question, we did an evaluation on USRP-based testbed.
And to answer the second question we evaluated using laptops and assess
points at 65 locations. So let's try to answer the first question.
Observe there is a practical challenge here. If I'm an access point and I'm
transmitting my backoff value on my transmit antenna, since my listen antenna is
also on me, there will be a high self signal from the transmit to the listen antenna.
And because of that, it may not be possible to understand who else is
transmitting on the listen antenna.
And let me show you through this example how that happens. So here I'm
showing you a frequency spectrum on the listen antenna. So I, as an access
point, am transmitting on a subcarrier of number 45. So that is why you see a
high self signal on 45.
There are other access points who are transmitting on subcarriers between 40
and 60. From this figure it's not possible to say what particular subcarrier values
they have chosen. You know that there are people who are between 40 and 60.
But you cannot really tell what numbers they have chosen. And this happens
because the self signal from 45 overflows into the distance subcarrier.
Now, to solve this problem, WiFi uses 64 point FFT to get a frequency spectrum
at any receiver. We find that if he use a high point FFT, it's possible to resolve
these frequency better. And, hence, from this diagram you can see that although
the self signal is high, we can clearly see where the other peaks are and from
that find out what subcarriers are active and, hence, what backoff values other
people have chosen in the network.
So using this I present here our subcarrier detection performance. So here on
the Y axis I'm showing you detection accuracy as I increase the distance in
subcarriers from the self subcarrier on the X axis. Essentially the first point on
the X axis is most vulnerable to the self signal. And to help you read this graph
better, we have a robust subcarrier detection at 14 dB. And what is this 14 dB?
This 14 dB is essentially the signal strength of a weak access point at my listen
antenna while my transmit antenna is busy transmitting my own backoff value.
So if we can detect subcarriers, how much throughput gain can we have over
WiFi? So here I'm showing you on the Y axis throughput gain over WiFi as I
increase the number of access point on the X axis. And as you can see that we
have higher gain at higher rates. And why is that the case? In case of WiFi the
whole idea of backoff is like a fixed cost. If you increase the rate, the amount of
air time you will take for the packet will reduce. But the overhead is fixed and,
hence, the backoff overhead is higher, relatively at a higher rate. We are trying
to reduce the backoff overhead, and, hence, we have a higher gain at higher
rates. Yes?
>>: [inaudible].
>> Souvik Sen: Sorry?
>>: Is there only downstream traffic in this experiment or [inaudible] are also
sending?
>> Souvik Sen: In this -- in this experiment, this is a -- in this particular graph,
exactly this graph, this is upload traffic.
>>: Upload traffic?
>> Souvik Sen: Yes. [inaudible].
>>: Since your description is all in terms of APs, I [inaudible] so the APs
[inaudible].
>> Souvik Sen: Right. So both the class and the access points can do backoff.
That is ->>: [inaudible]. So you are assuming that clients have a [inaudible].
>> Souvik Sen: Yes.
>>: And in that case, what is the downside of using the 256 point FFT?
>> Souvik Sen: So the downside of -- there is a trade-off. Is good thing about -about using backoff is that you save sensing energy. Essentially when you are
trying to send, send find if the channel is idle or not. All right. So you save some
energy there.
But you also spend that energy on using that higher point FFT. So it's -- I do not
have a good answer of whether that energy trade-off -- how it will play off.
>>: You haven't done measurements with how much higher end [inaudible].
>> Souvik Sen: No.
>>: You just seem to know what [inaudible].
>> Souvik Sen: Sorry. I did not ->>: Can you just do some kind of cancellation [inaudible] because you know
what you're transmitting?
>> Souvik Sen: Right. Right. So we can do that. But I'll add some more
complexity into the system.
So we started off just -- we started off not by thinking how can we do this without
cancelling. And apart from cancellation to answer your question further, you can
use the system without using 256 point FFT also. If you just use 64 point FFT,
you can use every fourth subcarrier. And that will give you a very similar
performance in terms of subcarrier detection. But then you have lower number of
numbers to choose from.
So you may -- you may increase collision. But that is possible to resolve by
increasing number of rounds we are doing.
>>: So does 256 FFT mean that you are [inaudible] channel more frequently or
is it just you are doing more cancellations?
>> Souvik Sen: So, we are taking long time.
>>: Long time to find something ->> Souvik Sen: No, we are just taking more time.
>>: So how do you [inaudible]? There has to be a continuous monitoring ->> Souvik Sen: Sorry, I could not hear you.
>>: So you have a single antenna, you continue to signal like three signals
[inaudible] right?
>> Souvik Sen: Right.
>>: [inaudible] and you also have to do some sort of backoff [inaudible] so you
[inaudible] how do you quantify the [inaudible].
>> Souvik Sen: No. But to answer your question, you need -- you need to do -you need to activate the second antenna when you are transmitting on the first
antenna your backoff. So if -- if you are not -- if you are not -- if you are not in the
backoff round, we need not turn on the second antenna. So only when you are
doing the backoff you need to turn on the listen antenna or the second antenna.
>>: [inaudible] just wanted to get this [inaudible].
>> Souvik Sen: Sure.
>>: Did you actually have 50 quote/unquote access points [inaudible] two
antennas and generate these ->> Souvik Sen: No. So this is -- this is not a text-based result, this is a
trace-based result. So we didn't have 15 [inaudible] talking to each other. We
don't have that -- we didn't have that much results.
>>: Simulated results.
>> Souvik Sen: It's not simulated, but it's trace based.
>>: Trace based.
>> Souvik Sen: So essentially we went and took measurements in different -- in
four different links. And we characterized what the interferences are. We
characterized what the subcarrier detection capabilities are, from USRP. And we
used all the information to find out what the gains can be.
>>: But just wanted [inaudible] like the level of detail [inaudible] in this
experiment. So your [inaudible] does not require like [inaudible] like transmit,
receive, turn around?
>> Souvik Sen: So we are -- we are -- so we have not -- so it's a negative -- in
our case we have not implemented that system. But we are taking care of the
fact that turn around time is what the turn around time of a typical hardware is.
So essentially if you think about sift duration, that when you send a packet and
then you have to send an act within nine microseconds, so we are taking care of
-- taking care of the fact that you need nine microseconds for sensing and turning
around from the receipt to the transmit mode. So all this information has gone in
this block.
>>: I see. So -- but the system was not implemented [inaudible].
>> Souvik Sen: That nine microsecond system was not implemented.
>>: So what was implemented?
>> Souvik Sen: So the subcarrier detection is happening on the USRPs.
Collision detection is happening on software radios. All traces are really traces.
So we went around and find out links. So essentially we transmit or links and
found that what the [inaudible] how two links interfere. So we took all the data.
And from there we did this trace-based throughput evaluation.
So the previous graph was a text-based graph. This graph is a trace-based
graph.
>>: So and this was like you basic took like just measuring the WiFi environment
[inaudible].
>> Souvik Sen: Yes.
>>: And then ->> Souvik Sen: Yes.
>>: And you had 50 active clients in your ->> Souvik Sen: No. So I was saying that we don't have 50 -- 50 nodes. So we
took -- we took links. So essentially there are 50 -- so we took one client, one
access point. And from there we took -- for that link, what is the rate -- what is
the inter-- what amount of interference that link is going to have from all other
links that is there in the interference. So we measured -- we measured that as
well.
And we throw all this information to the trace-based emulator.
>>: So [inaudible].
>> Souvik Sen: Sorry?
>>: [inaudible].
>> Souvik Sen: Yes. Yes. But that -- but there are parameters that goes in from
the real world. As in how much can you detect from the subcarrier? What is the
real interference level? What is the real read that is supported in the links.
So we could not -- essentially, essentially the software based systems can -- it's
hard to do a quick turn around of nine microseconds. So that is why it's hard to
build a real system and take evaluation results here. We actually have done that.
But the turn around time is such that it's hard to compare with WiFi, which
requires a quick turn around.
So we build a system. But to show the results along with WiFi we did this
trace-based [inaudible].
>>: So in your experiment [inaudible].
>> Souvik Sen: Sorry. I cannot hear you.
>>: So do you have 58 piece in the same domain in the trace that you collected?
>> Souvik Sen: In this graph, yes. But we have -- we have -- we have done
other graphs in the paper which have looked at multiple collision domains what
happens. So they're essentially -- as I was saying, there are 65 location and at
which we collected all this data. And from that, that spans the entire building.
And for -- that is why for those we have multiple collision domains a and real
traffic.
>>: I'm still trying to understand. So if [inaudible].
>> Souvik Sen: So imagine, imagine this graph is wrong. Imagine the X axis
says number of clients and not number of access points. Okay? And imagine all
these clients are trying to sends information to the access point. So they -- and
imagine the fact that they are in a one-collision domain. A single-collision
domain. So they can hear ->>: [inaudible] you collect a trace? Is that the [inaudible].
>> Souvik Sen: For this graph, yes. For this particular graph I'm showing you,
yes. Not in general.
>>: [inaudible] for generating this ->> Souvik Sen: So this particular graph was called 10 bitrate. Essentially ->>: [inaudible].
>> Souvik Sen: Transmitted, yes.
>>: [inaudible] the backoff [inaudible] highly dependent on [inaudible]. If you
have [inaudible].
>> Souvik Sen: So whenever -- whenever -- of course. I mean, any amount of
throughput gain you have or you can show depends on what kind of traffic you
have.
>>: This is basically like a [inaudible].
>> Souvik Sen: Right. This is basically showing that how much throughput gain
can you have when everyone is trying to transfer. But, but this also shows that
when you are transmitting, when you are transmitting a packet, how much -- how
much -- how much of channel usage are you going to improve by using Back2F?
Okay. So to summarize Back2F contention resolution is a very general problem.
So saying it happens whenever there is a single resource and multiple parties
are trying to access that resource.
In case of wireless, channel is a shared resource. And we are seeing several
proposals who have tried to optimize the wireless channel access overhead.
They have tried to optimize a time domain backoff operation of WiFi.
Now, backoff we find is not fundamentally a kind of an operation. It's a concept
which says that people will choose random numbers and whoever has the lowest
random number can transmit. Back2F shows the feasibility in the frequency
domain. And it tries to alleviate the longstanding overheads of backoff.
So let's take a step back. At this point. We started off to reduce the gap
between MAC layer throughput and physical layer bitrate, and we found that if we
can solve the challenges in contention resolution, this gap can reduce.
Now, the other problem that we can solve to reduce that gap further, wireless
collisions is one such problem. Why? Because why there is a collision, the
physical layer is transmitting at the best bitrate possible. But at the MAC layer
the packet is corrupted and hence your effective throughput is zero, contributing
to that graph -- gap.
Let's look at the [inaudible] of a wireless collision how it happens when it
happens. Let's say T1 and T2, these two laptops, are associated with the access
point R. And they want to talk to R. Let's look at a sequence of transmissions
with time on the vertical axis.
T1 wants to talk to R. And let's say it starts talking to R. T2 cannot hear T1. It
also decides to talk to R. It starts in the middle of T1's transmission causing a
collisions at R. Now, T1 knows nothing about this collision. It will keep
transmitting. And after the packet is -- the transmission is over, it will wait for
acknowledgement from R. Of course R is not going to send this
acknowledgement because the packet did not go through and, hence, T1 will
keep waiting until the ACK timeout. And beyond that we will know that the
packet did not go through and, hence, it will retransmit the entire packet.
Now, we believe that this is not efficient. It would have been better if T1 aborts
right after the collision. Why? Because there might be some other transmitter T3
who was waiting for T1 to finish his transmission. And if T1 aborts his
transmission in the middle of the packet, T3 can come in and transmit to some
other access point replacing the fruitless transmission from T1.
Now, if you think about a more mature physical layer like the wired networks, this
is exactly what happens. The transmitter keeps -- senses the channel as it is
transmitting. If what it senses and what it's transmitting is not the same it says
that the -- that there's probably a collision at the receiver, it goes ahead and
aborts his transmission. This is called collision detection or CSMA/CD. And we
have believed as wireless researchers that this is not feasible to do in the context
of wireless networks.
Now, observe that collision detection is like prevention. Prevention is hard to do
in the context of wireless and, hence, we as wireless researchers have tried to
cure collisions, essentially tried to do something about the collision after it has
happened.
Now, we tried to break off from the convention and ask the question, can we
imitate CSMA/CD or collision prevention in the context of wireless networks? So
in the next few slides I'll talk about a system called CSMA/CN, which will try to
achieve collision prevention in the context of wireless networks.
Let me do that using this example. Let's say a transmitter TX wants to talk to the
receiver RX. And I'll call the data transmission signal S1. Of course the collision
happens at the receiver and, hence, the receiver needs to detect it. Now, let's
say a collision has happened at the receiver. The transmitter is a wireless
transmitter and, hence, it has no idea about this collision. So the receiver has to
send some feedback to the transmitter. We'll call this collision notification signal
S2. Now, observe this is not enough yet because the transmitters transmit
antenna is busy transmitting is data transmission signal and, hence, it will not be
able to find the collision notification signal.
So to do that, we'll introduce a listen antenna. Now, at the listen antenna, the
transmitter can find the notification and can go ahead and abort transmission,
preventing the collision. This sounds good, right? But it does not work.
Why? Because there is a high self signal that will transmit to the listen antenna.
And because of this -- because of this strong self signal, S1, it's going to be so
high at your listen antenna, that in presence of S1 it will not be able to -- it's going
to be hard to understand the presence of S2.
So when we face this problem, we didn't find anything that we can borrow from
related work. And, hence, we started doing lot of experiments in our USRP
testbed. And the observation we had is that if we can suppress S1 at the listen
antenna somehow, we'll be able to detect the collision notification or S2.
And the idea we had is that S1 need not be a unknown signal. We can very well
send S1 from the transmit antenna over to the listen antenna over Y and
because -- if we can do that, if S1 can become known, it is possible for us to
suppress S1.
Now, in this setting let's think about what we have at the listen antenna. At the
listen antenna we have two gallons. One over wireless, which has the transmit
signal as well as the collision notification signal. And one over Y which has the
transmit signal only. So if you subtract, of course you will get S2. But then you
will also get a lot of noise. Why? Because S1's copy over wire is only a
approximate of the wireless copy. Because wire and wireless propagation is not
the same.
So because of this noise, it will become very hard to decode S2. Now, when we
face this problem, we had an idea. And the idea was S2 need not be an
unknown signal for this transmitter. The receiver can very well send its MAC ID
as the collision notification. And because the transmitter knows this MAC ID it
need not decode for it. It can correlate. Now, correlation is essentially a
mathematical operation in which it's possible to detect the presence of a known
signal, S2, in presence of even a high background signal, S1.
So if the transmitter is correlating for the collision notification, if there is any it will
have a correlation spike. It will know that there is a notification. It will abort the
transmission, preventing the collision.
So let's see how much throughput gain can we have by preventing collisions in
our network. So to do that, we have a 10 node USRP testbed deployed at Duke.
And we found that across topologies on average we had a 40 percent gain in
throughput over WiFi. And this was particularly by preventing collisions.
Of course, this number 40 percent will depend on traffic and topology. But
CSMA/CN essentially reduces the cost of collisions. And these enables
networking researchers like us to be more aggressive in our particular designs,
not consider collisions as a big problem to direct [inaudible].
>>: [inaudible].
>> Souvik Sen: So ->>: Gave us 40 percent based on that [inaudible].
>> Souvik Sen: So this was a -- this was a USRP testbed. The traffic was a
constant bitrate traffic. And the topology was essentially nodes trying to talk to
each other across the geographical setting. So there was no -- there was no
particular setting. We just distributed nodes around.
And essentially the CDF here, each dot corresponds to each link we had in the
topology.
>>: So what is the [inaudible].
>> Souvik Sen: So this is essentially like WiFi. So whatever WiFi does is
essentially like WiFi.
>>: With capture?
>> Souvik Sen: Without capture.
>>: Without capture. Yes.
>>: [inaudible] you can't really do the comparisons.
>> Souvik Sen: Say that again. Sorry?
>>: The USRP you can't really do -- it doesn't [inaudible] it's very hard to have a
full fledged implementation of WiFi MAC, right? So [inaudible].
>> Souvik Sen: So this particular system, as I was saying like the previous
system, we have implemented everything that we talked about. But it's
semiautomatic scaled down in terms of time. Essentially the problem with carrier
sensing on USRP or the problem of doing realtime things on USRP is that the
turn around times are big. So you cannot do nine microsecond. But it's possible
for you to do 900 microseconds.
So essentially that is -- that is -- that is what we did.
>>: Are all the factors the same when you make this comparison in your power
output, you're [inaudible], your gain of your [inaudible] are those all the same ->> Souvik Sen: Yes.
>>: [inaudible].
>> Souvik Sen: Yes.
>>: Okay.
>>: I'm curious what you do if a receiver [inaudible].
>> Souvik Sen: You need -- we don't -- we don't attempt to do that. So
essentially if you are -- if your client does not have a second antenna -- are you
asking that what do you do?
>>: The receiving side.
>> Souvik Sen: Okay. Okay.
>>: You know that two guys are transmitting ->> Souvik Sen: Right. So essentially by looking at the physical properties you
can know. So the one we looked at specifically is essentially a symbol of a
constellation single level property. So -- and to give you a very brief, brief
overview of that, if you think about basic constellation level dispersion, it take -- it
accounts for both fading and interference. So if you look at fading, there is one
property that holds for dispersion.
Now, as you are resending a packet, if there is an interference in the middle of
the packet, you will see that the dispersion property or the dispersion distribution
suddenly changes or the entire band. And from there, it is it is possible to know
that there is an interference or there is a collision happening.
Okay. So with this, like we summarize here CSMA/CN, CSMA/CN tries to imitate
collision detection or prevention in the convex of wireless networks. So if you
think about wireless researchers, we have tried to cure collision before.
Essentially tried to do something to recover after the collision has happened.
We believe that prevention is better than cure and CSMA/CN we believe is a first
step towards this direction. So with this, let me summarize the wireless portion
on my talk.
>>: [inaudible] can you place this stuff in context [inaudible].
>> Souvik Sen: So two things. One is this was done before the full duplex.
>>: I meant more of a technical light. What are the key differences?
>> Souvik Sen: So if we have full duplex today, it will be more useful. But the
key, the key idea that require -- that is key in this project is correlation.
Essentially if you have full duplex, if you are trying to decode for a collision
notification in band, that's going to be less robust than if you can do correlation.
Because correlation is more robust to another signal going in band. So ->>: So what would be simpler in the sense like -- I mean, yes, like correlation is
easier, but correlation also carries less information than decoding does.
>> Souvik Sen: Right. But in this case you just need one [inaudible] of
information. You just need the information whether the receiver is being able to
receive the packet or not.
>>: But is the circuitry still good?
>> Souvik Sen: The correlation circuitry is always there in a WiFi. Because you
have to correlate to receive the preamble or to understand there is a beginning.
Packet. So the correlation circuitry is already there in a WiFi.
>>: It's already there, but is it simpler than like [inaudible] can you have a
cheaper notification system ->> Souvik Sen: Yes, absolutely. Correlation [inaudible] required much less,
much less of the [inaudible] systems than a full decoding circuitry. Yeah.
Because you can do correlation at the single level. I mean, you don't have to do
the other things that you need to do beyond just the single like demodulation,
decoding and things like that to do the actual decoding or to get bits out of it.
Okay. So with this let me summarize the wireless portion of my talk. We find
that physical layer information and capabilities can be used to solve the
challenges in wireless networking. And if you can do that, we can reduce the
gap between MAC layer throughput and physical layer bitrate.
So beyond wireless capacity, can physical layer formation still be useful? And as
we are doing this research, we found it very interesting that the answer is yes.
Wireless physical layer can be viewed as a sensor. And if you can use the
sensing information in the application layer, it will aid imaging areas like mobile
and pervasive computing.
So now I'll talk about how we could use the sensing information from the physical
layer to help indoor location. So indoors we see something called multipath.
Essentially where every a wireless transmitter broadcasts a signal, it transmits
the signal in all directions. So before coming -- before the signals arrive at the
receiver, the signals gets reflected by your doors, windows and walls before
coming to the receiver.
And these reflections affect a physical layer parameter called channel frequency
response. Now, since the channel frequency response essentially depend on
these reflections, if you go and measure the channel frequency response in
some other location, you will find that these responses are different essentially
because their reflections are different.
So if these responses are different in different location, that's good news in terms
of localization. Because it's possible to use these responses for location
signatures. You can go and measure these responses around this building and
create a database. And later, when you go and give me a response, I can map
in the database and tell you where you are.
But even before I can do that, what is the stability of this response in a particular
location?
>>: [inaudible].
>> Souvik Sen: What is that? Sorry?
>>: I mean, how many transmitters are there, just one?
>> Souvik Sen: Yes. So it's possible to do without transmitter. More transmitter
means more information, and, hence, you can do local evaluation ->>: [inaudible] challenge because your response is location specify?
>> Souvik Sen: Right.
>>: It's location, transmitter specific, right?
>> Souvik Sen: Yes. So even before we can do that, what is stability of this
signature -- or of this channel responses? Because this might be -- this might
vary all the time. Because frequent responses at a given location may vary over
time. But what we really need is to find a detectible pattern from which we can
extract the location signature.
So to understand that, we tried to do lot of experiments using Intel [inaudible]
cards. And we find that at a single location in many cases these responses are
clustered as I'm showing you in the figure here. So there are 20,000 response
this is this figure, but as you can see, they are very much clustered.
Now, of course it is not necessary that you will have only one cluster in one
location. In the same location here on later -- in a later time, you can see another
cluster. Okay?
Now, if you look at these responses, observe that they have both amplitude and
phase, because they are essentially complex numbers. If you take one
subcarrier from that, and you plot them in the complex, this is what you get. We
observe that this -- these clusters are essentially Gaussians. And by looking
these Gaussians, they have a mean and a variance. And this cluster mean and
variance can be used as location signatures.
But this can be done only if you have a few clusters. Because if there are a lot of
clusters, it will be hard to identify all of them and create the database.
So to understand that, we need measurements at ->>: [inaudible] clusters?
>> Souvik Sen: No. So that is what I want to talk about right now.
So to understand that, we did measurements over a week at 30 locations. And
I'm showing you a CDF of number of clusters we could find at these 30 locations.
And as you can see, that most of these locations, with a if you clusters, up to five.
But then there are some locations which has a lot of clusters, up to 19. And this
may mean that at these locations it is not possible to use these clusters as
location signatures.
So to understand that more, we ask the question do all these 19 clusters occur
with the same frequency? And we did measurements, and we found that it's not.
Rather if you take a -- take only a few dominant clusters, these clusters are
dominating -- are dominating so much that you only need to understand alone
these few clusters. And these other clusters can be treated essentially as noise,
and you need not learn all of them. So -- yeah?
>>: [inaudible].
>> Souvik Sen: Sorry?
>>: Were there any [inaudible].
>> Souvik Sen: Yes. I mean, this one week trace essentially was taken at a
Duke engineering building where there are classrooms and people are going -coming ->>: [inaudible].
>> Souvik Sen: Yes. Yes. We let them run continuously. It was a natural
involvement.
So essentially if you can learn this for -- for clusters and you can make a -- build
a map of it, it's possible to provide locations. Now, I'll skip the neck details, but I
would like to say that our system PilLoc could pinpoint paintings at the Duke
museum, with 90% accuracy.
Now, while we did that, we are really excited about this project. And we thought
that this might be one of the ways of -- to solve the challenges in [inaudible]
localization. So we started talking to lot of consumers of this technology. The
Duke museum, of course, but also to a Wal-Mart. And Wal-Mart came back and
said that this is what they need. Essentially what they need is anytime anywhere
localization.
However, the problem with PinLoc is that we need to do war-driving. You have
to go and measure these responses, these clusters before you can even give
location service. Wal-Mart or consumers in the space are not willing to do that.
So we took that learning and we came back and we asked the question, how can
we do -- how can we design an indoor localization system without doing any
war-driving? So I'll do the same here. But before I move on, I would like to say
that please remember that these PinLoc spots or the PinLoc locations can be
used as landmarks. Essentially if I -- if you go there, and if you give me your
WiFi signatures, I can tell you exactly where you are. Yes?
>>: [inaudible] the challenges [inaudible] so is it -- is it consistently across
hardware, like if I have hard drive with your card and then like crossing those
code differences or [inaudible] matter or not?
>> Souvik Sen: So it's hard to guess. So we did -- we used four cards. But it
was the same vendor. Because Intel 5300 was the only card we could find which
was giving this kind of information.
So across vendors if the intended design is different, it probably might be
different. But that is also -- it is possible that it is -- that is easy to model. And
there are some recent work which shows that that is possible. So ->>: How would you model that?
>> Souvik Sen: I don't know. I have no good answer there. But there are some
recent papers which shows that if you have one card versus the other card, it's
possible to model how these frequency responses would look with a different
card given you know what the response is with one card. Yeah. So you have to
model the difference.
And if that is possible, then that -- what you are asking is -- can be easy.
>>: Okay.
>> Souvik Sen: Okay. So let's move on. So we asked the question, how do we
design a truly unsupervised indoor localization system? And we thought that
maybe we can borrow from other localization. Because other localization has
been very mature. If you think about other location-based applications you see
several of them in the iPhone AppStores and the Android marketplace. So as
you are scaling over outdoor location -- outdoor location-based applications, one
technique that we found interesting was called dead reckoning. And I would like
to go for you using the slide how dead reckoning can be used to provide location
in an outdoor setting.
So let's say you are that user, and you go over the Microsoft building in this U
shape. Now, I can track your location by using that accelerometer and compass
on the phone because accelerometer will give me your displacement, and
compass will give me your direction.
Now, of course these senses are noisy, and hence my estimated walking trail of
U will not be the same as the ground truth. It will deviate away over time.
But then outdoors, we have GPS. And it's possible for us to correct these
walking trails at this known GPS location. Let's see how. Let's say we started
from the -- almost the same starting point. We walked a bit. We cancelled the
GPS and found actual ground truth location. And we corrected the dead
reckoning error. We did the same at a later point. And if you keep doing that,
observe that the correct dead-reckoned walking trail is similar to the ground truth.
So observe that these known GPS locations are like landmarks. So outdoors in
a nutshell, it is possible to dead reckon to find the location and correct this
dead-reckoning error at landmarks.
So we thought maybe we can bring this technology indoors. Accelerometer and
compass, in a way different sensors work reasonably indoors, but GPS does not
work. But observe all we need are a few landmarks. Essentially locations which
have something unique about them so that whenever you go at this location we
know exactly where you are.
PinLoc locations are like landmarks because whenever you are at a PinLoc
location by looking at your WiFi I can say exactly where you are. That's like a
landmark. But WiFi is only one sensor of the phone. If you think about all the
sensors that are there on the phone, it might be possible to come up with more
landmarks. Essentially locations which have a unique sensor fingerprint.
And as we get thinking, we -- our intuition said that that is possible because of
the inherent diversity in the way people move and the buildings are structured.
And I would like to share you some of the ideas here.
If you look at accelerometer, if you think about elevator, we find that there are
these complimentary bumps in the accelerometer space. And this happens in
the start and the stop of deliver. Whenever you go up the staircase, the manager
of the acceleration has a high variance.
If you think about sounds, whenever you are at a drinking fountain or you're
taking coffee from a coffee machine at a cafe, you see that there is a unique
sound signature that shows up.
And also we can find landmarks in sensor domains that we cannot perceive as
humans, for example magnetometer. So this is a lab at Duke -- at Duke, this
computer lab. And essentially these computers are electrical devices. And they
affect the magnetic field. So whenever you go and stand at the door of this
particular lab, you will see that a unique magnetic signature shows up. And if
you can learn that, you can use this as signature.
And we find that even no sensor reading is good for us. So this is a basement at
our engineering building. And it looks very creepy. So, you know, creepy is that
if there is one location in this -- in this basement where if you go and stand you
will not get any kind of wireless signal. No WiFi, no 3G. Forget 4G. Nothing.
So if you are trying to find someone and you know that that person is in the
building and you are not being able to connect to him wireless anyhow, there is a
notion that goes around in our lab that either he's with Romet [phonetic], talking
to him, or he's at that location. So essentially what I'm trying to say is that even
no sensor reading can be a signature.
And if you keep thinking, there can be several that we can come up with.
But the hard question is how do we locate these landmarks or these locations
with unique signatures without doing any war-driving? And we tried to do that by
using dead reckoning from outdoor localization.
And let me go through this example and discuss how. Let's say in this building
map there is a computer lab, and it causes some unique magnetic fingerprint at
that location, at the door of the building. So I will dead reckon you from the door
of the building, one known location.
So whenever you go there and either giving your sensing information to the
cloud, the cloud will know that you are at a unique location because whatever
you're seeing on your phone is very different from other location that you are
sensing. The cloud will not know where this location is, but the cloud will know
your dead reckoned estimate.
So when I go there, the cloud will know that both of us are at the same location
because we are seeing the same sensing signature. But the cloud doesn't yet
know where the landmark is. It knows only our dead-reckoned somewhat. As
more and more people goes there, the cloud will have a confidence about this
particular landmark. It will still not know where the landmark is. It has its
dead-reckoned estimate.
Now, this dead-reckoned estimate can be independent because all these people,
they might approach a particular landmark from different directions. And the
sensing -- the sensor noise can be independent. And by law of large numbers,
the cloud consider take the centroid as the dead -- of the dead-reckoned
estimate to find where the landmark is.
So in our experiments we find that within two man hours our landmark local error
was within a meter. So we can find these landmarks. It's possible to dead
reckon and provide localization service indoors.
So in our the way different we took a recursive approach. Initially we know only
one landmark. That's the door of the building. So if you want a location, I'll give
you a location by using dead reckoning using that existing one landmark. And of
course the localization error initially will be very high.
But then I'm going to use all the sensing information from your phone as well as
others. If it's possible to find a unique sensor fingerprint, we'll find the landmark
location using the dead-reckoned estimates. And if you find landmark, we'll add
it to the landmark list.
Over time, as more people goes in, you will see that more landmarks will come
up in geography and that landmark localization error will improve. As landmark
localization error improves, dead reckoning will also improve. And as dead
reckoning improve, the landmark localization error will also improve in our
recursive loop. So in the steady state, we expect to see that the localization error
will go down. So to understand that, we did experiments in our Duke University
and also a shopping mall. And we found that the localization error reduces over
time as more of these landmarks are identified and the localization error of these
landmarks go down.
And the steady state after two hours of the mean localization error was 1.63
meters.
So to summarize the localization portion of my talk -- yes?
>>: I don't understand. Why is this better than war-driving. It's like with a
systemwide war-driving I can just, you know, do it once and -- or do it once a
year or something and forget about it. But with this system now I have no idea
what it's going to do and how much time it's going to take to actually give me the
right result.
>> Souvik Sen: So ->>: And there are issues around error propagation as well. Two locations end
up having the same signature. I don't know how dead reckoning is going to
behave because you're going to just keep on creating the error in a convoluted
manner.
>> Souvik Sen: So let's take your comments one by one.
>>: Yeah.
>> Souvik Sen: If you think about war-driving, it's hard to image a similar
whether you will do only once a year. You have to do it periodically, given the
amount of changes. Okay? So if you just think about this system uses some
component of war-driving, let's say you are doing WiFi war-driving-based
localization. The system will automatically learn that. It will know that this
landmark was here today. If the landmark goes away tomorrow, it can't
understand that. So it will -- it will automatically log that.
Also, to answer your second question about whether the errors will propagate -sorry, I -- can you ask that again?
>>: It seems you're assuming a lot about the nature of the error, once you're
doing this unsupervised learning that you are. One is like initially you may not
even know if a location has unique signature. You may not just have ->> Souvik Sen: Right.
>>: Just, you know, it's just data coming in.
>> Souvik Sen: Right.
>>: And two locations could have the same signature or the signature of a
location may not be unique by itself, depending on computers were on or off, for
instance, in the lab.
And so it's unclear to me how you are actually, first of all, dealing with the issue,
and the other is tell me why it's necessary the way different but in the end like it's
hard to understand what happens with the way different because of possibilities
like that.
>> Souvik Sen: Okay. So ->>: And not to mention the uncertain of knowing whether the system is actually
properly trained.
>> Souvik Sen: Yeah. So it's hard to understand -- so if you look at the system,
and if you take a snapshot of the system, it's hard to understand whether the
system has converged or not. That is true. Because it will not -- you don't have
the information that where the landmarks actually should be.
Now, essentially you are taking a multi-dimension approach. If two locations has
a very similar landmark fingerprint, it's possible that these two locations have a
different WiFi signature. So if you add WiFi along with that, they will be different.
>>: Well, now you're -- that's a contradiction right there, right? That's like two
locations have the same signature, you are saying they are not. That's not the
case the way different.
>> Souvik Sen: Right. Now, if within the WiFi -- within one WiFi area, if two
locations have the same signature, we'll not use them. Because it's ambiguous.
>>: But you don't look at two locations.
>> Souvik Sen: We do not know the two locations unless in geography the
dead-reckoned estimates are giving two different clusters. See, if locations are
so nearby that these dead-reckoned estimates are giving you one big clusters,
we will not know that. But if the dead-reckoned estimates are such that they are
two different clusters will know that these are two different locations and will not
use the landmark as that particular instance at that point. Because that is
ambiguous.
And the good thing about -- the good thing that I like about the system is that,
see, essentially you are trying to find a few landmarks where you can correct the
error. Right? If your dead reckoning is good enough, you essentially just need
some few landmarks. And --
>>: The way different just that. I mean, you are -- by taking this Android for
instance you are assuming something about the nature of the dead-reckoned
error being completely advised. And I'd be surprised, I think because the way it's
structured with the layout that dead reckoning actually gives you a zero bias by
which -- by that, I mean, like that it's equally likely to be anywhere at the 10
answers it gives you. My intuition would be that dead reckoning is systematically
wrong.
>> Souvik Sen: Okay.
>>: Because people walk around the way different is not like -- it's not
completely random.
>> Souvik Sen: So the error -- I -- the error might be on bias because the error is
essentially coming from the sensor error. The sensors are unbiased because if I
take your -- take my phone and you take your phone and we calculate the dead
reckoning somehow, using some algorithm, because our sensor's unbiased you
will see the dead reckoning may also be unbiased.
So even if you walk at a location you can -- I and you walk at a location from the
same exact direction using the same exact path, the dead-reckoned estimate
that the cloud will compute, is the way different will commute will be different
because the sensor is -- the sensors are different. The sensors are unbiased.
>>: The way different benchmark analysis of dead reckoning the way different
unbiased errors around the location?
>> Souvik Sen: So we have not the way different but we have taken -- we have
taken snapshots. And we have tried to convince ourself whether they are
unbiased. And it seemed to us that it was unbiased.
>>: By just looking at that?
>> Souvik Sen: Yes. Yes.
>>: So if you are dead reckoning, so you have the displacement the way
different the sensor, and also you would have to turn the way different so in
between turns do you assume you're following a straight line?
>> Souvik Sen: No. No. We look at the accelerometer and the compass and
gyroscope to do that [inaudible].
>>: So in between turns?
>> Souvik Sen: In between turns also. So ->>: If the paths are [inaudible].
>> Souvik Sen: Yes. It will -- we will account for that. We are not assuming that
all the paths are straight or 90 degrees.
Okay. So to summarize the localization portion of my talk, WiFi fingerprints is a
well researched area in the indoor localization. So if you look at the other
sensors, there are also fingerprints in these phone sensors that we have. If we
can bring them together, it is probably possible for us to help solve the problems
of indoor localization.
We tried to do that. And we tried to solve the problem of war-driving by bringing
dead reckoning from other localization.
So with this, let me summarize my talk. In my PhD, I tried to take a cross-layer
approach to bridge the gap between networking and communication. In terms of
wireless networking, I find that physical layer information and capabilities can be
useful in solving existing challenges and problems in wireless.
And as I was doing this research, I also found it very interesting that the physical
layer in wireless can be viewed at the sensor. And the sensing information can
be used to build building blocks and concepts which can be used in applications
in the application layer. And the localization project that we talked about is one
such building block that we worked on.
So in terms of future work, I feel that correlation can be a very strong primitive in
terms of communication networking. And I would like to talk about why.
If we think about wireless, in one direction we have signal in the physical layer.
In the other direction you have decoded bits. If I said decoded bits you probably
mostly think about data bits. But data communication also needs coordination,
and, hence, we have a lot of control bits.
Now, these control bits are and overhead, and, hence, we have seen lot of
protocols and research that have tried to reduce the overhead of the control bits.
Now correlation sits between signalling and decoding. It's neither signalling nor
decoding. It's in the middle. And it gives us a cheap method of sending
feedback or information in presence of data communication.
So if you can take those control bits and move them from decoding to correlation,
it might be possible for us to save bandwidth. And CSMA/CN or collision
notification that I talked about today is one such protocol in this domain. We
have looked at how can you save energy by using correlation? And going ahead
I would like to ask the broad question, how do you redesign protocols using
correlation as a primitive?
Now, more broadly, I would like to augment sensing with wireless. So if you think
about sensors on the phone, there are a lot of them. And if you take a
multi-modal approach, it's possible to create more opportunities and solve
problems on phone as a platform.
And we also see that whenever a new sensor gets added to this piece, the
opportunity space increases drastically.
Now, apart from these sensors that we know, accelerometer, compass,
gyroscope, there are these sensors which are also there on the phone,
essentially the wireless physical layer. Now, these are the sensors which I
believe has not been explored a lot until now. So if you can combine the sensor
space, I believe the opportunity space will increase drastically, and we might be
able to solve problems and come up with better opportunities in the mobile
computing space at large.
So at this point, I will conclude my talk. I would like to take any questions or
comments.
>> Jie Liu: Thank you.
[applause].
>> Jie Liu: In the interest of time, I think we're going to take questions offline.
>> Souvik Sen: Sure.
>> Jie Liu: And you're going to meet most of the people here. Thanks.