Podcasts

10 January 2024

Eseye’s Founders: The Road from Zigbee to Ubiquitous Global Cellular IoT

IoT Leaders with Nick Earle, CEO of Eseye, Ian Marsden Founder and CTO, and Paul Marshall Founder and CCO

It turns out that big mobile network players can learn a lot from the airline industry. These two seemingly disparate industries actually have more in common than might appear at first glance.

It is one of several topics discussed on our 40th special edition of IoT Leaders, which brings together Eseye’s two Founders Ian Marsden and Paul Marshall to discuss the global IoT connectivity challenges they set out to solve when they started Eseye.

The show explores:

Eseye’s founding story from Zigbee to SGP.32 and beyond, including top a-ha moments from the past 16 years
Why achieving 80% connectivity uptime kills the IoT business case
The unsustainability of roaming as a quick fix for connectivity, and why there’s a need for a new financial model for roaming
What mobile network operators (MNOs) can learn from the airline industry, and the Star Alliance in particular
Why SGP.32 will be a big feature for 2024

Tune in to hear how Eseye tackled the challenges surrounding global connectivity long before it became an industry buzzword, and what the journey looks like today.

Read the transcript

Subscribe to IoT Leaders

Subscribe now

Ready to take the mic?

Join us on the IoT Leaders Podcast and share your stories about IoT, digital transformation and innovation with host, Nick Earle.

Transcript

Intro:
You are listening to IoT Leaders, a podcast from Eseye that shares real IoT stories from the field about digital transformation, swings and misses, lessons learned and innovation strategies that work. In each episode, you’ll hear our conversations with top digitization leaders on how IoT is changing the world for the better. Let IoT Leaders be your guide to IoT, digital transformation and innovation. Let’s get into the show.

Nick Earle:
Hi, this is Nick Earle, CEO of Eseye, and welcome to this very unusual episode of the IoT Leaders podcast. It’s unusual because instead of interviewing a customer, a visionary, industry analyst, I today recorded the interview with Ian Marsden and Paul Marshall. They are two founders of Eseye. They founded the company 16 years ago and I sat them down and started to talk to them about, as you’ll hear, why did they build what they built and to what extent did they learn lessons along the way of the problems that they had to solve. And so they tell the story pretty well here on the podcast and even looking forward as to how new technologies come along will also fit into this.

They describe it from both a technical perspective because obviously they’re deeply technical. These are the guys who were very instrumental in the creation of ZigBee. They chaired the ZigBee working group and ZigBee is now used in, I think, four and a half billion devices around the world and actually on Mars with the Mars Rover. ZigBee is very well established. They then took that and said, “Okay, how can we do that for cellular?”

But they don’t just address it from a business perspective. They also address it from a financial model perspective, which is how do you create a new financial model for roaming, which actually gives a more equitable distribution of the revenue to the operators. If you can solve that problem, then you can actually solve the problem of global IoT for everybody. That’s a really fundamental aspect of what we believe in and what we’ve implemented here in Eseye. I think you’re going to really enjoy this. What I’ll do now is just hand over to my podcast with the founders of Eseye, Ian Marsden and Paul Marshall.

Ian and Paul, welcome. As you know, this is the podcast that I’ve been wanting to do for a long time. We’ve interviewed a lot of customers, we’ve interviewed analysts, we’ve interviewed thought leaders, and now we’ve got the founders of Eseye, and so really looking forward to this one. Let’s just start off before we dive into what you did and why and where we’re going, into your backgrounds. Maybe I can start off with you, Ian, just to introduce yourself, but also what’s your background before co-founding Eseye?

Ian Marsden:
Well, I suppose I think our backgrounds in some ways are obviously joined together. We originally worked together back last century in Philips and at that point we were working on wireless systems and we were instrumental in the founding and setting up of the ZigBee protocol. We left Philips to start up a company called CompXs to develop ZigBee Silicon Solutions. Ultimately, that company was acquired and then we moved on to starting up Eseye.

Nick Earle:
Paul, your background, obviously, is very similar as he’s already said, but I think you guys had different sort of skill sets that you had that you both brought to it.

