Hello, and welcome to Android bites powered by Asper I'm, David Rudick and each week I'm joined by my cohost Michelle ramen diving deep into the world of Android. And this week we're embarking on a journey that I think is really interesting because it's an area that like many of our episodes, nobody really talks about, um, in, and they even in the kind of niche tech media. And today we're talking about EIM, which is something that I know is exciting, especially to pixel users, because Google's embrace the standard so much, but it also has massive global implications. As the telecom industry continues to evolve. And we have a very special guest today. Who's responsible for a very innovative product in this space. And I'll let Michelle introduce

him. Thank you, David. So on today's episode, we've invited Christos from telco village. Welcome to the show Christos. Thanks, having. And so the topic of today's episode as David mentioned is EIM. So for those of you don't know, EIM stands for embedded SIM and SIM stands for subscriber identity module. It's a very interesting topic because there are not that many phones on the market. With EIM capabilities built in. But Ray recently I discovered a product by the company that Christos works for that actually enables bringing ES IM to almost any Android smartphone out there. Most Android smartphones are compatible with this product. So that got me wondering how in the heck is this possible knowing what we know or what we thought we know about ES IM how is it possible to bring something that's supposed to be embedded into a device? Externally through what looks to be a regular SIM card. So that topic that got me down a rabbit hole of, uh, GSMA specifications of what the heck a smart card is of what APIs are used in Android to talk to smart cards and all sorts of business. And that's kind of what I wanna talk about on today's episode is like how the heck does communication with the SIM card module actually work? What makes an EIM different from a regular SIM. On a technical level. And that's why I wanted to talk with Christos. Who's an expert in this field before we actually start talking about ES I and how this communication between Android and an ES IM module actually works. I think it's important to understand why the ES IM actually exists because there are two main reasons. One is the size. And that's probably the most obvious reason for anyone to understand why the em exists, because if you've used phones for a long time, you know, that SIM cards used to come in much bigger sizes. If anyone's used the regular, the original credit card size SIM card, the one FF size. But, uh, I wasn't using phones back then. I used that size, but I think most people today probably use the two FFF three FFF or four FFF, which is mini micro, and then nano respect. Most of our modern today support the nano SIM card. That's what you find on most devices, but even smaller than that, you have the EIM, which is I embedable into the devices motherboard. So instead of dedicating space for a physical SIM card trace lot that has to be removable. That requires extra space. Maybe somewhere on the side or in the body, you can just build it directly into the motherboard, saving some space, which is very valuable on a small device, like a smartphone. Then in the future soon, we'll have iSims, which are integrated directly into the system on chip saving, even more space that could be reserved for other components on the mother. I wanted to start off by asking you first, Christo, what do you know about the EIM form factor? Because many people don't know or at least, I didn't know until, uh, a couple of weeks ago that there are actually multiple ES I form factors that there's not just one size for an EIM. There's a F two, which stands for machine the machine form factor. And then there's also the. W L C S P, which stands for the wafer level chip scale package. I know there's two different sizes and like, I know there's different uses for them. I wanted to ask you, what can you tell us about them? Yes. Uh,

basically everything starts with a wafer, which is the circuit, and then you can build the package around it, depending on the use case that you have. And for the embedded SIM, starting with the machine to machine devices, uh, they wanted to solar them on, on PCBs, on printed circuit boards, and later they wanted to have them in smaller. Is waterproof devices. And this is why the other phone factors came. We did exactly the opposite. We did not look into making them smaller, but installed, uh, the EIM wafer inside a SIM cut phone factor. And the reason for that is to create an opportunity for people with existing devices to benefit from ES. On their devices, which makes their devices also more sustainable using them longer and getting the benefit of this new technology.

