Finding suitable areas where a reservable connectivity service can be provided

[tlohmar]

Problem description

The discussion around API alignment clarified the needs and issues around finding suitable areas, where the reservable connectivity service is provided. The network of the API provider may not support the connectivity performance for all NWProfiles anywhere in the network coverage. Thus, reservation requests for networks may fail, because the requested service area does not support the required connectivity performance needed by the requested NW profile. Note, the API invoker (customer) assumes, that the connectivity performance of the NW profile is consistently provided anywhere within the requested service area (with a certain degree of confidence).

The Dedicated Network API uses area names, but there is no programmatical support for resolving an area name into a GeoShape (e.g. Polygon of GPS coordinates). API customer is made aware about usable area names during the on-boarding procedure.

Discussion:
When the network reservation request fails, the API response may provide hints for tuning a retry so that the next retry has a higher chance of success.

An alternative workflow may add a lookup / search procedure as a pre-step before the network reservation request.

• Such a search procedure may take different input parameters (search criteria) such as the area of interest.
• The output of such a search procedure can be a list of areas, where each output area is described by a GeoShape (e.g. polygon of GPS coordinates), supported network profiles within this service area, etc.

Possible evolution

Alternative solution

Additional context

[Masa8106]

Thank you for raising the issue. I thought same thing through the API alignment discussion.
Regarding the workflows, I understand there are two possible workflow. In my opinion, the latter one to add a lookup/serch procedure would be better than the first one to provide hints for tuning a retry, because the latter is surer approch to search areas and can be avoid that API consumer send API requests many times.
Reagarding the latter approach, can we consider an API as a API invoker inputs GeoLocation and then a list of relative areas (and that GeoShape) returns.

[Masa8106]

Reagarding the latter approach, can we consider an API as a API invoker inputs GeoLocation and then a list of relative areas (and that GeoShape) returns.

Now I am thinking that the above can be realised by atLocation request in your proposed API.