Connecting in Difficult Remote Locations Over Cellular

 What to expect when you're connecting in difficult remote locations where bandwidth and hardware constraints are working against you. We are joined by Andrew Jarman, CTO of Toku systems and Kenta Yasukawa, CTO and co-founder of Soracom. 

Andrew shares his experience deploying leak detection devices in oil and gas fields and along pipelines in some of the most remote regions of the world. He shares both his engineering tactics for optimizing hardware, but also explains why old DOS programmers make some of the best IoT embedded engineers.

The participants talk extensively about minimizing power and bandwidth requirements for IoT devices, optimizing cellular connectivity, improving software and firmware performance, and the use of services like Soracom Beam and Soracom's Global Roaming SIMs for efficient and cost-effective data transmission. They also discuss GDPR and IoT security. The discussion reveals the deep technical complexity of IoT systems and the creative solutions required to ensure they operate effectively.

Transcript

Ryan: 0:00

We're here talking about the, what to expect when you're connecting in difficult remote locations where bandwidth and hardware are working against you. We're here with Andrew Jarman of Toku systems. He's a chief technology officer. and we're also here with Kenta Yasakawa, the chief technology officer, and one of the co founders of Soracom Andrew, would you paint a visual picture about where you're deploying your products and hardware? And what does that, what does that look like? Set the stage for us.

Andrew: 0:32

thank you, Ryan. In the oil and gas industry, there's lots and lots of places where you find instrumentation. you know, you think mainly of your big oil and gas refineries, processing plants, and those areas are very well instrumented with traditional technologies because they're using wired sensors and they're running control systems and everything has to work properly there or bad, bad things happen. but In a lot of the upstream gathering systems, so the, from the oil wells and from the smaller pipelines to some of the remote facilities, there's not a lot of infrastructure in those locations, right? They're further away from the centers, and there's often not a lot of power, out in some places. And so they're not Frequently instrumented very well, right? There's a lot of drive up, check out that things aren't leaking, that pumps are running, and that's as far as people go in many cases. Now, over the years, of course, the higher producing assets are, are instrumented better because there's more money there, but there's a lot of applications where people. Didn't instrument it. So in recent years, as technology has gotten cheaper and some of these technologies like the cell connectivity and IOT types of sensors are more emergent, it now opens up the possibility to put things like pressure monitoring on Places which historically haven't had them right so you go out there, but now you're you're not in the cities or close to cities You're now in the middle of nowhere So you've got locations where you know there is no power if things are powered by you know Gas sources to run equipment so have to be battery powered It's, it's cold, right? Especially in Canada and northern United States. It gets down to minus 40 at night. So the temperatures are extreme. there's not a lot of sunlight. So your typical solar panels, you know, they have to work all the time, not just most of the time. So in the middle of winter on Christmas, it's, it's dark, lots of night and it's cold. And so, you know, the power systems struggle. to work properly in those times, you get snowstorms for two or three weeks at a time. So very poor sunlight for your charging. And then, of course, there's the connectivity part. So you have to have connectivity to your cell towers. If that's what you're relying on. You know, some places are in forests, some places are in valleys. so you end up with, a mediocre at best signal in many of the locations. So, all those provide challenges just to get something, anything to work properly. and then on top of that, you have to have hardware that can actually work. Uh, in those environments. So oil and gas applications by their nature are hazardous, right? You've got explosive gases. You've got things that burn and blow up. So they really don't like you putting equipment that's not certified. So the equipment has to be a certified, you know, either, you know, underwriters lab in the States or CSA in Canada or equivalent. bodies and throughout the world. So they, uh, equipment is expensive to design and test and go through all those certifications. And then when you install it, it has to be installed. Uh, according to the right, uh, criteria, right? So getting an IOT device that has a cell modem, um, built in. The cell modems are relatively power hungry. They, to transmit RF energy, they need peak currents that are not. Um, as you know, for some of these small things that are intrinsically safe, it's easier. But when you have a power hungry device while it's transmitting to do that without causing damage or to meet with the safety certifications, it's a lot of challenges to get a product built and certified to do that. So all those add a lot of cost and time to market to bring products to work. And then you have to write your software to. To work properly with all the edge cases that happen in, uh, in these applications. and then there's no one there. You can't just drive up and go look at a log or look at a screen. There is no screen. Uh, there's no one there. So, you have to know what you're doing and work hard to anticipate all the problems that could show up.

