What Enterprises Need to Know About SGP.32

SGP.32 is the latest standard from the GSM Association (GSMA) set to change connectivity and deployment in the world of IoT. 

But is it the holy grail everyone’s been waiting for?

Not so fast, says longtime IoT Leaders contributor and Transforma Insights Founding Partner Matt Hatton.

In this episode of the IoT Leaders Podcast we discuss what SGP.32 is (and isn’t), what the standard is capable of and where SGP.32 is likely to go.

Listen to the podcast to find out:

1. Why SGP.32 is making waves in the world of IoT 
2. What enterprises need to be aware of about those claiming they have SGP.32-based solutions available now
3. The role managed service providers (MSPs) play in global connectivity

Tune in to learn how SGP.32 will be the dominant standard in the world of IoT.

Subscribe to IoT Leaders

Subscribe now

Subscribe now

Subscribe now

IoT Explained

SGP.32 – Remote SIM Provisioning for IoT

Learn more

Blogs

Is SGP.31/32 the solution to all IoT connectivity problems?

Learn more

Whitepapers

Adopting SGP.32: What Enterprises Need to Know

Learn more

Blogs

Future Proofed, Market First SGP.32 eSIM Platform Paves Way for Billions of New IoT Activations

Learn more

Transcript

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, the CEO of Eseye. And welcome to this episode of IoT Leaders Podcast. This is an unusual one. Today we’re talking about SGP.32, yet another acronym from the telecom industry. But in this case, it’s one that is actually pretty important to a lot of people. There’s a lot of people asking questions about SGP.32. “Is it the holy grail? Does this solve all the issues I’ve had with my IoT deployment?” There’s a lot of startups who are building next generation MVNOs around SGP.32 and there’s a lot of companies who are experimenting. So what we decided to do is to really help people understand what it is, what it isn’t. What it’s capable of, what it’s not capable of, where it is, and where it’s likely to go. And advice on how to move forward and do the assessment because we know that, eventually, it’s going to be hugely important.

But the fact is, as you’ll hear in the podcast, from Matt Hatton who runs Transforma Insights, a frequent guest on this podcast. And as you’ll hear, the hype in this case has definitely got ahead of the reality. So this is a bit of a reality check in terms of what’s there. And if you really don’t know what SGP.32 is and you think, “I need to get myself educated because people are asking me internally,” then this podcast, hopefully, will be helpful for that.

All of this, as you’ll hear at the beginning when we get going, is available as a white paper on our website. You just search for SGP.32 and you’ll find the white paper that this IoT Leaders Podcast is based on. So with that, let’s get going and I’ll introduce my guest, Matt Hatton, who’s the founder of Transforma Insights. One of the leading research firms in the IoT space. Here we go.

Matt, welcome to the IoT Leaders Podcast again.

Matt Hatton:

Thank you. Delighted to be here. I think I was wearing a rather less conservative shirt when I was on last –

Nick Earle:

Hey. Listen to this, so most people will bemused by that comment, but some people do watch the YouTube video and so I can explain it to everyone. Yes. I remember being startled myself. You seem to have a very exotic-golfing shirt on or you were-

… feeling particularly adventurous that day or something. I don’t know.

Matt Hatton:

Wasn’t deliberate. It must’ve been in the middle of the summer. It’s the middle of the summer now, but I don’t think we’ve got anything to be too-

Nick Earle:

No. Not with the weather that we’ve got in the UK right now. So let’s get back to the… Okay. So listen, there will be some people who know exactly who you are and you’re standing in the industry. But there will be some people saying, “Who is this Matt Hatton guy and who are at Transforma?” So let’s start off with the basics. And just introduce yourself and your company to the listeners, to the podcast.

Matt Hatton:

Of course. I can. Happy to do that. Matt Hatton, I’m one of the founding partners here at Transforma Insights. We’re a boutique research and consulting firm. You could describe us as… Majority of what we do is focus on the internet of things. We look at some other disruptive technologies as well, AI and blockchain and a few other things, but probably 80% of what we do is IoT. And within that, my particular focus is on all things related to connectivity. So whether that’s access network technologies or what the communication service providers are doing or devices or indeed, things to do with remote SIM provisioning and [inaudible 00:04:08] such topics.

Nick Earle:

Which is where we’re going to go.

Matt Hatton:

Exactly. A neat little segue into-

Nick Earle:

