Proposal - Runtime Restrictions API

[gmuratk]

Problem description
There is currently no mechanism for API Producers (e.g. Operator) to communicate which optional capabilities/features/parameters are supported and enabled to API Consumers!

Possible evolution
A programmatic approach that is generic enough to describe Runtime restrictions imposed by an API Producer and exchange capabilities enabled based on end-user, network location/status, etc.

Alternative solution
There has been discussion around use of well-known URL.

Additional context
Some of the recorded (open and closed) Issues that will potentially benefit from such a solution:
https://github.com/camaraproject/ReleaseManagement/issues/11
camaraproject/IdentityAndConsentManagement#57
camaraproject/DeviceStatus#46
camaraproject/SimSwap#58
camaraproject/QualityOnDemand#173

[gmuratk]

Just to add a note, I realize this is a proposal for an API, and there will be a separate submission to API Backlog WG. However, I think it is a fairly general topic that will benefit the project/community at large so Commonalities group should review and comment.

[nickvenezia]

This would be in addition to ad tech Propsal submission. I believe QOD refers to it also.

[rartych]

The slide deck was uploaded CAMARA Wiki.
I propose to convert this issue to discussion.

[olivier-arnaud]

Hi, thanks to @tanjadegroot I discover this dicussion. I'm working on TMF Operate API, currently defining Product Catalog for API. I think we can address the issue, at least part of it.
This diagram is interesting because TMF has a model for this.

My understanding is this

• A. What is possible? What the network can do -> this is the Resource Facing Service (RFS) in TMF Production ODA block, that has 100 characteristics and 10 usages possible (example)
• B. What the network will (is configured to) do - Footprint and capabilities (FC) -> this is the Customer Facing Service (CFS) in TMF Production ODA block, that has 90 characteristics and 8 usages possible (example)
• C. What the network will expose (FC based on who is asking)* -> this is the Product Specification, but it's not Network that exposes this, it's Core Commerce block (in TMF ODA framework); the marketing teams define as many Product Specification based on CFS as many Product they want to sell. A Product Specification can have 50 characteristics and 5 usages possible (example)
• (added) C bis : How the Core Commerce wants to sell ? -> this is the Product Offering that put Prices, Terms and Conditions to each Product Specification
• (added) C ter : at this point there must be an order of a ProductOffering/ProductSpecification by a Customer, on the catalog made available for him. During the order, the Customer selects and configure the Product Specificationconfigurable characteristics, price can depend on the characteristics values.
• (added) C quar : the Operator delivers the Product to the Customer. It implies a delivery of the Service on the Network (TMF Production block) applying the characteristics and usages defined in Product Specification and valued by the Customer during the order.
• D. What the network may provide for the device right now (FC based on who is asking, device location and network state) -> this is based on the Product and Service instanciated during the order.

TMF has all documentation for this.
Currently within Operate API workgroup we are defining ProductSpecification and their usages and characteristics. Trying to have a common model and standardizing some characteristics.
Happy to share this to Camara team and have your feedbacks.