Should IP flows be supported in QoS Booking?

[JoachimDahlgren]

This issue is raised to trigger a discussion and to get further input. It originates from the work group meeting April 4th 2025 when this topic was first brought up.

Background

In the currently proposed first version of the QoS Booking API, it is possible to indicate which flow that sometime in the future is to get new QoS treatment. This flow is indicated by IP address and port of the device as well as of the application server.

With cellular connectivity, the IP address is assigned when the device connects to the network. There is no guaranteed that a disconnected device will get the same IP address when reconnected.

Questions

This raises the question if IP flow granularity is reasonable for the QoS booking API? Or should it rather be per device as is the case in the QoD Provisioning API?

In case we want it to be per flow:

• What is then the use case?
• How will the application developer know what will be the flow in the future when the QoS Booking turns into a change in quality?
• What should happen if the traffic to be boosted have moved from one flow to another?

[hdamker]

Maybe the API should allow the booking only down to the granularity of a device? And later, within the booked geography and time slot the API consumer can either request a provisioning for the (complete) device or for a specific flow (via quality-on-demand)?

Then only the IP address within device parameter can be - optionally - used to identify the device at the time of the booking. Within later calls the API consumer might need to use the then current IP address to identify the same device.

[Masa8106]

Thank you for raising the issue.
As you mentioned, there is a possibility to change the device IP address after booking via the API.
However, in my opinion, the API consumer can specify a device by IP address (and port) for the booking and operator can identify the device to be requested booking. At this time when the QoS Booking API is invoked, operator also might preserve which device is booked by using other format such as MSISDN which is transformed from IP address and may be used at the time of new QoS treatment. It may resolve your concern which is possibility of IP address change.
And on the top of that, if API consumer specify the server IP address and port, I think this API can treat QoS on IP flow basis.

[hdamker]

@JoachimDahlgren is your question answered and we can close the issue. Alternatively we can convert to discussion.

[JoachimDahlgren]

My question was if IP flow granularity is to be supported by QoS Booking. The two answers kind of indicate that it should not be supported but that IP address could be used to identify the device at time of booking.

If that is the case then this should be documented and devicePorts, applicationServer and applicationServerPorts ought to be removed not to lead people to think they can book for a specific flow.

[hdamker]

My question was if IP flow granularity is to be supported by QoS Booking. The two answers kind of indicate that it should not be supported but that IP address could be used to identify the device at time of booking.

@JoachimDahlgren My initial answer wasn't correct or at least misleading ... as @Masa8106 described in his answer it is possible for the network operator to derive all the necessary information which determines a flow:

• Device IP address for the flow is the IP address of the device at the time the actually booking (QoS session) gets available. That is, as described by @Masa8106 , not necessarily the same IP address which was used to identify the device at the booking time. That's similar to the case that the device is identified by PhoneNumber ... the IP address is then implicit and known to the network operator
• applicationServer, devicePorts and applicationServerPorts are outside the device object and will be used together with the actual device IP address to determine the flow.

[JoachimDahlgren]

So I am to interpret your answers as "QoS Booking should support booking QoS for a future flow".

That then leads me back to the original three questions

• What is then the use case?
• How will the application developer know what will be the future flow to change quality on?
• What should happen if the traffic to be boosted have moved from one flow to another?

Note: It is probably a bad idea to use the IP address to do the booking as we could not respond back the MSISDN in the response. Thereby the only reference to the device in the booking (in case the IP address change) is an invalid IP address.

[hdamker]

Note: It is probably a bad idea to use the IP address to do the booking as we could not respond back the MSISDN in the response. Thereby the only reference to the device in the booking (in case the IP address change) is an invalid IP address.

That is reopening all the discussions about the device object and which responses are allowed/possible. Yes, the IP address (which one: IPv4 or IPv6 ... IPv4 is normally not sufficient to identify a device) might be a last resort for specific use case. Preferable is the device identification within the access token (hint: there is no device identifier in the responses allowed). The newly defined "DeviceResponse" is only meant to indicate to the API Consumer which device property was used in case the API Consumer provided multiple ones. In short: in many cases there no device reference at all in the booking resource responses.

[Masa8106]

@JoachimDahlgren,
Let me try to respond to your questions.

• What is then the use case?
  => Though we can think many use cases, one of examples is ‘Premium Connection Ticket’ at an event venue as I mentioned in other issue (Issue #12). I assume it would be possible to provide priority QoS for video streaming services during the event period at the event venue.

• How will the application developer know what will be the future flow to change quality on?
  => The application developer, which I assume is API consumer, can know the device of the future flow at the time of booking request as @hdamker mentioned above. Even in case the device IP address changes, I assume the application develover has Booking ID where operator can trace the device IP address change of the device. The API consumer can know the application server of the flow because the application developer itself operates the server.

• What should happen if the traffic to be boosted have moved from one flow to another?
  => I think it should sent notification to the API consumer, if the API consumer subscribes it at the time of booking request. What else do you think should happen?