Problem description
Quality of Service (QoS) Profiles define the performance characteristics offered by Service Providers to API consumers. These profiles are intended to be technology-agnostic, representing specific performance requirements (such as latency, jitter, and throughput) regardless of the underlying network layer.
However, there is currently no standardized naming convention for these profiles. This lack of uniformity creates significant friction for API consumers. For example: Provider A may use voice, Provider B may use VC, Provider C may use QOS_VOICE_CALLING, and Provider D may use QOS_VOICE
Without a standard nomenclature, API consumers cannot intuitively understand a profile's purpose or performance tier by its name alone. This inconsistency leads to multiple issues including name space ambiguity and interoperability.
Therefore, a standardized naming framework across all Service Providers is needed. Standardizing these names will simplify consumptions, set right expectations, and enhance transparency.
This needs a discussion and a proposal. To jump start the discussion we can use the following model to construct the names: [NAMESPACE]_[CATEGORY]_[CHARACTERISTIC]
Example: QOS_VOICE_REALTIME
This standard must remain extensible, allowing providers to expose specialized capabilities—such as specific 5G network slices—using a uniform QOS_EXT_[Provider]_[Feature] naming convention.
Possible evolution
An update to descriptions and enums in the Qos_profiles.yaml might be required along with commonalities and/or other documentations.
Alternative solution
none
Additional context
none
Problem description
Quality of Service (QoS) Profiles define the performance characteristics offered by Service Providers to API consumers. These profiles are intended to be technology-agnostic, representing specific performance requirements (such as latency, jitter, and throughput) regardless of the underlying network layer.
However, there is currently no standardized naming convention for these profiles. This lack of uniformity creates significant friction for API consumers. For example: Provider A may use
voice, Provider B may useVC, Provider C may useQOS_VOICE_CALLING, and Provider D may useQOS_VOICEWithout a standard nomenclature, API consumers cannot intuitively understand a profile's purpose or performance tier by its name alone. This inconsistency leads to multiple issues including name space ambiguity and interoperability.
Therefore, a standardized naming framework across all Service Providers is needed. Standardizing these names will simplify consumptions, set right expectations, and enhance transparency.
This needs a discussion and a proposal. To jump start the discussion we can use the following model to construct the names:
[NAMESPACE]_[CATEGORY]_[CHARACTERISTIC]Example: QOS_VOICE_REALTIME
This standard must remain extensible, allowing providers to expose specialized capabilities—such as specific 5G network slices—using a uniform QOS_EXT_[Provider]_[Feature] naming convention.
Possible evolution
An update to descriptions and enums in the Qos_profiles.yaml might be required along with commonalities and/or other documentations.
Alternative solution
none
Additional context
none