Device Object - Can implementation require a minimum of two device identifiers

[MsOlaAjibola]

The current device object has minimum properties of 1. Can an Operator's implementation require a minimum of two device identifiers?

It might be that the cellular network nodes (PCRF, HSS, BSS, etc.) need at least two fields (phone number+ NAI/IP) to correctly identify the UE.

Minimum of 2 still meets the requirement of min = 1 but wanted to understand if this meets the goal of the device object.

Thanks
Ola@GSMA

[eric-murray]

Hi @MsOlaAjibola

Is this related to multi-SIM scenarios?

The idea behind the Device object is that any one of the four parameters can uniquely identify the physical device, and hence the associated subscription. Where this breaks down is for multi-SIM scenarios where SIMs share a common MSISDN, but do not have a unique "secondary" MSISDN. This scenario is under review, and may result in changes to the Device object (e.g. accepting IMSI / SUPI as an identifier).

But even for multi-SIM scenarios, IP/port will still identify a unique physical device.

If it is not a multi-SIM scenario, it would be good to understand why a single identifier is insufficient. All of the systems you mention above will have a single "key" that identifies the subscription, and usually MSISDN can be used as that key.

[lwood989]

@eric-murray the use case that identified this was the roaming use case although Multi-SIM would apply too. Our stance is that in order for a successful query against a network node such as HSS, PCRF the message needs to contain at very least the MSISDN (Phone Number) or the Network Identifier. Just identifying the IP address alone will not allow a successful query against the network node.

[eric-murray]

... the roaming use case

The only implementation I was involved in that had to work for roaming devices was the roaming status API, and that implementation only required MSISDN. In general, getting network APIs to work for devices that are roaming will be challenging, but if there is some insight you can share as to why these scenarios might require two identifiers, that would be useful.

... the message needs to contain at very least the MSISDN (Phone Number) or the Network Identifier

Do you mean "and" rather than "or"? I understood that two identifiers were required for your use case.

Also, by "Network Identifier", do you mean the 3GPP External Id (as defined in 3GPP TS 23.682), or some other network identifier? External Id can be mapped to MSISDN by the implementation, and so would not require the MSISDN to also be explicitly provided.

[lwood989]

@eric-murray Thank you for you your response. for the MSISDN or Network Identifier I was referring to "or" because you are correct in the 3GPP standard the 3GPP external Id would have the MSISDN apart of it string.

[eric-murray]

@lwood989
OK thanks. The original issue raised by @MsOlaAjibola was that some use cases require two identifiers to be provided by the API consumer. I'm still trying to understand the details of these use cases.

At the moment, an API consumer can provide multiple identifiers, but they are not required to. If two identifiers are required for a given API or scenarios, the question is whether to mandate that through the OAS definition, or just document it.

[lwood989]

Eric, Understood. Only concern i have is the API invoke is delivered with only the IP addresses and not the MSISDN or Network Identifier. if that is not the case and either a MSISDN or Network Identifier will be delivered than we have no issues. Thank you. *Lee Woodruff* Director Network Architecture, Shush M: +1.601.573.7188 <http://x.com/ShushSherlock> | @ShushSherlock <https://x.com/ShushSherlock> | Shush <https://www.linkedin.com/company/shush-inc/> | shush.pw

…

On Wed, Oct 23, 2024 at 9:27 AM Eric Murray ***@***.***> wrote: @lwood989 <https://github.com/lwood989> OK thanks. The original issue raised by @MsOlaAjibola <https://github.com/MsOlaAjibola> was that some use cases require two identifiers to be provided by the API consumer. I'm still trying to understand the details of these use cases. At the moment, an API consumer can provide multiple identifiers, but they are not required to. If two identifiers are required to for a given API or scenarios, the question is whether to mandate that through the OAS definition, or just document it. — Reply to this email directly, view it on GitHub <#322 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/BJ4BVTBMPJO7H4WEAGE3PJ3Z46W5VAVCNFSM6AAAAABQME7ELOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDIMZSGQYDMMBQGE> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[eric-murray]

Only concern i have is the API invoke is delivered with only the IP addresses and not the MSISDN or Network Identifier

Indeed, this is a recognised problem. The implicit assumption is that all API providers support the full functionality of an API, but it is recognised that this will not always be the case.

The "workaround" is that you just return an error, effectively saying "identifier not supported, please provide MSISDN / NAI".

A more elegant proposal is a Capability and Runtime Restrictions API, where an API provider can advertise what they support and do not support. But this remains a proposal for now.

[gmuratk]

As @eric-murray mentioned Capability and Runtime Restrictions framework proposal can help with communicating [not] supported/accommodated device identifiers and/or higher minRequired value by the API Provider