Ryan: 4:39

I'm hearing these are devices that are in locations that are difficult to service. And even if you could service them, you're probably potting them in epoxy or you're putting them into enclosures that are challenging to get into. They require. As much power efficiency as possible, since you're not going to be pulling off of a line someplace and when you do get signal, you're pushing peas through a, a straw. trying to maximize the throughput of whatever limited bandwidth you have access to.

Andrew: 5:11

Absolutely right. And then troubleshooting right when things go wrong. Who can tell you what it's doing, right? You have a limited user interface, if anything. that creates a lot of challenges to supporting a large network. If you have hundreds of thousands of devices out there, you're proactive at how you look for data problems and react and work with your customers to get them back online.

Ryan: 5:35

there's multiple sides of this coin, and I don't even think it's 2. So we're looking at another geometric shape of some kind and there's, the hardware. There's the embedded software. There's the actual, software that you're communicating with, out into the cloud. But then there's all of the cellular infrastructure for all of the. Packet routing and protocols and so I'd like to actually turn this question to Kenta over the years, knowing that cellular is very power hungry. How is the evolution of cellular come to a meet some of these specific needs? And where have you as someone who lives in the space had to find new ways to evolve. Cellular to, address the gaps, maybe where traditional cellular has fallen short.

Kenta: 6:27

Yeah, definitely. The cellular network and radio technologies, they evolved to support more bandwidth, you know, more uh, rich applications, but there are certainly needs for supporting those low power consumption devices. And definitely when it comes to using regular cellular module for, The use case is that the Andrew and talk systems are working on the oil and gas industry in general. Those you don't require high bandwidth. You don't want to reduce the battery consumption and reduce the overhead for communication. So 3GPP has actually worked on, to evolve cellular standard to support those low power communications. So, uh, the. Probably our audience may have heard, uh, LTE Cat M or NB IoT. Those are, evolution of cellular LTE technology to reduce the bandwidth, but, uh, reduce the power consumption as well so that they can support the, uh, low power footprint devices. So it has a limited, limited bandwidth, but that actually allows the modem to be simpler so that the modem cost can be also lower. And because it's simpler, it doesn't have to consume too much energy to communicate. And also it has some enhanced technology to put the modem into low power sleep mode. there are some technologies that, uh, LTE Cat M supports. For example, EDRX that actually allows modem to sleep for a longer period of time than the standard, high bandwidth LTE modules. There is also a power saving mode that can actually, uh, put the modem into low power energy consumption more than stays keeps the battery for a long time. So, uh, there are these technologies that can be applied to oil and gas technology industry and also, those devices in the remote and also on top of that, that's the kind of underlying underlying cellular technology world evolution towards the, low power battery use cases. another thing that we have been doing on top of that, to reduce the communication overhead. if you, have to do, a full fledged secure protocols and all the TLS negotiations and everything on top of the cellular connections, it would cause, a lot of data overhead and also has to consume the processing power and that actually ends up draining more battery. So when we launched our service, we have focused, on, supporting all these, Battery power devices and IOT devices so that they can efficiently communicate with cloud backend. So we have come up with a solution to receive data over our cellular link. That link is provided from us and our partner carrier. So it's not going through the internet. This link can be used as a trusted communication between, IOT devices and SolarCom platform. So this part, you can use the, no overhead protocol. And without actually putting authentication information, we can authenticate and see who is sending data. So we can receive it securely. And then, we can apply, customer provided configuration and credentials and, security mechanisms to forward the data to customer's cloud backend. By doing that, We can actually, support to build end to end secure IoT architecture while having low overhead and low data consumption on the IoT side. By combining all these, we can optimize the data consumption. Build an efficient system. Mm hmm.

Ryan: 10:00

