Skip to content

Route QoS Prediction - scope enhancement of Predictive Connectivity Data#303

Open
ALIIQBAL786 wants to merge 7 commits into
camaraproject:mainfrom
ALIIQBAL786:ALIIQBAL786-V2X-Exposure-API-Proposal
Open

Route QoS Prediction - scope enhancement of Predictive Connectivity Data#303
ALIIQBAL786 wants to merge 7 commits into
camaraproject:mainfrom
ALIIQBAL786:ALIIQBAL786-V2X-Exposure-API-Proposal

Conversation

@ALIIQBAL786

@ALIIQBAL786 ALIIQBAL786 commented Mar 6, 2026 •
edited
Loading

Copy link
Copy Markdown
Contributor

What type of PR is this?

  • enhancement/feature
  • documentation

What this PR does / why we need it:

This PR proposes Route QoS Prediction: trajectory-aware, per-segment QoS forecasting. An application submits a planned route (a list of waypoints) and receives a forecast of network conditions (latency, throughput, reliability) with a confidence value for each segment, before a device travels the route.

Following the API Backlog discussion, this is reframed as a scope enhancement of Predictive Connectivity Data (PCD) rather than a new V2X API family, and now follows the API Scope Enhancement template. It supersedes the earlier V2X Exposure API framing.

Relationship with Predictive Connectivity Data. PCD already forecasts connectivity for an area or volume over time. This builds on that model and adds the route dimension. The specific delta is:

  • route/corridor input instead of a polygon or geohash area;
  • per-segment output in travel order instead of grid cells;
  • numeric latency and throughput plus a confidence dimension, alongside PCD's categorical service levels;
  • optional forecast-change subscriptions, in addition to PCD's one-shot asynchronous callback.

Out of scope. The API only produces the forecast. QoD invocation, route optimisation or selection, and application adaptation are outside the normative scope and are shown only as examples of API composition.

TM Forum. TMF759 (Private Optimized Binding) and Private Optimized Connectivity sit on the management/NaaS layer, whereas this is a northbound predictive primitive whose output could feed such a decision. They therefore appear complementary rather than overlapping, still to be confirmed against the full TMF759 v5.0 specification.

Artifacts:

  • Scope enhancement: documentation/API proposals/APIScopeEnhancement_Route_QoS_Prediction.md
  • OpenAPI definition: documentation/SupportingDocuments/route-qos-prediction.yaml (lint-clean against the CAMARA Commonalities ruleset)
  • Presentation: documentation/SupportingDocuments/Route QoS Prediction API.pptx

Which issue(s) this PR fixes:

Fixes #302

Special notes for reviewers:

Reframed from a new V2X API family to a Predictive Connectivity Data scope enhancement, per the Backlog feedback. Northbound semantics (device-optional MVP, best-effort values, enum outcome model) are captured in the OpenAPI definition. Happy to review the field-level delta with @eric-murray and Connectivity Insights overlap with @kevin-smith.

Changelog input

 release-note
Reframe proposal as a Route QoS Prediction scope enhancement of Predictive Connectivity Data (route-aware, per-segment QoS forecasting with optional forecast-change subscriptions).

Additional documentation

docs
Supporting material: OpenAPI definition and presentation for the Route QoS Prediction scope enhancement.

@albertoramosmonagas

albertoramosmonagas commented Mar 6, 2026

Copy link
Copy Markdown
Contributor

Hi @ALIIQBAL786 ,

Thanks for creating the Backlog issue and the API proposal PR, and for sharing the supporting material. It’s good to see a potential new API that could be incorporated into the CAMARA API family. I’ll include the proposal in next week’s Backlog agenda.