A neat little segue. I was telling Matt before the recording on the podcast that we have sponsored a white paper which has been written by Matt on today’s subject, which is SGP.32. And I was saying that I put out a LinkedIn post, and I got between three and four times the number of views I normally get, my LinkedIn post. So clearly, this is a subject that has got great interest and people were really interested in this topic. So before we start here and get into it, everything that we’re going to be talking about on this is actually in a white paper that was sponsored by Eseye, written by Matt.

And it’s part of Transforma’s series of Transforma Transition Topics. If you go to Eseye.com, E-S-E-Y-E.com, and just hit search and then type in SGP.32. And you’ll get the Transforma Insights white paper, which goes into a lot more detail on what we’re about to talk about. So we know there’s a lot of confusion that will be a theme of this podcast. There’s certainly a lot of confusion.

There’s people making mistakes and there’s people over promising, significantly in some cases. So we’re going to try and uncouple that and get to the recommendations. So let’s start at the beginning. And Matt, can you… Just to briefly get us going, what is SGP.32? I know it was announced in May, 2023, but what is it?

Matt Hatton:

Yes, happy to talk through that. As a little prelude to that, it did send me thinking, just as you were doing that intro, that there’s normally this maxim that people buy services rather than buying technologies or people don’t buy technology, they buy what that technology can do for them. But it’s quite notable, you don’t get a much more obscure technical term than SGP.32, which isn’t entirely transparent in terms of what it is and what it might do. And I use the phrase advisedly, and I’m sure you’ve seen the same thing. We’ve had a lot of enterprises hearing about this technology, seeing it’s becoming available. And being very interested in what it can do for them in terms of their global cellular-based IoT connectivity deployments.

And so in a way, it’s one of the instances where the technology has got ahead of things, which is pretty interesting to see. But let’s take it back in the midst of time, about 10 years ago. There was really no way to change the SIM profile on the device other than switching out a plastic SIM. And then let me just note that I’m going to have to go through a few processes along the way before I get onto talking about what 32 is because there’s a bit of a windy path.

Nick Earle:

It’s a journey here that we need to map out. Yeah.

Matt Hatton:

Yeah. Exactly. A bit of a windy path to get to 32. But anyway, so you start with the fact that, as of around about 2015, you started to get embedded SIMs sold, and SIM cards, machine form factor SIM cards being put into devices, which were very useful because they were much more robust, much more secure. You can have people stealing them not quite as easily, although it’s still possible.

So effectively, that SIM element was soldered into the device, great for coping with extremes of temperature and vibration and so on. So much more appropriate for IoT deployments. Problem with that, of course, is how do you move operators? How do you change operators if the SIM has been soldered into the device? You have to introduce a mechanism for doing that. And the mechanism for doing that is something called remote SIM provisioning.

And as a part of that process of introducing remote SIM provisioning, the GSM Association developed a series of standards under the umbrella of SGP, the first being SGP.2, that was the M2M standard for remote SIM provisioning. That one was in 2014. Then we saw SGP.22, which was the consumer variant, which came out in 2016. And then the SGP.32 variant, which is what’s termed [inaudible 00:08:28]. It came out last year. Initially, the first specifications came out last year.

But we’ll get on to discuss something around the timing in a little bit. So effectively, you’ve got three standards. There’s three standards that were introduced or in the process of being introduced. But the first one, SGP.2, was based on a profile, an eSIM profile being pushed by a service provider to the device. So it requires the integration of the donor, provider and the recipient provider, so that the credentials can be handed over between the two, effectively agreeing to migrate that device from operator A to operator B.

The consumer variant SGP.22, which followed it, is a pull variant. The user can say, “I want to pull a profile from whichever my chosen provider is,” rather than relying on the existing provider to send it. So they can pull it themselves, they have increased freedom to do that. But what was realized was that the SGP.2 variant was a little bit clunky and the SGP.22 one was really only appropriate for consumer devices because SGP.22 needed an advanced user interface.

There was some limitations in terms of what technologies it would work with. It needed SMS, for instance. And so it was decided that what was really needed was an enhancement on SGP.22 to make it appropriate for IoT. So you put an agent onto the device, the IPA, the IoT profile assistant-

Nick Earle:

Yeah. I think it is. I think it is, yeah.

Matt Hatton:

I’m missing a word out there, but it’s one of those jumbled acronyms again. And that acts effectively as if it was the user, so selecting to pull down the profile from whichever was the chosen provider. So that’s how SGP.32 works. It’s a very brief version of how SGP.32 works. It represents quite an improvement on both of the previous standards. So we’ve had some people describing it as third-time lucky for these remote SIM provisioning standards, in as much as 02 required agreement and cooperation and integration between the two carriers. So it was a bit clunky.

22 required the user actually to be present and taking photos of QR codes or whatever. Whereas 32 allowed that all to be done remotely. It also supported lightweight protocols. There wasn’t a requirement for SMS and the footprint of the LPA was much reduced, because actually part of it had been taken off the device. So it’s a lighter weight standard than the two that had come before, which is obviously good in constrained deployments. So there we go.

Nick Earle:

That was nice explanation. As we said at the beginning, a complicated subject. And if I can, I give the view of Eseye as a managed-service provider in the IoT space with a lot of global customers. Customers…, If you’re in IoT, you know what the issues are in terms of being locked into an operator. Multi-IMSI roaming gave them some freedom but not complete freedom. And so SGP.32 on the surface sounds, as you say, third-time lucky. “Wow, this is great. You mean my SIM can now basically connect to anybody because if it’s an industry standard, everyone will adopt it? I can connect to anybody and actually I now have full freedom and therefore full connectivity and therefore everything will now work. And all those issues that have held back IoT adoption are going to go away.”

And in fact, what we’ve also found is that… And we’ll get into the fact of whether the standard is actually there yet. But SGP.32, there are early versions and the standard [inaudible 00:12:26] publicized. There are a lot of people who have got some very slick demos and they will show you, “Look, here’s the SIM connected to operator A, drop-down menu, which one would you like?” Click. “Oh, look, here’s the SIM connected to operator B, why don’t you have a go? You see it shows.” Oh, click. “Oh, suddenly freedom. I can do whatever I want.”

And it looks great, and the demo looks very slick. And we all know in the industry… And I’d like you to comment on this, that ultimately if you… Look, SGP.32 will clearly be the dominant RSP, remote SIM provisioning methodology. But the point about this podcast is around the realities of what’s required right now and the recommendations on how to go forward.

Because at the moment there’s a big difference, isn’t there, Matt? Between the demo and the promise and what customers are actually seeing. Even though we think that ultimately this will become the majority way in which devices will be connected.

Matt Hatton:

Yes, completely. So my comments about it being great, I would stand by it is an improvement in many ways on the other standards that came before solving some of the issues that came from those. And as you say, it will become the dominant standard, not exclusively. There are many scenarios where, actually, some of the other alternative technologies might be more appropriate. I think probably, connected-car makers will probably be perfectly happy with SGP.2 still working as their chosen form. Many consumer devices will be happy with 22. But we think that of the… We’ve done some calculations, we published a report last year where we looked at the total opportunity associated with this remote SIM provision. And we came up with a figure of 2.3 billion IoT cellular-connected devices will be remote SIM provisioning capable by 2032.

And the majority of those will be SGP.32. Dominant technology in the field, certainly. But there are a couple of fairly healthy buts that we need to think about. One is about timing. As you say, this technology actually isn’t available today. Okay. The standards were more or less finalized last year. There was some work to be done on certification. There’s still a few things to be ratified, and effectively, we are not expecting devices in full SGP.32 capability to be around until probably early next year.

So if anybody is putting in front of you a SGP.32 offering and you’re not listening to this sometime deep into 2025, by the way, which I’m sure you’ve got a lot of people who go back through the-

Nick Earle:

Yeah, there are. There’s a long tail. Which is a long tail of this thing. Yeah.

Matt Hatton:

Yeah. Exactly. I’ve listened back to the repertoire. So if you’re not listening to it deep into 2025, the chances are what you’re being presented with is effectively a pre-standard SGP.32, which is simply SGP.22 with some additional elements. Now, it probably does work in more or less the same way as SGP.32, but without that interoperability and actually removing the one key big benefit of 32. Which is the ability to move between any operator because it’s based on the standard. So effectively, you’re more or less tying yourself into a non-standard approach, although one where there’s likely to be an evolution path. But just to set a reality check on that to say it is not available today. And what you’re getting is not quite SGP.32.

Nick Earle:

