QoS Profile Get ALL

[gauravn00b]

Enhancement done as per of #348, I agree that many will not implement Get All and offer a short list of "standard" profiles mutually agreed.

However, irrespective of this, we should not abandon the Get All and provide flexibility, in case some network operators want the profile names to be fetched and use in create session API, even though profiles are created as per agreement only. Sharing mutually agreed profiles over email/Chat is not a reliable method and API will simplify this manual process.

Also, the "POST /retrieve-qos-profile" with device as input, we are still not sure under what condition, this will be used? Reason is, while creating session or provisioning, qos profile is passed as an input, so API invoker is already controlling the device to profile mapping and is aware which profile is mapped to what device. So, based on that, API invoker can do "GET /qos-profile/{name}" to fetch the profile details in case required.

[hdamker]

Hi @gauravn00b - thanks for your points.

POST /retrieve-qos-profiles allows currently multiple cases -- but probably we haven't make this explicit enough

a) With 2-legged token (client-credential) and no device as parameter it should return all QoS profiles provided by the network (but: if it is an aggregated API across multiple operators it has to be defined by the aggregator what gets returned here, e.g. the intersection across a set of supported network operators)
b) With 3-legged token (indicating a device) or with an explicit device parameter it will return the QoS profiles which are available for that device -- which is potentially only a subset of the the set returned in case a). This request will work also on aggregation layer, as the request can be routed to the network operator who is serving the device.

To your second question: the intention is to use the /retrieve-qos-profiles before calling the quality-on-demand API to get the list of QoS profiles which can be used as input for the quality-on-demand API (qosProfile is an input parameter create a session). Having the specific list for a device reduces the cases where a QoS profile is valid for the network but not available for the concrete device.

Said this, what is your expected action for this issue? I see two options:

1. Explain the two different uses of the operation as above as part of the API documentation
2. Re-add the operation GET /qos-profiles for the case a) as this is clearer for an API consumer

[gauravn00b]

Thanks @hdamker for the inputs.

For Point b you have explained, as per our understanding, when qos profiles are created in network, there is no mapping of device to qos profile at network operator until unless API invoker assigns a QoS profile to a device, which can only be done under 2 situations:

1. Session creation
2. QoD Provisioning

In both the above cases, its API invoker itself who is assigning qos profile with the device. So not sure under which scenario API invoker would need to know which qos profile is mapped to which device. Its already known to API invoker.

If there is any such case, where profiles are required to be mapped to devices (during profile creation and before session creattion/qod provisioning), then this needs further deliberation and discussion.

[hdamker]

@gauravn00b seems that I haven't explained it correctly. Maybe you can give some context about from which direction you are asking - an operator implementing the APIs or an API consumer using them. Then I can adapt the explanations accordingly.

Thanks @hdamker for the inputs.

For Point b you have explained, as per our understanding, when qos profiles are created in network, there is no mapping of device to qos profile at network operator until unless API invoker assigns a QoS profile to a device, which can only be done under 2 situations:

1. Session creation
2. QoD Provisioning

In both the above cases, its API invoker itself who is assigning qos profile with the device. So not sure under which scenario API invoker would need to know which qos profile is mapped to which device. Its already known to API invoker.

If there is any such case, where profiles are required to be mapped to devices (during profile creation and before session creattion/qod provisioning), then this needs further deliberation and discussion.

In short: QoS Profiles will not created, but defined upfront - think of them as kind of products an API consumer can use while creating Sessions or Provisionings (if the profiles are "existing" in the network before a session is created depends on the technical means used to implement them).

And which QoS Profiles can be requested for a device depends e.g. on the kind of network a device is in (for a device in a 4G/5G NSA network there might be different options then for a device in a 5G SA network). The API consumer can't know these when calling createSession. With /retrieve-qos-profiles they can get the list of eligible profiles for the device.

@RandyLevensalor could you add to the discussion?

[eric-murray]

@gauravn00b

If you are looking for an API where the API consumer can request an arbitrary QoS profile, I suggest looking at the Network Slice Booking API. For that API, the QoS profiles are not assigned names, as they are not pre-defined "catalogue" entries offered by the API provider, unlike the QoD APIs.

[gauravn00b]

Thanks for your inputs @hdamker @eric-murray.

So POST /retrieve-qos-profiles without device in body or token (2 leg) is basically the deprecated GET /qos-profiles, where all profiles will be returned.

Regarding profile per device type, we have noted down inputs on this and will connect again in case some further clarity required.

[RandyLevensalor]

profile per device type

@gauravn00b This is an option that I've not considered and I'm not sure how it would be implemented. Since user plan and network type / region could also limit which profiles are available.

For instance if a user is connecting to Wi-Fi over a DOCSIS or Fiber network, they could have more capacity than if they were connecting to a mobile network.

If this isn't a constraint that we want to include in the API, it's something that we could consider.

Additionally, how granular would we need to get on device type. Would it be like Phone, Tablet, Laptop or other form factor? Or be by capabilities supported such as bands or Wi-Fi generation. Or would it need to go down to brand, model and generation?

[gauravn00b]

@RandyLevensalor Currently discussion is only about how a device can have a limited set of profiles out of total profiles available (Like @hdamker explained device being in 5G and another device being in 4G, so both devices can have different set of profiles).

The points you mention are much more deeper and increases the granularity further.

It's difficult to comment on this aspect at this moment.

@hdamker one query, are we planning to expose a create profile API as well in near future? Where API invoker itself will create/define profiles in network. (Obviously it will be based on some pre-agreement/SLAs, by placing some checks at the network during profile definition)

[hdamker]

@hdamker one query, are we planning to expose a create profile API as well in near future? Where API invoker itself will create/define profiles in network. (Obviously it will be based on some pre-agreement/SLAs, by placing some checks at the network during profile definition)

@gauravn00b No, there are no plans to allow to create QoS profiles by API consumers.

There is an approach with https://github.com/camaraproject/ConnectivityInsights/blob/main/code/API_definitions/application-profiles.yaml, which allow to express the expected network thresholds of an application. Currently used with the connectivity-insights API, but a possible evolution could be to offer an API which maps an application profile to an available QoS Profile. There is also #302, proposing to use application profiles as direct input to quality-on-demand, but my impression is that this has low support at the moment due to implementation complexity and indeterministic behaviour for the API consumer.

Another discussion - which will start in https://github.com/camaraproject/QualityByDesign/blob/main/README.md - is that an API like connectivity-insights could provide as results "corrective actions", which could be a recommended QoS Profile for the application requirements under the current connectivity situation to achieve the required network quality (kind of a feedback loop between application and network).