Extend: Device Status Connectivity with Standard

[NoelWirzius]

If there is a valid Data connection established the API should also inform about the Standard with which the device is connected. (2G, 3g, 4g , 5gnsa, 5gsa)

This is helping developers to get a better insight about the connection status.

[sachinvodafone]

I'm concerned about combining connectivity status and network standard information into a single API. I believe keeping them separate would make the API easier to understand and use. Users could then choose which information they need without unnecessary complexity.

Consider a scenario where the network element responsible for providing network standard information differs from the one handling connectivity status. Attempting to merge these distinct pieces of information into a single response would pose significant challenges and complexities. It's comparable to amalgamating data from two disparate databases with different schemas, a task feasible but laden with unnecessary complexity and the risk of potential points of failure

[QaunainM]

I haven;t factored in the point that @sachinvodafone mentioned above, but this would be very useful as it means the DeviceStatus API provides a bit more information that helps developer know when they should invoke other APIs.

For example, if the user only has 2G then we know now to invoke QoD for them.

For developers it can means less APIs to call and reduced costs, but this is without factoring in points that @sachinvodafone mentioned

[murthygorty]

Hi @akoshunyadi , is it possible to add this to 0.6.0 list, instead of 0.7.0 -> when are each of these targeted for (roughly?)

[murthygorty]

Good discussion here on separate vs same endpoints. FWIW, I too agree with @sachinvodafone that this should be a separate endpoint AND a separate API altogether. Speaking along the lines of separatinig the yamls in the other issue that @NoelWirzius raised.
cc: @gmuratk @NoelWirzius

[akoshunyadi]

Hi @akoshunyadi , is it possible to add this to 0.6.0 list, instead of 0.7.0 -> when are each of these targeted for (roughly?)

@murthygorty if we have an approved PR in time, then why not. The API version 0.6.0 (actually the splitted APIs with possible other versions) should be part of the upcoming fall metarelease, so we should have the first RC at middle/end of June.

[murthygorty]

Hi @akoshunyadi , is it possible to add this to 0.6.0 list, instead of 0.7.0 -> when are each of these targeted for (roughly?)

@murthygorty if we have an approved PR in time, then why not. The API version 0.6.0 (actually the splitted APIs with possible other versions) should be part of the upcoming fall metarelease, so we should have the first RC at middle/end of June.

Super, this is great info for me @akoshunyadi -> also good to know that we are targeting 0.6.0 for the fall release. Got the input.
@gmuratk @NoelWirzius

[NoelWirzius]

@sachinvodafone im supporting this idea and see also that this could be in two single APIs/Endpoints.

Connection Standard
Connection Standard subscription
I guess also the subscription model makes sense here, so developers are getting a notification, when sth. is changing and then can adjust their applications

[murthygorty]

Can we please use the term 'network type' as opposed to 'connection standard'?

1. IMO, it is non-telecom Developer friendly.
2. As I understand from my telecom colleagues, we could get into debates about what a true 'connection standard' is, since for practical reasons, different MNOs may have used diifferent terminologies for the same 3GPP standard.
   @gmuratk , @NoelWirzius

[akoshunyadi]

Do we have an idea how the API could be implemented?

[gmuratk]

I added a 'draft' PR for this feature request. Currently it's lacking the subscriptions.

[hdamker]

@NoelWirzius @camaraproject/device-status_maintainers:

There is currently an overlap with an PR within ConnectivityInsights (see issue camaraproject/ConnectivityInsights#48 which I have created there). One cause of this overlap is that neither DeviceStatus nor ConnectivityInsights has raised within APIBacklog their intent to define such API and that they want to include it into the scope of their Sub Project.

My proposal would be to create an issue within APIBacklog for the scope enhancement and use that as a trigger for the discussion in which Sub Project the API will be allocated.

[Kevsy]

There is currently an overlap with an PR within ConnectivityInsights (see issue camaraproject/ConnectivityInsights#48 which I have created there). One cause of this overlap is that neither DeviceStatus nor ConnectivityInsights has raised within APIBacklog their intent to define such API and that they want to include it into the scope of their Sub Project.

My proposal would be to create an issue within APIBacklog for the scope enhancement and use that as a trigger for the discussion in which Sub Project the API will be allocated.

As per agreed action API Backlog meeting 11th July, I have created a Scope Enhancement issue . This is intended as input to the connected-network-type API discussion.

[akoshunyadi]

@gmuratk now we should continue working on this. As discussed in our last community call, we are still not confident about the possible implementation on the 3GPP side. Could you please provide some information about it?

[Kevsy]

This appears to now fall under PR 158 in Device Status, so recommend to close this issue.

Edit: apologies, I mean a successful merge of 158 will close this issue :)

[gmuratk]

@gmuratk now we should continue working on this. As discussed in our last community call, we are still not confident about the possible implementation on the 3GPP side. Could you please provide some information about it?

@akoshunyadi I think it's fair to expect network operators to determine the network their subscriber/device is connected to and there could be different implementations. One option may use 3GPP Monitoring Event API, which offers connection information.