From bab2221170d3cebcac190cbbf6d9573d5e4b99b5 Mon Sep 17 00:00:00 2001 From: Masaharu Hattori <112887632+Masa8106@users.noreply.github.com> Date: Mon, 2 Dec 2024 17:06:59 +0000 Subject: [PATCH 01/13] Create APIproposal_QoS_Booking_KDDI. md --- .../API proposals/APIproposal_QoS_Booking_KDDI. md | 12 ++++++++++++ 1 file changed, 12 insertions(+) create mode 100644 documentation/API proposals/APIproposal_QoS_Booking_KDDI. md diff --git a/documentation/API proposals/APIproposal_QoS_Booking_KDDI. md b/documentation/API proposals/APIproposal_QoS_Booking_KDDI. md new file mode 100644 index 0000000..1529829 --- /dev/null +++ b/documentation/API proposals/APIproposal_QoS_Booking_KDDI. md @@ -0,0 +1,12 @@ +| **Field** | Description | +| ---- | ----- | +| API family name | Name of the API or API family | +| API family owner | Company submitting the API proposal. | +| API summary | High level description / scope of the API or API family, and two/three examples of in-scope business cases. | +| Technical viability | Identify the underlying network/cloud capabilities which are needed for the support of this API or API family, relating these capabilities them to standards maturity.
Example: this API requires the availability of NEF with this Rel-15 "X"feature. +| Commercial viability | Specify the availability of commercial or (industrialized) open-source solutions for the identified network/cloud capabilities.
NOTE: If open-source, provide a publicly available reference/link to the actual solution, and specify the version under consideration.| +| YAML code available? | YES / NO. | +| Validated in lab/productive environments? | YES / NO.
If YES, specify if it was lab network or productive network. | +| Validated with real customers? | YES / NO.
If YES, specify how many customers participated in the evaluation, and what their use cases were.
NOTE: It is not mandatory (though recommendable) to specify the name of the customers. | +| Validated with operators? | YES / NO.
If YES, specify how many operators participated in the evaluation.
NOTE: It is not mandatory (though recommendable) to specify the name of the operators. | +| Supporters in API Backlog Working Group | List of supporters.
NOTE: That shall be added by the Working Group. Supporting an API proposal means that the supporting company must provide at least 1 (one) Maintainer at the time of the Sub Project creation. | From fdd8fcbceab7675e184db421b827e28de4d91a68 Mon Sep 17 00:00:00 2001 From: Masaharu Hattori <112887632+Masa8106@users.noreply.github.com> Date: Mon, 2 Dec 2024 17:11:10 +0000 Subject: [PATCH 02/13] Update APIproposal_QoS_Booking_KDDI. md --- .../API proposals/APIproposal_QoS_Booking_KDDI. md | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/documentation/API proposals/APIproposal_QoS_Booking_KDDI. md b/documentation/API proposals/APIproposal_QoS_Booking_KDDI. md index 1529829..fc66548 100644 --- a/documentation/API proposals/APIproposal_QoS_Booking_KDDI. md +++ b/documentation/API proposals/APIproposal_QoS_Booking_KDDI. md @@ -1,12 +1,12 @@ | **Field** | Description | | ---- | ----- | -| API family name | Name of the API or API family | -| API family owner | Company submitting the API proposal. | +| API family name | QoS Booking | +| API family owner | KDDI | | API summary | High level description / scope of the API or API family, and two/three examples of in-scope business cases. | | Technical viability | Identify the underlying network/cloud capabilities which are needed for the support of this API or API family, relating these capabilities them to standards maturity.
Example: this API requires the availability of NEF with this Rel-15 "X"feature. | Commercial viability | Specify the availability of commercial or (industrialized) open-source solutions for the identified network/cloud capabilities.
NOTE: If open-source, provide a publicly available reference/link to the actual solution, and specify the version under consideration.| -| YAML code available? | YES / NO. | -| Validated in lab/productive environments? | YES / NO.
If YES, specify if it was lab network or productive network. | -| Validated with real customers? | YES / NO.
If YES, specify how many customers participated in the evaluation, and what their use cases were.
NOTE: It is not mandatory (though recommendable) to specify the name of the customers. | -| Validated with operators? | YES / NO.
If YES, specify how many operators participated in the evaluation.
NOTE: It is not mandatory (though recommendable) to specify the name of the operators. | -| Supporters in API Backlog Working Group | List of supporters.
NOTE: That shall be added by the Working Group. Supporting an API proposal means that the supporting company must provide at least 1 (one) Maintainer at the time of the Sub Project creation. | +| YAML code available? | YES | +| Validated in lab/productive environments? | NO | +| Validated with real customers? | NO | +| Validated with operators? | NO | +| Supporters in API Backlog Working Group | List of supporters.
NOTE: That shall be added by the Working Group. | From a56c6224e6d6c765015fac25a90fed90d518d940 Mon Sep 17 00:00:00 2001 From: Masaharu Hattori <112887632+Masa8106@users.noreply.github.com> Date: Mon, 2 Dec 2024 18:39:00 +0000 Subject: [PATCH 03/13] Update APIproposal_QoS_Booking_KDDI. md --- .../APIproposal_QoS_Booking_KDDI. md | 19 ++++++++++++++++--- 1 file changed, 16 insertions(+), 3 deletions(-) diff --git a/documentation/API proposals/APIproposal_QoS_Booking_KDDI. md b/documentation/API proposals/APIproposal_QoS_Booking_KDDI. md index fc66548..14e088c 100644 --- a/documentation/API proposals/APIproposal_QoS_Booking_KDDI. md +++ b/documentation/API proposals/APIproposal_QoS_Booking_KDDI. md @@ -2,9 +2,22 @@ | ---- | ----- | | API family name | QoS Booking | | API family owner | KDDI | -| API summary | High level description / scope of the API or API family, and two/three examples of in-scope business cases. | -| Technical viability | Identify the underlying network/cloud capabilities which are needed for the support of this API or API family, relating these capabilities them to standards maturity.
Example: this API requires the availability of NEF with this Rel-15 "X"feature. -| Commercial viability | Specify the availability of commercial or (industrialized) open-source solutions for the identified network/cloud capabilities.
NOTE: If open-source, provide a publicly available reference/link to the actual solution, and specify the version under consideration.| +| API summary | This API adds a booking feature on QoD service. This API offers a programmable interface for developers to request the assignment of a certain QoS Profile to a certain device in advance. This API enables the developers to book an assignment of the requested QoS profile to an specific device with some conditions such as start time, duration and location. + + QoD Service provides the customer with the ability to set certain 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. + ・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. + + But there is another possible use case for QoD, which is not currently supported: + ・the developer wants to give devices an right to use the required QoD profile in advance in order to know the expected number of users, while end user can apply and secure the connectivity service on "first come first served" basis. + +Proposed evolution of the existing API is to add support for a new booking feature with following operations: +Creating a booking for required QoS profile +Removing the booking for required QoS profile +Getting the QoS booking details +Updating the QoS booking details for a device | +| Technical viability | This API can leverage on the existing QoD services such as CAMARA QoD API, QoS Profile API and OoD Provision Mode API. . +| Commercial viability | This API adds a booking feature on QoD service. This feature is more convenient for those use cases where a limited network, especially radio, resourece have to be shared by multiple devices simalteneously at the same place. For example, at the event venue, this feature enables end users to book high quality connectivity in advance.| | YAML code available? | YES | | Validated in lab/productive environments? | NO | | Validated with real customers? | NO | From 1efdc3780afec8a8f691b139bdfc3b4eafacfc08 Mon Sep 17 00:00:00 2001 From: Masaharu Hattori <112887632+Masa8106@users.noreply.github.com> Date: Mon, 2 Dec 2024 18:45:35 +0000 Subject: [PATCH 04/13] Update APIproposal_QoS_Booking_KDDI. md --- .../APIproposal_QoS_Booking_KDDI. md | 23 ++++++++----------- 1 file changed, 10 insertions(+), 13 deletions(-) diff --git a/documentation/API proposals/APIproposal_QoS_Booking_KDDI. md b/documentation/API proposals/APIproposal_QoS_Booking_KDDI. md index 14e088c..a940228 100644 --- a/documentation/API proposals/APIproposal_QoS_Booking_KDDI. md +++ b/documentation/API proposals/APIproposal_QoS_Booking_KDDI. md @@ -3,19 +3,16 @@ | API family name | QoS Booking | | API family owner | KDDI | | API summary | This API adds a booking feature on QoD service. This API offers a programmable interface for developers to request the assignment of a certain QoS Profile to a certain device in advance. This API enables the developers to book an assignment of the requested QoS profile to an specific device with some conditions such as start time, duration and location. - - QoD Service provides the customer with the ability to set certain 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. - ・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. - - But there is another possible use case for QoD, which is not currently supported: - ・the developer wants to give devices an right to use the required QoD profile in advance in order to know the expected number of users, while end user can apply and secure the connectivity service on "first come first served" basis. - -Proposed evolution of the existing API is to add support for a new booking feature with following operations: -Creating a booking for required QoS profile -Removing the booking for required QoS profile -Getting the QoS booking details -Updating the QoS booking details for a device | +