my understanding is that there's 2 different sides of the cellular game. There's from your device to the tower, the tower to the carrier. And then the carrier typically goes right to the public internet and then connects over to your servers, whether it's on AWS or Azure or wherever. And that all requires, An encrypted signal with TLS, which is a bunch of, you know, packet headers. So it just adds extra strings of, of code and, and characters. And you're having a heavy lift that goes from the device to the tower, the tower, to the data center, And what you're saying, Kenta is. You've shrunk the requirements between the device and the data center in the cloud, and you then add the packet headers. You add the encryption and then communicate from the Soracom servers to the, the cloud server. So AWS, whoever you're talking to gets all the encryption that they're looking for, the extra commands and authentication and saving people like Andrew that heavy lift, right? Reducing the burden. Maybe Andrew, talk to me about, your experience in having to deal with data overhead, paying for it, powering it using battery life to, to move it across the airwaves. I'd love to hear your, your practical experience with that.

Andrew: 11:24

Yeah, That's a great point. That's one of the biggest selling points that I was very pleased when I found this on the Soracom website is our initial product didn't have encryption, which, of course, we knew we had to get there, but we had to get something working, and then we needed to start looking at at encryption on top of it. So we use MQTT. And so we had to be using something that the MQTT server could use, which meant we had to do a TLS wrapper around the socket connection. Well, our processor is only running at 16 megahertz, like megahertz, right? Uh, and that doesn't even slow down to eight megahertz. And that's that's as fast as we run it on on our controller. It's equivalent in horsepower to like an old PC from 1986, right? That's, we were able to do everything with that. so doing a full TLS handshake, one, we even got the libraries that we could do all that stuff, on our client libraries, but it took so long to just do the electrical curve calculations that the connection would drop, like the server would reject the connection. So we would either have to look at. boost up our clock speed just to do the TLS handshake, or, all sorts of stuff, right? And it was just very challenging to get that to work as well as all the code, added on to our microcontroller to implement the TLS libraries. and a lot of them aren't designed for deep embedded applications, So that was just, it was just a real challenge. So with, uh, with using a, product like Soracom has with their beam and their virtual private gateways, we keep it encrypted by the nature of the cell, technology, uh, with the APNs and so on. but we can just keep using our code as it was before. We just changed our endpoint to go through the Soracom proxy and it did the TLS wrapper. To our MQTT server. So in a few short days, we got that working and it was like, that was it. Yep, that's it. So it was great, right? I, I knocked off a, a pretty significant development effort, in as much time as was just trying to get the stuff going. and it was, implemented and pushed out to our. field devices in a few weeks. So that was very, very helpful. And then the power consumption there is better to write with embedded devices. Clock speed means power, right? So if you can lower your clock speed, you lower the power consumption and then. All the TLS also adds a lot of round trips between the device and the server to get the handshake done. That adds latency, and that is also measured in power, right? So everything comes back to power consumption. So the quicker you can get something done at the lower clock speed means you're saving power.

Ryan: 14:05

it's almost a trifecta Reducing how much data you need to send reduces how much processing you need, which reduces how much power you need. And it also reduces the cost, right? if you're sending less data over cellular, you're paying for less data over cellular,

Andrew: 14:22

Absolutely right. Yeah, so it cuts your cell costs and your latency, That's actually a bigger factor is that the more you're time you're spending sending messages back and forth, you're keeping the modem powered on longer,

Ryan: 14:35

So Kenta, what was the initial impetus? Where was the push to add functionality like this into Sorcom with that unified end point or a SSL proxy of some kind, was it people trying to bring non encrypted devices into modern cloud integration? Or was it specifically trying to just reduce the actual power consumption or processing requirements?

Kenta: 15:01

