WEBVTT

1
00:00.000 --> 00:05.280
Let's take a moment to drill deeper into this conversation about high density

2
00:05.280 --> 00:06.760
designs.

3
00:06.760 --> 00:11.480
Because a lot of our wireless networks these days have to be designed to

4
00:11.480 --> 00:12.620
support a lot

5
00:12.620 --> 00:13.920
of wireless stations.

6
00:13.920 --> 00:18.070
We think about maybe a high school gymnasium that could support hundreds of

7
00:18.070 --> 00:19.200
wireless devices

8
00:19.200 --> 00:20.200
at a time.

9
00:20.200 --> 00:22.280
Well that's very high density.

10
00:22.280 --> 00:26.580
And again, back when I was doing wireless surveys, a school gymnasium would get

11
00:26.580 --> 00:27.040
a single

12
00:27.040 --> 00:31.020
access point because there was nothing stopping the wireless signal and all we
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

12
00:27.040 --> 00:31.020
access point because there was nothing stopping the wireless signal and all we

13
00:31.020 --> 00:31.560
cared about

14
00:31.560 --> 00:32.720
was coverage.

15
00:32.720 --> 00:37.960
And so the 10 or 15 wireless devices that showed up could use the Wi-Fi.

16
00:37.960 --> 00:40.320
But again, now you've got bleachers full of people.

17
00:40.320 --> 00:43.160
You've got dozens, if not hundreds of people all there.

18
00:43.160 --> 00:47.400
And they've all got a cell phone that they might try to attach to the Wi-Fi.

19
00:47.400 --> 00:52.720
Well at that point, we're going to need a little bit of a change in our

20
00:52.720 --> 00:53.520
philosophy

21
00:53.520 --> 00:57.000
for how we are going to complete these high density designs.

22
00:57.000 --> 01:05.240
And again, at this point, we are focused on capacity, not coverage.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

22
00:57.000 --> 01:05.240
And again, at this point, we are focused on capacity, not coverage.

23
01:05.240 --> 01:08.740
It's very easy to get wrapped up in the coverage conversation and make sure we

24
01:08.740 --> 01:09.440
have wireless

25
01:09.440 --> 01:10.760
signal everywhere.

26
01:10.760 --> 01:15.530
And forget about the fact that capacity is what really determines the success

27
01:15.530 --> 01:16.720
these days

28
01:16.720 --> 01:18.840
of a wireless design.

29
01:18.840 --> 01:20.280
So there's a few things to keep in mind.

30
01:20.280 --> 01:24.730
First of all, we already mentioned the multi-cell concept where we can have an

31
01:24.730 --> 01:25.640
overlapping

32
01:25.640 --> 01:30.000
cell on a single access point or multiple overlapping cells.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

33
01:30.000 --> 01:33.680
So we can deploy lots of these together.

34
01:33.680 --> 01:38.960
And ideally, we hope that there's a distribution of the wireless stations among

35
01:38.960 --> 01:39.920
the bands.

36
01:39.920 --> 01:45.440
Now there is work at being able to direct wireless stations to balance out a

37
01:45.440 --> 01:46.400
little bit.

38
01:46.400 --> 01:50.950
For example, I might have a wireless station that tries to associate on one of

39
01:50.950 --> 01:51.480
the five

40
01:51.480 --> 01:55.800
gigahertz bands and the AP says, "Hey, you know what?

41
01:55.800 --> 01:58.280
You should go look at the other five gigahertz band.

42
01:58.280 --> 01:59.280
Maybe this is channel 48.

43
01:59.280 --> 02:05.560
And I want you to look at channel 64 because channel 48 has 35 stations on it.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

43
01:59.280 --> 02:05.560
And I want you to look at channel 64 because channel 48 has 35 stations on it.

44
02:05.560 --> 02:08.040
Channel 64 has 15."

45
02:08.040 --> 02:13.500
And so these are methods that are being developed even today to try to help to

46
02:13.500 --> 02:14.320
deal with these

47
02:14.320 --> 02:15.880
high density types of deployments.

48
02:15.880 --> 02:20.360
But it does start by having multiple cells overlapping one another.

49
02:20.360 --> 02:24.800
But then we do need to ask the question about bonded channels.

50
02:24.800 --> 02:27.680
We covered bonded channels earlier on.

51
02:27.680 --> 02:33.820
The idea here is that I'm going to take to a J-cent 20 megahertz channels and I
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

