Closed rjb1000 closed 6 months ago
I don't understand why you want to remove metricsReportingConfigurationId
from the M5 POST endpoint. The metricsReportingConfigurationId
is generated via M1 and then used via M5. A ServiceAccessInformation can have multiple clientMetricsReportingConfigurations
entries and therefore multiple metricsReportingConfigurationId
. When sending a metrics report from the Media Session Handler to the Application Function via M5 the metricsReportingConfigurationId
identifies the corresponding entry from clientMetricsReportingConfigurations
.
Note that the payload of the POST request that is issued via M5 includes the metrics report (in XML format). It does not create a new metrics reporting configuration.
Yes, @dsilhavy is correct: the M5_MetricsReporting_submitMetricsReport operation isn't a RESTful creation operation, but rather a Remote Procedure Call.
It's important to include the metrics reporting configuration ID in the HTTP request at M5 for the following reasons:
urn:3GPP:ns:PSS:DASH:QM10
, then the MIME content type of reports must be application/3gpdash-qoe-report+xml
per TS 26.247 clause 10.6.1 and the schema type of the XML document must be urn:3gpp:metadata:2017:HSD:receptionreport
per clause 10.6.2 (a change to the schema namespace was approved at SA#101 last week as TS 26.247 CR0182r3 S4-231517|SP-230912 and soon to be published as TS 26.247 V17.4.0).Your implementation needs to validate the metrics report, perhaps using a simple extensible lookup table mapping the scheme URI to the expected MIME content type and schema namespace identifier, and reject the report if it is malformed in any way. This includes XML parsing errors.
M5_MetricsReporting.yaml specifies the following error responses for the submitMetricsReport operation:
Although not currently specified in TS 26.512, I think both errors should carry a _TS29571CommonData.yaml#/components/schemas/ProblemDetails providing an explanation of the error.
Questions regarding M5 Metrics POST
endpoint: In which format real streaming metrics from client modules are going to be? XML or Json?
In previous implementation, Metrics Reporting data sample (https://github.com/5G-MAG/rt-5gms-media-stream-handler/issues/35) was in XML format, and I implemented parsing function to draw out relevant client metrics from the body of POST
request. Later, I added invokation of storing function to save metrics locally: https://github.com/5G-MAG/rt-5gms-application-function/issues/90
For the Consumption Reporting the case is slightly different - M5 Consumption POST
endpoint expects JSON data, invokes predefined OpenAPI functionalities (which are not defined for M5 Metrics POST
) and stores reports as local files.
Have there been any structural changes on the UE side regarding metrics formatting?
The default report format for QoE Metrics Reporting based on the default scheme 3GPP urn:3GPP:ns:PSS:DASH:QM10
is XML. With the current client-side implementation supporting the default scheme, you can expect the reports to be submitted in XML format. Example report as generated today:
<?xml version="1.0" encoding="utf-8"?>
<ReceptionReport clientID="e98e353f-0872-4239-9910-cce4b204f7e7"
contentURI="https://livesim.dashif.org/livesim/testpic_2s/Manifest.mpd"
xsi:schemaLocation="urn:3gpp:metadata:2011:HSD:receptionreport DASH-QoE-Report.xsd"
xmlns:sv="urn:3gpp:metadata:2016:PSS:schemaVersion" xmlns="urn:3gpp:metadata:2011:HSD:receptionreport"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<QoeReport reportPeriod="10" reportTime="2024-03-13T10:10:15.719Z" periodID="P0">
<QoeMetric>
<BufferLevel>
<BufferLevelEntry level="29943" t="2024-03-13T10:10:06.168Z"/>
<BufferLevelEntry level="31888" t="2024-03-13T10:10:06.187Z"/>
<BufferLevelEntry level="31451" t="2024-03-13T10:10:06.647Z"/>
<BufferLevelEntry level="30820" t="2024-03-13T10:10:07.259Z"/>
<BufferLevelEntry level="30939" t="2024-03-13T10:10:08.176Z"/>
<BufferLevelEntry level="31886" t="2024-03-13T10:10:08.192Z"/>
<BufferLevelEntry level="30815" t="2024-03-13T10:10:09.273Z"/>
<BufferLevelEntry level="31773" t="2024-03-13T10:10:10.170Z"/>
<BufferLevelEntry level="31773" t="2024-03-13T10:10:10.180Z"/>
<BufferLevelEntry level="30794" t="2024-03-13T10:10:11.304Z"/>
<BufferLevelEntry level="31894" t="2024-03-13T10:10:12.189Z"/>
<BufferLevelEntry level="31874" t="2024-03-13T10:10:12.208Z"/>
<BufferLevelEntry level="30780" t="2024-03-13T10:10:13.315Z"/>
<BufferLevelEntry level="31902" t="2024-03-13T10:10:14.178Z"/>
<BufferLevelEntry level="31872" t="2024-03-13T10:10:14.210Z"/>
<BufferLevelEntry level="30787" t="2024-03-13T10:10:15.305Z"/>
</BufferLevel>
</QoeMetric>
<QoeMetric>
<HttpList>
<HttpListEntry actualurl="https://livesim.dashif.org/livesim2/testpic_2s/A48/855162302.m4s"
interval="94" range="" responsecode="200" trequest="2024-03-13T10:10:06.071Z"
tresponse="2024-03-13T10:10:06.073Z" type="MediaSegment"
url="https://livesim.dashif.org/livesim2/testpic_2s/A48/855162302.m4s">
<Trace b="13279" d="94" s="2024-03-13T10:10:06.073Z"/>
</HttpListEntry>
<HttpListEntry actualurl="https://livesim.dashif.org/livesim2/testpic_2s/V300/855162302.m4s"
interval="120" range="" responsecode="200" trequest="2024-03-13T10:10:06.063Z"
tresponse="2024-03-13T10:10:06.065Z" type="MediaSegment"
url="https://livesim.dashif.org/livesim2/testpic_2s/V300/855162302.m4s">
<Trace b="35889" d="120" s="2024-03-13T10:10:06.065Z"/>
</HttpListEntry>
<HttpListEntry actualurl="https://livesim.dashif.org/livesim2/testpic_2s/Manifest.mpd" interval="104"
range="" responsecode="200" trequest="2024-03-13T10:10:07.148Z"
tresponse="2024-03-13T10:10:07.153Z" type="MPD"
url="https://livesim.dashif.org/livesim2/testpic_2s/Manifest.mpd">
<Trace b="2121" d="104" s="2024-03-13T10:10:07.153Z"/>
</HttpListEntry>
<HttpListEntry actualurl="https://livesim.dashif.org/livesim2/testpic_2s/A48/855162303.m4s"
interval="121" range="" responsecode="200" trequest="2024-03-13T10:10:08.052Z"
tresponse="2024-03-13T10:10:08.053Z" type="MediaSegment"
url="https://livesim.dashif.org/livesim2/testpic_2s/A48/855162303.m4s">
<Trace b="13177" d="121" s="2024-03-13T10:10:08.053Z"/>
</HttpListEntry>
<HttpListEntry actualurl="https://livesim.dashif.org/livesim2/testpic_2s/V300/855162303.m4s"
interval="150" range="" responsecode="200" trequest="2024-03-13T10:10:08.040Z"
tresponse="2024-03-13T10:10:08.041Z" type="MediaSegment"
url="https://livesim.dashif.org/livesim2/testpic_2s/V300/855162303.m4s">
<Trace b="38180" d="150" s="2024-03-13T10:10:08.041Z"/>
</HttpListEntry>
<HttpListEntry actualurl="https://livesim.dashif.org/livesim2/testpic_2s/Manifest.mpd" interval="115"
range="" responsecode="200" trequest="2024-03-13T10:10:09.150Z"
tresponse="2024-03-13T10:10:09.154Z" type="MPD"
url="https://livesim.dashif.org/livesim2/testpic_2s/Manifest.mpd">
<Trace b="2121" d="115" s="2024-03-13T10:10:09.154Z"/>
</HttpListEntry>
<HttpListEntry actualurl="https://livesim.dashif.org/livesim2/testpic_2s/A48/855162304.m4s"
interval="120" range="" responsecode="200" trequest="2024-03-13T10:10:10.046Z"
tresponse="2024-03-13T10:10:10.048Z" type="MediaSegment"
url="https://livesim.dashif.org/livesim2/testpic_2s/A48/855162304.m4s">
<Trace b="13286" d="120" s="2024-03-13T10:10:10.048Z"/>
</HttpListEntry>
<HttpListEntry actualurl="https://livesim.dashif.org/livesim2/testpic_2s/V300/855162304.m4s"
interval="144" range="" responsecode="200" trequest="2024-03-13T10:10:10.033Z"
tresponse="2024-03-13T10:10:10.035Z" type="MediaSegment"
url="https://livesim.dashif.org/livesim2/testpic_2s/V300/855162304.m4s">
<Trace b="38114" d="144" s="2024-03-13T10:10:10.035Z"/>
</HttpListEntry>
<HttpListEntry actualurl="https://livesim.dashif.org/livesim2/testpic_2s/Manifest.mpd" interval="133"
range="" responsecode="200" trequest="2024-03-13T10:10:11.157Z"
tresponse="2024-03-13T10:10:11.166Z" type="MPD"
url="https://livesim.dashif.org/livesim2/testpic_2s/Manifest.mpd">
<Trace b="2121" d="133" s="2024-03-13T10:10:11.166Z"/>
</HttpListEntry>
<HttpListEntry actualurl="https://livesim.dashif.org/livesim2/testpic_2s/A48/855162305.m4s"
interval="124" range="" responsecode="200" trequest="2024-03-13T10:10:12.048Z"
tresponse="2024-03-13T10:10:12.058Z" type="MediaSegment"
url="https://livesim.dashif.org/livesim2/testpic_2s/A48/855162305.m4s">
<Trace b="13258" d="124" s="2024-03-13T10:10:12.058Z"/>
</HttpListEntry>
<HttpListEntry actualurl="https://livesim.dashif.org/livesim2/testpic_2s/V300/855162305.m4s"
interval="151" range="" responsecode="200" trequest="2024-03-13T10:10:12.048Z"
tresponse="2024-03-13T10:10:12.053Z" type="MediaSegment"
url="https://livesim.dashif.org/livesim2/testpic_2s/V300/855162305.m4s">
<Trace b="39217" d="151" s="2024-03-13T10:10:12.053Z"/>
</HttpListEntry>
<HttpListEntry actualurl="https://livesim.dashif.org/livesim2/testpic_2s/Manifest.mpd" interval="142"
range="" responsecode="200" trequest="2024-03-13T10:10:13.159Z"
tresponse="2024-03-13T10:10:13.167Z" type="MPD"
url="https://livesim.dashif.org/livesim2/testpic_2s/Manifest.mpd">
<Trace b="2121" d="142" s="2024-03-13T10:10:13.167Z"/>
</HttpListEntry>
<HttpListEntry actualurl="https://livesim.dashif.org/livesim2/testpic_2s/A48/855162306.m4s"
interval="113" range="" responsecode="200" trequest="2024-03-13T10:10:14.049Z"
tresponse="2024-03-13T10:10:14.057Z" type="MediaSegment"
url="https://livesim.dashif.org/livesim2/testpic_2s/A48/855162306.m4s">
<Trace b="13279" d="113" s="2024-03-13T10:10:14.057Z"/>
</HttpListEntry>
<HttpListEntry actualurl="https://livesim.dashif.org/livesim2/testpic_2s/V300/855162306.m4s"
interval="169" range="" responsecode="200" trequest="2024-03-13T10:10:14.036Z"
tresponse="2024-03-13T10:10:14.039Z" type="MediaSegment"
url="https://livesim.dashif.org/livesim2/testpic_2s/V300/855162306.m4s">
<Trace b="38163" d="169" s="2024-03-13T10:10:14.039Z"/>
</HttpListEntry>
<HttpListEntry actualurl="https://livesim.dashif.org/livesim2/testpic_2s/Manifest.mpd" interval="99"
range="" responsecode="200" trequest="2024-03-13T10:10:15.204Z"
tresponse="2024-03-13T10:10:15.205Z" type="MPD"
url="https://livesim.dashif.org/livesim2/testpic_2s/Manifest.mpd">
<Trace b="2121" d="99" s="2024-03-13T10:10:15.205Z"/>
</HttpListEntry>
</HttpList>
</QoeMetric>
<sv:delimiter>0</sv:delimiter>
</QoeReport>
</ReceptionReport>
As #143 was merged I am closing this issue
According to the TS 26.512 section 11.4.2, the only request supported by M5 regarding Metrics Reporting is
POST
(Creation). It's supposed to operate on{apiRoot}/3gpp-m5/{apiVersion}/metrics-reporting/{provisioningSessionId}/ {metricsReportingConfigurationId}
meaning that ID for Metrics Reporting Configurations is contained within the URL. M1-side code of the same operation implements functionmsaf_metrics_reporting_configuration_create()
which generates UUID value when invoked (also according to the specification). That leads me to the question about adding new function that won't generate UUID but fetch it directly from the URL (message->h.resource.component[2]
). Does it make sense to have two quite similar functions, or it's worth to consider removingmetricsReportingConfigurationId
from the M5 POST endpoint? @dsilhavy @davidjwbbc