Development and Implementation of LPA Bridge, Easing eSIM Use with IoT Devices, and Calling for Proof of Concept (PoC) participants

By now an experienced engineer, I have been involved in the industry as a tech guy for more than 30 years, as noted in my profile, while keeping a side-eye on the progress in computers and mobile communications.

Overview

Around three years ago, IIJ Mobile launched its eSIM service. At the time the decision was made to begin eSIM service, I was thinking it would be disappointing if the only use-case was in devices like the iPhone, other smartphones and some types of PCs. I began wondering if we could also provide eSIM service for LTE routers, IoT devices and the like; in other words, whether it would be a simple matter to develop such devices with built-in eSIM (eUICC^*1). From there we have finally come to the stage of starting PoCs. Here I would like to look back at how we got to this point, and describe some of the technical details, while explaining what IIJ provides in the PoC and what the Company intends to do together with the participants of the PoC.

First of all, what is a SIM, and what is an eSIM?

What is the SIM that comes with a smartphone, etc. for mobile communication?
As many of you may already know, a SIM (Subscriber Identity Module) is a kind of “tiny computer,” with its own microprocessor unit (MPU), storage, and memory, on which a Java program runs.
The hardware features encrypted storage to prevent tampering, and is set to self-destruct in case of repeated attempts at unauthorized access, making it a highly secure system. Physically, the card type is like the credit cards you all carry around in your wallet.
A conventional SIM is issued with the information needed for communication (called the SIM profile,^*2 consisting of IMSI, MSISDN, Ki, etc.) already stored in the SIM as a container. For an eSIM, on the other hand, the container and information are managed separately. The OS is extended so that the information can be put in the container on demand and the SIM functions enabling communication can be completed. In addition, an applet running on the system handles the SIM profile operations, and multiple profiles can be stored.
A SIM and eSIM differ only in their functionality, as physically both can have either a card or IC chip form factor.

Development of the elements making possible the eSIM PoC discussed here

First was collecting and reading the documentation.
I went around hunting for and reading eSIM documentation, including Official Document SGP.2x – RSP Architecture issued by the GSMA^*3 and ETSI TS 131 122 issued by 3GPP.^*4
Two implementation architectures have been specified, as shown in Figure 1.
These are the M2M model and consumer model, of which the M2M model is intended for use with IoT devices.
Since the IoT and other devices for which the M2M model is intended lack a rich user interface, a bootstrap profile is preconfigured in the eUICC as the base communication profile, which has access to the SM-SR platform arranged for in advance. A SIM profile is obtained from an eSIM server (SM-DP) in accord with rules set in the accessed SM-SR.
Although I wrote “obtained,” as a use case, there is the “push” model, where a unitary-model IoT device is shipped to multiple destinations and the SIM profile decided in advance for the environment where it will be installed is pushed into the SIM.
This model is difficult to implement without deep involvement of the SIM vendor and mobile network operator.

Figure 1. Two eSIM architectures
Source: GSMA_eSIM-Whitepaper-v4.11

The consumer SIM model, on the other hand, is a “pull” model that truly respects the will of users, independent from both the SIM vendor and mobile network operator; but here, also, there are two problems.

The first is that it requires a communication bearer for downloading a SIM profile from an eSIM server over the Internet, to enable communication. (A chicken-or-egg problem?)

The second, something that may seem a bit strange, is that no matter which document you look at, the architecture is designed as in Figure 2 so that the LPA^*5 running on the device MPU communicates directly with the eUICC.

Figure 2. Implementation of the consumer model in a device
Source: SGP.22 RSP Technical Specification Version 2.2.2

Nearly all IoT devices don’t have an I/O bus that would enable the MPU on which applications run to access the eUICC. Instead, communication with the eUICC must be done via a separate computer called a communication module (modem), which is connected in advance at a UART serial port.

Figure 3. Standard implementation inside an IoT device

While the documents give details of each of the APDU for direct operations on the eUICC, there is nothing about how to access the eUICC via a communication module. (To be sure, it’s easy to understand why people say they can’t be bothered with implementation using the communication modules made by vendors.)
Could it be that in the case of a smartphone the circuit shown in red is electrically possible?

At this point, we put a temporary halt to implementation of a consumer eSIM for IoT devices.

Could this also be an encounter? An idea that had been forgotten is reincarnated by a new way of looking at things

Then in spring of 2021, a certain vendor introduced us an app that can read/write/disable/delete a SIM profile on a card-type eUICC after connecting a smartcard (SIM card) reader to a PC by USB cable. This turned out to be the spark leading to development of LPA Bridge.

I should note that LPA Bridge was announced in a press release.
IIJ Announces LPA Bridge, New Technology Enabling Consumer eSIM Use with Wearable and IoT Devices

My first impression upon the app was that it had no obvious use, however. Why would anyone want to go to the trouble of downloading a SIM profile from an eSIM server and writing it to a card-type eUICC, not at all in wide use, and plug that into the SIM socket of a device? What were they thinking when they made this app? So I took his business card and left it at that.

A few days later, when I was drinking, it suddenly dawned on me. I started thinking that just maybe, this could be a gamechanger.
So I got in touch with the vendor and said I would like to talk with the engineer and product manager.
Then I explained my own idea to the engineer who had developed the application, and we began discussions.

Did we find the part that was missing?

Figure 4.

The first problem that I noted above, the need for a communication bearer with Internet access for downloading a SIM profile to enable communication (Figure 4 (1)) is solved nicely by using the connectivity that a PC has.
And that brings us to the second problem, how to establish a communication between the LPA app and eUICC.

Communication by USB cable ⇒ Wi-Fi or BLE (Bluetooth Low Energy)