51
02:27.680 --> 02:33.820
The idea here is that I'm going to take to a J-cent 20 megahertz channels and I

52
02:33.820 --> 02:34.560
'm going

53
02:34.560 --> 02:39.120
to combine them together into one large 40 megahertz channel.

54
02:39.120 --> 02:44.720
And then I can do this to combine two separate 40 megahertz channels into an 80

55
02:44.720 --> 02:45.280
and to 80s

56
02:45.280 --> 02:47.280
into a 160.

57
02:47.280 --> 02:50.470
The cool thing about bonded channels is it gives me a whole lot more of that

58
02:50.470 --> 02:51.160
wireless real

59
02:51.160 --> 02:55.200
estate, which means I can transmit on more frequencies.

60
02:55.200 --> 03:00.160
And this in the end, it gives me a whole lot more wireless throughput.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

60
02:55.200 --> 03:00.160
And this in the end, it gives me a whole lot more wireless throughput.

61
03:00.160 --> 03:06.040
So bonded channels very, very good for throughput.

62
03:06.040 --> 03:11.550
But again, when we're talking about a high density wireless deployment, we're

63
03:11.550 --> 03:13.240
not as concerned

64
03:13.240 --> 03:15.240
about throughput.

65
03:15.240 --> 03:17.560
So this is another thing that we have to consider.

66
03:17.560 --> 03:20.680
It's not just capacity versus coverage.

67
03:20.680 --> 03:31.910
So it's also a conversation about reliability or maybe a robust network versus
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

67
03:20.680 --> 03:31.910
So it's also a conversation about reliability or maybe a robust network versus

68
03:31.910 --> 03:34.040
throughput.

69
03:34.040 --> 03:39.190
Because having higher throughput is great for a single user or maybe we've got

70
03:39.190 --> 03:39.800
a bunch

71
03:39.800 --> 03:42.000
of devices that really need high throughput.

72
03:42.000 --> 03:46.000
But we wouldn't have 35 or 50 of these devices in theory.

73
03:46.000 --> 03:51.050
At that point, what we care more about is reliability and being able to

74
03:51.050 --> 03:53.480
maintain a connection.

75
03:53.480 --> 03:57.630
And so yeah, the bond to channels are great for throughput, but they're not so

76
03:57.630 --> 03:58.880
good for

77
03:58.880 --> 04:00.800
reliability.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

77
03:58.880 --> 04:00.800
reliability.

78
04:00.800 --> 04:04.440
Meaning that we are going to have reliability.

79
04:04.440 --> 04:06.280
We're going to have a lot more stations.

80
04:06.280 --> 04:08.760
Again, crowding the space.

81
04:08.760 --> 04:13.540
We're going to use up our channels faster because now if I'm having, you know,

82
04:13.540 --> 04:14.560
I've mentioned

83
04:14.560 --> 04:18.670
two five gigahertz channels, well, if those are bonded, now I'm going to use

84
04:18.670 --> 04:19.400
four of those

85
04:19.400 --> 04:21.560
channels on the same physical space.

86
04:21.560 --> 04:25.360
So four channels here and four channels here and four channels here.

87
04:25.360 --> 04:30.320
I start to run out of even five gigahertz channels pretty quickly.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

87
04:25.360 --> 04:30.320
I start to run out of even five gigahertz channels pretty quickly.

88
04:30.320 --> 04:35.250
And furthermore, it's a lot harder to transmit on a 40 gigahertz channel or on

89
04:35.250 --> 04:37.200
80 or 40 megahertz

90
04:37.200 --> 04:42.150
channel or an 80 megahertz channel, and especially 160 megahertz channel, it's

91
04:42.150 --> 04:43.160
just harder to gain

92
04:43.160 --> 04:45.400
access to that airspace.

93
04:45.400 --> 04:50.040
And so even though when we do get access to it, we can communicate a massive

94
04:50.040 --> 04:50.680
amount of

95
04:50.680 --> 04:56.040
data, it makes it harder for a bunch of stations to reliably take turns.

96
04:56.040 --> 05:01.870
We'd all rather be connected very reliably, maybe at a slower data rate, but at
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

96
04:56.040 --> 05:01.870
We'd all rather be connected very reliably, maybe at a slower data rate, but at

97
05:01.870 --> 05:02.980
least have

98
05:02.980 --> 05:04.480
consistent access.

99
05:04.480 --> 05:08.480
It's typically what we're going for in a high density design.

