WEBVTT

1
00:00:00.120 --> 00:00:03.160
<v Speaker 1>You know, you're probably used to your phone always being connected, right,

2
00:00:03.600 --> 00:00:07.440
<v Speaker 1>but what about like everything else around you. Imagine your

3
00:00:07.679 --> 00:00:11.039
<v Speaker 1>smart firmostat at home, or maybe a city traffic light,

4
00:00:11.359 --> 00:00:14.359
<v Speaker 1>or even say a water meter hidden deep down in

5
00:00:14.400 --> 00:00:17.879
<v Speaker 1>a basement somewhere. What if all these different devices could

6
00:00:17.879 --> 00:00:22.920
<v Speaker 1>communicate really efficiently, sending and getting data, all while running

7
00:00:22.920 --> 00:00:25.399
<v Speaker 1>on just a tiny battery, and not just for months,

8
00:00:25.399 --> 00:00:27.079
<v Speaker 1>but potentially for a whole decade.

9
00:00:27.239 --> 00:00:29.440
<v Speaker 2>Yeah. That sounds almost like science fiction, doesn't it. But

10
00:00:29.559 --> 00:00:31.800
<v Speaker 2>it's actually the reality of a technology we're going to

11
00:00:31.839 --> 00:00:35.920
<v Speaker 2>dive into today. It's called narrowband Internet of Things, or

12
00:00:36.000 --> 00:00:39.280
<v Speaker 2>you'll often hear it called NBIOT exactly.

13
00:00:39.640 --> 00:00:42.320
<v Speaker 1>And we've gathered a pretty comprehensive stack of sources for

14
00:00:42.359 --> 00:00:47.079
<v Speaker 1>this deep dive, including a really detailed technical book. Our mission, well,

15
00:00:47.119 --> 00:00:50.200
<v Speaker 1>it's pretty straightforward. We want to pull out the essential insights.

16
00:00:50.200 --> 00:00:54.960
<v Speaker 1>We want to understand the clever engineering behind NBIOT.

17
00:00:54.840 --> 00:00:57.200
<v Speaker 2>And discover some of the surprising ways it's already shaping

18
00:00:57.240 --> 00:00:58.880
<v Speaker 2>our connected future, right.

19
00:00:58.960 --> 00:01:01.039
<v Speaker 1>And we want to do it with out getting totally

20
00:01:01.079 --> 00:01:05.480
<v Speaker 1>bogged down and overly complex technical jargon. By the end,

21
00:01:05.480 --> 00:01:07.599
<v Speaker 1>you should have a really good handle on what makes

22
00:01:07.599 --> 00:01:10.480
<v Speaker 1>this technology so unique and honestly is so vital.

23
00:01:10.760 --> 00:01:13.680
<v Speaker 2>Okay, so maybe we should start by tracing the wireless

24
00:01:13.760 --> 00:01:16.519
<v Speaker 2>journey a bit, because it's been quite an evolution.

25
00:01:16.719 --> 00:01:19.040
<v Speaker 1>Good idea. Yeah, I mean, back in the nineteen eighties

26
00:01:19.079 --> 00:01:21.519
<v Speaker 1>we had one G mostly just for voice calls, right

27
00:01:21.680 --> 00:01:25.719
<v Speaker 1>then two G brought in digital voice, some basic data, and.

28
00:01:25.599 --> 00:01:29.200
<v Speaker 2>Then three G with things like WCDMA that really kicked

29
00:01:29.239 --> 00:01:32.200
<v Speaker 2>off mobile broadband. Suddenly we had a richer mix voice

30
00:01:32.280 --> 00:01:34.200
<v Speaker 2>video data, and by the time.

31
00:01:34.040 --> 00:01:37.480
<v Speaker 1>For GLTE came along, we were fully in the multimedia era.

32
00:01:37.640 --> 00:01:40.640
<v Speaker 1>And that's actually where the groundwork for something called machine

33
00:01:40.640 --> 00:01:43.879
<v Speaker 1>type communication or MTC really start to get laid.

34
00:01:44.079 --> 00:01:46.439
<v Speaker 2>Yeah, that's a key point. MTC was this shift in

35
00:01:46.480 --> 00:01:49.719
<v Speaker 2>thinking beyond just people talking to people. It was about

36
00:01:49.760 --> 00:01:52.840
<v Speaker 2>devices communicating directly with the network or maybe even with

37
00:01:52.920 --> 00:01:56.280
<v Speaker 2>each other, no humans involved directly, and the Internet of

38
00:01:56.319 --> 00:02:00.719
<v Speaker 2>Things IoT. That's basically the full realization of what MTC

39
00:02:00.799 --> 00:02:04.519
<v Speaker 2>was aiming for, a world packed with connected things. And

40
00:02:04.560 --> 00:02:08.039
<v Speaker 2>these things are usually pretty simple, right, low complexity, needing

41
00:02:08.080 --> 00:02:10.360
<v Speaker 2>long range communication, super low.

42
00:02:10.199 --> 00:02:13.680
<v Speaker 1>Power, right, often just sending tiny bits of data that

43
00:02:13.680 --> 00:02:17.159
<v Speaker 1>aren't super urgent, like you said, a smart meter reporting

44
00:02:17.400 --> 00:02:20.000
<v Speaker 1>or reading once a day exactly.

45
00:02:20.319 --> 00:02:23.520
<v Speaker 2>And the scale we're talking about is just massive millions

46
00:02:23.560 --> 00:02:25.639
<v Speaker 2>of devices post square kilometer potentially.

47
00:02:25.719 --> 00:02:28.840
<v Speaker 1>Wow. And that's exactly where MBIOT comes in, isn't it.

48
00:02:28.879 --> 00:02:32.240
<v Speaker 2>Precisely? It's not just another iteration. It was specifically designed

49
00:02:32.319 --> 00:02:34.719
<v Speaker 2>kind of a script down version of LTE built by

50
00:02:34.759 --> 00:02:38.039
<v Speaker 2>three GPP just for this purpose to handle the unique,

51
00:02:38.159 --> 00:02:42.439
<v Speaker 2>sometimes extreme demands of connecting huge numbers of simple devices.

52
00:02:42.560 --> 00:02:44.360
<v Speaker 1>And when you look at the design goals, you immediately

53
00:02:44.360 --> 00:02:46.360
<v Speaker 1>see why it's such a big deal for you know,

54
00:02:46.400 --> 00:02:48.199
<v Speaker 1>making this connected world actually happen.

55
00:02:48.479 --> 00:02:52.439
<v Speaker 2>Absolutely, the goals were well ambitious, but there what make

56
00:02:52.479 --> 00:02:56.039
<v Speaker 2>widespread IoT practical. First off, ultra low cost. They were

57
00:02:56.039 --> 00:02:57.479
<v Speaker 2>aiming for just five dollars US.

58
00:02:57.360 --> 00:03:01.240
<v Speaker 1>Deeper device five dollars. That's incredible. That really opens things up.

59
00:03:01.520 --> 00:03:06.360
<v Speaker 2>It does then maybe the most critical part minimal power

60
00:03:06.400 --> 00:03:09.919
<v Speaker 2>consumption leading to that crazy long battery life. We're talking

61
00:03:09.960 --> 00:03:13.080
<v Speaker 2>devices designed to sit power in the nanolam range. So

62
00:03:13.159 --> 00:03:16.439
<v Speaker 2>a single small battery maybe five wat hour capacity could

63
00:03:16.439 --> 00:03:18.280
<v Speaker 2>potentially last up to ten years.

64
00:03:18.280 --> 00:03:22.000
<v Speaker 1>Ten years, just imagine installing something and basically forgetting about

65
00:03:22.000 --> 00:03:24.479
<v Speaker 1>the battery for a decade. That's a game changer totally.

66
00:03:24.840 --> 00:03:27.319
<v Speaker 2>Another big one was extended coverage. The goal was twenty

67
00:03:27.360 --> 00:03:30.199
<v Speaker 2>dB beats better reach indoors and outdoors compared to older

68
00:03:30.240 --> 00:03:34.159
<v Speaker 2>stuff like gprs, so connectivity and really tough spots, basements,

69
00:03:34.360 --> 00:03:36.280
<v Speaker 2>utility shafts, even underground.

70
00:03:36.400 --> 00:03:38.319
<v Speaker 1>Okay, that makes sense for things like meters.

71
00:03:38.439 --> 00:03:41.840
<v Speaker 2>Yeah. And finally, low complexity to keep the hardware cheap

72
00:03:42.000 --> 00:03:45.000
<v Speaker 2>and low latency, but low in an IoT context. Right, Yeah,

73
00:03:45.039 --> 00:03:47.199
<v Speaker 2>so ten seconds or last for ninety nine percent of

74
00:03:47.240 --> 00:03:50.039
<v Speaker 2>devices for data that isn't time critical.

75
00:03:49.719 --> 00:03:52.080
<v Speaker 1>Got it? So not instant, but fast enough for most

76
00:03:52.199 --> 00:03:53.680
<v Speaker 1>sensor application exactly.

77
00:03:53.800 --> 00:03:56.199
<v Speaker 2>And if you zoom out a bit, nbiot actually fits

78
00:03:56.199 --> 00:03:59.080
<v Speaker 2>perfectly into the bigger five G vision, the IMT twenty

79
00:03:59.120 --> 00:04:02.840
<v Speaker 2>twenty requirements. That vision includes things like massive connection density

80
00:04:03.080 --> 00:04:06.199
<v Speaker 2>up to one million devices per square kilometer, and nbiot

81
00:04:06.479 --> 00:04:08.879
<v Speaker 2>is a key enabler for a lot of those use cases.

82
00:04:09.039 --> 00:04:12.039
<v Speaker 1>Okay, those are some seriously impressive goals. That ten year

83
00:04:12.080 --> 00:04:15.800
<v Speaker 1>battery life especially just jumps out from an engineering standpoint.

84
00:04:15.840 --> 00:04:19.199
<v Speaker 1>What was the like the magic trick? How did they

85
00:04:19.240 --> 00:04:22.120
<v Speaker 1>actually unlock that kind of longevity? It must involve some

86
00:04:22.160 --> 00:04:23.759
<v Speaker 1>really clever design.

