Speaker 1: You know, you're probably used to your phone always being connected, right,
Speaker 1: but what about like everything else around you. Imagine your
Speaker 1: smart firmostat at home, or maybe a city traffic light,
Speaker 1: or even say a water meter hidden deep down in
Speaker 1: a basement somewhere. What if all these different devices could
Speaker 1: communicate really efficiently, sending and getting data, all while running
Speaker 1: on just a tiny battery, and not just for months,
Speaker 1: but potentially for a whole decade.
Speaker 2: Yeah. That sounds almost like science fiction, doesn't it. But
Speaker 2: it's actually the reality of a technology we're going to
Speaker 2: dive into today. It's called narrowband Internet of Things, or
Speaker 2: you'll often hear it called NBIOT exactly.
Speaker 1: And we've gathered a pretty comprehensive stack of sources for
Speaker 1: this deep dive, including a really detailed technical book. Our mission, well,
Speaker 1: it's pretty straightforward. We want to pull out the essential insights.
Speaker 1: We want to understand the clever engineering behind NBIOT.
Speaker 2: And discover some of the surprising ways it's already shaping
Speaker 2: our connected future, right.
Speaker 1: And we want to do it with out getting totally
Speaker 1: bogged down and overly complex technical jargon. By the end,
Speaker 1: you should have a really good handle on what makes
Speaker 1: this technology so unique and honestly is so vital.
Speaker 2: Okay, so maybe we should start by tracing the wireless
Speaker 2: journey a bit, because it's been quite an evolution.
Speaker 1: Good idea. Yeah, I mean, back in the nineteen eighties
Speaker 1: we had one G mostly just for voice calls, right
Speaker 1: then two G brought in digital voice, some basic data, and.
Speaker 2: Then three G with things like WCDMA that really kicked
Speaker 2: off mobile broadband. Suddenly we had a richer mix voice
Speaker 2: video data, and by the time.
Speaker 1: For GLTE came along, we were fully in the multimedia era.
Speaker 1: And that's actually where the groundwork for something called machine
Speaker 1: type communication or MTC really start to get laid.
Speaker 2: Yeah, that's a key point. MTC was this shift in
Speaker 2: thinking beyond just people talking to people. It was about
Speaker 2: devices communicating directly with the network or maybe even with
Speaker 2: each other, no humans involved directly, and the Internet of
Speaker 2: Things IoT. That's basically the full realization of what MTC
Speaker 2: was aiming for, a world packed with connected things. And
Speaker 2: these things are usually pretty simple, right, low complexity, needing
Speaker 2: long range communication, super low.
Speaker 1: Power, right, often just sending tiny bits of data that
Speaker 1: aren't super urgent, like you said, a smart meter reporting
Speaker 1: or reading once a day exactly.
Speaker 2: And the scale we're talking about is just massive millions
Speaker 2: of devices post square kilometer potentially.
Speaker 1: Wow. And that's exactly where MBIOT comes in, isn't it.
Speaker 2: Precisely? It's not just another iteration. It was specifically designed
Speaker 2: kind of a script down version of LTE built by
Speaker 2: three GPP just for this purpose to handle the unique,
Speaker 2: sometimes extreme demands of connecting huge numbers of simple devices.
Speaker 1: And when you look at the design goals, you immediately
Speaker 1: see why it's such a big deal for you know,
Speaker 1: making this connected world actually happen.
Speaker 2: Absolutely, the goals were well ambitious, but there what make
Speaker 2: widespread IoT practical. First off, ultra low cost. They were
Speaker 2: aiming for just five dollars US.
Speaker 1: Deeper device five dollars. That's incredible. That really opens things up.
Speaker 2: It does then maybe the most critical part minimal power
Speaker 2: consumption leading to that crazy long battery life. We're talking
Speaker 2: devices designed to sit power in the nanolam range. So
Speaker 2: a single small battery maybe five wat hour capacity could
Speaker 2: potentially last up to ten years.
Speaker 1: Ten years, just imagine installing something and basically forgetting about
Speaker 1: the battery for a decade. That's a game changer totally.
Speaker 2: Another big one was extended coverage. The goal was twenty
Speaker 2: dB beats better reach indoors and outdoors compared to older
Speaker 2: stuff like gprs, so connectivity and really tough spots, basements,
Speaker 2: utility shafts, even underground.
Speaker 1: Okay, that makes sense for things like meters.
Speaker 2: Yeah. And finally, low complexity to keep the hardware cheap
Speaker 2: and low latency, but low in an IoT context. Right, Yeah,
Speaker 2: so ten seconds or last for ninety nine percent of
Speaker 2: devices for data that isn't time critical.
Speaker 1: Got it? So not instant, but fast enough for most
Speaker 1: sensor application exactly.
Speaker 2: And if you zoom out a bit, nbiot actually fits
Speaker 2: perfectly into the bigger five G vision, the IMT twenty
Speaker 2: twenty requirements. That vision includes things like massive connection density
Speaker 2: up to one million devices per square kilometer, and nbiot
Speaker 2: is a key enabler for a lot of those use cases.
Speaker 1: Okay, those are some seriously impressive goals. That ten year
Speaker 1: battery life especially just jumps out from an engineering standpoint.
Speaker 1: What was the like the magic trick? How did they
Speaker 1: actually unlock that kind of longevity? It must involve some
Speaker 1: really clever design.
Speaker 2: Yeah, it wasn't just one thing, def not a single
Speaker 2: magic bullet. It was really a combination of smart choices
Speaker 2: across the different communication layers. You know, how the device
Speaker 2: talks to the network, secures data, sends messages reliably, all that.
Speaker 1: Stuff, right, the whole protocol stack exactly.
Speaker 2: And maybe one of the biggest breakthroughs a real power
Speaker 2: saving superpower something called power saving mode or PSM PSM. Okay,
Speaker 2: This lets a device basically switch off its radio completely
Speaker 2: for really long periods. Yeah, and I mean long, potentially
Speaker 2: up to four hundred thirteen days.
Speaker 1: Wait, four hundred and thirteen days while still being registered.
Speaker 2: Yeah. It stays registered with the network, so the network
Speaker 2: knows it exists, it knows it's sleeping, and it won't
Speaker 2: try to page it or send it anything during that time.
Speaker 2: So think about that smart water meter again. It could
Speaker 2: wake up maybe once a week, send its reading.
Speaker 1: And then just go back into deep hibernation for ages
Speaker 1: without needing to reconnect from scratch every.
Speaker 2: Time, precisely like a data bear hibernating. It saves a
Speaker 2: massive amount of power compared to constantly keeping the radioactive
Speaker 2: or even just lightly sleeping.
Speaker 1: Wow, Okay, that's huge, And I think you mentioned something
Speaker 1: else too, DRX.
Speaker 2: Right, So even when a device isn't in that super
Speaker 2: deep PSM sleep, it still needs to save power. That's
Speaker 2: where discontinuous reception DRX comes in. Even when it's technically awake,
Speaker 2: it's not listening constantly. It only wakes up its receiver
Speaker 2: during very specific, pre agreed tiny windows of time okay.
Speaker 1: Like little listening appointments exactly.
Speaker 2: These are called paging occasions. Within paging frames, it checks
Speaker 2: for messages for a very short burst and if there's nothing,
Speaker 2: boom back to sleep immediately. And then there's extended DRX EDRX,
Speaker 2: which pushes those cycles even further apart, up to about
Speaker 2: one hundred and seventy five minutes nearly three hours between
Speaker 2: these brief liftening moments most three hours.
Speaker 1: So it's like checking your mailbox only at very specific times,
Speaker 1: maybe once every few hours, just to save energy.
Speaker 2: That's a great analogy. It's all about minimizing the time
Speaker 2: the radio components are powered up.
Speaker 1: Makes total sense. Okay, So that covers the power saving.
Speaker 1: What about actually making the data transfer itself efficient and
Speaker 1: reliable because these signals might be weak, right, definitely.
Speaker 2: So another layer, the Packet Data Convergence Protocol PDCP, handle
Speaker 2: some crucial stuff here. The key insight is making every
Speaker 2: single bit count and keeping things secure. PDCP does ciphering
Speaker 2: That strong encryption using keys the network.
Speaker 1: Provides security is obviously important.
Speaker 2: Absolutely, and it also does header compression, specifically something called
Speaker 2: robust header compression or ROWHC. This shrinks down the size
Speaker 2: of the network headers like TCPIP headers before transmission. Less
Speaker 2: data descend means less time transmitting, which saves power and bandwidth.
Speaker 2: Plus it includes integrity protection to make sure messages aren't
Speaker 2: messed with.
Speaker 1: Okay, compressing headers encrypting, that's clever. And what about making
Speaker 1: sure the data actually arrives, especially if the connection isn't
Speaker 1: perfect right?
Speaker 2: That's where the radio link Control ROLC layer comes in.
Speaker 1: Yeah.
Speaker 2: It offers different levels of reliability, kind of like your
Speaker 2: postal service options. There's transparent mode TM super simple, no acknowledgments,
Speaker 2: good for basic control messages.
Speaker 1: Send and hope pretty much.
Speaker 2: Then there's unacknowledged mode UM. This is often used for
Speaker 2: things like multicast traffic, sending the same info to multiple devices,
Speaker 2: no retransmissions if something gets lost.
Speaker 1: Okay, so maybe for less critical one way stuff exactly,
Speaker 1: But then.
Speaker 2: You have acknowledged mode AM. This is the reliable one.
Speaker 2: It uses automatic repeat request ARQ. It waits for acknowledgments,
Speaker 2: handles errors, retransmits lost packets, even breaks up large messages
Speaker 2: and reassembles them. It guarantees delivery.
Speaker 1: Ah okay, So you choose the mode based on how
Speaker 1: important the data is, like registered mail versus a standard letter.
Speaker 2: You got it. Match the delivery method to the message importance.
Speaker 2: Save energy when you can guarantee delivery when you absolutely
Speaker 2: have to.
Speaker 1: And this reliability does it go even deeper down to
Speaker 1: the physical radio level.
Speaker 2: It does down to the medium access control MAC and
Speaker 2: physical PHY layers. There are more tricks. When devices first
Speaker 2: want to talk, they use random access procedures. Often its
Speaker 2: contention based. Devices might kind of shout to get attention
Speaker 2: and the network sorts it out. A bit chaotic can be,
Speaker 2: but it works for these simple devices. Then for dealing
Speaker 2: with errors in noisy conditions, there's hybrid automatic repeat request HARQ.
Speaker 2: This allows for really fast retransmissions right at the physical layer,
Speaker 2: much faster than the RLC layer's ARQ.
Speaker 1: Okay, quick error correction.
Speaker 2: Yeah. But maybe the most remarkable thing for that twenty
Speaker 2: dB coverage game we talked about is subframe repetition. This
Speaker 2: is a phy layer technique. Sending a chunk of data
Speaker 2: a subframe just once, the device can repeat it many
Speaker 2: many times, like sixty four or even one hundred and
Speaker 2: twenty eight times.
Speaker 1: Repeating the same thing over and over.
Speaker 2: Exactly, it dramatically increases the chance that the base station
Speaker 2: receives it correctly, even if the signal is incredibly weak
Speaker 2: or fading. It's like shouting your message repeatedly until you're
Speaker 2: sure it got through. That's key for reaching those difficult locations.
Speaker 1: Wow. Okay, so it really is a whole symphony of
Speaker 1: intelligent design, deep sleep listening, Windows data compression, different reliability levels,
Speaker 1: even just repeating the signal, all to make these tiny
Speaker 1: bits of data get through reliably while barely sipping power.
Speaker 2: That's the essence of it.
Speaker 1: But, like we hinted, all this specialized optimization, right, there
Speaker 1: must be trade offs, right. It raises that big question,
Speaker 1: if it's so good for these things, why don't we
Speaker 1: use NBIOT for you know, our smartphones or laptop.
Speaker 2: That's a critical point. Yeah. The trade off for all
Speaker 2: that efficiency and coverage is performance in other areas, mainly
Speaker 2: speed and latency guarantees NBIOT generally uses what it called
Speaker 2: default bearers, which are non guaranteed bitrate non GBR, meaning
Speaker 2: meaning the network doesn't promise a specific data speed. It'll
Speaker 2: do its best, but during busy time speeds might drop
Speaker 2: or packets could even be dropped if there's heavy congestion.
Speaker 2: There are quality of service identifiers QCI and Priority levels
Speaker 2: ARP to manage traffic, but no hard guarantees.
Speaker 1: Okay, best effort, not guaranteed service. That makes sense. So
Speaker 1: what are the main limitations we should be aware of?
Speaker 2: Well, first and foremost the limited data rate. We're talking
Speaker 2: really narrow bandwidth, just one resource block. Typically, physical data
Speaker 2: rates are only a few hundreds of kilobits per second
Speaker 2: kbps at best.
Speaker 1: Definitely not for watching videos or anything data intensive.
Speaker 2: Absolutely not. It's purely for small data packets. Another thing
Speaker 2: is limited antennas support. These devices are built for simplicity
Speaker 2: and low cost. They usually support only one, maybe two
Speaker 2: antennas just for received diversity. They don't do the fancy
Speaker 2: multi antenna stuff like spatial multiplexing or massive MIMO that
Speaker 2: gives modern LTE and five G their high speeds.
Speaker 1: Simpler hardware lower speeds, got it.
Speaker 2: And maybe the most crucial limitation For many applications, the
Speaker 2: core network does not guarantee packet delay. This means it's
Speaker 2: great for things that can tolerate delays that hourly temperature
Speaker 2: reading the daily meta report, but it's totally unsuitable for
Speaker 2: anything real time, like.
Speaker 1: Live video or maybe urgent safety alerts or remote control
Speaker 1: that needs instant response.
Speaker 2: Exactly, anything where a delay of even a few seconds,
Speaker 2: let alone potentially longer during congestion, would be a problem.
Speaker 2: It's a specialized tool for a specific job, connecting massive
Speaker 2: numbers of low power, delay tolerant devices efficiently.
Speaker 1: Right connecting the right tool to the right job. Okay,
Speaker 1: now that we've unpacked its strengths in these well carefully
Speaker 1: engineered limitations, let's make it more concrete. Let's talk real
Speaker 1: world examples. Fundamentally, nbiot is about connecting sensors measuring things
Speaker 1: like temperature, water levels, parking spot occupancy, and actuators things
Speaker 1: that take action like rolling a street light or closing
Speaker 1: a valve.
Speaker 2: And the impact is already pretty huge and growing. Tack
Speaker 2: smart parking imagine tiny, cheap ultrasonic sensors with nbiot chips
Speaker 2: built right into every single parking spot. They detective of
Speaker 2: card is there or not. If the status changes, they
Speaker 2: wake up, send that tiny bit of data occupied or
Speaker 2: vacant over nbiot to a central server. Drivers could then
Speaker 2: get live parking availability maps on their phone or car dashboard,
Speaker 2: maybe even reserve a spot ahead of time.
Speaker 1: That would save so much time and frustration and fuel too.
Speaker 1: Presumably exactly.
Speaker 2: These sensors are perfect for NBIOT, small, low power, only
Speaker 2: need to send data infrequently. They wake up, report, go
Speaker 2: back to deep slip. Multiply that across a whole city.
Speaker 2: Massive benefit.
Speaker 1: Yeah, you can see how that scales, and it extends
Speaker 1: beyond parking right into the broader smart city idea.
Speaker 2: Definitely. Nbiot is a key enabler for smart cities. Think
Speaker 2: smart electricity grids using sensors to monitor load and improve efficiency,
Speaker 2: or environ mental monitoring tracking air quality, water levels and rivers,
Speaker 2: noise pollution.
Speaker 1: Public transport too, yep.
Speaker 2: Tracking buses and trains for real time schedules, maybe even
Speaker 2: monitoring the health of railway tracks. And another big one
Speaker 2: is smart waste management.
Speaker 1: Oh yeah, the bins that tell you when they're full.
Speaker 2: Exactly, sensors and garbage containers report how full they are.
Speaker 2: The waste clashing company can then optimize routes only visiting
Speaker 2: bins that actually need emptying, huge potential savings in fuel,
Speaker 2: time and resources.
Speaker 1: It really changes how city services could operate. And what
Speaker 1: about closer to home, the smart home.
Speaker 2: It plays a role there too, though maybe alongside other
Speaker 2: technologies like Wi Fi or zigby. But for things that
Speaker 2: might be further away or need that long battery life,
Speaker 2: think truly connected appliances, refrigerators reporting issues, washing machines that
Speaker 2: can be managed remotely, smart lighting systems, security sensors on
Speaker 2: doors and windows that last for.
Speaker 1: Years, and maybe eventually things get even smarter, like cognitive homes.
Speaker 2: That's the vision. Yeah, cognitive NBIOT could allow homes to
Speaker 2: learn your preferences, manage energy use automatically, ad just lighting
Speaker 2: and temperature based on whose home, all based on data
Speaker 2: collected from various sensors over time, saving time, saving cost.
Speaker 1: Okay, So for all these devices, parking sensors, trash cans,
Speaker 1: maybe my fridge to talk effectively, especially at the application level,
Speaker 1: they need a common language rights protocol.
Speaker 2: Exactly, and for many of these constrained IoT devices, the
Speaker 2: go to protocol at the application layer is message Q
Speaker 2: telemetry Transport or MQTT MQTT.
Speaker 1: Okay, what makes that so suitable.
Speaker 2: It's incredibly lightweight, inefficient, designed from the ground up for
Speaker 2: devices with limited bandwidth, low processing power, and maybe unreliable connections.
Speaker 2: Basically a perfect fit for NBIOT. Get this. It's fixed header.
Speaker 2: The basic overhead for every message is just two bytes.
Speaker 2: Tiny two bytes.
Speaker 1: Okay, that is efficient. How does it work?
Speaker 2: It uses a published subscribe model, which is really elegant
Speaker 2: for IoT. Instead of device is constantly asking a server
Speaker 2: a new for me. Devices publish messages to specific topics
Speaker 2: like our smart meter might publish its reading to a
Speaker 2: topic like home energy meter reading. Okay, then any other client,
Speaker 2: maybe an app on your phone or the energy company's dashboard,
Speaker 2: can subscribe to that topic or maybe a broader topic
Speaker 2: like home energy managed tag. To get all energy related messages.
Speaker 2: The central MQTT broker handles routing the messages from publishers
Speaker 2: to the correct subscribers. It decouples the devices ah, so.
Speaker 1: The meter doesn't need to know who's listening. It just
Speaker 1: sends its data to the right topic and listeners subscribe
Speaker 1: to the topics they care about.
Speaker 2: Precisely. It simplifies things massively, especially when you have potentially
Speaker 2: thousands or millions of devices. MQTT also offers different quality
Speaker 2: of service QoS levels for delivery. QS zero is at
Speaker 2: most once fire and forget. QS one is at least
Speaker 2: once guarantees delivery, but might result in duplicates. QS two
Speaker 2: is exactly once, guarantees delivery exactly one time, but with
Speaker 2: more overhead.
Speaker 1: So again you can choose the trade off between reliability
Speaker 1: and efficiency depending on the data exactly.
Speaker 2: And one last really clever feature of MQTT is the
Speaker 2: will message. A client when it connects can tell the
Speaker 2: broker if I disconnect unexpectedly, like if I lose power
Speaker 2: or crash, please publish this specific will message to this
Speaker 2: specific topic.
Speaker 1: Oh like a last testament kind of.
Speaker 2: It's a way to immediately alert other interested systems that
Speaker 2: the device has gone offline abruptly. Really useful for critical
Speaker 2: monitoring instantly if a center drops off the network.
Speaker 1: That is clever. Okay, Wow, that's quite a journey through MBIOT.
Speaker 1: We've covered the core ideas, the incredible power saving tricks
Speaker 1: like PSM and EDRX, the protocols like RLC and MQTT,
Speaker 1: making it efficient and reliable.
Speaker 2: Yeah, and how it all comes together in real world applications,
Speaker 2: from smart parking to smart homes. It really is a
Speaker 2: specialized but incredibly powerful technology. It's the quiet enabler behind
Speaker 2: so much of the massive Internet of things scale we're
Speaker 2: starting to see.
Speaker 1: It operates often completely unnoticed, doesn't it. But from extending
Speaker 1: battery life out to a decade to enabling entire smart cities,
Speaker 1: NBIOT is genuinely transforming our environment. Hopefully you listening now
Speaker 1: have a much deeper feel for how these millions of
Speaker 1: tiny connected devices managed to keep working away, making our
Speaker 1: world just a little bit smarter, a little more.
Speaker 2: Efficient, And maybe a final thought to leave you with.
Speaker 2: As NBIOT keeps rolling out globally, connecting more and more
Speaker 2: things that can monitor our physical world for years without
Speaker 2: needing intervention, what new ethical questions, what new privacy considerations
Speaker 2: might arise from having this kind of pervasive, long term,
Speaker 2: low power monitoring all around us. It's definitely a vast
Speaker 2: new frontier.
Speaker 1: That's a really interesting point. Lots to think about there.
Speaker 1: The deep dive, as always, has only just begun