Adds service provider defined QoS profiles

[RandyLevensalor]

The current enum of 4 predefined QoS profiles will be replaced with service provider-defined profiles. 3GPP TS 23.203 Rel-15 supports 21 different QoS Class Identifiers (QCIs), and each QCI can be mapped to multiple QoS profiles. Wireline broadband operators typically deploy 50 or more QoS profiles to a single distribution network to address a combination of enterprise and residential needs.

These profiles will be searchable based on profile and end device identifier attributes. Each QoSProfile will contain attributes that describe the profile along with a required name and unique ID. The only change to the Qod session is replacing QoS with a QosId.

Here is an example QoSProfile payload for a QoS profile based on the 3GPP QCI_1 profile for voice:

{
  id:"123e4567-e89b-12d3-a456-426614174000",
  name:"QCI_1_voice",
  status:"Active",
  minBandwidth:{ value:1 unit:"Mbps"},
  maxBandwidth: { value:1 unit:"Mbps"},
  minDuration: { value:1 unit:"Seconds"},
  maxDuration: { value:24 unit:"Hours"},
  priority: 2.0,
  DelayBudget: { value:100 unit:"ms"},
  packetErrorLossRate: 2 
  direction: "Both"
}

The diagram below shows the new endpoints, components, and schemas for the proposed change.

A partial implementation of the above change can be viewed in this fork

[eric-murray]

Thanks @RandyLevensalor

Can you clarify the scope of the id parameter? I assume this is unrelated to the "session id" (currently also called id) and identifies the QoS profile only (independent of any device that might be using it, so that all devices requesting "QCI_1_voice" get the same id)?

What does a status of Active mean? That the profile can be requested for a device?

I assume maxDuration and minDuration are the (statically defined) minimum and maximum durations that can be requested for that profile, and not related to the duration that is requested by the client (other than that a request will be rejected if the requested duration falls outside these bounds).

Is name intended to be unique? Would it not be "friendlier" to allow the client to request a QoS profile by name rather than id? Are both id and name required?

Is the intention that the qos profile applies to all protocols, or is a protocol field required?

Mobile connections are usually asymmetric, with much higher throughputs both available and required on the downlink than the uplink. Separate throughput (aka bandwidth) parameters are required for uplink and downlink. Otherwise, it will be very limited what can be offered on the downlink if that also has to be supported on the uplink.

[RandyLevensalor]

@eric-murray Thanks for the excellent questions.

Can you clarify the scope of the id parameter? I assume this is unrelated to the "session id" (currently also called id) and identifies the QoS profile only (independent of any device that might be using it, so that all devices requesting "QCI_1_voice" get the same id)?

Correct. The id in QoSProfile is scope to the QoSProfile and is different than id in session id. All devices requesting the Qos Profile id:"123e4567-e89b-12d3-a456-426614174000" will get the same profile. The intent is for the id to be unique for the service provider or at least the service provide endpoint.

What does a status of Active mean? That the profile can be requested for a device?

Yes, Active status means that it can be requested. Deprecated status is used for QoS profiles that are in use, but can't be used to create a new QoD session. Inactive status means that they are not in use and can't be used. This is an attempt to enable a level of lifecycle management for a QoS profile.

I assume maxDuration and minDuration are the (statically defined) minimum and maximum durations that can be requested for that profile, and not related to the duration that is requested by the client (other than that a request will be rejected if the requested duration falls outside these bounds).

Exactly

Is name intended to be unique? Would it not be "friendlier" to allow the client to request a QoS profile by name rather than id? Are both id and name required?

I was thinking that name will not be required to be unique where the id is unique. So you could use the full or partial name as the query string and get all matching profiles. For instance, QCI profile for voice doesn't specify how much bandwidth will be allowed. So there could be multiple QCI_1_voice profiles or the name could be much more descriptive "Profile for voice calls on a device connected using mid-band spectrum".

Is the intention that the qos profile applies to all protocols, or is a protocol field required?

Interesting question. Protocol or other flow identifies could be added to either the QoS Profile or the QoD Session. I had assumed that the session would provide the classification data. Now that you ask, it could make for sense to include this in the QoS profile. Happy to discuss further and would love to hear more input on this.

Mobile connections are usually asymmetric, with much higher throughputs both available and required on the downlink than the uplink. Separate throughput (aka bandwidth) parameters are required for uplink and downlink. Otherwise, it will be very limited what can be offered on the downlink if that also has to be supported on the uplink.

I added the directionality, so that this profile could be applied to either upstream or downstream. I can think of three options to address this. I'm sure I'm missing something and would love to hear more thoughts on this.