87
00:04:23.839 --> 00:04:26.560
<v Speaker 2>Yeah, it wasn't just one thing, def not a single

88
00:04:26.600 --> 00:04:30.519
<v Speaker 2>magic bullet. It was really a combination of smart choices

89
00:04:31.120 --> 00:04:34.199
<v Speaker 2>across the different communication layers. You know, how the device

90
00:04:34.519 --> 00:04:38.480
<v Speaker 2>talks to the network, secures data, sends messages reliably, all that.

91
00:04:38.439 --> 00:04:40.800
<v Speaker 1>Stuff, right, the whole protocol stack exactly.

92
00:04:41.319 --> 00:04:43.959
<v Speaker 2>And maybe one of the biggest breakthroughs a real power

93
00:04:44.000 --> 00:04:48.680
<v Speaker 2>saving superpower something called power saving mode or PSM PSM. Okay,

94
00:04:48.800 --> 00:04:52.079
<v Speaker 2>This lets a device basically switch off its radio completely

95
00:04:52.240 --> 00:04:55.600
<v Speaker 2>for really long periods. Yeah, and I mean long, potentially

96
00:04:55.680 --> 00:04:56.920
<v Speaker 2>up to four hundred thirteen days.

97
00:04:56.920 --> 00:05:00.000
<v Speaker 1>Wait, four hundred and thirteen days while still being registered.

98
00:05:00.240 --> 00:05:02.959
<v Speaker 2>Yeah. It stays registered with the network, so the network

99
00:05:03.000 --> 00:05:05.399
<v Speaker 2>knows it exists, it knows it's sleeping, and it won't

100
00:05:05.399 --> 00:05:07.639
<v Speaker 2>try to page it or send it anything during that time.

101
00:05:08.079 --> 00:05:10.519
<v Speaker 2>So think about that smart water meter again. It could

102
00:05:10.519 --> 00:05:12.959
<v Speaker 2>wake up maybe once a week, send its reading.

103
00:05:12.879 --> 00:05:16.560
<v Speaker 1>And then just go back into deep hibernation for ages

104
00:05:16.680 --> 00:05:19.079
<v Speaker 1>without needing to reconnect from scratch every.

105
00:05:18.920 --> 00:05:22.319
<v Speaker 2>Time, precisely like a data bear hibernating. It saves a

106
00:05:22.399 --> 00:05:25.759
<v Speaker 2>massive amount of power compared to constantly keeping the radioactive

107
00:05:25.839 --> 00:05:27.120
<v Speaker 2>or even just lightly sleeping.

108
00:05:27.560 --> 00:05:30.199
<v Speaker 1>Wow, Okay, that's huge, And I think you mentioned something

109
00:05:30.199 --> 00:05:31.920
<v Speaker 1>else too, DRX.

110
00:05:31.560 --> 00:05:34.920
<v Speaker 2>Right, So even when a device isn't in that super

111
00:05:34.959 --> 00:05:38.360
<v Speaker 2>deep PSM sleep, it still needs to save power. That's

112
00:05:38.360 --> 00:05:43.199
<v Speaker 2>where discontinuous reception DRX comes in. Even when it's technically awake,

113
00:05:43.560 --> 00:05:46.439
<v Speaker 2>it's not listening constantly. It only wakes up its receiver

114
00:05:46.600 --> 00:05:50.720
<v Speaker 2>during very specific, pre agreed tiny windows of time okay.

115
00:05:50.480 --> 00:05:52.079
<v Speaker 1>Like little listening appointments exactly.

116
00:05:52.120 --> 00:05:55.199
<v Speaker 2>These are called paging occasions. Within paging frames, it checks

117
00:05:55.199 --> 00:05:57.920
<v Speaker 2>for messages for a very short burst and if there's nothing,

118
00:05:58.000 --> 00:06:03.079
<v Speaker 2>boom back to sleep immediately. And then there's extended DRX EDRX,

119
00:06:03.360 --> 00:06:06.360
<v Speaker 2>which pushes those cycles even further apart, up to about

120
00:06:06.360 --> 00:06:09.120
<v Speaker 2>one hundred and seventy five minutes nearly three hours between

121
00:06:09.199 --> 00:06:11.600
<v Speaker 2>these brief liftening moments most three hours.

122
00:06:11.639 --> 00:06:14.240
<v Speaker 1>So it's like checking your mailbox only at very specific times,

123
00:06:14.279 --> 00:06:16.600
<v Speaker 1>maybe once every few hours, just to save energy.

124
00:06:16.800 --> 00:06:19.680
<v Speaker 2>That's a great analogy. It's all about minimizing the time

125
00:06:19.720 --> 00:06:21.079
<v Speaker 2>the radio components are powered up.

126
00:06:21.120 --> 00:06:23.519
<v Speaker 1>Makes total sense. Okay, So that covers the power saving.

127
00:06:24.000 --> 00:06:27.480
<v Speaker 1>What about actually making the data transfer itself efficient and

128
00:06:27.560 --> 00:06:30.720
<v Speaker 1>reliable because these signals might be weak, right, definitely.

129
00:06:30.920 --> 00:06:35.199
<v Speaker 2>So another layer, the Packet Data Convergence Protocol PDCP, handle