It's very confusing, but the embedded in Essem doesn't actually mean it has to be embedded inside the device. It's something that you think you take for granted? Cause it sounds like, oh, embedded means it's inside, but the specification doesn't actually say it has to be inside the device, which is a bit of a fun fact that telco village took advantage of with the Esme product, which we'll talk about in a. Before we go down. I think I wanted to touch upon what actually comprises a SIM card that you hold in your hand. So for the most part, the reason we're able to go from the big plastic credit card size card down to the nanos SIM is that most of it was just plastic. It's just like a covering like a shield for the actual circuitry that you can clearly see is like the yellow part of any SIM card that you hold that yellow part without all the plastic around it. That is what actually has the micro controller. That's the circuit. So this micro controller, it has its own CPU. It has its own Ram. It has its own storage. It has its own IO circuitry so that it can actually communicate with the card reader and whatever host device this SIM card is attached to. And this is an entire micro controller. It has its own embedded firmware, and this firmware is responsible for communicating with the host device. And it also is able to store some contacts, some messages. So it's not very common nowadays, but a long time ago, people used to actually store a couple of messages or a couple of contacts directly on the SIM card, rather than like in the cloud with Google contacts and SIM card still enable you to do that, but it's just not very common anymore. So this whole package, that circuitry that's called a U I C, which stands for universal integrated circuit card. You also see sometimes this referred to as a smart card, which is a generic term for any card with an embedded circuit. So a U I C C is a, just a specific type of smart card that conforms to a specification that was made for this purpose. One of the differences between traditional SIM cards and EIMS is that EIMS make it possible to store and switch between multiple SIM profiles. That's one of the defining differences. At least most people recognize. So a SIM profile for those of you don't know is what identifies the services that your device is able to connect to. So of course, like a carrier doesn't. Any non-pay customer to be able to connect to their services. So you have a profile that determines I can connect to the voice call service. I can connect to whatever extra services they have. I wanted to ask you, why do we need an EIM to do this? Why can't we just retrofit existing traditional SIM cards to support storing and switching between multiple SIM profiles.

Actually SIM cards can store multiple SIM profiles. And we've been doing this for years before SIM the problem there was that, uh, you also store keys and those solutions were all proprie solutions. Everybody was having his own solution as a mobile operator. You could control those counts where you could remotely upload SIM profiles there. The actual problem was the interoperability between parties. And this interoperability main problem was sharing the keys of your network. The keys that the subscribers identify themselves to the network with another party and with EIM, which is a standard. That a problem will solve because the EIM profile is including those keys without the necessity to share them with somebody. So when you share the EIM profile, you don't share any keys and the GSMA, uh, which release the standard is creating the root certificate. So the E U I C C, which is the chip has a certificate from the GSMA, the RSP server. Which is serving the profile as a certificate. So there is an environment created, uh, with trusted parties and therefore the communication is not possible. So it's not that it's something new with a SIM profiles, but now it is a standard that is globally. Establish and agreed so that it can be executed. This is the main advantage of ES IM that this technology enables the interability between manufacturers of devices, providers, and mobile

operators. Yeah. So interesting point about that is while I was researching for the original article that I wrote on this, I learned about the apple SIM card. For those of you who actually had a SIM card, a physical SIM card that let you store multiple profiles onto it, or I think it came pre-installed with multiple SIM profiles from multiple different us carriers. And you could pick and choose which one to use. But as Christos mentioned, the problem with that is it's not interoperable. If you were to use an apple SIM card, On a Android device, you wouldn't be able to switch between the profiles that were stored on that SIM card because only Apple's iOS was set up to do that. So by introducing the EIM standard, which standardizes the way these profiles are managed, then you could switch between profiles in a standardized way. So like right now there's no way to you can't like transfer your EIM profiles from an apple device to an Android device. But the way in which those profiles are managed is now standardized. I wanted to talk about now your product in particular. So as you mentioned before, the E be embedded, doesn't actually have to be within the device and your company, telco village actually took advantage of this, carve out in the em specification to basically create a product that lets you enable EIM on any device. I wanted to ask you, how exactly does that work? Can you tell us a bit about.