Paul Marshall:
Yeah, what was interesting is Ian looks much more at the software and the protocols and the way those systems come together. I’m much more focused on the hardware and how people deliver actual physical solutions that are going to do what people do. I think the thing we’ve always found really interesting and good about working together is being able to balance those two and say, “How can you drive the cost out of the system either by improving the hardware or actually drive the cost out of the hardware by doing something novel with the software?” When you’re talking about communication systems, whether that’s the short range ZigBee or some of the stuff we’re going to talk about today, it’s the same sort of story. That’s the same sort of challenges that we’ve been overcoming.

Nick Earle:
Great. Well, let’s dive into those challenges. Any company when it gets formed, its founders have a vision and arguably a frustration with how things work today. They see an opportunity of how they could work in the future and they set out to build something that fills that need delivers something in a completely new way. That leads me into asking you, after you left Philips, you formed CompXs, you sold CompXs. ZigBee is in billions of devices and not just around the globe, but also on the moon with the Mars Rover. It’s massively successful. But what were the drivers that triggered you to start a new company, which subsequently became called Eseye? Ian, what problems, if you like, were you trying to solve or what could you see in the market that wasn’t working?

Ian Marsden:
Yeah, I think there’s a number of layers there. Certain people would always go and start businesses and do stuff. I think we came out of CompXs going, “Okay, what are we going to do next?” That’s really where we were looking at what the opportunities and what the challenges were. It was really, I think the driver to start Eseye was a realization from our ZigBee customers who were all building local area networks for connecting devices together that actually those devices were fine by themselves, but they all needed to connect back to an enterprise to deliver as a service function to an end customer. Whether that’s a smart meter or a smart home device or whatever, it fundamentally needs to connect to something else.

We realized that one of those challenges was making sure the solution could be delivered globally. I suppose we looked at what technologies were out there to do that and it was obvious that cellular was the only technology that could. I think we naively started at that point going, “How difficult can this be?” That’s where the journey starts and then I suppose we evolved from there.

Paul Marshall:
Yeah, but I think that’s a very interesting point because actually we were trying to solve these problems without getting data from a local area network back to the enterprise. We were being asked these questions and people were looking at VHF radios and other proprietary bespoke technologies. I’d like to say one of the inspired things, but that might be stating a bit much, but we were saying, “The cost of using mobile phone networks, the cost of the hardware to do that is going to come down and the cost of using those networks is going to come down,” to actually being able to build something which will be able to use those to deliver this connection back to the enterprise. That was when we started to go, “This could be really exciting.” I suppose also we were looking at that saying, “These networks are global so we are not now looking at…” But they were being, I suppose they were being looked at by many people as very local networks.

You almost physically had to go and get a SIM card if you wanted to build a connected device. Then you might even have to speak to somebody to get that SIM card activated. Almost like if you are going to build a network of a hundred thousand or a million devices connected around the globe, having to speak to somebody about every single one clearly is not going to be the scalable solution. Actually, we could see that we have the skills and technology to be able to take that forward. That’s where it’s starting to get really exciting.

Ian Marsden:
I think that ties back into the ZigBee discussion, which is ZigBee at some point is really important, when we designed ZigBee to say, “How do you make a solution that can be globally rolled out, you can manufacture a single product somewhere and it go anywhere in the world and fundamentally work?” We were looking at cellular, which as a global standard clearly met those requirements. But the geographic nature that Paul has just alluded to with the MNOs having licenses in different territories means that it’s not just something that’s very easy to deploy in global products despite it being a global standard.

Nick Earle:
For our listeners, just to give them a little roadmap here of the discussion, clearly Ian and Paul have mentioned a couple of times, well the industry needed a global connectivity solution and nowadays everybody talks about that. But just to put all of this in context, this was not a year ago or three years ago we’re talking about here. Eseye, I think I’m right, was formed by you guys about 16 years ago. In fact, Paul, you told me the other day in the corridor that we’re coming up to a fairly significant anniversary, which is a certain number of days since you guys decided to plunge in on this, didn’t you?

Paul Marshall:
Yes. We hit 6,000 days in spring 2024, so we must look out for that.

