Problem description
The current Optimal Edge Discovery (OED) API is oriented toward runtime or near-runtime edge selection, where an application provider wants to identify the best edge target for an active device or session context.
However, application providers may also need to make a pre-deployment planning decision before any deployment exists and before any active device context is available. In this case, the question is not “which edge is optimal for this device now?”, but rather “which edge options are viable in a target area for this application profile and its constraints?”.
Today, this planning step is not addressed explicitly. As a result, developers or aggregators would need to discover and compare operator capabilities separately, which limits automation for rollout planning and multi-operator edge assessment.
Possible evolution
Extend OED with a pre-deployment planning mode that complements the existing runtime optimization mode.
Possible enhancements could include:
- support for a geographic or service-area target context in addition to the current device-oriented context
- support for application-profile-based viability queries without requiring an active device/session
- returning a feasible set of candidate edge zones, instead of only a single optimal result
- inclusion of planning-relevant estimated metrics (for example latency envelope) to support go/no-go rollout decisions
This evolution should preserve OED’s developer-facing abstraction and should not expose operator-internal constructs such as DNN, S-NSSAI, internal routing policies, or topology details.
Alternative solution
An alternative would be to define a separate sibling API in the Edge Cloud family dedicated specifically to deployment planning.
That approach would provide semantic separation between:
- runtime optimization (current OED)
- pre-deployment viability assessment
However, since both use cases are forms of edge discovery and may rely on similar application constraints and performance estimation logic, extending OED may be a simpler path if the Working Group considers the conceptual scope still aligned.
Additional context
This enhancement is motivated by rollout-planning scenarios in which an application provider wants to evaluate where a latency-sensitive service can be launched before committing deployment work.
Illustrative example:
- target area: Patras, Greece
- application profile: low-latency cloud gaming
- constraint: p95 latency below 20 ms
Expected outcome:
- which candidate edge zones are viable in the target area
- through which operators / edge providers
- with what estimated performance envelope
The proposal is intended to support developer-facing planning and multi-operator aggregation, while keeping operator-internal realization hidden.
A short presentation has been prepared to explain the motivation, positioning, and expected behavior of the enhancement and can be attached or linked here for discussion.
CAMARA_EDP_API_presentation.pdf
Problem description
The current Optimal Edge Discovery (OED) API is oriented toward runtime or near-runtime edge selection, where an application provider wants to identify the best edge target for an active device or session context.
However, application providers may also need to make a pre-deployment planning decision before any deployment exists and before any active device context is available. In this case, the question is not “which edge is optimal for this device now?”, but rather “which edge options are viable in a target area for this application profile and its constraints?”.
Today, this planning step is not addressed explicitly. As a result, developers or aggregators would need to discover and compare operator capabilities separately, which limits automation for rollout planning and multi-operator edge assessment.
Possible evolution
Extend OED with a pre-deployment planning mode that complements the existing runtime optimization mode.
Possible enhancements could include:
This evolution should preserve OED’s developer-facing abstraction and should not expose operator-internal constructs such as DNN, S-NSSAI, internal routing policies, or topology details.
Alternative solution
An alternative would be to define a separate sibling API in the Edge Cloud family dedicated specifically to deployment planning.
That approach would provide semantic separation between:
However, since both use cases are forms of edge discovery and may rely on similar application constraints and performance estimation logic, extending OED may be a simpler path if the Working Group considers the conceptual scope still aligned.
Additional context
This enhancement is motivated by rollout-planning scenarios in which an application provider wants to evaluate where a latency-sensitive service can be launched before committing deployment work.
Illustrative example:
Expected outcome:
The proposal is intended to support developer-facing planning and multi-operator aggregation, while keeping operator-internal realization hidden.
A short presentation has been prepared to explain the motivation, positioning, and expected behavior of the enhancement and can be attached or linked here for discussion.
CAMARA_EDP_API_presentation.pdf