Skip to content

V2X Exposure API proposal#303

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

V2X Exposure API proposal#303
ALIIQBAL786 wants to merge 5 commits into
camaraproject:mainfrom
ALIIQBAL786:ALIIQBAL786-V2X-Exposure-API-Proposal

Conversation

@ALIIQBAL786

@ALIIQBAL786 ALIIQBAL786 commented Mar 6, 2026

Copy link
Copy Markdown
Contributor

What type of PR is this?

Add one of the following kinds:

  • enhancement/feature
  • documentation

What this PR does / why we need it:

This PR introduces a new API proposal for a CAMARA V2X Exposure API in the API Backlog.

The proposal explores how ETSI MEC V2X Information Service capabilities can be exposed through CAMARA northbound APIs, enabling developers to access V2X services through a simplified and standardized interface.

The API is motivated by smart mobility and smart city use cases, including connected emergency vehicles, collision risk detection, and cooperative traffic services. The proposal is based on ongoing projects such as CASCAD-e and ToMOVE (City of Turin), which demonstrate edge-enabled mobility scenarios using MEC infrastructure.

The goal of this proposal is to gather feedback from the CAMARA community and evaluate the potential creation of a new V2X API family within the project.

Which issue(s) this PR fixes:

Fixes #302

Special notes for reviewers:

This PR provides the initial proposal for discussion in the API Backlog Working Group.
Feedback from the community is welcome regarding scope, alignment with existing CAMARA APIs, and potential collaboration with ETSI MEC V2X specifications.

Changelog input

 release-note
Introduce API proposal for CAMARA V2X Exposure API enabling standardized access to V2X services leveraging ETSI MEC capabilities.

Additional documentation

This section can be blank.

docs
Supporting material: CASCAD-e and ToMOVE smart mobility projects demonstrating edge-enabled V2X use cases.

@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

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

Reviewers

@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

@albertoramosmonagas albertoramosmonagas Awaiting requested review from albertoramosmonagas albertoramosmonagas 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

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

[API Proposal] V2X Exposure API

2 participants

@ALIIQBAL786 @albertoramosmonagas