Nick Earle:
Right, that’s about 16 years ago. You’ve got to think about this story in the context of what was maybe is obvious today what certainly wasn’t obvious, the conventional wisdom was different 16 years ago. It’s been a journey. You decided to solve the problem. You settled on, you had this vision of global connectivity, you’d already created global connectivity. ZigBee is global connectivity, press a button device resident. You started off on the journey, but any journey, certain assumptions that you make in the early days turn out not to be true when the strategy hits the reality of what customers actually want to do and what problems they want to solve. Maybe you guys can talk about how the Eseye today was formed by some of those early experiences that drove strategic decisions on the architecture right from the very beginning.

Paul Marshall:
I suppose one of the first things that we saw was as we were starting to build test devices and work with customers to say how could they use this technology in some products, we noticed that if you had a connection from a single network operator, about 80% of the devices would be able to connect and work because of geographical coverage. What’s really interesting to me about that is that number hasn’t changed very much around the globe and in the time that we’ve been doing this. Mobile networks, although they are increasing their coverage, when you talk about IoT devices, it’s not like covering the population necessarily. IoT devices can be put where population is and where population isn’t. That means we are tending to still see about 80, maybe 85% of devices can connect on a single network.

Being able to deploy with a single network isn’t good enough. Therefore, solutions that people were coming up with were having a red version of a product and a green version and a blue version and they’d have to try each of them with a different SIM card from a different network operator and try to see which one worked on every installation. Again, going back to scalability, you can’t deploy something globally if you have to send three devices out to every location to see which one’s going to work.

Nick Earle:
Right, right. And so multi-IMSI, was that the aha that said single IMSI wouldn’t do it?

Ian Marsden:
Well, I think there was a step in between really, which is we started out with delivering single network solutions and the first aha I think was the 80% rule. We had customers who were going, “How do we improve this?” From that, the first aha was, “Well, actually there is a way of improving this because this is where roaming comes in,” because roaming, whether it’s in country or international roaming, at some point you can as a carrier have roaming agreements with multiple operators.

Paul Marshall:
If I can just jump in there with a good example. We worked with Chubb to put in alarm systems and one of the challenges that they were having when they were working with one of the national network operators was that although they wanted to install the alarm system by the main door or the main entrance to a building, actually it wasn’t always possible. They were ending up having to install the control panel in unusual bizarre places just to get coverage from that network operator. I think that was another aha moment, which is some of these very large players who are delivering cellular networks in the country or in multiple countries, but those signals, they’re still only getting this 80% and they’re forcing their customers to some very odd behaviors.

Ian Marsden:
It’s also worth pointing out that odd behavior is actually cost. It’s either complexity for the installer, it’s complexity for customer, it’s that they have to have four variants of the product. All of that is hidden cost in the IoT solution that drives inefficiency in being able to deploy it out.

Nick Earle:
Ian, you mentioned roaming and a lot of people listening to this, and we’ve done a lot of podcasts and a lot of our guests have talked about this, is that there is a general perception out there which is “Well, yeah, duh, that’s why we have roaming.” But specifically can you give some examples of why roaming, which is so perceived wisdom in a lot of the market, why roaming doesn’t solve these problems alone?

Ian Marsden:
Yeah, to your point, roaming on paper solves this problem and to a certain extent it does. If we wind back in our business probably seven years, it probably was very much the answer in the industry and a perfectly valid answer. But there’s a number of things that that means that makes it not necessarily work. Some of those are technical and some of those are economic and some of those are regulatory. For example, let’s start with the regulatory, obviously, certain countries have data sovereignty, certain applications have data sovereignty type rules or regulatory rules that you have to conform to and often roaming, because it’s designed for temporary, either gets exemption or doesn’t fall under those rules. But if you start using that as the method for permanently making your product work, you fall foul of those restrictions. You have economic rules where ultimately the balance of payments, et cetera for roaming is often biased to penalize the network that you are roaming onto, which is fine again for a temporary roamer coming into a location.

But if you are there permanently, actually that balance goes out of kilter and I’ll elaborate that on after I’ve done the technical stuff. There’s also technical aspects of roaming, which is things to do with latency, because obviously if you’re roaming you tend to be backhauling your traffic to the home network and therefore the traffic is no longer in the location of service, which depending on your application may not be a problem or may be a significant detriment to the product overall. There’s a number of reasons. There’s a last reason, which is often you see on roaming is although theoretically roaming could run on multiple networks, in practice, of course roaming tends to be steered and therefore actually the number of networks you can roam onto in the foreign country is now massively restricted and you’ll suddenly find your back on one network and back at the 80% percent group.

