Discussion on overlapping with IoT Data Transfer Activation API

[FabrizioMoggio]

The IoT Data Transfer Activation APi was recently proposed in APIBacklog (camaraproject/APIBacklog#144)

During the presentation, a possible partial overlap with the DedicatedNetworks API, was suggested API (https://lf-camaraproject.atlassian.net/wiki/spaces/CAM/pages/46268427/2024-11-28+API+backlog+minutes)

It was decided to start a Discussion.

Considering the IoT Data Transfer Activation API, the relation with the DedicatedNetwork API can be seen as the following.
The IoT Data Transfer Activation API focuses exclusively on IoT Devices. When a device included in the transfer window via API, it's automatically profiled as an IoT device. It can, for example, set the SIM default APN to be one specific for IoT (actual implementation could vary based on operator policies).
From a more technical point of view, there are also other differences. The DedicatedNetwork API focuses on reserving resources in a specific location of the network. Devices in an IoT fleets can be located in different geographical position so the IoT Data Transfer Activation API does not introduce this kind of constraint. Moreover, the idea in the DedicatedNetwork API seems to make reserved resources unusable while in the Reserved state. IoT Data Transfer Activation API does not reserve resource until the start time of the scheduled transfer and it reserves them only for the devices that are actually connected (i.e., if some device goes offline, no network resource is allocated).

[tlohmar]

Some random feedback:

IoT Devices

We have not discussed any special device requirements for Dedicated Networks. The basic assumption is that the device is capable of using IP as transport. The devices can certainly be Non-SmartPhones / IOT devices, like a Professional Video Camera, Credit Card Readers or CCTV Cameras. My reading of the IoT Data Transfer Activation API is that devices are configured with an APN (or DNN), thus, also use IP as Transport.
Note, an example realization of a Dedicated Network can be an APN (2G/3G/4G) or DNN (5G).

Moreover, the idea in the DedicatedNetwork API seems to make reserved resources unusable while in the Reserved state

the resources can be used by other users, while the dedicated network is in Reserved state. It can be compared with reserving a reserving a hotel room: The hotel makes the hotel room accessible only during the reserved time. The hotel room can be used by other guests, while the room is in a reserved state. Of course, the hotel room can also be constructed only for the reserved time. It seems to be the same concept in the IoT Data Transfer Activation, that a time window for data transfer is reserved before the actual data transfer.

IoT Data Transfer Activation API does not reserve resource until the start time of the scheduled transfer and it reserves them only for the devices that are actually connected

Isn't the data transfer a future data transfer and isn't there a reservation, about the scheduled time window? I think, the intention of the IoT Data Transfer Activation API can also be phrased as "IoT Data Transfer Activation API allows reserving data transfer resources for a time window and a geographical area.". The idea is that the devices can execute the data transfer during the time window, meaning, enough data transfer capacity is available.

(i.e., if some device goes offline, no network resource is allocated).

The Dedicated Networks allows reserving resources, in case an API consumer (like a festival organizer or a media producer) needs a certain connectivity performance. The reservation does not implicitly include a requirement or assumption, that the reserved resources are actually used (similarly, there is the concept of a No-Show when reserving hotel rooms).

The concept of scheduling a time window for a data transfer (i.e. reserving a time window) seems identical to reserving a dedicated network for a specific time (i.e. the dedicated network offers a certain connectivity performance). In both cases, transmission capacity is reserved and the targeted capacity is only available for the selected devices within the scheduled time window (and service area). Still, there can be other differences.

[varanto]

Thanks for your feedback.

I see that there are similarities and the transfer part can be achieved in both API. What is still unclear to me is whether the Dedicated Network API allows for a specific profiling of the devices involved in the transfer. In fact, in the IoT API we know that it's targeted for IoT fleets and all the configured network resources takes into account this nuance. Is it possible to specify something similar also in the Dedicated Network API?

[varanto]

Just wanted to provide a quick update on our discussion regarding the IoT Data Transfer Activation API. After further review, we’ve decided to focus this API specifically on IoT-related features to ensure it aligns closely with the needs of IoT use cases. To streamline functionality and avoid overlap, we’ll leverage the Dedicated Network API for resource scheduling, since it already does what we had in mind regarding those aspects.

This approach should help us maintain a clear separation of responsibilities between the two APIs. However, one question that came up: does the Dedicated Network API return some kind of identifier (e.g., a request ID) that we can use to correlate the resource scheduling request with the corresponding request in the IoT Data Transfer Activation API? This would help us maintain traceability and ensure seamless integration between the two APIs.

[tlohmar]

In principle, the Dedicated Network API will provide some identifier. However, details are not yet clear.
It is suggested to create a separate issue on the DN API to track the progress and to have the discussion on the "does the Dedicated Network API return some kind of identifier (e.g., a request ID) that we can use to correlate the resource scheduling request with the corresponding request in the IoT Data Transfer Activation API?".

[tlohmar]

The discussion on the question "does the Dedicated Network API return some kind of identifier (e.g., a request ID) that we can use to correlate the resource scheduling request with the corresponding request in the IoT Data Transfer Activation API?" is continued in the new Issue #17