1. Add upstream and downstream bandwidth attributes to the QoS Profile
2. Allow for multiple QoS profiles in a session, so that both upstream and downstream profiles can be added to a session.
3. Add an intermediate construct for a service. Where I service would consist of one or more QoS Profiles. Then a session would have one service. I think this option maps the closest to some of TMF order models.

[eric-murray]

Hi @RandyLevensalor

Nobody else has contributed yet, so I will give my opinion:

I was thinking that name will not be required to be unique where the id is unique.

So name is just a hint to the API caller what the profile might be useful for, and not a key with which to specify the protocol. That's fine.

I added the directionality, so that this profile could be applied to either upstream or downstream. I can think of three options to address this. I'm sure I'm missing something and would love to hear more thoughts on this.

The problem with separate QoS profiles for uplink and downlink is that, whilst it can make sense to have separate and independent throughputs for uplink and downlink, it does not really make sense for delay budget.

Whilst the concept of "one way" latency is valid, it is really round trip delay that (generally) matters because:

• Most protocols and applications are interactive to at least some degree, so the round trip latency affects the user experience far more than the individual one way latencies.
• It is notoriously difficult to measure one way latencies accurately, as the two ends will never be perfectly time synchronised. For the sort of latencies we are considering, the typical synchronisation error will be significant.

So my preference would be to expand the current proposal to include separate "uplink" and "downlink" bandwidth parameters, but retain the common priority and delayBudget parameters. Probably the direction parameter can be removed in that case.

To support "uni-directional" QoS profiles where a QoS profile is only applied in one-direction. I'd suggest to allow the value "default" to be specified for the relevant minThroughput and maxThroughput parameters, this meaning "Applying this QoS profile will not affect what you are currently getting or would get in this direction if you didn't use this API". But to meet latency targets, the traffic really needs to be prioritised in both directions, even if the throughput is only enhanced in one.

BTW - I'm originally an RF engineer, so for me, "bandwidth" will always be measured in MHz. Anything measured in Mb/s, I'm going to call "throughput".

[RandyLevensalor]

@eric-murray Thanks for the feedback. I've incorporated your feedback regarding throughput for both up stream (US) and down stream (DS).

{
  id:"123e4567-e89b-12d3-a456-426614174000",
  name:"QCI_1_voice",
  status:"Active",
  minUSThroughput:{ value:1 unit:"Mbps"},
  maxUSThroughput: { value:1 unit:"Mbps"},
  minDSThroughput:{ value:1 unit:"Mbps"},
  maxDSThroughput: { value:1 unit:"Mbps"},
  minDuration: { value:1 unit:"Seconds"},
  maxDuration: { value:24 unit:"Hours"},
  priority: 2.0,
  DelayBudget: { value:100 unit:"ms"},
  packetErrorLossRate: 2 
}

[eric-murray]

Thanks @RandyLevensalor

Looks good. I see that you did not adopt my proposal to use Throughput for the parameter names rather than Bandwidth, but that's just terminology and we can vote on that. Also, no matter how intuitive "up" and "down" may be to us, it will not be to others, so expect some debate there.

I'd still like to see some way to specify that either the "up" or "down" parameters will retain their "default" values (which may be device specific) rather than always be explicitly specified. I guess if those are optional parameters in the profile, they could just not be included if the default would apply. We can discuss in the meeting.

[RandyLevensalor]

@eric-murray

Looks good. I see that you did not adopt my proposal to use Throughput for the parameter names rather than Bandwidth, but that's just terminology and we can vote on that. Also, no matter how intuitive "up" and "down" may be to us, it will not be to others, so expect some debate there.

That was a copy paste error for the json, which I corrected. This diagram had the change to Throughput.

I'd still like to see some way to specify that either the "up" or "down" parameters will retain their "default" values (which may be device specific) rather than always be explicitly specified. I guess if those are optional parameters in the profile, they could just not be included if the default would apply. We can discuss in the meeting.

Happy to have a debate about us vs down. I'd say if no max throughput is specified, then it would not change. Overloading the API to allow for a throughput to be a speed or a string is something I'd like to avoid.

[patrice-conil]

@RandyLevensalor, @eric-murray,
Thanks for your work on this topic.
I'm trying to set up such a system to find where the wolves are.
Have you ever thought about mapping QosProfile Id to qosReference in multi SCEF/NEF environment?
Maybe we should think of an "admin" API to propagate profiles to NEFs/SCEFs.

[eric-murray]

Hi @patrice-conil

We have to be careful not to couple this API too tightly to the SCEF / NEF, as other backend systems will be possible. I would not expect the NEF to be used for the fixed connectivity use cases of interest to Randy, for example. And I'm still waiting for our first production NEF to be deployed in Vodafone.

But to your specific point, the parameter used by the SCEF / NEF T8 to specify the required profile, qosReference, is just a string. So my expectation is that the id parameter proposed Randy would be that parameter.