Let me add something to what you just mentioned with the E and the GSMA standard. The standard requires that the profiles are stored in a physical hardware, so that they're not stored in as a software. That's the requirement and this physical hardware, if it's sold on, on the motherboard, or if it. And another way, you know, connected to the motherboard through the SIM card is still sufficient for the standard. As I mentioned before, we were doing multiple SIM profiles on SIM cards before, and actually we, we registered the eim.me domain in 2015, one year ahead, the release. Of the ESY standard, which is funny. And we were happy that the ESY standard hit the market because this created the ability and the interpretability as, as we mentioned. So our goal was to create a removable ESY that will upgrade that will add the ESY functionality to existing devices. But this was not the only goal. Our goal was also to. Create it without rooting a phone without soldering, anything without opening a phone, losing the guarantee. So we were talking with our colleagues and, uh, with, with friends, et cetera, and they were telling us that this is impossible because we need to have some kind of support from the hardware or the software, et cetera. So eventually we, we use. The knowledge of 20 years in telecommunications, we used our experience with multiple SIM profiles on the SIM card, and we created the SME card, uh, which is holding the E U I C C chip and the form factor of the SIM card. And. While our goal was to lift the users of existing devices, to the level of EIM compatibility with devices with ISIM built in. We actually went beyond that because if you see, for example, a Google pixel or any device with built in EIM, it's only for single device. You cannot use that em, in another device. So with our solution, we created EIM capabilities for under devices, but also beyond that. So once the EMM profile is downloaded and activated on the EMM card, you can remove this card, install it in your laptop, in your wifi router, in any device with a SIM slot and benefit from this connectivity. And. The second thing that we did is it's the world's first dual em solution. It means that you can have two ESY profiles active at a time on those devices. And this is also the reason why we have also customers that already have ESY built devices. Google pixel is a good example and the bio product for these two regions to be able to move those EIM profiles to other devices. For example, my smartphone runs out of battery. Where's my connectivity or I, my display is broken or any other thing is damaged. Another reason is when you want to transfer your profiles from one brand to another, it's very easy. You just do it in seconds. And some operators, when you want to transfer your EIM profile, they charge you between $10 and 40 euros. They call it replacement card. They make it very difficult for you. So we tho those customers save, had a. And money and, uh, so there's functionality and there's also convenience. We created the Esme app in a way in the play store. The device list has around I think, 15,000 compatible devices. With our product, but there is, uh, a multiple different Android versions that can be installed. So it's impossible to create a list which device is compatible and which is not compatible. We come to this later, how we check the compatibility, but the app will tell you, you download the free app and you will tell you your device is compatible or not compatible. And when it's compatible, you can order the CDI card, install it. And then you can just start downloading ePRO profiles. And we created. Let's say the, a variety of products to align to. I have a single device. I only want to use it there. So I don't want to spend too much money. I don't need the other features, or I want to switch and manage the cart between devices, et cetera. I need more space and more storage. And therefore we created the variety of products and our customers are excited about this product. And this gives us also the motivation to continue. We have also. Uh, future plans. We can talk about this later, what we are planning to do with the secure element.

Right. So it's definitely a very ingenious product. There's nothing else like it that I could find on the market and just both in what it does and how it takes advantage of a part about the specification that I completely wasn't aware of before, which is the fact that removable embedded SIM cards are possible. And that it's actually explicitly something that's supported by the G SMAs EIM specification. They actually does explicitly mention. Removable E U ICCS and anywhere you look up you, if you Google, EIMS almost, everything says it has to be embedded in the device and that's wrong. It doesn't have to be that way. And this product proves that. And the actual specification allows for that. The other interesting part is, as you mentioned, you built an app Esme that communicates with your em.me card without using root access, without having to be a system pre-installed app. And that's the other bit that I found really fascinating. Like, how is that possible? How is it possible to just download a standard user installed app from the play store and have it communicate. The card that you insert into your device, like, how do you do that? And that's something that I spent a bit of time diving into. And I think I wanna talk about that now, because as we know, SIM cards are meant to be removable in general, and you're meant to swap them between devices. There has to be a standardized way for the host device and the host operating system to communicate with the firmware on that card. Because if there wasn't, then your SIM cards would be tied to a single platform and that's not very useful. So I wanted to ask you a bit, Christo, can you tell us about how that communication works? Can you describe the software that's running on the U I C C slash E U I C C. And how does the post operating system like Android communicate with it?

