add tele-operation service level #53

Activity

1. vlasatno

   added

   enhancementNew feature or requestNew feature or request

   on May 19, 2026
2. albertoramosmonagas commented on May 19, 2026

   

   albertoramosmonagas

   on May 19, 2026

   Contributor

   More actions

   Hi @vlasatno,

   From a product scope perspective, I think TELE_OPERATION is aligned with Predictive Connectivity Data, since the API already covers terrestrial planning scenarios such as autonomous car route planning, not only aerial/drone use cases.

   That said, I would not treat this as a simple enum-only addition. In this API, serviceLevel directly affects how GC, MC, NC and ND are interpreted, so adding a new service level has semantic and implementation impact.

   There is also a broader design point here: we should avoid turning serviceLevel into a catalogue of vertical-specific use cases. If we add TELE_OPERATION, it should be defined as a reusable technical service-level pattern, not as an automotive-specific label. Otherwise, we may open the door to future enum values for every sector-specific scenario, which would weaken the interoperability of the API.

   I would suggest a few changes before merging:

   1. Make the description more generic and not limited to the automotive sector. TELE_OPERATION could apply to remote operation of vehicles, robots or machines requiring bidirectional low-latency control plus high-throughput sensor/video feedback.

   - TELE_OPERATION: Intended for remote operation of vehicles, robots or machines requiring bidirectional low-latency control and high-throughput sensor or video feedback. The connectivity values indicate whether the provider's prediction model expects the requested area, time, height and network type to satisfy the criteria associated with this service level.

   2. Clarify whether the criteria behind TELE_OPERATION are standardised by CAMARA, provider-defined, or implementation-specific. Without this, different operators may expose the same enum value with different practical meanings.

   3. Explicitly state that TELE_OPERATION does not imply any network performance guarantee, operational safety guarantee, service availability commitment, or authorisation to perform tele-operated activities. It should remain a predictive connectivity estimation service level, not a QoS assurance or safety certification mechanism.

   4. Add a specific 422 error for cases where TELE_OPERATION is a valid CAMARA service level but not supported by a specific API provider/deployment, for example:
      PREDICTIVE_CONNECTIVITY_DATA.UNSUPPORTED_SERVICE_LEVEL.

      This would keep a clear distinction between:

      • unknown/invalid service level value → 400 INVALID_ARGUMENT;
      • valid service level but not supported by the provider → 422 UNSUPPORTED_SERVICE_LEVEL.

   5. Add at least one request example and corresponding feature test for TELE_OPERATION.

   At minimum, we need to make the semantic boundaries explicit and confirm the approach with the rest of the API participants.

   WDYT @camaraproject/predictive-connectivity-data_codeowners?
3. hlkyt commented on Jun 22, 2026

   

   hlkyt

   on Jun 22, 2026

   More actions

   Hi @albertoramosmonagas ,

   Following last meeting's call, I'd like to inform you that I synced offline with TNO colleagues.

   As stated during the call:

   1. We're fine in making the description more generic - not limiting to the automotive sector.
   2. TELEOPERATION is an implementation specific service Level (more discussion below).
   3. TELEOPERATION does not in any way imply any network performance guarantee, operational safety guarantee, service availability commitment, or authorisation to perform tele-operated activities
   4. We can add a specific 422 error for cases where TELE_OPERATION is a valid CAMARA service level but not supported by a specific API provider/deployment.
   5. We can add at least one request example and corresponding feature test for TELE_OPERATION.

   Other than that, based on @eric-murray comments - we are flexible with the providing more detailed info, like expected data rate for TELEOPERATION etc and we could consider applying this service Level by combining C2 and STREAM_4K. But we want first to understand the rationale.
   As said above TELEOPERATION is implementation specific. For example depending on the use case, the amount of cameras might change, thus the needed bit rate and throughput. That is also our understanding of how C2 and STREAM_4K are created, as there is no specific (to the best of our knowledge) throughput, data rate or any other requirement for these serviceLevels.

   So, why should TELEOPERATION differ from that? Are there specific requirements the other two service levels must meet? Again, we're happy to give any information needed, but first we have to properly capture the logic of this API and make sure we're aligned.