100
05:08.480 --> 05:13.380
Now furthermore, we actually flip bonded channels on its head with modern

101
05:13.380 --> 05:15.160
wireless techniques.

102
05:15.160 --> 05:20.950
We have something called orthogonal frequency division multiple access or OFDMA

103
05:20.950 --> 05:21.200
.

104
05:21.200 --> 05:28.420
This was introduced to us with Wi-Fi 6, which from an IEEE perspective is 802.

105
05:28.420 --> 05:29.600
11 AX.

106
05:29.600 --> 05:35.920
OFDMA actually takes a 20 megahertz channel and divides it up.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

106
05:29.600 --> 05:35.920
OFDMA actually takes a 20 megahertz channel and divides it up.

107
05:35.920 --> 05:42.140
And suggests that hey, I might have four different stations transmitting on

108
05:42.140 --> 05:43.400
maybe, let's say,

109
05:43.400 --> 05:49.490
a quarter of this getting a little bit messy here, but we each get a slice of

110
05:49.490 --> 05:50.480
the channel.

111
05:50.480 --> 05:57.000
So now we're truly talking about multiple stations sharing a particular channel

112
05:57.000 --> 05:57.200
at the

113
05:57.200 --> 05:58.720
same time.

114
05:58.720 --> 06:03.050
And so it truly is flipping it on its head and saying rather than combining
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

114
05:58.720 --> 06:03.050
And so it truly is flipping it on its head and saying rather than combining

115
06:03.050 --> 06:03.960
channels to get

116
06:03.960 --> 06:07.970
more throughput, we're going to divide up a channel to get less throughput for

117
06:07.970 --> 06:08.600
the sake

118
06:08.600 --> 06:12.520
of supporting more stations.

119
06:12.520 --> 06:19.140
Another aspect to high density deployments is actually the use of 2.4 gigahertz

120
06:19.140 --> 06:20.320
and 6 gigahertz

121
06:20.320 --> 06:21.640
cells.

122
06:21.640 --> 06:24.600
So I already mentioned the concept of multicell.

123
06:24.600 --> 06:31.080
And multicell can have a single access point, have 2.4, 5, 5, and 6.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

123
06:24.600 --> 06:31.080
And multicell can have a single access point, have 2.4, 5, 5, and 6.

124
06:31.080 --> 06:33.120
And there's all kinds of different configurations out there.

125
06:33.120 --> 06:38.320
This is one of Cisco's high density types of access points, for example.

126
06:38.320 --> 06:41.920
But do notice that we're talking about 2.4 gigahertz again.

127
06:41.920 --> 06:48.690
And 2.4 gigahertz fell out of favor to the point that in Wi-Fi 5, which was 802

128
06:48.690 --> 06:51.240
.11 AX, there

129
06:51.240 --> 06:54.360
was no 2.4 gigahertz.

130
06:54.360 --> 06:58.210
The thought process when this was developed was we need to get rid of this very

131
06:58.210 --> 06:59.480
busy band.

132
06:59.480 --> 07:05.530
It's very small, we can't bond channels, it's very busy, nobody needs 2.4 giga
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

132
06:59.480 --> 07:05.530
It's very small, we can't bond channels, it's very busy, nobody needs 2.4 giga

133
07:05.530 --> 07:06.280
hertz, so

134
07:06.280 --> 07:07.680
let's go ahead and get rid of it.

135
07:07.680 --> 07:14.920
The truly no support for 2.4 gigahertz using Wi-Fi 5 and 802.11 A.C.

136
07:14.920 --> 07:18.480
So it's interesting that now we're bringing it back.

137
07:18.480 --> 07:25.050
The 6, which is Wi-Fi 6, which is 802.11 AX, this says you know what, we're

138
07:25.050 --> 07:26.660
going to allow

139
07:26.660 --> 07:29.160
2.4 gigahertz again.

140
07:29.160 --> 07:32.600
And the reason for that is because of this.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

140
07:29.160 --> 07:32.600
And the reason for that is because of this.

141
07:32.600 --> 07:36.440
And the fact that now we can start to divide up our wireless cells.

142
07:36.440 --> 07:42.920
So now 2.4 gigahertz becomes something that is a tool again for us.

143
07:42.920 --> 07:45.200
It's a tool in our tool belt.

144
07:45.200 --> 07:49.670
6 gigahertz is the same way, we just have to keep in mind that 6 gigahertz