The software on the us C we can simply call it EIM OS. So it's a software that managed the MCU, the storage, et cetera, and the interface to the host, as you mentioned, because it's meant to be removable, et cetera is just a smart card. ISO 78, 16 with commands. It's it's that simple. And the content of those commands of course, need to be aligned with what we sent from the Acme app to the Acme card so that it does the actions that we wish it's basically that

simple. Right? So the, this E IM OS, can you tell us a little bit about that? What kind of programs? I guess very, very, very basic from what I read Java card SIM apples, like, can you tell us a bit about what's actually running on the EIM? The

most important part here is the certificate. There is a mechanism that requires the E S C to authenticate itself to the let's call it network or server the us E C being the client and the other way around. So both need to authenticate each other. And from there. There is another piece of software that does the work, which is, uh, we are going to talk a bit later. The LPA, the local profess assistant can also be implemented in the us C, C. We are going to build a version that will have it, but it it's not at the moment. So the us C is only fulfill the GSMA standard in terms of exchanging the information with our.

Okay. So just in summary, all this communication is supposed to happen in a standardized way. You have a Java card, apple that's running in the ESM OS of the E Y C C. And that communicates both ways through app due commands, which stands for application protocol, data, unit commands, and all of those commands. Those are following a standard definition, the ISO 7 816 dash four. So all of this is, is kind of standardized, but one thing I was interested for me to learn about was that prior to Android nine, which introduced the open mobile API or O M API, that there was a bit of inconsistencies in the way that Silicon would actually have their devices communicate with the smart card on their device. So I wanted to ask you, if you could tell us a bit about the situation, like prior to Android nine, can you tell us about what it was like for. An app, like ISA me to communicate with ISA me card. Like, was that even possible? And what did O M B I a do to change? We have

customers using under five on their phones. This is the, the oldest hundred version that we have, uh, seen customers successfully using the EME caught anme app with the similar lines on MAPP. Is the OPI library that was before Android and was used by OEMs like Samsung Harvey. Samsung did a very good job implementing this and also continue to use similar lines OPI even beyond Android lines. So you have both APIs with them and sometimes we have to switch between them depending on. The implementation of the SIM card readers, because they may not be accessible. And we tried the one or the other way, but the way was the same. There are also other ways of communicating with the SIM card, with the very independent protocol with binary SMS, with a lot of things that are not. Really related in to Android. So, so a network provider mobile operator can talk to its SIM cards, uh, through the mobile network. They basically sent communication that is transposing through the Android system. But if we are talking about an app communicating, this is then done through a MAPP and then eventually open a logical channel, sending commands, uh, et cetera. That's that's the

implementation. So O mappy, by the way, if I didn't mention before was introduced in Android nine for a O S P prior to that, as Christos mentioned, some OEMs would integrate the library themselves, but it's now a standard feature as of Android nine and later. And I believe there's even a compatibility test suite test that checks for home APIs, whether or not it's been implemented. Correct. So your app, as you mentioned, works without root and depending on OS version, it uses om, API commands or other commands, depending on the device. I wanted to ask you now, how exactly is your app allowed to send these commands to the Emme card? And how do you ensure that only your app is able to communicate with the Emme card and not just any other third party app that you download off a Google play? Like, how does this