Paul Marshall:
In fact, can I jump in there with that? Even worse than that story, because we had a customer who was tracking high value assets. In fact, it was construction equipment in LATAM countries and one of the things that we found was that we had a solution which was roaming in the country where they had the equipment but they reported something was stolen. The tracking device was able to report back to the location until it reached the country border. As soon as it reached the country border, it switched, it obviously was no longer able to access those country networks. But the country it moved, into the actual profile, the SIM that we were providing had no roaming agreements at that time in that country.

The device, the digger, in fact it was, it absolutely just disappeared. We had no view of it. Now, one of the things we could do on the management platform was we could trigger when we see this device reappear and that was put on and nothing happened, the digger disappeared. Then two years later we got the alarm came up that this SIM card had just been seen connecting to the network and we could see that it had just crossed the border back into its country of origin.

Who knows what it had been doing for the last two years, but this stolen piece of equipment had obviously changed hands multiple times and it was now brought back in. The connection was still there and available and as soon as it reached a network it could get access to off it went connected.

Nick Earle:
Paul, the diggers is a good one. I had visions of a tracker, if you’re stealing a gold bullion truck, you need to drive as fast as possible to the border and then the police can’t track you. I think it’s a different image in my mind of a big digger lumbering its way to the border.

But I wanted to ask you a question on the data. Ian’s talked about the problems of economics. In fact, in previous podcasts we’ve talked about that disparity on the economics is actually four to one. The roamer gets 20% on average of the revenue. They definitely have a financial disincentive not to use long-term roaming, he’s talked about backhaul latency. We talked about because all the maps are proprietary, the operators don’t typically share their maps. You cross the border and suddenly bang, you’re not allowed to connect and whatever.

The issues of the data, it seems like for the IoT use case, getting hold of not just the connectivity but being able to monitor the networks and being able to get access to the network data is pretty important as well. Is there an issue here to do with as roaming scales you actually have less and less visibility on the core underlying data itself?

Paul Marshall:
I think that can be true depending on the platforms that you are using. Going right back to the very beginning of this story, one of the things we wanted to address was that if you build a device, we call them IoT devices now, the term hadn’t been coined in those days, but if you were sending data and it didn’t arrive on your server, you had no idea where to go to look for it. We said one of the most important things is actually to make sure that we’ve got the opportunity for both our technical staff and our customers to be able to look and see how is that data being routed, where is it being sent?

That meets multiple requirements, as well, I suppose. One of which is actually making sure the device is doing what you want it to do whilst it’s in deployment and whilst it’s in volume. Another is looking at the device during development, so that your development phase is much tighter and much more controlled. But I suppose the main one, really, is saying if you can’t see that data then you don’t really know what’s going on and what’s happening with it. Therefore, by putting those tools in, as you described, really helps people build those products better.

Ian Marsden:
But to add to that, it’s worth understanding, because of course we’re talking about global IoT, it’s really a conglomeration of networks being brought back together again. They’re all different. They all have different network components from different vendors. They all conform to a standard, but they all work different. To Paul’s point, you need tools to be able to diagnose those problems. That leads us onto a story where we were doing some work with the World Health Organization for cold chain monitoring across Tanzania, and the product was designed and built here and was working absolutely perfectly.

We then took it down to Tanzania to deploy. Of course, the network was different down there and it behaved in different ways. Out of the box, nothing worked. The good thing is we expected nothing to work and therefore we’ve taken all of the tools and components down there to do the testing to be able to spec it. But ultimately without those tools and the ability to do that, you’d just be sitting there going, “Well it doesn’t work.” I switch it on, thinking that the item is broken. It was really important for us and therefore for our customers to be able to provide them more information than “Good luck,” or “Try again,” and get that deeper visibility into the network.