QoD Service provides the customer with the ability to set certain 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. +
-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. +

But there is another possible use case for QoD, which is not currently supported: +
-the developer wants to give devices an right to use the required QoD profile in advance in order to know the expected number of users, while end user can apply and secure the connectivity service on "first come first served" basis. +

Proposed evolution of the existing API is to add support for a new booking feature with following operations: +
-Creating a booking for required QoS profile +
-Removing the booking for required QoS profile +
-Getting the QoS booking details +
-Updating the QoS booking details for a device | | Technical viability | This API can leverage on the existing QoD services such as CAMARA QoD API, QoS Profile API and OoD Provision Mode API. . | Commercial viability | This API adds a booking feature on QoD service. This feature is more convenient for those use cases where a limited network, especially radio, resourece have to be shared by multiple devices simalteneously at the same place. For example, at the event venue, this feature enables end users to book high quality connectivity in advance.| | YAML code available? | YES | From 07df7c5b7e9f740f1ad073b2a41de75535d0abe4 Mon Sep 17 00:00:00 2001 From: Masaharu Hattori <112887632+Masa8106@users.noreply.github.com> Date: Mon, 2 Dec 2024 19:02:55 +0000 Subject: [PATCH 05/13] Update APIproposal_QoS_Booking_KDDI. md --- .../APIproposal_QoS_Booking_KDDI. md | 18 ++++-------------- 1 file changed, 4 insertions(+), 14 deletions(-) diff --git a/documentation/API proposals/APIproposal_QoS_Booking_KDDI. md b/documentation/API proposals/APIproposal_QoS_Booking_KDDI. md index a940228..1bb5b3e 100644 --- a/documentation/API proposals/APIproposal_QoS_Booking_KDDI. md +++ b/documentation/API proposals/APIproposal_QoS_Booking_KDDI. md @@ -2,21 +2,11 @@ | ---- | ----- | | API family name | QoS Booking | | API family owner | KDDI | -| API summary | This API adds a booking feature on QoD service. This API offers a programmable interface for developers to request the assignment of a certain QoS Profile to a certain device in advance. This API enables the developers to book an assignment of the requested QoS profile to an specific device with some conditions such as start time, duration and location. -

