Provision mode for QoD

[jlurien]

Problem description QoD Service provides the customer with the ability to set ceratin profile of QoS to an access network connection. Currently, the API supoports a session mode:

• the developer wants to set the required QoD profile for a certain period of time, after which the be network configuration must be set back to the default one.

But there is another possible use case for QoD, which is not currently supported:

• the developer wants to set the required QoD profile indefinitely, this is, each time that the UE connects to the network, it will use the required QoD profile instead of the default one, until the association is removed.

Possible evolution

Add support for a new "provision" mode, complementary to the current "session mode", with equivalent operations under a new path, to model:

• Creating a QoD provision for a device
• Removing a QoD provision for a device
• Getting the QoD provision details for a device
• Updating QoD provision details for a device

Alternative solution

Where should discuss where to model these new operations. Probably the best option is in a separate API, under the same QoD API family. Most schemas can be reused.

Additional context

This new model is more convenient for those B2B use cases where the devices being connected are used for a single purpose. For example reporters on the move, using backpacks to cover events and perform live video connections, that need the networking conditions provided by the QoD profile each time the backpack is used.

[hdamker]

Thanks @jlurien for this issue. We might need another label for this, as it is more a proposal for a new API than the enhancement of an existing one. But that's about definition of the "enhancement" label and it's more about the size of "enhancement".

Said this, looking on the proposal I have the impression that it is maybe rather a product order API (e.g. for a tariff option or to make a SIM card eligible to use a certain slice) than a network API. For the use case of live video production it might in addition be necessary to book/reserve the needed resources in advanced, as proposed in https://github.com/camaraproject/NetworkSliceBooking.

[jlurien]

Hi @hdamker, thanks for the feedback. I agree this is maybe too much for an "enhancement" but it's not definitely any of the other labels ;)

The motivation for this proposal is to explore other models of associating a QoS Profile to a device which are not constraint by the limited duration of a session. We can think of this as applying a QoS profile by default or making the association persistent until is revoked or changed. I think that is more related to QoD service than to the new NetworkSlicingBooking. It would share almost the same input and output, apart from the duration details.

Let's discuss the best way to open a debate around this, being an issue here or in another place, cc @jgarciahospital

[Kevsy]

It's an interesting use case: one major consideration is the impact on reconciliation and settlement. If a network operator decides to charge for QoD the API consumer will want to make sure they have received the agreed service, and will challenge the operator if they believe otherwise. I suspect this involves a different level of complexity for an 'always on' QoD than for a session-based QoD.

[jlurien]

It's an interesting use case: one major consideration is the impact on reconciliation and settlement. If a network operator decides to charge for QoD the API consumer will want to make sure they have received the agreed service, and will challenge the operator if they believe otherwise. I suspect this involves a different level of complexity for an 'always on' QoD than for a session-based QoD.

fyi @jgarciahospital

[jgarciahospital]

As agreed during backlog meeting 11/04 minutes, the inclusion of the scope defined in https://github.com/camaraproject/APIBacklog/issues/26 got approved.

This issue can be taken in consideration again, PR will be created to modify the API readme (if needed).

[tlohmar]

@jgarciahospital : I have some questions for clarification on the new "Provisioning Mode"

It is not completely clear, whether this new provisioning mode changes (A). Changes the default QoS of a PDU Session, or
(B). Installs a QOD Sessions, which is activate as default.

(A) means, that the applicationServer and the applicationServerPorts properties are not present or ignored and the requested QoD Profile is applied to any traffic for that device (PDU Session) (B) means, that a QOD Session with the applicationServer and the applicationServerPorts properties are always present, without any reactivation or any extension of the session duration.

Further, what about timing aspects. According to the current PR, the provisioning changes is applied instantaneously (now) and is valid forever (infinite session duration). What about (C) adding an end-time, so that the provisioning is automatically removed after some time (e.g. by Friday)? (D) adding a start-time, so that the provisioning is not applied instantaneously (now), but by a specific timestamp?

When adding some time information, it seem to become similar with the Network Slice Booking API (link).

Can you please elaborate?

[hdamker]

Reopen as #294 only updated the README, but obviously the enhancement isn't yet done.

[jlurien]

@jgarciahospital : I have some questions for clarification on the new "Provisioning Mode"

It is not completely clear, whether this new provisioning mode changes (A). Changes the default QoS of a PDU Session, or (B). Installs a QOD Sessions, which is activate as default.

Proposal is to set a configuration for the device/flow which is activated by default each time the device is connected to the network or for certain flow

(A) means, that the applicationServer and the applicationServerPorts properties are not present or ignored and the requested QoD Profile is applied to any traffic for that device (PDU Session) (B) means, that a QOD Session with the applicationServer and the applicationServerPorts properties are always present, without any reactivation or any extension of the session duration.

Application server and ports are treated as as we have right now, If not specified, all destinations are assumed (as 0.0.0.0/0)

Further, what about timing aspects. According to the current PR, the provisioning changes is applied instantaneously (now) and is valid forever (infinite session duration). What about (C) adding an end-time, so that the provisioning is automatically removed after some time (e.g. by Friday)? (D) adding a start-time, so that the provisioning is not applied instantaneously (now), but by a specific timestamp?

End-time is not in the initial proposal, as the configuration can be enabled/disabled on demand, and it is initially intended for long periods of time, to make this use case more differential compared to the current one, for sessions.

Booking of provisions, or sessions, could make sense as a future enhancement.

When adding some time information, it seem to become similar with the Network Slice Booking API (link).

There are many similarities between QoD and Network Slicing and in some situations their scope overlap. To me QoD is more service oriented while Network Slicing is more technology oriented. Also Network slicing treats with a location dimension that is currently missing from QoD.

Can you please elaborate?

[Masa8106]

@jlurien : Thank you for raising this issue.

Further, what about timing aspects. According to the current PR, the provisioning changes is applied instantaneously (now) and is valid forever (infinite session duration). What about (C) adding an end-time, so that the provisioning is automatically removed after some time (e.g. by Friday)? (D) adding a start-time, so that the provisioning is not applied instantaneously (now), but by a specific timestamp?

End-time is not in the initial proposal, as the configuration can be enabled/disabled on demand, and it is initially intended for long periods of time, to make this use case more differential compared to the current one, for sessions.

Booking of provisions, or sessions, could make sense as a future enhancement.

When adding some time information, it seem to become similar with the Network Slice Booking API (link).

There are many similarities between QoD and Network Slicing and in some situations their scope overlap. To me QoD is more service oriented while Network Slicing is more technology oriented. Also Network slicing treats with a location dimension that is currently missing from QoD.

Just a comment. I have same thinking that booking of provisions, or sessions, make sense as one of enhancements for "Provision Mode". I believe there is a case that QoD session is booked on the top of Network Slice Booking which can reserve resources.