privilege work? As I mentioned before, our goal was not to require any permissions or not to require any unnecessary permissions from the user or the OEM. The only permissions that we ask the user to provide. And these are only optional is, uh, permission to use the camera. If you want to scan the QR code to download the Asim profile and the gallery. To access a Q code. This is very interesting because the way that it works is, uh, for example, you buy in they send you an email with a Q code, some operators send you a postcard with a printed Q code. That's that's not really environmental friendly and not really digital, but yeah, they, they just print on a SIM category. However, if I buy online and. Delivered to me by email, I would store it in the gallery. And then from the gallery, I can read it with in the app. So these are the two permissions we ask, but if you don't want to give this two permissions, you can just enter it manual. You it's like a URL that you enter with some code, and then you can download the profile. The rights that we get. Are, uh, sourced by the card. So the card has certificates that declare which applications that are assigned with specific keys are allowed to access. And we have a set of keys. Which means that our E CME app has access, but we are also open to provide access or similar to the entitlement that that manufacturers give to other, let's say developers to access their E U SCCs. Uh, we have the same option. So developers are open to contact us in this regards with the advantage. Say that even if, if somebody says I have Android running on Google, Android, running on Samsung, or in other manufacturers, they would require the entitlement from each manufacturer, not Google as an Android, but Google as a manufacturer, Samsung as a manufacturer because it's access to the hardware. So this is done with the case at the same time. We allow access to the system apps. So you can access the EME card with your SIM manager from the Google settings up to 111. It was even. Possible to download EI profiles because the ECM card has a higher priority to the embedded S C but with hundred 12, they specifically address the embedded us C so that you have to use the Acme app. But the system itself has access to the cart is the E S C standard. So we allow access to the system itself as.

So it's quite interesting. The way mechanism that this works is actually a certificate that declares, which apps can interface with it on the Android side and whatever other operating system is available. When I was reading through this, I, I learned about this is all part of a U I C C carrier privileged permission. So basically it's a way for an app to access certain privileged telephone APIs without actually having to be system pre-installed or having to be granted a specific permiss. So this way, EIM dot E is the only user installed app that can interface with the ES IME card. You can't install any other app on Google play. That's able to do what the Esme app is able to do, which is download and manage profiles on the em.me card. This actually is quite similar to like all other same cards. Basically you have your carrier apps, which are able to access carrier privileged APIs in this, in this very similar way. This is all standardized through the file. The whole certificate would call them access rule file. I believe so. Um, it was very interesting to learn that. But one thing that I did discover while I was using the eim.me app, is that it's not able to be pre-installed it's not able to be integrated into Android settings, like say Google SIM manager app is, and now I wanted to ask you about why that's the case and what would be required in order to get in ES IM app actually integrated into the Android operating system. As like, you know, you go to settings, you're able to directly add anim profile. Like you can on a pixel. So, can you tell us about some of the things that would be required in order to do that in order to actually integrate your app into Android OS setting?

What is required is a communication to two directions. The one is the communication to the RSP, the server that holds the profiles. This is standardized how it's going to be implemented. And the other is the connection to the U I C C. This application does not need to be certified because it's only the transport. Let's say the translator, it downloads the profile. It slices the profile down into commands, and then it is sending it to the U S C C prior to this, there is the authentication process necessary where the LPA. Just exchange the information between those two. And this is why the LPA does not really have to be in the app. It can be in the system, it can be in the app and it can even be embedded on the chip itself. This is called LPA E for embedded this time on the chip,

a couple of terms are thrown around just now, as you mentioned, LPA before stands for local profile assistant, it's actually part of the GS A's EIM standard. So if you look up the GSMA SGP two, two, One of the section talks about local profile assistant for device and that the other one is local profile assistant for embedded. So LPA in terms of Android is the EIM management app. Google's SIM manager app would be an example of an L P a D implementation. Um, another term that Chris has mentioned before RSP, which is the remote SIM provisioning, the server on the carrier side is called the SMDP plus. So subscription manager, data preparation, plus. And that server that they deploys, what supports RSP, remote SIM provisioning, but that's all not Android. What is Android side is the L P a D, which is the application that actually helps the user download SIM profiles using a QR code, either downloaded or something they can scan. There are several applications that basically act as an L P a D brand Android. The EIM me app is basically kind of like that. Then there's also an open source project, which I talked about in my post called open E U Y C C. I wanted to ask about your thoughts on this project and what are you doing in relation to it?