Nick Earle:
People would say, and people do say all the time, “Okay, I get it that you talked about single IMSI and roaming and the issues, regulatory data sovereignty, latency, the financial disincentive, which drives a lot of behavior. And so they would say, well the answer of course is multi-IMSI, and multi-IMSI is going to do this. I solve this and I know that because obviously I know the company very well, talking about our own company, but Eseye has been a series of technical firsts and one of the technical first was the first company to introduce multi-IMSI. When we go back to the journey as part of the journey, and I can’t remember exactly when it was you guys did this maybe be 14 or 15, you started produced the first multi-IMSI multiple bootstraps on.

Ian Marsden:
I can’t remember.

Nick Earle:
Yeah, I think I saw it on a slide, multiple bootstraps in order to be able to do rotation remote SIM provisioning on multi-IMSI. Does multi-IMSI solve the problem or it solves some of the problem but not all of the problem? What would you say on that?

Ian Marsden:
Yeah, again, I’ll answer it in a number of ways. Obviously, there’s a number of problems that get solved by multi-IMSI and again, we’re going back to 2015, 2016, this is pre RSPs and remote SIM provisioning platforms and all of that. At that point, multi-IMSI was a method of going, “How do I solve what we alluded to as the roaming problem and get that percentage up?” But it also, of course, has the benefit of solving some of these technical problems around latency and stuff because you can then have more IMSIs that have different home networks and therefore one could be US-based and one could be European-based and therefore you can help with those aspects of it. This is leading towards localization, which is obviously where the industry’s heading from RSP type solutions. Absolutely, multi-IMSI was the next logical journey on that path for us. We’ve been doing it for a long time, yeah.

Nick Earle:
But you are saying that really localization, the ability to localize wherever possible is actually… I’m getting the impression of you’re saying the ability to localize wherever possible the device on a device by device basis would be the ideal solution if you could actually do it.

Ian Marsden:
Well, I think there’s two elements of where multi-IMSI or RSP comes in, and one of them is localization is where you’re saying, “I’m putting it on to a particular network.” That’s where you are solving that economic and regulatory challenge, which is how do you make sure that the person who’s delivering the service is getting recompensed correctly for it. Then there’s the technical challenges which multi-IMSI can do without necessarily being localization. It’s just changing it to a different route or a different solution. Multi-IMSI solves both, but if you’re looking at where the industry is heading and where the challenge is around network, the economic challenge, obviously the economic challenge is driving to what we see as access fees, and therefore how you deal with access fees is localization.

Nick Earle:
Right. Again, just to explain to listeners this disparity this four to one, you collect a dollar of currency, but when you roam, you only give 20% of it and data prices are coming down. Actually, you’re getting 20% of a declining number is causing people to say, “You can’t roam on my network for a longer period of time. You must localize,” but it’s not technically possible many cases to localize. Access fees are in effect an additional charge to roam onto their network for longer period of times. Paul, those access fees, they can be quite prohibitive, especially when considered in the light of the business case for a lot of customers, right?

Paul Marshall:
Yeah, I think a lot of the projects we work on, it comes down to the business case, which is actually how do people get the value from the connection? If suddenly you get access fees, which mean that there is a significant charge per month per device for paying for those access fees, all of a sudden that economic model of the product itself falls out the window. That really gives them challenges. This is, I think, just part of networks change over time. If I go back to my hardware days, I think when people are designing IoT hardware, they look at what radio access technology and when we think right back to the beginning we are thinking, “Did people put in a 2G modem or did they spend the extra on a 3G modem and was that really necessary?”

Of course, now as the technologies evolve, people are putting in either CAT-M1 or LTE modems or whatever they need, but that’s evolved. But what it shows is that when people install an IoT device, the installation time of that device, because we still have 2G devices in the field today working fine. The life of that device in the field can be 10-15 years.

Nick Earle:
10-15 years for a meter for example, is a long time.

Paul Marshall:
Exactly. Making sure the hardware can last that long and the radio access technology is going to be available is important. But also the other thing which is much harder, I think, to get a grasp on is to say, “Is the way the service is being delivered today going to be the right way for delivering that service in 15 years time?” I think that’s where the multi-IMSI that we pioneered really came in, because what it meant was that we could offer customers a SIM card with the opportunity to say, “If the way the network operators change their data model or their operating model or whatever changes over time, we will have the opportunity to switch to a new profile with a different network operator to continue to deliver service for the life of that device.”

