Repository navigation
Should IP flows be supported in QoS Booking? #9
Description
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?
Activity
hdamker commentedon Apr 25, 2025
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 commentedon May 7, 2025
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 commentedon Jun 30, 2025
@JoachimDahlgren is your question answered and we can close the issue. Alternatively we can convert to discussion.
JoachimDahlgren commentedon Jun 30, 2025
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 commentedon Jun 30, 2025
@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:
JoachimDahlgren commentedon Jun 30, 2025
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
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 commentedon Jun 30, 2025
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.