WEBVTT 1 00:00.000 --> 00:05.120 I don't know about you, but when I first started using wireless devices, I made 2 00:05.120 --> 00:06.360 an assumption 3 00:06.360 --> 00:10.800 that all of these wireless devices were just all communicating at the exact 4 00:10.800 --> 00:11.680 same time. 5 00:11.680 --> 00:16.620 And as I got into the world of network engineering and especially the wireless 6 00:16.620 --> 00:17.600 side of things, 7 00:17.600 --> 00:21.400 you start to learn that some of your assumptions like that might not quite be 8 00:21.400 --> 00:22.120 correct. 9 00:22.120 --> 00:27.550 The reality is that when we're talking about wireless as a medium, this is half 10 00:27.550 --> 00:28.480 -duplex. 11 00:28.480 --> 00:34.580 When we think back to our wired Ethernet, studies we recall that half-duplex WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 11 00:28.480 --> 00:34.580 When we think back to our wired Ethernet, studies we recall that half-duplex 12 00:34.580 --> 00:37.480 means that we need to take turns. 13 00:37.480 --> 00:43.880 We can only have a single transmission going at a single time. 14 00:43.880 --> 00:50.280 And so we think about a room with tons of wireless devices and all of these 15 00:50.280 --> 00:51.040 devices, 16 00:51.040 --> 00:56.150 whether it's our mobile phones or our laptops or whatever it is, we have 17 00:56.150 --> 00:57.040 connected to the Wi-Fi. 18 00:57.040 --> 01:00.040 They're all blinking their lights and it looks like everybody's just WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 18 00:57.040 --> 01:00.040 They're all blinking their lights and it looks like everybody's just 19 01:00.040 --> 01:01.840 communicating at the same time. 20 01:01.840 --> 01:07.840 But when we shrink the wireless world down to milliseconds and nanoseconds, 21 01:07.840 --> 01:13.630 what we find is that this device starts transmitting and that transmission ends 22 01:13.630 --> 01:13.640 . 23 01:13.640 --> 01:18.290 And then everybody sort of sits there and listens. There's actually a downtime 24 01:18.290 --> 01:18.640 here. 25 01:18.640 --> 01:23.730 And once we decide that, "Hey, nobody else is communicating, then somebody else 26 01:23.730 --> 01:25.040 will start speaking." 27 01:25.040 --> 01:28.730 And then there will be another wait time and then somebody else will take a 28 01:28.730 --> 01:30.240 turn and start speaking. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 28 01:28.730 --> 01:30.240 turn and start speaking. 29 01:30.240 --> 01:36.640 And again, when we zoom in to this level, we're truly talking about nanoseconds 30 01:36.640 --> 01:38.040 and milliseconds here. 31 01:38.040 --> 01:43.330 When we're talking about that small of a time gap, we really do find that there 32 01:43.330 --> 01:46.440 's only one transmission happening at a time. 33 01:46.440 --> 01:51.810 Furthermore, with the wired world, we had a sense of whether our transmission 34 01:51.810 --> 01:52.840 went through. 35 01:52.840 --> 01:56.640 Remember this concept of CSMA-CD. 36 01:56.640 --> 02:02.240 This was for the wired world. When you're sharing a medium, it's carrier sense, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 36 01:56.640 --> 02:02.240 This was for the wired world. When you're sharing a medium, it's carrier sense, 37 02:02.240 --> 02:04.640 multiple access collision detection. 38 02:04.640 --> 02:08.080 We don't have to worry about this too much in the world of switches, but back 39 02:08.080 --> 02:09.040 when we had hubs, 40 02:09.040 --> 02:12.570 we had to worry a lot about this and whether there'd be a collision on the line 41 02:12.570 --> 02:12.840 . 42 02:12.840 --> 02:16.840 Well, we're not talking about wired right now. We're talking about wireless. 43 02:16.840 --> 02:22.690 And wireless doesn't have the same luxuries, if you want to call it, that the 44 02:22.690 --> 02:24.640 wired networking had. 45 02:24.640 --> 02:28.440 So we have to use something else, something we call carrier sense, multiple 46 02:28.440 --> 02:33.240 access collision avoidance for our wireless communications. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 46 02:28.440 --> 02:33.240 access collision avoidance for our wireless communications. 47 02:33.240 --> 02:37.650 Because we need to know if there was a collision of signals at the point of the 48 02:37.650 --> 02:38.440 receiver. 49 02:38.440 --> 02:43.840 Now, the problem with this is if I send a signal out to the receiver over here, 50 02:43.840 --> 02:49.870 how do I know whether or not there was a signal that collided with it right at 51 02:49.870 --> 02:51.840 the point of the receiver? 52 02:51.840 --> 02:56.570 With wired, I can tell whether there was a collision or not, because I will 53 02:56.570 --> 02:59.640 inevitably see whatever caused the collision, 54 02:59.640 --> 03:04.540 and I can run some math and figure out if my signal happened to be at the WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 54 02:59.640 --> 03:04.540 and I can run some math and figure out if my signal happened to be at the 55 03:04.540 --> 03:06.440 receiver at the same time, 56 03:06.440 --> 03:09.240 or on the medium at the same time as this other signal. 57 03:09.240 --> 03:13.930 With wireless, I don't have that luxury. I might get a signal in after I'm done 58 03:13.930 --> 03:16.240 transmitting and maybe the receiver was here. 59 03:16.240 --> 03:19.580 Maybe the receiver was here. Maybe the receiver was here. I can't even 60 03:19.580 --> 03:27.340 necessarily tell the direction of whether these wireless competing devices were 61 03:27.340 --> 03:28.840 closer to my receiver, 62 03:28.840 --> 03:34.240 further away from my receiver. This is known as a boundless medium. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 62 03:28.840 --> 03:34.240 further away from my receiver. This is known as a boundless medium. 63 03:34.240 --> 03:40.350 There is no way for me to contain this signal. On a wired side, it's contained 64 03:40.350 --> 03:41.240 to the wire. 65 03:41.240 --> 03:44.240 And with wired ethernet, I know that I can only go 100 meters. 66 03:44.240 --> 03:48.500 So again, I can run that math operation to figure out if I just heard a signal 67 03:48.500 --> 03:50.240 after I was done transmitting, 68 03:50.240 --> 03:56.240 was that signal colliding with my signal or did that come long enough later 69 03:56.240 --> 03:59.240 that I know that a collision did not occur? 70 03:59.240 --> 04:05.310 So what exactly is CSMACA, this collision avoidance technique? It essentially WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 70 03:59.240 --> 04:05.310 So what exactly is CSMACA, this collision avoidance technique? It essentially 71 04:05.310 --> 04:08.240 boils down to I'm going to transmit, 72 04:08.240 --> 04:14.240 and then I'm going to wait for an acknowledgement or an act. 73 04:14.240 --> 04:16.240 Yeah, that says wait there. How about that? 74 04:16.240 --> 04:19.240 So we are going to wait for an acknowledgement. 75 04:19.240 --> 04:25.020 What this means is when I have a transmitter and a receiver, my transmission is 76 04:25.020 --> 04:26.240 going to go out, 77 04:26.240 --> 04:30.240 and I'm going to hope for the best. I'm going to hope that my receiver got it, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 77 04:26.240 --> 04:30.240 and I'm going to hope for the best. I'm going to hope that my receiver got it, 78 04:30.240 --> 04:32.240 but I'm not going to assume it got it. 79 04:32.240 --> 04:35.590 In fact, I'm going to assume the opposite. I'm going to assume that that 80 04:35.590 --> 04:41.240 transmission did not get through until I receive an acknowledgement back. 81 04:41.240 --> 04:44.760 Wireless is set up to allow these acknowledgments to come back very, very 82 04:44.760 --> 04:47.240 quickly after the initial transmission was sent. 83 04:47.240 --> 04:51.570 So in theory, nobody else can step in and transmit before the acknowledgement 84 04:51.570 --> 04:52.240 gets out. 85 04:52.240 --> 04:56.550 So if I get this acknowledgement and I see, oh, okay, good, you did receive the 86 04:56.550 --> 05:01.300 packet. Let's say I have three packets or really technically wireless frames to WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 86 04:56.550 --> 05:01.300 packet. Let's say I have three packets or really technically wireless frames to 87 05:01.300 --> 05:02.240 send, since it's at layer two, 88 05:02.240 --> 05:07.240 I might send number one and I get the acknowledgement back, so I check it off. 89 05:07.240 --> 05:11.660 Then I'm ready to send frame number two. So I send frame number two and I get 90 05:11.660 --> 05:13.240 the acknowledgement back. Great. 91 05:13.240 --> 05:17.660 Then I'm ready to send frame number three and I don't get an acknowledgement 92 05:17.660 --> 05:18.240 back. 93 05:18.240 --> 05:21.690 Let's say I have four frames in this case. So now I didn't get an 94 05:21.690 --> 05:25.240 acknowledgement back. I'm not going to go on to frame number four. 95 05:25.240 --> 05:28.970 Instead, I'm going to have to retransmit frame three until I get that 96 05:28.970 --> 05:30.240 acknowledgement. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 96 05:28.970 --> 05:30.240 acknowledgement. 97 05:30.240 --> 05:35.350 So it's a sense of transmissions and retransmissions that hinge on the concept 98 05:35.350 --> 05:37.240 of an acknowledgement. 99 05:37.240 --> 05:41.240 So that is what CSMACA is all about. 100 05:41.240 --> 05:46.040 Now when we talk about collisions, it's a little bit different, but also kind 101 05:46.040 --> 05:53.240 of the same as wired collisions, it's ultimately the intersection of signals. 102 05:53.240 --> 05:58.160 So when two signals overlap each other, they can have a detrimental effect on 103 05:58.160 --> 05:59.240 one another. 104 05:59.240 --> 06:03.740 Now here's the funny thing. What happens when wireless signals collide in free WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 104 05:59.240 --> 06:03.740 Now here's the funny thing. What happens when wireless signals collide in free 105 06:03.740 --> 06:04.240 space? 106 06:04.240 --> 06:09.920 I've got a signal coming here and a signal coming here and they're coming right 107 06:09.920 --> 06:11.240 at each other. What happens when they hit? 108 06:11.240 --> 06:16.240 Are they permanently disfigured and believe it or not, the answer is no. 109 06:16.240 --> 06:20.650 If these two signals pass by each other, signal A and signal B are just going 110 06:20.650 --> 06:25.840 to pass through each other and now signal B is over here and signal A is over 111 06:25.840 --> 06:28.240 here and they just keep going their merry ways. 112 06:28.240 --> 06:32.980 That concept of ships in a night, that phrase that basically implies that they WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 112 06:28.240 --> 06:32.980 That concept of ships in a night, that phrase that basically implies that they 113 06:32.980 --> 06:37.940 pass right by or in this case right through each other and they just don't care 114 06:37.940 --> 06:38.240 . 115 06:38.240 --> 06:40.240 They signals are fully intact. 116 06:40.240 --> 06:45.890 The problem is what happens if the receiver is right here where the collision 117 06:45.890 --> 06:47.240 is occurring. 118 06:47.240 --> 06:49.240 Now there's a problem. 119 06:49.240 --> 06:53.890 If the receiver is over here and signal A passes through B and it ultimately 120 06:53.890 --> 06:58.890 arrives at the receiver, it's going to be intact at that point and that's great 121 06:58.890 --> 06:59.240 . 122 06:59.240 --> 07:04.660 But if the receiver is here in the middle, this is where that collision concept WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 122 06:59.240 --> 07:04.660 But if the receiver is here in the middle, this is where that collision concept 123 07:04.660 --> 07:10.610 occurs and now the receiver is not going to be able to tell the difference 124 07:10.610 --> 07:12.240 between those signals. 125 07:12.240 --> 07:20.170 This is what we refer to as wireless interference and we do need to keep in 126 07:20.170 --> 07:27.240 mind that interference only happens for same frequencies. 127 07:27.240 --> 07:30.370 What happens if A and B come in and they're two completely different WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 127 07:27.240 --> 07:30.370 What happens if A and B come in and they're two completely different 128 07:30.370 --> 07:34.360 frequencies? We've got A with a lower frequency and maybe B with a higher 129 07:34.360 --> 07:35.240 frequency. 130 07:35.240 --> 07:40.820 Well, there is technically a collision there but we can use some advanced math 131 07:40.820 --> 07:43.240 to separate those signals out. 132 07:43.240 --> 07:46.780 And as long as there are different frequencies, we can split them out and make 133 07:46.780 --> 07:49.240 sure that I'm only looking at the one I care about. 134 07:49.240 --> 07:53.830 But when it's a same frequency signal that's colliding with another one at the 135 07:53.830 --> 07:58.240 point of reception, this is where we can't separate those signals out. 136 07:58.240 --> 08:02.650 It causes interference and I am not going to be able to send that WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 136 07:58.240 --> 08:02.650 It causes interference and I am not going to be able to send that 137 08:02.650 --> 08:04.240 acknowledgement. 138 08:04.240 --> 08:08.180 Now this is interesting because we just said that we're taking turns here and 139 08:08.180 --> 08:12.190 yet we also just said that there's this intersection of signals that can cause 140 08:12.190 --> 08:13.240 interference. 141 08:13.240 --> 08:18.200 So if we're taking turns and everybody's doing their part, then how can we even 142 08:18.200 --> 08:22.240 have two different signals out there of the same frequency? 143 08:22.240 --> 08:27.000 Well, there's a pretty simple answer for this and it comes back to the fact 144 08:27.000 --> 08:29.240 that wireless is a boundless medium. 145 08:29.240 --> 08:34.960 So imagine this. Imagine I have an access point here and I have transmitter A WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 145 08:29.240 --> 08:34.960 So imagine this. Imagine I have an access point here and I have transmitter A 146 08:34.960 --> 08:38.240 over on the left and I have transmitter B on the right. 147 08:38.240 --> 08:42.240 So maybe these are two different mobile devices connected to an AP. 148 08:42.240 --> 08:46.240 So now, again, zooming in here, we see that nobody is communicating. 149 08:46.240 --> 08:51.140 A and B are both ready to transmit a frame. They listen and they both start 150 08:51.140 --> 08:53.240 transmitting at the same time. 151 08:53.240 --> 08:59.130 So that can happen, but I will say it's not very likely. Wireless is pretty 152 08:59.130 --> 09:04.380 good about operating in distinct intervals and chances are by the time A starts WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 152 08:59.130 --> 09:04.380 good about operating in distinct intervals and chances are by the time A starts 153 09:04.380 --> 09:07.240 transmitting B would actually hear A. 154 09:07.240 --> 09:13.400 But here's the problem. What if A is so far away that by the time its signal 155 09:13.400 --> 09:18.240 gets to be it's not legible anymore or readable. 156 09:18.240 --> 09:22.780 Listenable, whatever we want to say, it's lightweight. So I guess we would say 157 09:22.780 --> 09:25.240 it's not visible anymore to transmit B. 158 09:25.240 --> 09:31.150 So A listens, it's empty starts transmitting. Later on B decides to start WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 158 09:25.240 --> 09:31.150 So A listens, it's empty starts transmitting. Later on B decides to start 159 09:31.150 --> 09:35.240 transmitting because it can't actually hear A communicating. 160 09:35.240 --> 09:39.670 This is called a hidden node problem. It's a very common situation with 161 09:39.670 --> 09:40.240 wireless. 162 09:40.240 --> 09:45.930 And because these transmitters are so far apart from one another, they might 163 09:45.930 --> 09:50.100 actually end up causing a lot of collisions because they're going to keep 164 09:50.100 --> 09:51.240 trying to speak on top of each other. 165 09:51.240 --> 09:56.150 But they can't actually hear one another. Meanwhile the AP here in the middle 166 09:56.150 --> 09:57.240 can hear both of them. 167 09:57.240 --> 10:01.920 And it's going to result in a lot of problems. And we have mechanisms to help WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 167 09:57.240 --> 10:01.920 And it's going to result in a lot of problems. And we have mechanisms to help 168 10:01.920 --> 10:03.240 resolve this issue. 169 10:03.240 --> 10:08.660 But I'm bringing this up as a way to illustrate how collisions can occur and 170 10:08.660 --> 10:14.580 kind of the challenges that wireless presents that we just don't have to worry 171 10:14.580 --> 10:18.240 about when it comes to wired communications. 172 10:18.240 --> 10:23.720 So why can an axis point not read the signal if we have interference? Well, 173 10:23.720 --> 10:27.240 because when we look at our waveforms, 174 10:27.240 --> 10:32.310 waveforms are measuring energy. Remember that concept of amplitude and origin, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 174 10:27.240 --> 10:32.310 waveforms are measuring energy. Remember that concept of amplitude and origin, 175 10:32.310 --> 10:35.240 the amount of energy that is in the waveform here. 176 10:35.240 --> 10:41.900 When we're looking at signal A coming in, and then we have signal B down here 177 10:41.900 --> 10:46.240 that's the same frequency, what we end up doing is sort of this waveform math. 178 10:46.240 --> 10:51.290 I can take this positive value, let's say it's at positive 2 here. Well, here 179 10:51.290 --> 10:54.240 it's actually at negative 2. 180 10:54.240 --> 10:59.110 So you add these up and it's 0. And then same thing here, this is negative 2 181 10:59.110 --> 11:04.030 and positive 2 or whatever the value is, ultimately these two waveforms end up WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 181 10:59.110 --> 11:04.030 and positive 2 or whatever the value is, ultimately these two waveforms end up 182 11:04.030 --> 11:05.240 canceling out. 183 11:05.240 --> 11:09.650 Again, this addition problem, so to speak, is kind of an illustration of what 184 11:09.650 --> 11:13.800 happens. And so two signals can actually cancel each other out if they're the 185 11:13.800 --> 11:15.240 exact same frequency. 186 11:15.240 --> 11:20.730 But interestingly, if we take two signals that are the same, go back a little 187 11:20.730 --> 11:25.240 ways here, what happens if they're the same as one another. 188 11:25.240 --> 11:30.080 Well, that waveform math still applies and you end up with a signal that's the WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 188 11:25.240 --> 11:30.080 Well, that waveform math still applies and you end up with a signal that's the 189 11:30.080 --> 11:33.240 same frequency, but a much higher amplitude. 190 11:33.240 --> 11:38.120 And so we can actually use this to our advantage, a lot of modern wireless 191 11:38.120 --> 11:43.240 devices do use this to their advantage and this can create a signal boost. 192 11:43.240 --> 11:48.400 But this requires very precise overlap of signals, requires calculated transm 193 11:48.400 --> 11:54.540 issions. And so more often than not, we do some form of waveform math that 194 11:54.540 --> 12:00.240 creates this wonky signal or a canceled out signal that nobody can read. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 194 11:54.540 --> 12:00.240 creates this wonky signal or a canceled out signal that nobody can read. 195 12:00.240 --> 12:07.240 And so that's why when we are talking about collisions, that that's bad news. 196 12:07.240 --> 12:13.160 Now one last thing to keep in mind in all this is what we said up here, which 197 12:13.160 --> 12:18.240 is that signals degrade over time, meaning that they lose their energy. 198 12:18.240 --> 12:22.300 Wireless signal doesn't last forever. Most of us are familiar with this concept 199 12:22.300 --> 12:25.910 just because we use wireless devices and we've got that signal strength 200 12:25.910 --> 12:30.900 indicator on our phones that maybe indicates whether I've got really strong WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 200 12:25.910 --> 12:30.900 indicator on our phones that maybe indicates whether I've got really strong 201 12:30.900 --> 12:33.240 service or really weak service. 202 12:33.240 --> 12:38.370 And the idea here is that if I'm trying to communicate to a cellular tower or a 203 12:38.370 --> 12:43.240 Wi-Fi access point either way, that signals do degrade over time. 204 12:43.240 --> 12:51.240 And so what we'll also find is this is relative to our frequency. 205 12:51.240 --> 12:58.560 The higher the frequency, the lower the distance, meaning that a high frequency 206 12:58.560 --> 13:02.240 signal will degrade faster over time. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 206 12:58.560 --> 13:02.240 signal will degrade faster over time. 207 13:02.240 --> 13:06.750 So if I draw a high frequency signal here, it'll degrade faster than a low 208 13:06.750 --> 13:11.240 frequency signal, although both do eventually degrade over time. 209 13:11.240 --> 13:17.280 So if we're comparing, for example, our 5 gigahertz wireless to our 2.4 giga 210 13:17.280 --> 13:23.260 hertz wireless will see that 2.4 goes quite a bit further and 6 gigahertz goes 211 13:23.260 --> 13:26.240 even less far than the 5 gigahertz. 212 13:26.240 --> 13:30.510 So that's something to consider as we look at deploying different bands and WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 212 13:26.240 --> 13:30.510 So that's something to consider as we look at deploying different bands and 213 13:30.510 --> 13:33.240 different channels into our environment. 214 13:33.240 --> 13:37.720 Really, it's more of a band level conversation than channel, but again, in 215 13:37.720 --> 13:40.240 general, it's relative to frequency. 216 13:40.240 --> 13:44.250 And so the higher the frequency of a signal, the lower the distance we can 217 13:44.250 --> 13:48.590 expect it to go, and that will be something we need to consider when it comes 218 13:48.590 --> 13:49.240 to our cell designs. 219 13:49.240 --> 13:49.920 designs.