130
00:06:35.279 --> 00:06:38.439
<v Speaker 2>some crucial stuff here. The key insight is making every

131
00:06:38.560 --> 00:06:43.160
<v Speaker 2>single bit count and keeping things secure. PDCP does ciphering

132
00:06:43.240 --> 00:06:46.079
<v Speaker 2>That strong encryption using keys the network.

133
00:06:45.759 --> 00:06:48.480
<v Speaker 1>Provides security is obviously important.

134
00:06:48.079 --> 00:06:51.839
<v Speaker 2>Absolutely, and it also does header compression, specifically something called

135
00:06:51.959 --> 00:06:56.079
<v Speaker 2>robust header compression or ROWHC. This shrinks down the size

136
00:06:56.079 --> 00:07:00.920
<v Speaker 2>of the network headers like TCPIP headers before transmission. Less

137
00:07:00.959 --> 00:07:05.040
<v Speaker 2>data descend means less time transmitting, which saves power and bandwidth.

138
00:07:05.360 --> 00:07:08.319
<v Speaker 2>Plus it includes integrity protection to make sure messages aren't

139
00:07:08.319 --> 00:07:08.720
<v Speaker 2>messed with.

140
00:07:08.759 --> 00:07:12.720
<v Speaker 1>Okay, compressing headers encrypting, that's clever. And what about making

141
00:07:12.720 --> 00:07:15.920
<v Speaker 1>sure the data actually arrives, especially if the connection isn't

142
00:07:15.959 --> 00:07:17.079
<v Speaker 1>perfect right?

143
00:07:17.199 --> 00:07:19.759
<v Speaker 2>That's where the radio link Control ROLC layer comes in.

144
00:07:19.839 --> 00:07:20.079
<v Speaker 1>Yeah.

145
00:07:20.120 --> 00:07:22.360
<v Speaker 2>It offers different levels of reliability, kind of like your

146
00:07:22.360 --> 00:07:27.920
<v Speaker 2>postal service options. There's transparent mode TM super simple, no acknowledgments,

147
00:07:28.279 --> 00:07:30.399
<v Speaker 2>good for basic control messages.

148
00:07:30.160 --> 00:07:31.759
<v Speaker 1>Send and hope pretty much.

149
00:07:32.199 --> 00:07:35.959
<v Speaker 2>Then there's unacknowledged mode UM. This is often used for

150
00:07:36.000 --> 00:07:39.959
<v Speaker 2>things like multicast traffic, sending the same info to multiple devices,

151
00:07:40.240 --> 00:07:42.279
<v Speaker 2>no retransmissions if something gets lost.

152
00:07:42.360 --> 00:07:45.279
<v Speaker 1>Okay, so maybe for less critical one way stuff exactly,

153
00:07:45.360 --> 00:07:45.720
<v Speaker 1>But then.

154
00:07:45.639 --> 00:07:48.879
<v Speaker 2>You have acknowledged mode AM. This is the reliable one.

155
00:07:49.120 --> 00:07:53.360
<v Speaker 2>It uses automatic repeat request ARQ. It waits for acknowledgments,

156
00:07:53.439 --> 00:07:57.560
<v Speaker 2>handles errors, retransmits lost packets, even breaks up large messages

157
00:07:57.560 --> 00:07:59.839
<v Speaker 2>and reassembles them. It guarantees delivery.

158
00:08:00.079 --> 00:08:02.160
<v Speaker 1>Ah okay, So you choose the mode based on how

159
00:08:02.199 --> 00:08:05.199
<v Speaker 1>important the data is, like registered mail versus a standard letter.

160
00:08:05.279 --> 00:08:08.519
<v Speaker 2>You got it. Match the delivery method to the message importance.

161
00:08:08.920 --> 00:08:12.120
<v Speaker 2>Save energy when you can guarantee delivery when you absolutely

162
00:08:12.120 --> 00:08:12.439
<v Speaker 2>have to.

163
00:08:12.639 --> 00:08:15.319
<v Speaker 1>And this reliability does it go even deeper down to

164
00:08:15.360 --> 00:08:16.600
<v Speaker 1>the physical radio level.

165
00:08:16.800 --> 00:08:20.680
<v Speaker 2>It does down to the medium access control MAC and

166
00:08:20.759 --> 00:08:24.680
<v Speaker 2>physical PHY layers. There are more tricks. When devices first

167
00:08:24.680 --> 00:08:28.639
<v Speaker 2>want to talk, they use random access procedures. Often its

168
00:08:28.680 --> 00:08:32.200
<v Speaker 2>contention based. Devices might kind of shout to get attention

169
00:08:32.639 --> 00:08:35.039
<v Speaker 2>and the network sorts it out. A bit chaotic can be,

170
00:08:35.360 --> 00:08:38.279
<v Speaker 2>but it works for these simple devices. Then for dealing

171
00:08:38.279 --> 00:08:43.159
<v Speaker 2>with errors in noisy conditions, there's hybrid automatic repeat request HARQ.

172
00:08:43.919 --> 00:08:47.159
<v Speaker 2>This allows for really fast retransmissions right at the physical layer,

173
00:08:47.440 --> 00:08:49.639
<v Speaker 2>much faster than the RLC layer's ARQ.

