WEBVTT 1 00:00.000 --> 00:05.510 Anytime we're going to start a wireless design, it's going to begin with us 2 00:05.510 --> 00:10.870 taking a floor plan and our goal is to strategically place access points 3 00:10.870 --> 00:14.000 throughout this space in order to provide proper coverage. 4 00:14.000 --> 00:18.270 And so we draw the signals around these access points. This would not be a very 5 00:18.270 --> 00:23.000 good cell design because we've got a lot of empty space in here, for example. 6 00:23.000 --> 00:29.010 But again, each one of these access points is covering an area that we refer to 7 00:29.010 --> 00:34.830 as a cell. But what exactly defines a cell? I mean, we've got a boundary around WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 7 00:29.010 --> 00:34.830 as a cell. But what exactly defines a cell? I mean, we've got a boundary around 8 00:34.830 --> 00:36.000 this access point. 9 00:36.000 --> 00:41.220 But chances are I can not only communicate with this access point here, but 10 00:41.220 --> 00:45.050 even if I go out into the space, I can probably still communicate with this 11 00:45.050 --> 00:46.000 access point. 12 00:46.000 --> 00:50.550 And so is the cell boundary arbitrary or we just drawing pretty circles around 13 00:50.550 --> 00:56.200 these access points? But no, we actually do have a definition for what these 14 00:56.200 --> 01:00.000 cells look like in the boundaries around them. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 15 01:00.000 --> 01:05.370 Specifically, we're going to set our cell boundaries based on that signal 16 01:05.370 --> 01:07.000 strength concept. 17 01:07.000 --> 01:12.770 What the wireless world will refer to as the received signal strength indicator 18 01:12.770 --> 01:18.000 or SSI is going to be what we've been referring to as signal strength. 19 01:18.000 --> 01:24.970 That dBm measurement of how strong a signal is. And recall that if we have 20 01:24.970 --> 01:29.000 anything over, again, these are negative numbers to keep that in mind. 21 01:29.000 --> 01:34.500 But anything over, I would say about negative 70 is going to be considered a WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 21 01:29.000 --> 01:34.500 But anything over, I would say about negative 70 is going to be considered a 22 01:34.500 --> 01:39.790 very good signal. If we get into the lower negative 60s and to the negative 50s 23 01:39.790 --> 01:43.460 , it's a phenomenal signal. And you'll almost never see a signal that's as 24 01:43.460 --> 01:48.080 strong as negative 40. If you do, then you know you are probably sitting right 25 01:48.080 --> 01:50.000 underneath the access point. 26 01:50.000 --> 01:54.340 So when we're talking about this signal strength and again, it's measured in dB 27 01:54.340 --> 01:58.600 m, we've got to define what these cell boundaries look like based on what a good 28 01:58.600 --> 02:00.000 signal strength is. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 29 02:00.000 --> 02:04.130 The problem is that the definition of a good signal strength can change 30 02:04.130 --> 02:08.760 depending on whether we're deploying access points for data only or 31 02:08.760 --> 02:13.000 specifically whether we're going to deploy real time applications. 32 02:13.000 --> 02:18.580 And when I say real time applications for the most part, we're talking about 33 02:18.580 --> 02:22.000 especially voice voice over IP and video. 34 02:22.000 --> 02:26.530 Now if we have other real time applications struggling even to think of some 35 02:26.530 --> 02:30.000 examples, there are definitely examples out there. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 36 02:30.000 --> 02:34.750 Then we're going to need to design for real time even if we're not deploying 37 02:34.750 --> 02:40.450 voice and video over wireless. But these days we pretty well expect that we 38 02:40.450 --> 02:44.000 want to use the Wi-Fi for our voice calls. 39 02:44.000 --> 02:47.000 So a lot of our designs are going to use real time metrics. 40 02:47.000 --> 02:51.550 Now the difference between these has to do with what again we consider to be a 41 02:51.550 --> 02:56.710 good enough signal strength with data only we can go as low as 72 dBm and say 42 02:56.710 --> 03:01.370 that we should be able to connect at a really good data rate and have a strong WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 42 02:56.710 --> 03:01.370 that we should be able to connect at a really good data rate and have a strong 43 03:01.370 --> 03:02.000 connection. 44 03:02.000 --> 03:06.860 And if somebody wanders out of this cell and they're getting negative 74 45 03:06.860 --> 03:12.110 negative 76 they can probably continue to communicate to that access point if 46 03:12.110 --> 03:17.080 they need to and ideally at some point they find another access point and roam 47 03:17.080 --> 03:18.000 over to it. 48 03:18.000 --> 03:23.370 Now with real time applications are threshold shrinks a little bit we say 49 03:23.370 --> 03:26.000 negative 67 dBm. 50 03:26.000 --> 03:31.930 So if I am deploying the access points in the exact same space but I'm using a WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 50 03:26.000 --> 03:31.930 So if I am deploying the access points in the exact same space but I'm using a 51 03:31.930 --> 03:37.640 real time boundary metric then these cells are going to shrink and we might 52 03:37.640 --> 03:42.420 expect them to look a little bit more like this at which point we see we're not 53 03:42.420 --> 03:44.000 covering the entire space anymore. 54 03:44.000 --> 03:49.120 So it does depend or does matter greatly what we're performing this access 55 03:49.120 --> 03:54.660 point survey or really the wireless design the cell design what we're designing 56 03:54.660 --> 03:59.000 it for is going to impact where we place the access points. 57 03:59.000 --> 04:05.070 On top of all of this we need to also keep in mind that we do require some WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 57 03:59.000 --> 04:05.070 On top of all of this we need to also keep in mind that we do require some 58 04:05.070 --> 04:07.000 amount of overlap. 59 04:07.000 --> 04:11.840 We may have noticed that we've got these areas in between the access points and 60 04:11.840 --> 04:16.280 we've said that this overlap is important because if I'm roaming from one 61 04:16.280 --> 04:21.380 access point to the other if the boundaries are barely coming up against one 62 04:21.380 --> 04:26.000 another then if I'm trying to roam in here I might not have a good signal to 63 04:26.000 --> 04:29.900 the first access point but I might not have a really good signal to the next 64 04:29.900 --> 04:31.000 access point either. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 64 04:29.900 --> 04:31.000 access point either. 65 04:31.000 --> 04:36.970 Instead we want to overlap by enough so that by the time I recognize hey I'm on 66 04:36.970 --> 04:42.250 this side this edge of the cell and I'm getting a little bit weak on this side 67 04:42.250 --> 04:47.000 well look how close I am to the next AP and I can perform a seamless realm. 68 04:47.000 --> 04:51.540 Now the question is how big of an overlap do we need well again it's going to 69 04:51.540 --> 04:56.140 depend on whether we're talking about a data deployment or a real time 70 04:56.140 --> 05:00.000 deployment with data we like to see a 20% overlap. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 71 05:00.000 --> 05:05.260 And with real time applications we like to see believe it or not 35% overlap we 72 05:05.260 --> 05:09.910 want to ensure that our rooms are as seamless as possible with real time 73 05:09.910 --> 05:14.460 applications because if we get a big hiccup when we're roaming and yeah 74 05:14.460 --> 05:17.990 somebody might be on their phone and just walking through this whole facility 75 05:17.990 --> 05:22.350 and they roam for different times well we don't want that phone call to get 76 05:22.350 --> 05:27.000 disrupted for different times we wanted to be as seamless as possible. 77 05:27.000 --> 05:33.670 So one thing we have to consider within the cell design concept is the idea of WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 77 05:27.000 --> 05:33.670 So one thing we have to consider within the cell design concept is the idea of 78 05:33.670 --> 05:40.370 bringing in or containing our cells a little bit because it certainly makes 79 05:40.370 --> 05:45.170 sense on some level to say that hey I'm going to try to fill this space with 80 05:45.170 --> 05:49.330 this few access points as possible if I need to deploy five access points in 81 05:49.330 --> 05:50.000 here. 82 05:50.000 --> 05:54.800 That's going to be a whole lot cheaper than deploying let's say 15 access 83 05:54.800 --> 05:59.420 points and if I crank up the power and I say hey I want all these access points 84 05:59.420 --> 06:05.640 to be broadcasting at 250 millawatts or something along those lines then yeah I WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 84 05:59.420 --> 06:05.640 to be broadcasting at 250 millawatts or something along those lines then yeah I 85 06:05.640 --> 06:10.000 could probably cover this space with only the five APs. 86 06:10.000 --> 06:15.900 So this is the concept of coverage and back when I was first starting to deploy 87 06:15.900 --> 06:21.660 wireless coverage is what we cared about I'd go into a school building like 88 06:21.660 --> 06:26.870 this and try to figure out the fewest number of APs required in order to hit 89 06:26.870 --> 06:33.000 these boundaries these metrics but these days we care about not really coverage WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 89 06:26.870 --> 06:33.000 these boundaries these metrics but these days we care about not really coverage 90 06:33.000 --> 06:38.000 anymore what we really care about is capacity. 91 06:38.000 --> 06:43.560 And when we have capacity requirements well this is where our large cells can 92 06:43.560 --> 06:49.260 start to get us into trouble because again back when I was doing these coverage 93 06:49.260 --> 06:54.560 based surveys we maybe had I don't know 50 wireless stations in the entire 94 06:54.560 --> 06:59.980 building so maybe 10 stations on each access point we didn't have a lot of 95 06:59.980 --> 07:05.000 wireless stations but these days we might have 500 wireless stations. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 95 06:59.980 --> 07:05.000 wireless stations but these days we might have 500 wireless stations. 96 07:05.000 --> 07:10.240 And so I can't have 100 stations associated to every single one of these access 97 07:10.240 --> 07:11.000 points. 98 07:11.000 --> 07:15.960 Number one the hardware might struggle with that but number two we have basic 99 07:15.960 --> 07:21.000 wireless physics the physics of wireless defined for us how long it takes to 100 07:21.000 --> 07:25.600 send a signal how long we have to wait for the signals to finish propagating in 101 07:25.600 --> 07:30.510 the space and these physics are going to provide a limit to the number of WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 101 07:25.600 --> 07:30.510 the space and these physics are going to provide a limit to the number of 102 07:30.510 --> 07:33.000 devices that can associate with an AP. 103 07:33.000 --> 07:37.410 And as you can imagine the physics of wireless signals they're not going to 104 07:37.410 --> 07:42.030 change a whole lot if at all they're not going to change at all ultimately even 105 07:42.030 --> 07:47.130 as technology develops I can have the best hardware in the world I can have the 106 07:47.130 --> 07:51.610 best protocols in the world and the physics of light waves that's not going to 107 07:51.610 --> 07:52.000 change. 108 07:52.000 --> 07:56.920 So we will always have this limit to the number of stations that can or should 109 07:56.920 --> 08:01.720 be associated to a single AP. And so now that we care more about the wireless WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 109 07:56.920 --> 08:01.720 be associated to a single AP. And so now that we care more about the wireless 110 08:01.720 --> 08:07.670 capacity what we're really focusing on is the number of wireless stations per 111 08:07.670 --> 08:09.000 access point. 112 08:09.000 --> 08:13.770 So let's pause for a moment and think why this matters so much I mean why do we 113 08:13.770 --> 08:19.260 need fewer stations per access point beyond the concept of wireless physics 114 08:19.260 --> 08:21.000 because we might look at this situation say okay yeah but I've 115 08:21.000 --> 08:26.630 really only got I don't have 500 maybe I've got 150 stations so I could 116 08:26.630 --> 08:32.000 probably throw 30 wireless devices on every access point and that would work WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 116 08:26.630 --> 08:32.000 probably throw 30 wireless devices on every access point and that would work 117 08:32.000 --> 08:36.000 right well number one that assumes they're evenly distributed throughout the 118 08:36.000 --> 08:41.200 space but we're also going to have other issues with these large cells so if we 119 08:41.200 --> 08:48.770 're talking about large cells we're going to find that we have greater chances 120 08:48.770 --> 08:50.000 of having wireless issues. 121 08:50.000 --> 08:55.410 First and foremost we're going to have a little bit more likelihood that we 122 08:55.410 --> 09:01.000 have poor wireless signal in places so the concept of shadows. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 122 08:55.410 --> 09:01.000 have poor wireless signal in places so the concept of shadows. 123 09:01.000 --> 09:06.450 It would be like saying I've got a room and I put one gigantic bright light in 124 09:06.450 --> 09:10.000 the middle well that's going to create shadows. 125 09:10.000 --> 09:15.530 And throughout the room based on where there are maybe pieces of furniture and 126 09:15.530 --> 09:20.000 the like whereas if I put a lot of lights which is typically how we do lighting 127 09:20.000 --> 09:25.640 in a space well now there's fewer shadows it's better lit throughout the whole 128 09:25.640 --> 09:30.020 area and this exact same premise is going to apply to us in the wireless space WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 128 09:25.640 --> 09:30.020 area and this exact same premise is going to apply to us in the wireless space 129 09:30.020 --> 09:35.200 so we want to have good wireless signal everywhere in as few shadows as 130 09:35.200 --> 09:36.000 possible. 131 09:36.000 --> 09:41.390 Remember wireless signal is light so there's a lot of these analogies we can 132 09:41.390 --> 09:46.690 use to kind of think along those terms furthermore we're going to find that 133 09:46.690 --> 09:49.000 wireless stations are sticky. 134 09:49.000 --> 09:54.400 They do not like to roam because roaming is has the potential to be disruptive 135 09:54.400 --> 09:59.390 and so if we are looking at large cells like we have up in the upper left at 136 09:59.390 --> 10:03.390 this point we're assuming those are large cells we might have a client that WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 136 09:59.390 --> 10:03.390 this point we're assuming those are large cells we might have a client that 137 10:03.390 --> 10:05.000 gets out into the middle of nowhere. 138 10:05.000 --> 10:11.320 And is still trying to hang on to its access point far away whereas there might 139 10:11.320 --> 10:16.410 be actually a closer access point nearby and so it'd be better for us to roam 140 10:16.410 --> 10:20.990 to that but if the access point is further away because of our large cells and 141 10:20.990 --> 10:24.020 we just happen to be sitting in one of these shadows we talked about is going 142 10:24.020 --> 10:28.000 to make it so that it's very difficult for us to seamlessly roam. 143 10:28.000 --> 10:33.240 We're also going to have that problem of co-channel contention remember the WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 143 10:28.000 --> 10:33.240 We're also going to have that problem of co-channel contention remember the 144 10:33.240 --> 10:38.430 more stations we have in the space the more waiting there's going to be because 145 10:38.430 --> 10:41.000 we speak one at a time. 146 10:41.000 --> 10:46.720 Everybody's going to have to take turns and so if we have 50 or 60 stations on 147 10:46.720 --> 10:52.160 one access point versus 20 there's going to be a whole lot more contention for 148 10:52.160 --> 10:56.000 that wireless space because of the half duplex nature. 149 10:56.000 --> 11:01.200 So instead what we're really talking about here is we want to have smaller WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 149 10:56.000 --> 11:01.200 So instead what we're really talking about here is we want to have smaller 150 11:01.200 --> 11:06.830 cells for our wireless deployments in most cases and yes this will require more 151 11:06.830 --> 11:11.490 access points it might come at a greater cost but it's going to be a more 152 11:11.490 --> 11:13.000 robust wireless design. 153 11:13.000 --> 11:17.820 So there's a number of ways of accomplishing this first of all we can lower the 154 11:17.820 --> 11:20.000 transmit power of our devices. 155 11:20.000 --> 11:24.400 Now for access points this is pretty simple I just get into the access point 156 11:24.400 --> 11:29.380 and turn down the transmit power for our wireless stations this is going to 157 11:29.380 --> 11:34.670 depend on the capabilities of the station there have been some protocols that WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 157 11:29.380 --> 11:34.670 depend on the capabilities of the station there have been some protocols that 158 11:34.670 --> 11:39.270 have been put out that allow access points and wireless networks to dictate the 159 11:39.270 --> 11:44.880 transmit power of a station but not every station supports that not every 160 11:44.880 --> 11:49.000 wireless network configuration supports it and so ideally we can make that 161 11:49.000 --> 11:49.000 happen. 162 11:49.000 --> 11:53.410 But we don't always have the best control over it but if we do have that 163 11:53.410 --> 11:57.000 capability we should absolutely take advantage of it. 164 11:57.000 --> 12:03.180 We should also consider deploying lots of overlapping cells which is WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 164 11:57.000 --> 12:03.180 We should also consider deploying lots of overlapping cells which is 165 12:03.180 --> 12:11.560 interesting we can do a multi cell overlap and we can do this using either a 166 12:11.560 --> 12:16.000 band based method or a channel based method. 167 12:16.000 --> 12:22.180 So if I've got an access point here we mentioned this previously in this course 168 12:22.180 --> 12:28.390 that this access point let's say it's a Cisco AP it might have four different 169 12:28.390 --> 12:34.710 radios well those radios might be a 2.4 gigahertz a 5 gigahertz another 5 giga WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 169 12:28.390 --> 12:34.710 radios well those radios might be a 2.4 gigahertz a 5 gigahertz another 5 giga 170 12:34.710 --> 12:42.720 hertz and a 6 gigahertz radio and so when I deploy this AP I might see that I've 171 12:42.720 --> 12:45.000 got a 2.4 gigahertz cell but then I've got a 5 gigahertz. 172 12:45.000 --> 12:51.400 So I can draw that about the same size and then the 6 gigahertz cell and we can 173 12:51.400 --> 12:57.600 maybe even adjust the transmit power per radio to try to make them overlap a 174 12:57.600 --> 12:59.000 little bit more. 175 12:59.000 --> 13:03.650 But if we think about it this physics space the half duplex nature of all the WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 175 12:59.000 --> 13:03.650 But if we think about it this physics space the half duplex nature of all the 176 13:03.650 --> 13:10.090 contention we've been talking about this all applies within the concept of a 177 13:10.090 --> 13:11.000 channel. 178 13:11.000 --> 13:15.320 And so if I have four different bands and therefore four different channels or 179 13:15.320 --> 13:19.560 for that matter if I've got I guess this you know it'd be three different bands 180 13:19.560 --> 13:25.470 but either way I've got the potential to even deploy dual channels within the 5 181 13:25.470 --> 13:29.990 gigahertz space well at this point I've got four different spaces so I could 182 13:29.990 --> 13:36.300 have 120 different wireless stations all in this physical space and yet I've WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 182 13:29.990 --> 13:36.300 have 120 different wireless stations all in this physical space and yet I've 183 13:36.300 --> 13:40.000 got a rough distribution of 30 stations per radio. 184 13:40.000 --> 13:47.050 And that would be perfectly fine. That's very useful. We can also lower the 185 13:47.050 --> 13:52.000 threshold of what makes a packet valid. 186 13:52.000 --> 13:58.340 And this uses a technique known as receiver start of packet or RxSOP and 187 13:58.340 --> 14:03.100 essentially what we're saying is if a station gets too far away from the AP and WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 187 13:58.340 --> 14:03.100 essentially what we're saying is if a station gets too far away from the AP and 188 14:03.100 --> 14:05.000 again remember they're sticky they don't like to roam. 189 14:05.000 --> 14:10.040 So if this is too far away and I'm getting a signal that exceeds the threshold 190 14:10.040 --> 14:15.570 or maybe misses the threshold either way we can just ignore this wireless 191 14:15.570 --> 14:19.000 station and say hey you no longer have a connection. 192 14:19.000 --> 14:23.110 Whereas the Wi-Fi standard says yeah you're allowed to stay connected but 193 14:23.110 --> 14:26.000 because they're connected they have a low data rate. 194 14:26.000 --> 14:31.580 They're going to have a low success rate on their transmit so they're going to WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 194 14:26.000 --> 14:31.580 They're going to have a low success rate on their transmit so they're going to 195 14:31.580 --> 14:37.030 have to do a lot of retransmissions and those transmissions will be very slow 196 14:37.030 --> 14:41.000 because of the amount of bits and bytes that it has to send 197 14:41.000 --> 14:44.970 or well I should say the number of transmissions it needs to send to 198 14:44.970 --> 14:49.590 communicate the same number of bytes and ultimately this is going to slow the 199 14:49.590 --> 14:51.000 entire cell down. 200 14:51.000 --> 14:55.430 So we can lower the transmit power to shrink the cells we can deploy multiple 201 14:55.430 --> 15:01.410 cells on top of each other and we can call it raise the threshold of what a WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 201 14:55.430 --> 15:01.410 cells on top of each other and we can call it raise the threshold of what a 202 15:01.410 --> 15:03.000 valid signal should be. 203 15:03.000 --> 15:07.190 So by leveraging these techniques we can create a network that has smaller 204 15:07.190 --> 15:11.380 cells which will be again a little bit more capacity focused than coverage 205 15:11.380 --> 15:15.040 focused it will be a more expensive wireless design because of the number of AP 206 15:15.040 --> 15:19.550 s that will be required but it will be a far more robust experience for wireless 207 15:19.550 --> 15:20.000 users.