QoD Service provides the customer with the ability to set certain 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. -
-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. -

But there is another possible use case for QoD, which is not currently supported: -
-the developer wants to give devices an right to use the required QoD profile in advance in order to know the expected number of users, while end user can apply and secure the connectivity service on "first come first served" basis. -

Proposed evolution of the existing API is to add support for a new booking feature with following operations: -
-Creating a booking for required QoS profile -
-Removing the booking for required QoS profile -
-Getting the QoS booking details -
-Updating the QoS booking details for a device | -| Technical viability | This API can leverage on the existing QoD services such as CAMARA QoD API, QoS Profile API and OoD Provision Mode API. . -| Commercial viability | This API adds a booking feature on QoD service. This feature is more convenient for those use cases where a limited network, especially radio, resourece have to be shared by multiple devices simalteneously at the same place. For example, at the event venue, this feature enables end users to book high quality connectivity in advance.| +| API summary | This API adds a booking feature on QoD service. This API offers a programmable interface for developers to request the assignment of a certain QoS Profile to a certain device in advance. This API enables the developers to book an assignment of the requested QoS profile to an specific device with some conditions such as start time, duration and location.

QoD Service provides the customer with the ability to set certain 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.
-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.

But there is another possible use case for QoD, which is not currently supported:
-the developer wants to give devices an right to use the required QoD profile in advance in order to know the expected number of users, while end user can apply and secure the connectivity service on "first come first served" basis.

