10 QoE for Progressive Download and DASH
26.2473GPPProgressive Download and Dynamic Adaptive Streaming over HTTP (3GP-DASH)Release 17Transparent end-to-end Packet-switched Streaming Service (PSS)TS
10.1 General
A progressive download or 3GP-DASH client supporting Quality of Experience (QoE) shall report QoE metrics according to the QoE configuration. QoE reporting is optional, but if a 3GP-DASH client reports DASH metrics, it shall report all requested metrics.
The quality metrics are defined in subclause 10.2.
The quality metrics applicable for progressive download are specified in section 10.3. In this case the activation and configuration of QoE reporting framework is achieved by a corresponding OMA DM QoE Management Object as specified in Annex F, or by the QMC functionality as specified in Annex L.
The quality metrics for DASH are specified in section 10.4. In this case, QoE reporting may be triggered using the MPD ( i.e. when the Metrics element is present in the MPD) or using OMA DM QoE Management Object as specified in Annex F, or by the QMC functionality as specified in Annex L. When QoE reporting is triggered via any of the above methods, the 3GP-DASH client is expected to collect quality metrics according to the QoE configuration. When using the MPD or the QMC functionality, the Quality Reporting scheme as defined in section 10.5 may be used.
The QoE configuration shall only be evaluated by the client at the start of a QoE measurement and reporting session (“QoE session”) associated with a streaming session. This includes evaluation of any filtering criteria such as by geographical area. Client evaluation of all measurement and reporting criterias for an ongoing QoE session shall be unaffected by any QoE configuration changes received during that session – i.e., any changes to the QoE configuration shall only affect QoE sessions started after these configuration changes have been received.
The quality metric reporting protocol is defined in subclause 10.6. This protocol shall be used when QoE reporting is triggered via the MPD or OMA DM QoE Management Object. When QoE reporting is triggered via the QMC functionality, the reporting is specified in Annex L.
The usage of ITU-T P.1203 [49] Audio/Video Mean Opinion Score (A/V MOS) estimation is defined in Annex K.
10.2 QoE Metric Definitions
10.2.1 Introduction
This section provides the general QoE metric definitions and measurement framework.
The semantics are defined using an abstract syntax. Section 10.6 provides a mapping to an XML schema. Items in this abstract syntax have one of the following primitive types (Integer, Real, Boolean, Enum, String) or one of the following compound types:
– Objects: an unordered sequence of (key, value) pairs, where the key always has string type and is unique within the sequence.
– List: a ordered list of items.
– Set: an unordered set of items.
Additionally, there are two kinds of timestamp defined, i.e. real time (wall-clock time) and media time.
10.2.2 Void
This clause is void.
Table 25: Void
10.2.3 Representation Switch Events
Annex D.4.4 in ISO/IEC 23009-1 [43] defines the metrics for representation switch events.
Table 26: Void
10.2.4 Average Throughput
This metric in Table 27 indicates the average throughput that is observed by the client during the measurement interval.
Table 27: Average Throughput
|
Key |
Type |
Description |
|
|
AvgThroughput |
Object |
Average throughput that is observed by the client during the measurement interval |
|
|
numbytes |
Integer |
The total number of the content bytes, i.e. the total number of bytes in the body of the HTTP responses, received during the measurement interval. |
|
|
activitytime |
Integer |
The activity time during the measurement interval in milliseconds. The activity time during the measurement interval is the time during which at least one GET request is still not completed (i.e. excluding inactivity time during the measurement interval). |
|
|
t |
Real Time |
The real time of the start of the measurement interval |
|
|
duration |
Integer |
The time in milliseconds of the measurement interval |
|
|
accessbearer |
String |
Access bearer for the TCP connection for which the average throughput is reported |
|
|
inactivitytype |
Enum |
Type of the inactivity, if known and consistent throughout the reporting period: User request (e.g. pause) Client measure to control the buffer Error case |
|
If the client requests the media Segments from the server separately over multiple non-competing parallel TCP connections established over separate access network bearers named as accessbearer, then the average throughput values should be reported as a list of events with average throughput for each access network and associated access network bearer information reported separately, following the same guidelines as described above.
10.2.5 Initial Playout Delay
This metric in Table 28 signals the initial playout delay at the start of the streaming of the presentation.
The metric is only logged at the time point when the playout of streaming video begins.
Table 28: Initial Playout Delay
|
Key |
Type |
Description |
|
InitialPlayoutDelay |
Integer |
The initial playout delay is measured as the time in milliseconds from the fetch of the first media Segment (or sub-segment) and the time at which media is retrieved from the client buffer. |
10.2.6 Buffer Level
Annex D.4.5 in ISO/IEC 23009-1 [43] defines the metrics for buffer level status events.
Table 29: Void
10.2.7 Play List
Decoded samples are generally rendered in presentation time sequence, each at or close to its specified presentation time. A compact representation of the information flow can thus be constructed from a list of time periods during which samples of a single representation were continuously rendered, such that each was presented at its specified presentation time to some specific level of accuracy (e.g. +/-10 ms).
Such a sequence of periods of continuous delivery is started by a user action that requests playout to begin at a specified media time (this could be a "play", "seek" or "resume" action) and continues until playout stops either due to a user action, the end of the content, or a permanent failure.
Table 30 defines the play list event metric.
Table 30: Play List
|
Key |
Type |
Description |
||||
|
PlayList |
List |
A list of playback periods. A playback period is the time interval between a user action and whichever occurs soonest of the next user action, the end of playback or a failure that stops playback. |
||||
|
Entry |
Object |
A record of a single playback period. |
||||
|
start |
Real Time |
Timestamp of the user action that starts the playback period. |
||||
|
mstart |
Media Time |
The presentation time at which playout was requested by the user action. |
||||
|
starttype |
Enum |
Type of user action which triggered playout – New playout request (e.g. initial playout or seeking) – Resume from pause – Other user request (e.g. user-requested quality change) – Start of a metrics collection period (hence earlier entries in the play list not collected) |
||||
|
Trace |
List |
List of periods of continuous rendering of decoded samples. |
||||
|
Traceentry |
Objects |
Single entry in the list. |
||||
|
representationid |
String |
The value of Representation@id from which the samples were taken. This is an optional parameter and should not be reported in case of progressive download. |
||||
|
subreplevel |
Integer |
If not present, this metric concerns the Representation as a whole. If present, subreplevel indicates the greatest value of any SubRepresentation@level being rendered. This is an optional parameter and should not be reported in case of progressive download. |
||||
|
start |
Real Time |
The time at which the first sample was rendered. |
||||
|
sstart |
Media Time |
The presentation time of the first sample rendered. |
||||
|
duration |
Integer |
The time in milliseconds of the duration of the continuously presented samples (which is the same in real time and media time). "Continuously presented" means that the media clock continued to advance at the playout speed throughout the interval. |
||||
|
playbackspeed |
Real |
The playback speed relative to normal playback speed (i.e.normal forward playback speed is 1.0). |
||||
|
stopreason |
Enum |
The reason why continuous presentation of this representation was stopped. Either: – representation switch (not relevant in case of progressive download) – rebuffering – user request – end of period – end of content – end of a metrics collection period – failure – other |
||||
|
stopreasonother |
String |
The stopreasonother attribute shall be included only if stopreason attribute is included and has the enum value other. In this release of the specification, the sender of this string shall set its value to one of the following:: – switch from unicast to broadcast – switch from broadcast to unicast The receiver of this attribute shall ignore this attribute if its string is set to differerent value than the values listed above. |
||||
NOTE: The trace may include entries for different representations that overlap in time, because multiple representations are being rendered simultaneously, for example one audio and one video representation.
The playlist includes user actions about start/stop, but also other non-user actions such as adaptation and rebuffering. Thus the playlist may be used to derive many other metrics, and an example calculation of a few stalling-related metrics is shown below.
Assume a user at wall-clock time hh:mm:ss = 09:00:00 clicks to start a 60-second video with the following playout characteristics:
Figure 10-1 Example for Playout
– 5 seconds of initial stalling
– 10 seconds playing with representation 1
– 15 seconds of stalling
– 20 seconds playing with representation 2
– 30 seconds playing with representation 1
This would result in the following (somewhat simplified in this example) playout list being reported by the client:
Playlist
Entry#1
start = 09:00:00
mstart = 00:00:00
starttype = New playout request
Trace
Traceentry#1
representationid = 1
start = 09:00:05
sstart = 00:00:00
duration = 10 seconds
stopreason = rebuffering
Traceentry#2
representationid = 2
start = 09:00:30
sstart = 00:00:10
duration = 20 seconds
stopreason = representation switch
Traceentry#3
representationid = 1
start = 09:00:50
sstart = 00:00:30
duration = 30 seconds
stopreason = end of content
The number of stalling occurances may be calculated by counting how many times a stop reason is specified as "rebuffering".
The time duration for a stalling event may be calculated based on the time difference between the end time of a trace entry with stopreason equal to "rebuffering", and the start time of the next trace entry. In the example above the stalling starts at "Traceentry#1, (start + duration)" = 09:00:05 + 10 secs = 09:00:15, and ends at "Traceentry#2, start" = 09:00:30. Thus the length of the stalling is 15 seconds.
10.2.8 MPD Information
This metric can be used to report Representation information from the MPD, so that reporting servers without direct access to the MPD can understand the used media characteristics.
The metric is reported whenever the client sends any other quality metrics report containing references to a Representation which MPD information has still not been reported.
Table 31 defines the MPD information for quality reporting.
Table 31: MPD Information for Quality Reporting
|
Key |
Type |
Description |
|
|
MPDInformation |
Object |
||
|
representationid |
String |
Value of Representation@id for the representation addressed by the QoE metrics report. |
|
|
subreplevel |
Integer |
If present, value of SubRepresentation@level for the subrepresentation addressed by the QoE metrics report. If not present, the QoE metrics report concerns the representation as a whole. |
|
|
Mpdinfo |
RepresentationType |
Provides the MPD information for the representation or subrepresentation identified by representationid and subreplevel, if present. The following attributes and elements shall be present within mpdinfo if they are present for the identified representation or subrepresentation and their values shall be identical to those presented in the MPD: @bandwidth, @qualityRanking, @width, @height, @mimeType, and @codecs. |
|
10.2.9 Playout Delay for Media Start-up
This metric in Table 31a indicates the waiting time that the user experiences for media start-up.
The metric is only logged at the time point when the media start-up happens.
Table 31a: Playout Delay for Media Start-up
|
Key |
Type |
Description |
|
PlayoutDelayforMediaStartup |
Integer |
The playout delay for media start-up is measured as the time in milliseconds from the time instant of DASH player receives play-back-start trigger to the instant of media playout. – If the MPD has been delivered earlier before the user clicks, it may include the process time of MPD, the fetch time of some media segments which are required for media presentation, the process time of segments, and the time for media decode and render to the user. – If no MPD has been fetched earlier, it also needs to add the fetch time of MPD. |
10.2.10 Device information
This metric contains information about the displayed video resolution as well as the physical screen characteristics. If the video is rendered in full-screen mode, the video resolution usually coincides with the characteristics of the full physical display. If the video is rendered in a smaller subwindow, the characteristics of the actual video window shown shall be logged.
If known by the DASH client, the physical screen width and the horizontal field-of-view shall also be logged.
The metric is logged at the start of each QoE reporting period, and whenever the characteristics changes during the session (for instance if the UE is rotated from horizontal to vertical orientation, or if the video subwindow size is changed).
Table 31b defines the device information metrics. If an individual metric cannot be logged, its value shall be set to 0 (zero).
Table 31b: Device information
|
Key |
Type |
Description |
||
|
DeviceInformationList |
List |
A list of device information objects. |
||
|
Entry |
Object |
A single object containing new device information. |
||
|
start |
Real-Time |
Timestamp when the device information was logged. |
||
|
mstart |
Media-Time |
The presentation time at which the device information was logged. |
||
|
videoWidth |
Integer |
The width of the displayed video, in screen pixels (not encoded video pixels). |
||
|
videoHeight |
Integer |
The height of the displayed video, in screen pixels (not encoded video pixels) |
||
|
screenWidth |
Integer |
The total width of the screen, in screen pixels |
||
|
screenHeight |
Integer |
The total height of the screen, in screen pixels |
||
|
pixelWidth |
Float |
The width of a screen pixel, in mm |
||
|
pixelHeight |
Float |
The height of a screen pixel, in mm |
||
|
fieldOfView |
Float |
The actual or estimated horizontal angle subtended at the eye by the screen, measured in degrees. |
||
10.3 Quality Metrics for Progressive Download
The following metrics shall be supported by progressive download clients supporting the QoE reporting feature:
– Average Throughput (Clause 10.2.4),
– Initial Playout Delay (Clause 10.2.5),
– Buffer Level (Clause 10.2.6),
– Play List (Clause 10.2.7), and
– Device information (Clause 10.2.10).
10.4 Quality Metrics for DASH
The following metrics shall be supported by 3GP-DASH clients supporting the QoE reporting feature:
– List of Representation Switch Events (Clause 10.2.3),
– Average Throughput (Clause 10.2.4),
– Initial Playout Delay (Clause 10.2.5),
– Buffer Level (Clause 10.2.6),
– Play List (Clause 10.2.7),
– MPD Information (Clause 10.2.8),
– Device information (Clause 10.2.10).
The @metrics attribute contains a list of quality metric keys listing all metrics that the DASH shall collect and report.
The semantics of the attributes within the Metrics element are provided in Table 32. The XML-syntax of a Metrics element is provided in Table 33.
Table 32: Semantics of Metrics element
|
Element or Attribute Name |
Use |
Description |
|||||
|---|---|---|---|---|---|---|---|
|
Metrics |
DASH metric element |
||||||
|
@metrics |
M |
This attribute lists all quality metrics (as a list of quality metric keys as defined in section 10.2, separated by a whitespace) that the client shall report. Certain keys allow specifying a measurement interval or period over which a single value of the metric is derived and potentially also other parameters controlling the collection of the metrics. The parameters, if any, are included in parenthesis after the key and their semantics are specified in clause 10.2 with the metric definition itself. |
|||||
|
Range |
0..N |
When specified, it indicates the time period during which quality metric collection is requested. When not present, quality metric collection is requested for the whole duration of the content. |
|||||
|
@starttime |
O |
When specified, it indicates the start time of the quality metric collection operation. When not present, quality metric collection is requested from the beginning of content consumption. For services with MPD@type "Live", the start time of quality metric collection can be obtained in wallclock time by adding the value of this attribute indicated in media time to the value of the MPD@availabilityStartTime attribute. For services with MPD@type "OnDemand" , the start time is indicated in media time and is relative to the PeriodStart time of the first period in this MPD. |
|||||
|
@duration |
O |
When specified, it indicates the duration of the quality metric collection period. The value of this attribute is expressed in media time. |
|||||
|
Reporting |
1…N |
Descriptors that provide information about the requested Quality Reporting method and formats, and Auxiliary Reporting method and format. See clause 10.5 for the 3GP-DASH quality reporting schemes, and clause 14 for the 3GP-DASH auxiliary reporting scheme. |
|||||
|
Legend: For attributes: M=Mandatory, O=Optional, OD=Optional with Default Value, CM=Conditionally Mandatory. For elements: <minOccurs>…<maxOccurs> (N=unbounded) Elements are bold; attributes are non-bold and preceded with an @. |
|||||||
Table 33: XML-Syntax of Metrics element
|
<!– QoE Collection and Reporting –> <xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/> <xs:complexType name="RangeType"> |
10.5 Quality Reporting Scheme for DASH
This section specifies a 3GP-DASH quality reporting scheme.
The quality reporting scheme is signaled using in the Reporting element in the Metrics element. The URN to be used for the Reporting@schemeIdUri shall be "urn:3GPP:ns:PSS:DASH:QM10".
The reporting scheme shall use the quality reporting protocol defined in section 10.6.
The semantics and XML syntax of the scheme information for the 3GP-DASH quality reporting scheme are specified in Table 34 and Table 35, respectively.
Table 34: Semantics of Quality Reporting Scheme Information
|
Element or Attribute Name |
Use |
Description |
||
|
@apn |
O |
This attribute gives the access point that should be used for sending the QoE reports. |
||
|
@format |
O |
This field gives the requested format for the reports. Possible formats are: "uncompressed" and "gzip". |
||
|
@samplepercentage |
O |
Percentage of the clients that should report QoE. The client uses a random number generator with the given percentage to find out if the client should report or not. |
||
|
@reportingserver |
M |
The reporting server URL to which the reports will be sent. |
||
|
@reportinginterval |
O |
Indicates the time(s) reports should be sent. If not present, then the client should send a report after the streaming session has ended. If present, @reportingInterval=n indicates that the client should send a report every n-th second provided that new metrics information has become available since the previous report. For each report sent, only the newly collected information since the previous report shall be reported. |
||
|
LocationFilter |
0..1 |
When present, this element indicates the geographic area(s) or location(s) where quality metric collection is requested. When not present, quality metric collection is requested regardless of the device’s location. The LocationFilter element comprises one or more instances of any combination of targeted cell-IDs, polygons and circular areas.Each cell-ID entry in LocationFilter is announced in cellList, and each polygon and circular area entry is announced in the polygonList or and circularAreaList elements, respectively. |
||
|
cellList |
0..N |
This element specifies a list of cell identified by E-UTRAN-CGI or CGI. |
||
|
shape |
Geographic area comprising one or more instances of polygonList and/or circularAreaList elements. |
|||
|
polygonList |
0..N |
This element, when present, comprises a list of ‘Polygon’ shapes as defined by OMA MLP[51]. |
||
|
@confLevel |
O |
This attribute indicates the probability in percent that the DASH client is located in the corresponding polygon area. It is defined as ‘lev_conf’ by OMA MLP. If not present, it has default value of 60. |
||
|
circularAreaList |
0..N |
This element, when present, comprises a list of ‘CircularArea’ shapes as defined by OMA MLP[51]. |
||
|
@confLevel |
O |
This attribute indicates the probability in percent that the DASH client is located in the corresponding circular area. It is defined as ‘lev_conf’ by OMA MLP. If not present, it has default value of 60. |
||
|
SliceScope |
0..1 |
When present, this element indicates a list of network slices in which the QoE collection is requested. When not present, quality metric collection is requested for all network slices. The SliceScope is a list of S-NSSAIs. |
||
|
Legend: For attributes: M=Mandatory, O=Optional, OD=Optional with Default Value, CM=Conditionally Mandatory. For elements: <minOccurs>…<maxOccurs> (N=unbounded) Elements are bold; attributes are non-bold and preceded with an @ |
||||
Table 35: Syntax of Quality Reporting Scheme Information
|
<?xml version="1.0"?> <xs:annotation> <xs:element name="ThreeGPQualityReporting" type="SimpleQualityReportingType"/> <xs:complexType name="SimpleQualityReportingType"> <xs:sequence> <xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> <xs:simpleType name="FormatType"> <xs:complexType name="LocationFilterType"> <xs:element name="shape" type="ShapeType" minOccurs="0"/> <xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/> <xs:anyAttribute namespace="##other" processContents="lax"/> </xs:complexType> <xs:complexType name="ShapeType"> <xs:element name="CircularAreaList" type="CircularAreaListType" minOccurs="0"/> <xs:anyAttribute namespace="##other" processContents="lax"/> </xs:complexType> <xs:complexType name="PolygonListType"> <xs:documentation> see [OMA MLP] </xs:documentation> </xs:annotation> <xs:sequence> <xs:element name="Polygon" minOccurs="0" maxOccurs="unbounded"/> <xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> <xs:attribute name="ConfLevel" type="xs:unsignedInt" use="optional"/> <xs:anyAttribute namespace="##other" processContents="lax"/> </xs:complexType> <xs:complexType name="CircularAreaListType"> <xs:documentation> see [OMA MLP] </xs:documentation> </xs:annotation> <xs:sequence> <xs:element name="CircularArea" minOccurs="0" maxOccurs="unbounded"/> <xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> <xs:attribute name="ConfLevel" type="xs:unsignedInt" use="optional"/> <xs:anyAttribute namespace="##other" processContents="lax"/> </xs:complexType> <xs:simpleType name="UnsignedIntVectorType"> |
10.6 Quality Reporting Protocol
10.6.1 General
The quality reporting protocol consists of:
– The XML-based report format defined in section 10.6.2
– The reporting protocol defined in section 10.6.3
The MIME type of an XML-formatted QoE report shall be "application/3gpdash-qoe-report+xml" as defined in Annex J.
10.6.2 Report Format
The QoE report is formatted as an XML document that complies with the following XML schema:
|
<?xml version="1.0"?> xmlns:sup="urn:3gpp:metadata:2016:PSS:SupplementQoEMetric" xmlns:sv="urn:3gpp:metadata:2016:PSS:schemaVersion" <xs:element name="ReceptionReport" type="ReceptionReportType"/> <xs:complexType name="ReceptionReportType"> <xs:complexType name="QoeReportType"> <xs:element ref="sup:supplementQoEMetric" minOccurs="0" maxOccurs="1"/> <xs:attribute name="qoeReferenceId" type="xs:hexBinary" use="optional"/> <xs:attribute name="recordingSessionId" type="xs:hexBinary" use="optional"/> </xs:choice> <xs:complexType name="HttpListType"> <xs:complexType name="HttpListEntryType"> <xs:simpleType name="HttpEntryResourceType"> <xs:simpleType name="StringPatternType"> <xs:simpleType name="ExtensibleHttpEntryResourceType"> <xs:complexType name="HttpThroughputTraceType"> <xs:complexType name="RepSwitchListType"> <xs:complexType name="RepSwitchEventType"> <xs:complexType name="AvgThroughputType"> <xs:simpleType name="InactivityType"> <xs:anyAttribute processContents="skip"/> <xs:complexType name="BufferLevelEntryType"> <xs:complexType name="PlayListType"> <xs:anyAttribute processContents="skip"/> <xs:complexType name="PlayListEntryType"> <xs:complexType name="PlayListTraceEntryType"> <xs:attribute name="stopReasonOther" type="xs:string" use="optional"/> <xs:simpleType name="StartType"> <xs:enumeration value="Other"/> <xs:complexType name="MpdInformationType"> <xs:complexType name="RepresentationType"> <xs:simpleType name="DoubleVectorType"> <xs:simpleType name="StringVectorType"> <xs:simpleType name="UnsignedIntVectorType"> </xs:schema> |
The following schema is an extension to allow additional QoE metrics.
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema
xmlns="urn:3gpp:metadata:2016:PSS:SupplementQoEMetric"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
targetNamespace="urn:3gpp:metadata:2016:PSS:SupplementQoEMetric"
elementFormDefault="qualified">
<xs:element name="supplementQoEMetric" type="SupplementQoEMetricType"/>
<xs:complexType name="SupplementQoEMetricType">
<xs:sequence>
<xs:element name="deviceinformation" type="DeviceInformationType" minOccurs="0"/>
<xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="DeviceInformationType">
<xs:choice>
<xs:element name="Entry" type="DeviceInformationEntryType" maxOccurs="unbounded"/>
</xs:choice>
<xs:anyAttribute processContents="skip"/>
</xs:complexType>
<xs:complexType name="DeviceInformationEntryType">
<xs:attribute name="start" type="xs:dateTime" use="required"/>
<xs:attribute name="mstart" type="xs:duration" use="required"/>
<xs:attribute name="videoWidth" type="xs:unsignedInt" use="required"/>
<xs:attribute name="videoHeight" type="xs:unsignedInt" use="required"/>
<xs:attribute name="screenWidth" type="xs:unsignedInt" use="required"/>
<xs:attribute name="screenHeight" type="xs:unsignedInt" use="required"/>
<xs:attribute name="pixelWidth" type="xs:double" use="required"/>
<xs:attribute name="pixelHeight" type="xs:double" use="required"/>
<xs:attribute name="fieldOfView" type="xs:double" use="required"/>
<xs:anyAttribute processContents="skip"/>
</xs:complexType>
</xs:schema>
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns="urn:3gpp:metadata:2016:PSS:schemaVersion"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
targetNamespace="urn:3gpp:metadata:2016:PSS:schemaVersion"
elementFormDefault="qualified">
<xs:element name="schemaVersion" type="xs:unsignedInt"/>
<xs:element name="delimiter" type="xs:byte"/>
</xs:schema>
Note: If a supplementQoEMetric needs to be sent when no ordinar QoEMetric are due, a dummy MPDInformation metric shall be sent with codecs="none", bandwidth=0, mimeType="none", representationId="none".
Note: If the attribute qoeReferenceId was defined in the QMC configuration (see clause L.2), the value shall be copied into each QoE report, to facilitate network-side correlation (see [63]). If this attribute was defined the attribute recordingSessionId shall also be returned for each QoE report. The recordingSessionId is a two-byte octet defined by the client. It shall remain the same for all QoE reports belonging to the same streaming session, and it should be different for QoE reports belonging to different streaming sessions.
Note: For QMC scheme, if the SliceScope is included in the QoE configuration and the slice associated with the streaming service is within the SliceScope, the DASH client should execute the QoE collection and include the S-NSSAI and DNN that correspond to the report data for support of per-slice QoE reporting and evaluation in OAM. This information may be retrieved via the AT Command +CGDCONT [61]) or the specific traffic mapping with URSP rule[69].
10.6.3 Reporting Protocols
For configuration done via the QMC functionality (see Annex L), the client shall also send QoE reports via the QMC functionality. For MPD or OMA-DM configuration, if a specific metrics server has been configured, the client shall send QoE reports using the HTTP (RFC 2616) [9] POST request carrying XML formatted metadata in its body.
An example QoE reporting based on HTTP POST request signalling is shown below:
|
POST http://www.exampleserver.com HTTP/1.1 Host: 192.68.1.1 User-Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; Trident/4.0) Content-Type: text/xml; charset=utf-8 Content-Length: 4408 |
|
<?xml version="1.0"?> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> </HttpListEntry> <HttpListEntry type="InitializationSegment" url="http://www.example.com/content/initRep1.3gp" trequest="2011-02-16T08:59:40" tresponse="2011-02-16T08:59:41" interval="200"> </HttpListEntry> <HttpListEntry type="InitializationSegment" url="http://www.example.com/content/initRep2.3gp" trequest="2011-02-16T08:59:41" tresponse="2011-02-16T08:59:42" interval="200"> </HttpListEntry> <HttpListEntry type="InitializationSegment" url="http://www.example.com/content/initRep3.3gp" trequest="2011-02-16T08:59:42" tresponse="2011-02-16T08:59:43" interval="200"> </HttpListEntry> </HttpList> |