32. It’s 22 with the skin. And I mentioned… And we’re going to go through I think seven points. Again, we’re saying that we know eventually we’re all going to get there, but this is about helping people and not make mistakes. And as I said, we have several customers who have said, “Oh my word, I’ve gone too fast, too early,” and then had to start again. This first one actually, is the demo point, isn’t it? Is that… And if people think we listened to this at the picture of a iceberg, this is a bit above the water, which I call the demo.

It looks great, and the demo is actually 22 with a skin on it. And it looks absolutely wonderful, but the reality is it’s not there yet and it’s not full 32. So caveat emptor, buyer beware. There’s a few more questions you need to ask when considering it. And as you said, the standard, the GSMA standard is not fully ratified yet, so there’s always a bit of a risk there. So it’s not an either, or, is it? Because what you seem to be saying is that both are going to… Just as two exist today, three will exist in the future. And for IoT devices, well, SGP.2 or SGP.02 is the dominant form RSP today, and 32 is coming along. It seems like what you’re saying is whatever happens, it will be a managed transition, Matt?

Matt Hatton:

Yes. There’s a few aspects to this. One is, it may be that SGP.32 isn’t actually the most appropriate technology for you to use as a buyer of connectivity, right?

Nick Earle:

Right.

Matt Hatton:

Maybe SGP.2 is more appropriate. Maybe a multi MC approach, maybe a single MCCM. If you’re only deploying in one country, maybe you don’t need this technology. So probably the best approach is find somebody who can sort you out with whichever is the most appropriate technology to use rather than assuming that this is a universal panacea that’s going to solve every issue. There’s another topic… It’s several other topics related to this, it being a managed service, is it might offer companies the opportunity to take their connectivity from whoever they like.

But are you realistically going to go out and negotiate the connectivity arrangements with dozens of different carriers? Maybe some companies will.

Nick Earle:

They won’t.

Matt Hatton:

No. I suspect most won’t. The car makers probably would, most others probably wouldn’t. And so most naturally, you will want somebody to handle that relationship or that negotiating approach for you. There are other things going on in the background as well. So simply switching the network operator is only part of the process of how you manage the connections.

If you switch from operator A to operator B, can you be sure that your SLAs will still be comparable? Are you sure that your APN settings have all been done properly? Are you sure that your local breakout is happening in the way that you want it to? And so simply which eSIM profile that happens to be on the device is only part of the requirement. So there’s the zone aspect, and there’s also the time aspect that we’ve alluded to during the conversation already, whereby 32 might not be available today. And so you might be implementing something which maybe it’s a pre-standard one, maybe it’s SGP.2, maybe it’s a Multi-IMSI approach.

But at some point, you probably want to evolve to SGP.32, if that’s appropriate. And having somebody to help you manage that process of evolving from one to another is obviously an important thing as well. And I probably missed something there, Nick, but thats-

Nick Earle:

Well, I was going to say, I was actually going to bring it to the APNs because we’ve certainly had some cases where people have gone early. And full disclosure, we’re a managed service provider that offers SGP.2, SGP.22, SGP.32 and a managed transition, but we’ll get back to that. So we’re offering the full range, but people have gone pure and then we’ve said, “Oh, hold on a second, back to the iceberg. The APN seems to keep on changing.” And maybe you can comment just briefly on that because one of the things under the water level is that, as you said, it’s not just about whether it’s push or pull from the profile into the SIM that’s above the water level. But you’ve also got to make sure that everything else in the infrastructure works.

And one of the critical components is the APNs got to be consistent when it switches. And another one, if I can give you two to comment on, and I guess you’ve also got to be sure that the operator that you were on knows that you’ve left so that they don’t continue billing you.

Matt Hatton:

This is an interesting one. So second one first, we work with a lot of telcos and one of the things that actually has come up quite recently is how do you deal with that? The fact that there is no mechanism for alerting or no… Sorry, no requirement for a mechanism-

Nick Earle:

A standard.

Matt Hatton:

… to alert the donor, provider. So you might be moving your connections off operator A onto operator B, but you also need to send them a letter and say, “I want to cancel my contract. I need these connections,” and so on. So there’s a bit of a logistics exercise involved in that. It doesn’t apply with SGP.2, and incidentally, I think there’s a notification process. There has to be a notification process because it’s a two-way handover. So that does complicate things a little, should we say. But the APN setting… Not much to add to what you said, and not just APNs really, there’s all sorts of things that you need to ensure work in the background where the data flows are happening, where you’re making sure you are compliant with the requirements in any given territory.

