Scope issue for next iteration of IoT Device Management

[rkandoi]

Problem description

This issue is the umbrella issue for scoping / discussing next set of features in the IoT Device Management domain.

[rkandoi]

Here is my view on potential set of capabilities and their priorities:

1. eSIM Profile Management API v0.2.0

1.1 Callbacks and events

The current APIs don't support callbacks or events.
This is a much needed capability for any practical deployment.

CAMARA has excellent guidelines for the technical API designs for both the above.
https://github.com/camaraproject/Commonalities/blob/main/documentation/CAMARA-API-Event-Subscription-and-Notification-Guide.md

There are two models, implicit and explicit.
Implicit is "callbacks" and explicit is a separate "/subscriptions" endpoint to create such event requests.

In my view, we need both. This is a relatively straight forward additive approach.

1.2 eSIM Profile Ordering capability

The current APIs assume that the network and device are already configured and can be used for eSIM state management on the device / eUICC.
This new capability should add the pre-requisites for ordering eSIM profiles and the result should be such that the eSIM profile is then ready for download and use.

We suggest to consider multiple eSIM profiles and resulting inventory requirements as part of the initial requirements.

There are two ways to introduce this capability, a new API "eSIM Profile Ordering" API or part of the existing "eSIM Profile Management API".
We are open to both and perhaps this judgement can be made once we know how similar or different the schemas are from the current API.

On a high level, we anticipate the following requirements:

• An enterprise should be able to browse the various service plans and their capabilities.
  E.g., service plan A has 10 GB data.
  Cost information in the API is not essential in the initial scope since commercial agreements can vary based on the requirements and use case.
  However, before ordering anything, it is important to define what is being ordered.
  In this case, an enterprise is ordering eSIM Profiles with one selected service plan.

  So, a GET /service-plans type endpoint.
  This should presumably be its own API - "Service Plans API".

• An enterprise should be able to order eSIM profiles.
  The result is such that the system is configured (EIM, SMDP+, packet core, etc.) for use.
  I am not sure how / when the EUICC and EIM bindings take place and would rely on the group's expertise for comments.

2. Subscription Management API (v0.1.0)

Traditionally this API is used to manage the network state associated with a "network subscription", i.e., much like how eSIM Profile Management address state management on the device side, the Subscription Management API allows managing state on the network side.

These states are usually connected with use cases related to billing, or controlling when a device can be used or not.

This capability is closely related to the provisioning capability in the ordering phase.
My view is that we can address this capability better, once we have a clearer understanding of the ordering and provisioning flows.

This may or may not be related to the current task.

3. Batch operations for state management

While useful, I think we should still focus on feature completeness first. Batch operations will likely look quite different than the single device operations in any case. Once we have a good baseline for all the capabilities in IoT Device Management, it will be easier to develop a unified batching capability across all the features.

[david-bohaty-thalesgroup]

Thanks for the information. I am attaching presentation that was shared in the call on 22.9.2026. The content is quite in line with your proposals.

Thales_Camara_Next_Steps.pdf