Actually, you know what? We, we designed and developed this product for the specific needs that Andrew was talking about. So the, the TLS negotiation and all the cryptographic, processing. It's hard for the low power, devices and it could be already a challenge for IOT devices to be, used in the, in reality. So back in, 2015 when we launched our cellular connectivity, API and management platform, that was definitely the foundation that we have. focused on first, but at the same time, we also worked on this capability of, offloading TLS and authentication workload from devices to cloud. So that was, what We have been doing since the launch. And the reason why to look into that is I used to work as a researcher, for connected home, connected sensor gateway and all these, you know, kind of early days IoT projects. And always was wondering how we could actually run all these security protocols from the device to the cloud all the time. And another challenge that you might face is the how to properly configure this authentication credentials to each and every device, that's already a headache if you have to build thousands or tens of thousands of devices and have to manage that in a factory. And then after that, you are able to have to rotate credentials over time. So by using our connectivity ID in cellular network, it's a SIM card provides an ID and authentication, so it can be used as an authentication token. And then, we can establish a secure link by using our private secure, cellular network. So we can offload authentication and encryption to cloud side so that the devices can, be more efficient and the data usage cost can be lower. And that was actually one thing that I'm so excited when you said, Andrew, is that actually offloaded your development time, which is an important resource in IoT development projects, by using our capability, you didn't have to integrate TLS library into your device, and you could actually just change the endpoint to Soracom endpoint, and you could actually apply TLS Integration by doing that. That, was another thing we wanted to, do. we wanted to offload developer's time, to, our platform services so that you could focus on the most fun part of IoT, that is to build applications and, services. what you said actually, made my day today.

Andrew: 17:40

It's great when technology works. There's actually another point with that kind of methodology is that Right now we have all our devices send data to one server instance, but if we ship the same product to, say, different parts of the world, or to, say, a large customer who wants to run their own MQTT server. If I don't use something like Beam, I would then have to go push out the endpoint down to the devices, maybe before they ship, which is another step in my logistics. With, with Soracron Beam, I can go just change the SIM card to belong to a different pool and on the server, change the endpoint that it's going to. So it's actually added an operational savings, in that kind of application where the customer wants to take over the MQTT side and run some other. that we're doing, we can just make an endpoint for them and, and change it on the fly. And it's done in a few seconds. So it's a logistical improvement as well.

Ryan: 18:36

This reminds me of in the marketing world, the ability to take 1 QR code and put it on the back of your business card. And that QR code actually links to a dynamic. web space where you're actually on the fly changing how that QR code route. So it's going to like a tiny URL and then you, you get to actually change it up. So that could be, your latest event or, whatever you need it to be. and in this particular case, you're getting to ship the same device with the same profile, the same credentials, and it's the SIM that is the unique fingerprint. And then you just say and assign that SIM number to a group that might have a different set of rules. Is that right, Andrew?

Andrew: 19:21

Absolutely. That's, that's great. Right. We do that for testing, right? So we can things we send things to test server. So I just grab a device off the shelf or do other demos of things that a lot unusual. That makes it very easy. so that's, it's great Love it.

Kenta: 19:37

Yeah, I'm so happy hearing that you can. So, uh, just for, uh, to, to explain to the audience, the, Soracon Beam, our product to, offload, TLS encryption and authentication, you can actually define a group of SIM cards or devices and apply different end point configuration. So devices can just send data to one single unified end point that we have. There is no change in the configuration in the device side needed, but you can define devices into different groups and each group can have a destination server configured. So one group can be test group, the data can be forwarded to test MQTT server. One production group can send to, the production server. If there's a group in a specific area, that should use different server, you can just, uh, apply the configuration and you can just change the group level configuration from one server to another and all the devices. The data destination will be, changed at once. So the IOT device management can be easy as well by doing that. I'm glad that you have been using that feature.

Andrew: 20:46

Do you have a lot of oil and gas customers who are in the oil and gas space?

Kenta: 20:52

Yeah, we have a, a customer in Japan called Nichigas. They have been, they have deployed, the network control unit for, legacy, of the gas meters. And they have been sending data, from time to time by using both, cellular Cat-M and also Sigfox. That's, one of the, our largest customers in oil and gas.

Andrew: 21:10

Well, interesting.

Ryan: 21:11

Andrew, are you doing certificate management at the device level on your hardware? Or are you leveraging the SIM for

Andrew: 21:18

