add tele-operation service level

[vlasatno]

Problem description
TNO, within the European funded ENVELOPE project, is using the predictive connectivity data API to facilitate a tele-operated use case, with automotive industry partners. The available service levels do not fit our use case.

Possible evolution
A simple addition to the ServiceLevel enum would solve this issue.

[albertoramosmonagas]

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?