174
00:08:49.919 --> 00:08:51.080
<v Speaker 1>Okay, quick error correction.

175
00:08:51.240 --> 00:08:54.039
<v Speaker 2>Yeah. But maybe the most remarkable thing for that twenty

176
00:08:54.120 --> 00:08:57.200
<v Speaker 2>dB coverage game we talked about is subframe repetition. This

177
00:08:57.279 --> 00:09:01.000
<v Speaker 2>is a phy layer technique. Sending a chunk of data

178
00:09:01.080 --> 00:09:04.320
<v Speaker 2>a subframe just once, the device can repeat it many

179
00:09:04.360 --> 00:09:06.919
<v Speaker 2>many times, like sixty four or even one hundred and

180
00:09:06.919 --> 00:09:07.559
<v Speaker 2>twenty eight times.

181
00:09:07.600 --> 00:09:09.360
<v Speaker 1>Repeating the same thing over and over.

182
00:09:09.320 --> 00:09:12.320
<v Speaker 2>Exactly, it dramatically increases the chance that the base station

183
00:09:12.440 --> 00:09:15.200
<v Speaker 2>receives it correctly, even if the signal is incredibly weak

184
00:09:15.279 --> 00:09:18.000
<v Speaker 2>or fading. It's like shouting your message repeatedly until you're

185
00:09:18.039 --> 00:09:21.519
<v Speaker 2>sure it got through. That's key for reaching those difficult locations.

186
00:09:21.799 --> 00:09:24.399
<v Speaker 1>Wow. Okay, so it really is a whole symphony of

187
00:09:24.440 --> 00:09:30.039
<v Speaker 1>intelligent design, deep sleep listening, Windows data compression, different reliability levels,

188
00:09:30.120 --> 00:09:33.320
<v Speaker 1>even just repeating the signal, all to make these tiny

189
00:09:33.360 --> 00:09:36.600
<v Speaker 1>bits of data get through reliably while barely sipping power.

190
00:09:36.759 --> 00:09:37.759
<v Speaker 2>That's the essence of it.

191
00:09:37.879 --> 00:09:41.559
<v Speaker 1>But, like we hinted, all this specialized optimization, right, there

192
00:09:41.600 --> 00:09:43.759
<v Speaker 1>must be trade offs, right. It raises that big question,

193
00:09:44.279 --> 00:09:46.360
<v Speaker 1>if it's so good for these things, why don't we

194
00:09:46.440 --> 00:09:49.559
<v Speaker 1>use NBIOT for you know, our smartphones or laptop.

195
00:09:49.639 --> 00:09:52.279
<v Speaker 2>That's a critical point. Yeah. The trade off for all

196
00:09:52.320 --> 00:09:55.799
<v Speaker 2>that efficiency and coverage is performance in other areas, mainly

197
00:09:55.879 --> 00:09:59.960
<v Speaker 2>speed and latency guarantees NBIOT generally uses what it called

198
00:10:00.120 --> 00:10:04.320
<v Speaker 2>default bearers, which are non guaranteed bitrate non GBR, meaning

199
00:10:04.759 --> 00:10:07.919
<v Speaker 2>meaning the network doesn't promise a specific data speed. It'll

200
00:10:07.919 --> 00:10:10.879
<v Speaker 2>do its best, but during busy time speeds might drop

201
00:10:11.000 --> 00:10:13.360
<v Speaker 2>or packets could even be dropped if there's heavy congestion.

202
00:10:13.919 --> 00:10:17.879
<v Speaker 2>There are quality of service identifiers QCI and Priority levels

203
00:10:18.120 --> 00:10:21.279
<v Speaker 2>ARP to manage traffic, but no hard guarantees.

204
00:10:21.399 --> 00:10:24.039
<v Speaker 1>Okay, best effort, not guaranteed service. That makes sense. So

205
00:10:24.360 --> 00:10:26.360
<v Speaker 1>what are the main limitations we should be aware of?

206
00:10:26.679 --> 00:10:29.279
<v Speaker 2>Well, first and foremost the limited data rate. We're talking

207
00:10:29.600 --> 00:10:33.960
<v Speaker 2>really narrow bandwidth, just one resource block. Typically, physical data

208
00:10:34.039 --> 00:10:36.360
<v Speaker 2>rates are only a few hundreds of kilobits per second

209
00:10:36.600 --> 00:10:38.120
<v Speaker 2>kbps at best.

210
00:10:38.519 --> 00:10:41.960
<v Speaker 1>Definitely not for watching videos or anything data intensive.

211
00:10:41.519 --> 00:10:45.080
<v Speaker 2>Absolutely not. It's purely for small data packets. Another thing

212
00:10:45.159 --> 00:10:49.240
<v Speaker 2>is limited antennas support. These devices are built for simplicity

213
00:10:49.279 --> 00:10:52.639
<v Speaker 2>and low cost. They usually support only one, maybe two

214
00:10:52.639 --> 00:10:55.919
<v Speaker 2>antennas just for received diversity. They don't do the fancy

215
00:10:56.000 --> 00:10:59.399
<v Speaker 2>multi antenna stuff like spatial multiplexing or massive MIMO that

216
00:10:59.480 --> 00:11:01.919
<v Speaker 2>gives modern LTE and five G their high speeds.

217
00:11:02.039 --> 00:11:04.399
<v Speaker 1>Simpler hardware lower speeds, got it.

218
00:11:04.320 --> 00:11:08.600
<v Speaker 2>And maybe the most crucial limitation For many applications, the

219
00:11:08.639 --> 00:11:12.279
<v Speaker 2>core network does not guarantee packet delay. This means it's

220
00:11:12.320 --> 00:11:15.279
<v Speaker 2>great for things that can tolerate delays that hourly temperature

221
00:11:15.320 --> 00:11:18.320
<v Speaker 2>reading the daily meta report, but it's totally unsuitable for

222
00:11:18.360 --> 00:11:20.000
<v Speaker 2>anything real time, like.

223
00:11:19.919 --> 00:11:22.840
<v Speaker 1>Live video or maybe urgent safety alerts or remote control

224
00:11:22.879 --> 00:11:24.480
<v Speaker 1>that needs instant response.

225
00:11:24.320 --> 00:11:27.519
<v Speaker 2>Exactly, anything where a delay of even a few seconds,

226
00:11:27.600 --> 00:11:31.039
<v Speaker 2>let alone potentially longer during congestion, would be a problem.

227
00:11:31.279 --> 00:11:35.720
<v Speaker 2>It's a specialized tool for a specific job, connecting massive

228
00:11:35.840 --> 00:11:39.840
<v Speaker 2>numbers of low power, delay tolerant devices efficiently.

229
00:11:39.519 --> 00:11:42.279
<v Speaker 1>Right connecting the right tool to the right job. Okay,

230
00:11:42.600 --> 00:11:45.759
<v Speaker 1>now that we've unpacked its strengths in these well carefully

231
00:11:45.799 --> 00:11:49.080
<v Speaker 1>engineered limitations, let's make it more concrete. Let's talk real

232
00:11:49.080 --> 00:11:54.320
<v Speaker 1>world examples. Fundamentally, nbiot is about connecting sensors measuring things

233
00:11:54.360 --> 00:11:58.720
<v Speaker 1>like temperature, water levels, parking spot occupancy, and actuators things

234
00:11:58.759 --> 00:12:01.399
<v Speaker 1>that take action like rolling a street light or closing

235
00:12:01.440 --> 00:12:02.200
<v Speaker 1>a valve.

236
00:12:02.200 --> 00:12:05.279
<v Speaker 2>And the impact is already pretty huge and growing. Tack

237
00:12:05.360 --> 00:12:10.440
<v Speaker 2>smart parking imagine tiny, cheap ultrasonic sensors with nbiot chips

238
00:12:10.440 --> 00:12:13.480
<v Speaker 2>built right into every single parking spot. They detective of

239
00:12:13.480 --> 00:12:15.960
<v Speaker 2>card is there or not. If the status changes, they

240
00:12:15.960 --> 00:12:18.200
<v Speaker 2>wake up, send that tiny bit of data occupied or

241
00:12:18.279 --> 00:12:22.200
<v Speaker 2>vacant over nbiot to a central server. Drivers could then

242
00:12:22.240 --> 00:12:26.080
<v Speaker 2>get live parking availability maps on their phone or car dashboard,

243
00:12:26.279 --> 00:12:28.000
<v Speaker 2>maybe even reserve a spot ahead of time.

244
00:12:28.039 --> 00:12:30.519
<v Speaker 1>That would save so much time and frustration and fuel too.

245
00:12:30.559 --> 00:12:32.080
<v Speaker 1>Presumably exactly.

246
00:12:32.679 --> 00:12:37.559
<v Speaker 2>These sensors are perfect for NBIOT, small, low power, only

247
00:12:37.600 --> 00:12:41.360
<v Speaker 2>need to send data infrequently. They wake up, report, go

248
00:12:41.399 --> 00:12:44.120
<v Speaker 2>back to deep slip. Multiply that across a whole city.

249
00:12:44.600 --> 00:12:45.440
<v Speaker 2>Massive benefit.

250
00:12:45.600 --> 00:12:47.679
<v Speaker 1>Yeah, you can see how that scales, and it extends

251
00:12:47.720 --> 00:12:50.720
<v Speaker 1>beyond parking right into the broader smart city idea.

252
00:12:50.759 --> 00:12:54.759
<v Speaker 2>Definitely. Nbiot is a key enabler for smart cities. Think

253
00:12:54.759 --> 00:12:58.960
<v Speaker 2>smart electricity grids using sensors to monitor load and improve efficiency,

254
00:12:59.440 --> 00:13:03.360
<v Speaker 2>or environ mental monitoring tracking air quality, water levels and rivers,

255
00:13:03.679 --> 00:13:04.399
<v Speaker 2>noise pollution.

256
00:13:04.960 --> 00:13:06.639
<v Speaker 1>Public transport too, yep.

257
00:13:06.759 --> 00:13:10.159
<v Speaker 2>Tracking buses and trains for real time schedules, maybe even

258
00:13:10.200 --> 00:13:13.320
<v Speaker 2>monitoring the health of railway tracks. And another big one

259
00:13:13.440 --> 00:13:14.879
<v Speaker 2>is smart waste management.