The things, I mentioned, to do with SLAs and security and so on. Really, as you say, the eSIM profile is just the tip of the iceberg as far as the connected device and the getting data from point A to point B is concerned. And increasingly, we have this conversation with a lot of connectivity providers. You can’t just think about it as the IoT connectivity. It is the concept, really, of device to cloud. So taking data from a device and delivering it to the cloud in a seamless way as possible and compliant. I’ll throw that one in as well.

And this is that evolution in microcosm. The connectivity piece is the eSIM profile, but there’s a whole bunch of other things that sit around in terms of effectively providing device to cloud. Whether that be APNs or whether that be security or whether that be local data breakout or whatever, that need to be set appropriately for their deployment.

Nick Earle:

Yeah. And that’s going to bring us into shining a bit of a dull light on it at the moment. But there is a path, there will be a bright-light version coming here. But one last thing I’d toss onto the table is that what we see at least, is that people saying, “I’m going…” We say, “Why do you want to go SGP.32 now as opposed to a managed transition?” And one of the things that they say is, “Oh, because I’m going to save money. I’m going to save money with this.” I think you’ve come across that as well. And we’re not sure that’s actually true, are we?

Matt Hatton:

No. Who has the best negotiating power with network operators? Is it an individual company on their own, trying to negotiate for connectivity for 20 different countries with different providers? Or is it a connectivity provider, MVNO or MNO? It’s not. It doesn’t necessarily have to be an MVNO. Companies who negotiate for connectivity for millions of devices are invariably going to be able to secure a more price-effective solution, should we say. There are some exceptions.

I mean, if you are doing millions of devices in a given market, if you’re doing a smart-meter rollout, for instance, okay, you can probably go direct to the carriers and you can probably get a pretty decent deal, and so you may want to eliminate a middleman, say. But if what you want is 10,000 connections or 100,000 connections globally-

Nick Earle:

You don’t have the negotiation leverage.

Matt Hatton:

You don’t.

Nick Earle:

… just because you’re using one RSP tool. Okay. So we talked about the buyer beware, but we’ve also said that, “Look, this is an improvement and it will, we believe ultimately, become the main one. Not the only one, but the main one.” But key to that, I think is the next stage I’d like to go to in this discussion, which if you’re following along, is also in the report. It’s under the title SGP.32 as part of a portfolio of managed connectivity. So I think what… Could you talk about the fact that… And you’ve already mentioned it, that the way to do this is… You’ve used the phrase, a managed transition, you’ve used as part of a managed service. So what is your recommendation from Transforma, of the way customers should go about both evaluating and experimenting, with this exciting standard?

Matt Hatton:

When the standard came out, the expectation was that maybe it allows enterprises full freedom to switch between their carriers of choice and away they go. And that always raised a few red flags with me, with the question being, if I were to put myself in the boots of an enterprise, can I do this myself? Would I want to operate the infrastructure, the SMDP plus the EIM, to throw in a couple more tasty acronyms into the discussion? Can I do, what I discussed earlier or what we discussed earlier, all the negotiation of connectivity contracts? Am I going to handle all of the back office integration, the APN settings, all of that, all that sort of stuff? Will I want to do that myself? And I think the conclusion was, and there were always some exceptions, for the most part, probably no.

Which means that what you need to do is find somebody to provide that to you as a managed service. And this is not any different from, really, connectivity as it’s been provided up until now, typically as a managed service. If you wanted to as an IoT customer, you could set yourself up as your own MVNO. But precious few have chosen to do that in any way because it’s complicated and probably you don’t have the contract, the negotiating muscle that others would. And inevitably, I think we hone in on this idea of it being a managed service, somebody interjecting themselves between the enterprise customer and the networks. And that might be network operator or it might be [inaudible 00:27:06] providing that managed service to ensure all of those pieces for the customer are done for them because it’s a specialist role.

It’s not really one that enterprise customers have shown much interest or capacity for doing in most cases, up until now. So it’s going to be a managed service. And that topic of managed transition is really related to the fact that 32 is not available yet, and so you’ll be using something else before you’re using 32. And so you want to manage that transition from one to another. And that again, points to working with some sort of a managed-service provider type company.

Nick Earle:

With experience on 02. And one of the interesting things about when new standards come along is that, you get a lot of innovation and you get a lot of startups. And certainly, we’ve noticed. And you do a very good analysis of the overall landscape for IoT as part of Transforma, me giving you a plug now.

Matt Hatton:

Thank you.

Nick Earle:

Services that you offer, you’ve just released it. We’re very pleased with our position in your chart. But there’s a ton of new entrants and certainly we’ve seen an increase in the last, I would say, year, 18 months since the SGP.32 was clearly going to be coming out. There’s been a lot of startups, and I would call them pure SGP.32 startups. So people who have just said, “I’m going to start from scratch and build an IoT MVNO, next generation MVNO, I’m not going to deal with any of this legacy stuff. It’s complicated. I’m going to offer 32, 32 only.”

And they’re the types of companies where I was referring to earlier, that we’ve seen some people go with that. And then, well, almost exclusively hit the brakes when some of these below the water line iceberg issues came up. So yeah, on this point about managed transition, is your point, and I think it is, that it’s a managed-service provider, either MVNO or MNO that has the capability of both SGP.02 and future capability and expertise around 32? As a managed service where the things like the portal, the user experience, everything stays… Like the swan on top of the water, I’m using another aquatic analogy, that above the water stays the same, whereas below the water it might be 02, 32.

But the key thing is you’ve got to, as a managed-service provider, have the ability for both because of what we’ve said about it not being available. And at the same time, you’ve got to present it, not as two solutions but as one solution to the user.

Matt Hatton:

I think that’s right, and certainly for now. Okay. And you made the point right at the start of the podcast, that what we’re interested in discussing is the here and now, reality check with here and now. And the reality is, it’s not as a technology, actually available. Today, you need some roadmap for evolution to it and you need a portfolio of offerings. And actually more broadly in the long term, we may find or we’re likely to find that there’s a number of ways in which IoT and IoT solution might be deployed at, where 32 isn’t the appropriate one.

So why limit yourself to just one technology? Quite how things are going to play out in the commercial models that the dominator’s still, I think, somewhat to be confirmed. Because of many of the reasons that I’ve stated up until now to do with the negotiating power, the fact that there’s a whole lot of other things to manage than just the eSIM profile and a bunch of other things around that.

We don’t expect it, necessarily, to radically upset the status quo in terms of who you would go to, what kind of services they might be able to provide to you, how they would… But maybe slightly in terms of how they would do that, because I think more profile localization rather than roaming. But I think in terms of what’s visible to the customer, it may not be that apparent that there’s been that much of a change. Because one of the obligations of the connectivity providers will be to abstract the complexity out of that.

If you are localizing on somebody else’s network, you still need the management and control that comes with what would historically be managing on your own core network. But all of that is possible. And so what we see, there’s a lot of moves to abstract that complexity and mean that whoever the connectivity providers are, are able to deliver effectively a seamless set of capabilities. But using 32 where it’s appropriate to do and, for instance, for compliance reasons where it might be necessary.

Nick Earle:

As we draw it to a conclusion, you started the podcast with an interesting… It’s all been interesting, but a very interesting one at the beginning in particular. Where you said, “Normally in technology, we always try and say, ‘Look, forget the technology itself. Forget the standards. Let’s concentrate on the business use case. Let’s concentrate on the value. What does it do for customers?’ We should hide this complexity. Why do customers even need to care about this obscure acronyms? We’ve got enough acronyms.”

And then of course… And we said, “Unfortunately, right now we do need to explain it because everyone’s really interested. There’s a huge amount of interest. We get asked about it all the time, hence the white paper.” And I talked about 3X the LinkedIn views, if you just talk about it as a subject, I’m sure that’s the case for everybody.

But really, at the end of the day, success is when it fades back into the background. From our point of view, the customers shouldn’t have to almost know or care about this. The fact is that, providing you have full-agnostic choice and as near as possible, 100% connectivity, and as you say, “Connectivity is only a component of device to cloud because that’s what you really want, is device to cloud.” Why do you actually really need to care? So in an ideal world, we would say, “We’ll decide whether we use 02 2032, whatever comes out in the future. That’s the swan’s legs below the water. Don’t worry about it.”

But it has been one of those things that comes along every now and again when suddenly everybody gets very excited about a technology and an acronym. And you go to the event, there are huge conference streams and talks and startups who are saying, “This is the new way.”

