TS26.512 - Consumption reporting: How is aspId for POST url generated?

[shilinding]

Problem description

In TS26.512-h40 clause 11.3.2, about the url for POST, it says:

Consumption reports shall be submitted to one of the URLs selected from the ClientConsumptionReportingConfiguration.serverAddresses array of the ServiceAccessInformation resource (see clause 11.2.3). The path of the URL should conform to the following general format:

{apiRoot}/3gpp-m5/{apiVersion}/consumption-reporting/{aspId}

where {aspId} shall be substituted by the 5GMS Client with the relevant Application Service Provider identifier.

But how the aspId be generated isn't defined in the spec. It would be great if we can clarify it. I might have missed something here.

[rjb1000]

This is one of the least satisfactory parts of TS 26.512 in my opinion.

I think the assumption here is that the Media Session Handler already knows the value of {aspId} from the 5GMSd-Aware Application. But there is nothing specified in the M6 client API to provide this information to the Media Session Handler, so there is a bit of a gap.

Something could be added to the M6 client API to supply the Application Service Provider identifier. But this doesn't feel quite right.

An alternative would be to add aspId to the Service Access Information, but I believe this is the wrong architectural approach because it represents an abstraction leakage.

In Rel-16 and Rel-17, the Media Session Handler deals in the currency of Provisioning Session identifiers, and I think this would be a better basis for reporting consumption, aligning clause 11.3.2 with the metrics reporting procedure specified in clause 11.4.2.

My proposal is therefore to change the URL format for consumption reporting to:

{apiRoot}/3gpp-m5/{apiVersion}/consumption-reporting/{provisioningSessionId}

[rjb1000]

(Side note: in Rel-18, we are likely to replace the use of the Provisioning Session identifier at M5 with an external service identifier that is used to launch media session handling at M6 by embedding it in a 3GPP Service URL that is "handled" by the Media Session Handler. The external service identifier extracted from the 3GPP Service URL will then be used by the Media Session Handler to retrieve Service Access Information from the 5GMS AF instead of the Provisioning Session identifier. It would make sense to use the same external service identifier when sending consumption reports and QoE metrics reports as well in order to achieve a consistent abstraction at reference point M5. The 5GMS Client doesn't really need to know the Provisioning Session identifier when it has the external service reference as a proxy for it.)

[dsilhavy]

From the 5G-MAG call discussion, which of these options is the one we want to choose for now:

1. Add the aspId to the M8 information or include it in a settings file that is read by the 5GMS Aware Application
2. Use the provisioningSessionId instead of the aspId as @rjb1000 suggested

[rjb1000]

For the time being, @dsilhavy, I suggest providing the aspId in the M8.json catalogue document. In our reference implementation, it is potentially different for each entry in the content catalogue. (This would probably not be the case for a real world app where all content in the catalogue is typically associated with a single Application Service Provider, but let's ignore that here.)

Meanwhile, I think SA4 should amend the Rel-16 and Rel-17 specifications to use the Provisioning Session identifier in the consumption reporting API instead of the Application Service Provider identifier. (This change would target SA Plenary in September.)

And, for Rel-18, I will propose using an external service identifier instead.

[rjb1000]

Proposed change in clauses 11.3.2 and C.4.2 endorsed at post-SA4#124 ad hoc meeting:

• TS 26.512 CR0037 Rel-17 "[5GMS3, TEI17] Essential maintenance" in S4aI230105.

[rjb1000]

CR contributed to SA4#125 by @rjb1000:

• TS 26.512
  • Rel-16: CR0043 "Essential maintenance" in S4-231158.
  • Rel-17: CR0037r1 "Essential maintenance" in S4-231156.

[rjb1000]

CRs agreed at SA4#125:

• TS 26.512
  • Rel-16: CR0043r1 "Essential maintenance" in S4-231425.
  • Rel-17: CR0037r2 "Essential maintenance" in S4-231424.

[rjb1000]

CRs revised (YAML corrections) and approved at SA#101:

• TS 26.512
  • Rel-16: CR0043r2 "Essential maintenance" in SP-231082.
  • Rel-17: CR0037r3 "Essential maintenance" in SP-231053.

[rjb1000]

Approved changes published and available for download:

• TS 26.512 V16.11.0
• TS 26.512 V17.6.0