260
00:13:14.919 --> 00:13:16.919
<v Speaker 1>Oh yeah, the bins that tell you when they're full.

261
00:13:17.039 --> 00:13:19.919
<v Speaker 2>Exactly, sensors and garbage containers report how full they are.

262
00:13:20.200 --> 00:13:23.919
<v Speaker 2>The waste clashing company can then optimize routes only visiting

263
00:13:23.960 --> 00:13:27.960
<v Speaker 2>bins that actually need emptying, huge potential savings in fuel,

264
00:13:28.080 --> 00:13:29.240
<v Speaker 2>time and resources.

265
00:13:29.279 --> 00:13:31.480
<v Speaker 1>It really changes how city services could operate. And what

266
00:13:31.559 --> 00:13:33.879
<v Speaker 1>about closer to home, the smart home.

267
00:13:34.080 --> 00:13:37.000
<v Speaker 2>It plays a role there too, though maybe alongside other

268
00:13:37.039 --> 00:13:40.399
<v Speaker 2>technologies like Wi Fi or zigby. But for things that

269
00:13:40.519 --> 00:13:43.399
<v Speaker 2>might be further away or need that long battery life,

270
00:13:43.879 --> 00:13:48.919
<v Speaker 2>think truly connected appliances, refrigerators reporting issues, washing machines that

271
00:13:48.960 --> 00:13:52.720
<v Speaker 2>can be managed remotely, smart lighting systems, security sensors on

272
00:13:52.799 --> 00:13:54.360
<v Speaker 2>doors and windows that last for.

273
00:13:54.440 --> 00:13:58.799
<v Speaker 1>Years, and maybe eventually things get even smarter, like cognitive homes.

274
00:13:58.919 --> 00:14:02.840
<v Speaker 2>That's the vision. Yeah, cognitive NBIOT could allow homes to

275
00:14:02.919 --> 00:14:06.679
<v Speaker 2>learn your preferences, manage energy use automatically, ad just lighting

276
00:14:06.840 --> 00:14:09.960
<v Speaker 2>and temperature based on whose home, all based on data

277
00:14:09.960 --> 00:14:13.600
<v Speaker 2>collected from various sensors over time, saving time, saving cost.

278
00:14:13.919 --> 00:14:17.360
<v Speaker 1>Okay, So for all these devices, parking sensors, trash cans,

279
00:14:17.600 --> 00:14:20.360
<v Speaker 1>maybe my fridge to talk effectively, especially at the application level,

280
00:14:20.399 --> 00:14:22.600
<v Speaker 1>they need a common language rights protocol.

281
00:14:22.279 --> 00:14:25.480
<v Speaker 2>Exactly, and for many of these constrained IoT devices, the

282
00:14:25.559 --> 00:14:28.120
<v Speaker 2>go to protocol at the application layer is message Q

283
00:14:28.240 --> 00:14:31.679
<v Speaker 2>telemetry Transport or MQTT MQTT.

284
00:14:31.840 --> 00:14:33.200
<v Speaker 1>Okay, what makes that so suitable.

285
00:14:33.360 --> 00:14:36.840
<v Speaker 2>It's incredibly lightweight, inefficient, designed from the ground up for

286
00:14:36.879 --> 00:14:41.320
<v Speaker 2>devices with limited bandwidth, low processing power, and maybe unreliable connections.

287
00:14:41.320 --> 00:14:46.480
<v Speaker 2>Basically a perfect fit for NBIOT. Get this. It's fixed header.

288
00:14:46.679 --> 00:14:49.720
<v Speaker 2>The basic overhead for every message is just two bytes.

289
00:14:50.039 --> 00:14:51.159
<v Speaker 2>Tiny two bytes.

290
00:14:51.240 --> 00:14:53.159
<v Speaker 1>Okay, that is efficient. How does it work?

291
00:14:53.360 --> 00:14:56.080
<v Speaker 2>It uses a published subscribe model, which is really elegant

292
00:14:56.080 --> 00:14:59.279
<v Speaker 2>for IoT. Instead of device is constantly asking a server

293
00:14:59.639 --> 00:15:04.399
<v Speaker 2>a new for me. Devices publish messages to specific topics

294
00:15:04.480 --> 00:15:07.200
<v Speaker 2>like our smart meter might publish its reading to a

295
00:15:07.200 --> 00:15:10.679
<v Speaker 2>topic like home energy meter reading. Okay, then any other client,

296
00:15:10.679 --> 00:15:13.440
<v Speaker 2>maybe an app on your phone or the energy company's dashboard,

297
00:15:13.480 --> 00:15:16.039
<v Speaker 2>can subscribe to that topic or maybe a broader topic

298
00:15:16.120 --> 00:15:19.159
<v Speaker 2>like home energy managed tag. To get all energy related messages.

299
00:15:19.559 --> 00:15:23.639
<v Speaker 2>The central MQTT broker handles routing the messages from publishers

300
00:15:23.679 --> 00:15:27.279
<v Speaker 2>to the correct subscribers. It decouples the devices ah, so.

301
00:15:27.240 --> 00:15:28.960
<v Speaker 1>The meter doesn't need to know who's listening. It just