Yeah, we're not using certificates right now. we do our manufacturing process. We push out a unique serial number and, synchronize the passwords to be used with our MQTT server as well as on the device. But we, we are looking at using certificate authentication down the road, which case then would use a certificate management that would be provided through, uh, through beam to add the certificate, information and we can use that instead.

Ryan: 21:44

Would that reduce by not having to have that, that credential at the device level and just letting... That unified endpoint handle that handshake. Does that reduce any additional processing power? Or is it more on the manufacturing side

Andrew: 21:59

More on the manufacturing side. And of course, you know, when you have a pre shared secrets, you have to manage that, manage the security of the pre shared secret. Um, you know, and, and there's other, operational and data security things that we have to do. So, you know, we keep all those, you know, encrypted, uh, and stored away so that we can recover them. Of course, if you, I mean, you can imagine having thousands of devices, we lose the secrets because we had to rebuild the MQTT server. That would just be horrific. Uh, so, you know, you just don't, you put a lot of things in place to make sure that can never happen. but certificate management through Soracom would be even better because then the device doesn't even have to manage it at all. Right? We

Ryan: 22:41

yeah, I remember a contract manufacturer that I've been working with at a past company. And we actually had to, they actually sent someone with the, you know, the, the aluminum sided. Spy, suitcase, everything but the handcuffs, I guess, but actually like went into the factory with the USB drive. And like, they had to observe the chain of custody on those secret codes that were going to be installed on the devices. Like, they were there for, I think, 6 weeks, in a hotel near the manufacturing facility to just oversee that those keys weren't ever going in the wrong place because it was a, it was a fairly sensitive application. So just having to manage, as you said, like, keep track of all of that stuff. And, to, to eliminate that seems like it would, for even some really sensitive applications. Eliminate that need since there is no duplicate sims out in the world, right

Andrew: 23:41

Exactly. Yeah.

Ryan: 23:43

So talk to me a little bit about the, the balance, the dance that you play between optimizing the hardware itself. And the challenges that you've had to overcome at that level. And then firmware side that handshake side with like the MQTT and then the cloud server, you've had some unique situations like, how long your sessions can be open. Can you talk to a little bit about that?

Andrew: 24:10

Yes, yes, certainly. As I mentioned before, time that the modems on is absolutely critical, right? when the modems powered on is taking 50 to 100 times more power than the device takes when it's just sampling and recording the data. So we really want to minimize that. we sample and store the data to flash. So that is very useful to, Make sure that we don't lose any data if the cell side drops off or we have to retransmit or whatever. But once we get the data in memory, we then want to send it over the server to over the over the link channels as compactly as possible. So we've worked hard to pack those bits in as as tightly as possible. So when we send in our one second pressure data, and we typically send it in every hour. So we gather all up and then we send it in in an hourly burst. so we will take all that data and we strip out timestamps, we strip out extra bits. So we don't send floating point numbers. We said we strip it down to an integer, a scaled integer. So it's maybe a hundredth of a P. S. I. Or 1000 of a P. S. I. Pack in All of that as tightly as possible into, MQTT message. So we're basically bit packing it, extended it over the, over the MQTT. And then the server then, of course, reverses that and turns it back into, some of the web guys like better JSON or all sorts of very wasteful representations of data, but more standard. You know, the, uh, the amount of, I mean, the random we have on these processes, 128 K of RAM, right? So you can't put large strings in there or anything like that. You have to be very aware of how much you've got for memory and flash storage and then know it as use. Point out, you know, packing in the data to go over the wire cuts down the uptime for those messages. So when we're, you know, is a race as soon as you turn that motor power on, we've got to do everything we can to get connected as quickly as possible, send the data as quickly as possible and then disconnect as quickly as possible and then shut everything down with all the retries and air handling and stuff that you need to do to make sure that that connection get through.

Ryan: 26:24

What is that optimization process? What did that look like? were there any big breakthrough moments or any ahas we got it down to. Once every hour, we got it down to, from five, once every five hours, down to once every hour. Is there anything along those lines where little, little changes made big, big results?

Andrew: 26:43

