Understanding Cellular IoT: Technical Insights from Industry Leaders

Welcome to Understanding Cellular IoT, Technical Insights from Industry Leaders. My name is Chris Gammell. I’m from Goliath, and I’m here with some of those technical leaders I just mentioned. We’re going to go around the go around the horn and introduce ourselves. Why don’t we start off with Daan? And, Daan, why don’t you tell us about yourself and, where you’re from? Hi. I’m Daan. As you said, I’m the founder of DP Technics, and we build IoT solutions for our clients, but we also build IoT building blocks such as Walter, our, IoT multi radio module, and the Blue Cherry IoT platform. Awesome. Duncan, let’s keep it alphabetical. Duncan next. Sure. Hi. I’m Duncan Fraser. I, I work at Soracom. Soracom are an IoT cellular provider. We specialize in IoT connectivity, cellular based, a little bit of satellite and other options, as our customers need. And we provide global connectivity and integration services so that people can manage their connected devices on an enterprise-level, global scale and ensure they have the right security and routing controls in place to get the right, messages to the right places and cut down any attack vectors for people trying to get in. Awesome. Finally, Imad. Hello, everyone. So I’m Imad Makaiel. I’m product marketing at Sequans Communications. For those who don’t know who is Sequans, Sequans is a fabulous company focused on IoT, Internet of Things, on the cellular part. We are modem vendor. We are we do our own chipsets and our own modules, for 4G and 5G. And maybe you have heard in the, recent news that, Qualcomm have acquired the four g, IP from Sequans, which means it’s good technology. So it will help us focusing on the five g development, but also we can keep as before working with our 4G, IP, for commercial usage. Awesome. Well, I’m really excited to be here with all of you. I think, I’m gonna be kinda chucking some questions your way, and we’re gonna pick out who the best person is to talk about this sort of stuff. But why don’t we start with one that’s good for everyone? What are, what are some of the things that you you see in that space, and and what are some of the use cases you see on a daily So, let me take that one. So, LPWAN is, stands for low power wide area network, and it’s a technology which is vital to the IoT, because it’s all about being able to deploy things wherever you want. So that’s the long range part, not only line-of-sight connections, but also in basements, on the sea, in nature. And, of course, when you deploy things, in these places, you also don’t visit them as often. So, therefore, we need the low power part. So, these technologies, and there are a myriad of them, they all focus or the biggest use case that I see are, sensors and remote sensing applications. Maybe I can add to this, that we need to keep in mind that the engine of things or the IoT is the natural evolution of what once used to be called m to m or machine to machine. And the machine to machine, what started in the nineteen nineties, when we, started connecting local machines to each others to make them communicate, and that by that time, it used to use some local area network. And by the evolution of time and technology, the, those connected machines had to be further away. This is why we needed to have some, some, distant connectivity based on on, RF. And, not everywhere there was some connectivity, meaning the device had to work on a battery powered. So this is why we saw a development of several low power area networks, where they were targeting to have the connectivity at low power, the most low power possible because the device was working on a small battery, not always rechargeable, and not always replaceable. Great. So we’re kind of all floating around the fact that we’re all involved with cellular stuff here, but there are some other technologies, things like Sigfox, LoRa, Wi Fi halo, those kind of things. So, how does that stuff fit in now? So that’s also low power. That’s also often wide area networks, sometimes local area networks, but, I guess in the latter case, that’s that’s usually a more wide wide area network. Where does it start to differentiate from cellular? So, you know, in terms of power profile and, data connectivity and and and things like that? Mhmm. So the biggest difference between cellular devices, so LTE-M and NB IoT, and other technologies such as Sigfox and LoRaWAN are the most well known ones, but there are actually a lot of, technologies there, newer and older ones. Mioty is one that is coming up. Wi Fi halo is a technology that you could, see as an LPWAN, but it’s in between local wireless thing and LPWAN. But the big biggest difference is actually, the the bands that they use. You have unlicensed spectrum and licensed spectrum. So Sigfox, LoRaWAN, they are all in free to use unlicensed spectrum bands, while the cellular technologies are in licensed spectrum. So there’s a lot more regulation there. I would add to that that, I mean, when we are comparing these licensed band to unlicensed band, the one typical example is, is the interference. And and, I mean, what can happen is someone can deploy over an unlicensed band since it is unlicensed, meaning anyone can use it at any time. So you can deploy your network. Things start working. Everything is fine. And all of a sudden, it stops working. And by looking closer to the to the to the signals, you will discover that another device or another technology of someone is transmitting at the same, using the same frequency, meaning it will it will, interfere with your, own devices. And on top of that, I mean, the fact that the the the, license, license spectrum is submitted to standardization, meaning there is 3GPP, which is Third Generation Partnership Project, partnership project, which is, handling all this under standardization. So everything is really is following a rule, specific rule, meaning so everything’s standardized, even for these small things. And, also, we need to take into consideration the deployment management, meaning in in in the and the license bands, there is an MNO or there’s someone who’s managing the deployment, the infrastructure, all that in in in a place where the unlicensed band, when we need to have access to the technology, the device or maker has to make his own deployment, which is a burden, a a a lot of I mean, in in indeed, it is an additional economic burden to him. And one last point is let’s not forget about pairing. When we are using the cellular technology, we all know the SIM card where we put the SIM and it’s seamless. It works straightforwardly in a highly secure manner, while all the other technologies can require some complicated pairing using involving manual, information. Plus, I mean, the security is not always at the standard expected standard. Got it. Yeah. I always talk about, being a good RF neighbor and, sounds like basically, you don’t have a choice when you’re in the license spectrum. Otherwise, you get booed. In the cellular space, where is kind of the adoption of a lot of these different technologies in the LPWAN space? Because it is segmented as well between kind of traditional telephony and high speed data and also the kind of the more IoT focused LPWAN style stuff. Right? Yes. Indeed. That’s right. And so in the cellular world, LPWAN tends to, be either NB IoT or Cat-M1, and different providers in different countries or even the same country are deploying, different network support on their towers, and through their their routing, networks. And we see we see both growing very well. We look at our database. We have a a list of countries that we we we support people through forty plus of each. Sometimes they’re overlapping. Sometimes, they’re they’re one or the other. But, there there’s there’s good coverage certainly across the majority of the the the parts of the world that are doing a lot of our IoT work. What’s nice is, developers looking to start up with either NB-IoT or help or or Cat-M1. They have multiband options or multi, multi, standard options. So, actually, Daan’s Walter board, which uses, Imad’s module is dual. So it has both NB-IoT and Cat-M1. And, of course, you complete the circle with with putting a Soracom SIM in it, and you’re gonna be able to connect in any one of those countries on on on the list, one way or the other. So let’s zoom in a little bit onto the technology itself. So NB-IoT, is a little different than how, you know, CAT one, CAT four, on up to the the higher CAT levels. There are some some technical differences there. But what are some of the things in terms of, utilization of different IP standards and, how you’re talking back to server sense? So say I have a device say I have the the DP technics device, and it has a Sequans modem and a Soracom card on it, and I’m utilizing NB-IoT carrier that’s nearby and and going to the tower. What what do I need to consider in terms of how I’m talking back to the Internet then? Mhmm. Well, first thing that that comes to mind to many of the application engineers in IoT are the application level protocols. I’m thinking everybody is speaking MQTT, HTTP, other protocols. But, when we are doing cellular, it’s good to, go one level below that. And then we are actually seeing the two protocols that drive the mother Internet, so to speak, and that’s TCP and UDP. And they are both running on IP packets, which are routed all over the Internet. Also, NB-IoT and LTE-M are routing IP packets, through the MNO over servers and so on up to the final, destination where they need to be. So the two differences between TCP and UDP are are the reliability that’s built in in that layer. When you have, TCP, it’s a protocol that is built to get data to a location in a reliable way. That means, when I have a device and I want to transmit a TCP packet, it first sets up a connection by sending a connection initiation packet. The server sees the packet, accepts the connection, and then, the device, again, acknowledges that the connection has been established. And then when transmitting data, you have this continuous ping pong of packages. I send something. The server acknowledges that it has received, so you are one hundred percent sure that it arrives. And there are a lot of mechanisms in TCP, such as retransmissions when a package would have been lost because of bad radio situation or something like that. The server or the the receiver will, notice that there’s something out of order or a missing package, and it will request a retransmission, and the TCP stack of the sender will automatically retransmit. So there’s a lot of of control communication. With UDP, the focus is more on getting data somewhere as fast as possible, but the reliability is not so important. You make a packet, you transmit it, and if you’re lucky, it arrives. If you’re, if if you’re unlucky, then it doesn’t arrive. And these are two things that you need to be very well aware of when doing cellular. And many of the application level protocols that we know today like MQTT and HTTP are using TCP instead of use UDP because of the reliability. But in cellular, that’s maybe not the best case, to do. How do we stack on top of this maybe less expensive protocol or less expensive transport rather, with protocols on top of it? Yeah. When looking at at, many larger, platforms, you would tend to think that HTTP and MQTT are the only application level protocols there, but there’s a a lot more out there to discover. And, CoAP or Constrained application protocol is actually, built on top of UDP and not on, TCP, but still giving you the kind of reliability that you need in your, IoT device. You know, TCP was was designed when wireless connectivity was only at the beginning, and, it’s actually designed with Ethernet in mind where, especially with fast Ethernet and gigabit Ethernet, retransmissions are almost free. But with n b NB IoT, that’s no longer the case. So you really need the application to be well aware of retransmissions, and that’s what the CoAP and DTLS protocol, give you. The CoAP protocol, actually has or or takes care of the reliability, but on a much smarter way than TCP does. So while it might be a little bit more daunting than MQTT to set up, CoAP is actually, the route you want to take when designing, a cellular IoT device with LPWAN technology, especially if you’re going to use narrowband IoT and still get the reliability that you are used to, that you have with TCP. Yeah. You mentioned it’s daunting. I mean, what in terms of the kind of the other side of the the equation, how do you how is it daunting, I guess? How is it how is it you you have to implement them? Well, the thing is that with, with TCP, you have something between a client and a server that is called, a connection. So everything in between that link is well aware of that connection and allows packets to to cross the wire, freely. With UDP, you don’t get anything, like, as a connection. So, what is more daunting is that you, as an application and a server provider, you need to take into account that, the disconnection is not not there. So you need to know that you only have a limited time to process responses. Also, the protocol itself is not giving you the publish subscribe thing that you get with MQTT. So there’s a little bit more work to do in the application, and that’s what making the the entry point or the getting started point with CoAP, a bit more difficult than MQTT, but it’s definitely doable. Yes. Great. What about actually when you’re then routing packets to, you know, to some of the hyperscalers that don’t so, like, Amazon had a beta CoAP, interface, but they actually discontinued it. I think Azure tried it, but very quickly or maybe didn’t even didn’t even take off. So then if you’re trying to directly route stuff, so you’re writing your own application level stuff in CoAP, you’re trying to talk to these large back ends. What do what do you do then? Well, there are some some interesting solutions, and we have one at Soracom. So, when you consider the path that your messages are taking from, a device through the cellular network and then across the Internet to, whichever your hosting provider is, if you look inside the the the cellular portion, there’s a bunch of compute options that you can do you can make use of there. And so, Soracom offers a few different services, funnel and funk Soracom funnel, Soracom funk are the ones that spring to mind. They can repackage the the raw message that’s come from the device. So you can make use of your UDP, excellent fit for the the device, the device’s power constraints, the network type you’ve got. But once the messages reach the the safety, if you like, of the the core network, we can then process that. We can, re recode it, maybe move it to an MQTT, MQTTS type message. We can even add your platform credentials so that by the time it’s reached something like AWS IoT or Azure’s IoT platform, it it looks the platform like the message originated this format from the device, but you’ve taken advantage of a bunch of efficiencies along the way to, optimize what’s going down the device, make use of the platform in the middle, and make sure that you’ve got the the most appropriate message format when it that arrives when you you’ll call your application. Mhmm. We actually do, something similar in, Blue Cherry, which is good because it shows the need for it. Doing TCP over narrowband IoT is going to give you errors. We have, plenty of customers who did the cellular design, and they were using MQTT because that’s what they know. That’s what their back end, talks. But in poor RF conditions, they saw devices disconnecting, without any any reason, dropping connections, and so on. So what we did in the BlueCherry IoT platform and in the libraries of Walter, which is our multi radio, module, is we have some libraries that allowed you as an application developer to just to publish subscribe as if you do an MQTT. It dynamically translates this to, CoAP plus DTLS, then it sends this over to the Blue Cherry servers, and there it’s translated back into MQTT so that it’s actually completely transparent to the back end. And, this has helped various customers already where they had an application with cellular. They had a back end with MQTT, but seeing connections drop out. And just by replacing the communication part with our CoAP translator, things got much, much better. And it was as if changing the application layer improved, the radio performance of their device, but it was actually not the radio that was performing badly. It was the application that was not well suited for, this use case. Well, Daan, you and your teammate also just ported the Goliath SDK for the Walter board as well. We’re really excited about that. And, the Goliath SDK actually is CoAP native, talking to CoAP back end. So that’s another thing you could do is if you wanted to find there are some limited CoAP back ends as well, and Goliath operates one of them. And so you could talk directly and then take advantage of all the services that are out there. So I think we’ll talk about that a little bit more later. But this is great. And I think, you know, all these cases, you start to see a lot of benefits. You know? So we’ve talked about kind of the expensive nature of, TCP versus UDP. One of the things that I think about is the battery level. But if we kinda zoom back out kind of to the to the cellular level now and all the features that are part of, LPWAN networks in in a cellular context, all the capabilities that are in there, you know, my brain is still stuck in the early two thousands days of, like, GSM and, like like, I wanna put, like, the largest capacitors on every board that I designed because I’m like, well, this thing’s gonna slug like three three amps at a time. But we’re actually not seeing that, and we start to see some other benefits in terms of some of the power modes that are out there. So maybe we could shift over to power modes and and think about or talk about rather some of the benefits of, the power modes at the tower and on the and on the the device side that actually allow you to take advantage of of lower power communication, outside of the protocol and transport layers. Sure. Well, first, let’s it’s a good good good thing to look back. If we look at the, two g and three g modems back in time, they used to be the same modems which were used to set up call a phone call, and that same modem was used, to for for for data transmission in the case of machine to machine or M2M. And there was no differentiation between, what the application is doing and so the the modem was there and was, let’s say, full throttle using all the power available for for it for for the application no matter how is the usage of the application. Now if we look at those modern protocols like LTE-M and NB-IoT, they are completely part of 4G, which is somehow a recent protocol. And when four g was conceived, by definition, they it it was they decided to have different categories, meaning we will have different modems, and each modem would be addressing some different application. So when the the LTE-M and NB-IoT have been conceived or part of the four g, the idea was that there are some applications that will need this low power, and this is why they included what we call the PSM or power safe mode and eDRX or Extended Discontinuous Reception. And those are two different protocols. I can develop more why we have this and that, but both of them are important for very low power. And the budget for for for for this, PSM and eDRX, the power budget is quantified in microamps, meaning we target really devices working on batteries. That’s great. Yeah. And so the the these modes are both tower side and device side, but it how much so I guess a device designer myself, how much then do I have to actually, like, micromanage? And is it like a setup or is it more like wake up now, set a timer, do this sort of thing? Like, where where does where does that kind of, management layer live in the the in the modem and in just the application side as well? Sure. Actually, why do we have two two different things? First of all, because all the applications are not the same. Actually, I mean, some applications, they are there. They wake up, do some activities, send data, go back to sleep, and they don’t want to be bothered. Some other applications, they wake up, send data, then go back to sleep. But while they are sleeping, they expect to have some data from coming from the network from time to time during their, let’s say, kind of sleep way. Typical example, if we look at a gas meter, in in hazardous area, a gas meter if there is an earthquake, the utility would like to shut off the gas meter despite it has nothing to say, nothing to transmit, but it has to be aware that that a message is coming from the network to wake him up and say, shut down. Stop the the gas now because there’s something something dangerous. So this is where PSM and eDRX are really different. So the PSM is, by the by design, is made for the application. You just configure it that after I transmit, I go back to sleep, and it looks like I left the network despite the device did not leave the network. It’s still on the network, but it’s using very minimum amount of of power, let’s say, just to to help it come back to the network whenever it will wake up. Next time, it will it will wake up. While the eDRX is going to to sleep and then configurable indeed. I mean, you can configure the the waking up time. It will wake up, listen to the network. Is there any message for me? Yes or no? If there’s no message, I’ll go back to sleep. And and this is how how it goes. So so this is the difference between PSM and eDRX, and this is why we have both because they are complementary. Yes. Yeah. I think it’s like, I always think about, like, eDRX is like telling a tower, like, hey. I’m gonna go check my mailbox in, like, eighty two seconds or whatever the standard there’s like standard Windows too. Right? And just expect me around then. You’ll see me. Yeah. I’ll be back then versus like PSM is more like I’m a modem. That’s actually just modem side. Right? So you actually have to do handshake and things like that as well. Yeah. So Yeah. It’s pretty interesting stuff. Well, let’s shift a little bit to, things that have given me headaches in the past, as, at working at MVNO in the past. APNs. Mostly, users setting it poorly. That would be the thing that gave me headaches, but also, what what is an APN? I mean, actually, that that might be helpful to talk about. Sure. Sure. I can talk about that. So, I talked earlier on about the the kind of the architecture between a device and the Internet server that that is trying to send messages through. So the the device is gonna connect to a tower, and the messages will pass to the tower and on through a series of connections to get to wherever the destination is. And we’re all familiar with using APNs or maybe familiar with using APNs in phones, but also say the devices. The APN is the access, protocol name, access point name, which tells the tower and the cellular network which provider actually to route its data through. So we’re familiar with roaming, multiple carriers, multiple SIMs can work on the same tower. But between the tower and the Internet egress point and the host, you have the core network for the cellular provider that you’re working with. So the APN is the element that the the the piece of information that the device uses to set up the connection to the tower and say, and send all my messages over here, please. Setting up an APN, if you’ve got a unique APN for every device or every, should we say customer, not device, every every customer environment with different APNs, that can be a headache and that can be, something to to cause you struggles when you’re you’re managing it. But with something we’ve simplified with Soracom, we have we we use a single APN, and we do our routing control very securely at a later on point in the in the, in the core network. That very much simplifies things. So everybody that uses Soracom uses a single, a single APN and a single username password. I say everybody. I’m sure there there are some exceptions, but by and large, and so that’s that’s the role of an APN. Now the APN is the is the the the configuration that tells the the tower, the the the network, where to send, the messages in order to pass through the chosen, cellular provider’s network and then reach the Internet. Got it. Got it. And so what about the private side though? So the private APN versus, not? I mean Well, yeah. Private APN, in a traditional world, a private APN is, if you like, a a personal access point into that core network. Access point into that core network. It’s useful for, isolating people’s, customer use of that network’s data to make sure that it can’t be touched or has no overlap with anybody else’s data. So we choose to implement a slightly different, solution. So everybody uses the same APN and then we route just after the APN. That Got it. That represents a significant saving in the management they need to do to set those those pieces up. Got it. Multi tenancy and private kind of segmentation at the at the software level versus at the APN level as well. Yeah. Absolutely. Yeah. Yeah. That’s and that’s super useful too. I mean, like, it’s a very ridiculous, premise of the idea of, like, me sending, you know, data to Daan’s devices — that’s not going to happen, not a not a possibility, that sort of thing. It is something that we, you know, we are interested in data flowing in both directions as well. So in terms of, two way communication, you know, we’re often talking about sensors talking up to the cloud, sending stuff back to a, you know, hyperscaler or maybe just a charting program, things like that. What about then control down to the device? I mean, this is something that the Walter board is is good at. Right, Daan? So, you know, both data up, data down, that sort of thing? Yeah. Exactly. So, two way communication, as said before, is one of the perks that you get with cellular communication. But there are actually, it’s important to know there are two methodologies that you can use when doing two way communication. I like to call them the solicited two way communication and the unsolicited. And with solicited, I mean that you have a device. It talks to the cloud, and then the cloud can send an answer back. So it’s device initiated. The sensor example is perfect. You have a sensor. It uploads some data, and then it stays awake for a a small period of time to be able to receive an answer or a command, for example, to have an over the air update, to reconfigure itself with other calibration data or so on and so on. But you can imagine various other use cases. For example, if you would would take, Walter and put it in a street lighting system, for example, or or a pump control, then, actually, it’s not, the device that’s going to initiate communication, but it’s a a controlling system, a human controller, or some some cloud business logic that wants to control that device, put on the street lighting, close, some locks, switch on the pump. And then, if you are using solicited communication, you would need to have a device that sends out a request, do you have any command for me every second? And that would take up a lot of power, a lot of bandwidth, and you would still have a sluggish or nonresponsive system in the end. With unsolicited communication, you need to have the device continuously listening for commands so it will consume bit more power. But if you are only listening, it doesn’t consume any bandwidth. And that’s also possible, with with cellular. But it needs a bit of more configuration on the MVNO or, APN side. So like I mentioned, I mostly am looking for an IP address as a designer, but I have actually dreamed even bigger, even wider, even further. And some of the some of the stuff that has been announced lately is some of the NTN or non terrestrial network stuff. So where have you guys seen this kind of in the space? I mean, it is similar hardware, similar infrastructure type of stuff, but ultimately, again, as a hardware designer, I’m mostly just like, I just want a connection and I’d love for this thing to work in Sub Saharan Africa as much as, you know, up the street from my NBIO T tower. So where does the NTN stuff start to fit in here? Good question. Well, actually, NTN stands for non terrestrial network, which involve they include actually the the, let’s say satellites, which is a I mean, they didn’t wait for cellular to connect devices to to the ground, but also it has UAVs and it can include UAVs and it can include, some drones. So, indeed, we have more and more players coming into into into, into the game. So and we would like to separate, let’s say, the terminal from the, satellite part or the the, the transmitter part. And this is where we need to have some some some, let’s say, standardization, and this is where three g p p could come in place. And this is why we have the 3GPP Release 17, which which started to, I mean, which included some standardization in the NB-IoT, for for the for the NTN, but also on 5G NR for the NTN. So, indeed, I mean, it’s just not just a matter of, technical part because on the 3GPP side, has converged how to to do the technical side, but, also, we need to have the entire ecosystem moving forward in order to have, the all the players who’s selling what, etcetera, etcetera, in order to have your device connected in the desert as you have as you are dreaming. Yeah. Great. Great. And we and and so this is a traditional well, this is kind of like more broad based hardware, towers, m and o’s, all of the capabilities, all the things that Imad kind of laid out, all these players working together. What are kind of the comparative aspects as of today? Like, so if if I wanted similar capabilities to work in Sub Saharan Africa or on a boat or similar, what what do I what do I do? Yeah. So there are, various use cases for non terrestrial communication, but the thing is that they are typically really niche use cases. Some for science, for example, we once did an application with a proprietary protocol called Astrocast where we connected, a a a weather station on a vessel which which was sailing near Greenland, for example. And there you have other solutions, like, Swarm that’s now taken over by, SpaceX. And and really interesting to see what they are going to do with their, low orbit, satellites. But you have systems like Argos, which is, exclusive to to science. But that is, exactly what we see. The scientific use cases are big, but the commercial use cases are still, lacking or, maybe there are just not so much commercial use cases. I I hear, some customers talking, oh, we could track containers on on the oceans. But then again, if you have a container vessel, when you have a container inside the vessel or two or three containers, in the stack, you won’t have any NTN connection available. Metal boxes are not good for, for RF signals. Is that what you’re saying, Daan? Exactly. Just physics — RF signals. Alright. Well, we have covered a lot of topics here. We’ve talked about, different carrier technologies. We’ve talked about NTN and, you know, kind of future technologies coming down the lines and the practical implementations of UDP versus TCP and all that stuff. We’re gonna actually cut over to a demo right now, and all of you have an opportunity to build up your questions. You can put them down in the chat. We’ll definitely, we’ll get to those in the q and a section that’s coming up right after the demo. But wanted to say thank you to Dan, Duncan, Imad. This has been a great conversation, and it just kinda shows your industry and, even though it is it does sometimes feel like a very small industry, it it touches so many aspects of our lives and I’m really excited to see all the new things that are happening here. So thank you. Thank you for this today. Cheers, Chris. Thanks. You too, Chris. You too. Thank you. Alright. We’ll see you all after the demo in the q and a. Me and Chris have been preparing, a demo together with Walter and the Goliath IoT platform where Walter is sending, temperature and humidity readings to the Goliath platform, over LTE M. So we have here, your regular temperature and humidity sensor, and this is the Walter module. On Walter, you have the ESP thirty two s three, with sixteen megabytes of flash and two meg two megabyte PSRAM. And here we have the Sequans Monarch 2 cellular chipset. On the chipset, we have both LTE M and narrowband IOT, and we also have a GNSS receiver. That’s why you can see two micro FL connectors here, one for the LTE connection and one for the GNSS signal. To power Walter or to program it, you can use the USB C connector or you can power through, the header pins on the bottom. Also on the bottom is a nano SIM card slot, in which here the Soracom SIM card is connected. So let’s switch over to Chris, who is going to guide you through the Goliath platform. Great. Yeah. That hardware is really, really great, Daan. Okay. So let’s talk a little bit about, this is the view of Goliath. And, this is kind of the view of the actual the device that, Daan has in front of him. This is individual device view. So Daan will walk through that in a second. I just wanted to go across kinda the tabs on the top here because each of these kinda represents a feature. One thing we could see is kind of this is, this is the usage and the status of this device, and so it is connected. Credentialing, we actually do have certificates, and we have, PSK ID and PSK, which is pre shared key. That’s basically like username password, and that’s what Daan used here because that’s usually the fastest way to get the device online. Firmware, Goliath has over the air updates, and we manage all that stuff in a tab over here on the left, but this one is running one point two point five. LightDB State is a two- sided database that you could set up to do an ad hoc digital twin as well. And so in the past, I’ve done things like, you know, send a request to update a counter, and then on the device, the device is actually controlling that counter. And then you’ll see that live update. But you you have a kind of a requested new version of the count of the counter value and then the actual counter itself. LightDB stream, Daan’s gonna be talking about this data here, but this is some of our time series data. Logs are default with, in the Goliath SDK, especially on Zephyr. We have, we have a compressed version of the logs coming through here. So this is CBOR, and CBOR-serialized logs that are coming through. And this is tied directly into the Zephyr back end. And so, basically, all of the logs that you see on your UART, you will also see show up on cloud. In terms of settings, you see, this is actually a fleet wide, a blueprint wide, which is kinda like a hardware, version wide or an individual device. And so this one’s running every ten seconds here. And then finally, a remote procedure call, this is actually, capability to go and, send custom triggers for custom functions that you’ve written written on your device. So say Daan wrote a new function for just taking a single GNSS reading on the Walter board. And then we did an OTA to have that function pushed out to the devices. Then we could go and call it from the remote procedure call, and you can even add stuff in, like, perhaps you wanna add, parameters, like how many, you know, don’t send me a reading until you see ten satellites or something like that. It’s really all up to you. And so all of this is the Goliath platform and Dan’s gonna show us a little bit more about this, live with with the hardware that he has in front of him. Yeah. So, you can see here, Walter is, streaming temperature and humidity data. So if I if I warm up the sensor, we should see the temperature rising. And this data is also, encrypted or it’s encoded, so to speak, in CBOR. So it’s really compact, and it’s using the CoAP protocol to transmit it to, the Goliath platform, which means that now we’re connected over LTE M, but we could switch over to narrowband IoT and don’t change anything to the code because we are using these optimized protocols. So as you see here, I just held my finger onto the sensor, and we saw the temperature, going up. So there you have it. It’s a really small example of a weather station, which is, IoT connected with cellular, and it’s only a module and four wires on a breadboard. That’s great. Yeah. So I think we’re gonna take some questions now in the q and a. So hopefully, people have been asking questions in the chat. If not, now is your opportunity. And, Daan, great demo. You and your team have done a really awesome job getting getting this thing talking to the cloud and, excited to see what you do next. Thank you. Same same to the Goliath team who built a fantastic platform with the right technology for cellular, which is extremely important. Welcome back, guys. Great demo again, Daan. Alright. So we have a little time left here. Questions have been asked in the Q&A area, in the chat. So as people are if you’re still sticking around and, see some something else you’d like to ask about, please do put that in there. We’ll we’ll start going through these. I think let’s go reverse order. So the first one from Prabhat was, how do you see the integration of IoT cellular technology with satellite using the 3GPP NTN? Do you see compliance with the spec as important, and is there a strong market demand for it? Yeah. So, I can take, that one. I don’t think there’s already a strong market demand. It’s probably you know, it’s the it’s the real beginning of NTN networks. There are some technology demos at the moment, but it’s still really specific where there’s one provider doing, a proof of concept with a certain cellular chipset. So the release seventeen is standardized and ratified, but we are now waiting until it is implemented. And as I said before, it’s also, are we looking here for a solution to a problem, or are we still looking for problems for release seventeen to actually solve? Only future is going to to, to tell. And we’ve got, an interesting tech preview status, if you like, with Soracom. So we work with our partner Skylo. We’ve, we’ve integrated so that, the the the Skylo, connectivity is is managed through the the same as our, platform as our cellular technology or certainly the routing of data. So some of the, the funnel funk, some of the other services that we have for, translating or recoding the messages that are coming for an NB-IoT NTN connection through to something, far richer to go up to the hosted compute. We’re we’re very we see great fits for those those complimentary services, working together. Satellite is so limited, unless it gets very expensive then, saving every bit and byte, it becomes a great value. That’s a good lead in the next question. Bruce asked about the bandwidth and being very low. Generally satellite is I mean like yeah it’s expensive and slow to talk all the way to space. So do you guys have, like, relative numbers? Do you know that sort of thing? And and do you think, do you think it’s gonna increase in the future to to something more like CATM? Mhmm. Well, the the developments are mainly focusing on narrowband IoT. And the reason for that is, of course, when you’re talking to space, distances are big, a lot bigger than when you’re a few kilometers away from a tower. And thus, the signals are weaker, and you need to have good sensitivity on your receiver to be able to decode them. And that’s where NB-IoT is is strong. And that’s also why at this time, we need to be really small bandwidth, low messages. So you won’t be streaming audio and video anytime soon over LPWAN, to satellite. But, of course, as technology advances, receiver technology gets more sensitive, speeds will increase in the future. But we’re not there yet. Yeah. I think a lot of people look at like the Starlinks of the world and say oh well I’m gonna have high speed video. It’s like these are not, these are not Starlink devices. But I think that’s We’re talking like devices with a single antenna, so no beamforming, no antenna arrays. That would be just too expensive for the IoT use case. That’s right. Yeah. Alright. One more question in chat here. What is what is the impact of five g gonna have in IoT? Let’s maybe take that at a high level, but, do you and then asking about bandwidth, in IoT as well in five g. So are we gonna see you know, we’re already into the five g era, but, like, are we seeing increases? Or I guess just to add my own editorial as well, like, you know, are we see are we going to see increases specifically for IoT devices? Well, maybe I can take this one. The way to look at this question and to picture what we call five g and, not five g in a sense where if I look at, the, let’s say, the proper technology point of view, CATM and NB IoT, which started from the four g era but are part of the release fifteen of 3GPP and went over and over, are definitely part of the five g. I mean, as as a five g concept. Of course, they do not use the five g new radio waveform to to to exchange with the with with the network. However, they are considered as part of the five g. And we need to keep also into in to take into consideration that this technology is used in some, smart meters where we expect the life cycle to be about ten to fifteen years, so we are not going to change this technology tomorrow. So this is one part of the equation. Now let’s go back to the five g, what people call five g. Actually, there was the buzz at the beginning when the five g NR or new radio was introduced, was definitely targeting the very high end, which is targeting several gigabit per second. Of course, this is not IoT. This is for very high speed, equipments like telephones or or videos or things like that. And, indeed, it was very, very expensive. So after that, there was a need in the market that we started hearing about five g red cap or reduced capability, which is targeting lower throughput but with indeed, lower cost. And the following generation, which is about Release 18, which is the e red cap or enhanced reduced capability, which is targeting what I would call today similar to CAT one or CAT one base existing in the market. So all in all, what I’m trying to say here is all depends where we put the bar about IoT or Internet of Things. Today, most of the time, we’re thinking about the LPWA, which is get them in the IoT. As of now, there is no, let’s say, convergence or we don’t see at 3GPP level any crossing between what’s happening with the, 5G NR and the existing Cat-M1/NB-IoT. Maybe it will change and release nineteen, twenty. I don’t know. I mean, it’s it’s in the future. Of course, one day, we will have a next generation. Nevertheless, I would go as down as possible to the e-RedCap, or the 5G NR e-RedCap, which is definitely a transition or transformation of existing devices from cat one base to five g n r. Now about the volume of connected devices, indeed, I mean, it’s not the technology which is driving this. It’s more the need that the people are counting more and more on connected devices because it’s easing our life. We saw this during the pandemic or other other aspect of our life where connected devices are really helping us a lot in many other and this is why we are connecting the out those devices and and increasing the IoT space. I think one thing we can agree on is 3GPP really needs to hire someone to name things better. Those names are really very confusing. And you know just know that like like Imad said you know they’re gonna talk about next generation. Someone’s gonna tack an NG onto something at some point if they haven’t already. They all do it. They all do it. It is interesting too about like the, you know, so there’s the so the question was really around increasing bandwidth and, you know, my take as a as a hardware designer, as someone doing like simple IOT devices is like that kind of like Imad mentioned too like the crossover between like these different technologies but then application space too. It’s like a smart meter doesn’t need to send that off and maybe in certain environments I think we talked about at some point maybe just the four of us, maybe it was, I don’t know if it made the, if we talked about the webinar, but like like maybe there’s certain like high bandwidth events. So like in emergency situations and things like that, maybe you do need it then, but most, you know, like a lot of these smart smart meters or low bandwidth things, there’s always the the trade off of battery and transmission and then you know, so you’re really just trying to do this one thing and go back to sleep to save your battery. But then also, like Imad said, to the cost of individual nodes as well, All these things start to interplay together and becomes this very complex mix of what technology, what hardware, what, you know, what protocol like we talked about, where it all fits together, and it’s it’s very confusing. But I’m glad to have you guys, helping helping to piece it all together, you know. It’s like webinars like these are are required to to make it a little, you know, to bring some more clarity, which is great. Alright, guys. Any other last thoughts before we wrap up this webinar? Well, I do see a small question asking if the Walter module is available and I’m glad to say that it is available. We have been working for more than a year on the module, and it’s now, in stock on Crowd Supply. We also have a European distributor called Tinytronics, and we’re working round the clock to add more distributors to the list. And soon, I think this month, a Walter will also be available through Mouser. Awesome. That’s great. Well, excited to see you. Walters out in the world and transmitting back using wonderful Sequans modems and Soracom connectivity. So, it pieces it all together and talking to Goliath hopefully and, yeah. Thank you all for, being here. Thank you to all of our our attendees for being here. But Dan, Duncan, Imad, great job. And, yeah. We’ll hopefully have another webinar like this soon. Thanks so much. Cheers, Chris. Thank you. Thank you very much.