302
00:15:28.960 --> 00:15:31.559
<v Speaker 1>sends its data to the right topic and listeners subscribe

303
00:15:31.559 --> 00:15:32.720
<v Speaker 1>to the topics they care about.

304
00:15:32.840 --> 00:15:37.519
<v Speaker 2>Precisely. It simplifies things massively, especially when you have potentially

305
00:15:37.559 --> 00:15:42.320
<v Speaker 2>thousands or millions of devices. MQTT also offers different quality

306
00:15:42.320 --> 00:15:46.240
<v Speaker 2>of service QoS levels for delivery. QS zero is at

307
00:15:46.279 --> 00:15:49.320
<v Speaker 2>most once fire and forget. QS one is at least

308
00:15:49.320 --> 00:15:53.440
<v Speaker 2>once guarantees delivery, but might result in duplicates. QS two

309
00:15:53.600 --> 00:15:57.600
<v Speaker 2>is exactly once, guarantees delivery exactly one time, but with

310
00:15:57.639 --> 00:15:58.320
<v Speaker 2>more overhead.

311
00:15:58.559 --> 00:16:01.120
<v Speaker 1>So again you can choose the trade off between reliability

312
00:16:01.120 --> 00:16:03.159
<v Speaker 1>and efficiency depending on the data exactly.

313
00:16:03.600 --> 00:16:06.320
<v Speaker 2>And one last really clever feature of MQTT is the

314
00:16:06.360 --> 00:16:09.120
<v Speaker 2>will message. A client when it connects can tell the

315
00:16:09.159 --> 00:16:12.519
<v Speaker 2>broker if I disconnect unexpectedly, like if I lose power

316
00:16:12.600 --> 00:16:15.639
<v Speaker 2>or crash, please publish this specific will message to this

317
00:16:15.679 --> 00:16:16.480
<v Speaker 2>specific topic.

318
00:16:16.679 --> 00:16:18.639
<v Speaker 1>Oh like a last testament kind of.

319
00:16:18.759 --> 00:16:22.000
<v Speaker 2>It's a way to immediately alert other interested systems that

320
00:16:22.000 --> 00:16:24.919
<v Speaker 2>the device has gone offline abruptly. Really useful for critical

321
00:16:25.000 --> 00:16:27.639
<v Speaker 2>monitoring instantly if a center drops off the network.

322
00:16:27.679 --> 00:16:30.720
<v Speaker 1>That is clever. Okay, Wow, that's quite a journey through MBIOT.

323
00:16:31.080 --> 00:16:34.000
<v Speaker 1>We've covered the core ideas, the incredible power saving tricks

324
00:16:34.000 --> 00:16:37.759
<v Speaker 1>like PSM and EDRX, the protocols like RLC and MQTT,

325
00:16:38.080 --> 00:16:39.559
<v Speaker 1>making it efficient and reliable.

326
00:16:39.919 --> 00:16:43.000
<v Speaker 2>Yeah, and how it all comes together in real world applications,

327
00:16:43.240 --> 00:16:45.879
<v Speaker 2>from smart parking to smart homes. It really is a

328
00:16:45.879 --> 00:16:50.519
<v Speaker 2>specialized but incredibly powerful technology. It's the quiet enabler behind

329
00:16:50.639 --> 00:16:53.120
<v Speaker 2>so much of the massive Internet of things scale we're

330
00:16:53.120 --> 00:16:53.879
<v Speaker 2>starting to see.

331
00:16:54.080 --> 00:16:58.759
<v Speaker 1>It operates often completely unnoticed, doesn't it. But from extending

332
00:16:58.799 --> 00:17:02.960
<v Speaker 1>battery life out to a decade to enabling entire smart cities,

333
00:17:03.399 --> 00:17:08.039
<v Speaker 1>NBIOT is genuinely transforming our environment. Hopefully you listening now

334
00:17:08.119 --> 00:17:10.880
<v Speaker 1>have a much deeper feel for how these millions of

335
00:17:10.920 --> 00:17:14.839
<v Speaker 1>tiny connected devices managed to keep working away, making our

336
00:17:14.839 --> 00:17:17.319
<v Speaker 1>world just a little bit smarter, a little more.

337
00:17:17.200 --> 00:17:19.519
<v Speaker 2>Efficient, And maybe a final thought to leave you with.

338
00:17:20.119 --> 00:17:23.480
<v Speaker 2>As NBIOT keeps rolling out globally, connecting more and more

339
00:17:23.519 --> 00:17:26.720
<v Speaker 2>things that can monitor our physical world for years without

340
00:17:26.759 --> 00:17:30.799
<v Speaker 2>needing intervention, what new ethical questions, what new privacy considerations

341
00:17:30.920 --> 00:17:34.119
<v Speaker 2>might arise from having this kind of pervasive, long term,

342
00:17:34.240 --> 00:17:36.799
<v Speaker 2>low power monitoring all around us. It's definitely a vast

343
00:17:36.799 --> 00:17:37.480
<v Speaker 2>new frontier.

344
00:17:38.200 --> 00:17:40.400
<v Speaker 1>That's a really interesting point. Lots to think about there.

345
00:17:40.519 --> 00:17:42.599
<v Speaker 1>The deep dive, as always, has only just begun