WEBVTT 1 00:00.000 --> 00:04.790 This challenge is a little bit more conversation-based. I encourage you to make 2 00:04.790 --> 00:08.280 sure you have some answers in mind before we talk through these situations 3 00:08.280 --> 00:09.000 together. 4 00:09.000 --> 00:13.000 So we understand ultimately that this design clearly is going to have some 5 00:13.000 --> 00:15.000 issues when it comes to high-density deployments. 6 00:15.000 --> 00:18.810 We're talking about 50 wireless stations all at the same time. That number is 7 00:18.810 --> 00:23.500 getting pretty high as far as the number of stations we should have on a single 8 00:23.500 --> 00:25.000 radio within a single space. 9 00:25.000 --> 00:28.650 We're going to have a lot of contention. We might even see interference because 10 00:28.650 --> 00:32.470 of the head node problem. I mean, there's going to be issues with these larger WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 10 00:28.650 --> 00:32.470 of the head node problem. I mean, there's going to be issues with these larger 11 00:32.470 --> 00:33.000 cells. 12 00:33.000 --> 00:36.750 So when we look at the scenarios, we see that employees are reporting the 13 00:36.750 --> 00:39.000 wireless gets slow. What changes could we make? 14 00:39.000 --> 00:42.490 Well, there's a lot of changes we could make, but a lot of it's going to come 15 00:42.490 --> 00:46.000 down to the fact that we need to shrink the number of stations per cell. 16 00:46.000 --> 00:51.360 We have a lot of different techniques that we can use at this point. We could 17 00:51.360 --> 00:55.000 deploy multiple channels all in the same space. 18 00:55.000 --> 00:59.080 We should probably consider reducing the channel size because 80 megahertz 19 00:59.080 --> 01:04.000 channels are great for throughput, but maybe not so much for the high-density WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 19 00:59.080 --> 01:04.000 channels are great for throughput, but maybe not so much for the high-density 20 01:04.000 --> 01:05.000 deployments. 21 01:05.000 --> 01:09.660 We might consider going down to a 40 megahertz channel or two 40 megahertz 22 01:09.660 --> 01:14.000 channels and maybe even go 20 megahertz if we get a lot more devices. 23 01:14.000 --> 01:18.750 Which is the second bullet point there. We're talking about doubling the 24 01:18.750 --> 01:22.330 capacity of our wireless network because we're going to distribute iPads to 25 01:22.330 --> 01:23.000 every employee. 26 01:23.000 --> 01:28.050 That's a wonderful thing when you love management to just come around handing 27 01:28.050 --> 01:29.000 out iPads. 28 01:29.000 --> 01:34.560 And so again, we probably want to look at shrinking the cell size. One of the WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 28 01:29.000 --> 01:34.560 And so again, we probably want to look at shrinking the cell size. One of the 29 01:34.560 --> 01:39.000 ways we could do that is by lowering the transmit power of our access points. 30 01:39.000 --> 01:43.250 Our cell sizes are going to get much smaller, which means we're going to need 31 01:43.250 --> 01:44.000 more APs. 32 01:44.000 --> 01:47.400 Yes, it's going to require some money. Management might not like that, but at 33 01:47.400 --> 01:52.000 least we're doing right by deploying a robust wireless network. 34 01:52.000 --> 01:56.760 Now we want to implement tracking services, well, only MOLY. At that point, we 35 01:56.760 --> 02:00.970 've got to consider the RTLS requirements of putting access points at the WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 35 01:56.760 --> 02:00.970 've got to consider the RTLS requirements of putting access points at the 36 02:00.970 --> 02:02.000 perimeter. 37 02:02.000 --> 02:05.720 So not only are we shrinking our access points, we're going to deploy more 38 02:05.720 --> 02:09.500 access points because we need to surround the space rather than have access 39 02:09.500 --> 02:14.840 points just in the middle, which is how our design would have been if RTLS wasn 40 02:14.840 --> 02:16.000 't involved. 41 02:16.000 --> 02:20.610 So again, a little bit more of a conversation. There's not a specific right-of- 42 02:20.610 --> 02:24.980 wrong answer to how we want to do this. For example, if you said, let's do 40 M 43 02:24.980 --> 02:27.000 Hz channels versus 20 MHz. 44 02:27.000 --> 02:31.920 Neither one is necessarily right or wrong. It just depends on the situation and WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 44 02:27.000 --> 02:31.920 Neither one is necessarily right or wrong. It just depends on the situation and 45 02:31.920 --> 02:35.000 whether it'll work based on the client density. 46 02:35.000 --> 02:40.160 But the main point here is if we're going to talk about higher density deploy 47 02:40.160 --> 02:45.820 ments, we usually want to talk about shrinking ourselves, shrinking the number 48 02:45.820 --> 02:49.000 of stations on a per radio per cell basis. 49 02:49.000 --> 02:52.350 We've got lots of techniques for doing that. And if we do talk about location 50 02:52.350 --> 02:55.810 services, we need to make sure our access points are getting deployed to the 51 02:55.810 --> 02:57.000 perimeter of our space. 52 02:57.000 --> 03:00.000 I hope this has been informative for you and I'd like to thank you for viewing.