Before the session, a few quick points that came up while reading the proposal (we can cover everything live in the Backlog call):

  • CAMARA capability vs MEC wrapper: today it can read as “a CAMARA façade over ETSI MEC 030 via a Transformation Function”. It would help to explicitly define the northbound service semantics (key entities/resources and portability expectations) and keep the TF/MEC mapping as implementation guidance.

  • Service API vs Operate/Platform boundary: terms like “provisioning” (especially anything that sounds like radio/network provisioning) may trigger out-of-scope concerns. Please make clear this is developer-facing service exposure (service-level configuration/info needed by apps/vehicles), not network management.

  • Overlap positioning: since you reference QoS/QoD and other CAMARA APIs, please clearly state what is in-scope for V2X Exposure and what is out-of-scope (covered by existing CAMARA APIs). Otherwise the discussion risks getting stuck on “this API does too much”.

  • Subscriptions alignment: if you propose a unified subscription entry point for multiple event types, make sure it follows CAMARA/Commonalities subscription patterns. Even before YAML, a short description of subscription semantics (filters/geo scoping, event types, error model) in the PR will make the review much more concrete.

@ALIIQBAL786

ALIIQBAL786 commented Mar 6, 2026 via email

Copy link
Copy Markdown
Contributor Author

@ALIIQBAL786

ALIIQBAL786 commented Mar 10, 2026 via email

Copy link
Copy Markdown
Contributor Author

@albertoramosmonagas

albertoramosmonagas commented Apr 15, 2026

Copy link
Copy Markdown
Contributor

Hi @ALIIQBAL786,

Thanks all for the offline exchanges so far. We received a message from Gianmarco at nextgcloud, and we've been discussing the API proposal internally.

To keep the evaluation transparent and aligned with the normal CAMARA backlog process, I think the discussion should continue here in the backlog thread rather than through additional 1:1 discussions.

After reviewing the current material and the feedback shared so far, we do not think the proposal is yet sufficiently framed as a concrete CAMARA API demand.

At the moment, the slides read more like a connected ambulance / V2X solution architecture than a clearly isolated CAMARA northbound API capability. The material combines a vertical use case, ETSI MEC V2X Information Service, a Transformation Function, QoD/QoS composition, and potentially additional APIs. In that form, it is still unclear what the single concrete CAMARA capability is that should be proposed here.

From a CAMARA perspective, it would be important to reformulate the proposal in a more focused and use case-neutral way. In particular, please update the backlog material to clarify:

  1. One concrete candidate capability only: Please avoid describing a broad “V2X API” or the overall connected ambulance solution. Instead, isolate one specific candidate capability that CAMARA should define.

  2. CAMARA northbound semantics independently of MEC: Please define the canonical entities/resources, expected behavior, portability expectations across operators, and what is left to implementation. MEC mapping / TF logic can be useful as implementation guidance, but should not be the core definition of the CAMARA API.

  3. Clear scope boundary: Please explain what is in scope for the proposed API and what is explicitly out of scope, especially versus existing CAMARA APIs and versus Operate/platform concerns.

  4. Explicit overlap / gap analysis: Since the slides already reference QoD/QoS and other CAMARA capabilities, please explain what is already covered by the current CAMARA portfolio, what could be composed from existing APIs, and what concrete gap remains.

  5. Subscription model, if applicable: If eventing/subscriptions are part of the proposal, please describe the event types, filters (including geo scoping if relevant), lifecycle, and error model in a way aligned with CAMARA/Commonalities patterns.

  6. Operator support / implementation realism: Please indicate which operator(s) realistically see this as a candidate CAMARA API to implement and maintain, and whether the proposal depends on enablers/platform functions that cannot be assumed to exist broadly across operators.

If useful, you may add one high-level diagram only insofar as it helps explain that single candidate capability. I would avoid expanding the full PoC solution architecture further unless it directly helps clarify the API proposal itself.

Once the proposal is updated in that form, it will be easier for the backlog group to assess whether:

  • there is a real need for a new CAMARA API,
  • the topic should instead be addressed by composition of existing CAMARA APIs, or
  • the topic is outside CAMARA scope.

CC: @tanjadegroot, @hdamker, @MarkusKuemmerle