I think that this is something for OEMs to implement their LPAs in their systems. Something that we didn't mention before is how can Google make sure that the map is implemented accurately in the devices? Fortunately, since 109, the map is there, unfortunately. The OEMs do not implement it correctly or fully. So maybe there is no MAPI. Maybe there is O MAPI only for the N C chip, but not for us C or maybe there is O MAPI for the us C, but there is no access to the SIM readers. And this is why we have created this compatibility check. And maybe this open us C is a way. For those OEMs to an update to integrate this functionality, to their phones. We, as Acme are welcoming other LPAs to access our cart because our cart, the Acme card is a secure element. And the secure element, the one thing that it can do is store in profiles. But the secure element is the same. Technology that we see on smart cards for credit cards. So we can store payment information. It can be sliced into secure domains and those secure domains can hold information like keys, like payment information, like any other kind of tokens, et cetera, that. Users or developers are going to develop and create other products. So, so we create the foundation on the physical level and provide the access, and this can enable other developers to basically build on top of that. So LPA is just one thing. And with the secure element, I think we provide a platform and a marketplace where these things can become reality. And the Acme app is not only an LPA. Actually it started very primitive and we expanded because we've seen the feedback from the audience that, uh, now that I have the storage to basically store EIM profiles, where do I get those EI profiles from? And why do I have to go somewhere else, et cetera. And we are creating a carrier neutral marketplace where everybody can offer their easy profiles. We are going to do KYC. For them in some countries it's required to know your customer. And if I am, let's say in Germany and I buy anim profile from Doche tele, from T-Mobile, I need to do KFC there. And then if I switch to Vodafone, I need to do KOC there. And there are a lot of hurdles that make this standard a bit unconvenient. And while if you have a platform. Compare it with Amazon as a marketplace, your credit card is store there. Your address is known you only click and buy, and we want to create a similar marketplace for it in profiles. So that users do not have to start this onboarding process from the beginning. It is authentication. It is payment gateway, et cetera.

This is I think where strategically, maybe we can zoom out a little bit. Just like the situation with telecom operators. For example, they have a lot staked on keeping the physical SIM standard alive, as long as they can, especially here in the us. They are very, very attached to it and they really have been very reticent to give it up. So I'm sure that that is also something that is kind of slow walked this technology for a number of years now, especially as we go to EIM, because to me, the carriers, like you said, they intentionally try to make this difficult or imposed with cost a very arbitrary and capricious way. It's it has nothing to do with helping customers. It has everything to do with making switching services and products. Very difficult. So it's interesting to me that even em, which I think was in many ways designed to be friendly to the carrier's concerns about competition, that y'all were able to come up with the solution that actually modularizes the standard and says, oh, you can take it anywhere with you now. That to me is what makes it so interesting. Have you had any conversations with any carriers or manufacturers or other people in the industry who said I was waiting for somebody to make this? I knew it was possible or is it truly just surprise? Like we literally did not think this could be done.

I agree with you. Operators ly think that if they stick to a Simco, they lock down the customer, but of course the Simco can be replaced with another Simco and ISIM is a threat to their eyes because they think that on the market, they're going to lose a customer. They don't see that this customer is going to another operator that could be themselves. So if I don't offer something, they cannot buy from me. And if I offer ES IM with an app, Like some operators do, then I cannot actually call it E and because they don't give you the activation code to basically see it as an standard. But this being said, I think that this is similar to the number portability that you didn't have in many countries over years. It, it established this way. Uh, we have countries, uh, like Saudi Arabia. where every operator has Zim and where they offer 30% discount. To EIM compared to Simco. I mentioned before they know your customer, they're onboarding. If you have prepaid customers, you have onboarding costs and those customers can leave you anyway. So you don't make any margin if they don't stay for a time with you. So I think that we cannot convince operators that EIM is something good for them and for the future, but we can see an analogy with, do I need a website? Do I need a web presence? You know, Back when online stores, et cetera, uh, created, we just let them take their time. We, of course, we've spoken to many operators because we are an operator ourselves and we have the context to all of them and they, the most of them think of. We are going to wait until there are ISIM only devices and then we have to move. But we also know, and we see this in some markets that if one operator starts advertising starts pushing marketing this, then the others will follow in no time. So we see in Europe, for example, there is, uh, no roaming between countries agree. So within the European union, there's no roaming charges allowed. And then you have, let's say. Polish operators selling in Europe, uh, check operators selling in Europe. It doesn't help the German operators to protect their SIM card because they're going to buy from somewhere else anyway. And the same will is happening in north America. We we've seen Canadians buying Asian EIMS. To use in north America because they only need data. So they don't have to pay for voice packages or whatever. I think it's just a matter of time. It's it's ISIM is a new path and the faster they jump on this, the better market share they can secure.

