Create a mapping table for qos_profiles

[shilpa-padgaonkar]

No description provided.

[shilpa-padgaonkar]

The mapping table has been relocated to https://github.com/camaraproject/QualityOnDemand/blob/main/code/API_definitions/QoSProfile_Mapping_Table.md

[shilpa-padgaonkar]

This mapping table addresses:-
We should agree on what ‘Throughput_S/M/L’ and ‘LOW_LATENCY’ mean, and document their mapping to standard 3GPP QCI/5QI values. This is quite important to 1) guarantee replicability and reproducibility of results when testing solution in two different telco networks; 2) ensure 3rd party has a clear understanding of what every tag means.

[eric-murray]

THROUGHPUT_L should map to "Fastest available" - i.e. unrestricted by the mobile network operator. This is something of a "best effort" type definition, but reflects the fact that the peak throughput will be anyway limited by the radio channel over which the mobile operator has little control.

Mapping THROUGHPUT_S and THROUGHPUT_M to specific maximum throughput values is reasonable, and the current proposal of 10 and 30 Mb/s is also reasonable. But the problem here is these values might become outdated as networks evolve or may not fit with particular business cases. Values should be published as guidance for developers, but mechanism such as that proposed in Issue #7 is required so that the current throughput levels available to the target UE can be determined via the API itself.

[jordonezlucena]

Agree with VF's thoughts. For THROUGHPUT_S and THROUGHPUT_M, the reference values are for internal validation purposes (within CAMARA). O
And totally agree on the need to make profiles discoverable as proposed Issue #7. But then we should agree on value ranges for individual profiles, so that we can offer consistent experience to the customer (across a global footprint) while allowing for differentiation across operators (either because of different network capabilities or linked to different service offering strategies). We can revisit these value ranges after conducting first validations, based on lessons learnt.

[Marcin-Jarzab]

Issue has been discussed and current solution/proposal agreed on weekly 22.04.meeting.