Radio Resource Management is a massive benefit and a huge part of the
lightweight architecture.
The idea here is that we can use a centralized wireless LAN controller to see
what exactly
is happening out in the RF space.
As a result of this, we're going to be able to make very intelligent decisions
about what
types of channels we should use, what power levels, everything tied to our RF
configuration.
But even better, it can be dynamic. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
But even better, it can be dynamic.
If we think back to the days of autonomous access points, if we had a bunch of
APs in
this space, I would have to do a site survey, try to figure out which channel
each access
point should be on, what power level.
But it was a very static concept.
I would configure it one time, and then it would be locked.
It doesn't matter if somebody were to move into this space next door and start
broadcasting
on a different channel, or one of these channels, I wouldn't be able to just
very easily figure
that out and log in and change channels. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
that out and log in and change channels.
But naturally, if that happened with a lightweight architecture with wireless
LAN controllers,
well, they can pick up on that with their intelligence and they can dynamically
change
the power levels in the channels to ultimately optimize the RF space.
And not just once, but on an ongoing basis.
So that's the value of radio resource management, and we'll cover the different
components of
radio resource management coming up soon.
But there is a problem with this model. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
But there is a problem with this model.
What happens, I shouldn't say a problem, it's more of a challenge, I suppose,
but what
happens if we don't just have one wireless LAN controller in here?
What if I have these access points split?
We have a wireless LAN controller responsible for this batch of access points
and a wireless
LAN controller responsible for this batch of access points.
Well this model looks like it's based on one wireless LAN controller having a
global
view of what's happening from an RF perspective. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
view of what's happening from an RF perspective.
But now I've lost that, I have two different wireless LAN controllers.
Well fortunately, like I said, it's not a problem per se, it's not going to
result in
us having to abandon this concept, instead it's a challenge that has a solution
.
We're going to be able to communicate on the wired network between wireless LAN
controllers
if they are part of the same RF group.
Now don't get confused, we talked about mobility groups which allows us to roam WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Now don't get confused, we talked about mobility groups which allows us to roam
from one access
point to another via access points that are connected to different wireless LAN
controllers.
That's a mobility group.
The RF group is saying we need to evaluate the RF space, but we need to do so
understanding
that our access points are connected to different wireless LAN controllers.
What this is essentially going to do is it's going to elect somebody to be the
leader of
the RF group.
And at this point, I get information from these access points, even though they WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And at this point, I get information from these access points, even though they
're connected
to a different wireless LAN controller, and I make all of the decisions because
I'm the
leader.
Now the leader can be statically assigned, I can go in there into the
configuration and
say you are the leader, but for the most part we want to leave this as an
automated process.
And the automated process is going to elect primarily based on capabilities.
We mentioned some of the wireless LAN controller options that Cisco has, and WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
We mentioned some of the wireless LAN controller options that Cisco has, and
for example, there's
that dash 80, which at the time of this video is the most powerful wireless LAN
controller,
well a dash 80 would win over a dash 40, and a dash 40 would win over a dash L
for example.
And from here, if there's a tie, then we've got other criteria we can use.
For example, the AP license count, we just want to allow the wireless LAN
controller
that has the most AP licenses to be responsible for being the RF group leader. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
that has the most AP licenses to be responsible for being the RF group leader.
And then we can also go with highest IP address if needed.
So eventually we do break the tie, and we're able to figure out which wireless
LAN controller
should be the RF group leader.
Now RF groups can support a lot of wireless LAN controllers up to 20 wireless
LAN controllers
and 6,000 access points.
Don't need to worry too much about the hard counts, just understand that these
RF groups
can be more or less as large as needed. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
can be more or less as large as needed.
Now how should we define RF groups?
Well specifically we should be looking at the boundaries in which the RF propag
ates.
So for example, if I have two different buildings on campus, each one should
probably be its
own RF group because there's in theory not going to be RF overlap between the
two environments.
I shouldn't have to worry about this access point having its channel decision
be made
based on like maybe this access point over here.
Because they're so far apart that they should not see one another. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Because they're so far apart that they should not see one another.
At that point they should be different RF groups.
But compare that to a building with a first floor and a second floor and a
third floor.
Well now I'm going to have access points on each one of these floors and even
though they're
on different floors the wireless tends to propagate enough so that their RF
propagations
will actually impact one another.
At that point we would want to make this all part of the same RF group. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
At that point we would want to make this all part of the same RF group.
Now again this is assuming we've got different wireless LAN controllers
involved with all
of these.
If we only have a single wireless LAN controller, maybe one that has a hot
spare at that point
we wouldn't necessarily need the RF group.
We could leave it as the default but generally speaking we want to be very
intentional with
the configuration and the design that we end up using.
So let's go ahead and flip over to the wireless LAN controller and show where
we can configure
this.
This is a global configuration and it's fairly simple. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
This is a global configuration and it's fairly simple.
We just need to know where to go to do it.
So we're going to go to configuration and then down here under wireless we're
going
to find wireless global.
Clicking this we see the RF group name here and the default is simply default.
So I could change this to something like CBTN or something that makes sense for
my organization
and click apply.
And that's all I really have to do.
The RF group configuration isn't that complex once again we just need to make
sure that we're
intentional about which wireless LAN controllers go into which RF groups and WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
intentional about which wireless LAN controllers go into which RF groups and
that should be
determined by whether their respective access points are part of the same RF
space or if
they're part of different isolated ones.