As for how that qosReference is mapped to a particular set of configuration parameters within the network, I don't think that is an issue for CAMARA. The SCEF / NEF will have a separate provisioning interface that allows it to understand what a particular qosReference value means in terms of configuration.

So we don't need CAMARA to specify paths for this API that allow new QoS profiles to be "uploaded" or existing profiles modified. That was the issue that I had with Randy's original proposal because it (a) allowed the end user to specify the QoS profile they wanted and (b) exposed to "the internet" a mechanism to modify the available QoS profiles that could never be guaranteed to be secure (and just does not need to be exposed in this way).

Of course, this all implies that particular QoS profile parameter values, such as minDownThroughput and DelayBudget, may be mapped to different network settings by different network operators, but that is fine as long as the resulting QoS is consistent with what is offered to the customer. And I've said before that mobile networks cannot "guarantee" minimum throughputs or maximum latencies, so there will anyway be a statistical element to the QoS achieved, which would be captured by some contractual SLA. It is hard to capture such contractual caveats in an API.

A separate but related issue is whether CAMARA specifies a set of common QoS profiles, with a common id. In that case, a tighter definition on how the profile is implemented may be required. But if network operators are publishing their own catalogue of available profiles, then implementation is up to the network operator.

[RandyLevensalor]

QosProfile

This is a revised proposal based on feedback.

id: string (required)

The id is a unique string for the QoS profile following the UUID format.

name: string (required)

The name is a descriptive string for the profile. This is not unique.

status: QosProfileStatusEnum (required)

The status is the current state for the QoS profile with one of the following values:

• Active - This profile is active and available to be used.
• Inactive - This profile is not available and can not be used at this time.
• Deprecated - This profile may be in use, but can not be added to new QoS sessions.

guaranteedUpstreamRate: Rate (Optional)

This is the guaranteed or minimum upstream rate for this profile.

maxUpstreamRate: Rate (Optional)

This is the maximum sustained upstream rate for this profile. If this is undefined, then the maxUpstream rate will not change.

If this rate is lower than the current provisioned maximum sustained rate, then the current rate is used.

maxUpstreamBurstRate: Rate (Optional)

This is the maximum burst upstream rate for this profile. If this is undefined, then the maxUpstream rate will not change.

If this rate is lower than the current provisioned maximum rate, then the current maximum burst rate is used.

guaranteedDownstreamRate: Rate (Optional)

This is the guaranteed or minimum downstream rate for this profile.

maxDownstreamRate: Rate (Optional)

This is the maximum sustained downstream rate for this profile. If this is undefined, then the maxUpstream rate will not change.

If this rate is lower than the current provisioned maximum sustained rate, then the current rate is used.

maxDownstreamBurstRate: Rate (Optional)

This is the maximum burst downstream rate for this profile. If this is undefined, then the maxUpstream rate will not change.

If this rate is lower than the current provisioned maximum rate, then the current maximum burst rate is used.

minDuration: Duration (Optional)

The minium period of time that this profile can be allocated.

maxDuration: Duration (Optional)

The maximum period of time that this profile can be allocated.

priority: float (required)

The priority of the traffic. This is a float between 1 and 10. The lower the value the higher the priority.

packetDelayBudget: Duration (Optional)

The packet delay budget defines an upper bound for the time that a packet may be delayed between the user device and the core network. This is the round trip latency of the access network, and doesn't include any transit or other network elements.

packetErrorLossRate: int (Optional)

This is a negative integer for the the exponent for the loss rate. Where a loss rate of '-5' would mean that no more than 10⁻⁵ packets will be lost.

Examples

Conversational voice

{
  id:"123e4567-e89b-12d3-a456-426614174000",
  name:"QCI_1_voice",
  status:"Active",
  guaranteedUpstreamRate:{ value:128 unit:"Kbps"},
  guaranteedDownstreamRate: { value:128 unit:"Kbps"},
  priority: 2.0,
  DelayBudget: { value:100 unit:"ms"},
  packetErrorLossRate: 2
}

OTT Streaming Video with Buffering

{
  id:"123e4567-e89b-12d3-a456-426614174000",
  name:"QCI_6_buffered_video",
  status:"Active",
  maxUpstreamRate:{ value:512 unit:"Kbps"},
  maxDownstreamRate: { value:512 unit:"Kbps"},
  priority: 6.0,
  DelayBudget: { value:300 unit:"ms"},
  packetErrorLossRate: 6
}

[patrice-conil]

Hi @patrice-conil

We have to be careful not to couple this API too tightly to the SCEF / NEF, as other backend systems will be possible. I would not expect the NEF to be used for the fixed connectivity use cases of interest to Randy, for example. And I'm still waiting for our first production NEF to be deployed in Vodafone.