I think that managing that risk and showing the route to keeping that risk managed was really important for a lot of customers and has proven the case. We have a lot of devices out today that are using IMSIs or profiles from network operators where that profile or that network operator wasn’t available to put on the card at the point the device was deployed and we’re now using it to deliver the service the same quality as they were expecting all along. Again, that’s really exciting, I think.

Nick Earle:
It is for us as an MVNO, I actually want to look at this from a completely different direction as an MNO, mobile network operator, because Ian, one interpretation of the challenges that we’ve talked about is that, “Well, you can only solve this as an MVNO, you’re abstracted, you sit above all the different MNOs and to some extent you’re agnostic.” The MNOs all have a, what’s known as a CMP, a connectivity management platform. We talked a lot about, well, you need globalization. Customers want globalization, they want more than the 80%, but the MNOs can only deliver the 80%. It seems like you need almost like a hybrid approach because the operators aren’t going to go away. They’re going to be major partners, they need to solve this problem, but they themselves are part of the problem. They can’t solve it. It seems like there’s a missing piece of the jigsaw, or put another way, how do you get the operators to join Eseye on this journey of everything that we talked about when they themselves are contributing because the proprietary nature of their IMSI and SIM, they’re contributing to the problem.

What’s the missing piece of the jigsaw?

Ian Marsden:
Yeah, so I’ll rephrase the question slightly because obviously in a way we go back in time because actually what the solution is because of access fees, you need to now decide which network you want to run on. You’re paying to be on that narrow, you’re now back down to arguably selecting the single IMSI. Now, you’re back down to having to talk to each individual operator, agree the tariff for them and run different platforms and different solutions for each. You’re going, “We haven’t really moved on in the world,” and then you say, “Well, okay, therefore I want, what I really need is a CMP and a solution provider that brings this world back together as a single pane of glass, a single management interface that allows me to, again, remove that problem, make it a solution under the hood.” But you still have the problem that, so you could do that at a API level where you just bring the CMP together and underlying use all the different operators interfaces, et cetera.

But, of course, what the customer actually still wants is that consistent experience with the debugging of the networks and operation of APNs and routing of traffic and costs of single pane of glass for billing and all of that stuff, which is where you kind of therefore need this hybrid approach between a CMP that’s bringing together all of these different operators, but also making a consistent service delivery layer that is then available to the customer on top of it. That’s really where we focus. You can see, hopefully, from the history we’ve outlined of how we’ve got here, that’s why we sit in this layer.

The benefit for that is that your question about where the MNOs sit, the MNOs at some point want to deliver what they can deliver well and get paid fairly for it, and ultimately don’t ask them to deliver something that isn’t core to them in their area. Really, what we see logically for that is bringing these group of MNOs that we partner with together in an equitable way as say a federation type relationship where actually it’s a symbiotic relationship where everybody wins doing what they’re good at.

Nick Earle:
The Federation, which we call the AnyNet Federation, which I’ve on multiple podcasts described as conceptually very similar to the formation of the Star Alliance in the airline industry because the airline industry was equally fragmented, it was equally frustrating. You couldn’t share infrastructure, you couldn’t share gates, you couldn’t share baggage systems, you couldn’t share payment systems. Then Star Alliance and others rose out of that to be able to sell you a global ticket and share everything. It was good for the airlines because as each airline sold tickets, they channelled and sent business to other airlines even though they were potentially competitors, in many cases, they were. That Star Alliance model, it seems like it not only enables with a single view as he says, single API, single portal the ability to do a single support, single billing, but it also is a more equitable model for sharing revenue than roaming. The aha is it’s not just a technical construct, it’s actually a more equitable revenue sharing model for operators to put traffic on each other’s network.

Ian Marsden:
For longevity. IoT is longevity, long lead times and long times in the build. Paul’s alluded to it, no devices on networks since 2009. The longevity is something that if it’s not equitable, you don’t get the longevity as a solution.

Nick Earle:
Right, right. Okay. That’s brought us up to date. Obviously, Eseye has a Federation currently 16 operators in our Star Alliance, more being added. Revenue is shared more equitably and we can deliver a global very, very high percentage global connectivity as a result. Paul, you are the device guy and I know a lot of device optimization happens around the firmware to be able to enable this magic, if you like, through the eSIM. Just briefly, Paul, in order for a SIM to actually be able to utilize the Federation and to be able to switch between either localization and/or roaming, what key challenges and problems you had to solve in order to make that possible?

