1
>> Srikanth Kandula: Okay. Hello, everyone. It's my pleasure to introduce
Shravan from Wisconsin. He has a lot of connection with MSR, even before this
interview. He interned with MSR India and also MSR Redmond before.
And today, he will talk about how to detect interference in wireless network.
He has done a lot of work in this area besides now WiFi and WiFi interference.
Okay. Go ahead.
>> Shravan Rayanchu: Thank you for the introduction. Good morning, everyone,
and thank you all for coming here to listen to some of my [indiscernible] grad
school. So this talk is mainly going to be about systems to understand
interference in the unlicensed band. And before I delve into the talk, though,
I wanted to give a little bit of introduction about different projects that I
have had a chance to work on during my grad school.
To introduce, so we all know WiFi [indiscernible] have become very popular.
They're almost everywhere. And in some sense, we have become dependent on
them, mainly because of the ease of access with WiFi devices with mobile
connectivity and also a lot of content that you're interested in is actually
online.
So naturally, as wireless users, we expect wire-like performance from wireless
networks. That is, we want the networks to be fast and we also want the
networks to be reliable.
However, there are several challenges that we have to solve before we can
actually get there, and it's indeed a very good time to be working in this area
of wireless networking and have a chance and was fortunate enough to work in
this area for the last few years. And I wanted to give you a brief idea of the
different projects that I have had a chance to work on in this area.
So mainly work on wireless networking and of late I've had the chance to work
in the area of mobile systems and applications. In wireless networking, I've
had a chance to work on something very fundamental in my open, and that has to
do with building tools and systems that help us improve our understanding of
wireless interference. These are the tools and systems that help us improve
our visibility into this wireless environment in some sense.
And this will be the focus of the talk today.
2
I've also had a chance to work on some optimizations for enterprise wireless
networks. For this, we actually have a [indiscernible] at Wisconsin which has
about 50-odd wireless nodes with boxes which consist of like a couple of
wireless guides. And basically, we use this as a platform for extensive
experimentation during my grad school.
So one of the products, for example, had to do with tweaking channel widths in
this network and looking at how we can traditionally [indiscernible] has a
fixed channel of 20 to 22 megahertz or maybe 40 megahertz in some cases. Our
project had to do with how do you go further, for example, five and ten
megahertz and look at the problem in the network wide scale and look at how you
can use channel widths effectively in such a setting.
Also had a chance to look at scheduling aspects of the network. For example,
if you have an enterprise scale network, how would you look at scheduling. For
example, the [indiscernible] of the scheduling versus the benefits it can
provide.
Also had a chance to look at some network recording mechanisms in the past
where we look at enterprise mesh kind of a setting and how do you look at
mechanisms to design the overall through-put.
Also had a chance to look at some [indiscernible] measurements. For example,
one of the projects over here had to do with a city-wide mesh network
deployment. We looked at some multimodal data in terms of SMP logs and, for
example, passive wireless traces as some active measurements and we looked at
how we can use those measurements to find out the characteristics of the
network as well as performance bottlenecks. And that's really some of this
that's part of my Ph.D. thesis.
I also had a chance to work in some interesting products. For example, this
mobile application analytics framework, where we know that there are a lot of
applications in the [indiscernible] store or the Android market. And the idea
here was to sort of come up with a library which can be imported to
applications and give feedback to the developers to understand their
applications better.
And I also did a couple of internships at Microsoft and had a chance to work on
some other projects that I had to do with, like improving battery life on
3
mobile devices and securing cloud watching machines.
So this is the overall [indiscernible] space I've been working on for the past
few years. And today, my talk is going to be about two different projects in
this space, and that is going to be about some nonWiFi interference issues that
I'm going to be talking about and some of this work was also fortunately picked
up by the media, and we got some very interesting feedback both in terms of the
comments on the articles as well as some e-mails, e-mails that we got. And
it's rather interesting to note what the non-academic community thinks about
our work.
So with that, I wanted to start through this talk, and this is going to be
about systems to be able to understand wireless interference better.
As naturally, as wireless users, we expect wire-like performance. And for the
most part, our experience has been that it seems to work well, all right?
However, there are these cases where we see that the connection, we see that
the wireless connection keeps dropping. And we don't really know what's going
on.
Let me give a small example and this is something come I got off an email
thread from the computer sciences department student meeting list. So these
are computer science students who are having trouble accessing their wireless
networks, right?
So the first student here says, is anybody else finding the network to be slow
or flaky? I want a sanity check before I tell my lab administrator. The
second one says my laptop keeps dropping connection. Is there a one-spot guide
to WiFi troubleshooting. And the third one says it was flaky for me yesterday,
and restarting the laptop seemed to solve the problem.
This is typically the approach we tend to take. We retry or we start the
laptop. Or if all else fails, we somehow try to communicate that to the
network administrator. And the network administrator in this particular case
had to say this. We continue to hear the reports of problems but could not
reproduce the problems on demand. Nor do we have enough details to identify
the real issues.
And this is really the crux of the problem where we see that most of the
wireless issues are very transient in nature, coupled by the fact that when
4
users typically complain to the network administrator they don't have enough
details about the problem and we don't have enough -- sophisticated tools in
the network today that will help network administrators debug what's going on
in their networks.
In fact, these are network administrators that actually are experts when it
comes to, for example, wire networking. But for some reason when it comes to
wireless networks, they don't have a very good what's going on.
So what we want to do, in some sense, is we want to empower the network
administrators to answer this very simple question. Is my wireless network
operating well enough? Right?
And trying to put it in more precise here, where given let's say target setting
up an enterprise wireless LAN where we have bunch of access points and let's
say the access points are connected to a central controller or a
[indiscernible]. And if you're given few wireless clients. Laptops, smart
phones, tablets and so on. And it is naturally connected to these access
points so in this particular case, we have six links in the network.
The question we want to ask is can we provide an overall score to the network.
And a very simple dial, which is bad and good, I'm going to sort of grade this
network, right.
So how do we go about doing that? So if you look at this network, one way to
do it is we want to sort of grade these links in the network, right. So let's
say have links on the Y axis and the goodness of the link on the X axis. And
let's say in this particular case we can look at something that looks like
this.
Coming over, this is probably not the hard part. What is harder is I want to
know why -- so let me just explain this graph over here, L1 and L2 are not
performing well at all, and L3 and L4 on the other end had mediocre performance
and L5 and L6 are doing very well, right.
So what is harder, though, is I want to understand why L1 and L2 are not
performing well, right. So I want to understand why certain links in the
network are underperforming. And I want to do that in realtime and I want to
do that without performing any sort of [indiscernible] on the wireless network.
>>:
[inaudible].
5
>> Shravan Rayanchu: So it's a good question. So I guess it comes back to the
fact, what is goodness of a link, all right. So what is good enough for us.
And basically what I mean by that is, you know, there could be a variety of
matrix maybe just loss link or maybe a through-put.
So essentially, if you take loss link, for example, I want to know why the loss
at a certain link is high.
>>:
[indiscernible].
Suppose I see like a [indiscernible].
>> Shravan Rayanchu: Sure. So the bandwidth is very much dependent on what
application is using -- what is application trying to push on that link, right.
So maybe the application is trying to push one megahertz, in which case that's
good enough. But if it's trying to push more than that, then it's not good,
right?
So in terms -- so rather, I would like to think of it in terms of the loss of
the links and see what is the quality of the link itself. Does that answer the
question?
>>:
So it's loss rate?
>> Shravan Rayanchu: Yeah, I mean like for example, that is one thing we
should focus on is loss rate, like how good is the link? Is the loss for the
link high, or is it not so high?
So coming back to this question, right so I want to understand why, for
example, a certain links not as good as the others. And if we look at a very
simple scenario, where you are given an access point and you're given a laptop,
and the user is trying to stream over you. And for some reason, let's say, the
video starts buffering. And let's just say that in this particular case, it's
because of the packets on this wireless link are not getting through.
So I want to understand what is the reason for this packet loss? So for
example, is it weak signal. That is, there is no interference in the network.
It just so happens that the laptop is quite far away from the access point.
Or, for example, the transfer power on the access point is not high enough that
the packet is able to be successful.
6
Or, it could be, for example, because of interference from WiFi devices. That
is, there are a number of WiFi devices that sort of share of spectrum in some
sense along with your laptop, and you want to understand whether any of this is
affecting this WiFi link.
For example, packets that could be transferred simultaneously and resulting in
collisions. On the other hand, it could also be because of interference from a
variety of non-WiFi devices. So, for example, things like microwave ovens or
/STPHELG devices or wireless video cameras or audio head sets or frequency
phones or even game controllers likes X-Box, right.
So which of them is actually causing the trouble. And it's not easy to find
out if you are given one link and it's experiencing packet losses. So, for
example, coming back to our mini wireless LAN example, let's say I download
something like this, where L1 is being impacted by a wireless video camera.
And its impact is 0.7 on a scale of zero to one, let's say, where zero being
the fact that whenever I turn on the wireless camera, it's not affecting the
link. With one being the impact where whenever I turn on the video camera,
none of the packets are getting signal, right.
For example, L2 has two different non-WiFi interferers. The first has an
impact of 0.3, and the second one has an impact of 0.1. L3 on the other hand
is being impacted by link and the network itself. It's impacted by link L6 and
has an impact of 0.2.
L4, on the other hand, is not really suffering from any interference but is
actually suffering from a weak signal problem, where the access point is not
high enough. So I want to come up with a mechanism that sort of grades these
links and finds out what is the reason behind high packet loss on each of these
links.
And, in fact, the resolution is very much dependent on what is the underlying
cost of this under performance. So in some sense, I want to come up with a
system that tells me what is the reason for packet loss on each of these links.
So for that, we have a solution where we have done realtime interference
estimators for WiFi to WiFi interference. That is, interference on WiFi links
from other WiFi notes. We looked at this problem back in 2008, where we worked
on something called COLLIE, which essentially stands for collision inferencing
engine, where we looked at a very simple scenario which takes one wireless
7
account and says whether that link is suffering from other wireless networks.
And this was a single node system. And we've developed the solution to work
off the WiFi hardware and we built a [indiscernible] system which we call PIE,
where it looks at multiple wireless nodes, uses the multiple vantage points and
tries to characterize the realtime interference conflict graph of the network.
And when it comes to non-WiFi to WiFi experience, we put a special restriction,
and that is we do not want to use any extra hardware. We don't want to use any
custom hardware or even sophisticated spectrum analyzers, for example, but use
the information provided by a WiFi card itself to first detect the
[indiscernible] non-WiFi devices and then not only data device, but also
quantify the impact of a non-WiFi interferer and also physically pinpoint
where, for example, in the physical space is this device.
So I will be talking about these two projects in this particular talk, where we
are folk having on how to protect he's non-WiFi interferers and sort of
quantify their impact and physically pinpoint them. So but before we delve
into this non-WiFi interference specifics, a question I want to ask is, well,
is non-WiFi interference a real problem? Should we be worried about it.
And if you look at a number of wireless vendors and other [indiscernible] from
them a lot of them are working on this particular problem. And for example,
there's a recent report from Cisco which says that more than 50% of the trouble
in enterprise wireless LANs can be attributed to random interference sources
like non-WiFi devices.
So the first question when we look at the problem, we asked was, well, is how
severe is impact, right? Should we be worried about it. So we did some
control experiments where we looked at what are the -- what is the impact on
these links when you -- on some good quality WiFi links when you use devices
like video cameras or cordless phones or microwave ovens.
And it turns out that there are many cases where there's more than 50%
through-put drop and in some cases, the there is a complete loss of
connectivity, especially with devices like wireless video cameras or analog
cordless phones, which are why duty devices, which sort of emanate energy
continuously. There's a complete through-put loss on the WiFi link. So there
seems to be a real problem here.
8
The other question, well, we know that, you know, this impact can be severe.
But are these devices popular? Are these devices prevalent enough that I
actually encounter them on a day-to-day basis. To understand this aspect, we
went to cafes inter surprises and homes and we looked at non-WiFi device
activity in each of these environments by look a custom hardware. And, in
fact, this data set is publicly available for download.
What we could find was that across locations, there are many devices that
appeared often and, in fact, with very high signal strength. Possibly
indicating non-WiFi interference in these cases. So how do we solve this
issue?
So our solution, I'll give you a small example. Let's say you have there
access points, AP1, 2 and 3. And you're given a wireless link and you're given
two different non-WiFi interferers. The first piece of solution, which we call
Airshark, tries to detect the non-WiFi devices by using a software solution
that runs independently on all three access points.
So, for example, AP1 over here says I'm able to see a microwave oven. AP2 says
I'm able to see a microwave oven. I'm also able to see a video camera. AP3
says I'm able to see a video camera, right.
So once we're able to detect all these devices independently, the next step is
to sort of understand the interference impact of these devices and also
physically pinpoint where they are.
So we combine information from all these access points to a central controller,
and in the first step, we reject the device's location and. For example, here,
microwave oven is at location R1. The video camera is at location R2, and then
we find out what is the interference impact of, for example, this wireless
video camera on this laptop here.
>>:
[inaudible].
>>:
Yes, continuous senders, and they just [indiscernible].
>> Shravan Rayanchu:
>>:
[indiscernible].
So, for example --
9
>>: They can use different bands, for one, and so if you set the AP to channel
1, the thing is at channel 11, whatever, you can do it that way. And I think
that this is basically the security camera space. Security people have WiFi,
you know, networking people sometimes don't talk too well.
>>: [indiscernible] phone on the market which was interfering with WiFi
[indiscernible]. That's why I wonder if [indiscernible].
>>: Maybe the other way without, but I'd be willing to bet I it would cost
[indiscernible].
>> Shravan Rayanchu: So basically, the system, for example, over here, at the
end of the day, basically does detect there is a microwave oven at location R1.
And there is a video camera at location R2, and it has an impact on link L3 on
your network, an impact of 0.4. So this is a system that we want to come up
with.
>>: There are many products that I know of, I know of two products that claim
to do the same thing. Have you looked at those? For example, is this
[indiscernible].
>> Shravan Rayanchu: I think airtight is more focused on rogue devices which
might or might -- which are there in the wireless.
>>:
That was two years ago.
Now they've moved on.
>> Shravan Rayanchu: But I'm not sure what hardware they're using to do that.
I know for sure that they were in order for their solution to work, you have to
deploy sensors. So I'm assuming they have some custom piece of hardware which
can do that. I think our contribution was how can you do all this with a WiFi
card, right.
>>: So do you have enough vantage point to [indiscernible] to localize to R1
or R2?
>> Shravan Rayanchu: Sure. So it basically depends on the density of the
access points in the network, and I'll show you later in experiments where we
looked at different densities and depending on how dense a network is, your
10
precision of localization will change.
>>: Also, what if the [indiscernible] interfere by microwave sources, how do
you tell that [indiscernible].
>> Shravan Rayanchu: So the way we do that is we mainly based on correlation,
right. We basically look -- if we see that there are [indiscernible] samples
with one device affecting a portable WiFi link, we say that that is the impact.
But there could be some bad cases, some pathological cases where with certain
times of devices which are always on, it's hard to distinguish who's the real
culprit. But I'll talk about them.
So the first piece of work is Airshark, where we want to come up with a
software solution that tries to run on top of a WiFi card and can tell you what
other different non-WiFi devices in the WiFi card's vicinity.
So how do we do this? We use a commodity WiFi card. And the goal here -- it's
a single node system, and the goal here is to be able to detect multiple
devices that can be operating nearby a WiFi card, right. And we want to do
that in realtime.
So we make use of this emerging class of WiFi cards which give us slightly fine
grained information about the spectrum. So they give us something called
spectrum samples. Essentially what I mean by that is they give us the power on
[indiscernible] per sub carrier. And traditionally, for example, wireless
cards are exposed just a single R [indiscernible] value per packet, but here
what we're getting is much more fined grained information about
[indiscernible], but every sub carrier. An example is the Atheros AR 9280 chip
set on which we developed Airshark.
So one of the challenges here ->>: If you need like a special emerging type of card and your main
[indiscernible] is to be able to do it using a WiFi card, I ask you like what
is a WiFi card?
>> Shravan Rayanchu: WiFi card, I mean basically cards that are coming out
today. Let's say, of course, this mechanism for example will not be -- we
won't be able to use that in already deployed networks and still not expose its
functionality.
11
So what I mean by a WiFi card is basically a card which has the physical layer
and a [indiscernible] layer that conforms to the WiFi protocol. And this
particular card just exposes a certain amount of information, and
[indiscernible] information. But at the end, it's still a WiFi card. We're
not using some extra sophisticated high [indiscernible] which probably has a
higher sampling rate, for example, which can sort of detect these devices.
>>: So you're saying some of the techniques that may be required to detect
non-WiFi [indiscernible] like would not be embedded into a WiFi card? Is that
the idea?
>> Shravan Rayanchu: Sure. So at least if you look at the picture a lot of
stuff that has gone into detecting these different devices, the kind of
processing that you need, you probably have to end up changing the physical
layer, which is not what I mean by WiFi card.
So I'm talking about a traditional WiFi card which has all the processing
required to just decode it back. And I want to use that functionality, which
is sort of used in just decoding a packet, but just expose some information,
for example, just like fine information about the channel which I can use to
get at these different WiFi cards, different [indiscernible] devices.
>>:
[indiscernible].
>> Shravan Rayanchu: Sure. In fact, if you use [indiscernible], you'll
probably get a much more information about the channel, for example, or much
more information about the signal itself. But I guess ->>: For example if you're going to depend on a new generation of WiFi cards,
then why not just take ->> Shravan Rayanchu: Because I don't really see a software defined radio-based
platform being deployed in the near future. Or the fact that, for example,
let's say there's a new [indiscernible] coming up and you're trying to deploy
[indiscernible] there. I want this [indiscernible] today and not building.
>>:
Why don't we see a new generation of things?
>> Shravan Rayanchu:
It might, but I think it's going to take awhile.
12
>>:
So that comes out, then what happens to your system?
>> Shravan Rayanchu: So I think if that becomes a problem, we might have a -if that comes up, and when that comes up, you know, I'm sure we can think of a
rather -- in fact, a lot of -- all the approaches that we dealt with here will
definitely be applicable, because that platform is always going to give us more
information than what I have right now.
So you can possibly improve, for example, localizing precision or impact
characterization of how well you characterize impact. But I do see that the
techniques are applicable. It's just that we're able to do also on top of a
WiFi card.
>>:
[indiscernible].
>> Shravan Rayanchu:
sense to --
I didn't understand your question.
I mean, it does make
>>: [indiscernible] next generation of cards. Why are you limiting yourself
to next generation of cards? Why are you making that judgment on that?
>> Shravan Rayanchu: Because I think that the non-WiFi device interference is
a problem that's there today, and it makes sense to solve it as quickly as
possible.
>>: Can you make some sort of an argument that what you're using is
[indiscernible].
>> Shravan Rayanchu: So that's a very good question, and I think it has to do
a lot more with -- maybe I'll go to this slide and come back to that question.
It has to do with basically what sort of information do you need to detect
these devices, for example, the first step.
And I think the amount of information that we have from these WiFi cards is
just about enough for us to be able to get at these devices.
So for example, let's say if I want to look at this fine frequency block, I'm
going to start off interested in understanding the non-WiFi device
functionality. Rather, non-WiFi device activity in this particular block of
13
spectrum.
So the first challenge that I face, for example, is that WiFi cards typically
have a very narrow view of spectrum, like maybe 20 gigahertz or maybe 40
megahertz. So you cannot sample the entire spectrum all the time.
The second challenge is that you're getting these samples which are very
coarse-grained in nature. For example, they [indiscernible] thousand or ten
thousand samples per second and I'm calling them coarse-grained mainly because
of the custom [indiscernible] give you a much higher precision. As high as,
for example, one million samples per second if you use spectrum analyzers.
And if you look at the frequency resolution, again, again, WiFi cards are
limited by the fact that you're going to get the information about the power or
the RSSI every sub carrier. So you're going to get one sample every 312
kilohertz. So you're dealing with all these coarse-grained aspects. However,
the biggest challenge is that a WiFi card cannot decode a non-WiFi device
transmission.
So by using just the packets of the power in the ear, I somehow had to figure
out what are the different non-WiFi devices that are present in the spectrum.
So coming back to your question, right, I think these are the challenges that
we had. But I think they were just enough. For example, the [indiscernible]
was just enough for us to be able to detect these non-WiFi devices, and the
information that we're getting is not really the entire information about the
signal itself, but just about R value. So I will say I think this information
was just enough for us to sort of be able to detect these devices, which was
not possible before because we were limited to just like one RSSI value for the
entire channel.
>>: So does it also mean that there, like, some kinds of non-WiFi devices you
will not be able to [indiscernible]?
>> Shravan Rayanchu: So for example if we are talking about, let's say, two
devices which are within a 312 kilohertz band which are transferring, we will
not be able to say if it's one device or two device, for example. And we might
be able to say that there is some device that's out there, but it probably
might not be able to detect them very well.
14
>>: So are those [indiscernible] limited function of the WiFi card today.
by just it device manufacturer aim to detect non-WiFi --
Or
>> Shravan Rayanchu: I think it is a combination of both. For example, at
least when I talked about the resolution in terms of frequency, that's
something which is limited by the WiFi protocol access, so that's not going to
change.
But if you're talking, for example, sampling, is, so a lot of it is also
limited by the fact that what is a processing capacity that I have on these
access points. So it's not just number of samples that were coming in, but the
ability to process them. So I think those are the two limiting factors. And
if you have more beefier CPUs, you probably can slightly increase the sampling
rate. But this sampling rate was sort of just enough for us to be able to
[indiscernible] the device. So we can only go better than this if you have
higher sampling rate.
>>: Question. So on the previous slide, if you had, you know, 75 bluetooth
devices sitting around your gizmo, could you detect it with this system?
>> Shravan Rayanchu: No. So as you increase more and more devices, you're
going to sort of crowd the spectrum and it sort of becomes really difficult to
sort of detect what are the different devices.
We might be able to say that there is a bluetooth device that's there in the
spectrum but I don't think with the system that we have it's going to -- there
are 75 other devices. The system that we designed is [indiscernible] ten
devices, maybe. But not more than that.
>>: But are you assuming the CW weight, or are you -- because the bluetooth is
a frequency hopper. So it's not clear that you'll see a frequency hopper with
this system.
>> Shravan Rayanchu: We are able to. That's because we do keep hopping on.
I'll come to that very soon. I'll tackle that.
But just to counter your argument about
measurement study that we did, where we
enterprises and homes and coffee shops,
were more often than not, the number of
75 bluetooth devices, at least with the
looked at real environments like
things like that, what we found out
devices, the number of different
15
devices that are out there are not more than four, for example.
Of course, this is very much limited to our sample. But at least if there's a
fairly odd location we looked at, we did not find too many devices at the same
time operating simultaneously.
>>:
Were there measurements there that you measured?
So did you [inaudible]?
>> Shravan Rayanchu: Yes. So basically for the measurement, we did the
measurement not with Airshark, but with some other custom hardware that's
available out there, special chip sets that are designed specifically to detect
these different non-WiFi devices.
So if you're questioning the ground truth, or rather questioning the accuracy
of the custom hardware itself, we did perform some controlled experiments
before we went out into the [indiscernible] to measure how good is the system
to be able to detect these different non-WiFi devices. And it was sort of
accurate for the most part. So we believed that and we take that as a ground
truth and we measure the [indiscernible] activity in different environments.
>>: So what devices did you use to detect, like, bluetooth like frequency
hoppers? Because that's really hard. Because spectrum analyzers don't
typically see that stuff.
>> Shravan Rayanchu: So if you have a wide band receiver, it's still possible
to do that. But I think most of the systems that are out there that are even
based on -- there is some hardware which are wide enough for example to sample
100 megahertz at the same time, which is enough for you to even to detect
bluetooth devices because you're mostly concentrating on the [indiscernible]
band that you have.
The system, on the other hand, that we have is that we, although we cannot
sample spectrum all the time, we keep hopping on the spectrum so the hope is
that we're going to catch the devices soon. We might not be able to catch the
entire activity for a bluetooth device, but we'll be able to detect, capture
some of its activity.
So how does this work, right? So uses wireless card which can give us some
spectrum samples. And the goal here is to predict the presence of the device.
16
So and what we're getting really is a [indiscernible] the power in the air. So
naturally, we said lights try to use a machine learning mechanism. But we want
the system to run in realtime, so we say we want to use something very
lightweight, something like a decision tree classifier.
And the way these things mostly work is they operate on features, right. So
what we really did was we use an [indiscernible] classifier and our job was to
really come up with these features and to use the domain numbers that we have
to come up with features that can sort of distinguish these devices.
So we came with features that capture this spectral and the temporal properties
of different non-WiFi devices. So I go into this now. So how does it work?
So if you have a wireless card, and here's a device detection pipeline, which
is going to give you some spectral samples to begin with. And we apply a
series of procedures after which we're able to detect a device.
I talk a little bit about each of these modules. The first one is spectral
sampling, which is quite simple. What we do is we're given a big block of
spectrum to sample and we know we cannot sample it all the time, the entire
spectrum all the time. So we divide it into a certain amount of sub banks.
Let's say 20 megahertz, which a WiFi card can sample.
We sample one sub band at a time and then we move to the next one and so on and
so forth, right. So although we want to capture all the spectral samples, the
hope is that we will be able to catch all different non-WiFi devices, frequency
hoppers or not, over time.
>>:
[indiscernible] or this is the main card?
>> Shravan Rayanchu: So right now, we have a card which is dedicated to just
doing this spectrum analysis and trying to figure out what other non-WiFi
devices activity.
So it really depends on the use case. So, for example in Airshark, we wanted
to monitor the entire spectrum. But for example, we could limit yourself to a
certain channel that you're interested in. In which case the card can actually
be involved in transmissions. But at the same time, you're constrained to just
monitoring the activity within a certain sub band.
So once you gather in a sample.
So next step is I want to understand, I want
17
to look at each of these samples and figure out is there anything interesting
in sample. I want to know if there is any non-WiFi device activity in the
sample and in which case I want to process the sample further. Otherwise, I
want to neglect the sample.
So if you look at a particular sample, it looks something like this, where you
have power and frequency. And we use a very simple approach, which says given
-- let's say we pick a threshold and if the power value is actually more than a
threshold, then you believe that there is something interesting going on over
there. Otherwise, you simply discard the sample.
By the end of this, what we really get are pulses. But pulse is what I mean
are time frequency blocks which have a certain amount of power, but are more
than the rest of the samples.
So given these time frequency blocks, the idea is to now detect the devices
based on these pulses or time frequency blocks. So let me give you an example.
Let's say you're given this block of spectrum, and you have certain amount of
samples. If you use an analog phone, for example, it's a high energy device;
that is, it's going to transfer energy continuously.
So, for example, we get a big time frequency block corresponding to an analog
phone transmission. Or if it's a ZigBee device which happens to ZigBee
packets, we get two pulses or two time frequency blocks, corresponding to these
two packets.
If you see a microwave oven, it can see a packet that looks something like
this. Or if it's a bluetooth device, we might see short, one-minute pulses
that are spread across the frequency band. However, at this point, what you
really get are these time frequency blocks. We don't know what are the devices
that are operating in this particular spectrum.
So by looking at -- so in order to understand what are these pulses belong to,
and to do that, we sort of create signatures that are specific to each device.
>>: Do you control your sample frequency?
frequency, which time you sample?
Do you control, like, which
>> Shravan Rayanchu: So what we have -- so I guess we could do that
specifically if we -- so I know we have a very uniform mechanism where we keep
18
hopping around and the amount of [indiscernible] time in each band is uniform.
However, you know, you can always come with a mechanism where you think that
there is more activity in a certain part of a spectrum compared to another one,
for example.
So signatures, for example, are -- yeah?
>>: So this, if you were in the same [indiscernible], in order to get this
nice pattern, you see some hopping, it goes away ->> Shravan Rayanchu: So this is the version of Airshark, where we were trying
to detect devices and then [indiscernible]. In the second piece, WiFi Net,
where we basically modified Airshark, where it's going to work only on a single
channel and we are actually to able to detect all the devices, even bluetooth
for that matter, of an equal amount of accuracy.
So there are certain properties that we cannot exploit when we are not hopping
around. For example, I want to use things like what is the distribution of
pulses, for example. Those sort of properties or those sort of features, we
cannot use them. But we still can do the bluetooth device even when you're
monitoring a single channel.
>>: You said something like of course we use machine learning, but in this
particular case, it seems like you don't have complex. Why don't you come up
with ->> Shravan Rayanchu: So we've not used machine learning to start with. We
used a very simple approach, how do you extract these properties. But I think
the advantage of using something like a decision tree classifier was very
useful, especially when there are multiple bluetooth devices operating at the
same time, especially when the spectrum is crowded. Otherwise, if it's simple
packets, we could still be able to figure them out, just by using some of the
features, for example, that I'm going to talk about. You don't really have to
build a tree out of it.
So, you know -- yeah?
>>: Are there, you mentioned that there is specialized hardware that does this
also, like frequency [indiscernible]. Do they also do [indiscernible]
classification?
19
>> Shravan Rayanchu: So there are [indiscernible] products that are out there
which uses custom hardware, and detect the different devices. I know for sure
that one of them uses machine learning. I'm not sure about the other one. But
they do this automatic device classification with that hardware, yes.
>>: So I guess getting back to the earlier question. So the contribution here
is not the classification, per se, but it's scaling the classification down?
>> Shravan Rayanchu: I think the classification was to identify the fact that
we're able to do that on a WiFi card and the fact that, you know, given these
coarse-grained samples, how can you build a system that can work off these
coarse-grained samples. Because the features, some of the features that you
can use when the sampling is high are not applicable when you are working with
such a coarse-grained fashion. So I think the contribution must also come up
with what sort of features do you use when you are getting even samples at such
a coarse grain.
>>: [indiscernible] specifically had to change about the system classification
[indiscernible].
>> Shravan Rayanchu: So I do not know exactly what the propriety mechanisms or
classification mechanisms used by people who are using custom hardware, so I
cannot really compare that. But at least during our experiments, we did
compare our accuracy that we have, the accuracy of our system that's built on a
WiFi card with custom hardware, and it seems to be, you know, pretty close to
that.
So to start with, we said we're going to use something very simple, like center
frequency and bandwidth. And if you have a time frequency block and you're
able to figure out what is its center frequency and what is its bandwidth. And
we know that most protocols use certain predefined channels.
So for example, ZigBee has 16 channels of two megahertz wide each. So if you
are able to see a pulse, a time frequency block that is aligned to one of these
16 channels, and it has a bandwidth of two megahertz, we can see what most
likely looks like a ZigBee device. We're not sure at this point, but it gives
us a hint about what device is operating nearby.
Similarly, if you look at the duration of the pulses, even that sort of gives
20
us a hint about what other devices are operating.
So for example if you look at bluetooth, it has an active transmission
tradition of 366 microseconds every 625 microsecond slot. So if you see a time
frequency block that is about 366 microseconds that sort of tells you that
maybe it's a bluetooth device.
Or if it's a cordless phone, for example, it has a different timing property.
Similarly, even if you look at the timing between the pulses, even that sort of
gives you an idea of what is a device that's operating. If you look at
bluetooth, it has the start time difference between the time difference between
the start times of two pulses, for example, is always a multiple of 625
microseconds.
Or if you see a microwave oven, you might see an [indiscernible] which is 16.66
milliseconds. So even the timing between the pulses sort of gives you an idea
of what is the device that you're looking for.
So these are very simple features that I talked about, and there are slightly
more complicated features which I'm not going to be discussing, but I'll just
briefly mention what they are.
So one of them was what you call a spectral signature. Especially tries to
sort of capture the shape of the signal in some sense. It tries to look at
what is the power distribution of the device, or the frequency band. Or, for
example, the pulse spread, where we look what is the distribution of the pulses
that cause the frequency band.
Or we also look at some of the features, which are some of the ways the duty
devices, for example microwave ovens.
>>: So [indiscernible] again I haven't kept up. Three years ago, there was a
[indiscernible] frequency hopping. It was a bluetooth. And it was minimized
[indiscernible]. They watched WiFi signal, and it would hop across it. Now, I
wonder if, like, for example, [indiscernible] signals if there's one thing to
sort of raise a flag and another thing to adapt to basically where you are. So
two systems that have [indiscernible].
>> Shravan Rayanchu:
So I guess I think the way our experiment is we
21
[indiscernible]. For example, I think it just looks at the amount of raw power
that's there in the channel. For example if you were to use an analog form,
the [indiscernible] even tries to avoid the analog form. So I think the
mechanism that they have is just look at the [indiscernible] and try to hop,
adapt.
And so at least in our experiment, you can see that there are certain cases
when especially if you have one of the wireless links operating as one of the
channels bluetooth will try to hop away from those channels and not really
interfere. But when the spectrum becomes crowded, that's when you have some
problem.
So after this, once we're able to detect all these features, the next step is
to start off, use these features to start off, find out where, what other
devices that are operating. And for that we collect samples in both cases from
the devices on and the devices off and basically extract the features that we
talked about and retrieve the classifier.
And done in realtime, it's sort of, it does say whether the device is present
or not, based on this classifier. So that's sort of how Airshark works
overall, and we evaluated by implementing it on an Atheros-based chip set, and
we tested it across a few classes of devices. So, for example, we tested them
across narrow band high duty devices like cordless phones and video cameras,
broad bad interferers like microwave ovens, and also radio frequency hopping
devices like cordless phones and bluetooth head sets and game controllers.
So the current version of Airshark is able to detect all these different
devices, and just want to give you a couple of snapshots about the results.
Yeah?
>>: Was your training set using the same -- did you have a train set that used
different [indiscernible] different manufacturers?
>> Shravan Rayanchu: Yes, yes. So even like different environments and also
looked at different. So our training was based on one rather, you know, just
like one model, for example, for each device class and we actually just tested
across multiple models and it seems to work very well.
>>: So if a device and model was in your train, your training set, it would be
not be in your test set?
22
>> Shravan Rayanchu:
Yes.
>>: Question. How large is a training set of devices.
how many [indiscernible]?
And for each device,
>> Shravan Rayanchu: So it really depends on the [indiscernible] device. So,
for example, if it's an analog cordless phone, which it's always on, we only
need a few samples, because the property of the devices aren't really changing,
the transmission property.
But for example if you look at a bluetooth device, we need slightly more amount
of samples. So the training ranged from a few hundred milliseconds, which was
enough for devices like analog cordless phones, versus a few seconds for the
devices like bluetooth device.
>>: [indiscernible] within each type of device or, I mean, for different
device for same device on different manufactures. And then [indiscernible] the
feature consistent with the type of device?
>> Shravan Rayanchu: Yes, yes. In fact, that's the reason why we're able to
sort of accurately detect the other models of devices. But there are certain
devices, for example, some cheap hardware that you get, for example, analog
cordless phones that are not so expensive. And those are devices that we saw
that some of them do not really exhibit stable features. For example,
especially when they are [indiscernible] cases. But other than that, for the
most part, we see that the features are compatible across all the models.
So the first question was how accurate is the classification. To do that, we
have this block where we have accuracy on the Y axis, and the power from the
device on the X axis.
So, for example, the device is farther away. You have much lesser power from
the device. As you come closer and closer to WiFi card, the power increases.
And here are the overall results. We see the mechanism is accurate for the
most part, especially when you're looking at these high RSSI cases. But as you
sort of move the device farther and farther away, the accuracy starts dropping.
This is mainly because of a few things, for example. Things like if the power
is less than a certain pressure we will just neglect the sample. Or, for
23
example, things like some of those features, like the [indiscernible] signal
which sort of starting at a real low power level. So it's about not being able
to extract these features well enough during low power case, which is the
reason for inaccuracy. These lower power cases.
>>:
How do you define accuracy?
>> Shravan Rayanchu:
>>:
Not for example.
>> Shravan Rayanchu:
there.
>>:
So, for example, if I were to detect -Specifically, for this, what does accuracy mean?
So being able to detect the device if it's actually
Being able to determine that there is interference with the device?
>> Shravan Rayanchu: Not interference, but just the fact that there is a
device. So microwave oven, will it say that there is a microwave oven.
>>: Okay. And are you also counting the [indiscernible] devices is, or just
to say there is a device?
>> Shravan Rayanchu: Exactly which is the device.
it's a cordless phone or whatever.
If it's a microwave, if
>>: Basically, those things. So what happens if you can't be as accurate
[indiscernible] present classification?
>> Shravan Rayanchu: We say in that case, the accuracy goes down. And false
positives increase. So accuracy is being able to currently detect the type of
the device that's actually being operated.
>>:
And so what about false positives.
>> Shravan Rayanchu:
basically ->>:
Yes, so, you know, so there's a trade-off, right.
Asking what the results are.
>> Shravan Rayanchu:
I don't have a number.
I can just show you that.
So
24
>>:
Okay.
>> Shravan Rayanchu: So the system is sort of fairly accurate, especially when
you're looking at signals more for example minus 80 dBm. And the next question
is what happens when there are multiple devices, right? So here again
regarding accuracy, we did an experiment where we keep devices at different
distances and we want to measure the accuracy in each case. That is, we want
to be able to detect each of the device. If I'm running three devices,
Airshark has to detect all three devices correctly.
So here are the results. As you increase the distance, the accuracy falls
down. But more importantly, as you keep increasing the number of devices, the
accuracy starts falling off. And that's because as you increase more -- as you
sort of throw in more and more devices, the spectrum becomes sort of more
crowded. And especially there are cases, for example, where the signals can
overlap, which can cause for the trouble. Because the accuracy sort of starts
falling down.
So coming back to your question, I think. So this is the false positive rate
that we have, and it's [indiscernible] because it's very much dependent on the
threshold that we're looking. For example we can slightly increase accuracy,
but we would take a hit on false positives. So we sort of did some experiments
and used the thresholds that we wanted to keep the false positives low.
And we experimented with certainly locations and also tried to compare it with
the custom hardware that's out there today. We find that the amount of
accuracy sort of slightly less compared to, for example, the custom hardware
that's out there. There's a 2% increase in error rate, for example. We also
look at some other mechanisms like [indiscernible] machines and things like
that, but we wanted to have the system do the classification in realtime and
also we wanted to transfer in some sense.
So we did not use -- so we struck the [indiscernible] class fires. So I have
very small demo of Airshark. Here we have a set up where there is an access
point, and that's going to give you some spectrum samples. And these are four
different devices that we tested. So this one is an analog cordless phone.
This is a frequency hopping cordless phone. This is a ZigBee device. And this
is a bluetooth head set with an iPhone. And this is all [indiscernible]
Airshark over here with four different windows corresponding to the output of
25
each device. And it's actually a ten-minute video, which I compressed it to
one minute. So it might be a little choppy, but I hope it gives you an idea.
So here, we are trying to switch on an analog cordless phone. That's a high
[indiscernible] device that's always sort of going to transmit energy
continuously. And we are able to detect this cordless phone in realtime and
also show you the amount of power received from this particular cordless phone.
>>:
Does this work even in the presence of actual normal WiFi?
>> Shravan Rayanchu: Yes, so we also have experiments which quantify the
impact of WiFi traffic, because WiFi traffic in some sense is noise to our
system. So what we found out, if there's extremely amount of interference,
there's too much WiFi traffic, the accuracy sort of slightly starts falling
down.
>>: How much WiFi traffic was there in the graphs you showed, the performance
results you showed us earlier?
>> Shravan Rayanchu: So basically if you were to complete the [indiscernible]
that's where it starts falling down. And in fact for devices ->>: In the actual results that you showed us, you actually gave us specific
numbers.
>> Shravan Rayanchu:
>>:
Yeah.
How much WiFi was there?
>> Shravan Rayanchu: So we performed the experiments in our department so
there is regular wireless LAN traffic going on. So it was not an isolated
environment, but, you know, that's sort of, I won't say a realistic
environment, but we also had controlled experiments where we tried to push a
lot of WiFi traffic and look at specific accuracy numbers even there.
So I guess although you might not get a very good sense of how Airshark was,
the point was to also sort of detect all the four different devices in this
case. One was a cordless phone. One was a ZigBee device, which is a variable
ZigBee device and two frequency hoppers. Like bluetooth and cordless phone.
26
So just to sort of recap, what have we done so far. So we have Airshark, which
can run independently on all these access points, and it can detect all these
different devices and then access points vicinity, for example.
The next step is to sort of combine this information and figure out where in
the physical space is this device and whether this device is actually impacting
any of the WiFi links. So this is what [indiscernible], whether there's any
interference that is actually happening.
So to do that, so there are actually a couple of challenges that we have to
solve before we actually get to a stage where we can use, where we can
physically pinpoint where the device is and what is actually interference
impact.
So I'll not go into the details of this mechanism but just show you what are
the challenges that we faced when trying to solve this and how we could sort
of, you know, overcome those challenges.
And let me give you an example to show you the challenges. The first one is
let's say I have a cordless phone where you have three different access points.
And it's transmitting a buzz, a time frequency block. And let's say we're
running Airshark on all these three access points. So they happen to catch
this transmission, tag it with the fact that it belongs to a cordless phone
device, and, you know, these are three different powered at RSSI which it's
able to capture this pulse.
So if you were try to localize this device, we want to find out where in the
physical space is this device. So if this was a WiFi packet, for example, we
could simply combine information from all three access points and start off get
something like a fingerprint and we could use this fingerprint to find out
where in the physical space is this device.
The problem over here is that this is a time frequency block, right. There's
no, for example, header information over here. So there is no ID or
[indiscernible] that's actually associated with this particular pulse. All we
know for sure is that it appears to be a transmission from a cordless phone
device. So the question over here is how do I know that all these pulses
actually correspond to the same transmission?
So I'll give an example as to how we solved it.
We used a very simple
27
heuristic, actually. Let's say we're able to run Airshark on all three access
points over here. The first one gives us two pulses, P1 and P2. The second
one gives us two pulses, P3 and P4. And the third one finally gives us a
pulse, P5.
And all of them are type cordless phone. And want to find out what are the you
increase pulses in this five pulses that I'm able to see. So we are
[indiscernible] simple heuristic which says, well, if you look at pulse P2 and
P5, we see that they start at the same time. They end at the same time. They
have the same center frequency and they have the same bandwidth.
So the heuristic says if you are able to see all these four properties where we
see that it's a transmission for a type cordless phone and they start at the
same time and have the same significant bandwidth, then most likely, it's from
the same -- it belongs to the same transmission.
>>:
So how do you [indiscernible] between the various [indiscernible].
>> Shravan Rayanchu: I'm going to come to that. So the question here is how
do you align the timelines. It's not like a chicken or egg problem here,
because we want to use the time synchronization to find out what are the common
responses in some sense.
So here's where running on top of a WiFi card was useful, because it so happens
that the clock that is used to time stamp the packets, the WiFi facts, the same
clock that is used to time stamp these spectrum samples. So what we really do
is we look for common WiFi packet receptions and then we synchronize all the
access points in the network.
And we had to do some sort of transducing synchronization, because all the
access points may not be in the same -- might not be able to hear each other,
for example.
So once we have this [indiscernible] synchronization based on common WiFi
packet receptions, we're not able to align the timelines.
So once we align the timelines, for example, P2 and P5 are, indeed, the same
transmissions. P1 and P3, for example -- yeah.
>>:
[indiscernible].
28
>> Shravan Rayanchu: So right now, for a granularity of [indiscernible], we
have an error of about six microseconds. So the sound, the granularity is
dependent on whatever am I sort of, sort of what is the [indiscernible] I'm
willing to sort of give to say that both of them started at the same time. So
essentially we're getting the sampling rate is something like 100 microseconds
per each sample. So as long as error is much lesser than that, it should be
okay. And we use the granularity of [indiscernible] seconds.
>>:
And in this scenario, [indiscernible] coordinator.
>> Shravan Rayanchu: So in this scenario, they're actually running on the same
channel. So we find the monitor one particular channel over here, so each of
them is just monitoring the WiFi environment on a particular channel. And
based on the WiFi, common WiFi packet reception, we're able to synchronize the
time clocks.
>>:
I see.
>> Shravan Rayanchu: So once we synchronize, all right, and we're able to
figure out what are the you increase pulses in the system, and how about
there's one more challenge before we can actually go to device localization and
interference quantification. And I can give you an example again where, let's
say, estimate what is the impact of this particular phone.
So the problem here is that let's say have one more phone which can transfer at
the same time. Then right now we don't have the capability to distinguish what
are the transmissions belong to different phones. For example, if you want to
find out that phone one is off of these two phones if this particular phone is
actually the culprit, at the very least, I should be able to segregate the
transmissions from the phone to quantify the impact.
So what we do there is so the question is, you know, Airshark was able to tell
us that there is a cordless phone. Now the question is how many cordless
phones are there. And what are the -- which device does each of these phones
belong to.
So we use some clustering based mechanisms which help us sort of distinguish
what are the other segregated transmissions from these different devices. And
I'm not going into the specifics of this clustering mechanism, but we were able
29
to sort of exploit some device specific properties and also some generic
properties like RSSI.
So just to give you a snapshot of the results. So here, I'm able to cluster
four different phone devices to two cordless phone hand sets and two cordless
phone base stations, based on some simple timing property. And here, we're
able to segregate out transmissions from two different microwave ovens, again
based on some timing properties.
And have one with plot average is going to show you being able to cluster the
transmissions from four different cordless phone devices, based on simply the
fact that they happen to be in different locations, for example. So we're
using RSSI as a proxy for location in some sense.
So once we fine out, after this clustering, we're able to sort of find out what
are the you increase devices in the spectrum, and we also are able to SEC grate
the transmissions.
So once we do that, once we know what are the you increase devices, we can then
proceed to the device localization and interference quantification.
So I can talk a little bit about each of these, just a slide on each of them.
Or maybe a couple slides on each of them. So device localization, at this
point, really becomes straight forward. We assume that access point locations
are known and there are several algorithm techniques that we experimented with.
So for example, we looked at centroid approach, which is a very naive approach,
where we looked at just the location of the access points and picked three
different access point with the highest signal strength and we say that the -just take average of that and say that's where the non-WiFi devices actually
present.
And we also look at some fingerprinting approaches where we actually went sort
of collected fingerprints in different areas of the building, for example, and
figured out and have a database of the fingerprint and figure out which is the
closest matching fingerprint. Of course, there is an overhead involved in such
fingerprinting approaches so we are experimented with a model-based approach,
which again we used a very simplistic propagation model, but it seems to work
fairly well and [indiscernible] a little bit.
30
So the challenge here was that we do not know the transfer power of the device.
For example if there's a microwave or cordless phone, for exam we, we don't
know what is the transmit power of the device. So traditional models, which
assuming if you know the transfer power will not work. So we use a model
where, basically, what we do is we have an algorithm which sort of works in
[indiscernible] access points. What it does is it tries to look at what is the
power and what is the related power between the access points. So it takes two
access points at a time and tries to figure out the difference between the
receive power. And the other simple model which tells you what is the
probability that the device is present in a certain grid, based on each data
access points.
So if you look at this example, this is a ground floor effort of computer
sciences department and we deployed like access points over there and this one
particular test case where the green star shows you the actual location of the
cordless phone. And here, for example, the algorithm sort of works in pair of
access points. So for example, after processing the first pair of APs, this is
what the probability looks like. Where the yellow circle over here is showing
you area with the maximum probability of finding that particular device. And
as you keep adding information from more and more access points, you sort are
able to sort of predict where the device is.
In this particular example, the predictor location is very close to the actual
location.
>>: Seems like a much easier thing to do is to add transitive power of the
device as one of the parameters in your model.
>> Shravan Rayanchu:
>>:
Sure, sure.
So basically --
[indiscernible].
>> Shravan Rayanchu:
I guess maybe you're talking about an approach where --
>>: So you have these observations and try to fine the post likely -- trying
to -- I take it's an iterative algorithm.
>> Shravan Rayanchu: Exactly. That's what we also have coming [indiscernible]
sort of detect iteratively while even using the transitive power as a
parameter. It just increases the search space. But we still can find it all,
31
but it's just that it is slightly more computationally expensive. Whereas this
particular model sort of accounts for the fact that we don't have to know the
transfer power by looking at the relative difference in the power of the access
points.
>>: So why does this work at centroid and not work -- why does it say centroid
does not work because of [indiscernible]. Why does this work?
>>: Centroid actually does work. It does work.
[indiscernible]. It works pretty good.
We've done this
>> Shravan Rayanchu: The algorithm density's high enough. If you have a
sparse density, that's when the centroid, it's very much more coarse grained.
So here's your centroid. So it's sort of like where two different deployments
in this particular case, basically given the accuracy is very much dependent on
the density of the access points. And we found that, you know, most of their
[indiscernible] work fairly well and for our use, it's probably the median
error that we see is about 4 meters, which I think is good enough. Because we
don't really want a very high precision attempts of device localization, but
just be able to figure out -- yeah.
>>:
So why is this better than centroid?
What's happening here?
>> Shravan Rayanchu: So centroid, for example, as I said, does not take into
account the fact that there is a wall, for example. So you're taking just the
round numbers that you're getting and trying to just take an average of that.
Whereas if you look at model, you can't account for what is exact application
loss and figure out exactly where the device is. So I think the centroid is an
approach which is going to just sort of, you know, take an average of things,
rather than taking ->>: You were taking averages too, but when you defined they had to reach that
space on some ->> Shravan Rayanchu:
>>:
Yeah, yeah.
Which does not include [indiscernible].
>> Shravan Rayanchu: Well, so we use upper AP [indiscernible] loss component,
so it does include the actual environment of an access point in some sense.
32
>>: But that's not what matters.
the transfer meter and the AP.
>> Shravan Rayanchu:
What matters is the number it was between
Um-hmm.
>>: So there's a little bit of problem.
that.
I'm not quite sure how you got around
>> Shravan Rayanchu: So, you know, so the way we sort of, we measure
propagation loss exponent for every access point, right. And depending on how
many walls are surrounding an access point, the [indiscernible] is going to
reflect that.
>>:
But it's not a property of the access point.
>> Shravan Rayanchu:
point.
It's a property of the environment surrounding the access
>>: It's a property of the transmitter is running to the access point. I have
a lot of walls on my left but no walls on my right, there's no such property of
the access point.
>> Shravan Rayanchu: Let me put it this way. It really depends on the
particular test case that you're trying to do. If I'm at a particular location
and you want to know, trying to see what are the number of walls between each
of the access points that I have a sample from, and if the duration of my
propagation loss exponent is good enough, for example to look at what is a
propagation loss in every direction, for example, you can do much better.
What we have is just a propagation loss experiment for every access point,
which might not take the direction into account for the actual number of walls
into account, but in some sense it does take [indiscernible] the granularity
takes the actual environment into account.
>>:
Okay.
>>: There's a much simpler explanation. Since you [indiscernible] there's
only one transmitter explains [indiscernible].
33
>> Shravan Rayanchu:
>>:
Yeah, so -- you had a question?
You're not taking anything about the building into account, are you?
>> Shravan Rayanchu: No.
which take the actual --
So I mean, there are a lot more sophisticated models
>>: [indiscernible] get there. I mean, if you [indiscernible] we actually had
a propagation model. It was modeling in there, but what we did certainly had
the attenuation factor for each wall. If you have that -- [indiscernible] you
get very precise. [indiscernible].
>> Shravan Rayanchu: So if you want to know the access points locations and
the actual map or something.
>>:
[indiscernible] might not be so unreasonable because most [indiscernible].
>> Shravan Rayanchu:
>>:
[indiscernible] that's where X, Y [indiscernible].
>> Shravan Rayanchu:
what works the best.
>>:
Sure.
Right.
Yeah, so we start off, take space into account and see
Are those results from deployment one or deployment two?
>> Shravan Rayanchu: So
you might notice this is
in this particular case,
a lot of random sub sets
four APs being active.
>>:
this one is actually from deployment two, where -- so
actually pretty dense deployment. So what we did is
which those sub sets of four access points and we took
like that and averaged all the deployment with just
[indiscernible].
>> Shravan Rayanchu: Yeah, so the experiment was where you have all these
access points, right, and we keep the transmitter at different locations and,
in fact, we use different device types, like cordless phones or, for example,
microwave ovens and look at the accuracy. This is an accuracy average over all
the device types at different locations.
34
>>: And are all these testing [indiscernible] access points or are they
outside?
>> Shravan Rayanchu:
>>:
They're randomly distributed.
Are they all [indiscernible] access points [indiscernible].
>> Shravan Rayanchu: I don't know how to answer that question.
this particular area.
>>:
I guess in
Up at the top left, 1366, was any of it outside --
>> Shravan Rayanchu:
No, no.
It was all inside.
>>: If there are exactly two access points, would the model produce the same
result as [indiscernible].
>> Shravan Rayanchu:
>>:
Two?
Two.
>> Shravan Rayanchu: Probably not. Simply because it's like a weighted
average in some sense. Like say based on the [indiscernible]. It's not going
to be the same.
>>: So centroid isn't weighting the average.
average?
It isn't using a weighted
>> Shravan Rayanchu: Sure, but the weight is going to be different is what I
mean. By [indiscernible] actually take the actual [indiscernible] weight and
the propagation loss model, it's going to be the actual [indiscernible] that's
going to enforce that weight.
>>:
Oh, okay.
So you could fix centroid by using a better propagation model.
>> Shravan Rayanchu:
Sure, sure.
>>:
Okay, all right.
So that's it.
>>:
There's another question.
Why is four meters enough and eight is not good
35
enough for what you're doing?
>> Shravan Rayanchu:
>>:
Sure.
I mean, so this is four access points.
Why not use all the access points?
>> Shravan Rayanchu: We can use all the access points. We were basically
experimenting with like different densities of access points and figuring out
what is the precision in each case.
>>:
Why [indiscernible].
>> Shravan Rayanchu: So the accuracy, of course, increases as we increase the
density. So in this particular case of four access points, it's four meters.
In the worst case was 15 meters, where it was basically, we could not really
increase the [indiscernible], but the worst case was much better when we have
much [indiscernible].
So I did want to talk a little bit about interference estimation, where the
goal here is basically want to quantify the impact of each device on each of
these wireless links. So in some sense, what we really use is correlation,
where we first identify what are the transmission overlaps between WiFi frames
and different WiFi device transmissions. And then we correlate this to the
actual frame losses that we happen to see.
So let me use one example so sort of how quantify the interference. So let's
say you have one wireless link, one access point and a client. And you have a
non-WiFi device transmitter, a cordless phone. And you want to find out what
is the impact of this phone on this particular link.
So let's say this particular wireless link transmits three WiFi frames and this
cordless phone is able to transmit to a non-WiFi device transmission. By
virtue of the fact that we're using the same clock to time stamp the packets
and analyze the pulses, and we will show time synchronization, we're able to
align the transmission timelines over here.
Once we do that, if you look at, let's say if you look at frame one, let's say
it's lost. Frame two is successful, and frame three is lost, right? So
basically, by looking at this, we can see whenever there is an overlap between
a WiFi frame and a non-WiFi device transmission, there seems to be loss, right?
36
So in this case, for example, the impact is one. So more firmly, what we find
out is what is the probability of loss. And given there's an actual overlap
between the transmissions. So that sort of quantifies the impact in some
sense.
So here's the one snapshot, where on the ground truth over here is basically
the actual impact of a non-WiFi device, which we find [indiscernible]
controlled experiments by knowing exactly when the device is and exactly when
the device is off. And on the Y axis, we have WiFi Net estimate, which we have
in realtime, but randomly switching on and off the device.
And we see most of the points are close to the line, showing that the estimate
is very close to what the actual ground truth is. And I have a CDF of the same
data on the right-hand side. And what we see that the impact that we
characterize is within 10 percent of the ground truth in most cases. So for
the most part, we are able to sort of accurately find out what is the impact of
the device in some sense.
And the idea of experiments, and I don't mean to bore you with the details of
this graph ->>: Question. On the last one, on the impact, do they impact in
[indiscernible] of the WiFi frames? Is the WiFi Net estimated the ground truth
that [indiscernible] rate of the WiFi frame [indiscernible] combinations.
>> Shravan Rayanchu: It's a loss rate given there's an [indiscernible], yeah.
So we try to do experiments with a variety of topologies, to try to mix in, for
example, WiFi and non-WiFi interference and also look at multiple device types.
And the goal here was to look at whether we sort of figure out the locations of
the device accurately and also sort of pinpoint the actual interference impact
on each case.
And the system seems to work fairly well in most cases.
So finally, I just wanted to talk a little bit about when you presented the
results of the identified, identification process, it shows that you were
accurate about [indiscernible], something like that.
>> Shravan Rayanchu:
You mean detection accuracy?
37
>>:
Detection accuracy.
>> Shravan Rayanchu:
Right, right.
>>: So did you do any evaluation of where the signal strengths below that have
impact, have significant interference and how does that play into this?
>> Shravan Rayanchu: That's a good question. So the thing is, there are two
things here, which is the signals at my detector [indiscernible] is minus 80,
but maybe there's a client which is close to that device, because there's an
actual impact. So the actual impact is very less when you look at signal sense
minus 80, for example. But it so happened that even though Airshark is able to
detect the device at minus 80, the device can actually have an impact on some
of the [indiscernible] much nearer that device. So that can definitely happen.
But however, given an enterprise setting where you have not just one node, but
you have multiple nodes, the hope is that you might find one node which is
close enough for it to be able to get the device correctly.
>>: So if there is an amount that you can't detect the signal strength is too
low and it's causing interference, can you at least say there is interference
[indiscernible]?
>> Shravan Rayanchu: Sure. So I mean I guess we could say things like I see
five devices in my list, and I'm able to sort of figure out what is the impact
of each of these five devices. So I guess if you're not able to detect -- if
any other node is not able to detect the device, all we can say is that there
are some devices or some links which are unaccounted for. But we cannot do
better than that.
>>: So I've got a couple of slides on the future work, which I wanted to talk
about work in the context of what I've been doing. And specifically, in the
context of like next steps in terms of like wireless or diagnostics. And
slightly more like broader interests and future directions.
So in terms of wireless diagnostics, at a very high level, what we're trying to
do is with systems that can improve our visibility into these wireless
environments, and the way we did, the way our approach was to basically build
systems for wireless monitoring and diagnostics.
38
And you see the four pieces of work, like COLLIE, PIE, Airshark and WiFi Net as
building blocks in this particular aspect where we looked at both WiFi-to-WiFi
interference and non-WiFi to WiFi interference. And we took support from
access points or the network to do this. And this is really scratching the
surface in some sense. For example, all of these approaches are very passive
in nature. So one approach could be to augment it with a limited amount of
active measurements and see how that can help us. For example, sending proofs
into the next work and trying to figure out what is the actual impact on the
device and see if we can sort of improve our accuracy by doing that.
And, in fact, another approach would be to even use the clients, where we could
see, for example, you can imagine a small piece of cord running on the clients
which can sort of help us give a you increase view of the system. For example,
we know where the client of the network is and see how that can sort of improve
the overall accuracy of the system.
And what we really want to do is learn through deployment and that's the
approach we're taking at least with Airshark. And right now, we have deployed
the system in one [indiscernible] and we're trying to see so this is a
primitive web interface of Airshark and we're trying to see how that can sort
of help understand the wireless environment in our [indiscernible] department
and we're working very closely with our network administrator in this case to
get their feedback on so if this [indiscernible].
And also, we are trying to currently commercialize Airshark. There are three
wireless vendors who are very much interested in this particular solution and
we're trying push it to the industry.
So slightly more broader aspects. So I think at the end of the day, what we're
trying to do is really improve the user experience in some sense. To do that,
one of the things is to actually build a solid platform for diagnostics and
management. Not just of wireless networks, but systems as a whole and even
applications.
And we're trying to see, for example, some of the projects where we're trying
to see how smart phones, for example in your environment can sort of be helpful
in this wireless diagnostics. And even if you look at home networks, there's
actually a completely different space where we don't have this advantage of
having an infrastructure that can help us diagnosis wireless issues. So it
39
remains to be seen how a single node system, how far can it push with that and
if it can somehow use a mechanism that can use information from multiple
[indiscernible] nodes and see if it can diagnose in the environment better.
And we also are looking at, for example, one of the things is how do you
[indiscernible] network speeds, for example. And go for smarter controlled
mechanisms and see how much of it can we actually push, for example, on
[indiscernible] WiFi cards. And also new technologies on the horizon, 11 ac,
60 gigahertz wireless, which a lot remains to be done in this aspect.
Of course, energy is going to be a primary bottleneck. It remains a big
challenge as to how do you make systems more energy efficient, especially on
these mobile platforms. And I want to look at, for example, optimizing
protocols and also look at specific support from operating system. For
example, simple things like enabling hibernation on the phones in order to sort
of save the battery power.
And one of the things to really look at is to look at the context and see how
an external context can be useful to sort of improve the energy aspect on this
particular -- on these mobile platforms. And finally, I'm also interested in
enabling new services and not only developing these services, but also sort of
developing the infrastructure for these services. So, for example, simple
things like indoor navigation. It has been, network localization has been a
problem for a long while, but it's still not solved.
Even, for example, enabling richer applications, not only using external
resources, not just the cloud, but also resources on the mobile device itself.
For example, things like GPUs, which are not yet being tapped into to see what
sort of richer applications can be enabled.
So that's sort of the general different thinks I'm interested in, and so for
that, I just wanted to thank my advisor and some of the students and mentors,
both at Microsoft research and even outside who I had a chance to work with
over the past few years.
>>:
[inaudible].
>> Shravan Rayanchu: So I think a lot of it has to do even with the first
step, which is that I think I found administrators don't even have an idea of
what is going on in the network. If a particular link is bad, why is it bad.
40
So I feel that is the biggest contribution. And coming back to your question,
which is, well, what can we do about this? So really depends on the type of
scenario and the actual device that you're looking at. For example, if it's a
narrow band interferer, you can do simple things like, for example, changing
the channel.
So if it's an interferer which is using the entire channel, there's not much
you can do, but just simply change the channels. But a lot of these mechanisms
can actually be implemented on the access point, once it knows what interferer
it's dealing with.
>>: Not a techy question. So why did you decide to focus on enterprise
wireless networks? Like you know, honestly, I [indiscernible] and maybe this
is particularly bad. Why don't I move to a more challenging environment like
[indiscernible].
>> Shravan Rayanchu:
>>:
So --
[inaudible].
>> Shravan Rayanchu: So the [indiscernible] actually started with the fact
that at least in Wisconsin, for the last one and a half years, we probably
changed our wireless vendor twice and it's mainly because of the issues that
we're facing on the network.
So I think [indiscernible]. But before that, it was Zerus at some point. So
the issue was, in fact, I can quote you one example with Zerus. It so happened
that, you know, we were not able to connect with the network or there was a lot
interference. So the Zerus engineers were actually on the site for a couple of
days, and they came up with this -- the first time they came, they can't really
account for what's going on.
And on the second visit, though, they actually came with like spectrum
analyzers and they pointed microwaves and the cordless phones as the culprits
for the amount of -- for the [indiscernible] that was going on in our
department. So that was actually the turning point for the project, where we
said well, these guys are saying the problem is because of these non-WiFi
devices. We do not have any solution or infrastructure that can actually
evaluate the problem. Because even their sampling was only for two days. We
wanted to be sure that is actually the problem.
41
So that is actually how we started working on the problem. And I think we
chose enterprise networks mainly because of the trouble, at least in our
department.
>>:
So finish that story.
So after that, you --
>> Shravan Rayanchu: So at that point, we were deploying it and we want to
measure it over time and see if that is actually causing trouble. Because even
at least the engineers from Zerus, for example, were able to find out that
there's a lot of non-[indiscernible] activity. But they can't account for.
But is the [indiscernible] activity responsible for any loss we were able to
see on the link. That answer from them was not definitive. And that's what
we're trying to solve right now.
>>: What are some new things that might come up in [indiscernible] in the next
few years.
>> Shravan Rayanchu: So, you know, I think for example, simple as you go
further, especially with like 11 ac and things like that, clearly you can have
much wider bandwidth. In that case, especially if you're talking about what
can we do with these kind of approaches, you know, we had this problem,
hopping, for example. Which we don't have to deal with anymore. And our
personal sampling will be much higher and we'll see only see the accuracy of
the system improving much further with that kind of functionality.
And even clocks on the WiFi cards are getting, I think, much better in their
position, and simple things like indoor navigation, which traditionally, we
have been using things like RSSI, which probably we can solve the problem much
better by using these much finer clocks. Simple things like time of
[indiscernible] or time difference of [indiscernible], those kind of mechanisms
which can be enabled bu these newer cards that are coming out.
>>:
Have you tried them [indiscernible].
>> Shravan Rayanchu: No, no, because we don't have access to that sort of
hardware. But I think the new chip sets.
>>:
[indiscernible].
42
>> Shravan Rayanchu: Actually, I'm a little [indiscernible], and they are
using that and they seem to quote a very high precision, like one to two
meters. And I think they [indiscernible] Congress is like a feedback.
>>:
I was there.
[indiscernible] other sensors.
>> Shravan Rayanchu:
folks.
>>:
At least that's the information I got from the Qualcomm
[indiscernible] new access point [indiscernible].
>> Shravan Rayanchu:
[indiscernible].
>>: I suppose as you discussed, you have a situation where you know there's
interference, you don't have enough access points. You know where it is.
Would your system in the future, perhaps suggest hey, open a probe here and
then I can tell you what's going on?
>> Shravan Rayanchu: So I guess, yeah, maybe for example, if you were to have
a bunch of access points. The view that we're getting about the spectrum, you
might be able to figure out as to figure out if there is some interference
which would not account for. But if you know roughly where it exists, then
maybe you can do that, yeah.
>>:
So let's save the question for the other meeting and let's thank him.