Proposed evolution of the existing API is to add support for a new booking feature with following operations:
-Creating a booking for required QoS profile
-Removing the booking for required QoS profile
-Getting the QoS booking details
-Updating the QoS booking details for a device | +| Technical viability | This API can leverage on the existing QoD services such as CAMARA QoD API, QoS Profile API and OoD Provision Mode API.| +| Commercial viability | This API adds a booking feature on QoD service. This feature is more convenient for those use cases where a limited network, especially radio, resourece have to be shared by multiple devices simalteneously at the same place. For example, at the event venue, this feature enables end users to book high quality connectivity in advance.| | YAML code available? | YES | | Validated in lab/productive environments? | NO | | Validated with real customers? | NO | | Validated with operators? | NO | -| Supporters in API Backlog Working Group | List of supporters.
NOTE: That shall be added by the Working Group. | +| Supporters in API Backlog Working Group | List of supporters.
NOTE: That shall be added by the Working Group.| From 1d9339a1908cf22aa168f52f29d2e6c9af6875c4 Mon Sep 17 00:00:00 2001 From: Masaharu Hattori <112887632+Masa8106@users.noreply.github.com> Date: Mon, 2 Dec 2024 19:07:34 +0000 Subject: [PATCH 06/13] Create APIproposal_QoS_Booking_KDDI.md --- .../API proposals/APIproposal_QoS_Booking_KDDI.md | 12 ++++++++++++ 1 file changed, 12 insertions(+) create mode 100644 documentation/API proposals/APIproposal_QoS_Booking_KDDI.md diff --git a/documentation/API proposals/APIproposal_QoS_Booking_KDDI.md b/documentation/API proposals/APIproposal_QoS_Booking_KDDI.md new file mode 100644 index 0000000..1bb5b3e --- /dev/null +++ b/documentation/API proposals/APIproposal_QoS_Booking_KDDI.md @@ -0,0 +1,12 @@ +| **Field** | Description | +| ---- | ----- | +| API family name | QoS Booking | +| API family owner | KDDI | +| API summary | This API adds a booking feature on QoD service. This API offers a programmable interface for developers to request the assignment of a certain QoS Profile to a certain device in advance. This API enables the developers to book an assignment of the requested QoS profile to an specific device with some conditions such as start time, duration and location.

QoD Service provides the customer with the ability to set certain 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.
-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.

But there is another possible use case for QoD, which is not currently supported:
-the developer wants to give devices an right to use the required QoD profile in advance in order to know the expected number of users, while end user can apply and secure the connectivity service on "first come first served" basis.

Proposed evolution of the existing API is to add support for a new booking feature with following operations:
-Creating a booking for required QoS profile
-Removing the booking for required QoS profile
-Getting the QoS booking details
-Updating the QoS booking details for a device | +| Technical viability | This API can leverage on the existing QoD services such as CAMARA QoD API, QoS Profile API and OoD Provision Mode API.| +| Commercial viability | This API adds a booking feature on QoD service. This feature is more convenient for those use cases where a limited network, especially radio, resourece have to be shared by multiple devices simalteneously at the same place. For example, at the event venue, this feature enables end users to book high quality connectivity in advance.| +| YAML code available? | YES | +| Validated in lab/productive environments? | NO | +| Validated with real customers? | NO | +| Validated with operators? | NO | +| Supporters in API Backlog Working Group | List of supporters.
NOTE: That shall be added by the Working Group.| From 88597d5f962c4bac5364fe0cc403929d7210f1f8 Mon Sep 17 00:00:00 2001 From: Masaharu Hattori <112887632+Masa8106@users.noreply.github.com> Date: Wed, 4 Dec 2024 22:42:00 +0000 Subject: [PATCH 07/13] Revert "Create APIproposal_QoS_Booking_KDDI.md" This reverts commit 1d9339a1908cf22aa168f52f29d2e6c9af6875c4. --- .../API proposals/APIproposal_QoS_Booking_KDDI.md | 12 ------------ 1 file changed, 12 deletions(-) delete mode 100644 documentation/API proposals/APIproposal_QoS_Booking_KDDI.md diff --git a/documentation/API proposals/APIproposal_QoS_Booking_KDDI.md b/documentation/API proposals/APIproposal_QoS_Booking_KDDI.md deleted file mode 100644 index 1bb5b3e..0000000 --- a/documentation/API proposals/APIproposal_QoS_Booking_KDDI.md +++ /dev/null @@ -1,12 +0,0 @@ -| **Field** | Description | -| ---- | ----- | -| API family name | QoS Booking | -| API family owner | KDDI | -| API summary | This API adds a booking feature on QoD service. This API offers a programmable interface for developers to request the assignment of a certain QoS Profile to a certain device in advance. This API enables the developers to book an assignment of the requested QoS profile to an specific device with some conditions such as start time, duration and location.