Yeah. I think the convenience at EIM really can't be understated in some situations like my cousin she's visiting us from Bangladesh and of course she needs a local Sy card because she's here for several weeks. So because she has an iPhone, I remember that T-Mobile actually offers an app that just completely guides you through the process of setting up an EES. I profile within the app and paying within the app. Within a matter of like five minutes, we had service up and running for. I didn't have to go anywhere else. I didn't have to go to a store. Didn't have to shop around for one of the various MBN OS that offer plans. It was just at home connected to my wifi network, five minutes up and running with a new plan. And as you mentioned, even smaller carriers, like in surprise markets like Canada, connecting to an ES IM offering from Hong Kong, three, three Hong Kong, I believe is the carrier that many of them subscribing to. There's an opportunity there that a few carriers are actually taking advantage of. And, you know, it's a bit of a chicken and egg situation where more carriers are waiting for devices to go EIM only, but devices won't go EIM. Only if few carriers are supporting EIM. So like, We're kind of a stuck at the standstill where the highest end premium phones have in EIM and they also have a physical SIM card. But there's also a little technical limitation with the ES. I currently in that most ES IMS only support having one of their SIM profiles active at a time. And as you mentioned, Chris, four, your solution supports enabling multiple ES I profiles because you can have one ES IIM profile enabled on your ES IM me card. And then another one enabled on the phones built in ES I, or you could have a phone with dual in card slots and you could have two Essem me. But something interesting that I learned about recently is that Android 13 is implementing a new feature called multiple enabled profiles, which would enable you to have two SIM profiles stored on an EIM at the same time, it would allow you to use both them at the same time. So I wanted to ask your thoughts on this multiple enable profiles feature and whether or not it's something that actually could be done with an eim.me card.

This is a great feature. Uh, I really welcome this. Uh, if it's available for us to access it, we are going to implement this also forme we had, uh, customers actually, let's start to define how those multiple is improves, can be used. It is determined by the number of SIM card slot, and eventually by the number of moderns. So if I have two mode, I can have two subscriptions active at a time. And even in some cases where somebody has a dual SIM phone, but wants to use a second SIM card slot for, he says D card. It will be a benefit because he can have one Acme card with two profiles addressing the two mode while he has an SD card on the. That's a lot. So there is a use case for this and there is we, we have received many requests for this. Uh, so I think it's a, it's a good feature. And we will implement this. The access for this is possible means if the OEM will enable this access, because it's depending also on them, how limited this new feature will be similar to the O MAPI on the, on the previous

things. From what I read according to Google's patent, it doesn't actually require two modems for MEP to work, which the conventional wisdom that you would need for every active SIM profile. If you want an active data connection, you need a second modem, but, uh, DSDs or dual standby. DOSIM dual standby. You could still have EIM MEP work with a single modem. Google's patent describes a opening two logical connections from the SIM car to the modem. And yeah, I'm curious to see how it's gonna work. It's something Google hasn't announced yet, but there's some documentation available for it and whether or not this can be extended to removable. E YCCS is another story entire. I

haven't seen the patent. So I cannot tell something about the patent, but I've seen the description where you can basically address two or three mode. I haven't seen a device with three mode, but at least from the theory point of view, this is possible. If their patent can talk to multiple, let's say networks, et cetera, in a time difference than maybe this is also possible. So theoretically it's possible. Uh, if there is a requirement from the network, That's another thing. So open to see what this pattern will look like and how the let's say the mobile network will or will not have to implement part of the pattern to, to make it work.