But to your specific point, the parameter used by the SCEF / NEF T8 to specify the required profile, qosReference, is just a string. So my expectation is that the id parameter proposed Randy would be that parameter.

As for how that qosReference is mapped to a particular set of configuration parameters within the network, I don't think that is an issue for CAMARA. The SCEF / NEF will have a separate provisioning interface that allows it to understand what a particular qosReference value means in terms of configuration.

So we don't need CAMARA to specify paths for this API that allow new QoS profiles to be "uploaded" or existing profiles modified. That was the issue that I had with Randy's original proposal because it (a) allowed the end user to specify the QoS profile they wanted and (b) exposed to "the internet" a mechanism to modify the available QoS profiles that could never be guaranteed to be secure (and just does not need to be exposed in this way).

Of course, this all implies that particular QoS profile parameter values, such as minDownThroughput and DelayBudget, may be mapped to different network settings by different network operators, but that is fine as long as the resulting QoS is consistent with what is offered to the customer. And I've said before that mobile networks cannot "guarantee" minimum throughputs or maximum latencies, so there will anyway be a statistical element to the QoS achieved, which would be captured by some contractual SLA. It is hard to capture such contractual caveats in an API.

A separate but related issue is whether CAMARA specifies a set of common QoS profiles, with a common id. In that case, a tighter definition on how the profile is implemented may be required. But if network operators are publishing their own catalogue of available profiles, then implementation is up to the network operator.

Hi @eric-murray,
I agree with this approach and let's play with the first NEF before thinking about multi env.
My initial thought was about "how do we guarantee that the profiles we expose are the right ones ... those really available?" but you're right, it's out of Camara's scope.

[eric-murray]

@RandyLevensalor

Unfortunately I was not able to attend the last QoD meeting, so do not know what was discussed, but I would have a problem using the term "guaranteed" in the parameter names, as throughputs just cannot be "guaranteed" for mobile radio links. Now I know that 3GPP use the term GBR, but "guaranteed" in that context is a technical term and not a guarantee as would be understood by the man on the Clapham omnibus. GBR is not a term that we use with customers.

Given that these APIs will be made available to external developers, we need to be careful not to raise false expectations. Our legal team would not allow us to use language that implies the customer will always get at least the specified minimum data throughput irrespective of radio network conditions, because we know where that will lead when they inevitably don't get it at some point. There is no way that we can attach "small print" or SLAs directly to the profile descriptions, and nobody reads the small print anyway.

So I would suggest more "radio friendly" terminology, such as targetMinimumUpstreamDataRate and targetMinimumDownstreamDataRate, and the documentation can explain that this target will be subject to an SLA (i.e. it is not guaranteed all the time under any and all conditions).

Regarding Upstream and Downstream, my understanding is that Up is towards the server and Down is towards the client (i.e. device). Is that understanding universal and unambiguous?

[patrice-conil]

@RandyLevensalor, @eric-murray

Unfortunately I was not able to attend the last QoD meeting, so do not know what was discussed, but I would have a problem using the term "guaranteed" in the parameter names, as throughputs just cannot be "guaranteed" for mobile radio links. Now I know that 3GPP use the term GBR, but "guaranteed" in that context is a technical term and not a guarantee as would be understood by the man on the Clapham omnibus. GBR is not a term that we use with customers.

Given that these APIs will be made available to external developers, we need to be careful not to raise false expectations. Our legal team would not allow us to use language that implies the customer will always get at least the specified minimum data throughput irrespective of radio network conditions, because we know where that will lead when they inevitably don't get it at some point. There is no way that we can attach "small print" or SLAs directly to the profile descriptions, and nobody reads the small print anyway.

So I would suggest more "radio friendly" terminology, such as targetMinimumUpstreamDataRate and targetMinimumDownstreamDataRate, and the documentation can explain that this target will be subject to an SLA (i.e. it is not guaranteed all the time under any and all conditions).

I also prefer targetMinimum to guaranteed

Regarding Upstream and Downstream, my understanding is that Up is towards the server and Down is towards the client (i.e. device). Is that understanding universal and unambiguous?

IMHO Up and Down should be ok because all developper Upload/Download files frequently.

[hdamker]

@RandyLevensalor #129 is finally merged, so the way is free for the next PRs. Would it be able for you to create your PR before the next call on April 21st (to follow the proposed timeline in #136)?

[RandyLevensalor]

@RandyLevensalor #129 is finally merged, so the way is free for the next PRs. Would it be able for you to create your PR before the next call on April 21st (to follow the proposed timeline in #136)?

@hdamker Thanks for the update. I will create the PR ahead of the meeting.

