SGP.32 Without the Hype

Hello everybody, thank you for joining us today. We've got a hot topic for you today which is SGP.32 without the hype. So we've got 45 minutes allocated for this and the majority of the time is going to be around Q&A. So prior to the webinar throughout the promotion we've been asking you all if you have any questions. So we've got quite a lot of questions that have been submitted and there's also the opportunity during the webinar itself to submit some more live. Before we get started I just wanted to go through a few housekeeping items. So we have some resources available via the interface you can download. There's the ability via the Q&A tab to submit any questions which will go through to our speakers. And as soon as the event has finished you will get an on demand link where you can watch the event as well. So I'd like to introduce our speakers for today. We have Paul Marshall, who's our CCO and Co Founder here at Eseye, and Marco Parmigiani, our Solutions Architect Director. So there are subject matter experts on the topic today and I will hand over to them. Thanks John and good afternoon everybody. So the first topic here is what is SGP.32? In a simple way, it's the newest SIM standard for IoT devices to load a new profile on a SIM card. That's it in simple terms, it makes remote profile management and profile switching really a reality. At its core, you know, SGP.32 allows a seamless architecture to allow you to manage the SIM profile from a number of different providers. You have a bucket of profiles and you're able to send them to your SIM card. So one platform where you can send multiple profiles to the SIM card. So at scale, it means you're not locked into a single provider. And it allows you to give you that full life cycle. And we've all experienced, even with our mobile phones and swapping SIM cards or whatever, it eliminates that element as well. So it's a true sort of independence providing those multiple MNOs down to a SIM card. As deployment expands into new regions, then you can add new operators or MNOs seamlessly to the SIM card. The beauty of SGP.32, it gets initiated from the device or the SIM card. So even with the low power WAN, NB IoT or CAT M1 devices, new profiles can be sent down to the devices. So it's an easy way of upgrading your SIM card to have new profiles in a seamless way. So that is SGP.32. Handing over to Paul. What actually matters? Paul? Thanks very much. So I think probably this is for me, this is the key for why SGP.32 really starts to become interesting for people developing IoT products, which is why does it matter and what does it allow us to do that we couldn't do in the past? And to look at that, I was looking really at some of the things that our customers and developers using IoT are actually struggling with, and the issues they're actually wrestling with day to day trying to deliver reliable IoT products. And of course, the first thing people ask about is long term, which is if you're deploying an IoT device, then it's really important to know that device is going to last in the field, last with customers long enough to get a return on investment. And therefore, that device has to have long term durability. And therefore, people are really concerned to say, is my device going to be working not just in one year or five years, but is it going to be working in ten years, maybe fifteen years time? And actually, these are the things that are really important. And the question there is, is SGP.32 actually going to be something that can help us here? Or is actually this something where we need to look at the modem technologies and making sure that we're developing devices correctly? And I think there's probably a combination of the two, which is to say that SGP.32 will allow us to put new profiles on a SIM card without having to visit the device, which is really important. So therefore, in a changing landscape, over the next five, ten, fifteen years, it's possible to make sure that the profile on the card is able to access whichever commercially available networks are available, providing radio access types and everything else can be met. So that's the sort of first thing we see. And the second thing is, it's always about percentage uptime, how available things. And I think again there, that's something where the first point of call is to a device and say, how am I building my device to make sure that I'm going to get this high availability? It's going to be able to communicate each time that it wants to. But also having the SGP.32 in there, again, it's a way of delivering profiles. It's something we've been doing for a long time, delivering new profiles. It means that there are more ways for the device to be able to connect, and therefore we can continue to do that. I think when we're looking at commercial viability as well, and then the second point there, again, when customers are looking at IoT products, the product itself and the connectivity has to pay its own way. Aren't any vanity IoT The product has to be there to be able to do it. And therefore, the key thing there is to say that you take cost of ownership over the lifetime of the device, which is actually at what point, and we're talking generally about quite long term deployments as we talked about earlier, so at what point does this device start to become generating revenue from the connection rather than having been an investment in setting it up? And when does that And therefore, looking at the total cost of ownership, looking at the lifetime costs of running that is really important. And saying, how are we actually going to get revenue from using this? And in some applications, it's really easy to understand because the connectivity is essential. For example, if it's vending, whether it's vending in an EV charger or vending machines, you can see that you don't get any revenue unless you collect the cash. So, in some ways, that's a really easy one to see. But in others, where you're gathering metrics, you're gathering performance, you're able to optimise how systems work, then it's much harder to see that and it's much more important to look at the total ROI over the life of the product. And that takes us back to the product has to last for the length that it's predicted to last for, because otherwise that's not gonna work. And then the other thing that I think people often see is operational complexity, where actually deploying IoT devices, when I was started by thinking you have one or two devices in the lab, it's really easy. At that point, if anything looks a bit funny, you can power cycle them, you can touch them, you can look at them, you can have both of them on the screen at the same time and see how they're getting on. Then when you start to go to ten, one hundred devices, which are maybe more remote, then it starts to get a little bit more difficult. And people are saying, when I've got one hundred devices, how do I make sure they're working each day? How what you know, I'm maybe managing this. You can imagine magic on the spreadsheet, but it's not a scalable solution yet. And then of course, when people go to a thousand, ten thousand, a hundred thousand devices, all of a sudden you cannot have people doing this anymore. You need to have machines. You need to have rules that say how are these devices being managed, how the connection's working. And therefore, that's where the operational complexity comes in, because at that point we're saying, for example, if we're looking at the SGP.32, we're loading multiple profiles on the card, if we've got one hundred thousand devices, how are we managing the split of those across the different MNOs, which country they're in, whether they're using the right MNO for that particular location, whether they're using the optimum MNO for that particular location is another thing. So that then starts to mean that we need to put proper automation in place, and especially when we consider the SIEM lifecycle. So when we're talking about devices which have extended lifespans, how are we managing that life cycle when those devices, you know, a small number of them will come to end of life earlier than others, how are we controlling that and managing it? And that all then feeds into actually what are the overheads of using this to control the SIM cards and manage them. And then the other thing that, again, Marco and I see all the time, suppose, there is people saying we're thinking about switching to SGP.32. We've heard it's a new standard. It's clearly going to be important, but what's the risk of switching and how are we going to maintain continuity if we switch? And even what does switching mean? And I suppose that probably takes us neatly on to the next slide, Marco. Thank you, Paul. And the next slide is that top takeaway. So yeah, you know, what do you need to make SGP.32 work? I think, you know, you've summed it up there, Paul. I'm incredibly well, you know, SGP.32 is important, but it's not really just that part of the equation because as you said, it's the longevity of the device, the geographical location of that device that's out there and how it communicates and how often it communicates as well. And again, as we know, Paul, and I know you elaborate this more than myself is how the device is put together. Is it mains? Is it battery operated? All those elements that go into that equation of the device. You're going to use SGP.32, it's just one part of the equation. Don't know if you wanted to expand on that at all Paul? No? Okay. No, think he did an excellent job. Sorry. Thank you. Thank you. Okay. You were just listening. That's a first for you Paul. There we go. Okay, we have some questions. You know, the first one is that does SGP.32 improve reliability, uptime and resilience? You know how appropriate that is the first question in. My first answer, know Paul probably disagree, but the answer is no because SGP.32 is the ability to load a new profile into the device. But depending on location, country of operation, you'll load a new profile into it to give you more routes to a particular network or a number of different networks in that if it's a roaming profile or if you're using the Eseye multi-IMSI profile on that to give you that increased reliability routes to certain networks in certain countries. Your views on that one, Paul? Yeah, so I think it's a bit of a yes and no to be quite honest. I think for I'll start off by no, in itself, I don't think SGP.32 does necessarily improve the reliability of devices. When we're working with customers, one of the key things that we find is actually looking at devices, looking at how the device is performing, how it recovers in unusual situations. Those are the key things that spending time on makes a big difference to getting the overall availability of the entire state up. However, having said that, the ability to be able to load new profiles into the SIM cards remotely and deliver new ways of delivering connectivity over the lifetime of the device gives the person who's doing that, I'm going to say us, gives us the ability to improve performance over the life of the device. So, for example, if we've got roaming devices, we can make sure that we are roaming from the optimum location. And that might mean that we're using lower latency because we are using a more regional profile. By switching on to using a home profile, it might mean that it's important because, again, we can make sure we comply with local legislation and local rules about data sovereignty and things like that. So, I think it's an important part of making sure we improve reliability, but it's probably not the first thing that we should be looking at. Totally agree with you, Paul. I've got a question that's split into two sections here. The first part is, is SGP.32 required for 5G SALs, 5G standalone deployments? Well, you know in simple terms, you know SGP.32 is ability to load a profile into a SIM card. If that profile allows that particular wrap type to work, of course it will work. But if it only allows, let's say, 4G only, then of course if there was a network out there using 5G or 5G standalone, it won't actually be able to connect. But it's just a profile, and as time moves forward, then the profile will allow us to use 5G connectivity as it's available. The second part of that question was, how is SGP.32 different from the current technology Eseye uses to deploy new profiles to SIM cards in the field? And what makes it better over the existing solution? So I'm going to take a breather there Paul, and I'm to hand that question over to you. Yeah, so it's a good question actually, because we've been delivering multiple profiles or multiple IMSI cards, I think about fifteen odd years now. So, we've seen different technologies as different ways of delivering those multiple profiles. So, talk about Multi IMSI technology, which we use and we put on all our cards. We've also used SGP.02, which is the current standard that's used for IoT devices. And what these are, are different ways of delivering profiles. Where SGP.32 starts to become, I suppose, new and different, is that it takes advantage probably of two different things. The first is that it uses software that's running or run from the SIM card to poll a server to say, is there a new profile for me to load? Now, because it's doing that polling actively, it's not waiting to get some other way of being nudged to say it's if there's a new profile for it. So, that can help in some situations because it's now controlled by the device and the SIM card as to when those that poll takes place, that can be synchronised to the application. And that's important, we might come back to that later I suppose. Yeah, one of my pet subjects at the moment about how that actually happens. But the second part I suppose is that because SGP.32 is built on SGP.22, which is used for consumer profiles and the way they're loaded, and a lot of the underlying technology is very similar, it means that it's very much more, much easier for network operators to provide profiles which are suitable for IoT devices, and make them available on the existing platforms and existing technologies. And the investment that they need in putting in new infrastructure and new connections to be able to deliver those down to IoT devices is much lower. And I think that means it's a much lower barrier for network operators to be able to provide profiles in their region. So, again, I think it's part of a journey that we've seen, which is when we started off doing multi-IMSI, it was something that's very novel and we were having to explain to people why multi IMSI might be important and why we wanted to do that. We then moved on to SGP.02 where the understanding of why people might want to do it becomes much clearer, I suppose, and it's a much more globally understood thing. But underlying the technology was quite, I would say, expensive and difficult to implement, and therefore the availability was somewhat limited. And I think moving forward to SGP.32, that will now really open the flood gates to saying different network operators can easily deliver profiles. Absolutely, absolutely correct there, Paul. That leads on to another question. They all seem to be linked in. We're stimulating our customers out there listening in on questioning is, which MNOs do we provide that are SGP.32 available? The simple answer is all of them. So all the MNOs that we have direct links in have provided us with an SGP.32 profile that we can load onto our SIM card, as well as with our multi IMSI, I call that a profile as well. We've got those partners that we can link into that. So not only do you have an SGP.32 profile from one of our providers, but we also got the multi IMSI one that we can load in to give you the fallback to give you that high availability, high resilience out there when you're deploying in different regions around world. Which is great news. So thank you for that question. Here's one that I'm going to pass over to you Paul to start off is how do you manage private APNs when changing SIM profiles in a typical IoT solution? Now SGP.32 does not offer any means to prepare the device to use multiple APNs. I know this is a discussion that we've had numerous times, Paul, so over to you. Yes, think this is probably going to be a challenge, which needs to be addressed at the point that devices are being designed and implemented and built. Because if the profile in the card changes, then it is possible. So, for example, it moves from one network operator to another network operator, unless there is a named private APN which can be ported, or it's available on both network operators, then it will be necessary to be able to instruct the device to switch the new APN. Now, could be done at manufacture time, so it could be loaded in that says, I know that I'm likely to use these profiles, therefore the device has to identify those profiles and use that APN at the time, and it has to switch automatically. Or it could be that the device, and I would hope everybody's device, has got the capability of doing firmware update, in which case the firmware update could be used to prepare the device for the new profile that's going to be loaded. I'd say that the because of our history really of doing multiple profiles, we use a single named APN for customers, so we've got multiple APNs for different services on them, but once that APN is available for the device, it doesn't matter which of the profiles is loaded onto the card or switched to, that the same APN name is available to all of them. So what that means is for our customers, they don't need to worry about switching APN at the time the profile changes, the profile can change any time, the APN will always be resolved and was always available. Absolutely, which again links on in the case of you know NB IoT deployments. You know the question that's come in is you know it's quite limited on its uplink and downlink. It's always based on short bursts of data, but it's required, you what is the energy required in the SIM and the device to download a new profile on NB IoT solution? And I know Paul, you're probably if I hand this over to you Paul, you'll probably talk for the next twenty two minutes on that one. But it's all down to the modem, the power, the consumption, how far you're away from the tower and how big that new profile is to go down into the device. So that is a very difficult question. How much power will use or how much battery life will it use to download a new profile into a device? So very difficult to answer that. But from our experience, Paul, from your experience, I know you've done a lot of work on this, Paul, what time does it take to download a new profile on an NB IoT type circuit? Yeah, well, going to send you an answer saying it depends. Because, particularly with NB IoT, where we see variable data rates based on distance from the tower and signal availability. And we know that the profiles by different mobile network operators are very, very different in size. Now, I think where we're looking at customers looking at low power, so for example NB IoT devices, we need to be looking and working with network operators to make sure that the IoT profiles are as small as possible to keep that down. But I have to say, I think my biggest concern for NB IoT devices and SGP.32 is not the download of the profile, because the download of the profile is probably a once, twice, maybe three times in the life of the device, and therefore actually spread over, you know, water meter is probably going to have either a seven or a fifteen year lifetime, That's not what worries me. I think what I am more concerned about is that the way SGP.32 works for delivering that profile is the unit through the SIM card will trigger a poll of the server to say, and I paraphrase, is there a new profile for me? And if so, where do I get it from? Now we have to decide for our water meter, how often are we going to do that poll? So for example, we could say I'm going to do that poll every time I'm powering up, but then there are two possible scenarios there, both of which worry me a little bit, I suppose. The first is if that NB IoT device is being turned off and turned on every day, then it's going to be polling every twenty four hours. It's going to be probably spending more energy polling to see if there's any profile available than actually delivering the meter reading data. On the other hand, if it's been designed to use low power modes, PSM, EDRX, then it's highly likely that device will only reconnect to the network very, very infrequently, in which case those poles will be very slow. And if they are that slow, does that mean that we can be responsive enough to make sure that the device is getting updated in a timely manner if that needs to be done? So, I think that's something that we're going to spend a lot of our time talking to customers about exactly how is the application going to work, and what are the compromises that we need to make, or what are the optimisations that we need to make, to put a more positive way of looking at it, to say we need these devices to be able to use the SGP.32 profiles to be able to pull them in, but how are we going to make sure that that's managed correctly? And I think those are going be some of the challenges that we see over the coming years. Absolutely Paul, I can agree with you more. Then okay, have another two part question here. Is the Eseye eSIM solution already GSMA certified? We only deploy approved and certified technology because I've seen we've all seen you know SGP.32 has been talked around probably for about the last twelve-eighteen months and there was people deploying it eighteen months ago, but it was a non standard. And now you know there's lots of changes that happen. So unless it's certified, we don't deploy. So yes, we are totally certified on that. And then the other part of that question was, there already been some serious commercial deployments of SGP.32? We've seen a lot of customers getting ready. We've seen a lot of people dabbling and trying things out. I know what we like to say the early adopters. Paul and I like to say is, is the right profile available for you? Is your device ready for SGP.32? And then can it be deployed in that region? Because if you get some nos in there, then it's not the right solution for you. So it's all down to those three things. Can your device support it? Is the actual profile that you need available to you? And then, you know, can it actually be deployed in that country that you want to use? I'm not sure if you've got any other views on that, Paul. No, no. Think it will end up being delivered as the standard way of delivering connectivity, and whether the SGP.32 components are activated and used might depend on the particular application, and again, would be something we'd be discussing with customers. But the question was about large scale deployments, and I think at the moment, there's a lot of early adopters testing and evaluating, and that's what we're seeing as well. But the actual delivery, I think people are waiting to see and to make sure that the system is reliable and does what we want. One of the things we noticed with SGP.02, for example, was some of the very early adopters that rolled out reasonably large states quite quickly on SGP.02 were later on in their, the lifecycle of device coming to us saying, Can we transfer the profiles across? We've SGP.02, we'd like to use that feature, and we found that some of those early deliveries, those early SIM cards, didn't necessarily contain all the features that were necessary to allow that to happen very easily. Yeah, absolutely. So I think people are being a little bit more cautious this time. Yeah, also, you know, to sum that up, know, it's an investment, you know, why are you doing an IoT project? You know, that there's got to be the fundamental business case and the return on investment, as you've mentioned earlier on, Paul, about that, that you know, what are you trying to do, what you're trying to achieve, otherwise it doesn't make sense. Which leads on to another question that we've got in Paul is is there any technical difference between SGP, you know, .22, .02 and .32? In my view, no, it's just a way of downloading a profile down to a SIM card. Yes, the technology behind that on how the profile is sent to the card. Yes, it's different, know, with SGP twenty two, it's more commercial based with .02 and .32 is more based on the IoT. But technically, you know, it's just a profile onto a SIM card. It's how it's being used is the fundamental difference and where you're going to deploy it. Yeah, and I think it again, I think it depends on which part of the solution you're looking at. And it probably says more about where we're looking, because of course, the underlying technology, and the way that the profiles and the actual files that are loaded to the cards are created and encrypted is different. So, it's not a case of saying I've got the file, I can download it using this method or that method. That's different. But at the application level and saying I want to be able to use multiple profiles on a card, SGP.32, again our platform supports this, says I want to download a profile to the card. The platform then says this card is an card or this card is an SGP.32 card, and then it will use the appropriate underlying technology to deliver it. So, the application level, it looks just the same. It does It looks just the at the application level, but underlying fairly different. Yeah, is fine. It's the one that's just come in now. Can connectivity providers ever explicitly trigger a profile update or is it always pulling from the device or the SIM card? And can the timing be changed? You know, is that the firmware level or on the SIM app? So there's a one I'm putting, you know, I'm going to hand over to you Paul, because I know you've done a lot of testing on that on on that. But from our perspective, yes, we can trigger it from the platform, or we can let the SIM do it. But you know, do want elaborate that in a bit more detail? Yeah, so I think this is again, this is a really important feature of SGP.32, which is to say at what point do we get we've got a new profile, want to get it onto the card, how do we know that the device is ready to accept it? So, for example, I'm thinking about, for example, somebody's making a blood pressure meter. It comes online, stays online for a few seconds, updates the reading and shuts itself down. Now, if we were trying to trigger an SGP.32 download to the card at that point, there would be challenges because the modem needs to stay on to complete the download, and therefore the application needs to be synchronised with it. So there is an element where the device needs to be synchronised with how it's doing it. But the question is about how do you trigger and force a download? So, the way that the polling works is that we would post a download waiting for the device to come in and poll. And now what we're saying is when is that device going to come in and poll? And the way the application, the SGP.32 application on SIM card works, is you can configure a number of triggers. And again, is something when we're working with customers to say, how are you going to use SGP.32 as part of setting up the contract, we call it the package, but it's setting up things like firewall rules and how the IP address is allocated and which profiles can be used. But as part of setting that up, we would say, and how are we going to deliver the rules for polling for new profiles? So should it, for example, poll each time it powers up, in which case, there is no need for a push, if you like, from the server, because actually when the device comes on, it will get that push. Unless, of course, it's a device which stays on for a long time, in which case we might want to use one of the timing features and say we're going to poll for one every twenty four hours. However, there are other features included within the SGP.32 implementations and standards. So, for example, we can say you trigger, I want to trigger a poll when the device changes country. Now, if you've a vending machine, you can't move country. But what we can do is we can actually trigger the device to, for example, change the network, force a new registration, and those tools there will trigger the SIM cards to identify I've got a new connection, I'm going to do the poll now. So yes, the short answer is yes, we do have tools to allow us to trigger the device to do a poll now. You could just simply said yes, Paul, there we go. No problem, no problem. Another one just popped in, you know, what device modem is required to ensure an SGP.32 to work seamlessly? Well, the modem is a modem at the end of the day because it has to have the right features and it puts a SIM card, has to be an SGP.32 SIM card. So once the profile's in there, brains of the connectivity is the SIM card, the modem does the connectivity. There is no specific modules that we will recommend out there, but they're all moving down that route of that. They're interfacing to a SIM card that allows them to connect to a network that's out there, be it that the technology they use is the SGP.32 profile that's on the SIM card. Which leads on to another one that's come in is what practical barriers are there to switch to SGP.32? What do you think the price is going to do over the next coming years? Well, I'm not a commercial person, Paul, so you know me on that, but what the barriers are switching to SGP.32? I think we've touched that quite basically. It's the risk. Is the profile available? Is that profile available for the countries of deployment? And again, we go back to, as we always talk about on a daily basis, is the device. How does the device operate? Now, we just had a question about the polling. How does it poll? Does it poll when it changes country or once every twenty four hours? Is it battery or mains power? All comes into the equation of that. So it's an interesting question on that. The other barriers are is today, is it risky? I'd say no, but depending on where your deployment is, it could be risky. So, you know, what's your view on that Paul? Would you implement an SGP.32 solution today? Yeah, I'm going to pick up on the word which says risk, but I think I'm going to turn around the other way, which is when I speak to my colleagues that work in the sales department and actually working with customers to say, we can do this, and you know, if you have an SGP.32 solution, for example, we would be able to migrate it onto our platform, then what is you know, the barrier here is what is stopping that customer that we're talking to wanting to move across? And I think it's that the person that we're talking to, if they say, yes, this sounds like a great idea, I'd like to migrate all these devices. If they are sitting there with an, I don't know, ninety five percent success rate or something, and we're promising them much closer to one hundred percent, then are they prepared to go to their boss and say for that extra five percent to get us up to that really high availability, I would like to go ahead and do this? Or actually, are they too risk averse? And what they're going to do is say, actually, I'm going to sit at the percentage of success I've got at the moment, because I don't want to stick my head above the parapet. I'm not sure that I want to do that. So, I think that means what we'll end up doing is seeing sort of the market splitting into two parts really. Some parts where people have got high quality devices, they're managed, they've got processes in place which will allow them to do that, in which case they will be able to say, in order to improve my performance in this particular location or to be able to do something like that, then they will be able to do use the SGP.32 to do migration and possibly some very interesting migrations. We'll see other applications where maybe they'll be installed and actually the intention's there, but there's never a compelling event that says people want to make the change. So I think we might see it a bit like that. Thanks Paul, yeah. One of these days Paul you're to just say yes or no as an answer to the question, but I've known you too long for that, but there we go. Here's one that's quite straightforward. Know, how many MNOs globally already have an SGP.32 profile ready for downloadable profile? Well, another one, the MNOs that we speak to have them already, but globally, you know, I would like to make a figure on that, you know, seventy, eighty percent. And you know, each day that goes by, we know more and more MNOs are having that profiles available for them, depending on their operation, Which then leads on to the next question, Paul, which I'll probably hand back over to you, because I think you just elaborated on the previous question. Do you honestly believe SGP.32 is truly operational ready for a mass rollout? Now that's a loaded question after what you said just literally a few minutes ago. Views on that? I'd say it's very very close. That's my personal opinion. We're getting there. But your views on that Paul? Yeah, mean I think SGP.32 as a standard is now sufficiently stable, it's been tested, we've seen it working, we've seen the ability to be able to use it to deliver profiles, but we've been talking about early adopters, we've been talking about devices, you know, small numbers of devices in labs, maybe in fairly local settings. When does somebody want to take the plunge and say, actually, I'm going to start rolling out with SGP.32 I would imagine probably later in this year we'll start to see it as a primary desire to roll out those. I mean, course, I'm in a strange position I suppose, because our platform provides an extra layer between how the profiles are delivered to the cards and the control of which profiles are being used, actually working with our customers, we've got a very soft way of taking them through, because we can deliver multi-IMSI SGP.02 solutions today, and say at the point that you're happy to switch to SGP.32 cards, then we will start to switch across. And there are going to be advantages to switching to the SGP.32 cards. They're going to be to later releases of the GSMA spec, for example, where therefore they will be better. And also, we know that more operators are going to be offering SGP.32 profiles and solutions in the future, and the ability of, you know, the number of operators who continue to support SGP.02 is going to go down. And therefore, there is a driver to say, although you might be delivering today with multi-IMSI SGP.02, we should start to look to swap those and get not swap them, but in the production, build fewer SGP.02 Multi-IMSI only and go for Multi-IMSI SGP.32 two moving forward. And So, I think we're going to see a switch over to that over the next probably six months. A migration, you know, I think at the end the second part of that just came in as well, how many large deployments have switched over to SGP.32. From our experience, Paul, as you've just summarised, know they're using SGP two today with our multi IMSI solution and they've tested what SGP.32 can give them and it's a migration of that. So again, it's the same portal, it's the same API, they see everything in exactly the same way in one pane of glass and one bill from Eseye. But it's a transition and I totally agree with you as twenty twenty six comes to an end and early twenty twenty seven we'll see that switch over to SGP.32 as a standard. So here's one that's got the word DIY kit Paul. I think you'll like this one. Do you think SGP.32 would be a good DIY kit for many end user customers? I'm not sure what they mean by that one, but I know you're probably, you know, like dabbling things like that. Yeah, well, think it's really interesting because SGP.32 offers a very attractive almost, you know, a click a button and download a profile from anywhere on the internet, you can do whatever you like. And I think that again, with small numbers of devices in labs, that can actually be very attractive because it's a way of demonstrating that profiles can be changed. But I would say that actually in the long term, if we're looking at people who are delivering products and projects using IoT, that delivering the IoT itself should be a means to an end, rather than something that is the number one focus of getting up every day and worrying about. But actually, and again thinking about our customers, where they spend their time is saying, how can I make sure that my devices are delivering the highest possible uptime, they're delivering the service that customers are doing, and how are we developing those products to deliver those in the most cost effective way, I guess? And therefore, actually spending their time on a do it yourself, switching profiles, juggling them around, is not something that they want to spend their time doing. And of course, that's where the platform comes in, because the platform allows us to have rules based profile loading, whichever profile we're using. Absolutely correct. And then, again everyone's whatever we're saying Paul is doing something right because the questions seem to be linking all together. Said know SGP.02 SIM cards are they the same as the SGP.32 SIM cards? Well the answer is simply no. They're completely different, completely operator of the operating systems completely different. And no, they'll never merge together. So you have an SGP.02, .32 SIM card. They're going be completely different. So the swap out, if you have an SGP.02 mistake, would be to swap out to SGP.32. The beauty of Eseye and our solution, Paul, as you've mentioned and I've mentioned that, it's a phased approach, we're able to guide customers to switch over from .02 to .32 in a seamless fashion. And everything gets integrated in exactly the same way. They still have one pane of glass, one support ticket, and one bill from Eseye. If someone wanted to test, I'm going ask you a question Paul. If someone would like to test an SGP.32 without engaging, carry on with that DIY, without engaging or having a lengthy MNO contract, is that something they could do? I could ring up an operator and say, I want to use your profile. Can I just download it and do some testing? Or do I have to go into a lengthy contract with them? Can I ring up Eseye? Say, "can I just try one of your profiles quickly?" So, think that's a really interesting question, which is about how to get started and using it, because it starts off by that point, which is saying actually I'd like to have a profile, I'd like to try it out for a few months and then switch it to see what would happen. But I think we're then looking and saying how is the market actually going to go forward? Because if profiles can be switched very easily, and there's an expectation, and the market is talking about switching profiles very easily and very regularly, then our network operator is going to need to offer contracts which don't have a long lead time. Now, are some things where which should make this very easy. So, for example, typically if you're starting a new contract, there is investment. You've got to buy the SIM card, whether it's an embedded SIM sold on the board or a plastic SIM card, and those things either need to be paid for upfront in investment or spread over the lifetime. And therefore we tend to see contracts which have multi year contracts, or multi year contracts, to allow the investment that's needed to set up, okay, with an SGP.32 solution or with any solution that's loaded over the air, then there's a question about what how the operator can best charge for that. Now, because and again, I can talk about the way we work, suppose, because of the way we work, which is we actually use the multiple profiles of however we deliver them, to make sure that we get the best possible connectivity wherever devices are. Actually, our customers don't see contracts appearing in Dispute and basically contracts on the card, and then we put the underlying profile on there and make that work for them as a consistent interface all the time. Absolutely, thank you Paul. Again leading on from that, know after SGP-two we now had twenty two weeks to commercial and now we've got SGP.32. Do you think there's going to be another standard coming? Well, who knows? I've already seen some articles and been on a couple of seminars where they're talking about six gs. And someone mentioned seven gs, and my brain just exploded thinking, I can't even get over 5G at the moment. And we're talking about 6G and even 7G on there. So will there be another one? I know SGP.32, the way the profiles are sent to the SIM card, do you think that will change in the next eighteen months, two years, Paul? So I think the time it takes to develop a new standard means that we're not going to we don't have to worry at the moment about being quickly. But I think the other thing is that if we look at how standards evolve, we tend to get new standards that we can use when people reach limitations of the old ones. And I would say one of the challenges that we've seen with SGP.02 is the infrastructure cost needed to make the so although the technology works very well, the infrastructure cost to allow it to be delivered provides quite a barrier to entry and therefore it should be that device to address that. If that means that actually it's delivering what people need, then I think we can see it having quite a long life. Absolutely, absolutely Paul, I couldn't agree with you more. It's I think if I'm not mistaken, it took over two years for us to get to SGP.32. So, John, you've appeared back on the stage. Assume that Paul and I have been talking too long and we're coming to the end of the webinar. Yes, obviously you've both been kept on your toes there. We've had a lot of questions coming in. We do have one more, so I don't know if you wanted to answer that. We've got another minute. So if you wanted to answer that last question and then we will close the call off. Thanks, Oh, it seems like many companies are deploying this. How do you differentiate? Well, there's a loaded question. You know between me and Paul, I don't think we can answer that question in one minute. But how do we division? We offer a managed service. It's a simple, you know, we hold your hand from the device to understand your use case, what you're trying to achieve, how the device operates right through to the areas of deployment or countries of deployment to ensure that it gives you the utmost connectivity in any region that you want to deploy into. Build one ship globally, that's our motto. I'm not sure if you want to add another thirty seconds to that, Paul? No, I think that's pretty good. I I think the thing I would say is, for me SGP.32 is a tool which allows us to deliver profiles, but the main focus on how we differentiate is, we're looking to say our customers are looking for one hundred percent uptime, one hundred percent availability on their devices, and they're building IoT devices which are there for a purpose, and that purpose is to, you know, the connectivity to deliver that functionality. And therefore, SGP.32 is a tool that we're going to use that rather than something that we're selling because it exists. Excellent. Brilliant. Thank you, gents. Thank you everyone for joining. If there's any additional questions you want to submit afterwards, we've got a solution page on eseye.com/sgp-32 and you can submit any additional questions via that if you'd like to. But thank you all for your time and hope to see you again soon. Bye bye.