eSIM

Robustel Are Stress Testing Their SGP.22 eSIM Implementation. Good. But Also – Why SGP.22?

27th April 2026 · 6 min read
Robustel eSIM Stress Testing

David Evans, Global IoT Solution Architect at Robustel, posted on LinkedIn this week asking partners to submit LPA strings for SGP.22 stress testing. The ask is simple: if you can provide an activation string, Robustel will run it through their SGP.22 Router+Cloud implementation and check interoperability.

Most people will scroll past it. That would be a mistake.

The implementation Robustel are testing

Robustel’s eSIM whitepaper is unusually direct about how this all works. Their current product range – from the compact R1511e through to the 5G R5020Le – runs SGP.22. The whitepaper says it plainly: “In today’s deployments, Robustel’s eSIM solution is built on the GSMA SGP.22 architecture.” Each device carries a Kigen MFF2 eUICC with Robustel’s own LPAd embedded into RobustOS, which handles the communication with the SM-DP+ platform for profile downloads, activations and switching.

That is a real, production-grade eSIM implementation across their full router range. It is not marketing.

What David Evans is doing now is asking external partners to throw real-world LPA strings at it before customers find problems in the field. An LPA string looks like a simple activation code on paper. In practice, different operators and SM-DP+ platforms implement the same spec with enough variation that a string that works perfectly on one combination can fail silently on another. A router that cannot pull a profile on first boot in a remote cabinet is an expensive support call. A fleet that provisions correctly on one operator’s platform and fails intermittently on another can take weeks to diagnose properly.

Testing with internal inputs will not find those problems. External strings from across the partner ecosystem will.

So why is it SGP.22?

SGP.22 started life as a consumer specification – built for smartphones, QR codes, and users who are present when provisioning happens. As we covered in our SGP.22 vs SGP.32 technical guide, the architecture hands most of the profile lifecycle control to the mobile operator. That works fine if you are selling handsets. It creates real friction when you are trying to manage thousands of unattended devices across multiple operators and geographies.

SGP.32 was built to fix that. The IoT Profile Assistant removes the need for a full on-device LPA. The eIM hands control back to the enterprise rather than the operator. CoAP over UDP replaces HTTPS, which matters enormously for NB-IoT devices where a daily data budget might be measured in kilobytes. The full spec comparison is at sgp32.co.uk, but the headline is straightforward: SGP.32 was designed for exactly the environments Robustel’s routers get deployed in.

So the obvious question is: why are they still on SGP.22?

The answer is not complicated. When Robustel designed the hardware that is currently in the field, SGP.32-certified modules were not commercially available. SGP.22 infrastructure was widely deployed, operator support existed, and the SM-DP+ ecosystem was mature. Building on SGP.22 was not a mistake, it was the only practical option at the time. Their whitepaper acknowledges directly that SGP.32 is where they are heading. But the installed base is SGP.22, and that is what is out in remote cabinets and on energy sites right now.

That is precisely why the stress testing matters.

Teltonika are in the same position

Teltonika’s eSIM-capable hardware – the RUT241, RUTX50, and the RUTM16 and RUTM20 – all run SGP.22 as well. Their response to the same limitation has been to layer Remote Management System on top, adding server-initiated profile management on top of a consumer spec. Teltonika call it “the best of both worlds” – SGP.22 compatibility with SGP.32-style remote control. For routers and gateways, it holds up well in practice.

The Teltonika and Tele2 SGP.32 bootstrap work at sgp32.co.uk shows both vendors are moving, but neither has a production SGP.32 range shipping at volume yet. The two biggest names in industrial IoT routing are both hardening a spec they know is transitional, because that is what the current ecosystem demands.

Robustel’s stress testing is part of the same pattern.

The interoperability gap nobody talks about

GSMA certification means a device meets the spec. It does not mean two certified devices from different vendors, running different SM-DP+ platforms, will interoperate cleanly in every scenario. There is a gap between those two things, and that gap is where real deployments go wrong.

The only way to find those boundary conditions is to test against inputs you did not design for. That is what Robustel are doing. LPA strings from different operators, different platforms, different regions, and different device configurations will surface edge cases that internal QA cannot reach by design. It is unglamorous work and most vendors do not do it publicly.

The lessons from this testing will also carry forward. As Robustel and the wider industry move toward SGP.32, the organisations that have done this kind of rigorous interoperability work on SGP.22 will ship cleaner SGP.32 implementations. They already know where the bodies are buried.

If you are a partner with an LPA string to share, David Evans’ post is worth a few minutes of your time.

What the openness tells you

Most vendors do not make calls like this publicly. Asking the partner ecosystem to break your implementation requires a certain confidence in the underlying engineering, and a willingness to find out that something does not work before a customer does. That combination is rarer than it should be.

For anyone buying or specifying Robustel eSIM hardware, it is worth filing away. How a vendor behaves when they are doing unglamorous testing work tells you more about their support culture than any product sheet.

The SGP.22 to SGP.32 transition is coming. The vendors taking this seriously in the meantime are the ones worth watching when it arrives.

Related reading:

NOTE FOR PUBLISHING:

  • Replace LINKEDIN_POST_URL (x2) with David Evans’ actual post URL
  • Add featured image – Robustel router or eSIM/eUICC graphic
  • All internal IoTPortal links verified live April 2026