Uh, probably less, less in joyous or triumphant because our firmware guys were old. We grew up in the Apple II and PC days. So the best firmware guys are people who wrote DOS programs because essentially it was an embedded system. Like you didn't have, all the abstractions you have today. If you wanted to write a serial port on a DOS machine, you had to write your own interrupt search routines. I mean, that's how horrible it was back then. So the people who grew up and wrote code back in those days are pretty good at writing, embedded code for microcontrollers. So we knew we had to just dig back in the trunk of, of all the old programming techniques we used to use back in the day and apply it to the microcontrollers we have today. Um, so a lot of those, those techniques, but, you know, to put some numbers. In perspective, in an entire month of sending one second resolution data, and this is high, high resolution pressure data, we would send less than 15 megabytes of cellular traffic. So that's hourly transmits with one second pressure readings. So every, every hour, it's sending another 3600 seconds of data in and all that's less than 15 megabytes. that's not even a picture right on your phone. So yeah, we're very pleased about that,

Kenta: 27:58

Yeah, if you do it in JSON, it would be, it would explode like this.

Andrew: 28:03

Oh, yeah. So, yeah, you have to be very miserly and just really consider everything you're doing. Like, well, how often do we need to send that? And can we, does that go every minute? If we put that every hour, you have to, of course, your primary signal every second, but you have to, just think carefully how much you want, how much resolution do you want, right? Rather than say the floating point, send it as an integer and just scale it and just be aware of how many bits is really important. If that, yeah. There's no point setting temperatures to seven digits for ambient temperature. No one cares, right? So all those little tricks, you know, you to be aware of just to try, add some sanity to what's going on.

Ryan: 28:41

So, by working with the binary data, uh, at the device level, and then translating on the, on the latter half, that's just right. There is just. You know, why even optimize when you just send less characters

Andrew: 28:55

Yeah, right. Exactly. And, you know, you'd think, oh, let's just compress it. Well, really. there's no point using the typical compression algorithm, like your gzips or some of those other things, because those, if you have a small amount of data to send, if you can reduce what you're sending to begin with, that strips it down. But all those sorts of lossless data compression techniques have an overhead to them. And so when I was doing the analysis of this, the overhead Wasn't even worth what we're sending. If you just reduce the size down, if you're only sending four or five kilobytes at a time, the Gzip algorithm takes more overhead just to get started, right? So, uh, just to keep it all simpler, less code, less things to go wrong, and it's easier to debug it.

Ryan: 29:39

it's where the treatment is worse than the symptom itself, right? Like, this medicine is, what, what are the side effects? It doesn't sound like I'm actually going to feel any better, by applying the compression to what you're doing. Kenta, you had a question.

Kenta: 29:52

yeah, Andrew, do you have a way to change the frequency of sending data or measuring the pressure value of, when the devices are already deployed in the field?

Andrew: 30:04

Oh, yes. Yeah, we can. So we do everything over MQTT. Just, there's, I think, a quote that's the best part is no part, right? You can get rid of extra things that you don't have to put on there. Then why? Why add more stuff? Right? So we send commands out to the devices in MQTT as well. So we can change the sample rate, We can change how, often it calls in if, of course, the device finds as a fault or a pressure goes on alarm limits, it calls in right away, right? So if interesting things happen, it calls in without waiting the full hour. We can do firmware updates over MQTT. So I've called it MQTT file transfer protocol. So it's M M R T P. It's a very simple way for the device to go fetch a file, which is a new firmware download using MQTT. Messages. Um, because you got, it's the tool you got. Why don't you just use the tool? It's maybe not the most efficient transfer, but how often do you do send firmware updates, right? So, you know, if that's, uh, if you're doing deep embedded, just simplify, simplify, simplify the matter, less is more. I

Kenta: 31:13

Hmm.

Ryan: 31:13

if there was one thing that people took away for their Low bandwidth, low power, constrained situation. What is the one thing that you could recommend that provides the, greatest gains in power savings or whatever that might be? What's the one technical thing that they could be implementing? That, that you'd recommend

Andrew: 31:40

