5GMSd - QoE Metrics Reporting - Clarification on sampling rate for buffer level

[dsilhavy]

Problem description

TS 26.512 Section 11.4.3 defines the metrics reporting format to be used for 5G Media Streaming referencing the scheme urn:3GPP:ns:PSS:DASH:QM10 and TS26.247 clause 10.6.1 and 10.6.2.

One of the metrics defined in TS26.247 and ISO/IEC 23009-1 is BufferLevel. Two questions/comments arose when looking into the reporting of the BufferLevel as part of the reference implementation in the 5G-MAG Reference Tools.

1. At which sampling rate should the buffer level be requested? Is it sufficient to query it once for each metrics reporting iteration ( based on ServiceAccessInformation.clientMetricsReportingConfigurations.reportingInterval ). Or should it be derived periodically according to another configuration parameter? The report send on each iteration of the reporting interval would then contain multiple <BufferLevelEntry> elements.
2. As a sidenote: Most media players allow querying the buffer level specifically for each media type. As the content is usually not muxed the audio and video buffer might differ. For instance, an MSE based client has a separate SourceBuffer for audio and video. Consequently, it is possible to derive the buffer level individually for both audio and video. This is currently not covered by the BufferLevel and the BufferLevelEntry elements as they contain no media type. Instead the level is defined as : Indicates the playout duration for which media data of all active media components is available starting from the current playout time.

Suggested solution

1. Add a new field bufferLevelSamplingPeriod to the ServiceAccessInformation.
2. This is just as an fyi, but it might be useful to report buffer levels individually for each media type.

Additional context

A related discussion can be found here: 5G-MAG/rt-5gms-media-stream-handler#33

[rjb1000]

The request for sampling rate signalled in the M5 Service Access Information sounds reasonable to me. If agreeable to SA4, note that it would require a corresponding change to be made in the M1 Metrics Provisioning API.

Some additional thoughts:

• Data sampling rate sounds like something that applies to many different QoE metrics, not just buffer level. So a more general solution would be preferable.
• Such a general solution was recently added to TS 26.532 V17.2.0. See the definition of DataSamplingRule.samplingPeriod in clause 5.4.2.1.
• Based on this, there is a line of argumentation that a property (e.g. samplingPeriod) should be added to the M1 MetricsReportingConfiguration resource and to the M5 ServiceAccessInformation.clientMetricsReportingConfiguration object in TS 26.512 Rel-17 for self-consistency of that release.

[rjb1000]

Question about whether this essential change to TS 26.512 Rel-17 for alignment with TS 26.532 Rel-17 can also be justified in TS 26.512 Rel-16?

[rjb1000]

I will add this to my CR0037.

[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