I will miss the meeting on the 21st, but someone else from CableLabs will be on the call to discuss the PR.

[RandyLevensalor]

@eric-murray @patrice-conil

I'm happy to make the change from guaranteed to targetMinimum.

@eric-murray

How strongly do you feel about DataRate vs Rate? I can't imaging someone confusing an upstream/downstream rate measured in bits per second to be anything other than data rate. Adding Data seems a bit redundant and targetMinimumUpstreamDataRate is on the long side without adding data.

Are there any other opinions on this one.

[eric-murray]

@RandyLevensalor

Yes, you can drop the "Data" bit. We can put a full explanation in the documentation.

One additional request. When reviewing this internally, it was requested to include some metric for maximum "jitter". Now I really don't like the term "jitter" as it is so badly defined, but it at least has the benefit of having a short name. My preferred term is "packet delay variation", but then we would end up with targetMaximumPacketDelayVariation, which is maybe a bit of a mouthful. Possibly it could be shortened to targetMaximumDelayVariation, or even targetMaximumPDV. Let me know what you think.

Of course, we would still need a definition for Packet Delay Variation in the documentation, as there are several in use. Nothing is ever that simple.

[RandyLevensalor]

@eric-murray How do you see "jitter" comparing to the "maximumDelayBudget."

While I agree that "jitter" is a bit of an ambiguous term and many will scoff at its use. I think that more people would understand jitter than targetMaximumPacketDelayVariation.

I'm open to including this.

Would defining jitter as:

Jitter refers to the variation in the time it takes for none queue building packets to travel across a network measured in milliseconds (ms). In terms of maximum deviation for round trip latency on a network, jitter can be defined as the difference between the highest and lowest latency values experienced by the 99th percentile of traffic.

To be more specific, if we consider the round trip latency values of the 99th percentile of traffic, jitter is the measure of how much these values deviate from the average round trip latency for this percentile. A low jitter value indicates that the latency values are relatively consistent, whereas a high jitter value implies that there is a significant variation in latency times, which can negatively impact the performance of real-time applications such as VoIP, video conferencing, and online gaming.

I'll get some additional guidance from some colleagues that have been active in measuring and improving jitter. Please take this comment as an initial thought and not a final proposal.

[eric-murray]

Hi @RandyLevensalor

How do you see "jitter" comparing to the "maximumDelayBudget"

Well, they are different but related metrics:

• Maximum Delay Budget is the round-trip latency value above which a packet is considered to be dropped and will thus count towards the Packet Error Loss Rate. In other words, a packet not acknowledged within Maximum Delay Budget is considered dropped as far as QoS metrics are concerned, even if acknowledged later.
• "Jitter", or Packet Delay Variation will depend on the exact definition. Your definition above is essentially the 99%ile PDV as defined by, say, ITU Y.1540. This is a round-trip measure similar to Maximum Delay Budget, but referenced to the minimum round trip latency rather than 0 ms.

So Maximum Delay Budget is not something that is measured - it defines when a packet is considered so delayed that it counts as dropped - whereas Packet Delay Variation is something that can be measured and compared to the "target maximum".

If the minimum latency is very small, then 99%ile PDV will indeed be similar to 99%ile latency. But the minimum latency will not be that small for mobile communications (maybe 20 - 50 ms, or even higher for remote servers). And some measures of PDV are one-way rather than round-trip, which is why it is important to clarify what definition is being used.

I'm happy to adopt 99%ile round-trip PDV as defined by ITU Y.1540 as our definition for "Packet Delay Variation", though others may have different opinions. As for the name used within the API definition, well I don't want to be the one to perpetuate the use of the term "jitter", but so long as the definition is clear, maybe it doesn't matter so much.

[emil-cheung]

From implementation point of view, which network function shall owns the QoS profile data?

[ToshiWakayama-KDDI]

Hi @RandyLevensalor, Hi @eric-murray, Hi all,

I have one comment on the parameters targetMinimumUpstreamRate and targetMinimumDownstreamRate.

Changing from guaranteedUpstreamRate and guaranteedDownstreamRate to targetMinimumUp/DownstreamRate respectively for external developers sake is ok. However, I understand that these parameters are supposed to be mapped to 3GPP NEF/SCEF GBR (Guaranteed Bit Rate) parameters for mobile networks. The Conversational voice example in the YAML is a very good example, where its name is QCI_1_voice and targetMinimumUpstreamRate and targetMinimumDownstreamRate are defined. (QCI=1 is GBR, as we all know.)

We should document this somewhere, in order to avoid ambiguity in mapping: e.g. targetMinimumUpstreamRate and targetMinimumDownstreamRate are mapped to 3GPP NEF/SCEF guaranteedUpstream/DownstreamRate parameters.

