/Connectivity API there is no indication for which particular subscriber event (DATA/SMS)

[Chintanlodariya]

As per /Connectivity API there is no indication for which particular subscriber event (DATA/SMS) this particular request is being initiated , as this parameter “reachabilityType” would be required (TS 29.122) when NEF further triggered to 5G network function via using Monitoring Event API

ReachabilityType:
  anyOf:
  - type: string
    enum:
      - SMS
      - DATA
  - type: string
    description: >
      This string provides forward-compatibility with future
      extensions to the enumeration but is not used to encode
      content defined in the present version of this API.
  description: |
    Represents a reachability type.  
    Possible values are
    - SMS: The SCS/AS requests to be notified when the UE becomes reachable for sending SMS
      to the UE
    - DATA: The SCS/AS requests to be notified when the UE becomes reachable for sending
      downlink data to the UE.

[akoshunyadi]

Actually the API call returns the available reachability, SMS or DATA or none. So it doesn't map 1:1 to the MonitorinEvent API, but provides the caller a possibility the check both kind of connectivity in 1 call.
As a solution you might omit reachabilityType in the 3GPP request to get both status.

[sachinvodafone]

As per my understanding, in the current API specification:

1. The server doesn't explicitly support sending both CONNECTED_SMS and CONNECTED_DATA in the same API response.
2. The client does not have explicit control over the response, and it relies on the server to determine and provide the one of connectivity status (CONNECTED_SMS, CONNECTED_DATA, or NOT_CONNECTED).

I believe, we can introduce 'ReachabilityType" in the request to indicate its preference

[sachinvodafone]

In the connectivity response, the client may receive one of the following connectivity status (based on the specification):

Connectivity status:

CONNECTED_SMS: Indicates the device is connected to the network via SMS usage.
CONNECTED_DATA: Indicates the device is connected to the network via data usage.
NOT_CONNECTED: Indicates the device is not connected to the network.

Do we have provision available for the client to select their preferred status between CONNECTED_SMS and CONNECTED_DATA (or both in the same response)?

[Chintanlodariya]

@akoshunyadi @sachinvodafone

I believe, we must introduce 'ReachabilityType" in the request to indicate its preference.

Flow: Device Status API >> NEF (Monitoring event) >> UDM (Event Exposer)

AS per 3GPP 29.503 (6.4.6.3.3), Nef can use only one event to query form UDM either for Data or SMS.

[akoshunyadi]

I don't think that the Camara API has to match 1:1 the underlying NEF API. In Camara we want to provide user-friendlier APIs so that the developer can ask the connectivity status of device in one call.

But I think our current responses doesn't allow all combinations. Currently it's not clear if DATA means DATA+SMS or DATA only.

[shilpa-padgaonkar]

If we extend the context attributes (https://github.com/cloudevents/spec/blob/main/cloudevents/primer.md#cloudevent-extension-attributes) with one more attribute "reachability_type", a filter could be used in subscription by the consumer, to specify/indicate the preference of only certain reachability type events.

[maxl2287]

I don't think that the Camara API has to match 1:1 the underlying NEF API. In Camara we want to provide user-friendlier APIs so that the developer can ask the connectivity status of device in one call.

But I think our current responses doesn't allow all combinations. Currently it's not clear if DATA means DATA+SMS or DATA only.

NEF (Monitoring Event) API understands this that either DATA or SMS is used:

 - UE_REACHABILITY: The SCS/AS requests to be notified when the UE becomes reachable for sending either SMS or downlink data to the UE

[murthygorty]

my recommendation: I agree with @akoshunyadi --> we shouldnt be tied to what NEF can do and provide; in CAMARA we should be looking from a regular non-telecom developer perspective and provide what they are looking for. AFAIK, this API caller wants to know if the device is connected for DATA or SMS or both (or potential other types in the future).

Also agree that we need to fix the response to account for multi-channel availability (already existing issue)
cc: @gmuratk

[Chintanlodariya]

AFAIK, this API caller wants to know if the device is connected for DATA or SMS or both (or potential other types in the future).

Currently, in connectivity response, we have CONNECTED_SMS, CONNECTED_DATA, or NOT_CONNECTED. There is no option for both (SMS+DATA), or can we consider CONNECTED_DATA means (SMS+DATA)?

[maxl2287]

@bigludo7 & @jlurien:
As I have also developed a provider implementation for DeviceStatus I faced the same issue when using the 3gpp southbound of MonitoringEvent - API.
There you need to provide a specific reachability-type as it is based on subscriptions.

However, is there a possibility that we can offer the requester to provide an optional reachabilityType in the request?
E.g.

{
  ...
   "reachabilityType": "SMS"
}

If we do not get any information about that we could respond with HTTP-422? (see latest comment here #148)

Wdyt?
It's really blocking us, when using this 3gpp-API, as we do not have a good alternate solution.

[eric-murray]

Hi all

I know this issue is somewhat old now, but it is still open, so I will add my comments here.

My first comments is that we should always look to the use case, rather than designing the API to simplify a possible implementation. For this API, probably the use case was not rigorously defined, but I always assumed it provided the API consumer with the following information:

• Is the device connected to the operator's network?
• If so, does the device have an active data connection (i.e. is it connected to the packet switched core)?
• If there is no data connectivity, can the device receive SMS (i.e. is it connected to the circuit switched core)?

So, if we consider implementation using the NEF, then the sequence of calls to the NEF would be:

• Check if device has "REACHABILITY_FOR_DATA"
  • if so, return CONNECTED_DATA
  • otherwise check if device has "REACHABILITY_FOR_SMS"
    • if so, return CONNECTED_SMS
    • otherwise return NOT_CONNECTED

So the possible reachability states can be considered "hierarchical", and there is no need for a reachabilityType parameter to support this use case.

I would also add that the number of devices that can have data connectivity but cannot receive SMS must be tiny if the device SIM has a MSISDN. Even IoT devices can generally receive SMS - they just might have no mechanism to display the message, which is hardly a concern for the API. But other network operators may have implementations where data only devices cannot receive SMS.

However, I'm aware of discussions to extend the use case, in particular, to extend the API to explicitly return the connectivity state for both DATA and SMS connectivity (for those rare cases where a device has data connectivity but cannot receive SMS).

So I do believe the use case itself requires a review. In particular:

• Should the response give separate statuses for each connectivity type, or is the current "hierarchical" approach sufficient?
• Should additional connectivity types be considered?
• Should the API consumer be able to request a "filter" on the connectivity type to be considered (i.e. this issue)