QoE Metrics Reporting - Name Space Identifier required for DASH QoE metrics reporting parameters?

[dsilhavy]

Description

TS 26.512 Table 7.8.3-1 defines the metrics property as a non-empty list of metrics which shall be collected and reported. In the case of downlink media streaming and for the 3GPP scheme urn:3GPP:ns:PSS:DASH: QM10 the listed metrics shall correspond to the metrics specified in TS 26.247.

Our current client-side implementation uses the following constants to identify which metrics shall be reported by the Media Session Handler to the 5GMS Application Function. Note our implementation does not support all metrics defined in TS 26.247 yet.

object Metrics {
    const val BUFFER_LEVEL = "BufferLevel"
    const val HTTP_LIST = "HTTPList"
    const val REP_SWITCH_LIST = "RepSwitchList"
    const val MPD_INFORMATION = "MPDInformation"
}

A corresponding entry in the Service Access Information fetched via M5 looks the following:

{
  "metricsReportingConfigurationId": "7bdfb0b0-fe4a-41ee-8d9e-cb36a16378a2",
  "serverAddresses": [
    "http://192.168.2.7:7778/3gpp-m5/v2/"
  ],
  "scheme": "urn:3GPP:ns:PSS:DASH:QM10",
  "dataNetworkName": "",
  "reportingInterval": 10,
  "samplePercentage": 100,
  "urlFilters": [],
  "samplingPeriod": 5,
  "metrics": [
    "HTTPList",
    "BufferLevel",
    "RepSwitchList",
    "MPDInformation"
  ]
}

26.512 Annex E.2.1 defines the reporting parameters for 3GPP-DASH metrics. In the provided examples the identifiers are prefixed with the name space identifier defined as : urn:3GPP:ns:PSS:DASH:QM10.

Consequently, to report all metrics of the AvgThroughput type the identifier looks like the following urn:3GPP:ns:PSS:DASH:QM10#AvgThroughput

Discussion / Questions

• Annex E.2.1 does not seem to be referenced anywhere. Should there be a reference to Annex E.2.1 in Table 7.8.3-1
• What is the reason to add the name space identifier to each metric? Isn't it sufficient to provide the identifier via the scheme property (see example above)?

[rjb1000]

I have looked into this a bit and these are some initial findings:

• When doing QoE metrics reporting for a VR session carried over 5G Media Streaming, TS 26.512 table 7.8.3-1 specifies that the metrics should be as specified in TS 26.118 clause 9.3, and should be reported according to TS 26.118 clause 9.4.
• TS 26.118 clause 9.3 specifies some new metrics for VR. For example, table 9.3.3-1 defines the Rendered viewports metric with fields start time, duration and viewport.
• TS 26.118 clause 9.4 specifies that VR metrics are to be reported using the same basic QM10 schema as DASH metrics, but goes on to specify additional XML Schema types to convey the VR metrics.
  • I interpret this to mean that the provisioned metrics scheme identifier is also therefore urn:3GPP:ns:PSS:DASH:QM10, which tells the 5GMS AF what XML document format and MIME type to expect.
• TS 26.532 clause E.2.2 specifies that VR metrics specified in clause 9.4 are to be identified in 5GMS QoE metrics reporting using the namespace urn:3gpp:metadata:2020:VR:metrics.
  • For example, the duration field of the Rendered viewports metric would have the fully-qualified term identifier urn:3gpp:metadata:2020:VR:metrics#RenderedViewports/duration.

So, to make a concrete example of a metrics reporting configuration for VR over 5GMS:

{
  "metricsReportingConfigurationId": "7bdfb0b0-fe4a-41ee-8d9e-cb36a16378a2",
  "serverAddresses": [
    "http://192.168.2.7:7778/3gpp-m5/v2/"
  ],
  "scheme": "urn:3GPP:ns:PSS:DASH:QM10",
  "dataNetworkName": "",
  "reportingInterval": 10,
  "samplePercentage": 100,
  "urlFilters": [],
  "samplingPeriod": 5,
  "metrics": [
    "urn:3gpp:metadata:2020:VR:metrics#RenderedViewports"
  ]
}

This explains why the scheme and metrics array members are both fully-qualified term identifiers, even though the namespace is the same for the special case of DASH over 5GMS.

[rjb1000]

Annex E.2.1 does not seem to be referenced anywhere. Should there be a reference to Annex E.2.1 in Table 7.8.3-1.

I agree this needs to be properly cross-referenced.

[rjb1000]

Change Request contributed to MBS ad hoc meeting post SA4#127-bis-e:

• TS 26.512
  • Rel-16: Won't correct because 5G-MAG's Reference Tools implementation uses Rel-17 as a starting point.
  • Rel-17: CR0069 "[5GMS3, TEI17] Metrics reporting corrections" in S4aI240047.
  • Rel-18: Changes to be handled directly in TS 26.510 V1.2.1.

[rjb1000]

Change Request treated at MBS ad hoc meeting post SA4#127-bis-e:

• TS 26.512
  • Rel-17: CR0069 "[5GMS3, TEI17] Metrics reporting corrections" in S4aI240047.
    • Endorsed and will be resubmitted to SA4#128 for agreement.
  • Rel-18: Changes to be handled directly in TS 26.510 V1.2.1.
    • Editor to check TS 26.510 prior to contribution.

[rjb1000]

New specification versions published following approval of CRs at SA#104:

• TS 26.512
  • Rel-17: V17.9.1.
  • Rel-18: Not applicable: affected clause ported to TS 26.510.