@albertoramosmonagas

albertoramosmonagas commented Jun 11, 2026

Copy link
Copy Markdown
Contributor

Hi @ALIIQBAL786,

Thank you for presenting the updated proposal during today’s API Backlog session.

Below is a brief summary of the remaining action points and the next steps discussed during the meeting.

Outstanding action points

AP2 — Define the normative CAMARA northbound semantics independently of MEC

Status: Partially addressed

The updated proposal is more focused, but several elements of the northbound contract still need to be defined clearly and independently of the underlying implementation:

  • What exactly is deviceId (e.g. MSISDN, IP address, network access identifier or another identifier)?
  • Is deviceId functionally required for the MVP, or could the initial capability remain device-independent?
  • What does reliabilityScore represent, and what is its scale?
  • What does confidenceLevel represent, and is it comparable across operators?
  • Which outputs are guaranteed and which should be interpreted as best-effort estimations?
  • How should missing, insufficient or unavailable data be represented?

Please define these semantics explicitly, including the expected treatment of unknown or unavailable outcomes, for example through a well-defined enum-based outcome model or an equivalent pattern.

AP4 — Align subscriptions with CAMARA/Commonalities patterns

Status: Pending

The revised proposal still includes subscriptions for forecast-change notifications. If subscriptions remain within scope, please align the design with CAMARA/Commonalities patterns, including:

  • event types;
  • filtering model, including geographic or route-based scoping;
  • subscription lifecycle;
  • notification payload model;
  • error handling;
  • security and data-minimisation considerations.

It would also be useful to separate clearly:

  1. the existing asynchronous callback used to return the result of a retrieval request; and
  2. an ongoing subscription to future forecast changes.

These are different interaction patterns and should not be conflated.

AP5 — Clarify overlap and positioning within the existing CAMARA portfolio

Status: Partially addressed — further review required

The updated slides provide a first overlap analysis, but the positioning still needs to be refined.

Some elements in the proposal are currently mixed together, which makes the capability look like an L4 solution flow rather than a single horizontal CAMARA building block. In particular, QoD invocation, route optimisation and application adaptation should remain outside the normative scope of the API. They can be documented as useful examples of API composition.

Please review the proposal with @eric-murray and discuss the potential overlap with Connectivity Insights with @kevin-smith.

From the Predictive Connectivity Data perspective, my initial assessment is that there is also a significant overlap with the existing Predictive Connectivity Data API. The current API already provides future connectivity estimations for a geographic area or volume and explicitly includes drone flight planning and autonomous-car route planning among its use cases.

The meaningful delta introduced by this proposal appears to be more specific:

  • native route or corridor input instead of a polygon-based area;
  • route-segment output instead of grid-cell output;
  • potentially richer forecast metrics, such as latency, throughput, reliability and confidence;
  • optional ongoing notifications when the forecast changes, which would be different from the existing asynchronous response callback.

Based on this, my preliminary recommendation would be to assess the proposal as a potential scope enhancement of Predictive Connectivity Data, rather than progressing it directly as a new V2X API family or as an update of the original V2X Exposure API proposal.

WDYT @eric-murray?

AP6 — Review related TM Forum capabilities

Status: Pending

Please review the following TM Forum capabilities and document the outcome of the analysis:

The objective is to clarify whether they overlap with the updated proposal, complement it or are no longer relevant following the scope refinement.

Immediate next step

As an immediate action, please update the Issue and the PR so that they accurately reflect the revised scope, including:

  • title;
  • description;
  • API proposal content;
  • supporting presentation;
  • relationship with the original V2X Exposure API proposal;
  • overlap analysis against the existing CAMARA portfolio.

Please also clarify whether the original V2X Exposure API proposal remains active as a separate proposal or should be withdrawn.

Additional information required for the Predictive Connectivity Data review