4. albertoramosmonagas commented on Jun 22, 2026

   

   albertoramosmonagas

   on Jun 22, 2026

   Contributor

   More actions

   Hi @albertoramosmonagas ,

   Following last meeting's call, I'd like to inform you that I synced offline with TNO colleagues.

   As stated during the call:

   1. We're fine in making the description more generic - not limiting to the automotive sector.
   2. TELEOPERATION is an implementation specific service Level (more discussion below).
   3. TELEOPERATION does not in any way imply any network performance guarantee, operational safety guarantee, service availability commitment, or authorisation to perform tele-operated activities
   4. We can add a specific 422 error for cases where TELE_OPERATION is a valid CAMARA service level but not supported by a specific API provider/deployment.
   5. We can add at least one request example and corresponding feature test for TELE_OPERATION.

   Other than that, based on @eric-murray comments - we are flexible with the providing more detailed info, like expected data rate for TELEOPERATION etc and we could consider applying this service Level by combining C2 and STREAM_4K. But we want first to understand the rationale. As said above TELEOPERATION is implementation specific. For example depending on the use case, the amount of cameras might change, thus the needed bit rate and throughput. That is also our understanding of how C2 and STREAM_4K are created, as there is no specific (to the best of our knowledge) throughput, data rate or any other requirement for these serviceLevels.

   So, why should TELEOPERATION differ from that? Are there specific requirements the other two service levels must meet? Again, we're happy to give any information needed, but first we have to properly capture the logic of this API and make sure we're aligned.

   Hi @vlasatno,

   The points you listed address most of my concerns, especially making the description more generic, explicitly stating the non-guarantee nature of the service level, adding the unsupported service level error, and including examples/tests.

   On the rationale behind the criteria for TELE_OPERATION, I think your question is fair. I'm not suggesting that TELE_OPERATION should be held to a stricter standard than C2 or STREAM_4K. If the current API does not define normative latency, throughput, jitter, packet loss or availability thresholds for the existing service levels, then it would be inconsistent to require that only for TELE_OPERATION. For me, the key point is slightly different: adding TELE_OPERATION exposes a broader semantic question around serviceLevel in general.

   My understanding is that the current service levels are predefined communication requirement categories used by the provider’s prediction model, rather than CAMARA-standardised QoS profiles with fixed technical thresholds. In other words, GC, MC, NC and ND are interpreted relative to the selected serviceLevel, but the concrete criteria behind each service level are provider-defined / implementation-specific unless the API explicitly standardises them.

   If this is also the group’s understanding, then I think TELE_OPERATION can follow the same model. We just need to make that explicit enough to avoid false interoperability expectations. So instead of requiring detailed data rate or latency values only for TELE_OPERATION, I would suggest adding a general clarification to the ServiceLevel description, for example:

   Service levels represent predefined communication requirement categories used by the API provider's prediction model to classify expected connectivity. Unless explicitly stated otherwise, the detailed technical criteria associated with each service level are provider-defined and implementation-specific. Service levels do not represent standardised QoS profiles, network performance guarantees, service availability commitments, or operational safety approvals.

   Then TELE_OPERATION could be described along these lines:

   - TELE_OPERATION: Implementation-specific service level intended for remote operation of vehicles, robots or machines requiring bidirectional low-latency control and high-throughput sensor or video feedback. The connectivity values indicate whether the provider's prediction model expects the requested area, time, height and network type to satisfy the criteria associated with this service level.

   Regarding the idea of combining C2 and STREAM_4K, I see the conceptual link, but I would be careful with that approach. Today the API request accepts a single serviceLevel, and there is no formal composition model such as C2 + STREAM_4K. A consumer could query both separately and combine the results client-side, but that would not be the same as having a provider-defined composite service level for tele-operation. If the group wants service level composition, that probably deserves a separate discussion.

   So my proposal would be:

   1. Treat TELE_OPERATION consistently with the existing service levels.
   2. Clarify that service-level criteria are provider-defined / implementation-specific unless explicitly standardised.
   3. Add PREDICTIVE_CONNECTIVITY_DATA.UNSUPPORTED_SERVICE_LEVEL.
   4. Add the request example and feature test.

   WDYT? @eric-murray
5. vlasatno commented on Sep 28, 2026

   

   vlasatno

   on Sep 28, 2026

   Author

   More actions

   Hello @albertoramosmonagas

   I have incorporated most comments as I understand them from the above discussion. Afterwards I have merged with main. Some questions remain.

   1. What inconsistencies are you referring to? Are they still present after my recent commit?
   2. Clarification added in the service level description.
   3. Pulled in the UNSUPPORTED_SERVICE_LEVEL from upstream main.
   4. I do not see how the addition of the service level warrants a new example and/or test. There is only one example currently and there are three service levels. Of course the UNSUPPORTED_SERVICE_LEVEL response is a new testable scenario and should have a test, but that was present in upstream main.