Add Application Function Id (afId) or Sponsor Id

[SyeddR]

Problem description
Service Provider would like to track QoD session data usage for third party usage reporting or monetization purposes.

Possible evolution
Add Sponsor Id or Application Function ID (afID) in QoD API. These IDs are defined in 3GPP specs TS 29.122 (SCEF) and TS 29.522 (NEF). This will enable QoD session usage tracking based on application function ID in the network.

[hdamker]

@SyeddR

My first impression is that the use of these identifiers towards SCEF/NEF are an (internal) topic of the API provider implementation and would be (communication) service provider specific (not all of them will use SCEF or NEF, especially not if the underlying network isn't a mobile network).

Shouldn't the service provider be able to generate appropriate identifiers for SCEF/NEF out of the identify information about the API consumer which comes with the API call? Why should the API consumer know these identifiers and provide them as parameters?

But maybe I missed some point here.

Side note: AsSessionWithQoS (the south-bound API of SCEF/NEF for QoD API) uses ScsAsId, not afId.

[SyeddR]

The Id could be a customer account number/ application identifier combination not necessarily tied to mobile network. As with all the other required parameters we take from consumer, this should be part of QoD spec, in my opinion as this is required by downstream systems (SCEF/NEF in mobile network) to enable usage tracking per app.

I am not sure if we want to keep it operator specific implementation. The whole point of CAMARA APIs is to create a standard interface, isnt it?

[SyeddR]

Btw SCsASId is different than sponsor Id. Please review TS 29.122 spec

[eric-murray]

Hi @SyeddR

If I understand your proposal, you want to add this identifier to the northbound API so that the API consumer can specify it directly. What is not clear to me is how this differs from information that the CSP would already know from the identification / authentication process, and how the API consumer would later use the identifier that they specified when they created a QoS session.

Maybe you could expand on your proposal with an example.

[SyeddR]

@eric-murray

About the identification/authentication process, the new identifier will not interfere with it but will only provide additional, more specific information that can enhance usage tracking. In the case of the API consumer, these identifiers could be used when they need to retrieve specific information about their usage or for application-specific tasks.

For example, consider a scenario where the API consumer is a company with multiple applications using the QoD API. They could use the afID as a parameter when creating a QoS session for a specific application, enabling them to track the usage for that specific application, which can be beneficial for optimizing resource allocation, understanding usage patterns, and more.

[hdamker]

Btw SCsASId is different than sponsor Id. Please review TS 29.122 spec

Sure ... but you wrote "Add Sponsor Id or Application Function ID (afID)" in QoD ... and AsSessionWithQoS (the south-bound API of SCEF/NEF for QoD API) uses ScsAsId, not afId. afID has btw a very strange format, which requires to read at least one more spec. And Sponsor ID is to indicate the chargeable party, right?

As Eric wrote ... it would be good to have a use case description to understand your proposal better. Seems that at least one more API would be involved (to get analytics data).

[jlurien]

If a requirement for usage tracking, or similar, is eventually needed in CAMARA, we should think in a transversal solution which is valid for any API. We should not just expose certain internal parameters than happen to exist in the network APIs that are involved in the implementation of QoD, but the other way around, starting with a clear requirement.

[RandyLevensalor]

If we do this, can we also do this in a manner that isn't specific to 3GPP NEF specifications, so that it can be applied to wireline and Wi-Fi networks as well?

[SyeddR]

@jlurien I disagree. QoD is the only API that triggers network configuration, while rest of the other APIs are data exposure services. We would need a mechanism to track session data volume tracking per application.

@RandyLevensalor I totally agree, we should make it generic to cover non 3GPP use cases.

[tlohmar]

@hdamker

AsSessionWithQoS (the south-bound API of SCEF/NEF for QoD API) uses ScsAsId, not afId.

Note, 3GPP has changed terminology between 4G and 5G. Specifically. the "AS Session with required QOS" (TS 23.638, Clause 5.11) is named in 5G "AF Session with required QoS" (TS 23.502, Clause 4.15.6.6a). TS 29.522 (NEF API specification), Clause 4.4.9 says "description of the SCS/AS applies to the AF".

My interpretation is, that the 4G 'ScsAsId' is the 5G 'AfId'.

[jlurien]

@jlurien I disagree. QoD is the only API that triggers network configuration, while rest of the other APIs are data exposure services. We would need a mechanism to track session data volume tracking per application.

My point is that the requirement to track usage per 3rd party App is not exclusive of this API, and the identifier that is used to identify 3rd parties apps does not need to be anything specific to the internal network APIs. Implementations may map whatever identifier is used to identify 3rd party apps to whatever parameter exists in NEF/SCEF APIs for that purposes. CAMARA APIs in general try to hide clients from telco concepts.

[eric-murray]

Link to Syedd's presentation

[jlurien]

Last week the guidelines in Identity an Consent Management WG were updated with more details about the authentication phase and there it is mentioned that it is expected to have a client_id per application with its own credentials.

If there are concerns about this topic not entirely or correctly covered by the current guidelines, I suggest to open an issue in that WG, so topic can be properly discussed and considered in the guidelines, which apply to all CAMARA APIs.

[SyeddR]

opened the issue under identity and consent management project camaraproject/IdentityAndConsentManagement#126

[hdamker]

Added Backlog label, as Commonalities will address camaraproject/Commonalities#179 not for the Fall24 release.