The Quality-On-Demand (QoD) API provides a programmable interface for developers and other users (API consumers) to request stable latency or throughput managed by networks without the necessity to have an in-depth knowledge of the underlying network complexity (e.g. the 4G/5G system in case of a mobile network).
Create QoS Session to manage latency/throughput priorities
If the qosStatus in the API response is "AVAILABLE" and a notification callback is provided the API consumer will receive in addition to the response a
QOS_STATUS_CHANGED event notification with qosStatus as AVAILABLE.
If the qosStatus in the API response is REQUESTED, the client will receive either
- a
QOS_STATUS_CHANGEDevent notification withqosStatusasAVAILABLEafter the network notifies that it has created the requested session, or - a
QOS_STATUS_CHANGEDevent notification withqosStatusasUNAVAILABLEandstatusInfoasNETWORK_TERMINATEDafter the network notifies that it has failed to provide the requested session.
A QOS_STATUS_CHANGED event notification with qosStatus as UNAVAILABLE will also be send if the network terminates the session before the requested duration expired
NOTES:
-
In case of a
QOS_STATUS_CHANGEDevent withqosStatusasUNAVAILABLEandstatusInfoasNETWORK_TERMINATEDthe resources of the QoS session are not directly released, but will get deleted automatically at earliest 360 seconds after the event.This behavior allows API consumers which are not receiving notification events but are polling to get the session information with the
qosStatusUNAVAILABLEandstatusInfoNETWORK_TERMINATED. Before a API consumer can attempt to create a new QoD session for the same device and flow period they must release the session resources with an explicitdeleteoperation if not yet automatically deleted. -
The access token may be either 2-legged or 3-legged. See "Identifying the device from the access token" for further information
- When the API is invoked using a two-legged access token, the subject will be identified from the optional
deviceobject, which therefore MUST be provided. - When a three-legged access token is used however, this optional identifier MUST NOT be provided, as the subject will be uniquely identified from the access token.
- When the API is invoked using a two-legged access token, the subject will be identified from the optional
Check the Authorization guide on how to get an OAuth2 token, with the following scope:
dpv:RequestedServiceProvision#qod
Create an app on our Sandbox to get credentials and retrieve tokens so you can perform API calls to our operators' production environments, or use the following convenience token to test in mock mode:
mock_sandbox_access_token
You can explore our QoD sample code for additional guidance on using this API.