[Scope Enhancement] Route QoS Prediction — trajectory-aware, per-segment QoS forecasting

[ALIIQBAL786]

Background

This proposal was approved in the CAMARA APIBacklog (camaraproject/APIBacklog#303) and Alberto suggested opening this issue to continue the discussion here ahead of the October 13 meeting.

What the current API does not cover

The existing retrieveConnectivity operation works well for area-based connectivity estimation, but there is no way for an application to submit a planned route and get back a per-segment QoS forecast before the device actually travels it.

This matters for cases like an ambulance dispatcher who wants to know which segments along the route have weak connectivity before departure, a fleet operator comparing two alternative routes by their expected QoS, or a drone operator validating that a planned flight corridor has sufficient coverage before authorizing it.

What this enhancement proposes

The core idea is straightforward: accept a list of waypoints as input instead of a polygon, and return a forecast per route segment in travel order. The specific additions on top of the existing API:

• Route input (waypoints) instead of an area or volume.
• Per-segment output with numeric latency, throughput, reliability and a confidence value.
• Device remains optional — the MVP should stay device-independent.
• Unavailable results handled via an outcome.status enum rather than silent omission.
• Optional forecast-change subscriptions, separate from the existing one-shot async callback.

Things like calling QoD, choosing between routes, or adapting a video stream are out of scope — they are useful composition examples but not part of the API itself.

A lint-clean OpenAPI definition is attached to the APIBacklog PR and can serve as a starting point for the discussion:
camaraproject/APIBacklog#303

[albertoramosmonagas]

Hi @ALIIQBAL786,

A few clarifications before October 13 would help us validate feasibility on the Telefónica side:

Route segmentation:

• How does the API segment the route? (Fixed distance intervals — 100m, 1km? Waypoint-to-waypoint? User-defined?)
• Do we have training data at segment granularity, or are we interpolating from area-level forecasts? Segment-level accuracy directly affects adoption.

Forecast-change subscriptions:

• The proposal mentions "optional forecast-change subscriptions, separate from the existing one-shot async callback." Is this a new webhook?
• Does it fire per-segment when a forecast changes, or aggregated at route level?
• If per-segment and a user submits a 100+ segment route, what's the webhook frequency ceiling to avoid spam?

QoD composition and the ambulance use case:

• QoD invocation is out of spec scope, understood. But for the ambulance dispatcher: who receives the per-segment forecast output?What decision does the application make with it?
• Even if composition is out of normative scope, a reference architecture diagram (informative) would clarify the intended data flow for implementers.