-
Notifications
You must be signed in to change notification settings - Fork 4
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
QoE Metrics Reporting : Support for name space identifier in metrics property #73
Comments
@rjb1000 @davidjwbbc @jordijoangimenez : Do you have an opinion on this one?
|
Could you expand on what you mean by "robustness reasons", @dsilhavy , so we can better assess the pros and cons? |
For me, it was not obvious that the metric strings like So I am wondering if we should accept prefixed and non-prefixed versions of the metrics as an input, e.g. "metrics": [
"HTTPList",
"BufferLevel",
"RepSwitchList",
"MPDInformation"
] "metrics": [
"urn:3GPP:ns:PSS:DASH:QM10#HTTPList",
"urn:3GPP:ns:PSS:DASH:QM10#BufferLevel",
"urn:3GPP:ns:PSS:DASH:QM10#RepSwitchList",
"urn:3GPP:ns:PSS:DASH:QM10#MPDInformation"
] That way we would still report the specified QoE metrics even if the configuration done via M1 did not include the Our current implementation registers an instance of a |
My interpretation of the specification is that:
Turning to your implementation, your mapping of a provisioned metrics reporting configuration to a "reporter" instance in the 5GMS Client sounds good. The bit that's not quite aligned is that a given "reporter" instance might need to collect and report metrics that are not within the scope of scheme. That is never the case with DASH reporting, as currently specified, but would occur if/when the VR project wants to use 5GMS-based QoE metrics reporting mechanism. Given this, I would be inclined to make preparations in the reference implementation for that eventuality. |
That said, if you can come up with a convincing technical argument about why it's advantageous to have unqualified term identifiers listed in metrics, we might be able to accommodate that in the specification update. (For the avoidance of doubt, "this is how my current implementation works" is not a convincing argument, so you will need to do better than that!) |
Ok understood, based on your example from 5G-MAG/Standards#128: {
"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"
]
} In this case the scheme ( For now, I will change the implementation to check for the right prefixes. The current implementation approach would still work if we extend our reporter to support VR metrics (or any other metric reported with the scheme if (shouldReportMetric(Metrics.BUFFER_LEVEL, qoeMetricsRequest.metrics)) {
if (bufferLevel.entries.size > 0) {
qoeMetricsReport.bufferLevel = arrayListOf(bufferLevel)
}
}
|
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 schemeurn: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.
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 followingurn:3GPP:ns:PSS:DASH:QM10#AvgThroughput
Required changes
We need to adjust our implementation to support the name space identifier:
urn:3GPP:ns:PSS:DASH:QM10
.Optional changes
For robustness reasons, we might decide to support the prefixed and non-prefixed version of the metrics strings. However, this will lead to problems once there are multiple metrics with the same name but different identifier.
Related Issue
The text was updated successfully, but these errors were encountered: