Application Developers use cases

[sergiobrisio]

Problem description

The current basic list of use cases (Media Production, Festival, Enterprise, etc), seems oriented to a high-capacity demand with additional enterprise/public sector IoT scenarios. The risk is to not properly include the point of view of the Mobile (including wearables IoT) Application Developer, both in consumer and enterprise applications. This kind of stakeholders can have many unexpected needs to match for their innovative applications (latency? jitter? location/movement/speed?) and could request (even for a static Dedicated Network) a filter to match his own application requirements with 2 kinds of available capabilities: the network ones and end user device ones.

Possible evolution

It could be relevant to figure out if this kind of filtering/negotiation scenario for the application developer requirements to match network and device capabilities will be enabled in future phases.

Alternative solution

We could move this kind of scenario to a different API, but the risk is to split an enterprise dedicated network from a consumer dedicated network, while the demand for the former can benefit from the demand from the latter category of use cases.

Additional context

[tlohmar]

Hi @sergiobrisio,

a filter to match his own application requirements

additional filter schemes and criteria's are certainly needed, when a CSP starts offering many different Network Profiles and / or many different QOS Profiles. When only some few are provided, it can be acceptable, when the API invoker selects the needed capability from a full list.

Are you missing a particular filter feature?

[sergiobrisio]

It is not a problem to start as you say without filtering capabilities, but it is important to design the API set with future extensibility in mind to accommodate negotiation/filtering demands. If we assume that some of the capabilities of the dedicated network will not be negotiable, we could put in an object like network-profile which could be distinct from the filtered / negotiable ones (ex like in TMF645 Service Qualification API). If we follow a similar approach, we can separate non-negotiable features (e.g., NetworkProfile) from negotiable/filter components (e.g., BaseNetworkInfo), creating a modular design that isolates different aspects of the API. In this way we have also the latter more tuned to the ASP way of working, easier to extend without affecting the CSP view of network profiles services.