I think, personally, that’s probably a reflection of the frustration of IoT. We’ve talked in many podcasts about predictions. You and I have talked about it in previous podcasts that we thought there was going to be 50 billion by 2020. Turns out there was 11 billion. There’s a lot of frustration. It’s all too complex, it’s too proprietary. If only there was something that could take away this complexity. And I think a lot of people have thought, “Oh, this is it. It’s coming. It’s from GSMA, so it’s going to be great.” And as you said, “It will definitely make things better.” It is making things better already. We’re doing SGP.32 implementations, pre-standard implementations right now. They will get better. The complexity will go away, but it’s not a switch that you can just press and suddenly everything becomes interoperable and easy to use.

Matt Hatton:

Not a magic wand, is how I’ve described it.

Nick Earle:

Yes, it’s not a magic wand. And again, that’s the reason for the white paper and the podcast. We’re just saying, be aware, experiment by all means, choose a provider. Obviously, we’d like that to be us, but if not us, choose a provider who understands these issues and can hold your hand. And make sure you don’t run too far down a road that might be a blind alley and keep tuned in. Because as the standard gets ratified and a lot of these issues that people perhaps hadn’t thought of, they will get resolved. My favorite one is that one that you quoted. Talk about an unexpected consequence. There’s no requirement in the standard for 32. Unlike 22 consumer, there’s no requirement for the current operator to be notified that you’ve left. So if I switch my mobile phone from Vodafone to, I don’t know, 02, I have to go to the shop, it’s a bit of a pain in the butt, actually, to do it.

It takes 24 hours. I have to get this PUK code and I have to wait until it’s been initiated and then suddenly I’m on 02, not Vodafone or whatever. But the fact is, I do know my contract has terminated with Vodafone. I’m not going to be paying from the moment that PUK code has been initialized. But if you have 10,000 devices and there’s no… Or a 100,000 devices or even 1,000 devices and your managed service provider doesn’t think that’s part of their value added services to do all the notifications and sort out the APNs and the whatever. You can imagine an awful lot of billing disputes where people say, “Why am I still getting billed?” And people say, “Because I can’t tell you’re not there anymore. I just know I’ve got a contract.”

It’s a lot of wrinkles which could cause a lot of issues. And as always, be careful of it and deal with people with experience and look for a managed transition from a managed-services provider. I think that’s the… Make sure that you’ve got risk mitigation built into your plans, would be my summary.

Matt Hatton:

I think so. But we should… It is worth also stressing, this is a great technology. It’s an incredibly useful tool, should we say in the right hands?

Nick Earle:

I’ll go for inexperienced hands. Absolutely. Great technology. We’re embracing it. We’ve built in the backend capabilities to offer it and we’re working on projects today. But yeah, experienced hands, great potential, and anything that takes away the proprietary nature of IoT, which has been a subject of probably every one of the 47, I think it is, podcasts that we’ve done here so far. It can only be a good thing. So this is a big leap forward for the industry as a whole. And all available, Matt, in your white paper that’s on our website.

Matt Hatton:

Yeah. I’m sure there’s several items that we didn’t even get to that are all mapped out in the report, but yes. Thoroughly recommend taking a look at that.

Nick Earle:

Yeah. Matt, let’s leave it there. Thanks very much. Again, this has been a special episode just because of the demand. People have been asking for this, so hopefully we’ve done it justice. You know where to get more information. I’m pretty sure we’ll come back to this subject in the future given what’s happening. But in the meantime, thanks very much, and as I say, I’ll get the plug back to you.

There’s a whole plethora of white papers and capabilities on Transforma’s website. You are a global analyst. We should point that out for both Brits, but I know that in my dealings with US operators, they all subscribe to you and follow you. So you are a global analyst in this space. Your insight and experience is very much appreciated. And I’m sure that’s the case for people listening to this podcast. So thanks again, and let’s see whether or not we need to do a repeat on this one a bit later on to see how things have matured and improved.

Matt Hatton:

Six months down the line, and we’ll see how it’s going. Actually, no, maybe 12 months-

Nick Earle:

I was going to say, six months that’s a bit optimistic-

Matt Hatton:

Give ourselves to 2025. And then we’ll see how it-

Nick Earle:

We’re talking telecom, six months is probably too optimistic. Thanks, Matt. And thanks to all of you for listening to this episode of the IoT Leaders Podcast.

Matt Hatton:

Thanks, Nick.

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.

Resources