WEBVTT 1 00:00.000 --> 00:06.080 It's easy to focus on the RF side of wireless designs, the cell design, station 2 00:06.080 --> 00:07.000 , services, 3 00:07.000 --> 00:08.320 all of these things. 4 00:08.320 --> 00:13.080 But the switching infrastructure is going to be just as critical because it 5 00:13.080 --> 00:14.640 needs to support 6 00:14.640 --> 00:19.970 our wireless design regardless of what exactly we're doing on the RF side of 7 00:19.970 --> 00:20.800 things. 8 00:20.800 --> 00:25.810 One of the biggest things that it needs to support is going to be power over 9 00:25.810 --> 00:26.840 Ethernet. 10 00:26.840 --> 00:31.560 Now, unfortunately, power over Ethernet is not a simple conversation. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 10 00:26.840 --> 00:31.560 Now, unfortunately, power over Ethernet is not a simple conversation. 11 00:31.560 --> 00:35.080 These days, we have all kinds of different PoE standards. 12 00:35.080 --> 00:41.460 So for example, we have the original PoE, which gives us 15.4 watts, maximum 13 00:41.460 --> 00:42.600 per port. 14 00:42.600 --> 00:44.560 But then we also have enhancements. 15 00:44.560 --> 00:48.440 We have PoE+ which delivers 30 watts per port. 16 00:48.440 --> 00:55.780 We have PoE++ which Cisco also has a version of this called Universal PoE or UP 17 00:55.780 --> 00:56.360 OE. 18 00:56.360 --> 00:58.240 And this delivers 60 watts. 19 00:58.240 --> 01:01.640 And then we have high PoE. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 19 00:58.240 --> 01:01.640 And then we have high PoE. 20 01:01.640 --> 01:06.920 And Cisco's deployment is UPOE+ and this would be 90 watts. 21 01:06.920 --> 01:11.800 So when we look at this, what exactly do we need for our wireless deployment? 22 01:11.800 --> 01:19.510 Well, at the time of this video, Cisco access points all consume less than 30 23 01:19.510 --> 01:20.480 watts, meaning 24 01:20.480 --> 01:25.760 that I can get away with what might feel to be an older version of power over 25 01:25.760 --> 01:26.520 Ethernet 26 01:26.520 --> 01:28.240 on my devices. 27 01:28.240 --> 01:32.300 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 27 01:28.240 --> 01:32.300 So I could just get PoE+ switches and hey, if they happen to support a higher 28 01:32.300 --> 01:33.520 level of PoE, 29 01:33.520 --> 01:35.040 that's perfectly fine. 30 01:35.040 --> 01:38.040 So having PoE support is important. 31 01:38.040 --> 01:46.520 However, so is the concept of my PoE budget, my power budget on a switch. 32 01:46.520 --> 01:49.320 I can't provide unlimited power. 33 01:49.320 --> 01:57.430 If I have a 48-port switch, for example, that is supporting, I don't know, UPOE 34 01:57.430 --> 01:58.000 + or let's 35 01:58.000 --> 02:02.680 just even say UPOE, that's 60 watts per port. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 35 01:58.000 --> 02:02.680 just even say UPOE, that's 60 watts per port. 36 02:02.680 --> 02:08.080 If we do the math here and my calculator, the 60 watts on 48-ports is going to 37 02:08.080 --> 02:08.760 be a total 38 02:08.760 --> 02:12.240 of 2,880 watts. 39 02:12.240 --> 02:15.400 This is not something that most switches are capable of doing. 40 02:15.400 --> 02:21.100 So we're not going to be able to see us deploying whatever this power level is 41 02:21.100 --> 02:21.920 on every single 42 02:21.920 --> 02:23.000 port. 43 02:23.000 --> 02:29.520 For example, I might have a more realistic budget of 900 watts. 44 02:29.520 --> 02:32.920 And so I deploy a switch that has a 900 watt budget. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 44 02:29.520 --> 02:32.920 And so I deploy a switch that has a 900 watt budget. 45 02:32.920 --> 02:38.510 And if I'm deploying again a 48-port switch that has this 900 watt budget, well 46 02:38.510 --> 02:39.200 , I could look 47 02:39.200 --> 02:41.320 at this and say, "Alright, cool. 48 02:41.320 --> 02:44.160 Let's say access points take about 30 watts." 49 02:44.160 --> 02:49.280 So that gives me 30 ports at 30 watts. 50 02:49.280 --> 02:53.320 Now it is important to keep in mind that these access points might consume 28 51 02:53.320 --> 02:54.120 watts or something 52 02:54.120 --> 02:55.120 like that. 53 02:55.120 --> 02:59.960 So it's not going to be perfectly 30 watts of consumption. 54 02:59.960 --> 03:02.960 And fortunately, our budget is based on actual consumption numbers. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 54 02:59.960 --> 03:02.960 And fortunately, our budget is based on actual consumption numbers. 55 03:02.960 --> 03:08.570 So maybe I could get 31 or 32 ports depending on how much the power draw 56 03:08.570 --> 03:09.760 actually is. 57 03:09.760 --> 03:13.780 But we can already see that, "Okay, if I deploy a 48-port switch, I can't 58 03:13.780 --> 03:14.880 support APs on 59 03:14.880 --> 03:16.680 every single port." 60 03:16.680 --> 03:19.480 We're losing 18 of those ports. 61 03:19.480 --> 03:20.480 It's okay. 62 03:20.480 --> 03:24.640 So fine, we probably don't need that much density on a single switch anyways. 63 03:24.640 --> 03:33.350 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 63 03:24.640 --> 03:33.350 However, our access points, the only POE devices, what happens if I have, for 64 03:33.350 --> 03:34.720 example, voice 65 03:34.720 --> 03:38.560 over IP phones? 66 03:38.560 --> 03:41.450 Those phones are going to have a power draw as well, especially we're talking 67 03:41.450 --> 03:41.880 about an 68 03:41.880 --> 03:43.280 access layer switch here. 69 03:43.280 --> 03:47.260 So there were probably going to have some number of voice over IP phones these 70 03:47.260 --> 03:47.800 days. 71 03:47.800 --> 03:51.360 We might also have security cameras. 72 03:51.360 --> 03:55.920 And security cameras, they have a very high power draw. 73 03:55.920 --> 04:00.800 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 73 03:55.920 --> 04:00.800 They might actually exceed 30 watts on a per camera basis, especially if we 74 04:00.800 --> 04:01.680 have the concepts 75 04:01.680 --> 04:05.850 of zooming and tilting and all of the things that are required, you know, 76 04:05.850 --> 04:07.000 motors inside of 77 04:07.000 --> 04:11.120 these cameras, they call them pan tilt zooms or PTs. 78 04:11.120 --> 04:13.680 Pan tilt zoom, PTs, yeah, that's it. 79 04:13.680 --> 04:19.600 So we might see a lot of power draw that's being taken by these other devices. 80 04:19.600 --> 04:24.230 And so we can't just assume that we'll be good based on whatever the power draw 81 04:24.230 --> 04:24.720 is of an 82 04:24.720 --> 04:28.200 access point multiplied by the number of access points. 83 04:28.200 --> 04:29.600 And so what can we do here? 84 04:29.600 --> 04:31.040 Well, a couple of things. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 84 04:29.600 --> 04:31.040 Well, a couple of things. 85 04:31.040 --> 04:35.800 First of all, we could look at switches, maybe they have higher power budgets. 86 04:35.800 --> 04:41.000 Maybe we can get a 48 port switch that has a 1200 watt budget or something like 87 04:41.000 --> 04:41.280 that. 88 04:41.280 --> 04:44.440 Or we could look at deploying multiple 24 port switches. 89 04:44.440 --> 04:48.820 So if I deploy two 24 port switches where there would have been a 48 port 90 04:48.820 --> 04:49.720 switch, each 91 04:49.720 --> 04:54.960 one of these maybe can have a 900 watt draw or power budget rather. 92 04:54.960 --> 05:00.090 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 92 04:54.960 --> 05:00.090 And so at that point, we have made our port or our switches a little more power 93 05:00.090 --> 05:00.840 dense. 94 05:00.840 --> 05:04.560 So these are some design philosophy changes we could make to make sure that we 95 05:04.560 --> 05:04.760 have the 96 05:04.760 --> 05:07.840 proper power budgets. 97 05:07.840 --> 05:12.480 Now one last feature I want to talk about is the concept of multi gig. 98 05:12.480 --> 05:18.400 It's a pretty common conversation these days, especially in the wireless space. 99 05:18.400 --> 05:22.640 The reason for that is, first of all, let's just say what multi gig is. 100 05:22.640 --> 05:29.900 Multi gig is the ability for me to deploy 2.5 gig and 5 gig a bit per second on 101 05:29.900 --> 05:30.200 base WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 101 05:29.900 --> 05:30.200 base 102 05:30.200 --> 05:37.400 T deployments meaning copper RJ45. 103 05:37.400 --> 05:42.490 Before multi gig came out, we had one gig base T and we had 10 gig base T. And 104 05:42.490 --> 05:42.680 so if I 105 05:42.680 --> 05:46.460 needed more than one gig, I would have to go to 10 gig and 10 gig ports are 106 05:46.460 --> 05:47.640 kind of expensive. 107 05:47.640 --> 05:54.420 And we need cat 6a or cat 7 type of cables to make sure I get my full 100 108 05:54.420 --> 05:55.440 meters. 109 05:55.440 --> 06:01.380 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 109 05:55.440 --> 06:01.380 So multi gig came out and it allows 2.5 gig and 5 gig even on cat 5e which is 110 06:01.380 --> 06:02.240 wonderful 111 06:02.240 --> 06:06.970 because we have a lot of cat 5e out there in the environment and a lot of our 112 06:06.970 --> 06:07.760 buildings 113 06:07.760 --> 06:09.320 and it's also very cheap. 114 06:09.320 --> 06:14.120 And so I could actually still today pull brand new cat 5e connections. 115 06:14.120 --> 06:16.040 So why does this impact wireless? 116 06:16.040 --> 06:20.320 Well it impacts wireless because our access points today are capable on the 117 06:20.320 --> 06:21.800 wireless side 118 06:21.800 --> 06:26.160 of communicating at far greater than 1 gig. 119 06:26.160 --> 06:32.960 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 119 06:26.160 --> 06:32.960 In fact we can see communications up to something like 9.6 gig a bit per second 120 06:32.960 --> 06:33.280 depending 121 06:33.280 --> 06:37.240 on the radio configuration and the stations and all these things. 122 06:37.240 --> 06:42.420 So at that point I could say well I should connect this to a 10 gig base T 123 06:42.420 --> 06:43.640 switch port. 124 06:43.640 --> 06:48.860 Except even at 9.6 gig on the wireless side, the amount of actual throughput 125 06:48.860 --> 06:49.720 doesn't quite 126 06:49.720 --> 06:52.360 translate to what we're seeing there. 127 06:52.360 --> 06:57.800 I could for example see 9.6 gig a bit per second data rates but I'm only really 128 06:57.800 --> 06:58.600 seeing 1 129 06:58.600 --> 07:02.440 to 2 gig because of the efficiency of wireless. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 129 06:58.600 --> 07:02.440 to 2 gig because of the efficiency of wireless. 130 07:02.440 --> 07:07.810 Again it's half duplex it requires us dealing with retransmeds contention and 131 07:07.810 --> 07:09.080 interference. 132 07:09.080 --> 07:13.230 And so it's great to look at a raw data rate but the question is what is the 133 07:13.230 --> 07:14.080 throughput 134 07:14.080 --> 07:20.210 and what's making it through to the access point or back and forth ultimately 135 07:20.210 --> 07:20.880 is usually 136 07:20.880 --> 07:24.880 far less than what the radio is capable of doing. 137 07:24.880 --> 07:28.520 We might even see a situation where we're less than a gig. 138 07:28.520 --> 07:33.340 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 138 07:28.520 --> 07:33.340 Maybe we've got 500 Meg that we're expecting based on the number of stations 139 07:33.340 --> 07:34.240 and the quality 140 07:34.240 --> 07:36.640 of stations that are out there. 141 07:36.640 --> 07:40.550 So we could look at this and say oh man I need multi gig on all of my access 142 07:40.550 --> 07:41.040 points 143 07:41.040 --> 07:44.360 and yet I don't actually require multi gig. 144 07:44.360 --> 07:46.040 So it's a conversation point. 145 07:46.040 --> 07:50.180 If we're upgrading our switches we should look long and hard at multi gig 146 07:50.180 --> 07:50.960 because we have 147 07:50.960 --> 07:53.240 to think 5, 6, 7 years out. 148 07:53.240 --> 07:57.670 If I'm buying a new access layer set of switches I expect them to last a long 149 07:57.670 --> 07:58.320 time. 150 07:58.320 --> 08:03.070 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 150 07:58.320 --> 08:03.070 And I might do a wireless upgrade and all of a sudden I need 1 to 2 gig rather 151 08:03.070 --> 08:04.120 than 500 152 08:04.120 --> 08:08.120 Meg and then I'm going to regret not deploying multi gig. 153 08:08.120 --> 08:10.720 But if we're looking at deploying these types of access points do we 154 08:10.720 --> 08:12.440 immediately need to go 155 08:12.440 --> 08:17.240 and upgrade our switches to deliver multi gig and the answer is usually no. 156 08:17.240 --> 08:20.930 We need to perform some kind of analysis to figure out what that throughput is 157 08:20.930 --> 08:21.400 going to 158 08:21.400 --> 08:24.400 look like and whether we really need multi gig. 159 08:24.400 --> 08:29.040 Because as soon as we do exceed 1 and 2 gig a bit per second yeah we're going 160 08:29.040 --> 08:29.560 to want 161 08:29.560 --> 08:33.760 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 161 08:29.560 --> 08:33.760 to consider multi gig and potentially even 10 gig if we start to get to that 162 08:33.760 --> 08:34.400 point. 163 08:34.400 --> 08:39.050 And we might see that more as wifi 7 wifi 8 start to come out and give us even 164 08:39.050 --> 08:39.680 greater 165 08:39.680 --> 08:41.720 throughputs on the radio. 166 08:41.720 --> 08:46.380 But within the context of this conversation within the the world that we live 167 08:46.380 --> 08:46.920 in as of 168 08:46.920 --> 08:51.580 the moment I'm recording this very often multi gig is something that's nice to 169 08:51.580 --> 08:52.160 have not 170 08:52.160 --> 08:53.680 strictly required. 171 08:53.680 --> 08:58.220 But again from a future consideration perspective if we're doing an access 172 08:58.220 --> 08:59.280 layer upgrade we 173 08:59.280 --> 09:02.760 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 173 08:59.280 --> 09:02.760 probably want to consider multi gig in the same way we're considering the level 174 09:02.760 --> 09:02.920 of 175 09:02.920 --> 09:07.630 POE to deploy as well as the power budgets so that we're not going to regret 176 09:07.630 --> 09:08.600 deploying 177 09:08.600 --> 09:12.840 access layer switches that have only last 2 or 3 years.