QoD Service provides the customer with the ability to set certain 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.
-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.

But there is another possible use case for QoD, which is not currently supported:
-the developer wants to give devices an right to use the required QoD profile in advance in order to know the expected number of users, while end user can apply and secure the connectivity service on "first come first served" basis.

Proposed evolution of the existing API is to add support for a new booking feature with following operations:
-Creating a booking for required QoS profile
-Removing the booking for required QoS profile
-Getting the QoS booking details
-Updating the QoS booking details for a device | -| Technical viability | This API can leverage on the existing QoD services such as CAMARA QoD API, QoS Profile API and OoD Provision Mode API.| -| Commercial viability | This API adds a booking feature on QoD service. This feature is more convenient for those use cases where a limited network, especially radio, resourece have to be shared by multiple devices simalteneously at the same place. For example, at the event venue, this feature enables end users to book high quality connectivity in advance.| -| YAML code available? | YES | -| Validated in lab/productive environments? | NO | -| Validated with real customers? | NO | -| Validated with operators? | NO | -| Supporters in API Backlog Working Group | List of supporters.
NOTE: That shall be added by the Working Group.| From 97ef2d82fb800a740a30a30f7ea444e970c8479b Mon Sep 17 00:00:00 2001 From: Masaharu Hattori <112887632+Masa8106@users.noreply.github.com> Date: Wed, 4 Dec 2024 22:42:29 +0000 Subject: [PATCH 08/13] Revert "Update APIproposal_QoS_Booking_KDDI. md" This reverts commit 07df7c5b7e9f740f1ad073b2a41de75535d0abe4. --- .../APIproposal_QoS_Booking_KDDI. md | 18 ++++++++++++++---- 1 file changed, 14 insertions(+), 4 deletions(-) diff --git a/documentation/API proposals/APIproposal_QoS_Booking_KDDI. md b/documentation/API proposals/APIproposal_QoS_Booking_KDDI. md index 1bb5b3e..a940228 100644 --- a/documentation/API proposals/APIproposal_QoS_Booking_KDDI. md +++ b/documentation/API proposals/APIproposal_QoS_Booking_KDDI. md @@ -2,11 +2,21 @@ | ---- | ----- | | API family name | QoS Booking | | API family owner | KDDI | -| API summary | This API adds a booking feature on QoD service. This API offers a programmable interface for developers to request the assignment of a certain QoS Profile to a certain device in advance. This API enables the developers to book an assignment of the requested QoS profile to an specific device with some conditions such as start time, duration and location.

QoD Service provides the customer with the ability to set certain 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.
-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.

But there is another possible use case for QoD, which is not currently supported:
-the developer wants to give devices an right to use the required QoD profile in advance in order to know the expected number of users, while end user can apply and secure the connectivity service on "first come first served" basis.

Proposed evolution of the existing API is to add support for a new booking feature with following operations:
-Creating a booking for required QoS profile
-Removing the booking for required QoS profile
-Getting the QoS booking details
-Updating the QoS booking details for a device | -| Technical viability | This API can leverage on the existing QoD services such as CAMARA QoD API, QoS Profile API and OoD Provision Mode API.| -| Commercial viability | This API adds a booking feature on QoD service. This feature is more convenient for those use cases where a limited network, especially radio, resourece have to be shared by multiple devices simalteneously at the same place. For example, at the event venue, this feature enables end users to book high quality connectivity in advance.| +| API summary | This API adds a booking feature on QoD service. This API offers a programmable interface for developers to request the assignment of a certain QoS Profile to a certain device in advance. This API enables the developers to book an assignment of the requested QoS profile to an specific device with some conditions such as start time, duration and location. +

QoD Service provides the customer with the ability to set certain 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. +
-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. +

But there is another possible use case for QoD, which is not currently supported: +
-the developer wants to give devices an right to use the required QoD profile in advance in order to know the expected number of users, while end user can apply and secure the connectivity service on "first come first served" basis. +

