>> Jin Li: It's a great pleasure to have Suman Banerjee here to give us a talk.
Suman get his PhD degree from the University of Maryland, and now I just
learned he become associate professor, just get his tenure -- 10 years -- 10 -sorry, 10 years back, sorry. And he's going to talk about his WiNGS lab,
Wisconsin Wireless and NetworkinG System laboratories. It surely is a very
interesting name. And let's hear what Suman has to say.
>> Suman Banerjee: So thanks, Jin, thanks for inviting me here, and it's a great
pleasure to be back. So I'll -- you know, when I'm coming here to give a talk, I
need to make sure I get to say something new. I've been here multiple times in
the recent past I've talked about certain things but thankfully over the last year
and a half we had a lot of interesting activities and I'll try to cover some of them
getting through all of them of course in this time wouldn't be feasible.
And this logo of our lab is actually designed by one of our grad students who is
an intern here, Vladimir. So very good in artwork. Highly recommend him for
any logo design for any new conference or workshop that you may have in mind.
Although we have a newer version of that logo.
>>: [inaudible].
>> Suman Banerjee: That's okay. No, he's pretty good. In research as well.
>>: [inaudible].
>> Suman Banerjee: So anyway, so what I want to talk today about is a theme I
think everybody here already subscribes to, so it won't need a lot of motivation.
But basically I want to focus on building robust wireless network services through
infrastructure support. Previously we did a lot of work focussing on client
supported services where you kind of install specific things in that lines. Today
I'll focus on infrastructure support for a set of specific services, specifically
targeting enterprise wireless environments, but some of the ideas of course apply
to fairly generic A2211 like wireless environments.
So just a quick you know run through the initial motivation, you know any
enterprise would like to tightly control all of their resources which includes of
course office space, natural bandwidth, applications devices and definitely the
wireless spectrum.
So as we all know, wireless spectrum is a challenging thing to really control
because it's a shared resource, the spectrum doesn't respect building perimeters
so you may have intruders who are located outside the building can easily kind of
extract signal out of transmitters inside the building which becomes a major pain
point for many IT administrators. Yes?
>>: Do you know of cases where IT admins are actually worried or actually
detected such intrusion? Like I see a lot of work being motivated by such a
scenario, but I haven't come across any incident.
>> Suman Banerjee: Yes. That's a very good question. I think it's kind of a fear
factor I guess for more of the financial institutions I hear like you know if you go
and for example talk to Cisco, they will say that this is a capability that their
customers worry about who the specific customers I don't exactly know. I don't
think most university campuses or even regular, you know, campuses like
Microsoft would worry that much about it, but they seem to worry about it. They
seem to feel that, you know, we need to make sure this is true, but I don't know.
I don't have a very good answer for that. I wish I did.
>>: [inaudible] and there's a [inaudible] infrastructure. [inaudible] that they don't
trust any device [inaudible].
>>: They are [inaudible] their own.
>>: Including their own.
>>: Sure.
>>: So I mean basically it means having -- plugging into this jack it doesn't mean
the device belongs to the network. It depends on other [inaudible].
[brief talking over].
>> Suman Banerjee: Right. So I think his question is whether somebody just
eavesdropping sitting outside the building, is that a real threat, parking lot
access, what basically people worry about. There are examples of incidents
which are, you know, like I think there was that I think the Mumbai bomb blast
what last year and seemed that the perpetrators actually attended e-mails by
high jacketing somebody else's WiFi. Now, you could think of that you know,
somebody outside the building is actually hacking into your network.
So that is -- that is, you know -- you're not eavesdropping, you're accessing the
network so if you knew that this person was physically not present inside the
house, I would not let his signal inside.
>>: Well, that just seems like a [inaudible] rather than ->> Suman Banerjee: True. But there is issues with crypto, too. I mean, you
have to configure people have higher -- if you had a simple way of saying, okay,
the signal doesn't go out or you cannot penetrate from the outside or I can detect
the outsiders easily, then ->>: But it is the thing, right? I mean, that's always the function of how far
[inaudible] I have [inaudible].
>> Suman Banerjee: Sure. Well ->>: There is no such thing as signal doesn't penetrate.
>> Suman Banerjee: True. But even if you could figure out -- you have a strong
or a sensitive antenna and you can get in, in fact if I want to localize you, I could
still try to prevent you from getting in, I guess. Okay. It's not a very strong
example. I'm not trying to claim I have an answer to that but, nevertheless these
are the different scenarios that I will try to focus on. So again, this is something
very well understood here. Early on we had enterprise wireless LANs which
were very distributed in nature and effectively each access point was asked to
fend for itself. So everybody fought for their own channel access, they decided
their own channel, channels to use, AP [inaudible] and all of that. And today we
are moving towards a much more organized structure where it's almost like a,
you know, a legion where there's a controller that manages all its soldiers or all
its access points.
And besides a bunch of parameters for these access points which makes things
lots more streamlined. Okay. So within this framework, what I'll try to focus on is
how this approach can be utilized for a few specific solutions that we looked at.
So one of the things that I'll talk about is achieving high throughput through data
part centralization, and I think that's a very interesting question in itself that lot of
the control mechanisms like channel assignment, load balancing and bunch of
other parameters have been centralized. But the key decision of whether or how
or when you access the channel, can you centralize that, can you take the
decision in the controller? That's one question we'll try to look at. And of course
it will be based on some kind of scheduling mechanism. So we'll look at that.
Then I'll look at energy efficiency and we'll look at some techniques on which
controller can facilitate the mobile devices to be energy efficient by specific
mechanisms.
Then I'll talk about some rich media services. This will be a very short part of my
talk towards the end, how the infrastructure can facilitate improved media
services in the environment.
And finally I'll talk about security capabilities leveraging the infrastructure. Okay?
So let me get started with the first question, which is -- yeah?
>>: I guess a sense of like in doing this what are you will to change and what are
you not willing to change?
>> Suman Banerjee: So, yeah, that's a good question. So the question is what
do we want to try to change when we try to implement some of the services.
Ideally our goal here was to do most of the things only in the enterprise so that
you can come in with any arbitrary client, you don't have to come in and
physically modify all the clients. But in some cases you cannot do that, and you
have to make changes on both sides.
So there are advantages of doing changes only on one side of the -- one side of
the environment.
>>: [inaudible] but I also meant like in terms of hardware [inaudible].
>> Suman Banerjee: Okay.
>>: [inaudible].
>> Suman Banerjee: Right. So almost everything I'll talk about can be built on
A2211 without making any changes to the standard. So I'll answer this question
individually for each component. So we don't have a unified strategy for
everything, so in some cases, you know, because of what gains we get, it might
make sense to do more. Maybe make formal level changes. In some cases we
can live with only simple driver level changes at access points or at clients.
>>: [inaudible] you can say after the fact, after the design what you need to
change and what not. I'm trying to get a sense of like as you -- as you approach
the problem itself, like did you place constraints on yourself?
>> Suman Banerjee: Yes. So we did place -- and again, I'm kind of integrating
different pieces of work, so it's not going to be a consistent answer every time. If
we constrain it if a certain uniform way, in some cases the amount of risks you
can get reduced. And obviously more changes you can make, the better you can
do. So there is a trade-off.
So the first one, let me kind of do it, take the first one is an interesting example
where the goal is to kind of do scheduling or accessing the medium in a
centralized way. And our goal this was to not change the A2211 standard at all
but provide a little bit of simple API from the access point by which we could
manage the spectrum and not change the clients at all.
>>: So I'm just follow up the discussion a little more.
>> Suman Banerjee: Yes.
>>: We looked at this and I sent you the paper yesterday.
>> Suman Banerjee: Sure. Yeah.
>>: The SIGCOMM paper and the [inaudible] paper. Here's the thing. It's a
matter of where we draw the line. I mean it's not so much [inaudible] change the
API or the [inaudible] although that's the main distinction in terms of [inaudible].
>> Suman Banerjee: Right.
>>: But [inaudible] think about whether you want to keep this [inaudible] right
and in an enterprise environment, and you have full control, why do you want to
keep the system [inaudible] all these papers that say [inaudible] is so much more
efficient and ->> Suman Banerjee: That's exactly what this work was motivated by. And I think
that you need to keep the CSMM map to some extent because you have to
coexist with others. Even though it's an enterprise environment, we don't want to
change the clients, which mean the clients are going to use CSMM map so you
have to coexist with that. And you may have known enterprise traffic which is
maybe peer-to-peer traffic for some specific application, so you have to coexist
with all of that.
So if you could -- if you could change the clients and say I'll have a TDMM map
across everything, then sure, you can change the CSMM map. But here we will
not try to change that.
Okay. So this is the question. So we really kind of saw you know a bunch of
papers, mostly I guess simulation based which showed that if you could do a
very good scheduling of course you get this very nice efficiency. So is there a
real role for centralized scheduling in enterprise wireless LANs? And if you think
of a distributed multihub wireless environment, one of the challenges is if you
want to build a schedule of traffic across all of these nodes, you need to really
know who has what traffic to send and when. Okay? Which means you have to
aggregate all this information in a central point, which means there is overheads
in aggregating all this information.
And what will we really try to leverage is that the enterprise has a nice structure
that can allow us to get this information for lot of the traffic for free. And that's
what we'll try to leverage in this work. Okay?
So let's look at this with the very simple example. So here is a very simple
enterprise network with two access points, a few clients. And we have an edge
router. We assume that all the traffic that is dominate in nature goes through this
particular edge router. Okay?
And what happens is let's say these two access points happen to be hidden
terminals to each other, that means access points cannot send to each other but
the clients will of course get interfered with each other if the two access points
transmit together. And now let's imagine there's a red packet and a green packet
intended for these two clients, red and green. And typically in the DCF model
what will happen is these two packets will get sent to the different access points
without any special mechanism in the router, and then eventually the access
points will do a carrier sensing act, they will not sense anything, and then they
will transmit, they will send the channel to be free and they'll transmit and that will
lead to collisions, backoffs, loads, throughputs, all of that will happen. So hidden
terminals are a very known problem in this setting.
Now, how do -- how can we -- so why is this an important problem? So some
people feel that, okay, hidden terminals, maybe they -- do they occur once in a
while? Is it an important problem, do we really care about it in terminals? If you
really went ahead and did a very nice placement of access points in the
enterprise, maybe you can eliminate all possible hidden terminals, right? But if
you really look at the picture here before, the reason we had this hidden terminal
was because of the location of the clients, it is not because how you place the
access points. So clients can show up somewhere and they create the hidden
terminal with respect to the access points and you cannot avoid it, okay.
So there is a reason to believe that hidden terminals occur even if you had the
best assignment of channels and the best assignment of location of access
points.
>>: [inaudible] anything about like the spatial distribution of clients like if you
look at [inaudible] like stationary clients tend to cluster in specific places.
>> Suman Banerjee: Sure.
>>: Like lounging, conferencing, what not. So it's unclear that you're arguing
that you will [inaudible] in that setting.
>> Suman Banerjee: So I'll give you some numbers. These are -- so here they
have some measurements we did were from office building like here where you
have clients sitting in each office and working on their laptops. And yes you can
have, even if you're sitting in lounges and maybe in conference rooms, if you are
unlucky and two people connect to different access points, you can easily have a
hidden terminal scenario. If you are ->>: [inaudible] access points that aren't on the same channel.
>> Suman Banerjee: Well, I'll give you examples. And these are really
measurements, okay. I'm not -- and let me explain this plot first, okay. So what
we did was these were using regular production enterprise wireless LAN. One
happens to be of course in our CS building in Wisconsin, and the other is in
Waterloo, University of Waterloo, and the two production networks are very
different from each other. Ours is a Cisco based network. They're all manually
deployed. The IT administrators went and figured out where to place the access
points. They manually assigned all the channels. We had nine access points in
our -- in the five floors that we are considering, actually. And they did channel
assignment. Okay?
The Waterloo network is actually Aruba network and Aruba has lot more
sophisticated algorithm, they actually have a little more denser architecture, they
place more APs in the environment, and they have a dynamic channel
assignment scheme. So they're always changing their channels, okay?
And then what we did the -- and so this is we didn't change anything in the
network. We went basically placed our nodes in different rooms, as if they were
like people sitting in different desks. Okay? And then what we did is we allowed
these different clients to do peerwise tests and see what the throughput impact
is. Okay?
So this plot what it shows -- so on the X axis you have a bunch of AP client links.
We had about 45 and 51 clients in the two networks. And let me see here. Oh, I
think -- yeah, this is fine. So basically what this plot shows is the reduction in
throughput that happens when the two links went together compared to when the
links went in isolation, okay. So if your reduction is .5. It means that you just
equally share the channel, right? That's perfect. If you're in isolation versus
you're sharing it with somebody, you get half the throughput. That's what you
would expect modularly to rate and all those things.
Now, if you go significant below .5, that's a kind of a hint that there is hidden
terminal interference happening that you are not able to control. And so what we
found was that a reasonable -- sorry, so throughput reduction, so above .5 is
hidden terminal. Below .5 is not hidden terminal. Okay? Below .5 actually
means that you're not really interfering, so that's why your reduction is almost
zero. Okay?
So we had about a third of our client AP pairs, a third of our client AP links had a
hidden terminal from another client and some of them went up as high as close
to almost zero throughput, okay. So it's anecdotal evidence from two networks
but it at least shows that, you know, you cannot plan things accurately because
even if you have two weak access and some clients placed and connected to
these channels, you're just hosed, you cannot do anything. And even though I
would -- you know, you could argue that, okay, there is only five or six clients that
are getting really impacted and others aren't, let's not worry about the problem
too much. The problem is that these five people are not getting any throughput.
So these five people are completely hosed, even if you feel that this is a small
problem, those guys are completely hosed. So you really want to solve the
problem for these people. Yeah?
>>: Except for the [inaudible] bossy nature of data, right?
>> Suman Banerjee: Right. So ->>: So they're not -- I mean they're not completely hosed in the sense like ->> Suman Banerjee: Not all ->>: [inaudible] interfering with not using a link all the time.
>> Suman Banerjee: Right. I agree. So of course if the two are not active at the
same time there's no a problem. But it's still a problem in general. They can't
always, but sometimes you can have two people using the network at the same
time and you get this very bad performance. So it's still a problem, you know,
how important the problem depends on the volume of traffic and other things and
that's, you know, hard to argue about what user behavior will be like going
forward if everybody starts watching video all the time, you know. You cannot
really comment on how severe the problem will go. But I think the problem
exists. So it needs to be examined at least.
Okay. So let's look at exposed terminal next. And what we did was the
challenge in kind of quantifying how many exposed terminals exist in a real
production network is very hard because everybody does carrier sensing,
typically. And once you do carrier sensing, you cannot know whether there was
an exposed terminal or not. So we had to do the exposed terminal experiments
on our test bed. So what we did was we described by think in this experiment
there were 30 nodes and we kind of treated them as different nodes as client AP
pairs. We kind of chose the APs to be the nodes that were closest to the
physical APs in the infrastructures kind of mimicking the behavior of the wireless
production network.
And here what the plot shows on the Y axis, sorry, X axis, you have the fraction
of links on the Y axis you basically have a ratio of throughputs. The ratio is on
the numerator, you have no carrier sensing, that is if exposed terminals could be
exploited, that is if toolings could actually transmit you could transmit.
On the denominator you have carrier sensed throughputs which means if
exposed terminals could be handled then you would get the higher throughput,
right? Which means that if you look at the line which says one which that means
anything that is below that or equal to that, those are not really exposed
terminals. Anything above that are exposed terminals. Okay?
So we have some links that are perfect exposed terminals in our test bed and
essentially if you could handle exposed terminal you get double the throughput,
okay? So both of these problems exist in one little -- explained through the
production level in our test bed, but both are at least significant enough that they
can be -- that they can allow us to get some [inaudible] okay?
So we believe that there's a lost opportunity here because we could do
something by scheduling and the enterprise wireless LAN environment has some
very unique capabilities that allow us to do the search scheduling okay. So why
is that? So imagine that this edge router actually could somehow create this
conflict graph which basically says which links interfere with each other in the
enterprise environment, okay? So it has this image of this conflict graph with
itself. And when the packets show up, it looks up its conflict graph and it knows
that if the red and the green packet were to be sent together, they're likely to
interfere on the channel, okay. So this information in somehow, somehow was
available at the router because it sees the two packets come to it, right, it's the
only point through which all the packets go. So it knows this information. But
once you send it out to the APs, this information is lost, the APs don't know
unless you have told the APs something about what the parts look like, okay?
So what we could potentially do as a very trivial example is send out the first
packet, the router sends out the first packet and just holds the second packet for
a little bit of time and then sends out second packet after delay, there by
mitigating the fire interference. Okay. Very simple idea.
And again, this is only possible for the downlink packets because all these
packets are going through the single router and cannot be done for the uplink
packets. Okay.
So basically what we first did was we went ahead and implemented a simple
scheduler for only downlink packet. And it's a five-foot scheduler so you want to
take the next packet and try to schedule in it a conflict-free way based on the
conflict map that you have generated. So for conflict map generation we use the
technique that [inaudible] and his students had designed called smart opp. And it
has some very good properties, allows us to, you know, be efficient in terms of
detecting these conflicts. And we did the scheduling. So we call this first
iteration of the solution deterministic scheduling or det okay?
And here is some initial good news. So if you had two links hidden terminal
topology and depending on what is your load on the two links, det can improve
on DCF, okay. So basically X axis is the load per link and we are increasing the
load. And here in the experiment what we did was we fixed the data rate to six
megabits per second. On the right-most one you basically have fully loaded, fully
saturated links. Yeah?
>>: So I'm guessing the effectiveness of this depends on carrier sensitive links
and also the wire line to ->> Suman Banerjee: Absolutely.
>>: Wireless to lay off [inaudible].
>> Suman Banerjee: Absolutely. And I'll talk about that, too. Yeah.
So the good news is that we did -- we did some modifications, we optimized the
delays on the part, we did some modifications to make the Ethernet driver to the
wireless driver part very efficient. It doesn't go through the kernels so it's like a
memory copies that reduces the variability and the latency in that part. We of
course implement our scheduling in the kernel so it's as optimized as we could
do without, you know, having a realtime operating system running on these
nodes. Okay? And the good news is that that which is very simplistic gives you
significant gains and hidden terminals when the tools are highly loaded, which is
actually good. Of course if the link is not saturated, then there is no gains
because there is not enough traffic, which is fine, that's not a problem.
So in the common case it's not a problem. In the heavy case you actually gain,
so that's actually where we are doing well. Okay?
But the bad news is that now I'm showing the same kind of experiments but for
hidden, exposed, and scenarios which are neither hidden nor exposed. Okay?
Or basically they're regularly interfering links. So hidden is very easy to gain
performance because of this -- this here does very badly, right, so it's easy to
beat hidden terminals.
Exposed terminals of course we have not done anything with carrier sensing, so
we cannot do anything, we don't gain any performance gains. And then for the
non-hidden, non-exposed terminals it turns out in the high load case we actually
lose a little, and that the precisely because of the scheduling and efficiencies we
still have in the system. We could not eliminate everything and slight delays and
slight amount of carrier sensing associated with the delays can destabilize your
scheduling scenarios and leads to performance problems. Yeah?
>>: [inaudible].
>> Suman Banerjee: Yes. So we actually have experiments which show that
there are certain hidden terminals that cannot be solved by RTS/CTS either, and
RTS/CTS gives you a significant penalty. So we have numbers I'll show you
which shows DCF, DCF with RTS/CTS and R schemes. Now, adaptive
RTS/CTS is useful, only if your hidden terminal is showing up now and then. If
the hidden terminal exists adaptive becomes all the time RTS/CTS.
>>: So by adaptive means you turn it on only when you see for terminals for
specific client AP links?
>> Suman Banerjee: True. But for those links you always turn it on effectively -I mean, so long as you don't move roughly, right? So adaptive is equal to, you
know, nonadaptive when the hidden terminal links persist, right? And we'll have
some numbers to show what happens with adaptive, basically RTS/CTS
enabled. Yeah?
>>: [inaudible] the case you are showing that the router did the scheduling ->> Suman Banerjee: Oh, so -- right. So we -- I kind of didn't really mention this,
but we put a special machine on the part.
>>: [inaudible].
>> Suman Banerjee: Yeah. So ->>: So if you have more than two APs, I saw the efficiency of the system would
decrease.
>> Suman Banerjee: Right.
>>: [inaudible].
>> Suman Banerjee: Everything has to pass through it, so if you imagine this is
like a little more complex function but happening at the fast part, if you could
implement this at the -- on the line card.
>>: Not the [inaudible] the thing is I mean that router cannot issue a packet
faster than the wireless basic speed. I mean ->> Suman Banerjee: You're right. So basically one scheduler can handle a
certain number of access points and then you have to get another one. So you
have to -- if you scale, we could actually do with 10s of APs. So we went after 20
APs, one scheduler was sufficient.
>>: If you're using [inaudible] am I right each AP can at the most get one tends
of the bandwidth for the normal wireless network [inaudible] I mean because
otherwise it would be scheduled too quick.
>> Suman Banerjee: Right.
>>: You still run the risk of ->> Suman Banerjee: You're right. But our backlink can be a gigabit Ethernet, 10
gig Ethernet, which is way faster than your wireless link speeds if you think of the
nominal rates that you actually get.
>>: What I mean is this wireless link on the wireless link each packet were
[inaudible] by a certain ->> Suman Banerjee: Yes, yes, exactly.
>>: At some point each -- let's say a kilobyte packet usually will occupy
somewhere between one millisecond and ->> Suman Banerjee: Right. Exactly. One millisecond per milliseconds or less.
>>: Something like that.
>> Suman Banerjee: Yeah.
>>: And in order to not to conflict, you have to space the packet far enough so
that when they fend down to different APs, they will have no chance of collision.
>> Suman Banerjee: Yes. Exactly.
>>: On the open space.
>> Suman Banerjee: Exactly. Right.
>>: And that means that each of the AP will only be able to handle a foundling
bandwidth which is inverse proportional to the number of AP divided by the
wireless deposit.
>>: That will only be for the conflicting ones.
>> Suman Banerjee: Right. So those ->>: The ones that are of the same channel.
>> Suman Banerjee: Right.
>>: You need to find which one that is.
>> Suman Banerjee: Right.
>>: That's what we are doing.
>> Suman Banerjee: Right. That's exactly what we are doing. So if links are not
conflicting, then we just let them go.
>>: [inaudible].
>> Suman Banerjee: Yeah.
>>: [inaudible].
>> Suman Banerjee: Yeah. I mean you couldn't do better than that anyways,
right, exactly. Okay.
So the problem we had were with the exposed and the non-exposed, non-hidden
terminal scenario is one of the challenges with the exposed terminals is that it's
not very easy because one approach to really handle exposed terminals is to
disable carrier sensing, and I believe that like the C map there's work from, what
it, MIT, I guess, right, the C map work kind of proposed the same link area
sensing in a certain way and they kind of were not focussed on the hidden
terminal problem as much. And we feel that it can be very detention to
completely disable carrier sensing, okay? So that's one of the problems. And
sorry, I missed a slide somehow which I'll try to find. But there is basically we did
this detail benchmark of where the various delays are on the part between the -between the controller, the access point and the client. And we basically see all
the variability in the order of tens of microseconds to hundreds of microseconds
in scheduling decisions and many of these variability comes from not being able
to know when due to carrier sensing the packet actually goes out in the medium
and there is also we need to get a wired acknowledgement. So when the Mac
layer app comes back to the access point, the scheduler needs to eventually
know that this packet got scheduled. So there is other delays that are built in,
which makes things very hard. So these are basically the two things that we had
to deal with, okay?
So the final design that we kind of moved to, we called it SENTAR, and it tries to
mitigate exposed terminals without disabling carrier sensing, okay? And what we
did was we actually fixed the amount of backoffs that we are scheduling. We
kept carrier sensing on. We fixed the amount of backoffs to be the average
backoff period that you would use between CW min, so between zero and CW
min, okay? So half of CW min is what we used. And we schedule in epochs,
okay? So what that means is when I get traffic for a particular access point I
don't immediately decide to send it out, I group traffic in units of time, say, two
milliseconds, five milliseconds or ten milliseconds. And I basically schedule this
epoch at different access points, okay?
And the advantage of scheduling in epochs which means that your group,
scheduling a bunch of packets together is that you really are able to hide lot of
the variability in the downlink because the -- now the variability becomes much
smaller because the epochs are kind of going together, and that really helps us
benefit in the exposed terminal case. And one other thing that the epochs really
help in terms of exposed terminal is that suppose you want two packets to go out
on the link at the same time, right, now suppose one packet just goes out, you
know, a little before the other packet, right. The second access point then if it
does carry a sensing will sense this packet and will not be able to schedule the
packet because scheduling sensing prevents it from the sending.
But if you send a bunch of packets together to the two access points, then the
first packet may happen by going out first, but after that, they will get perfectly
synchronized, okay, because they have these fixed backoffs and they will -second packet when they try to carrier sense both together with the medium
[inaudible] and they will simultaneously send out packet and all the packets
subsequently go completely in synchrony to the clients. And then the problem
basically kind of be solved because you have achieved the synchronization by
allowing the first packet even though it's offset to go out first.
Okay? So that was one of the tricks that really helped us in managing exposed
terminals. And then we could basically because we'd only said well, carrier
sensing we can coexist with uplink traffic, okay? And we used another trick to
coexist with uplink traffic which is what we call a hybrid data part, okay? And
which is -- which is a motivation for our name SENTAR, which is partly
centralized, partly distributed, like partly man, partly horse. So SENTAR
basically has a structure where if you think of this special five full scheduling
system what it will do is it will examine the packet and make a decision, is this a
hidden terminal or an exposed terminal packet? If yes schedule, if no, just let it
go. Let it go on the DCF. Okay in and that reduces the burden on the scheduler
because we don't have to schedule a lot of packets. A lot of packets are
probably just non-hidden terminal, nonexposed terminal. So we just let them go
on the DCF path.
So basically if you identify from your conflict graph maps which ones are hidden
terminal scenarios, which one are exposed terminal scenarios, we'll only
schedule those packets and not worry about the rest are. And it really simplifies
the load on the scheduler and it's also very intuitive because for problems that
DCF can solve, why bother trying to put in all the scheduling mechanism to make
it messy. So just simplify the problems and handle only the corner cases that
DCF is unable to solve. And that really works quite well. Okay?
So now I'll show you target instead of experiments that we did to validate that this
really is a good idea. These are two plots, so the one on the left side is the
exposed only terminal scenario which means that all our links we were able to
basically create exposed terminals by adding carefully placed node which will
behave as an exposed terminal to that link. Okay? And on the E axis you have
throughput, on the Y axis, basically it's a CDF of how many links had the
throughput. So the first line over there on the exposed terminal case turns out to
be that very thin red line is a SENTAR with epochs of two milliseconds, okay,
which is actually pretty bad. It is the worst performing scenario. An epochs of
two milliseconds is not good enough for us to actually benefit or to leverage the
exposed terminal existence because our scheduling granularity is not small
enough. It cannot handle two milliseconds, we need to have at least a five
millisecond granularity so that the synchronization actually kicks in and that gives
us the performance gains. Okay?
And then basically the second, the black line, the solid black line is DCF, okay?
In this experiment we did not do RTS/CTS because RTS/CTS does not have the
exposed terminals, but in the hidden one, we did. Okay? And then the next two
lines, the light red and the deep red line, they are SENTAR with epoch durations
of five milliseconds and ten millisecond, okay? So you can see a significant,
nearly a factor of two throughput gain. This is a purely exposed terminal
scenario. And these are I think about 19 -- a total of 19 nodes all organized so
that they're all exposed terminals. So the very construed example to show that in
exposed terminals we get various gains by using a certain epoch duration and
with SENTAR.
And the last docket line is the ideal case which means that if you are to disable
carrier sensing in absence of anything else, what is the best you could do.
So we are kind of approaching the best, so which is pretty good that we get
almost a factor of two gain in all the links as far as we can tell in the scenarios we
have tested. Okay? Then you go to the next one, which is a hidden terminal
only topology. So all links basically here are hidden terminal, everything's
downlink in traffic. And the first line that you should look at is that dark black line.
That is DCF. Okay? So what happens in DCF is the hidden terminal is -- is
when there are hidden terminals, some links will really suffer, and when some
links suffer, basically they don't get to transmit which means some other links will
get to transmit and occupy the channel all the time, right? So there is huge
unfairness. Some links get no throughput, others get all the throughput because
they see the channel is empty. Okay?
So you had this distribution where maybe 50 percent of your links have very little
throughput and about maybe 12, 20 percent of your links have all the bandwidth
highly unfair scenario. Right? And then the dotted line is RTS/CTS, and it has a
little bit better, it mitigates some of your hidden terminal problems but not
enough, and it does a little better than DCF. And all our SENTAR schemes
which are in red actually is able to distribute the bandwidth all across, you know,
most of the clients that we see.
So we have a very nice improvement been throughput and actually the
aggregate throughput is conserved in the two experiments, they're very close to
each other. So the big gain in hidden terminals is not that you'll get more
throughput overall because finally the -- so long as your environment is fully
utilized that's the best you can do, but it balances the fairness across both hidden
terminal and non-hidden terminal links. So that's what we basically -- we
basically get in this. It's initial validation that the mechanism that we have
proposed are achieving the expected gains that we hoped, okay?
The next microbenchmark that we did was look at what happens with -- so the
previous one was only downlink traffic, which was, simpler because we are
scheduling everything. What happens with uplink traffic in the mix? Okay? So
in this example what we did was we had a pair of hidden terminal links and uplink
traffic, also operating in that environment. And we did hidden terminal plus
unscheduled, unscheduled is uplink and exposed terminal is unscheduled. And
what you can see is that with DCF, the hidden terminal software, the uplink gets
a lot of the bandwidth and with SENTAR, you know, the throughputs, the hidden
terminals are mitigated and the uplink doesn't suffer, okay?
And in fact, in all our cases the uplink also gains because when you mitigate
some of the hidden terminal problems, the channel utilization becomes better
and when the channel utilization becomes better, everybody gains because
everybody gets a little more of the channel because there is less collisions, less
losses. Okay? And it happens for both cases.
So at least uplink can coexist. So these are the initial microbenchmarks. And
then we did a large number of studies on different topologies with different types
of traffic. So these were, you know, kind of painstakingly done by my students,
so I'll go through a few of the slides to explain what happened.
So these were experiments on mixed topologies. So you had hidden terminals,
exposed terminals, regular nodes, all of that. And the top most set of bars
basically have DCF, SENTAR with two milliseconds, SENTAR with 10
milliseconds, and each bar corresponds to a client. There were 9 APs and 12
clients. So each bar is a client. And you have variances in all of that. The high
level bit, so the top level set of bars is UDP. Then you have TCP, then you have
delay, not just throughput. So throughputs and then delay.
And in general, we improve across all of the cases, you know, just looking at the
first set you can see that the average aggregate throughput gain across the
entire network is about four to six percent and the biggest gains of course come
to the hidden terminals in that case, 1.8 times of their DCF performance and
exposed terminals also get a more than 50 percent gain in many cases.
So overall, in a mixed topology we perform pretty well. There is a bunch of other
experiments. I won't go through all of them. It shows what happens when you
have a mix of uplink and downlink and you chain the ratio of the uplink to the
downlink. So you know, the gains are kind of persistence across all the
scenarios when we varied the amount of uplink and downlink.
>>: Okay.
>> Suman Banerjee: In the previous set of results I say that -- yeah, go ahead.
>>: [inaudible] on or off?
>> Suman Banerjee: So in the previous set of experiments we did fixed rate just
because it's easy to interpret the results. We did also different rates and then we
did auto rate. And you know, the gains persist. And the really -- the higher the
rates and the auto rate actually is even more beneficial to us because we are
operating on larger blocks, and so long as we can predict how things are
behaving we are estimating the delays on the parts we can actually schedule
things pretty well, whereas, you know, DCF goes into, you know, rate adaptation,
with hidden terminals things get very bad with rate adaptation, because it's really
not the rate which is the problem but the hidden terminal which is the problem.
So auto rate actually makes it even better for us. Because rate is not the
problem when they're hidden terminals, that's really the high level thing. So we
have experiments.
Now, this was another interesting experiment which is basically playing back real
traces on the same network. So what we did was we took the SIGCOMM 2004
traces which were bunch of web downloads people were doing and we played
them back from the clients and which of course clients and request data comes
back and this plot shows distribution of delays in downloading that web pages or
whatever they were for all the different sessions that were run and sorted by the
transaction size, size of the file that was being fetched. And basically we get
delay gains over the fetch durations for each of these web downloads.
We did more experiments with web traffic looking at opinions, core and so on,
and all of them were pretty good. So overall, based on the amount of
experiments we have done, we feel that this is a fairly robust solution for an
enterprise setting because it doesn't hurt people who are non-hidden,
non-exposed and it really gains when they are hidden and exposed. So overall,
you know, we don't lose much, but we gain a lot. So it's kind of a solution that we
are very comfortable with in kind of proposing for enterprise environment.
And the advantage here is that we don't require any client level modification.
Everything -- any change that we have done is only at the axis point and the
controller site, nothing -- and the axis point is really -- in fact, axis point the only
change we made was the driver to driver part optimization which is a serious
change in amount of coding effort, but it's really try to optimize the part agencies,
okay? And that became -- that was more important when we were doing
deterministic scheduling. It became less important when we do epoch-based
scheduling because we can live with variabilities better.
So in fact I think if we just disable the changes we made in the axis point we
should be just fine. There are other parameter changes in the axis point which is
the fixed backoffs, which is a parameter choice that we had made and so on. But
anyways, the clients don't change, and that's, I think, the biggest advantage in
this whole story.
>>: [inaudible].
>> Suman Banerjee: Yeah?
>>: [inaudible] I mean this scheduling seems a [inaudible] enterprise. How
about [inaudible]? I mean ->> Suman Banerjee: Right. So ->>: Even at my home I store a month of APs from my neighbors.
>> Suman Banerjee: Right. So very good question. So what happens in home
scenarios, do the result translate to home scenarios? And the challenge there is
that you don't have controller that can manage all your access points of different
homes, right? If you could, then you could just translate the same results to the
home environment, but I don't know if that is an easy fix because your neighbor
may be actually operating using a different ISP, and would you allow scheduling
at that level from a controller to all the ISP networks? That's really the key.
>>: Is your department non running 11A?
>> Suman Banerjee: Our department has 11A, but very few clients on it. Yeah.
>>: It's really [inaudible] just dying out. I mean people shouldn't be really
concerned about range. It's dying out. It seems like you know a [inaudible] and
lower ranges even is a blessing is not a problem. But I mean, it's hard to now
even go to try to buy a [inaudible].
[brief talking over].
>>: [inaudible] it's ridiculous.
>> Suman Banerjee: Exactly. So I guess it could solve the problem, but I -- you
know, that's not true.
>>: [inaudible].
>> Suman Banerjee: 12.
>>: [inaudible] you know like the [inaudible].
>> Suman Banerjee: You know, but there is actually another motivation why you
may want to keep a bunch of APs in the same channel, which is because of
handoffs. So actually keep APs in the same channel and they have overlap, then
the handoff process becomes -- because the client doesn't have to change
channels for handoff.
So there is some reason why you people -- even if you use 11A, there may be
some reason why you may want to deploy things to be on the same channel.
>>: [inaudible] I mean when you change from movie from one access point to
the other, even if you are using the same channel, I assume the process is
[inaudible]
>> Suman Banerjee: Yeah. But with avoid, you know, the smooth will be not as
smooth depending on [inaudible].
>>: [inaudible].
>>: [inaudible].
>> Suman Banerjee: So the complexity is really -- so the conflict map requires
the APs to be able to send packets in a synchronized way and observe whether
responses come back or not. And that's really not our work so I didn't go into the
details but basically if you send two packets and you don't get the X back and
you do this couple of times, you know that there is some sort of conflict. And
based on what kind of experiment you do, you can tell which kind of conflict it is.
>>: But you're doing for like ->> Suman Banerjee: Individual packets.
>>: No, but to you do it for every AP parent client.
>> Suman Banerjee: Every AP parent client pair and actually for 10 AP network
with 12 clients or 9 AP network with 12 clients that at least a smarter scheme can
achieve this within let's say four or five seconds. And you can probably distribute
it. It doesn't have to be done continuously so you can space that out. And all
this is factored into the experiment. So there is some [inaudible].
>>: [inaudible] I mean the complexity versus the performance. I mean the
performance benefits seem universal.
>> Suman Banerjee: There is complexity in the detecting the interference and I
think the complexity, the complexity and scheduling is there, so if you have very
inaccurate scheduling you will get bad measurements basically. But ->>: [inaudible] I mean since [inaudible] for the AP, if you detect that there are
these [inaudible] suspect that they might occur, you might have [inaudible] AP
channel assignment.
>> Suman Banerjee: So the problem is that these are maybe transient, right? It
could be just two clients sitting at some location that doesn't exist and you could
say that do we change it for these two clients when there are 20 other clients that
will get affected when each -[brief talking over].
>> Suman Banerjee: Aruba does.
>>: Yeah. But you know how [inaudible] once every night.
>>: Sure. Sure. But I mean you can -- [brief talking over].
>>: You can force the AP to disassociate. So you [inaudible].
>>: I under ->>: I force one client to just disassociate [inaudible] AP.
>> Suman Banerjee: That's a solution. Sure. I mean, whether by changing
channel I mean do you introduce -- I mean, maybe you kind of loop around,
there's another hidden terminal somewhere else.
>>: No, don't change channels, force the client to go to another channel,
disassociate him.
>> Suman Banerjee: What if that is only AP for that client? I you mean you
could get in the corner cases. I mean I guess you're right, we could do some of
the other things, too. I agree. But when we haven't investigated that, you guys
are looking at that, so certainly you should tell us what happens.
>>: [inaudible].
>> Suman Banerjee: Okay. So I will -- I have one until 12, so I have many more
slides to go. Is that right?
>>: [inaudible].
>> Suman Banerjee: Okay.
>>: [inaudible] but that's okay.
>> Suman Banerjee: So I was told it would be 12 [inaudible]. If you want I can
speed up and talk about a few less things, okay. So with that, I'll kind of move on
to the next question, which is how do we leverage infrastructure to improve
energy of mobile devices. And here basically we start the -- okay. So let me just
-- I think it's -- never mind. Yeah. So basically the approach we are trying to take
is, you know, packet losses are wasteful, we want to reduce them, avoid them as
much as possible, and then if possible we also want to improve the efficiency of
each transmitted bit, so I'll try to talk about both of them in some amount.
So the fundamental problem of, you know, packet loss, rate adaptation, condition
window adaptation, all of these things is the ability to figure out what caused the
packet loss, right? So imagine the scenario. Transmitter sends the packet to the
receiver. Packet is received in error, and then the error could have happened
due to at least two different reasons. It could be a collision or a weak signal.
And the interesting thing is each scenario requires a different the form of
adaptation. So if you have a weak signal and you do RTS/CTS or you do
backoff, you do adaptive RTS/CTS or anything, that's a wrong solution. You
really what you need to do is you need to either reduce the data rate or increase
transmit power, okay?
Whereas if it's a collision and you reduce the data rate, you are actual making the
problem worse. And typically most systems tend to do both because they don't
know which one it is. So they do both and one of them at least is wrong. All
right? So the fundamental question I think in our mind is how can we distinguish
between what is the cause of a packet loss? Was it a weak signal or was it a -was it a collision? Okay. So that the first thing that we wanted to solve and then
we'll show how to utilize that information in an infrastructure based system. So
we took a very simple approach and almost like a brain dead approach in my
opinion, but it actually works pretty well, so it's worth talking about it. So let's
see, let's match that we send this packet, transmit a packet, and it's received -it's received at the particular receiver. And it may be received in error, okay? So
the question we posed is by conducting like a postmortem of this packet can we
tell what is the cause of the error, whether it's collision or mixed signal. Okay?
So now imagine that if you have the original transmitter packet and received the
packet in error, you could compare things like the rich bits were in error, and you
know, what can you tell from these different bits, you know, so we can create an
error bitmap. But the only way you could do this is if you allow the received
packet in error to be send back to the source. Okay? So we took this kind of a
simple approach and said that, okay, we'll send a packet. If the packet is
received in error, we'll send the corrupt packet back to the source. Okay? And
then we'll let the source figure out what happened and then based on that, it will
do the right thing in terms of rate adaptation or, you know, whatever condition
window adaptation and other things like that.
Now, this might seem like a bad idea because you are wasting bandwidth in just
sending this big corrupt packet back, but from the energy point of view, if you
think about it, most of your, you know -- the energy savings that we really want
are at the clients, okay. So we really -- what we do is we do this for client traffic
so that it's client sending packets to the access points, only the access points
sends this packet back. And of course there is reception cost to the client, but
that is probably much less than transmitted cost, so that's fine. So for downlink
traffic we don't do this, all right, it's only for uplink traffic.
>>: [inaudible] receive cost is pretty much equal to transmit cost.
>> Suman Banerjee: Okay. That's ->>: [inaudible].
>> Suman Banerjee: It depends on the card, but -- so, okay. I agree that maybe
there is some increased cost, but I think the overall gains that we'll get actually,
you know, far ->>: [inaudible] the receiving [inaudible] AP ->> Suman Banerjee: The receiving SDR doesn't give you enough information. I
guess with, you know, SDR kind of things you could probably look at more -more information in the packet and figure this out. But we don't do this. We are
doing this on A.211, okay. If you could look at, you know, received SNR on
packet chunks and things like that, you could kind of tell. Okay?
So this work is actually very -- I don't think we have gone deep enough into the
problem, but we have taken some very initial steps. But I'll present some results
on that. So we actually kind of were trying to look at eight to 11 level metrics
which we could observe by observing bit error patterns in the packet and by
knowing which bitmap to which symbols and things like that. Okay?
So we basically looked at receive signal strength, we looked at bit error rate, we
looked at what we call errors per symbol. So how many bits were in error per
individual symbol? What is the symbol error rate, which is basically how many
symbols were in error as opposed to bits in error. And then we computed what
we call the S core, which is the number of consecutive symbols in error. Okay?
So you get a highest code if you have more number of consecutive symbols in
error as opposed to they're equally sparse, spread out through the packet.
Okay?
So we got compute all of them, and basically the high level intuition is that if there
is a collision and similar ideas now of course have been proposed by others
when they do things like analog network coding where they were trying to
observe where a packet actually starts colliding and things like that, but by
looking at much more detailed information in the packet, we are actually doing
this through A.211 only. And we basically expect that if there is a collision, a lot
of bit errors will happen in a large number within the two packets, we expect that
the errors per symbol will go up with symbols go in error they actually have a lot
of errors. These were some of the intuition that we had, and then the number of
consecutive symbols in error will also go up because of the same effect you have
in the bit errors and so on. So we looked at all these five different metrics, okay?
And the overall system what we designed was we took these five metrics and
when the client sends a packet, the AP sends the error packet back to the client,
it looks at the error bitmap and it computes all these different metrics and all
these metrics basically vote and say, yeah, it's a collision or it's a weak signal.
And based on that, we do link adaptation. Okay? A very simple algorithm has
some overheads, but that's what we did.
And what's interesting is that actually each of these metrics have some ability to
discern between collision and weak signal. It's not perfect. Yeah?
>>: [inaudible] right.
>> Suman Banerjee: Low [inaudible].
>>: So it goes [inaudible] also mean that the signal is [inaudible] or does it
[inaudible].
>> Suman Banerjee: It could be either.
>>: But if the noise [inaudible] collision.
>> Suman Banerjee: The noise is high -- I could not tell at least. I don't know. I
mean, it could be, but it's ->>: [inaudible] just wondering [inaudible] difference between the two, I mean ->> Suman Banerjee: Oh. So you could -- so basically the [inaudible] signal
strength measure that we get from the card doesn't tell us which of the two
actually happens.
>>: [inaudible].
>> Suman Banerjee: Yeah.
>>: Curious what does it mean to have a collision with [inaudible] versus a
[inaudible] I'm not sure what that means.
>> Suman Banerjee: I think that it is like synchronization got loss and whether -I don't know.
>>: [inaudible] think about this. I mean, if it's collision, right, I assume one of the
packet you probably receive a packet header [inaudible] because collision is
caused by two different packet source. So you have, I mean, one packet goes
through the other basically [inaudible] the packet can collide with another packet
[inaudible]. If it's weak signal, I mean [inaudible] then richer is loud. [brief talking
over].
>>: Right. But noise means collision, right? Could mean collision.
>>: So what I'm basically [inaudible] is this. You can define noise as high as -- if
knows is really that high, it should wipe out whole packets. [inaudible].
>>: [inaudible].
>>: Okay.
>>: [inaudible] what's the definition of [inaudible].
>>: I guess [inaudible]. You don't know whether the noise is from another
source or it's just from some other unintended protocol. I mean, let's say this
collision is defined as the source is another client [inaudible] right? We see now,
I mean, where the source can be let's say basically a colorless form [inaudible]
which just emits signal and not [inaudible].
>> Suman Banerjee: So ->>: Is it possible to [inaudible].
>>: Another way to [inaudible] is getting that if it's because of the provision the
increasing noise of the receiver is temporary and in a sense it toss not overlap
the entire package.
>>: I'm talking about [inaudible] I'm just curious about a one bit. Is it possible to
tell about [inaudible] or do you get some [inaudible] the stuff you were doing
[inaudible] that the noise can become better if it was as a signal? Can we
sometimes [inaudible]. I'm just curious whether you [inaudible].
>>: From the card?
>>: [inaudible] signal and noise.
[brief talking over]
>>: Occasionally you can get [inaudible] from the card which is [inaudible] I
mean, depends I mean whether the chip is will to give you that information.
>> Suman Banerjee: I don't think if it gives you S and N separately, sometimes
it gives S plus I, right?
>>: So you can get N because the hardware knows baseline N.
>> Suman Banerjee: Okay. Sure.
>>: That's what it used to synchronize itself.
>> Suman Banerjee: That's true.
>>: But I think what's unclear is like what timeframe it is actually.
>> Suman Banerjee: That's another problem.
>>: Plus like so the interesting thing is people have done detail measurements
where actually like some [inaudible] the reason RSS is not predictable is because
of ODM. What really matters is like S and R of individual subcategories.
>> Suman Banerjee: Yes.
>>: And that can be variable. And what the card gives you some kind of
average ->> Suman Banerjee: Average.
>>: Across the carriers.
>> Suman Banerjee: Sure.
>>: So what's really predictive, it's kind of like going back to the underlying
physics for predictable performance is the S and R [inaudible].
>> Suman Banerjee: Sure.
>>: So if you knew that, then your prediction would be a lot more accurate.
>> Suman Banerjee: That's absolutely right. I agree. Yes. So we did this in
2007, 2008 timeframe.
>>: [inaudible] variables not the average [inaudible] from sort of the -- because
there is a variance [inaudible].
>>: Selective fitting section.
>>: I see, is it selective fitting or is it --
>>: It's selective fitting.
>> Suman Banerjee: But if it's collision, it probably will affect a lot of them in the
same way.
>>: [inaudible].
>>: Because different subcategory frequency.
>>: They're pretty close, right, I mean there's not that different?
>>: Well, it does matter, it turns out. Which is the primary motivation behind
ODM as well. So I think in measurements you can see like, you know [inaudible].
>>: I see. [inaudible] deliberately select [inaudible]. I mean you want to get
some [inaudible].
>> Suman Banerjee: So actually I'll kind of interest of time, I'll summarize some
of the main results that we had. So it turns out that by using this voting scheme
what we could actually do was we could get a very accurate prediction of when
the collision happens due to a weak signal. So we got very high accuracy. If it
was a weak signal based collision, weak signal based pack loss we could tell it
pretty accurately. But if it was a collision based packet loss, we would make an
incorrect prediction 40 percent of the time, okay. So we have one side we could
do accurately, the other side we couldn't.
That was basically what this set of observations, that set of metrics were defined.
So clearly there is call for improvement and some of the things that [inaudible] is
mentioning looking at an individual ODM subcarriers probably will give you much
better performance. But this was the first stab at the problem. So ->>: [inaudible] you talk about the [inaudible] how do you know that [inaudible].
>> Suman Banerjee: Right. So we created the -- we created the ground crew.
So what we did was we positioned nodes if a way that we know that there is no
other interfering source and so it has to be weak signal and so on. So ground
truth is created for this.
So one of the problems that we face -- faced in kind of figuring out why weak
signal, detecting weak signal is a problem was given the metrics that we chose,
captured effect came and really interfered with us. If captured effect happened
we couldn't tell if the packet was lost due to weak signal versus collision, okay?
And the other thing that really messed up our measurements are our
predictability of the metrics was the size, the relative size of the colliding packets.
If there's small packet colliding with a large packet, that looked differently than
two big packets colliding with each other. These were [inaudible] problems. But
anyway, so we went and implemented the system with all the overheads of
sending the current packet back and all of that, and essentially this is basically
showing over time throughput gains which also translates so you can translate
that to energy per bit to kind of translate the energy gains, and so we
implemented this system called COLLIE which it stands for the collision
inferencing engine in the hardware -- sorry, in the system, not hardware, in the
kernel. And this is over time, the throughput you get for a mobile client in
presence of other traffic. This is basically because you are able to detect which
of the two is happening to some level of accuracy and take corrective measures
better in each of this ->>: [inaudible].
>> Suman Banerjee: So this is -- so we divide the throughput with the total
amount of energy consumed and I think I have the energy numbers in the
subsequent block. Oh, I think ->>: [inaudible].
>> Suman Banerjee: That's not throughput by energy, actually. These are
throughput gains, and I think the -- I don't have the energy plots here actually, all
right.
>>: But you [inaudible].
>> Suman Banerjee: We actually measure energy. We have energy
measurements just by taking the amount of energy consumed across the card.
And the -- I think the slide that actually is -- illustrates the point is that the number
of retransmissions with COLLIE goes down significantly so that will already give
you significant energy gains. So reduction in wasted retransmission goes down
by 40 percent. Okay. So I mean it depends on the -- how much mobility, how
much interference, all of that. So if it's a very good channel it didn't matter. So,
yes.
And some of these measurements were done by emulating this on a SPH is 101
or WiFi phone. So we were trying to basically emulate this for a bus or WiFi
device.
Okay. So I think I'll just talk about one more thing. I'll skip over a bunch of slides
so just pardon me here. So this is basically there's some work we did on kind of
reducing or improving the efficiency of the number of bits you transmit. It is the
initial part is header compression, but there is lot of interesting other ways of
eliminating redundancy some, you could eliminate a bunch of control message
that is are redundant because eliminate redundancy in payloads.
So there is the one I'm skipping over is probably some people here have heard of
it. This is our authentication work using radiometric fingerprinting which is
basically -- I don't know, this is a [inaudible] paper from last year which basically
looking at specific hardware level characteristics in packets or other
manifestation of hardware level transmitter properties in the packets in terms of
distorted frequencies or -- so looking at things like phrase error, the same
correlation error in that we receive packets, can you tell different transmitters
apart and then can you build security based on these kind of feature.
So this work was done using our very sophisticated piece of hardware, a vector
signal analyzer that would observe the packets, calculate this metric, give it our
and then we feed it into a machine learning tool and we could show really high
gains in terms of performance and accurately determine in transmitters without
requiring clients to authenticate, okay.
So I'm going to skip over this because I want to talk about the one last thing,
which is one of our most recent work, and I'm going to talk about for a couple of
minutes probably.
So we have been looking at this problem of WiFi video multicast and -- yeah?
>>: [inaudible] rest of the week.
>> Suman Banerjee: Right.
>>: [inaudible].
>> Suman Banerjee: Okay. So one you mean?
>>: Yeah.
>> Suman Banerjee: Okay.
>>: [inaudible].
>>: [inaudible].
>> Suman Banerjee: Well, this is -- this two minute version is really focussing
on the problem and the results. And maybe we can talk about this informally and
maybe that's fine. Yeah. So basically the problem we were looking at kind of
was motivated by something that our campus ID folks came and talked to us and
they said that they're interested in doing this campuswide broadcast of lectures
and they feel that in many cases students sit together in the library or in the dorm
and they will be associated with the same access point and if you'd broadcast the
same content to all the users it's going to, you know, self interfere and going to
be lot of problems especially if you go to HD the quality video. So how can we
sustain high quality video over multiple users when the video content is the
same? So this is basically WiFi video multicast.
And in this two minute teaser, I'm only going to give you the results and not the
techniques. But, you know, we can talk offline. So basically the -- I think the
punch line for our work really was that we could scale up to 25 users when we
were transporting video at the rate of 20 megabits second, which I thought was
very impressive.
And here is one experiment where it shows a few of the interesting things, so this
is PSNR of a video clip at the 20 megabit per second rate and we had clients that
were located in the good, medium and bad channel conditions of receiving the
same content. And we have four sets of bars for each client. So the first -- the
black one is unicast simultaneously, so it's individual unicast to each particular
users, 10 of them in this case, and obviously, you know, 20 times 10 is 200
megabits per second. So of course you don't get any useful PSNR over here, so
the black line is very bad.
The next one is a red line, which is broadcast, and broadcast at the best possible
data rate that you could pick. A single rate, fixed rate, but best possible rate.
And it does well because you're only transmitting one stream. Whoever doesn't
get it doesn't get it. Okay?
The next one, the green, is individual unicast, so this is actually interesting.
Individual unicast is you're only transmitting to one user at a time, and there is no
other user that is receiving stream at that time. Okay? So individual unicast you
expect it to do very well, because there's only one user. But the funny thing that
happens is that when the channel is good for the users for whom the channel is
good, you get very good performance.
As you get from medium to worse, unicast, individual unicast starts performing
badly, especially when compared to our scheme which we call [inaudible].
Okay? And it's -- the interesting aspect about individual unicast is that here what
happens is there is some notion of header plan blocking that happens. So if the
channel is bad and suppose you have a P packet that is sitting in the WiFi card's
buffer and it's trying to transmit this and it's not going through, it keeps on
transmitting this until it succeeds, and it keeps on transmitting more P frames
until this is hidden and then the I frame tries to go up, but the I frame can get
delayed sufficiently that the P and the B frames are occupying more of the
channel time in some cases.
In [inaudible] what happens is we at the proxy are deciding how to retransmit and
what to retransmit. Okay? We are not letting the Mac layer do anything because
we are doing broadcast and broadcast we don't have any acknowledgement so
we cannot retransmit. So because we are able to kind of expose packet priority
or, you know, even the retransmission priority, which packet is more important to
retransmit than others and how do you construct the correct schedule of packets
to transmit, we are actually able to implement a better schedule of transmissions
because we are kind of, you know, aware of packet priorities. So we actually
even in the bad case we outperform unicast to individual clients, which was a
very interesting result from our point of view that, you know, we can get to this
kind of performance.
The scheme is actually fairly adaptive and so we have a bunch of packet priority
mechanisms in there, we have rated adaptation for broadcast packets, we have,
you know, a scheduling mechanism and the rate adaptation of the little data is
interesting complexity where we set up a base rate to use for each -- a base rate
to use for the entire group and then we have mechanisms to choose data rates
for different packets which is above the base rate in certain cases, depending on
the packet priority. Okay?
And here is, you know, some example showing impact of things like interference
on performance so, you know, we started interfering source, and it shows that
broadcast, of course, doesn't do very well. Individual unicast in general does
well, and we can also kind of get to the same rate. Our latency in adapting the
rate is a little slower because we are trying to do it for the whole group and so
we're a little bit conservative compared to the most efficient way of doing it as
single user. But it is not significant.
And we did similar in the mobility experiment, so, you know, one user kind of
went behind a wall and came back in a few seconds quickly and we looked at,
you know, how adaptive things are. So it's kind of an interesting solution of trying
to do HD video to a bunch users. So I'll be happy to talk about more details
when we subsequently [inaudible] with each of you.
So I think that kind of summarizes our work. There is a bunch of other projects in
our group we do -- you know, we're looking at this metro scale mesh network
management with our 250 node access point network that we have in local
Madison and we're looking at some of the issues of fault management there. It's
kind of slowed down a little bit when it -- we need to pick up our pace there.
And the last thing I'll mention in the context of video services over wireless
networks, this is another piece of I think very interesting work, but this is one
example where we are looking at using SDRs for exploiting application layer
information with the file layer encoding that is employed. Okay? So we call it
approximate communication.
And the high level idea is that if you think of a set of -- you think of any
constellation scheme like, you know, 250 or 16 or 64 [inaudible] when a packet or
when a symbol is transmitted, the problem -- so there is a probability the symbol
will be received in error and the symbol error probability kind of decays with
distance from the location of the transmitter symbol, that is in the IQ space. So
you are likely to make errors which are close to you in the IQ space than which
are far away from you.
And the reason that will happen is if you are selecting a good enough rate, you
will obviously be making most of the times you will be correct, otherwise you're
not going to use that rate. When you rate adapt, you make sure that errors are
close by, or in fact you're trying to make sure that the most of the times you're
getting the right symbol. So as a natural consequence errors are also close by
more than they are far away. Okay?
So because of this property, what we can actually do is if you think of a symbol
consisting of a number of bits, we can selectively provide greater priority or the
channel -- I should say the channel provides greater protection to some bits than
others. So effectively in six bits of our X24 plan let's say the first two bits are the
most protected, next two bits are a little less and the last two are even less.
So if you can now map IP and B frames to the most protected less protected
least protected bit positions then overall the channel is giving you differential
protection for free without even having to introduce APCs or anything like that.
So you can do much more on top of that, but this is some capability the channel
already provides and we never exploit it. Okay? So that's the basis of
approximate communication.
So we design the system based on this using the WARP radios from Rice
University. There is feedback and all of that, so it does change on the Mac
protocol and so on. And you know, there are lots of experimental results to show
how this works. Yes?
>>: [inaudible] you're saying [inaudible] given symbol.
>> Suman Banerjee: Yes.
>>: [inaudible] differential.
>> Suman Banerjee: Yes. Depending on the bit position. And depending on
the encoding scheme that we use. So encoding scheme says how you map.
>>: Right. So why -- I would have thought that decoding scheme would be
optimum in the sense like all other possible symbols are equally distant from
[inaudible].
>> Suman Banerjee: Well, that's not possible, right, because if you take any
position 64 client.
>>: Yeah.
>> Suman Banerjee: There are 63 other positions. How can you ensure that
they'll be all equally ->>: No, no, you care about the symbols around a particular symbol.
>> Suman Banerjee: Right.
>>: There are equal number of symbols for a particular symbol.
>> Suman Banerjee: Right.
>>: And aren't they -- aren't they ->> Suman Banerjee: All of those are probably equally likely, I agree. But you
can still ensure that in general depending on how you map bit values to symbols,
you can ensure that the first bit is the most protected. The likelihood of the first
bit error. It depends on how many times by going to the neighboring symbol you
flip that bit. And that can be made fewer than the last bit flipping when you go
across one symbol. So that's by choosing the encoding scheme.
>>: [inaudible] but is that -- is that the property of current codes that are being
used?
>> Suman Banerjee: Some current codes actually have that property, but you
can also select the mapping. It's a choice that you can map. It's a completely
software decision.
>>: [inaudible]. So I mean that depends on what information you want to expose
to [inaudible] just a [inaudible] is equally [inaudible].
>>: Yes, so the [inaudible] I guess for some reason I [inaudible].
>> Suman Banerjee: So.
>>: [inaudible] is like you design if you [inaudible].
>> Suman Banerjee: Right. So what people do is they have this scrambler
module in the middle and that tries to kind of random [inaudible] all bits in some
ways are equally likely to be in error. Because you have introduced some
redundancies. And even after scrambling the bit positions are in error. Different
bit positions have different error. So if you scramble the I frame and you
scramble the P frame and then you scramble the B frame and then you take the
scrambled bits and put it on the most protected, medium protected, least
protected, you get that kind of property for the I bits which are scrambled P bits.
So overall you get this differential protection for free. And that's what you can
exploit.
And then you can -- so we're looking at various follow-up problems which is how
do you choose a constellation space that has certain properties of protection and,
you know, things like that, or what are better mapping between the encoding
scheme that you use.
So we got -- I mean, there's lot -- I mean, this is one slide for a whole paper
actually that we can talk about.
>>: [inaudible]. Because it makes the [inaudible].
>> Suman Banerjee: That is true. That is true.
>>: Different [inaudible].
>> Suman Banerjee: Yes, it's a different -- there's a single unicast problem that
[inaudible] and you know, it really, what it does is for -- in fact, what it really does
is for a symbol that is in error, if you think of schemes like [inaudible] zig-zag or
like, sorry, MRD and its variant, soft, all of these, what they're trying to do is
they're trying to increase the probability that the symbol is correctly decoded.
What we are trying to do is even if the symbol is decoded in error, we will extract
a few good bits out of it. So we are still extracting more out of the symbols which
are in error and that's what apex [phonetic] -- the system is called apex. That's
what it does. But it, of course, requires changes, both sides [inaudible].
So I'll stop there. I think that's a lot have things condensed in, and I probably
skipped over a bunch of things, but hopefully it sets up some context for more
conversations. Thank you.