Update and rename QoD_Latency_Bandwidth_User_Story.md

documentation/API_documentation/QoD_Latency_Bandwidth_User_Story.md → documentation/API_documentation/QoD_User_Story.md

@@ -1,10 +1,10 @@
-# QoD Stable Bandwidth and Latency API User Story
+# Quality-On-Demand (QoD) API User Story
 
 | **Item** | **Details** |
 | ---- | ------- |
-| ***Summary*** | As an application developer belonging to an enterprise, I want to request (using my application server/backend service), stable bandwidth/latency for a specified App-Flow from a Communication Service Provider (CSP), so that I can ensure better quality of experience for our end users inlcuding under network congestion.  |
-| ***Roles, Actors and Scope*** | **Roles:** Customer:User<br> **Actors:** Application service providers, hyperscalers, application developers. Currently the API does not explicitly handle consent management (expects that the customer either owns the device subscriptions or has agreed to manage consent as a part of general Terms and Conditions) and hence end users are not included as Actors. As this changes, the actor list will be extended with end users. <br> **Scope:** *Order To Activate (OTA)* \- Create/Remove/Get service instance (QoD session)\, get notification about the instance (QoD session) |
+| ***Summary*** | As an application developer belonging to an enterprise, I want to request (using my application server/backend service), stable latency or stable throughput for a specified App-Flow from a Communication Service Provider (CSP), so that I can ensure better quality of experience for our end users inlcluding under network congestion.  |
+| ***Roles, Actors and Scope*** | **Roles:** Customer:User<br> **Actors:** Application service providers, hyperscalers, application developers. Currently the API does not explicitly handle consent management (expects that the customer either owns the device subscriptions or has agreed to manage consent as a part of general Terms and Conditions) and hence end users are not included as Actors. As this changes, the actor list will be extended with end users. <br> **Scope:** *Order To Activate (OTA)* \- Create/Remove/Get service instance (QoD session resource)\, get notification about the instance (QoD session resource) |
 | ***Pre-conditions*** |The preconditions are listed below:<br><ol><li>The Customer:BusinessManager and Customer:Administrator have been onboarded to the CSP's API platform.</li><li>The Customer:BusinessManager has successfully subscribed to the QoD product from the product catalog.</li><li>The Customer:Administrator has onboarded the Customer:User to the platform.</li><li>The Customer either owns the device subscriptions or has agreed to the terms and conditions of the CSP for managing consent of subscription owners.</li><li>The means to get the access token are known to the Customer:User to ensure secure access of the API.|
-| ***Activities/Steps*** | **Starts when:** The customer application server makes a POST request to the QoD API to create a new QoD session and optionally registers a callback URL for receiving notifications.<br>**Ends when:** The customer application server makes a DELETE request to the QoD API, or the QoD session deletion was triggered automatically either because the customer specified duration has expired or the default expiration limit set by the QoD service provider has reached. |
-| ***Post-conditions*** | The specified App-Flow was provided stable throughput/latency and if callback url was specified, a QoD session termination notification was received at the end.  |
-| ***Exceptions*** | Several exceptions might occur during the QoD API operations<br>- Unauthorized: Not valid credentials (e.g. use of already expired access token).<br>- Invalid input: Not valid input data to invoke operation (e.g. IP address format not as expected).<br>- Conflict: Internal configuration policies didn’t allow for operations.<br>- Session-not-created: Due to other internal errors, QoS session could not be created|
+| ***Activities/Steps*** | **Starts when:** The customer application server makes a POST request to the QoD API to create a new QoD session resource and optionally registers a callback URL for receiving notifications.<br>**Ends when:** The customer application server makes a DELETE request to the QoD API, or the QoD session resource deletion was triggered automatically either because the customer specified duration has expired or the default expiration limit set by the QoD service provider has reached. |
+| ***Post-conditions*** | The specified App-Flow was provided stable latency or stable throughput and if callback URL was specified, a QoD session resource termination notification was received at the end.  |
+| ***Exceptions*** | Several exceptions might occur during the QoD API operations<br>- Unauthorized: Not valid credentials (e.g. use of already expired access token).<br>- Invalid input: Not valid input data to invoke operation (e.g. IP address format not as expected).<br>- Conflict: Internal configuration policies didn’t allow for operations.<br>- Session-not-created: Due to other internal errors, QoS session resource could not be created|