Proposed evolution of the existing API is to add support for a new booking feature with following operations: +
-Creating a booking for required QoS profile +
-Removing the booking for required QoS profile +
-Getting the QoS booking details +
-Updating the QoS booking details for a device | +| Technical viability | This API can leverage on the existing QoD services such as CAMARA QoD API, QoS Profile API and OoD Provision Mode API. . +| Commercial viability | This API adds a booking feature on QoD service. This feature is more convenient for those use cases where a limited network, especially radio, resourece have to be shared by multiple devices simalteneously at the same place. For example, at the event venue, this feature enables end users to book high quality connectivity in advance.| | YAML code available? | YES | | Validated in lab/productive environments? | NO | | Validated with real customers? | NO | | Validated with operators? | NO | -| Supporters in API Backlog Working Group | List of supporters.
NOTE: That shall be added by the Working Group.| +| Supporters in API Backlog Working Group | List of supporters.
NOTE: That shall be added by the Working Group. | From 0b8b61f56f25bda48be43c0a8fbe749eafc8a57f Mon Sep 17 00:00:00 2001 From: Masaharu Hattori <112887632+Masa8106@users.noreply.github.com> Date: Wed, 4 Dec 2024 22:42:37 +0000 Subject: [PATCH 09/13] Revert "Update APIproposal_QoS_Booking_KDDI. md" This reverts commit 1efdc3780afec8a8f691b139bdfc3b4eafacfc08. --- .../APIproposal_QoS_Booking_KDDI. md | 23 +++++++++++-------- 1 file changed, 13 insertions(+), 10 deletions(-) diff --git a/documentation/API proposals/APIproposal_QoS_Booking_KDDI. md b/documentation/API proposals/APIproposal_QoS_Booking_KDDI. md index a940228..14e088c 100644 --- a/documentation/API proposals/APIproposal_QoS_Booking_KDDI. md +++ b/documentation/API proposals/APIproposal_QoS_Booking_KDDI. md @@ -3,16 +3,19 @@ | API family name | QoS Booking | | API family owner | KDDI | | API summary | This API adds a booking feature on QoD service. This API offers a programmable interface for developers to request the assignment of a certain QoS Profile to a certain device in advance. This API enables the developers to book an assignment of the requested QoS profile to an specific device with some conditions such as start time, duration and location. -

QoD Service provides the customer with the ability to set certain 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. -
-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. -

But there is another possible use case for QoD, which is not currently supported: -
-the developer wants to give devices an right to use the required QoD profile in advance in order to know the expected number of users, while end user can apply and secure the connectivity service on "first come first served" basis. -

