Workflow for Content Production & Contribution #4
Conversation
jordijoangimenez
added
the
documentation
Just fixing some typos.
|
|
||
| ### Step 1) Preparing your device, configuring application clients & servers and configuring client/server flows | ||
| * Devices have already best effort connectivity . | ||
| * Through app specific [AppAPI], the client app is properly connected to the Application Server. e.g. Haivision app with BBC server, or LiveU app with LiveU server, etc … |
There was a problem hiding this comment.
Note sure about the AppAPI terminology as it may get confused with the network APIs?
I think we may need to distinguish between processes that belong to the application (App + Application Provider) - probably out of scope unless there is need to expose information from such an application to the network and/or viceversa - to be discussed.
There was a problem hiding this comment.
Interaction between Application client and Application server
"Application-specific API" - enables communication between the production network orchestrator and the production device nodes (e.g. camera control units, vision mixer, wireless microphones, sound mixer, etc.), some of which are UEs.
Check previous page to be consistent with terminology.
| * Through app specific [AppAPI], the client app is properly connected to the Application Server. e.g. Haivision app with BBC server, or LiveU app with LiveU server, etc … | ||
|
|
||
| ### Step 2)Event planning and pre-booking | ||
| * a) Through the Network API Platform, the production crew can discover the capabilities the network can offer (for which the production company is eligible for). |
There was a problem hiding this comment.
We should say here that the production crew can discover the network capabilities that are available from those the production company is authorized to use.
What are the conditions?
- Geographical area?
- Availability of the capability in the target area
- Schedule?
This may be enough for now.
| ### Step 2)Event planning and pre-booking | ||
| * a) Through the Network API Platform, the production crew can discover the capabilities the network can offer (for which the production company is eligible for). | ||
| * Example: QoD available, connectivity monitoring available, Timing as a service available, edge compute instantiation, … | ||
| * b) Through the Network API Platform, the production crew requests network services for every of the planned SIM cards in advance. Possible services (Network Capabilities) are: |
There was a problem hiding this comment.
I would deal with the network services somewhere else. In a place dedicated specifically to the capabilities.
| * Schedule (starting time and closing time of the event) | ||
| * c) Through the Network API Platform, the production receives a booking offer responding to the service request. | ||
| * d) Through the Network API Platform the production accepts the service booking offer (involving payment/contract/SLA aspects)[TL6] . | ||
| * e) Through the production receives connection IDs to be used for every reserved SIM/services |
There was a problem hiding this comment.
Should e) be "Through the production receives connection IDs to be used for every reserved SIM/services"
Is a "connection ID" a parameter that identifies the SIM with the booked services?
| Independent steps that can be triggered during the life of the event: | ||
| * The production crew can use [GwAPI] to monitor that the flows are coming and are properly using the reserved resource. | ||
| * The production crew receives notification through [GwAPI] indicating potential issues (throughput, delay, …) | ||
| * The production crew through [GwAPI] can request a change of the current configuration |
There was a problem hiding this comment.
I propose that we keep here the generic workflow and then we instantiate the full workflow for Quality on Demand (to start with)
Then we have a good reference to check the definitions in https://github.com/camaraproject/QualityOnDemand/blob/r1.3/code/API_definitions/quality-on-demand.yaml
| This documentation is currently **under development and subject to change**. It reflects outcomes elaborated by 5G-MAG members as part of **WI: Network Exposure and APIs Supporting Media Services and Applications** | ||
| We welcome and encourage contributions from the broader community. If you are interested in becoming a member of the 5G-MAG and actively participating in shaping this work, please contact the [Project Office](https://www.5g-mag.com/contact) | ||
|
|
||
| # Required interactions to exploit network capabilities |
There was a problem hiding this comment.
Add a graphic with the steps
|
|
||
| Independent steps that can be triggered during the life of the event: | ||
| * The production crew can use [GwAPI] to monitor that the flows are coming and are properly using the reserved resource. | ||
| * The production crew receives notification through [GwAPI] indicating potential issues (throughput, delay, …) |
There was a problem hiding this comment.
[GwAPI] Network API Platform
Trying the new PullRequest driven work flow.