To make the assessment actionable, please provide:

  1. A precise delta analysis against the current Predictive Connectivity Data YAML, covering:

    • route or corridor input vs polygon input;
    • route-segment output vs grid-cell output;
    • proposed QoS metrics vs the existing service-level connectivity model;
    • persistent prediction lifecycle vs the current retrieval operation;
    • asynchronous response callback vs ongoing forecast-change subscriptions.

  2. The intended semantics of the proposed latency, throughput, reliability and confidence metrics, including how missing or insufficient data would be represented.

  3. A clear explanation of whether deviceId is required for the MVP.

  4. A separation between:

    • the core route-aware predictive-connectivity retrieval capability; and
    • optional forecast-change subscriptions.

CC: @camaraproject/api-backlog_codeowners

@eric-murray

eric-murray commented Jun 22, 2026

Copy link
Copy Markdown
Collaborator

@albertoramosmonagas @ALIIQBAL786

I discussed with @Kevsy as to whether the updated proposal fitted within the scope of Connectivity Insights, and the conclusion was that Connectivity Insights is not intended to be predictive beyond the immediate future nor beyond the current location of the specified device. So whilst that API can provide alerts if the current channel quality cannot meet a specified minimum requirement, it is not intended to provide these alerts for future (anticipated) locations for the device.

For that reason, I think this fits better in Predictive Connectivity Data. Currently, that API is defined for generic service levels independent of any specific device. Part of the discussion will be around whether Predictive Connectivity Data should be extended to be predictive for a specific device, or to remain generic in its predictions.

@albertoramosmonagas

albertoramosmonagas commented Jun 22, 2026

Copy link
Copy Markdown
Contributor

@albertoramosmonagas @ALIIQBAL786

I discussed with @Kevsy as to whether the updated proposal fitted within the scope of Connectivity Insights, and the conclusion was that Connectivity Insights is not intended to be predictive beyond the immediate future nor beyond the current location of the specified device. So whilst that API can provide alerts if the current channel quality cannot meet a specified minimum requirement, it is not intended to provide these alerts for future (anticipated) locations for the device.

For that reason, I think this fits better in Predictive Connectivity Data. Currently, that API is defined for generic service levels independent of any specific device. Part of the discussion will be around whether Predictive Connectivity Data should be extended to be predictive for a specific device, or to remain generic in its predictions.

One key question is whether the API should remain device-independent or support device-specific predictions. My preference is to keep it device-independent unless there is a strong justification for requiring deviceId, as that introduces additional privacy and portability considerations.

Suggested next steps @ALIIQBAL786:

  1. Treat this as a Predictive Connectivity Data enhancement rather than a V2X Exposure update. If you're agree we can rename the issue, the PR, and the documentation accordingly and treat the issue in predictive connectivity date creating a new issue.
  2. Keep QoD, route optimisation and application adaptation out of scope.

CC: @camaraproject/api-backlog_codeowners

@albertoramosmonagas

albertoramosmonagas commented Jul 14, 2026

Copy link
Copy Markdown
Contributor

Hi @ALIIQBAL786,

Thanks for uploading the OpenAPI definition.

From my side, the YAML mostly addresses the previous concern around the northbound semantics: it clarifies that the API is implementation-independent, that the forecast values are best-effort/non-binding, that device is optional, and that unavailable results are handled through outcome.status.

For Backlog, I think the main open points are now:

  1. Portfolio fit / overlap: Please clarify the exact gap this API addresses within the current CAMARA portfolio, what is already covered by existing APIs, what would be composed from other APIs, and what is explicitly out of scope.
  2. Proposal framing: The PR is still framed as “V2X Exposure API”, but the current scope is now “Route QoS Prediction”. Please update the Issue/PR title and description so they reflect the actual proposal.
  3. TM Forum review: Please also close the pending review against TMF759 / Private Optimized Connectivity, or state explicitly if it is no longer relevant after the scope change.

QoD invocation, route optimisation and application adaptation should remain outside the normative scope of the API and be treated only as composition examples.

