QoS B: update of request parameter for serviceArea

[Masa8106]

Problem description
The present version of QoS Booking supports areaName, which can be human readable value, and then API invoker can specify an area where it want to use premium connectivity with specific QoS Profile.
At the same time, dedicated-network-areas API was defined in DedicatedNetworks repository. The API is for descovering available service area. It is been discussed to be generalise to use the API for other CAMARA APIs that DedicatedNetworks API. In the API, attributes such as id and name in ServiceArea schema are defined.
To utilise the dedicated-network-areas API, AreaName schema in QoS Booking needs to be updated in order to use id and name in ServiceArea of dedicated-network-areas API.

Possible evolution
AreaName schema in QoS Booking will be updated so that API invoker can specify an area by either id or name based on the invoker's preference.

Additional context
id in ServiceArea is unique value and name in ServiceArea is human readable value. Each attribute has own advantage nature. Therefore, it is considered to be good that API invoker can specify an area by either id or name based on the invoker's preference.

[jlurien]

So far, I assumed that the current name in QoS B AreaName was already a unique identifier for the area, similar to name in QoS Profile, but it has no description so there is space for improvement. If we decide to have a common Area APIs for CQM APIs it may have all sense to align QoS B with it, but we have to understand well the overall proposal (discovery + usage).

To identify an area in the request for QoS B we have to use in any case a unique unambiguous identifier, whether we call it id or name. Looking into the current DDNN proposal it seems that they define per Area, a serviceAreaId with UUID format and an optional name (with no description, is it unique?), and those identifiers are associated to a required area which is either a polygon or circle.

Before changing the identiifers in our API I would consolidate first the proposal about a common Area API.

[Masa8106]

@jlurien, Thank you for your comment.
I agree with the consolidation of the proposal about a common Area API.

As you pointed out, the current name in QoS B AreaName is assumed to be unique. However it is assumption. Technically it is not guaranteed to be unique. (As far as I recognise, this is a motivation to introduce id into the current DDNN proposal by Ericsson instead of name.)

I think there is difference advantage in each attribute, that is guranteed uniqueness for id and human-readable for name.

I guess the current DDNN proposal will be our common Area API. So I would like to propose that API customers can select one of attributes, which they want to use when they specify an area.
Please let me open a PR. I expect this PR will merge only after defining our common Area API.