Create initial version

[akoshunyadi]

Problem description Create initial version based on https://github.com/camaraproject/APIBacklog/blob/main/documentation/API%20proposals/APIProposal_Device_Connection_Quality_Indicator.md

Input:

• Device Availability: CONNECTED / NOT_CONNECTED
• Network Insights: https://github.com/camaraproject/ConnectivityInsights
• Network type: 2g/3g/4g/5g
• Remaining data volume of the contract: <200MB/<1GB/...
• Speed limitations of the contract: ?

Possible evolution Provide OAS file(s)

Alternative solution

Additional context

[akoshunyadi]

I think it would make a sense to first discuss and agree here on the general functionality e.g. endpoints and data in & out

[akoshunyadi]

As I understand, something like this is required:

base path: device-quality-indicator

POST /retrieve Request:

• device

Response:

• enum of predefined categories

POST /subscriptions Request:

• device
• enum of predefined categories, when changing to the specific category or on all changes

Questions:

• Can we map all the inputs into a single value, e.g. 1-10?
• Do we need 3-legged auth?

[sachinvodafone]

Just checking , whether it's better to have one consolidated endpoint (/retrieve) that provides all information like "network-status" and "congestion-history" etc in a single response, or whether it's more efficient to separate these concerns into multiple endpoints (e.g., one for real-time status and another for historical congestion data).

[VijayKesharwani]

@akoshunyadi Could you also confirm whether the following two things should be included in this API or not, as they will be available in the DeviceDataVolume API as well I guess? 1) Remaining data volume of the contract: <200MB/<1GB/... 2) Speed limitations of the contract: ?

[VijayKesharwani]

@akoshunyadi I also wanted to ask if I should create two separate MRs: one for the /retrieve endpoint and another for the /subscriptions endpoint. This would make it easier to review them individually. Please let me know your thoughts.

[akoshunyadi]

@akoshunyadi Could you also confirm whether the following two things should be included in this API or not, as they will be available in the DeviceDataVolume API as well I guess?

1. Remaining data volume of the contract: <200MB/<1GB/...

2. Speed limitations of the contract: ?

Yes, that's our requirement. DeviceDataVolume is clear, that's the other new API we should work on. About Speed limitations of the contract I don't have informations yet.

[akoshunyadi]

@akoshunyadi I also wanted to ask if I should create two separate MRs: one for the /retrieve endpoint and another for the /subscriptions endpoint. This would make it easier to review them individually. Please let me know your thoughts.

I would prefer 1 PR, that's easier to keep in sync, because similar changes may be necessary in both, after the reviews. But first we should agree here, how the API should work. How to combine these inputs? I mean creating an OAS which just returns a number, it's easy, but that doesn't solve the problem.

[akoshunyadi]

To summarize the current ideas:

1. API provides one magic number to describe the device connectivity => difficult to do the calculation, and to make it transparent for the customer
2. API provides each value of the input APIs separately => no extra value added, the evaluation has to be done on customer side
3. API provides "device connectivity potential" with indication of "where are we now" and what would be possible, e.g. a range