If communication by USB is possible, socket communication, converting the device files in the LPA app, should also be possible, right? … “That would be easy”
So we can use the Wi-Fi or BLE of an existing IoT device and connect it to the LPA app on the PC.
Then, if we can make it so the IoT device looks to the LPA app like an eUICC, we should be able to use it as is, right?

Implementing by smartcard R/W ⇒ virtualization by app

With a bit of investigation, we discovered that nearly all communication modules have AT commands for SIM operations, which are not documented in the manuals.
If that is the case, we could try logically bypassing the communication module by creating a kind of translator, so that the device application that is the recipient of the socket communication behaves like an eUICC to the LPA app running on a PC, sends the received APDU to the eSIM through some bypassing path in the communication module, converts the received values once again to APDU, and returns them to the LPA app.

Figure 5. Smartcard R/W using LPA Bridge

Shown here is an overall image of the newly developed LPA Bridge.

LPA Bridge gets its name from its role as a kind of bridge between the eUICC over at the communication module and the LPA app.
# As an aside, just in case someone figures out the way this works and starts getting ideas, we have applied for patents on the approach and implementation, without being certain how that will turn out.

Figure 6. General overview

Concerns were raised that putting such a program in a device would let someone wrongfully overwrite the eSIM contents. As long as LPA Bridge is not running, however, no one can access the eUICC module as an eSIM, merely it can be recognized by a communication module as a conventional SIM (UICC) card containing an activated SIM profile.
Device security can therefore be guaranteed by properly managing startup control of this app.

Specifically,

As a reference implementation, an eSIM environment can be created without modifying the existing IoT device hardware, running on a Linux OS widely used in routers, and mounting a card-type eUICC (which I had thought was a minor type with no use potential) in the SIM card socket.
Put simply, just by implementing in an existing device the LPA Bridge source codes provided by IIJ and a card-type eUICC, it becomes a device supporting consumer model eSIM service. It is then possible to think about the details such as how it works, its use cases, and the business model.

The normal approach would be to mount a chip-type eUICC in the product; but the hurdles for getting into the eSIM world, like PCB pattern modification for mounting the eUICC chip, become more formidable.

The purpose is to have engineers get into the eSIM world first of all with the minimum modifications to what is already existing.

For implementation in an existing device (mainly transplanting work), a reference model will be supplied at the same time, with LPA Bridge and the Quectel EC25-J LTE module, used in a relatively large number of LTE routers and gateways, installed on Raspberry Pi, and with a card-type eUICC set in the SIM socket.
# Compatibility has been confirmed also with SIMCom and Seiko Solutions communication modules.

Your own device can be made eSIM-ready while tracing operations step by step.
We will assist with testing by flexibly providing SIM profiles for loading into the eUICC, which had been an invisible obstacle up to now.

The IIJ’s business model and monetization

The biggest advantage of the consumer model eSIM is that it completely frees the device vendor/user from the MNO (carrier including Full MVNO).
In other words, the ability to obtain and use the necessary communication at the necessary timing from any desired MNO, without sticking one particular MNO ≒ It is of course OK to download a SIM profile from an eSIM server other than one provided by IIJ Mobile. (This is fully conformant with the standard specifications.)

“That looks interesting, but where and how can we make money from it?” This is a totally unsurprising to ask, as a company that pays salaries and gets us to work.

• Maybe we could offer paid license of LPA Bridge for use in devices? … Hmm, not so sure that’s a good idea.
  # This would go against the original purpose of enabling anyone to build an eSIM-supporting device and having all kinds of devices become eSIM-ready.
• How about commissioned development of LPA App for PCs and smartphones? … That’s not in line with what we want to do.
• We could make it available for downloading only from IIJ eSIM servers. … I thought we were supposed to have nothing but contempt for that sort of crowd.
  # Clearly, if you want to make the biggest ripples, the stone you throw had better be a big one.
• Another idea would be to have the LPA available only via a gate server, a kind of toll gate, and charge a fee at that point. … Not so sure about that one, either.
  # Would the fees extracted be commensurate with the costs of running the system with responsibility for high availability?
  # This relay server that we first implemented on a trial basis turned out to be a valuable debugger that let us check out the behavior of various eSIM servers. (LOL)

Assuming a world in which practically every communication device was eSIM-ready, it would become possible to buy “communication” anywhere in the world, just like we buy “AAA batteries” today.
In such a world, it would seem efficient to have all eSIMs handled not by carriers but by e-commerce giants like Amazon and Alibaba.

When the rules of the game change….

Tossing a stone at the current business model and disrupting the market…that’s how far I’m willing to promote this, taking responsibility for what happens.
As for how profits will be created, I’ll leave that up to the star players in the future markets born out of the newly created business model.
# In reality, if a monetizing model were in sight, I’d have started a new company.

Invitation to PoC, my original intention

Already, companies developing devices with SIM cards have begun to study use cases and business models for devices in which the SIM card is simply replaced by an eSIM, as we talked about earlier.
Maybe you are thinking about creating a communication-enabled device and starting up a new service. Perhaps you want to take an interesting-looking gadget from overseas and modify it for a domestic service you plan on starting. Or you would like to create something by taking a product that was originally designed on the basic model where the service provider or device vendor arranged for the communication and, if it becomes possible to procure communication on demand, to extend the form of service provision or the form of device usage accordingly.
As product supplier, we very much welcome the challenge of expanding the market with eSIM vendors.

We can give demonstrations on a reference model built on Raspberry Pi.
Those who are interested, or would like to help make eSIM the natural choice, or anyone else, we look forward to hearing from you.

Terms, Abbreviations