CC: @camaraproject/api-backlog_codeowners

@ALIIQBAL786

ALIIQBAL786 commented Jul 14, 2026

Copy link
Copy Markdown
Contributor Author

Thanks, and good to hear the YAML clears up the semantics question.

On portfolio fit: the real gap here is forecasting QoS along a planned route, segment by segment, before the device gets there. Predictive Connectivity Data already forecasts connectivity for an area or volume, so rather than stand this up as a separate API, I think it fits best as an enhancement of PCD. What it actually adds on top is route input instead of a polygon; output broken down per route segment, with numeric latency and throughput plus a confidence value; and the option to subscribe to forecast changes over time. To be clear on scope, the API only produces the forecast. Things like calling QoD, choosing between routes, or adapting the stream sit outside it and are just shown as examples of how you might compose it with other APIs.

On the TM Forum side, TMF759 and Private Optimized Connectivity live on the management/NaaS layer, they select and bind connectivity, whereas this is a northbound prediction that could feed into that kind of decision. So I'd read them as complementary rather than overlapping. I still want to confirm that against the full TMF759 v5.0 spec, which is behind TM Forum membership.

And you're right about the framing, I'll update the Issue and PR title and description so they reflect the current Route QoS Prediction scope rather than the old V2X one.

@albertoramosmonagas

albertoramosmonagas commented Jul 14, 2026

Copy link
Copy Markdown
Contributor

Thanks @ALIIQBAL786. For the next step, please update the Issue and PR title/description accordingly, including:

  • the new Route QoS Prediction framing;
  • the relationship with Predictive Connectivity Data;
  • the specific delta: route input, per-segment output, numeric QoS metrics/confidence and optional forecast-change subscriptions;
  • the out-of-scope clarification for QoD, routing and application logic;
  • the current TMF759 / Private Optimized Connectivity assessment, noting that it appears complementary but still requires confirmation against the full TMF759 v5.0 specification.

One additional process point: if the conclusion is that this should progress as an enhancement of Predictive Connectivity Data, then the proposal should no longer be handled as a generic API Proposal for a new API family. It should be reframed as an API Scope Enhancement instead, following the corresponding Backlog process/template.

Once this is reflected in the PR/Issue, I think the Backlog discussion will be much cleaner and we can focus on whether the enhancement should progress within the Predictive Connectivity Data context.

CC: @camaraproject/api-backlog_codeowners

@ALIIQBAL786 ALIIQBAL786 changed the title V2X Exposure API proposal Route QoS Prediction - scope enhancement of Predictive Connectivity Data Jul 14, 2026
albertoramosmonagas
albertoramosmonagas reviewed Jul 14, 2026
View reviewed changes
Comment thread documentation/API proposals/APIScopeEnhancement_Route_QoS_Prediction.md
@@ -0,0 +1,70 @@
# API Proposal

@albertoramosmonagas albertoramosmonagas Jul 14, 2026

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Don't forget to modify the current API proposal to the Scope enhancement template: https://github.com/camaraproject/APIBacklog/blob/main/documentation/API-Scope-Enhancement-Template.md

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

@albertoramosmonagas albertoramosmonagas albertoramosmonagas left review comments
@eric-murray eric-murray Awaiting requested review from eric-murray eric-murray is a code owner
@jgarciahospital jgarciahospital Awaiting requested review from jgarciahospital
@Noel-Wirzius-DT Noel-Wirzius-DT Awaiting requested review from Noel-Wirzius-DT
@caubut-charter caubut-charter Awaiting requested review from caubut-charter caubut-charter is a code owner
@FrimanJan FrimanJan Awaiting requested review from FrimanJan FrimanJan is a code owner

At least 1 approving review is required to merge this pull request.

Assignees

No one assigned

Labels

Scope Enhancement

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

[API Scope Enhancement] Route QoS Prediction (Predictive Connectivity Data)

3 participants

@ALIIQBAL786 @albertoramosmonagas @eric-murray