Proposal: Introduce optional edgeCloudFootprint field in EdgeCloudZone to represent zone coverage regions (OptimalEdgeDiscovery)

[clundie-CL]

Problem description
The current OptimalEdgeDiscovery response (EdgeDiscoveryResponse → EdgeCloudZone) provides identifiers and status for candidate edge zones but does not describe their geographic service coverage.

Application Providers often need a coarse geographic representation of a zone’s coverage to:

• Programmatically determine which edge zones overlap with a given device or service area, and
• Visually represent zones within their own UI or orchestration tooling (e.g., display eligible zones on a map).

In the absence of this information, Application Providers must rely on opaque zone names or out-of-band documentation, which limits automation and visualization capabilities.

Possible evolution
Introduce an optional areaFootprint field within EdgeCloudZone to convey an approximate service coverage area of the zone.

This field would support multiple geometry types to provide flexibility while preserving privacy of exact infrastructure coordinates.

Proposed schema addition:

EdgeCloudZone:
  properties:
    edgeCloudFootprint:
      description: |
        Approximate geographic coverage of this edge cloud zone.
        Enables application providers to understand service coverage or
        visualize the zone on a map. Exact infrastructure coordinates are not
        exposed. The operator chooses how to represent this footprint.
      oneOf:
        - type: object
          title: CircleFootprint
          properties:
            center:
              type: object
              properties:
                latitude:
                  type: number
                  format: double
                longitude:
                  type: number
                  format: double
            radiusMeters:
              type: number
              format: double
          required: [center, radiusMeters]
        - type: object
          title: PolygonFootprint
          properties:
            type:
              type: string
              enum: ["Polygon"]
              default: "Polygon"
            coordinates:
              type: array
              items:
                type: array
                items:
                  type: array
                  items:
                    type: number
                    format: double
                  minItems: 2
                  maxItems: 2
          required: [type, coordinates]

Example Response:

{
  "edgeCloudZones": [
    {
      "edgeCloudZoneId": "7ab123-9087-6543-ef12-3dc45f67gh89",
      "edgeCloudZoneName": "FrontRangeZoneA",
      "edgeCloudProvider": "CableLabs",
      "edgeCloudRegion": "us-mountain-1",
      "status": "active",
      "edgeCloudFootprint": {
        "center": { "latitude": 39.95, "longitude": -105.16 },
        "radiusMeters": 50000
      }
    }
  ],
  "applicationProfileId": "2fa85f64-5717-4562-b3fc-2c963f66afa0"
}

Key Points:

• Field is optional
• Intended for visualization and coarse selection only, not as an authoritative boundary
• Geometry choice (circle or polygon) left to the API Provider and conforms to well-known GeoJSON conventions

Alternative solution
A couple less flexible approaches were considered:

1. Region-level identifiers only. Sufficient for broad grouping but lacks visual or computational context for zone proximity.
2. Fixed “coordinate + radius” model only. Simpler but too restrictive; does not allow irregular service boundaries.

Additional context
In order to illustrate some of the UI uses cases this feature would support, the following are some examples assembled to highlight some purely illustrative use cases across different edge zone scales.

Regional Level

This is a zoomed out regional map highlighting a use case where a more rural subscriber my only have limited edge compute options where the closest network path is a metro-level edge compute zone in proximity to a device.

Metro Level

Zooming into the city level, multiple operators' coverage areas could be viewed.

Neighborhood Level

At a finer granularity, the following diagram highlights how multiple geometry types (circles, rectangles, and irregular polygons) can be used to reflect a mix of zone types:

• Neighborhood-scale compute zones
• Campus-level edges
• Highly localized compute nodes, e.g., a home AP with edge capability but obfuscated with course edges to preserve privacy.

[Kevsy]

I like the idea - just to say we should use the 'area' datatypes from CAMARA common.yaml, as they are used in DeviceLocation and other repositories.

There may also be value in including the region name as an option, as long as its easily understandable - it could be helpful in coverage scenarios where there is a simple divide, whereas more complex scenarios would benefit from the more granular area approach.