Proposed evolution of the existing API is to add support for a new booking feature with following operations: -
-Creating a booking for required QoS profile -
-Removing the booking for required QoS profile -
-Getting the QoS booking details -
-Updating the QoS booking details for a device | + + QoD Service provides the customer with the ability to set certain 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. + ・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. + + But there is another possible use case for QoD, which is not currently supported: + ・the developer wants to give devices an right to use the required QoD profile in advance in order to know the expected number of users, while end user can apply and secure the connectivity service on "first come first served" basis. + +Proposed evolution of the existing API is to add support for a new booking feature with following operations: +Creating a booking for required QoS profile +Removing the booking for required QoS profile +Getting the QoS booking details +Updating the QoS booking details for a device | | Technical viability | This API can leverage on the existing QoD services such as CAMARA QoD API, QoS Profile API and OoD Provision Mode API. . | Commercial viability | This API adds a booking feature on QoD service. This feature is more convenient for those use cases where a limited network, especially radio, resourece have to be shared by multiple devices simalteneously at the same place. For example, at the event venue, this feature enables end users to book high quality connectivity in advance.| | YAML code available? | YES | From a505940f73ac304d3b3fa2d1d3c4f95fd3aa00f6 Mon Sep 17 00:00:00 2001 From: Masaharu Hattori <112887632+Masa8106@users.noreply.github.com> Date: Wed, 4 Dec 2024 22:42:44 +0000 Subject: [PATCH 10/13] Revert "Update APIproposal_QoS_Booking_KDDI. md" This reverts commit a56c6224e6d6c765015fac25a90fed90d518d940. --- .../APIproposal_QoS_Booking_KDDI. md | 19 +++---------------- 1 file changed, 3 insertions(+), 16 deletions(-) diff --git a/documentation/API proposals/APIproposal_QoS_Booking_KDDI. md b/documentation/API proposals/APIproposal_QoS_Booking_KDDI. md index 14e088c..fc66548 100644 --- a/documentation/API proposals/APIproposal_QoS_Booking_KDDI. md +++ b/documentation/API proposals/APIproposal_QoS_Booking_KDDI. md @@ -2,22 +2,9 @@ | ---- | ----- | | API family name | QoS Booking | | API family owner | KDDI | -| API summary | This API adds a booking feature on QoD service. This API offers a programmable interface for developers to request the assignment of a certain QoS Profile to a certain device in advance. This API enables the developers to book an assignment of the requested QoS profile to an specific device with some conditions such as start time, duration and location. - - QoD Service provides the customer with the ability to set certain 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. - ・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. - - But there is another possible use case for QoD, which is not currently supported: - ・the developer wants to give devices an right to use the required QoD profile in advance in order to know the expected number of users, while end user can apply and secure the connectivity service on "first come first served" basis. - -Proposed evolution of the existing API is to add support for a new booking feature with following operations: -Creating a booking for required QoS profile -Removing the booking for required QoS profile -Getting the QoS booking details -Updating the QoS booking details for a device | -| Technical viability | This API can leverage on the existing QoD services such as CAMARA QoD API, QoS Profile API and OoD Provision Mode API. . -| Commercial viability | This API adds a booking feature on QoD service. This feature is more convenient for those use cases where a limited network, especially radio, resourece have to be shared by multiple devices simalteneously at the same place. For example, at the event venue, this feature enables end users to book high quality connectivity in advance.| +| API summary | High level description / scope of the API or API family, and two/three examples of in-scope business cases. | +| Technical viability | Identify the underlying network/cloud capabilities which are needed for the support of this API or API family, relating these capabilities them to standards maturity.
Example: this API requires the availability of NEF with this Rel-15 "X"feature. +| Commercial viability | Specify the availability of commercial or (industrialized) open-source solutions for the identified network/cloud capabilities.
NOTE: If open-source, provide a publicly available reference/link to the actual solution, and specify the version under consideration.| | YAML code available? | YES | | Validated in lab/productive environments? | NO | | Validated with real customers? | NO | From 9c7af0ba374969074c2626b98c8d3a90c3b53555 Mon Sep 17 00:00:00 2001 From: Masaharu Hattori <112887632+Masa8106@users.noreply.github.com> Date: Wed, 4 Dec 2024 22:42:52 +0000 Subject: [PATCH 11/13] Revert "Update APIproposal_QoS_Booking_KDDI. md" This reverts commit fdd8fcbceab7675e184db421b827e28de4d91a68. --- .../API proposals/APIproposal_QoS_Booking_KDDI. md | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/documentation/API proposals/APIproposal_QoS_Booking_KDDI. md b/documentation/API proposals/APIproposal_QoS_Booking_KDDI. md index fc66548..1529829 100644 --- a/documentation/API proposals/APIproposal_QoS_Booking_KDDI. md +++ b/documentation/API proposals/APIproposal_QoS_Booking_KDDI. md @@ -1,12 +1,12 @@ | **Field** | Description | | ---- | ----- | -| API family name | QoS Booking | -| API family owner | KDDI | +| API family name | Name of the API or API family | +| API family owner | Company submitting the API proposal. | | API summary | High level description / scope of the API or API family, and two/three examples of in-scope business cases. | | Technical viability | Identify the underlying network/cloud capabilities which are needed for the support of this API or API family, relating these capabilities them to standards maturity.
Example: this API requires the availability of NEF with this Rel-15 "X"feature. | Commercial viability | Specify the availability of commercial or (industrialized) open-source solutions for the identified network/cloud capabilities.
NOTE: If open-source, provide a publicly available reference/link to the actual solution, and specify the version under consideration.| -| YAML code available? | YES | -| Validated in lab/productive environments? | NO | -| Validated with real customers? | NO | -| Validated with operators? | NO | -| Supporters in API Backlog Working Group | List of supporters.
NOTE: That shall be added by the Working Group. | +| YAML code available? | YES / NO. | +| Validated in lab/productive environments? | YES / NO.
If YES, specify if it was lab network or productive network. | +| Validated with real customers? | YES / NO.
If YES, specify how many customers participated in the evaluation, and what their use cases were.
NOTE: It is not mandatory (though recommendable) to specify the name of the customers. | +| Validated with operators? | YES / NO.
If YES, specify how many operators participated in the evaluation.
NOTE: It is not mandatory (though recommendable) to specify the name of the operators. | +| Supporters in API Backlog Working Group | List of supporters.
NOTE: That shall be added by the Working Group. Supporting an API proposal means that the supporting company must provide at least 1 (one) Maintainer at the time of the Sub Project creation. | From 6b91554ed6fd815c2e144c4484c6802a305b45d2 Mon Sep 17 00:00:00 2001 From: Masaharu Hattori <112887632+Masa8106@users.noreply.github.com> Date: Wed, 4 Dec 2024 22:42:56 +0000 Subject: [PATCH 12/13] Revert "Create APIproposal_QoS_Booking_KDDI. md" This reverts commit bab2221170d3cebcac190cbbf6d9573d5e4b99b5. --- .../API proposals/APIproposal_QoS_Booking_KDDI. md | 12 ------------ 1 file changed, 12 deletions(-) delete mode 100644 documentation/API proposals/APIproposal_QoS_Booking_KDDI. md diff --git a/documentation/API proposals/APIproposal_QoS_Booking_KDDI. md b/documentation/API proposals/APIproposal_QoS_Booking_KDDI. md deleted file mode 100644 index 1529829..0000000 --- a/documentation/API proposals/APIproposal_QoS_Booking_KDDI. md +++ /dev/null @@ -1,12 +0,0 @@ -| **Field** | Description | -| ---- | ----- | -| API family name | Name of the API or API family | -| API family owner | Company submitting the API proposal. | -| API summary | High level description / scope of the API or API family, and two/three examples of in-scope business cases. | -| Technical viability | Identify the underlying network/cloud capabilities which are needed for the support of this API or API family, relating these capabilities them to standards maturity.
Example: this API requires the availability of NEF with this Rel-15 "X"feature. -| Commercial viability | Specify the availability of commercial or (industrialized) open-source solutions for the identified network/cloud capabilities.
NOTE: If open-source, provide a publicly available reference/link to the actual solution, and specify the version under consideration.| -| YAML code available? | YES / NO. | -| Validated in lab/productive environments? | YES / NO.
If YES, specify if it was lab network or productive network. | -| Validated with real customers? | YES / NO.
If YES, specify how many customers participated in the evaluation, and what their use cases were.
NOTE: It is not mandatory (though recommendable) to specify the name of the customers. | -| Validated with operators? | YES / NO.
If YES, specify how many operators participated in the evaluation.
NOTE: It is not mandatory (though recommendable) to specify the name of the operators. | -| Supporters in API Backlog Working Group | List of supporters.
NOTE: That shall be added by the Working Group. Supporting an API proposal means that the supporting company must provide at least 1 (one) Maintainer at the time of the Sub Project creation. | From 27c43e1f43f2f49d8fc49f6a58d01e51e3571f36 Mon Sep 17 00:00:00 2001 From: Masaharu Hattori <112887632+Masa8106@users.noreply.github.com> Date: Wed, 4 Dec 2024 22:46:47 +0000 Subject: [PATCH 13/13] Add files via upload --- .../API proposals/APIproposal_QoS_Booking_KDDI.md | 12 ++++++++++++ 1 file changed, 12 insertions(+) create mode 100644 documentation/API proposals/APIproposal_QoS_Booking_KDDI.md diff --git a/documentation/API proposals/APIproposal_QoS_Booking_KDDI.md b/documentation/API proposals/APIproposal_QoS_Booking_KDDI.md new file mode 100644 index 0000000..b384fd5 --- /dev/null +++ b/documentation/API proposals/APIproposal_QoS_Booking_KDDI.md @@ -0,0 +1,12 @@ +| **Field** | Description | +| ---- | ----- | +| API family name | QoS Booking | +| API family owner | KDDI | +| API summary | This API adds a booking feature on QoD service. This API offers a programmable interface for developers to request an assignment of a certain QoS Profile to a certain device with some conditions such as start time, duration and location in advance.

Existing QoD Services, e.g. QoD API and OoD Provisioning API, provide customers with the ability to set certain profile of QoS to an access network connection in real time.:
But there is another possible use case for QoD, which is not currently supported:
Proposed evolution of the existing APIs is to add support for a new booking feature with following operations:
Input:Output:
In case of exception such as network failuar, this API notify status change to device. | +| Technical viability | This API can leverage on the existing QoD services such as CAMARA QoD API, QoS Profile API and OoD Provisioning API.| +| Commercial viability | This API adds a booking feature on QoD service. This feature is more convenient for those use cases where a limited network, especially radio, resourece have to be shared by multiple devices simalteneously at the same place. For example, at the event venue, this feature enables end users to apply and secure the connectivity service on "first come first served" basis in advance.| +| YAML code available? | YES | +| Validated in lab/productive environments? | NO | +| Validated with real customers? | NO | +| Validated with operators? | NO | +| Supporters in API Backlog Working Group | List of supporters.
NOTE: That shall be added by the Working Group.| \ No newline at end of file