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

Activity

1. albertoramosmonagas commented on Sep 22, 2026

   

   albertoramosmonagas

   on Sep 22, 2026

   Contributor

   More actions

   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.
2. ALIIQBAL786 commented on Oct 9, 2026

   

   ALIIQBAL786

   on Oct 9, 2026

   Last edited by ALIIQBAL786

   Author

   More actions

   Apologies for the late reply.

   Hi Alberto, thanks for the detailed questions. These are exactly the right things to nail down before October 13.

   Route segmentation

   The intended model is waypoint-to-waypoint: the application submits an ordered list of up to 50 waypoints and gets back one forecast entry per consecutive pair, with startWaypointIndex and endWaypointIndex referencing the original list. Granularity is controlled by how densely the application places its waypoints.

   On training data: the API is intentionally implementation-agnostic here. Whether an operator derives segment-level predictions from area-level forecasts via interpolation or from native segment-granularity models is left to the implementation. Segments where confidence is too low return a non-AVAILABLE outcome.status (INSUFFICIENT_DATA, OUT_OF_COVERAGE, NOT_SUPPORTED, or UNAVAILABLE) with null metric fields, so the application handles it explicitly rather than receiving silently degraded values.

   Forecast-change subscriptions

   Yes, a CloudEvents webhook over HTTP following CAMARA Commonalities patterns. Notifications are per-segment; each event carries a segmentId. The anti-spam mechanism for long routes is the segmentIds filter in SubscriptionDetail: the subscriber scopes notifications to only the segments it actually cares about rather than receiving events for the full route. The subscription also supports subscriptionMaxEvents (auto-cancel after N events) and subscriptionExpireTime for lifecycle control.

   Event types: qos-degradation-forecast, qos-recovery-forecast, and prediction-expired.

   QoD composition and the ambulance use case

   The intended flow: the dispatcher app calls the Route QoS Prediction API before the ambulance departs, receives the per-segment forecast, identifies segments where outcome.status is AVAILABLE but reliabilityScore falls below an acceptable threshold, and triggers QoD on those segments to pre-establish a prioritized session. The ambulance then travels a route where connectivity has already been prepared on the weak legs.

   A reference architecture diagram as an informative annex is a reasonable ask and I am happy to include one ahead of the October 13 meeting.
3. albertoramosmonagas commented on Oct 9, 2026

   

   albertoramosmonagas

   on Oct 9, 2026

   Contributor

   More actions

   Thanks for the detailed clarifications, this addresses the key points. A few final checks from my side:

   • Route segmentation & training data: The waypoint-to-waypoint model with user-controlled granularity makes sense. On training data: implementation-agnostic is fine, but do you have guidance for operators on whether segment-level interpolation from area forecasts or native segment models yield better accuracy?
   • Forecast-change subscriptions & anti-spam: The segmentIds filter handles the long-route case well. One clarification: if an operator optimizes segments in real-time (e.g., rerouting due to network changes), does the subscription continue on the original segmentIds, or does the app re-submit the route? Need clarity for app developers.
4. ALIIQBAL786 commented on Oct 12, 2026

   

   ALIIQBAL786

   on Oct 12, 2026

   Last edited by ALIIQBAL786

   Author

   More actions

   Thanks Alberto.

   On training data: we intentionally leave the implementation approach to the operator. That said, the response's confidenceLevel and confidenceBand fields give applications a direct signal of prediction quality regardless of how the operator derived it. An operator interpolating from area-level forecasts will naturally produce lower confidence scores than one with native segment-granularity models; the accuracy difference surfaces in the output itself, so there is no need for normative guidance on the approach.

   On subscription behavior during network re-optimization: the subscription stays tied to the original segmentIds. If operator-side conditions change on a subscribed segment (say a base station fails and throughput on segment 4 drops), a qos-degradation-forecast event fires on that segmentId automatically. The app does not need to re-submit. However, if the application decides to take a different physical route, it re-submits the new waypoints to get a fresh forecast. Route re-optimization is intentionally kept in the application layer, not the API.
5. ALIIQBAL786 commented on Oct 13, 2026

   

   ALIIQBAL786

   on Oct 13, 2026

   Last edited by ALIIQBAL786

   Author

   More actions

   As promised, here is the reference architecture diagram as an informative annex ahead of today's meeting.

   

   The diagram shows:

   • The 5-step application flow (submit route → forecast → identify weak segments → trigger QoD → depart)
   • Route QoS Prediction API as a scope enhancement of the existing Predictive Connectivity Data API
   • CloudEvents async notifications per-segment (dashed purple arrow)
   • Operator Network as a black box (implementation at operator discretion)
6. albertoramosmonagas commented on Oct 13, 2026

   

   albertoramosmonagas

   on Oct 13, 2026

   Last edited by albertoramosmonagas

   Contributor

   More actions

   Thanks @ALIIQBAL786, all clear on my side. We’ll wait for @eric-murray here. Given that we’re closing the current meta-release, my proposal would be to target 15 November as the deadline to open a first draft PR. This gives enough runway to incorporate the architecture diagram as an informative annex and consolidate the segmentation and subscription design before the next cycle starts.
7. ALIIQBAL786 commented on Oct 13, 2026

   

   ALIIQBAL786

   on Oct 13, 2026

   Author

   More actions

   Thanks Alberto, sounds good. Looking forward to Eric's input.
8. albertoramosmonagas

   added

   enhancementNew feature or requestNew feature or request

   on Oct 13, 2026