think knowing what your hardware does and how does it work, You really have to start with that, whether you're buying hardware from someone else or designing it yourself, know how it works and understand clock speeds and how to manage how the processor works, Because that's really the key to everything. If you can manage your clock speeds, you can manage your power and then from there. All good things happen, you know, and then with that too, no data storage sizes, costs, transmission costs go a long way to be able to keep the costs down ongoing, and to keep your power consumption down.

Ryan: 32:16

Kenta?

Kenta: 32:18

Yeah. Since Andrew has all. I've already talked about so many techniques that you can do on the firmware. We'll focus on the cellular communication part. Therefore, when it comes to reducing power consumption that the cellular or any kind of communication or wireless communication, make the modem sleep as long as possible. That's the key thing. as you, Andrew said, if you keep the modem, open that connection for long time, that consumes a lot of battery. So did you think the, the time to send data. It's really important. So reducing because of that, the protocol negotiation should be as simple as possible. Maybe if you can completely remove the protocol negotiation and you can simply send data, that might be the best. But in that case, you might lose the ability to, do all the, benefit of using like TCP or MQTT. So there's always trade off. So you need to think about the right protocol. But by reducing the modem, open time or air time. that's the best thing to, reduce the battery consumption. And also by reducing the protocol overhead, you can pay less for cellular provider, which is also important. I think it may be, it may sound weird for me to say that, but we are actually here to, make your IOTs. Projects successful. So we really help to reduce the data consumption so that we can have a scalable, robust, infrastructure that is also, reasonably priced, when it comes to doing, more with less.

Ryan: 33:44

When it comes to multi carrier support, having to choose between a single provider or where Soracom is looking at multiple carriers, how is that impacting the work that you're doing with Toku and the device functionality out in the field,

Andrew: 34:02

That's really good. You brought that up. in the past, both before we, we discovered Soracom, um, and when I worked at another company that we were also doing IOT types of products, managing cell companies was. A bit of a pain to be honest, either you're using a primary carrier. So say in Western Canada, we might use TELUS, they were there with the old government telephone people. So they were very strong in Alberta, but you get outside of those areas or you get to an area where maybe TELUS doesn't have a tower or it's not the best carrier then you want that option to go with a different carrier or you get a trial customer a new opportunity, a different part of the country or in a different country, and then you have to scramble to get your cellular communications all set up. So these global roaming SIM cards like Soracom has these agreements with all these carriers, it's fantastic because I can use a single SIM card and ship it in inside the device and we can just figure it out once it gets there. So there's a range or obstruction between our device and a particular carrier. We've got other carriers to fall back on and it just works right? And that's that's the beauty of it. And then over time figured, okay, this is actually working pretty well. Let's start pulling all the SIM cards out of our existing products. So Bell Canada lost out and every device attached to our operations got the SIM card ripped out of it and a Sorocom SIM card went in and that's that. So, um, it just saves so much hassle, right?

Ryan: 35:37

in 20 years of doing IOT devices, changing carriers means having to go out and switch the SIM. Right? So Kenta How is it that, Andrew and his team are able to take advantage of an entirely new plan, but not having to swap out the SIM card that's probably buried deep within, uh, an enclosed, hard to get at piece of equipment. Could you describe that process?

Kenta: 36:05

Yes. Yeah. They, at the early stage of, our, platform development, we were aware of that. it's. Nearly impossible to replace the existing sim or eSIM in the devices that are already deployed in the field. and we knew that our subscription plan that we, we had at the beginning would be the best for forever. So we had to, think about the way to, Remotely update and over the air, and push down new profile whenever we have a new subscription plan that is beneficial for our customers. So we were aware of the challenge since when we were working on our own SIM product, we have, our global connectivity SIMs that we design and work with our SIM vendor to, and so we have all the, software that we have. We can install in our SIM chip and ship to our customers. And when we launched our first SIM product, we didn't have the backend infrastructure to update the profiles over the air, but we added that capability within our SIM card from the day one so that we can eventually use the feature to push down new profile. So, we launched that feature later on. And how it works is that you can select a sim or a bunch of sims and select push down new profile whenever it's ready. And that, that will trigger our, over the air update framework for sims, to send a message and download the profile onto existing sims. So in this case, we are now, launching a new, plan US max that allows access to all the three major carriers and you can select the sim and push down new profile. And that happens automatically and behind the scene. And the SIM will be able to switch to the new subscription plan once it's received and the modem can, talk to new carrier, by using it. That's how it works. We, we call it subscription container'cause the, the, the subscription plan is contained in a container and delivered to, already deployed SIMs in the field.