Paul Marshall:
I suppose this is working with customers to make sure that the device isn’t… I’m going to say isn’t fighting the SIM card or isn’t fighting the way that we are managing the connection. It’s very easy for people developing IoT devices to get sucked into writing software which controls the modem in a particular way or a particularly tight way, which can then stop the management using the GSMA standards actually taking place. I can give some of the examples are, I suppose, real business as well as technical challenges. For example, if I think if a customer’s got a healthcare device which is battery operated, and one of the things that they wanted to do was make the battery last as long as possible, and so therefore they allowed the device a very short amount of time to try and connect the network and send the data, and if it failed, it would shut down.

Now, of course, what that meant was because it was only connected to the network for a very short period of time, even using our connectivity management platform and the triggers and everything else, there wasn’t time while the device was connected to allow the actual management of that connection. Therefore, things like using the GSMA RSP systems SGP.02 or using the multi-IMSI that we talked about earlier actually then became impossible because before the session was established to allow you to do that control, the device had pulled the power on the modem, and therefore we had to work with that manufacturer to say, “It will… Look how it’s not going to actually affect your battery life to allow it to stay on the network for longer because normally it will have connected anyway and therefore the extra time doesn’t matter. But by investing this little bit of extra time, allowing the device to register, that will allow us to do the management using the platform and therefore your device will see higher availability on the network.”

Those are the kinds of things that we work through the customers all the time, which is understanding what they’re trying to achieve and why they’ve put in place the tools to do it in that particular way in their device. Then working with them to say, “How can we optimize those so that they actually get the benefits of the managed connections?”

Nick Earle:
Okay, so it’s as much if not more to do with the device as it is with just the basic connectivity is a way of paraphrasing what you’ve just said?

Paul Marshall:
I think so. I looked in two ways, the delivering the connectivity, I always say our customers should be expecting as close to 100% as absolutely possible on that connectivity service and therefore the work and the investment that my team needs to do is look at the devices and say, “How can they maximally exploit that and actually get full value from that availability of that service and the different ways that it’s delivered?”

Nick Earle:
I want to pivot now, you mentioned SGP.O2, not everybody who listens to these podcasts is probably au fait with all of the acronyms, but essentially the standard for pushing an IMSI, an international mobile subscriber identity, into the device, and that’s the GSMA standard. There’s also a new GSMA standard not yet ratified, which is coming, which is a method where the device pulls the IMSI itself. It’s common in the consumer world, like in your Apple Watch or your Kindle, and it’s where it’s known as SGP.22, but in the IoT world it is going to be called SGP.32. Ian is SGP.32 the next big thing that’s coming and is it complimentary to everything that we’ve been talking about?

Ian Marsden:
Yes, it is the next thing that’s coming, because as you outlined, it’s being standardized at the moment and it has some technical benefits around how it delivers the profiles that make it probably more robust to deliver it and better, certainly, for some of the low power technologies and some of the, as we’re heading towards 5G, et cetera in there. There’s benefits in there. Is it complimentary? Well, as we’ve outlined, we run remote SIM provisioning, either multi-IMSI SGP.O2, SGP.22. To us it’s a complimentary, it’s another solution under the hood that we have to deliver and manage. It has different pros and cons. It is clearly something that is important to us and we will deliver it to customers. We have customers that are absolutely asking for it, but we still also have large bodies of customers that are using those other technologies, and therefore we have to maintain those as compatibility as solutions that are depending on the most appropriate nature for those customers.

It’s worth saying, obviously when we’re talking about availability of profiles, availability of different profiles from different operators are not always available on all of those systems. At some point you also have to look at what does the product do, how is it looking to be used to make sure that we’re picking the right and most appropriate technology for it? But in short, yes, SGP.32 is clearly a 2024 feature.

