Smartphones connect nearly everywhere to the
Internet. What if we could use all their towers to connect
our sensors and other gadgets to the Internet? Would LoRaWAN or Sigfox be obsolete? If you are brave, you will follow my journey
and learn a lot about cellular IOT technology and how to survive the minefield it is built
on. Then, you can decide what to do with LoRaWAN. Grüezi YouTubers. Here is the guy with the Swiss accent. With a new episode and fresh ideas around
sensors and microcontroller
s. Remember: If you subscribe, you will always
sit in the first row. Many years ago, we had cheap modules to connect
via 2G networks. They were okay, but unfortunately, these networks
disappeared over time and were replaced by 4 and 5G networks. New modules for these networks were extremely
capable but expensive and power-hungry. Only recently has this changed, and everybody
talks about the new modes like CAT-M1 or NB-IOT. These modes are made for low-power, low-capacity
sensor boards. Exactly w
hat we need, right? Let’s check out. Other than with LoRaWAN or Sigfox, we have
to look at many things to get it running: - The cellular protocols and their low-power
modes - The frequency bands they use
- The available modules and Arduino libraries - The SIM cards and the roaming contracts
- The transmission protocols - The future
Finally, we will be able to compare it with LoRaWAN. Let’s start with the low-level protocols. Here, we have two and a half contenders. Two will be covered, and the h
alf only will
be mentioned at the end. These protocols belong to the 3GPP-standardized
technologies and operate on most 4 and 5G networks. The two modes are CAT-M, also called CAT-M1
or LTE-M, and NB-IOT. To understand the technicalities, let's look
at the spectrum. LTE, like most modern transmission protocols,
uses OFDM with multiple parallel subcarriers and slots. Its basic unit is a physical resource block
(PRB) with a 180kHz bandwidth, containing 12 subcarriers. 25 such PRBs combine to form
a 5MHz LTE signal. But wait, 25x180kHz is only 4.5MHz. Where's the missing 500kHz? It's not missing; it's used to separate channels
and is called the “guard band.” NB-IOT uses one such PRB and CAT-M1 six of
them. So you see the first difference: Bandwidth,
which usually translates into channel capacity. Another difference comes from ingenuity or
greed: Either the MBAs wanted to make money with the “useless” guard band, or clever
engineers offered them this solution. Nevertheless, NB-IOT can eith
er be implemented
in the guard band to generate additional profit or inside the regular band. CAT-M1 always uses valuable “LTE” bandwidth. CAT-M1 offers 1Mbit/s uplink and 1Mbit/s downlink
capacity. Much more than LoRaWAN, even on SF7. But we will see: A lot of it is used for overhead. NB-IOT offers a 66kbit/s uplink and a 26kbit/s
downlink. There is also a lot of overhead here. Still, it is plenty for typical sensors. CAT-M started in the US and NB-IOT in Europe. That's not a coincidence if you
ask me. Everything in the US is a bit bigger than
in Europe. I am already looking forward to the big engines
and the big steaks during my next US stay. Do not complain. I am a poor old man raised in a different
time. Anyway, I digress. As with all communication protocols also made
for battery-operated gear, they have to offer power-saving modes. So, let's look into what happens when you
switch your cellular IOT module on. But before we cover this topic, we have to
examine the frequencies used b
y these modules. Most of the current modules are made for the
global market and, therefore, support all these frequency bands. Let’s consolidate because some are the same:
Still ten bands left. They all are numbered. Unfortunately, they use a cryptic numbering
similar to the imperial system I will never understand. It seems the bands were numbered historically. First came the bands around 2GHz. Then, the sub-GHz bands, also called “digital
dividends,” that became available when UHF TV went cable
. And finally, the higher bands around 2.5GHz. Because IOT protocols are made for long-range
and deep penetration in houses or basements, they typically use the sub-GHz bands like
where I live band B20. This also explains what I said in my last
video about LoRaWAN gateways: You need filters for your gateways if you mount them in the
vicinity of cellular towers. 868 or 915MHz are pretty close to the sub-GHz
cellular frequencies… Now, we can continue with looking at the protocol
and finally, power
saving. When we power up our module, it starts to
consume a lot of energy. First, it boots up and, if you do not restrict
it, starts to scan all bands to find an appropriate signal. Then, it detects and chooses the cell. It connects to the cell covered by your contract
stored on the SIM card, not to the one with the best signal. Next, it updates its tracking area and registers
to the cell. Only now, it can start to deliver its message. You see, as promised, a lot of overhead not
needed by LoRaW
AN. There, most of these parameters are known
in advance. But it has the advantage that at least CAT-M1
supports an “organized” handover between towers for mobile devices as we know from
our Smartphones. NB-IOT does not support cell handover. It sticks with the current cell as long as
it is reachable. Only then, it searches for a new one. So, definitively, CAT-M1 has an advantage
for mobile devices. Now, we have to distinguish between downlink-heavy
and uplink-heavy applications. Let's start wit
h downlink-heavy, even if this
is not the typical case for sensors. It is a bit easier to explain. After registration, if there is nothing to
transmit, the modem goes into paging mode, where it waits for a downlink message. All LTE modems sleep for a very short time
during this cycle. If you want more, you can ask the cell for
eDRX. If granted, the receiver is switched off for
longer periods. The module still consumes milliamperes during
this phase. But from time to time, it can receive a downli
nk
message. Of course, with this delay. The carrier decides on the maximum allowed
eDRX time. It can be up to 44 minutes for CAT-M1 and
up to 3 hours for NB-IOT. However, as we will later see, there are better
possibilities than long eDRX times. This is the first method of saving energy
and, as said, mainly for downlink-heavy connections. The next phase is suspend mode where we more
or less power the LTE module down. This mode is called “PSM,” and its maximum
time is also determined by the carri
er. If we exceed this time, the connection is
lost, and our chip has to re-register to the cell. If we wake up before this time, most of the
overhead is not needed because our modem is still known to the cell. This is the preferred mode for sensors that
do not need a lot of downlink traffic. If your provider allows, you can even request
Release Assistance Indication (RAI) to shorten the receiving phase further. You see, we have many possibilities. Unfortunately, they depend on the network
operat
or and the SIM card you use. Now we know how the low-level protocols work,
and we can go on with the available modules. Most modules on AliExpress are from Simcom. I started with a SIM7080 mounted on an ESP32
S3 board from Lilygo. You get modules from other manufacturers like
Nordic, Quectel, Qualcomm, or Sequans. Lilygo also provides some example code that
uses the TinyGSM library. However, as its name implies, it comes from
the old GSM times, and we have to add code to be fit for the new IOT m
odes. This is why I use Walter, a similar board
with an LTE chip from Sequans. It is made by a small Belgian company and
currently is on crowd supply. They started a new open-source library that
is up to the task, and maybe it will become the new standard for modern protocols. You heard me talking a few times about SIM
cards. For your Smartphone, you get them from your
network provider as part of the contract. This is why I inserted one in my Lilygo board
and tried to connect. It only connected
using CAT-M1. I tried to get information about IOT SIM cards
from all providers in Switzerland. Without success! Fortunately, Walter contained a SIM card from
Soracom in the UK. Because the SIM card also supports roaming
in Switzerland, my sketch worked with it inserted without problems on both protocols. Strange. Later on, I met Harald from Crout, a German
company specializing in such cards. He explained that it is very difficult to
create SIM cards for CAT-M or, even more, NB-IOT because these
protocols are usually
not covered by standard roaming contracts between carriers. So, pay attention to the evaluation of the
SIM card. I searched for a very long time to find a
not existent error in my sketch. In the end, I contacted my Swiss SIM card
provider, and they were astonished that their SIM card supported CAT-M1. They thought it did not support any IOT standard. I leave links to the two SIM card suppliers
that sell working ones. However, check the availability in the countries
you wan
t to use your devices. A trick for the US: It might be easier to
use a foreign SIM card because some carriers will ask you for an FCC certification of your
device before you can connect to their network using US SIM cards. Not so if your device is “roaming”. Before we continue with the transmission protocols,
we want to see how our device works. For that, I used Walter’s “sensor example”. Because, for sensors, we are interested in
power consumption, I powered it with the PPK II power monitor. He
re you see what we learned before: The ESP32
switches on, and the modem connects to the network. As soon as the board is connected, it transmits
a value and goes to deep sleep. The modem transmits the value via CAT-M1 or
NB-IOT and, after paging, goes to sleep, too. After one minute, the ESP32 wakes up and transmits
the next value. To see what happens inside the cellular network
I was lucky that we have an RF lab in Switzerland where they have this base station simulator
from Anritsu. Like that,
we can see how the transmission
works also in the cell tower. After powering up, our device requests for
a registration. You see, a lot of information has to be exchanged
during this process to authenticate your device. You also see that this is a bidirectional
communication, and our device knows if it is connected and data can be transmitted. This explains why it takes so long. Watch also the power consumption during this
phase: It is quite high. After registration, data transfer is fast,
also
because Walter’s library uses an optimized protocol. After the paging phase where the module waits
for downlink traffic, it goes to sleep, too, and the current draw is only microamperes. If we wake up before the maximum PSM time,
our device stays known to the network, and no registration is needed. The power consumption is 30 to 50% less and
probably could be optimized further by using RAI. Keep in mind that these networks increase
the output power and the repetition rate when the quality of th
e connection is low. Here in the basement, the same transmission
takes longer, and if you do not pay attention, it can deplete your battery very fast—a
big difference compared to LoRaWAN. So we know how the communication with the
tower works, and we can continue with the transmission protocols. Modern modem chips support IP and MQTT. Coming from IOT, I prefer MQTT, of course. It worked fine with the SIM7080, even with
the encrypted MQTTS protocol. Unfortunately, this protocol is not optimized
fo
r cellular. That is why the specialists prefer UDP and
COAP to transfer messages. This was the main reason I used the Walter
board for my tests. As said before, I distinguish between sensor
and actuator boards. In reality, I could also distinguish between
battery and mains-powered boards. For mains-powered devices, most of the power
optimizations discussed before are not very important. If connected to mains, you do not need to
sleep and you could use the MQTT protocol. Just keep in mind that th
ese modules have
to dissipate the power, and maybe it is important to save power to avoid overheating in tight
spaces. So, for mains-powered devices or for devices
only used for a short period, the TinyGSM library and such a Lilygo board are perfectly
fine. We have now covered the major aspect of IOT
via cellular networks and are ready to compare it with LoRaWAN to answer the question of
the clickbaity thumbnail. Here are the differences that matter to me:
Moving vs. stationary devices The milli
ons of cell towers neatly distributed
across the globe offer incredibly high coverage. LoRaWAN, even with the Helium network, has
only a fraction of this coverage. So, if you have moving devices, cellular has
a huge advantage. If your devices are deployed in a defined
area, or in an area without 4G coverage, they can be covered by a LoRaWAN gateway at a low
cost, also indoors and in basements where 4G coverage is weak or non-existent. Aloha vs. bidirectional communication
LoRa uses the Aloha pro
tocol without confirmation, so the sender does not know if the message
arrived. This is OK for non-time-critical data, but
you probably would not want to transfer money across such a connection
Throughput LoRa and LoRaWAN are exceptionally slow protocols
hampered by the usage of non-licensed bands with a 1% duty cycle. NB-IOT and, even more, CAT-M1 have much higher
data rates and no duty cycle limitations. So, they are the right choice if you need
higher data rates. Complexity
LoRaWAN is a simpl
e technology compared with cellular. Writing programs is quite easy and straightforward. Deploying gateways allows you to control the
overall infrastructure if you want. Cellular, on the other hand, is complex because
it is a “jack of all trades,” and many companies are involved. In addition, because IOT SIM cards are dirt
cheap, only large contracts are interesting for the providers. If you are small, do not expect too much. So, ask a specialist for help if you deploy
your first project. Price
LoRa modules are still cheaper than cellular modems. However, the price difference gets smaller,
particularly with specialized chips that only support NB-IOT. Deploying a LoRaWAN gateway is a fixed cost,
whereas SIM cards cost an annual fee of a few dollars. Writing and testing code for cellular devices
will be more expensive until the complexity becomes smaller and more know-how is in the
markets. Power consumption
After all my tests, I did not find a big difference in power consumption between
CAT-M1 and NB-IOT. However, both cellular IOT protocols in an
uplink-only scenario consumed considerably more energy than LoRaWAN. Particularly with weak signals. This has to be expected because of the two
way nature of the communication. So, in this area, I expect LoRaWAN to be the
winner for a long time to come. Some fanboys state ten years of battery lifetime
for cellular sensors. If you read the fine prints, they suggest
a once-per-day upload of consolidated sensor values. I assume to preve
nt the big power drain of
the connection process. Future
LoRaWAN has not evolved rapidly over the last few years. Cellular, on the other hand, evolves quickly
and in big steps, so expect changes here. Fortunately, NB-IOT and CAT-M1 are part of
the 5G specifications. But new protocols are coming. Together, they are called 5G RedCap. You see, LoRaWAN will continue to exist, but
cellular will become more important. I hope this video was able to show that both
technologies have advantages and disadv
antages, and so help you make the right decisions. One last thing: In the beginning, I said that
we have 2.5 protocols to choose from. So far, I have only covered NB-IOT and CAT-M1. The third IOT protocol is CAT-1bis. Its throughput is higher, and its range is
smaller; however, because it is covered in the standard roaming contracts, its handling
is easier. Unfortunately , typical IOT modules like the
SIM7080 do not support it. This is why I only counted it half. That was all for today. As alway
s, you find all the relevant links
in the description. I hope this video was useful or at least interesting
for you. If true, please consider supporting the channel
to secure its future existence. Thank you! Bye
Comments