QoS B: Update the status diagram

[Masa8106]

Problem description
During discussions on test plan, the status diagram assumed when this repositoty established is found to miss some scenarios. Some Updates are needed for next release, along aligning with that of other CQM APIs.

Possible evolution
Update the status diagram in order to cover all test scenarios and to align with that of other CQM APIs. After the update it, the API difinition will be updated.

Additional context
As discussed in the CQM Breakout meeting, this issue is opened by transferred from the discussion in PR #70.

[Masa8106]

The latest proposal of updated diagram is the following:

• We can discuss on options "separate states of booking and QoS Session (Connectivity) (more complex?) vs combined state". Ericsson stated the separate states are better. I hope your feedback from others.
• There were several comments in our discussion. The diagram will be modified soon based on them.

[tlohmar]

Thanks for separating this out.
On "Activated (Available)" and "Activated (Unavailable)": Here, we are mixing two states into one state variable and the API customer needs to handle this two states separately (even when encoded into one state variable).

• State of the booking (which is Activated)
• State of the connectivity (which is either Available or Unavailable).

I would recommend using two state variables, since the API consumer anyhow need to separate the two.

On "Creation of QoS Flow" and "Failure to create QoS Flow" (grey boxes): I believe, this touches on some realization of the underlying transformation function, i.e. trying to add another QoS Flow. However, other realizations could teardown the existing QoS Flow and reconfigure the QoS Profile when re-establishing the QoS Flow. Thus, I suggest to mark these as examples.

on "Duration expiration, Delete booking" (grey boxes). The phrasing "Delete booking" sounds like using the DELETE method for deleting the booking resource. I believe, that there is no "Delete Booking" operation, when the booking terminates based on the service end time reached, both "Activated (Available)" and "Activated (Unavailable)". Thus, I suggest to remove the "Delete Booking" from these boxes and only keep "Duration expiration".

[Masa8106]

@tlohmar, thanks for your feedback. As the feedback, I have updated the state diagram.

The left diagram is state of booking and,
the right diagram is state of requested connectivity, which is available in case of "Activated" booking state. When the time window starts, the first state depends on some realization of the underlying transformation function. For exampe, it may be "available" in case to add another QoS Flow, while "unavailable" in case to teardown the existing QoS Flow and reconfigure the QoS Profile until completion of re-establishing the QoS flow.

Regarding final your suggetion to remove "Delete booking", I assume it is DELETE method. For my clarification, you mean booking resource will be removed therefore state of booking will be removed too?

[Masa8106]

Some updates on the diagram in the above comment.
If we can agree the state diagram, I will open a PR to align the API spec with the diagram.

[jlurien]

I like also the distinction between the control plane for the booking and the service plane for the QoS session itself. As we are used to the terms AVAILABLE/UNAVAILABLE from QoD sessions API, I would keep them for the equivalent cases. For booking management I would suggest ACTIVE or ONGOING instead of ACTIVATED.

In the case of TERMINATED, we may use CLOSED instead, to cover both that the booking expired or the booking was declined. Maybe a native speaker may help here better :)

[Masa8106]

@jlurien, Thank you for your comment.

I am ok with the distinction between state for the booking and for the QoS session. Please let me open a new PR.

Regarding the term of states you pointed out, we can update with better wording. What I want to say is that it is better to align or harmonise with other CQM APIs. Let's discuss about it in the next meeting.