It's easy to focus on the RF side of wireless designs, the cell design, station
, services,
all of these things.
But the switching infrastructure is going to be just as critical because it
needs to support
our wireless design regardless of what exactly we're doing on the RF side of
things.
One of the biggest things that it needs to support is going to be power over
Ethernet.
Now, unfortunately, power over Ethernet is not a simple conversation. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Now, unfortunately, power over Ethernet is not a simple conversation.
These days, we have all kinds of different PoE standards.
So for example, we have the original PoE, which gives us 15.4 watts, maximum
per port.
But then we also have enhancements.
We have PoE+ which delivers 30 watts per port.
We have PoE++ which Cisco also has a version of this called Universal PoE or UP
OE.
And this delivers 60 watts.
And then we have high PoE. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And then we have high PoE.
And Cisco's deployment is UPOE+ and this would be 90 watts.
So when we look at this, what exactly do we need for our wireless deployment?
Well, at the time of this video, Cisco access points all consume less than 30
watts, meaning
that I can get away with what might feel to be an older version of power over
Ethernet
on my devices.
So I could just get PoE+ switches and hey, if they happen to support a higher WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So I could just get PoE+ switches and hey, if they happen to support a higher
level of PoE,
that's perfectly fine.
So having PoE support is important.
However, so is the concept of my PoE budget, my power budget on a switch.
I can't provide unlimited power.
If I have a 48-port switch, for example, that is supporting, I don't know, UPOE
+ or let's
just even say UPOE, that's 60 watts per port. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
just even say UPOE, that's 60 watts per port.
If we do the math here and my calculator, the 60 watts on 48-ports is going to
be a total
of 2,880 watts.
This is not something that most switches are capable of doing.
So we're not going to be able to see us deploying whatever this power level is
on every single
port.
For example, I might have a more realistic budget of 900 watts.
And so I deploy a switch that has a 900 watt budget. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And so I deploy a switch that has a 900 watt budget.
And if I'm deploying again a 48-port switch that has this 900 watt budget, well
, I could look
at this and say, "Alright, cool.
Let's say access points take about 30 watts."
So that gives me 30 ports at 30 watts.
Now it is important to keep in mind that these access points might consume 28
watts or something
like that.
So it's not going to be perfectly 30 watts of consumption.
And fortunately, our budget is based on actual consumption numbers. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And fortunately, our budget is based on actual consumption numbers.
So maybe I could get 31 or 32 ports depending on how much the power draw
actually is.
But we can already see that, "Okay, if I deploy a 48-port switch, I can't
support APs on
every single port."
We're losing 18 of those ports.
It's okay.
So fine, we probably don't need that much density on a single switch anyways.
However, our access points, the only POE devices, what happens if I have, for WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
However, our access points, the only POE devices, what happens if I have, for
example, voice
over IP phones?
Those phones are going to have a power draw as well, especially we're talking
about an
access layer switch here.
So there were probably going to have some number of voice over IP phones these
days.
We might also have security cameras.
And security cameras, they have a very high power draw.
They might actually exceed 30 watts on a per camera basis, especially if we WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
They might actually exceed 30 watts on a per camera basis, especially if we
have the concepts
of zooming and tilting and all of the things that are required, you know,
motors inside of
these cameras, they call them pan tilt zooms or PTs.
Pan tilt zoom, PTs, yeah, that's it.
So we might see a lot of power draw that's being taken by these other devices.
And so we can't just assume that we'll be good based on whatever the power draw
is of an
access point multiplied by the number of access points.
And so what can we do here?
Well, a couple of things. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Well, a couple of things.
First of all, we could look at switches, maybe they have higher power budgets.
Maybe we can get a 48 port switch that has a 1200 watt budget or something like
that.
Or we could look at deploying multiple 24 port switches.
So if I deploy two 24 port switches where there would have been a 48 port
switch, each
one of these maybe can have a 900 watt draw or power budget rather.
And so at that point, we have made our port or our switches a little more power WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And so at that point, we have made our port or our switches a little more power
dense.
So these are some design philosophy changes we could make to make sure that we
have the
proper power budgets.
Now one last feature I want to talk about is the concept of multi gig.
It's a pretty common conversation these days, especially in the wireless space.
The reason for that is, first of all, let's just say what multi gig is.
Multi gig is the ability for me to deploy 2.5 gig and 5 gig a bit per second on
base WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
base
T deployments meaning copper RJ45.
Before multi gig came out, we had one gig base T and we had 10 gig base T. And
so if I
needed more than one gig, I would have to go to 10 gig and 10 gig ports are
kind of expensive.
And we need cat 6a or cat 7 type of cables to make sure I get my full 100
meters.
So multi gig came out and it allows 2.5 gig and 5 gig even on cat 5e which is WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So multi gig came out and it allows 2.5 gig and 5 gig even on cat 5e which is
wonderful
because we have a lot of cat 5e out there in the environment and a lot of our
buildings
and it's also very cheap.
And so I could actually still today pull brand new cat 5e connections.
So why does this impact wireless?
Well it impacts wireless because our access points today are capable on the
wireless side
of communicating at far greater than 1 gig.
In fact we can see communications up to something like 9.6 gig a bit per second WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
In fact we can see communications up to something like 9.6 gig a bit per second
depending
on the radio configuration and the stations and all these things.
So at that point I could say well I should connect this to a 10 gig base T
switch port.
Except even at 9.6 gig on the wireless side, the amount of actual throughput
doesn't quite
translate to what we're seeing there.
I could for example see 9.6 gig a bit per second data rates but I'm only really
seeing 1
to 2 gig because of the efficiency of wireless. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
to 2 gig because of the efficiency of wireless.
Again it's half duplex it requires us dealing with retransmeds contention and
interference.
And so it's great to look at a raw data rate but the question is what is the
throughput
and what's making it through to the access point or back and forth ultimately
is usually
far less than what the radio is capable of doing.
We might even see a situation where we're less than a gig.
Maybe we've got 500 Meg that we're expecting based on the number of stations WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Maybe we've got 500 Meg that we're expecting based on the number of stations
and the quality
of stations that are out there.
So we could look at this and say oh man I need multi gig on all of my access
points
and yet I don't actually require multi gig.
So it's a conversation point.
If we're upgrading our switches we should look long and hard at multi gig
because we have
to think 5, 6, 7 years out.
If I'm buying a new access layer set of switches I expect them to last a long
time.
And I might do a wireless upgrade and all of a sudden I need 1 to 2 gig rather WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And I might do a wireless upgrade and all of a sudden I need 1 to 2 gig rather
than 500
Meg and then I'm going to regret not deploying multi gig.
But if we're looking at deploying these types of access points do we
immediately need to go
and upgrade our switches to deliver multi gig and the answer is usually no.
We need to perform some kind of analysis to figure out what that throughput is
going to
look like and whether we really need multi gig.
Because as soon as we do exceed 1 and 2 gig a bit per second yeah we're going
to want
to consider multi gig and potentially even 10 gig if we start to get to that WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
to consider multi gig and potentially even 10 gig if we start to get to that
point.
And we might see that more as wifi 7 wifi 8 start to come out and give us even
greater
throughputs on the radio.
But within the context of this conversation within the the world that we live
in as of
the moment I'm recording this very often multi gig is something that's nice to
have not
strictly required.
But again from a future consideration perspective if we're doing an access
layer upgrade we
probably want to consider multi gig in the same way we're considering the level WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
probably want to consider multi gig in the same way we're considering the level
of
POE to deploy as well as the power budgets so that we're not going to regret
deploying
access layer switches that have only last 2 or 3 years.