Sorry for the late comment.

[sfnuser]

@RandyLevensalor

Thanks for driving this effort.

I have a question on the PR. The GET /qos-profiles endpoint seems to return only extendedQosProfile on success. As there is no type differentiation between qosProfile and extendedQosProfile that is visible to the user, what is the expectation on implementations that supports the four fixed qosProfile to return?

Having said that, I would like to propose the merge of qosProfile and extendedQosProfile into one. This would be future proof, clean and will not leave a legacy qosProfile that stays forever to be maintained.

All,

Assuming if we go with this idea, we need some changes in the extendedQosProfile schema.

1. id field can either be removed or made optional
2. name field should be made required and unique and this will be the QoSProfileId - this will be the one used in CreateSession & GET /qos-profiles/{qos-profile-id}
3. QoSProfileId will be a string and not an UUID

We can assume that there will be SLAs & charges associated with these profiles that are already documented/communicated and agreed upon (outside the scope of this spec). With this convergence, I want to list out some of the advantageous below:

• Operator can support both qosProfile and extendedQosProfile types in the same deployment. GET /qos-profiles endpoint will also list legacy qosProfile string if those fixed profiles are the only supported ones
• By removing the id field and using QosProfileId string (gives a hint on profile e.g. "QCI_VOICE"), we are not mandating a GET operation in order to get the id and use it (as it is now)
• No extra id field that needs mapping at various layers of the network. Eases customer support/debug/maintanence