Nick Earle:
Right. Okay. I’d like to finish if I can with some words of advice from you. Here’s the scenario. You’ve talked about your journey from deciding to build a company, which you named Eseye, and some of the issues that you felt you had to be solved, problems needed to be addressed, and learnings that we got from customers on what it takes to deliver true global connectivity, not just technical learnings, but actually a business model innovation, which is the Star Alliance. If you don’t solve the underlying financial problem, the technology won’t work anyway.

By putting all those together into a solution as produced the Eseye that we have today. But I’m a customer say, and I’m starting out on an IoT project, I’ve listened to all of this and thought, “Wow, I didn’t realize there was so much I had to know about it, but I’m doing my research and I’m glad to know that Eseye is one of the companies that solved a lot of these issues.” What advice could you give me? What’s the one piece of advice you could each give me to finish off the podcast of what I should do, what I should focus on for my IoT project that I’ve been tasked with? Ian, I’m going to come to you first.

Ian Marsden:
Yeah, so it’s one of the reasons I love what we do is because ultimately we get to see a lot of opportunities, a lot of different businesses that are trying to use IoT to deliver services, et cetera, out to their market. I find that absolutely fascinating. But one of them, to that, to your point, I suppose the most important thing is there’s lots of stuff you could do with IoT, but you really have to boil it down to say, “What is the value in that IoT product? What is the business case that makes that economically makes sense?” Because that’s the thing that everything else can get built upon, but it holds it all together. If that underlying business case doesn’t hold water, you’re going to have a chat.

Nick Earle:
Okay, so the CTO says it’s not the technology, it’s the underlying business case. Okay. Paul is the device guy. Are you going to tell me that it’s not the device, it’s something else?

Paul Marshall:
Well, actually I think the first point is exactly the one you made, which is it’s about the business case. If the business case doesn’t stack up, the project is going to fail. But the other reason I think people often struggle is it is all about the device. Actually, we can deliver really good connectivity, really reliable connectivity. We’ve got the tools in place to allow us to examine and look at how that connection is being established, the data that’s flowing through it. But if the device itself can’t create the scenario where it’s able to connect and it’s able to maintain that connection, and whether that’s using a prebuilt software modules like AnyNet SMARTconnect, for example, that we produce or using bespoke tested software that customers have done themselves, if they haven’t got that device absolutely right, they’re going to struggle.

I’m going to repeat, it is all about how getting that device, right, whether it’s making sure the power supply is right, so that it works in all cases, whether it’s making sure that you’ve tested it in unusual scenarios and it recovers because things do happen to devices out in the field and it’s an IoT device. There isn’t anybody to sit there and press the reset button. It’s got to sort itself out. It’s all about the device and the software in it.

Nick Earle:
There we go. All right, well why don’t we leave it there. You guys should be very proud of what you’ve started and built with some help from some more people along the way. As we know now, we are a company with just under a thousand customers and some of the biggest companies in the world like Amazon and Shell, Coca-Cola, and Sony, and devices in every country in the world. Paul, I’d be remiss if I didn’t finish by just re-emphasizing something you said very quickly, but it’s very important. We talked about the lack of connectivity in the 80% and et cetera, et cetera. Then you just dropped into the conversation and “Oh, and by the way, we deliver 99.5% of connectivity globally.” I just wanted to shine a light back on that because at the end of the day, I think that’s the litmus test, which is never mind what you say you can do, what are you prepared to sign up for and what do you actually deliver in practice?

Because a 1% of connectivity makes a big difference to that use case that you said, Ian. Certainly 80% kills your use case, which is where we started the podcast. I want to say thanks for being my in-house guests on IoT leaders. I’m sure all the employees will be some of the first ones to listen to this one. Thanks to you, the listeners as always, for listening to it. I hope you enjoyed this unusual episode. It’s actually our 40th edition of the podcast. Ian and Paul, thanks very much for joining me on the IoT Leaders Podcast.

Paul Marshall:
Thank you, Nick.

Ian Marsden:
Thanks very much.

Outro:
You’ve been listening to IoT Leaders, featuring digitization leadership on the front lines of IoT. Our vision for this podcast is to be your guide to IoT and digital disruption, helping you to plot the right route to success. We hope today’s lessons, stories, strategies, and insights have changed your vision of IoT. Let us know how we’re doing by subscribing, rating, reviewing, and recommending us. Thanks for listening. Until next time.