[JoseMConde]

Hi @clundie-CL , Thanks a lot for the contribution, I think could add some value to the API, always as an option.
Please take a look the Kev's comment and the next step should be to create a PR.

[ALIIQBAL786]

Hello everyone,

I have a question,

so there are multiple ways for the operator to exposure location in camara e.g. lon,lag and radius and ploygon.

Can't it effect the inter-operability of an application if it is using one method and the operator is supporting another?

[clundie-CL]

Hello everyone,

I have a question,

so there are multiple ways for the operator to exposure location in camara e.g. lon,lag and radius and ploygon.

Can't it effect the inter-operability of an application if it is using one method and the operator is supporting another?

@ALIIQBAL786 Thank you for the question. While I think you bring up a valid point, my thoughts are summarized below:

• This scenario likely exists more generally in regards to how API Consumers would manage APIs implemented across multiple operators where operators may not support endpoints/operations, have restrictions on the fields they support, or even the values they might support on a given field. This issue is in line with the motivation for the creation of the Capabilities and Runtime Restrictions API
• Even if your exact scenario would arise (application uses CIRCLE and provider returns POLYGON):
  • The application could add support for both, not sure if that would be a huge burden
  • If the application didn't want to support both, it could conceivably convert a polygon to a circle or a circle to a square (polygon) since this field represents a coarse coverage representation of the zone.

[maheshc01]

Summarizing my thoughts on the issue:

the different sub projects in the edge cloud API family is based on specific group of intents available here

The highlevel intent for optimal edge discovery to help application providers identify and make decision on which edge cloud zone they should deploy their apps. And for this decision making various inputs parameters(mandatory and optional) are supported as of today, shown below:

{ "device": { "phoneNumber": "+123456789", "networkAccessIdentifier": "123456789@domain.com", "ipv4Address": { "publicAddress": "84.125.93.10", "publicPort": 59765 }, "ipv6Address": "2001:db8:85a3:8d3:1319:8a2e:370:7344" }, "applicationProfileId": "string", "edgeCloudRegion": "us-west-1" }

As seen in the request body schema edgeCloudRegion is a optional input users can pass as input.
There is also a related helper API endpoint(GET /regions) for API users to get a list of edgeCloudRegions.
This was envisioned to support any potential data sovereignty or user preference requirements. And doesn't have any additional role to play in the optimal edge cloud zone discovery intent.

From the requirement perspective to show the edge cloud zone's geographic location is very much valid but its not the right fit along with the intents related optimal edge zone discovery. It might also be misleading to show the geo fence around the edge cloud zone which might incorrectly indicate to users that the devices within the given geo fence should connect to the specific edge cloud zone.
I see the requirements to be a better fit under Edge Application management. Please look at the endpoints GET /edge-cloud-zones and GET /clusters available here

We can consider expanding the schema in edge-application-management.yaml to include the additional information proposed as part of this issue.

[JoseMConde]

Thanks a lot for the feedback @maheshc01.
I am strongly agree with you, I have three aditional comments:

• I think we have to study the posibility to add this new schema inside EAM, but should we also change this schema in all the APIs that use EdgeClousZone, to have some consistency between APIs??

From the requirement perspective to show the edge cloud zone's geographic location is very much valid but its not the right fit along with the intents related optimal edge zone discovery. It might also be misleading to show the geo fence around the edge cloud zone which might incorrectly indicate to users that the devices within the given geo fence should connect to the specific edge cloud zone.

• Related to this parragraph, where Mahesh describe very well a posibility that the coverage area of one node contains a determinated user, but the user that is located on this area is not connected to the UPF of this node and thats not the optimal node for this user, but this also could happen with EAM, we could have a coverage area of one node, deploy the application in that node but one user that will be located inside the area could be connected to a different UPF and the optimal node should be another one.

[clundie-CL]

