eSIM and protocols of the GSMA SGP.02 specification: MTS case
In this post I’ll tell you how our team developed a service that allows you to manage a large number of eSIMs released specifically for such equipment.
My colleagues told me more about what eSIM is here. In this article we will talk about one of the options for using and applying the protocols of the GSMA SGP.02 specification.
Getting to know the technology
For reference: the SGP.02 standard is the same technology thanks to which eSIM chips can remotely record a digital SIM card. The final effect is completely similar to the operation in which a physical SIM card is inserted into the equipment with a slot.
Our business customer asked us to implement an interesting service. Organizations that own eSIMs purchased from us (hereinafter we will call them “partners”) should have been able to manage their cards.
We saw the following functions of the future service:
validation of partner requests for, for example, activation, deactivation and other actions with the profile. All requests are standardized according to SGP.02 and are the same for all members of the GSM association,
logging them,
authorizing a partner’s request and issuing permission or prohibition to execute it, depending on the rights to this eSIM.
In general, we ordered an admin panel for an MTS user with these capabilities.
Creating a service. Architectural solutions. Difficulties and overcoming them
The logic of operation of the business subsystem of telecom operators (BSS – business support system) with eSIM M2M technology is not covered by GSMA standards, and each telecom operator solves this problem as it sees fit. We wrote more about this in our other article.
Having studied the specification from GSMA and the place of MNO (Mobile Network Operator) in it, we began to formulate an architectural diagram of the solution:
We proceeded from the fact that in order to solve our problems, we need not only to identify the partner registered on the platform, but also to check his request before executing it.
The diagram below shows the process at a high level:
The consumer (our initiating partner) calls the identification service, presents the token previously issued to him, and enters the system. This is the 1st stage of request processing.
If everything is entered correctly, then our service (API vendor in the diagram) validates the request. Parses and checks key parameters from it.
The type of request, the object in respect of which the request was received, the current and target state of the object, and the current policy settings for the partner initiating the request are checked.
At the service level from the incoming request we check the specified request type from the parameter Action:
<wsa:Action>http://gsma.com/ES2/ProfileManagement/ES2-DownloadProfile</wsa:Action> For example, a request to download a profile. We also look at the values EID, ICCID in the request body and the values of some other parameters. This is the 2nd stage of request processing.
Finally, the final stage is to apply the policies and pass the execution request. If the request does not comply with the policy permissions, the request will be rejected with a 403 Forbidden error. The admin panel user can configure a policy for a partner.
Partner card with policy in the admin panel:
If all checks are passed, the partner’s request is executed by redirecting to the associated execution service, and the result is returned to him in the interface of our service.
Of course, minor modifications were needed to suit our needs on the part of related teams managing the common technical products that we used.
Among such solutions, for example, there may be monitoring and logging systems popular on the market.
We have also prepared a standard specification for our API for partners so that they can connect to us.
Backlog and new requests
As the product developed, new tasks of second priority began to appear.
For example, it was necessary to create a system of reports analyzing the status of eSIM partners. The user wanted to see in one window what state it was in, which eSIM belonged to which partner.
We have added detailed information for each card. For example, these:
ICCID (card serial number),
eSIM status at the moment,
reference data on connected services,
other data about the partner and his eSIM.
In the very first release, the user did not have access to this information. Now it was visualized on the front in the user’s admin panel.
Tabular part of the “SIM cards” section in the admin panel:
An example of an ordered report in the admin panel:
In some parts of the admin panel, we made an aggregation of parameters required by the customer. This simplified the perception of large amounts of data.
Another task was related to polling and updating the status (activity/inactivity) of SIM cards by contacting an adjacent external service and acting on SIM cards in case of their non-target status in an automatic mode according to a schedule.
This is where the difficulty arose. When transferring data via SIM to an adjacent service and processing it in bulk, errors were returned for some cards. The service we contacted did not have time to process all our requests. We solved this problem after additional joint tests.
It turned out that when we sent more than X requests to the execution service at once, sometimes errors occurred with TLS handshake.
We conducted load testing and found out at what load such errors do not occur at all. As a result, we had to fix it as a limit that our service should not exceed.
Another problem arose when setting the limit. We ourselves and our partners send requests for eSIM management. Naturally, we could not predict such a load and limit it in advance.
To deal with this, we developed the RequestsMaster module. It gradually takes requests from the queue and sends them for processing, adjusting the number of simultaneous tasks so as not to exceed the limit. Prospects and directions for product development
Our solution allows the partner owner of SIM cards to manage profiles on their eSIM, and the business user to manage the partner’s account and his rights to batches of SIM cards issued for specific tasks. You can also configure roles, policies, tasks (tasks) in the admin panel through it.
Over time, we can add new features to our solution upon request. Now, for example, we are introducing support for a new specification SGP.32 from GSMA.
Thank you for reading! If you have questions, write. I will be happy to answer them in the comments.
