Performance metric definitions do not match those of the QoD API

[eric-murray]

Problem description
The performance metric definitions for this API do not match those of the QoD API. Unless there is a very good reason for this, definitions should be harmonised. Remaining harmonised with the definitions used in the 5GFF flavour of this API is not a good reason.

Expected behaviour
The performance metric definitions adopted by the QoD API can be found here. The Connectivity Insights API should adopt the same definitions for metrics which are common. Currently, these are:

Connectivity Insights	QoD
maxLatencyMs	packetDelayBudget
minDownlinkthroughputKbits	targetMinDownstreamRate
minUplinkthroughputKbits	targetMinUpstreamRate
maxPacketlossPercent	packetErrorLossRate
maxJitterMs	jitter

Note that the associated QoD schema definitions are complex objects, defining both quantity and units.

Alternative solution
None

Additional context
N/A

[Kevsy]

Thanks @eric-murray

Agree we need to be consistent - although I do like the Connectivity Insights approach of appending the metric for clarity. Was that discussed in QoD at all?

Also I see QoD has packetDelay instead of latency (which is fine), but why jitter instead of packetDelayVariation?

[eric-murray]

The problem with fixing KPI units now is that it does not easily allow application of the API to alternative or future networks. Throughputs of over 1 Petabits/ second have already been demonstrated over fibre optic cables, and that would be a large number if expressed in kbits / second. And jitter for fixed networks can be measured in μs or less, which would be a very small number when expressed in ms.

Allowing the unit prefix to be separately specified is useful for the same reasons that SI defined prefixes in the first place. It also allows for the value itself to be an integer, which simplifies error checking.

packetDelayVariation was proposed for QoD, but jitter was agreed as most application developers have some idea what it means, even if they don't understand it is an ambiguous term with several alternative definitions.

[Kevsy]

Thanks @eric-murray , I agree we should adopt the QoD schema for these performance metrics.
@maheshc01 any thoughts?

[Kevsy]

Fixed in #15