TS26.512 - Clarification on the client behavior for the list of metrics which shall be reported

[dsilhavy]

Problem description

TS26.512 Table 11.2.3.1-1 defines the ServiceAccessInformation resource. The clientMetricsReportingConfigurations.metrics property defines the list of metrics which shall be reported, has a type set to Array(String) and a cardinality? of 1..1.

I would like to understand if this means that the metrics to be reported by the Media Session Handler are always stated explicitly in the metrics array? Or is it allowed to leave the metrics array empty which means that the Media Session Handler shall report all metrics that belong to the corresponding scheme? In my opinion, the latter makes a lot of sense as the content provider probably does not want to explicitly enable all metrics for a specific scheme. Leaving the array empty can then be interpreted as "report all the metrics the media player supports that belong the target scheme".

[rjb1000]

Yes, this looks ambiguous in TS 26.512.

I tend to agree with @dsilhavy's preference that an empty metrics array could be defined to mean that all metrics are to be collected by the Media Player and reported by the Media Session Handler.

To me this seems more useful than using an empty array to signal that metrics reporting is temporarily disabled, which would be the next most obvious semantic we could define instead.

If agreeable, I think the first semantic above could usefully be clarified in the Description column of table 11.2.3.1-1.

Any views to the contrary?

[gheikkila]

If I remember correct, the asssumed way to disable "old-style" metrics reporting in 26.247 and 26.114 (i.e. not AF-based), is to send a new valid metrics configuration, but with an empty list of metrics. I don't think there is any statement saying this, but there is no explicit "on/off" parameter. I guess another way would be to set "reporting percentage" to 0 (zero), which in practice also would stop reporting. So we should maybe check a bit so that we have a consistent understanding on how this is done over our different metric-related specs. Or at least not add something which messes up things.

Another issue is that some metrics require additional configuration information. For instance, the metric to measure buffer level needs to know the measurement interval. There are similar "extra parameters" also for 26.118 and VR metrics, and I'm not sure there are default values for all of these.

[rjb1000]

Apologies, @dsilhavy: I accidentally omitted this issue from the agenda of yesterday's joint meeting with 3GPP SA4 MBS delegates.

Looking at the M1 Metrics Reporting Provisioning API specified in clause 7.8, I notice that the MetricsReportingConfiguration.metrics array is an optional property which must, if present, contain at least one metric identifier. The specification adds:

If not specified, the complete (or default if applicable) set of metrics associated with the specified scheme shall be collected and reported.

So I think this is the intended behaviour when provisioning metrics reporting at reference point M1.

Turning back to the Service Access Information derived from this at reference point M5 (clause 11.2.3.1), the equivalent array is always present, but is allowed to be empty. Following the logic through, I conclude that this corresponds to the case where the array is omitted at M1, with the semantic that the default set of metrics or (if that is not specified) all metrics are to be reported.

I will therefore add a clarification to this effect in table 11.2.3.1:

A list of metrics which shall be reported.

If empty, the complete (or default if applicable) set of metrics associated with the specified scheme shall be collected and reported.

[rjb1000]

As @gheikkila points out, reporting can be temporarily suspended by setting MetricsReportingConfiguration.samplePercentage to zero at reference point M1, so I think that's good enough as a crude on/off control.

[rjb1000]

@dsilhavy: Regardless of the mechanism used to control metrics reporting, any change to the metrics reporting configuration only takes effect during the course of a media streaming session if the Media Session Handler re-requests the corresponding Service Access Information when it becomes stale.

The Media Session Handler must honour the Cache-Control: max-age time-to-live response header provided by the 5GMS AF to determine when the last requested Service Access Information resource representation has expired and needs to be re-requested.

The Media Session Handler can easily determine if the Service Access Information has changed when its copy goes stale, for example by storing the ETag header value from the most recently retrieved version and making a conditional HTTP GET request subsequently. This is achieved by quoting the last known entity tag value in an If-None-Match request header (see TS 26.512 clause 6.2.3.4).

The response is 304 Not Modified (with an empty response body) if the previously supplied resource representation is still fresh or 200 OK (including the updated resource representation in the response body) if it has changed. Only in the second case does the Media Session Handler need to reconfigure itself mid-session.

In both responses, a new time-to-live is supplied in the Cache-Control: max-age response header. This is intended to be used to prevent the Media Session Handler from attempting to revalidate the Service Access Information too frequently, since every HTTP transaction, even the efficient conditional GET described above, has a cost.

(For reference, this behaviour is specified in TS 26.512 clause 4.7.2.3.)

[rjb1000]

M1 Priovisioning (existing specification):

If not specified, the complete (or default if applicable) set of metrics associated with the specified scheme shall be collected and reported.

M5 Service Access Information (proposed clarification):

If empty, the complete (or default if applicable) set of metrics associated with the specified scheme shall be collected and reported.

Of course, @dsilhavy, this begs the obvious question: what is the default set of QoE metrics for the default metrics reporting scheme in 5G Media Streaming (i.e., the one with scheme URI urn:3GPP:ns:PSS: DASH:QM10 specified in TS 26.247)?

Clause 10.4 of TS 26.247 lists all the relevant DASH metrics, but doesn't specify a default set. The Metrics@metrics attribute (used to configure this feature in the DASH MPD in the case of PSS rather than 5GMS) is mandatory, but the schema in table 33 permits an empty string and the semantics in table 32 don't specify a default behaviour when the attribute contains an empty list. So no clues there, then.

In the absence of any better information, I conclude for now that if the M1 MetricsReportingConfiguration.metrics array is omitted and the M5 clientMetricsReportingConfigurations[].metrics array is therefore empty, this means that all DASH metrics need to be reported by the Media Session Handler.

Do you agree?

[dsilhavy]

Thanks for the detailed explanation @rjb1000

The Media Session Handler must honour the Cache-Control: max-age time-to-live response header provided by the 5GMS AF to determine when the last requested Service Access Information resource representation has expired and needs to be re-requested

I will create a dedicated issue for this as it is currently not supported: 5G-MAG/rt-5gms-media-session-handler#30.

In the absence of any better information, I conclude for now that if the M1 MetricsReportingConfiguration.metrics array is omitted and the M5 clientMetricsReportingConfigurations[].metrics array is therefore empty, this means that all DASH metrics need to be reported by the Media Session Handler.

This sounds reasonable and corresponds to how metrics reporting has been implemented.

[rjb1000]

CRs contributed to SA4#125 by @rjb1000 attempt minor clarification at clause 7.8.3.1:

• 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