And another reason this is, I think also starting to come up is that as 5g networks reach saturation, there are going to be use cases where having multiple networks actually is going to provide a material benefit to the end user. And that end user could be somebody doing something like downloading a very large file. We've already seen heterogeneous networking technology, like Samsung phones like that, this for years where you can use wifi and LT at the same time. Uh, to boost your download speeds, obviously in America carriers hate this feature because they would rather you be on wifi and nothing else, but it goes to show that there are going to be use cases that drive that. And so if you are able to have a phone that uses what you know, to be the most reliable data connection or device that uses the most reliable data connection day to. But can keep an active profile enabled that is particularly for like super high throughput downloads maybe, and maybe those are only necessary during business hours. And so you have it connected to the high throughput network when the device is active and being used, but when shuts off. It goes down to the super low power network. And maybe that's like a 5g IOT network where it's really just sending some basic packet data, time to time the check in. So I'm sure that there are all kinds of use cases out there that have really yet to be explored for things like this. And as we make it more integrated on the device, I think that we'll see those use cases start to emerge the biggest limiting factor. And I I'm guessing would agree, Christo is that. The physical side of a SIM card is that it has to go in something. You have to get it. And there's one SIM card per device. And that just makes doing anything complex or unique as far as a configuration, much more challenging when you're making SIM cards. It's probably a very big scale kind of thing you're doing. Like an, operator's not going to be like, oh, we're going to make this very special configuration for this one customer on our network. That's uniquely coded to these SIM cards and they can do special things that other customers can't nobody's providing that kind of service. So it would make sense that the technology should move to the device and end user side to be managed there. So that the implementations, just depending on how much does this cost me to do this. So the carrier just goes back to being that dumb bite. Instead of a glorified services provider, which we know they all aren't, they're just bits. So this is really cool. And I think that you guys have an amazingly interesting product, and this is usually where I would plug where Asper fits in with it. Um, this one's a little harder for us because, you know, we do have mobile data use case, and it's very interesting, but I've really thought about this and I'm like, I'm not sure exactly. But I am sure that eventually we will have customers wear more flexibility around mobile data, 5g and Essem is going to become a priority because it's a matter of flexibility for businesses. Being able to switch providers on the fly would be an amazing way to potentially reduce your costs or to up your data. Throughput, if you need more and just be more competitive, this is all about helping customers move faster, right? Making decisions about their network or switching networks or whatever it may be. And I think that that is a super defensible goal for any business in the tech industry, because this is a problem. And it's a problem that in many ways has been artificially constructed as a business competition barrier. And it's cool to see somebody starting to tear it down.

Actually, we are working with mobile operators and we try to visualize this opportunity. If I, for example, as a end customer, I have to choose between two networks, one being the premium networks, which is expensive. And the other one, which is cheaper with not a good coverage, I don't have to choose. I can use both. So having the ability to use both. Imagine that if, for example, you introduce the prepaid model where customers can buy your service for a day, but not to go to the shop, not to wait for shipping, et cetera, they just, they don't have coverage. And now they have coverage to your network. Sell them connectivity. Right on the spot. Right? So, so there is opportunity. And I think that, uh, it will take some time for operators to realize that there is opportunity. Uh, but definitely there is a benefit for the consumer and if something is good for the consumer, people will find the way to buy to get

it. Well, that's all the, uh, questions that I had for this episode. I just wanted to thank you Christus again for joining us. And before we close off, I wanted to have you tell people where they can find you online if you're online, anywhere and where they can follow for updates from you and your company.

Uh, they con contact, uh, me personally through my LinkedIn profile. Of course they can contact us through our websites, uh, contact from this is, uh, we respond to every request. We, we get a lot of different ideas, et cetera. We are open to everybody. We have. Actually received orders and customers from around 170 countries. So we see a lot of traction and we are open to developers that want to build on top of what we created. And we are also open to listen to customers that have maybe specific needs that we haven't thought about. So LinkedIn and on a website is I think, a good place to.

Okay, well, thank you for the outro. And as you've already mentioned, you can find David and i@esper.io. And this podcast is Android bites. We have a webpage up, but you can also find all our podcast episodes on blog, doper.io. So thank you again, Christmas for joining us. Thanks David, for joining me on another episode and thank you all for listening. See you next time.