145
07:49.670 --> 07:50.280
support is pretty

146
07:50.280 --> 07:52.240
low right now.

147
07:52.240 --> 07:57.100
But as we start to see more and more devices, more and more mobile devices,

148
07:57.100 --> 07:58.480
laptops, tablets,

149
07:58.480 --> 08:02.680
and all kinds of different devices start to support 6 gigahertz, we'll now we
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

149
07:58.480 --> 08:02.680
and all kinds of different devices start to support 6 gigahertz, we'll now we

150
08:02.680 --> 08:03.200
're going

151
08:03.200 --> 08:09.360
to see that more devices can take advantage of that 6 gigahertz cell.

152
08:09.360 --> 08:13.600
So by spreading our devices across all of these different bands and channels,

153
08:13.600 --> 08:14.000
we're

154
08:14.000 --> 08:20.200
going to maximize the number of stations that we can support in this given

155
08:20.200 --> 08:20.800
space.

156
08:20.800 --> 08:24.960
Now one last note is it has to do with something that Cisco has for us, which

157
08:24.960 --> 08:26.760
is known as radio

158
08:26.760 --> 08:29.800
resource management or RRM.

159
08:29.800 --> 08:39.170
Radio resource management is the automatic management of our wireless space,
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

159
08:29.800 --> 08:39.170
Radio resource management is the automatic management of our wireless space,

160
08:39.170 --> 08:40.000
especially

161
08:40.000 --> 08:48.380
as it relates to the transmit power and channel selection for our access points

162
08:48.380 --> 08:48.840
.

163
08:48.840 --> 08:53.470
Cisco recognized a long time ago, hey, by having a centralized wireless

164
08:53.470 --> 08:54.440
controller, the

165
08:54.440 --> 08:59.470
wireless LAN controller, we can look at a complex environment with all kinds of

166
08:59.470 --> 09:00.360
access points
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

166
08:59.470 --> 09:00.360
access points

167
09:00.360 --> 09:06.920
in here and overlaps and very often and very quickly evaluate this to say, hey,

168
09:06.920 --> 09:07.240
it was

169
09:07.240 --> 09:11.140
the wireless network changes over time, maybe we should shrink some of these

170
09:11.140 --> 09:11.880
cells, maybe

171
09:11.880 --> 09:15.580
we should expand some of these cells, maybe we should change the channel scheme

172
09:15.580 --> 09:16.000
to make

173
09:16.000 --> 09:19.520
sure that we have less contention in our network.

174
09:19.520 --> 09:23.480
And RRM helps us to maintain that over the course of time.

175
09:23.480 --> 09:29.240
Well, believe it or not, for high density deployments, Cisco recommends turning

176
09:29.240 --> 09:32.600
off RRM.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

176
09:29.240 --> 09:32.600
off RRM.

177
09:32.600 --> 09:37.520
We would want to actually disable this automatic provisioning of wireless

178
09:37.520 --> 09:38.760
configuration in

179
09:38.760 --> 09:44.800
the environment because it's so complex and so difficult that we don't actually

180
09:44.800 --> 09:45.080
want

181
09:45.080 --> 09:47.680
to change on a constant basis.

182
09:47.680 --> 09:53.030
Instead, we want to be very intentional with how we deploy our multi-cell overl

183
09:53.030 --> 09:53.520
aps, come

184
09:53.520 --> 09:57.760
up with a non-overlapping scheme and stick with it over time.

185
09:57.760 --> 10:01.760
Because we do run the risk in high density deployments of having signals
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

185
09:57.760 --> 10:01.760
Because we do run the risk in high density deployments of having signals

186
10:01.760 --> 10:03.480
overlapping more often,

187
10:03.480 --> 10:07.670
with there being contention from one side of a room to another side of the room

188
10:07.670 --> 10:08.560
, especially

189
10:08.560 --> 10:12.650
if wireless stations are transmitting at a much higher power level than our

190
10:12.650 --> 10:13.680
access points,

191
10:13.680 --> 10:15.680
which can happen.

192
10:15.680 --> 10:20.510
And so Cisco says, hey, let's go ahead and disable the automatic configuration

193
10:20.510 --> 10:21.600
of all of that

194
10:21.600 --> 10:27.050
and rely again on the static configuration that we create at the very beginning

195
10:27.050 --> 10:27.360
of this

196
10:27.360 --> 10:29.360
high density deployment.