Ryan: 38:08

Man, this reminds me a whole lot of like the Kubernetes and other sorts of, containerized, uh, deployments. What, what I find interesting though, is like when I've got my, my iPhone and I wanted to switch carriers. it was using EUICC and I had to go in and as the end user had to go and authorize a bunch of things as a consumer, but this isn't the same technology that a commercial handset is using, you develop something that, uh, can be deployed from a fleet manager. So Andrew or, uh, you know, someone who has access to that list of all the deployed Sims can make all of those changes without needing to do any sort of end configuration or end authorization? I'm

Kenta: 38:54

Yes, actually we support both, the EUICC, what do you use on iPhone, Android devices as well? So we have, a customer and our own application to download the Soracon profile onto your phones and use it. So that actually requires the user's operation on the device. But that's certainly useful for some use cases. We have supported that. We also, that's called the EUICC consumer profile management. And we also support EUICC M2M profile management. That one, you can push down new profile. To, existing EUIC systems, by using standard GSMA, technology that's also, supported, but we rather developed our own solution as well in addition to these standard technologies, because the when it comes to adding an app, Downloading subscription plans that we manage, we don't necessarily have to have the entire UICC framework to deliver the profile because we manage and we can make sure we can use our over the air update the keys we can. We could implement much lighter way of doing subscription management. Compared to EUICC profile management, that's downloading entire virtual machine onto you, server rack. It's we support that, but it's heavier. And requires much more communication overhead. Instead, our subscription container approach is like, as you said, Ryan, it's like Kubernetes. We actually have a lightweight container of subscription plan and push down that to existing SIMs over the air. We have supported both because by doing that, we can apply our new subscriptions to a wide range of SIMs and devices.

Ryan: 40:41

asking this because I don't know the answer, but for someone like Andrew, who was talking about, even getting the subscription container updated to get plan. U. S. Max added. Would being a heavier lift with a larger framework, would that be a harder thing to deploy in these? Remote low bandwidth locations

Andrew: 41:04

from my side, my biggest concern when we're looking at the subscription containers is how long the modem had to be on and how long did I have to leave it on for this magic to happen. I don't know what all goes on in the SIM card. I know there's a lot on there. It's not just a memory card. And so the bigger the download that the SIM card needs means in a poor cell phone connectivity. Area. How long would that take? How long do I need to leave the modem on? Because there's no feedback to me that all this magic is going on. So far, the devices I've tried have just worked. I added some commands to the new firmware to tell it, next time you call in, stay around, you know, don't, don't hang up so quickly, you just have a chat. And so I can... Synchronize that with enabling the container to try minimize that. Like you can imagine someone had a helicopter into a location to go install all of our devices. If that thing goes off net, it's a big deal, right? So I'm really reluctant to do anything that would mess that up. And we're very careful how we do the dance with the network, especially. That whole dance has to work properly.

Ryan: 42:10

Gentelmen I'm going to leave us there. There's still so much more ground to cover until then. Thank you for your time.

Andrew: 42:17

Thank you, Ryan.

Kenta: 42:18

Thank you. That was fun.

Ryan: 42:23

final question for you, Andrew, what is Soracom to you?

Andrew: 42:32

Oh, wow. Um. To me, their Soracom is a very valuable piece of our infrastructure, to enable the device to our cloud connectivity. Like it's, it's become bigger and bigger. And as I've explained to other people in our company, having one provider, the one SIM card provider, I have one part number that has a Soracom SIM card in it, and then it just works right if it works wherever I need to ship product to. it simplifies my, my supply chain. It simplifies, how I manage devices and it provides me a valuable partnership to get my data to my server. So that's, that's everything right. Without that, I don't have a product.