For an operator supporting hundreds of profiles, all the above would still hold true + there is no loss of functionality. Assuming there is naming strategy of QosProfileId like "QCI_VOICE_1", a query on GET /qos-profiles with QosProfileId partial string being `QCI_VOICE" should get all the voice profiles supported (like now).

Thoughts!

[ToshiWakayama-KDDI]

Hi @RandyLevensalor, Hi @eric-murray, Hi all,

Further to my privious comment a couple of days ago, I would like to propose to use guaranteedUpstreamRate and guaranteedDownstreamRate, rather than targetMinimumUpstreamRate and targetMinimumDownstreamRate. I believe 'targetMinimum' is not used in 3GPP but 'guaranteed' (e.g. GBR) is used in 3GPP, so, by using guaranteedUpstreamRate and guaranteedDownstreamRate, we can avoid ambiguity in mapping QoD API to Southbound Network API (i.e. NEF/SCEF).

Thanks.

[ToshiWakayama-KDDI]

From implementation point of view, which network function shall owns the QoS profile data?

I have the same question as Emil's. An important point to see if the API is implementable, I think.

Thanks.

[eric-murray]

@ToshiWakayama-KDDI

Further to my privious comment a couple of days ago, I would like to propose to use guaranteedUpstreamRate and guaranteedDownstreamRate, rather than targetMinimumUpstreamRate and targetMinimumDownstreamRate. I believe 'targetMinimum' is not used in 3GPP but 'guaranteed' (e.g. GBR) is used in 3GPP, so, by using guaranteedUpstreamRate and guaranteedDownstreamRate, we can avoid ambiguity in mapping QoD API to Southbound Network API (i.e. NEF/SCEF).

I disagree with this proposal for 3 reasons:

• The whole point of CAMARA is to provide "friendly" interfaces to developers who are not familiar with the technical definitions and terminology of telecommunications networks (3GPP or otherwise). So the assumption is that they do not care how the QoS profile is implemented in the network. So the names used in the QoS profiles do not need to capture how it will be implemented in the network. If we had customers who really cared about what 5QI mapping we were using and whether that was a "GBR" or "Non-GBR" bearer, then we could offer them the 3GPP T8, instead of abstracting that complexity through CAMARA.

• A common fallacy in CAMARA discussions is to assume that CAMARA APIs will only be used for 3GPP networks. This is not true, they could apply to any telecommunications network. So we should avoid "baking in" 3GPP terminology or architecture into the API definitions.

• Most importantly, I think the way a developer would view the term "guaranteed" and the way 3GPP use the term "guaranteed" will be fundamentally different. A "guarantee" is generally understood to mean "a promise that something will be done or will happen". But 3GPP use the term GBR to mean "the bearer can support this minimum bitrate until it is determined that it cannot, in which case a notification will be sent saying it is no longer guaranteed".

Imagine that you bought an expensive camera in a shop, and were told "this camera is guaranteed to work, unless it stops working, in which case we'll send you a letter saying it is not guaranteed any more". Not much of a "guarantee", is it?

I think the term "targetMinimum" explains far better to the API consumer what they will get than "guaranteedMinimum", and each API provider can attach their own SLA to the agreed QoS profile (e.g. "the target minimum throughput will be achieved for no less than 95% of the session duration"). If it is important to explain the mapping of a particular QoS profile to a 3GPP profile, that can be captured in the QoS profile name, or in any associated documentation.

[eric-murray]

@ToshiWakayama-KDDI, @emil-cheung

From implementation point of view, which network function shall owns the QoS profile data?

I have the same question as Emil's. An important point to see if the API is implementable, I think.

This question confuses me. If we are considering an implementation for a 3GPP network, then for many years now the 3GPP AsSessionWithQoS interface has included the parameter:

qosReference:
  type: string
  description: Identifies a pre-defined QoS information

Is there no known solution for the SCEF/NEF to maintain these pre-defined QoS profiles?

[emil-cheung]

@ToshiWakayama-KDDI, @emil-cheung

From implementation point of view, which network function shall owns the QoS profile data?

I have the same question as Emil's. An important point to see if the API is implementable, I think.

This question confuses me. If we are considering an implementation for a 3GPP network, then for many years now the 3GPP AsSessionWithQoS interface has included the parameter:

qosReference:
  type: string
  description: Identifies a pre-defined QoS information

Is there no known solution for the SCEF/NEF to maintain these pre-defined QoS profiles?

@eric-murray
Well, in 3GPP, NEF/SCEF does have the information of QoS references.
However, there is no standard definition about how QoS references are configured (or provisioned) into NEF/SCEF, neither how to retrieve it from NEF/SCEF. Different NEF/SCEF implementations may treat it in different ways.

My personal understanding is that QoS references shall be defined by BSS/OSS and then provisioned into NEF/SCEF.
NEF/SCEF is not the master of QoS reference data. The community please comment.

Additionally, it seems like the community agreed (in the meeting on April 21st) that QoS profile discovery will start from providing the information of QoS profiles in the initial phase. In later phases, it may be extended to eligibility aspect considering the UE subscription. If the solution is purely based on NEF/SCEF, the eligibility/subscription aspect may be difficult to fulfilled, but BSS/OSS based solution could better support that.

[eric-murray]

@emil-cheung
So if it agreed that QoS profiles can be provisioned for the SCEF / NEF, but the mechanism is proprietary, why can the same not be said for the CAMARA QoD API? If an example "owner" of these profiles is required, then BSS/OSS or some other proprietary non-3GPP IT system can be given.

But CAMARA do not need to define how this will work.

[eric-murray]

@sfnuser

Thoughts!

I'm happy for name to be a length-constrained but otherwise free-text string that should be unique so that it can be used as the QoS profile key. But CAMARA should not try to standardise the valid QoS profile names, so no associated enum and no mandating that particular profiles are supported. API providers should be free to define their own QoS profiles. If some CAMARA participants see value in defining "common" profiles, they are free to put those in the documentation as "recommended" profiles. And I should be free to ignore those recommendations.

I also do not want name be the parameter that we pass as qosReference to the NEF where that is the implementing network element. Of course, I could just define an "internal" qosReference parameter for each profile, and pass that when the API caller selects a particular profile by name. But I feel it would be better to keep id as an optional parameter in the QoS profile (renamed if you want, though I would avoid calling it qosReference) as I think that would simplify testing and debugging in some cases.

If kept, the id parameter could just be a simple string, as it would only be an output parameter, and not an input parameter, so data validation is not required.

[sfnuser]

@jlurien @eric-murray @RandyLevensalor

Thanks for the positive follow-up on the proposal. Adding my comments here as it is easy to follow a discussion than in the PR.

I'm happy for name to be a length-constrained but otherwise free-text string that should be unique so that it can be used as the QoS profile key. But CAMARA should not try to standardise the valid QoS profile names, so no associated enum and no mandating that particular profiles are supported. API providers should be free to define their own QoS profiles. If some CAMARA participants see value in defining "common" profiles, they are free to put those in the documentation as "recommended" profiles. And I should be free to ignore those recommendations.

I am OK with the above suggestions. Having said that, I am also wondering would it benefit the developer to have one (or maybe two) default QoS profile name that is defined in the guidelines? For e.g. say QOD_PREMIUM (to differentiate it is something more than STANDARD) could be a default qosProfile that is mandatory to be available across CAMARA implementations. The interpretation of it can be defined by the service provider. This would help QoD service implementations in testing, interoperability with multiple operators/network functions (from a developer perspective, this would greatly help)

I assume this should not hinder an operator in exposing multiple/varied profiles that they want to showcase. More on this further down.

I also do not want name be the parameter that we pass as qosReference to the NEF where that is the implementing network element. Of course, I could just define an "internal" qosReference parameter for each profile, and pass that when the API caller selects a particular profile by name. But I feel it would be better to keep id as an optional parameter in the QoS profile (renamed if you want, though I would avoid calling it qosReference) as I think that would simplify testing and debugging in some cases.

If kept, the id parameter could just be a simple string, as it would only be an output parameter, and not an input parameter, so data validation is not required.

Agreed. I would also like to keep id as an optional + output only parameter. If we agree on output only param, I think we shall stick with the name id. By having this id field, an operator with hundreds of profile can create alias qosProfile labels - for e.g. an operator targeting gaming audience can have the default QOD_PREMIUM label to be an alias of a most common gaming qosProfile say QOD_GAMING_144_1 and both having the same id field internally.

I am open to both options - No default qosProfile labels defined by CAMARA (or) we could define one or two default labels like QOD_PREMIUM_1/2(or better names) if the community feels its use and there is agreement.

Tagging other active participants here so that we can keep the discussion here in the issue than in the PR.
@hdamker @emil-cheung @patrice-conil @ToshiWakayama-KDDI

[ToshiWakayama-KDDI]

Hi @eric-murray,

Thank you for your comments to my proposal (targetMinimum -> guaranteed).

• Most importantly, I think the way a developer would view the term "guaranteed" and the way 3GPP use the term "guaranteed" will be fundamentally different. A "guarantee" is generally understood to mean "a promise that something will be done or will happen". But 3GPP use the term GBR to mean "the bearer can support this minimum bitrate until it is determined that it cannot, in which case a notification will be sent saying it is no longer guaranteed".

May I ask in which 3GPP document I can find the meaning of the term GBR, please? ("the bearer can support this minimum bitrate until it is determined that it cannot, in which case a notification will be sent saying it is no longer guaranteed" )

Many thanks,

[eric-murray]

@ToshiWakayama-KDDI
From TS 23.501

If, for a given GBR QoS Flow, Notification control is enabled and the NG-RAN determines that the GFBR, the PDB or
the PER of the QoS profile cannot be fulfilled, NG-RAN shall send a notification towards SMF that the "GFBR can no
longer be guaranteed". Furthermore, the NG-RAN shall keep the QoS Flow (i.e. while the NG-RAN is not fulfilling the
requested QoS profile for this QoS Flow), unless specific conditions at the NG-RAN require the release of the NG-RAN
resources for this GBR QoS Flow, e.g. due to Radio link failure or RAN internal congestion. The NG-RAN should try
to fulfil the GFBR, the PDB and the PER of the QoS profile again.

[ToshiWakayama-KDDI]

Hi @eric-murray,

Thank you so much. I could not find it by myself.

As you pointed out, the API is used not only for 3GPP Network, but in practice, the API will be used mostly for 3GPP Network. And I understand that the whole point of CAMARA is to provide "friendly" interfaces to developers who are not familiar with the technical definitions and terminology of telecommunications networks (3GPP or otherwise).

But at the same time, we should remove aubiguity in mapping between Northbound Service API and Southbound Network API (NEF/SCEF) as much as possible, so that we could avoid multiple interpretation among operators/service providers as much as possible and we could stick to the notion of CAMARA (and Open Gateway) of defining common APIs. This is my point which I raised for the v0.8.0 mapping discussions in November - December last year, if I remember correctly.

On 24th March we had some discussion on adding a type of profile (best effort or guaranteed), which I don't think has been concluded. So, could we consider adding this ('best effort' or 'guaranteed')? Or, wouldn't it be possible to add the 5QI/QCI value directly as a parameter? Operators/service providers, have a 5QI/QCI value for a profile, and operators/service providers could put it in a profile but developers just don't care it.

Just an idea, but what do you and others think?

Thanks.

[RandyLevensalor]

@ToshiWakayama-KDDI

We can provide examples of how the 5QI values could be mapped into these profiles. Since these also apply to non-3GPP networks, we can't overly burdon these APIs with 3GPP specific nomenclature.

These profile definitions are intended to map to PON and DOCSIS networks as well. Mapping this API to NEF could cause additional challenges when mapping to these wireline networks.

Since this API is intended for 3rd party developer, we should make it as straightforward as possible.

[ToshiWakayama-KDDI]

Hi @RandyLevensalor, Hi @eric-murray,

My question on relation between targetMinimumUp/DownstreamRate and 3GPP GBR was cleared at the last QoD meeting.

Then I have another question. Is it correct understanding that 'maxUp/DownstreamRate' is non-GBR/best effort rate for 3GPP?

Many thanks,

[eric-murray]

@ToshiWakayama-KDDI
Not necessarily. In fact, if the 3GPP MBR (Maximum Bit Rate) parameter is being used to enforce the maximum throughput, then the bearer must be a GBR bearer. But there are other ways to enforce bitrate throttling for non-GBR bearers. So it could be either.

[hdamker]

Done by #138