@maheshc01 @JoseMConde Thank you for the detailed feedback and for linking to the EdgeCloud-Intents-and-API-Mapping-Harmonisation.md document. I've been looking for this kind of consolidated documentation that captures the interplay across the API family, and it's been helpful for framing this discussion.

Your concern about geographic footprints being "misleading" is valid, and I think it stems from ambiguity in the proposal itself. After further consideration, I want to clarify the intended semantic:

The edgeCloudFootprint is not meant to represent the physical location of edge infrastructure (i.e., "the data center is roughly here").

Rather, the intent is to represent the geographic region from which devices would have optimal network paths to this zone, based on network topology — the coverage area within a given latency tier.

I believe this is a natural extension of the discovery API's existing capabilities. The core purpose of discovery is to help application providers determine which zones have optimal network paths to a device. An operator must already understand their network topology to resolve this. If that's true, then the following should hold:

1. Discovery APIs calculate network distance (latency via topology) from device connection point → edge zones
2. Operators must know their network topology to make this calculation
3. If they can solve "device at node Y → shortest path to zone Z," they can invert it
4. Inverted: "zone Z → all nodes where Z is optimal"
5. Those nodes (cell towers, APs) have physical locations
6. Therefore, an operator can define a boundary around "all physical locations where connecting devices would optimally route to zone Z"

Exposing this as edgeCloudFootprint would allow application providers to visualize and reason about zone coverage during planning without making individual discovery calls for every potential device location.

Does this reframing address your concern about misleading app providers? If so, I'll update the proposal description to make this semantic explicit.

That said, your suggestion to consider Edge Application Management raises a valid architectural question. This footprint data is zone metadata (pre-computed and device-agnostic), which doesn't fit neatly into a device-centric discovery call. However, EAM's intent is management, not discovery, and this information supports pre-deployment planning.

Perhaps the right pattern is a dedicated endpoint within OptimalEdgeDiscovery (similar to how GET /regions already provides device-agnostic context for discovery planning)? I'd welcome your thoughts on where device-agnostic, discovery-supporting zone metadata should live within the API family.

---

The following diagram captures the distinction between physical vs network proximity better. The device is physically closest to Zone B's infrastructure, but resides within Zone A's network footprint. Zone A's coverage area reflects the geographic region where devices have optimal network paths to that zone — determined by network topology, not physical distance to infrastructure.

[ALIIQBAL786]

@clundie-CL please correct me if I am wrong,

This functionality is meant to identify the area nearest to every respective zone by distance calculations. With a bunch of connection points, the system considers the distance of each connection point to all the available zones and determines the closest zone. The region of the closest zone is then chosen and sent back. An example would be that Zone A would have the shortest distance to the offered connection points of other zones and therefore the area of Zone A would be returned.

If it is correct, @JoseMConde I think this endpoint is specific to the OptimalEdgeDiscovery as it overlaps with its intent.
It focuses on discovery of optimal edge zone from a specific connection point.

[Kevsy]

Just an observation: I know of cellular network configurations where the geographic coverage may be misleading, because the network path to the User Plane Function / Packet Gateway has been load balanced and distributed nationally. In other words, I could be standing in the middle of the geographic region of a given edge cloud zone, but my network path means I would be better served by an edge cloud zone in another city closer to my UPF.

But I think that can be handled in the documentation of any operator in that situation, and of course, the actual lookup to determine 'optimal edge cloud zone' would account for that.

[gunjald]

In my view a given edge cloud zone may also be deployed to serve multiple geo locations so the multiplicity of location may also need to be factored in as part of the solution.
Also, as per my understanding the edge cloud zone concept was considered very closely to point to end users locations to which it is primarily designed to serve. With that point of view whenever the optimal edge cloud zone or geo locations associated with the given edge cloud zone was discussed it used to implicitly point to the end users locations but not the edge cloud location itself.

So this notion of end users location when referring the edge cloud zone serving footprint should be preserved unless we think there is some alignment still needed for the proper definition of the edge cloud zone serving location(s).

[maheshc01]

Device-Agnostic Requirement

One requirement that is clear to me is that the requested capability needs to be a device-agnostic call. The current API already supports this by making the Device object optional. Users can pass just the region of interest and application latency requirements (in the form of an application profile), and the API responds with a list of edge cloud zones that meet the criteria.

Breaking Down the Ask

If the ask is focussed more solely on being able to visually represent edge cloud zones, we would need two things:

1. Approximate location of the edge cloud zone
2. Approximate coverage area of the edge cloud zone
   I will share my thoughts on each of these.

1. Approximate Location
This is inventory/infrastructure metadata, not discovery information. My recommendation is to place this capability in EAM (GET /edge-cloud-zones) or another appropriate place the team sees fit — not within OptimalEdgeDiscovery.

2. Approximate Coverage
Today, discovery is primarily used with application latency requirements. Different applications have vastly different latency budgets — some latency-sensitive apps require sub-10ms, while others can tolerate 20–30ms. If we want to show a coverage area on a map, what would it actually indicate? Against what latency threshold?

If we go down this path, we would end up having to map out the most optimal edge cloud zone for very specific areas — as illustrated in some of the visualizations above (one street vs. another). Is that really the intent here? As @Kevsy pointed out, real-world configurations with nationally load-balanced UPFs can make geographic coverage misleading regardless of granularity.

My Proposal

Introduce a new endpoint: GET /edgeCloudZoneFootprint (potentially in OptimalEdgeDiscovery)

This endpoint would take latency (in milliseconds) as a required input parameter.
The output would be, for each edge cloud zone supported by the operator, a center point (latitude, longitude) and a radiusMeters representing the approximate coverage at that latency threshold.

This design addresses the ambiguity problem directly — the coverage footprint is only meaningful relative to a specific latency budget. A 10ms footprint looks very different from a 30ms footprint for the same zone.

This information can then be used by API callers for:

• Visual representation on a map
• Identifying overlapping coverage areas between zones
• Decision making around which edge cloud zones to target for app deployment
  Implementation note: Operators could implement this by approximating the latency-to-physical-distance conversion to calculate a circular geo-fence. I recognize this conversion is inherently imprecise (network topology, routing, UPF placement all affect actual latency). However, by making the developer explicitly specify their latency threshold, the approximation becomes context-aware rather than open-ended. The API documentation should clearly state that the footprint is an approximation intended for planning and visualization, not an authoritative coverage boundary.

@clundie-CL , hope i have understood your requirements accurately and my proposal meets what your are looking for. Please let me know your thoughts.

[gunjald]

I have one observation on the concept of "Approximate Location". As we discussed in past that the "Approximate Coverage" is something that indicate the suitability of an edge cloud to serve users in a given coverage area agnostic to the location of the edge cloud compute infrastructure. Till the network connectivity between the users and edge clouds are able to meet the QoS expectations as published by the operator, the physical location of the edge may not be of much concern.

The "Approximate Location" to me seems like representing the physical location of edge cloud compute infrastructure which an operator may not want to reveal but this reasoning is subjective and need more inputs from operators in case approximate location refers to physical location of edge cloud infrastructure.

I think we should clearly define what aspect "Approximate Location" represent w.r.t. to edge cloud location and the feasibility of exposing such information by the operator.

[Kevsy]

@mahesh thanks for the clear explanation, I generally agree, just one follow-up question on where this sits:

GET /edgeCloudZoneFootprint

There is some overlap here with the getEdgeCloudZones operation of EAM, which already accepts the query parameters status and region. If the requirement discussed here is device-agnostic, then it could be realised by adding a latencyBudget query parameter to getEdgeCloudZones. If that parameter is included then the information you described above is returned as well. This also allows the developer to filter the response by region and status. The documentation would change to reflect this, e.g.:

This discovery can be filtered by a specific geographical region
(e.g when data residency is need), by status (active, inactive, unknown), 
and can optionally return the coverage at a given latency budget.

WDYT?