ETSI TR 101 578 V1.2.1 (2015-07)

Speech and multimedia Transmission Quality (STQ); QoS aspects of TCP-based video services like YouTubeTM

RTR/STQ-00201m

General Information

• Status: Published
• Publication Date: 27-Jul-2015
• Technical Committee: STQ MOBILE - STQ Mobile
• Current Stage: 12 - Completion
• Due Date: 28-Jul-2015
• Completion Date: 28-Jul-2015

Standards Content (Sample)

TECHNICAL REPORT
Speech and multimedia Transmission Quality (STQ);
QoS aspects of TCP-based video services like YouTube™

2 ETSI TR 101 578 V1.2.1 (2015-07)

Reference
RTR/STQ-00201m
Keywords
measurement, QoS, service, TCP-based video
services
ETSI
650 Route des Lucioles
F-06921 Sophia Antipolis Cedex - FRANCE

Tel.: [phone]  Fax: [phone]

Siret N° 348 623 562 00017 - NAF 742 C
Association à but non lucratif enregistrée à la
Sous-Préfecture de Grasse (06) N° 7803/88

Important notice
The present document can be downloaded from:
http://www.etsi.org/standards-search
The present document may be made available in electronic versions and/or in print. The content of any electronic and/or
print versions of the present document shall not be modified without the prior written authorization of ETSI. In case of any
existing or perceived difference in contents between such versions and/or in print, the only prevailing document is the
print of the Portable Document Format (PDF) version kept on a specific network drive within ETSI Secretariat.
Users of the present document should be aware that the document may be subject to revision or change of status.
Information on the current status of this and other ETSI documents is available at
http://portal.etsi.org/tb/status/status.asp
If you find errors in the present document, please send your comment to one of the following services:
https://portal.etsi.org/People/CommiteeSupportStaff.aspx
Copyright Notification
No part may be reproduced or utilized in any form or by any means, electronic or mechanical, including photocopying
and microfilm except as authorized by written permission of ETSI.
The content of the PDF version shall not be modified without the written authorization of ETSI.
The copyright and the foregoing restriction extend to reproduction in all media.

© European Telecommunications Standards Institute 2015.
All rights reserved.
TM TM TM
DECT , PLUGTESTS , UMTS and the ETSI logo are Trade Marks of ETSI registered for the benefit of its Members.
TM
3GPP and LTE™ are Trade Marks of ETSI registered for the benefit of its Members and
of the 3GPP Organizational Partners.
GSM® and the GSM logo are Trade Marks registered and owned by the GSM Association.
ETSI
3 ETSI TR 101 578 V1.2.1 (2015-07)
Contents
Intellectual Property Rights . 7
Foreword . 7
Modal verbs terminology . 7
Introduction . 7
1 Scope . 9
2 References . 9
2.1 Normative references . 9
2.2 Informative references . 9
3 Abbreviations . 9
4 Quality of Service measurements for TCP-based video services like YouTube™ . 10
4.0 General . 10
4.1 Phases of TCP-based video services . 10
4.2 QoS aspects of TCP-based video services . 12
4.2.0 Scope of aspects . 12
4.2.1 Video freezes and - skips . 12
4.2.2 Downloading with DASH . 12
4.3 QoS parameters for TCP-based video services . 12
4.3.0 Paramater and trigger points . 12
4.3.1 Player IP Service Access Failure Ratio [%] . 15
4.3.2 Player IP Service Access Time [s] . 16
4.3.3 Player Download Cut-off Ratio [%] . 16
4.3.4 Player Download Time [s] . 16
4.3.5 Player Session Failure Ratio [%] . 16
4.3.6 Player Session Time [s] . 16
4.3.7 Video IP Service Access Failure Ratio [%] . 16
4.3.8 Video IP Service Access Time [s] . 17
4.3.9 Video Reproduction Start Failure Ratio [%] . 17
4.3.10 Video Reproduction Start Delay [s] . 17
4.3.11 Video Play Start Failure Ratio [%] . 17
4.3.12 Video Play Start Time [s] . 17
4.3.13 IP Service Access Failure Ratio [%] . 18
4.3.14 IP Service Access Time [s] . 18
4.3.15 Video Session Cut-off Ratio [%] . 18
4.3.16 Video Session Time [s] . 18
4.3.17 Impairment Free Video Session Ratio [%] . 18
4.3.18 Video Expected Size [kbit] . 19
4.3.19 Video Downloaded Size [kbit]. 19
4.3.20 Video Compression Ratio [%] . 19
4.3.21 Video Transfer Cut-off Ratio [%] . 20
4.3.22 Video Transfer Time [s] . 20
4.3.23 Video Mean User Data Rate [kbit/s] . 20
4.3.24 Video Playout Cut-off Ratio [%] . 20
4.3.25 Video Playout Cut-off Time [s] . 20
4.3.26 Video Expected Duration [s] . 21
4.3.27 Video Playout Duration [s] . 21
4.3.28 Video Freeze Occurrences . 21
4.3.29 Accumulated Video Freezing Duration [s] . 21
4.3.30 Video Skip Occurrences . 21
4.3.31 Accumulated Video Skips Duration [s] . 22
4.3.32 Video Maximum Freezing Duration [s] . 22
4.3.33 Video Freezing Impairment Ratio [%]. 22
4.3.34 Video Freezing Time Proportion . 22
4.3.35 End-to-End Session Failure Ratio [%] . 23
4.4 Recommended supplementary information for TCP-based video service measurements . 23
ETSI
4 ETSI TR 101 578 V1.2.1 (2015-07)
4.5 Configuration aspects including timeout recommendations for TCP-based video service measurements . 23
4.5.0 Purpose . 23
4.5.1 URL . 23
4.5.2 Timeouts . 24
4.5.2.0 Application of timeouts . 24
4.5.2.1 Player IP Service Access timeout . 24
4.5.2.2 Player Download Time timeout . 24
4.5.2.3 Video IP Service Access timeout . 24
4.5.2.4 Video Reproduction Start Delay timeout . 24
4.5.3 Video Playout Duration . 24
4.5.4 Handling of video freezes . 25
4.5.4.0 Use of freezes . 25
4.5.4.1 Minimum freeze duration . 25
4.5.4.2 Maximum duration of single freeze . 25
4.5.4.3 Maximum duration of all freezes . 25
4.5.4.4 Maximum number of freezes . 25
4.5.5 Timeout and Threshold Frameworks . 25
4.5.6 Hide video during playout . 26
4.5.7 Play until the end . 26
4.5.8 Cache and cookies . 26
4.6 Impacts of measurement hardware for TCP-based video service measurements . 26
Annex A: Measuring YouTube™ QoS with the Smartphone App . 27
A.0. Introduction . 27
A.1. User observable phases of the clip reproduction . 27
A.2. QoS Parameter for You Tube with the Smartphone App . 28
A.2.0 Parameter and trigger points . 28
A.2.1 App Video Access Failure Ratio [%] . 28
A.2.2 App Video Access Time [s] . 28
A.2.3 App Video Playout Cut-off Ratio [%] . 28
A.2.4 App Video Playout Duration [s] . 29
A.2.5 App Impairment Free Video Session Ratio [%] . 29
A.2.6 App Video Freezing Time Ratio [%] . 29
A.3. Configuration aspects . 29
History . 30

ETSI
5 ETSI TR 101 578 V1.2.1 (2015-07)
List of figures
Figure 1: Typical phases of TCP-based video services .11
Figure A.1: Typical observable phases of Smartphone App video service .27

ETSI
6 ETSI TR 101 578 V1.2.1 (2015-07)
List of tables
Table 1: Overview of QoS parameters and mapping to typical phases of TCP-based video services .13
Table 2: Overview of the trigger points used for the QoS parameter definition .15
Table 3: Observable quantities recommended getting included into the measurement results .23
Table 4: Example settings that do model a standard user .26
Table A.1: Overview of QoS parameters and mapping to typical phases of the video services as experienced by the user
...................................................................................................................................................................................28
Table A.2: Overview of the trigger points used for the QoS parameter definition .28

ETSI
7 ETSI TR 101 578 V1.2.1 (2015-07)
Intellectual Property Rights
IPRs essential or potentially essential to the present document may have been declared to ETSI. The information
pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found
in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in
respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web
server (http://ipr.etsi.org).
Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee
can be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Web
server) which are, or may be, or may become, essential to the present document.
Foreword
This Technical Report (TR) has been produced by ETSI Technical Committee Speech and multimedia Transmission
Quality (STQ).
Modal verbs terminology
In the present document "shall", "shall not", "should", "should not", "may", "need not", "will", "will not", "can" and
"cannot" are to be interpreted as described in clause 3.2 of the ETSI Drafting Rules (Verbal forms for the expression of
provisions).
"must" and "must not" are NOT allowed in ETSI deliverables except when used in direct citation.
Introduction
There are a variety of popular TCP-based video services available on the internet, on which users can upload, view and
share videos. These services use mainly Adobe® Flash® Video but also RealPlayer® and QuickTime® and lately
HTML5 technology to display a wide variety of video content, including movie clips, TV clips, and music videos, as
well as amateur content such as video blogging and short original videos.
NOTE 1: Adobe® Flash® is the trade name of a product supplied by Adobe. This information is given for the
convenience of users of the present document and does not constitute an endorsement by ETSI of the
product named. Equivalent products may be used if they can be shown to lead to the same results.
NOTE 2: RealPlayer® is the trade name of a product supplied by RealNetworks. This information is given for the
convenience of users of the present document and does not constitute an endorsement by ETSI of the
product named. Equivalent products may be used if they can be shown to lead to the same results.
NOTE 3: QuickTime® is the trade name of a product supplied by Apple. This information is given for the
convenience of users of the present document and does not constitute an endorsement by ETSI of the
product named. Equivalent products may be used if they can be shown to lead to the same results.
These services have become very popular and have a major share of the internet traffic worldwide. Due to its high
popularity in general and its use over mobile internet its availability and quality is of key interest of the provider of
mobile internet access, which makes the services a matter for benchmarking. The down-stream scenario, the probability
to access and see a desired video and the quality of the video is the subject of measurement method laid out in the
present document.
Any video content is accessed via a link that is provided by the service on a web page. The actual linked videos need to
be qualified however e.g. YouTube™ provides different quality profiles of the same video content e.g. a music video
clip.
NOTE 4: YouTube™ is the trade name of a product supplied by Google. This information is given for the
convenience of users of the present document and does not constitute an endorsement by ETSI of the
product named. Equivalent products may be used if they can be shown to lead to the same results.

ETSI
8 ETSI TR 101 578 V1.2.1 (2015-07)
The individual quality profiles can differ in resolution (e.g. 240p, 360p, 480p, HD720p, HD1080p), in the data-rate and
other aspects. Since these differences of clips have an impact on their size and thus on the reproduction speed and
quality, a fair comparison can only be provided if actually the same clips are streamed over different networks. On the
other hand the clips not need to come physically from the same server since mobile operators employ proxies in order to
move the content closer to their subscriber and the downlink bandwidth is often controlled primarily by the video
service. Therefore the clips need to be streamed from the actual live network and may not be streamed from a dedicated
server.
For cases in which the video content is compressed during the transfer by a proxy hence the content arriving at the
subscriber is not identical, the compression ratio may be indicated to show that possible advantages in performance are
achieved by reducing the amount of data to be transferred. Whether this enhancement was achieved at the cost of the
general quality of the content could be determined by an objective video quality assessment.
The TCP-based videos can be received either on Smartphone or a PC connected via mobile network to the internet. For
the Smartphone the way the content is provided can differ significantly with the type and the OS the phone is using. In
the present document content delivery for special Apps, RealPlayer® and QuickTime® is not taken into consideration
but only the streaming over TCP as e.g. used by YouTube™ with a Browser on a PC or Smartphone with the respective
player.
ETSI
9 ETSI TR 101 578 V1.2.1 (2015-07)
1 Scope
The present document focuses on Quality of Service (QoS) measurements for TCP-based video services where
downloading and viewing takes place in parallel. In principle the presented measurement approach can be used for all
video services, where the video is embedded in a HTML context as of video on demand services like e.g. YouTube™.
Similar applications are also available on social networks.
In the following, QoS parameters to be used for such video service measurements are presented. The underlying
procedure consists of two phases: first requesting a control script containing among other information a link to the
content, and second, requesting this content. In the present document, YouTube™ serves as the default example but the
described QoS parameters can easily be applied to other TCP-based video services.
Furthermore, the present document also offers practical guidance for measurement execution and evaluation of HTTP
streaming QoS measurement.
The present document covers the video request and playout of the video. Other services offered by content providers
such as e.g. uploading video or managing the private account are not covered.
2 References
2.1 Normative references
References are either specific (identified by date of publication and/or edition number or version number) or
non-specific. For specific references, only the cited version applies. For non-specific references, the latest version of the
reference document (including any amendments) applies.
Referenced documents which are not found to be publicly available in the expected location might be found at
http://docbox.etsi.org/Reference.
NOTE: While any hyperlinks included in this clause were valid at the time of publication, ETSI cannot guarantee
their long term validity.
The following referenced documents are necessary for the application of the present document.
Not applicable.
2.2 Informative references
References are either specific (identified by date of publication and/or edition number or version number) or
non-specific. For specific references, only the cited version applies. For non-specific references, the latest version of the
reference document (including any amendments) applies.
NOTE: While any hyperlinks included in this clause were valid at the time of publication, ETSI cannot guarantee
their long term validity.
The following referenced documents are not necessary for the application of the present document but they assist the
user with regard to a particular subject area.
[i.1] ETSI TS 102 250-2: "Speech and multimedia Transmission Quality (STQ); QoS aspects for
popular services in mobile networks; Part 2: Definition of Quality of Service parameters and their
computation".
[i.2] ETSI TS 102 250-5: "Speech and multimedia Transmission Quality (STQ); QoS aspects for
popular services in mobile networks; Part 5: Definition of typical measurement profiles".
3 Abbreviations
For the purposes of the present document, the following abbreviations apply:
CPU Central Processing Unit
DASH Dynamic Adaptive Streaming over HTTP
ETSI
10 ETSI TR 101 578 V1.2.1 (2015-07)
DNS Domain Name System
FLV Flash® Video
FTP File Transfer Protocol
GPU Graphics Processing Unit
HDD Hard Disk Drive
HTML HyperText Markup Language
HTTP HyperText Transfer Protocol
HTTPS Secure HTTP
IP Internet Protocol
LAN Local Area Network
NDIS Network Driver Interface Specification
OS Operating System
PC Personal Computer
PEC Performance Enhancement Client
QoS Quality of Service
RTP Real-time Transport Protocol
RTSP Real Time Streaming Protocol
SYN TCP synchronize flag
TCP Transmission Control Protocol
UDP User Datagram Protocol
URL Uniform Resource Locator
WLAN Wireless Local Area Network
4 Quality of Service measurements for TCP-based
video services like YouTube™
4.0 General
Many TCP-based video services, like e.g. the YouTube™ video service, provide videos in several resolutions and
qualities. For some video services the client can choose the resolution and quality of the video playback manually. On
the other hand, several mobile clients often allow only lower resolutions (delivered in lower bandwidth). Usually,
videos are streamed in proprietary Flash® format (FLV) over TCP. In addition, for very large videos or client devices
not supporting Flash® other formats are supported as well, e.g. 3GP video down-stream via RTP/UDP for RealPlayer®
on Symbian OS™.
Many TCP-based video services, like e.g. the YouTube™ video service, provide videos in several resolutions and
qualities. For some video services the client can choose the resolution and quality of the video playback manually. On
the other hand, several mobile clients often allow only lower resolutions (delivered in lower bandwidth). Usually,
videos are streamed in proprietary Flash® format (FLV) over TCP. In addition, for very large videos or client devices
not supporting Flash® other formats are supported as well, e.g. 3GP video down-stream via RTP/UDP for RealPlayer®
on Symbian OS™.
NOTE: Symbian OS™ is the trade name of a product supplied by Symbian Ltd. This information is given for the
convenience of users of the present document and does not constitute an endorsement by ETSI of the
product named. Equivalent products may be used if they can be shown to lead to the same results.
4.1 Phases of TCP-based video services
Most TCP-based video services, like the YouTube™ video service, are comprised of several phases which are mainly
the set-up of a HTML context including downloading the control script for the multimedia playout entity (in the
following: "player") and the down-stream of the video itself.
Figure 1 shows typical phases of TCP-based video services, like YouTube™.
ETSI
11 ETSI TR 101 578 V1.2.1 (2015-07)

Figure 1: Typical phases of TCP-based video services
In principle the video service can be divided into the setup of the context until the player is ready to play and the
download and playout of the video.
The setup of the context until the player is ready to play can be divided into two phases, the "IP service access" phase
and the "player download" phase.
The "IP service access" phase starts when the HTML context and the player configuration download are requested. It
ends upon receipt of the first data byte containing HTML content, starting the player download phase.
NOTE: The initial DNS request sent when e. g. the YouTube™ URL is opened is not considered to be part of the
"IP service access" phase. Thus, the quality of service for the initial DNS resolution for the HTML
context and the player configuration download is not covered by the QoS parameters defined in the
present document for the "IP service access" phase.
The "IP service access" phase is followed by downloading the HTML context information and the player configuration
script (in case of Flash® Player). It contains potential surrounding HTML based information (YouTube™ site), which
can be the original YouTube™ site with an embedded player (YouTube™ in a browser window), or the player
application without any visible HTML context (YouTube™ App or Flash® Player in an empty HTML context). The
last step of the context setup is the download of the player configuration script. The entire download phase is called
simplified "player download". At the point the context and the configuration is downloaded completely, the player is
"ready to play".
The "streaming access" phase is started by pressing the "Play" button (or in case of "AutoPlay" with the event "Ready
To Play" that is then equivalent to requesting the video) and ends with receiving the first video packet over TCP or
RTP. This phase could be very interesting if there are proxies between the user and the content server, thus making
DNS resolution and other events an influential factor.
In a simple case, during "streaming access" phase there will be only one GET (in case of a requested TCP stream) or a
RTSP DESCRIBE (in case of a requested RTP stream) request for the video, followed immediately by the 200 OK
message and the payload packets for FLV (TCP) or 3GP (RTP) video. In a more complex case, there may either be
several ranged GET requests or it may happen that after the first GET request there will be several redirects (because of
proxies) and several more resolving of DNS, etc. so this phase can be much longer. Basically, QoS parameters related to
this phase allow concluding how close the network is to the content server for the measured video. Even if a preferred
server (URL) is given and firstly requested, the actual approached location of the clip may differ and lead to a
redirection to a closer or more appropriate server and DNS has to be contacted again.
In case of RTSP, an RTSP link is embedded in the HTML context. After receiving the final URL or the video, the video
can be streamed/downloaded (Ready to Play).
Upon receiving the first video packet, the "buffering" phase commences. While the "download" phase will end with the
last received video packet, the "buffering" phase ends in the moment the video playout actually starts. QoS parameters
related to this phase allow estimating the initial buffer size for the measured video and current Internet connection type
(e.g. DialUp, NDIS, WLAN, LAN).
The "IP service access", the "player download" and the "streaming access" phases jointly constitute the "pre-download"
phase. The "buffering" and the remaining video content transfer constitute the "download" phase.
ETSI
12 ETSI TR 101 578 V1.2.1 (2015-07)
As soon as playout starts, the "playout" phase commences. This phase overlaps with the "download" phase and
represents the full playout time for the video. Depending on the configuration the full video can be displayed or video
playout can be cut short when video download is complete.
During the "playout" phase the "freezes" of the video display and "video skips" are detected.
4.2 QoS aspects of TCP-based video services
4.2.0 Scope of aspects
When looking at impairments of the video playout, this clause focuses on objectively measurable impairments, such as:
• failures to start;
• video freezes;
• video skips; or
• failures to download completely.
It may be that further subjective impairments exist, which limit comparability of QoS parameters obtained in different
setups. Such subjective impairments can e.g. be downscaling of video image quality or frame-rate.
4.2.1 Video freezes and - skips
Freezing events are when the video playout stops (freezes), it is mainly caused by a buffer under-run. The video pauses
until the re-buffering is complete. After that, the video continues. There is no video information lost. This is the
common case for YouTube™ using Flash® Player.
Skip events are when playout is not continuous, which means that parts of the video content are not displayed or re-
displayed, i.e. the playout jumps to a future or past point in time. A possible reason for this can be player misbehaviour
or network outage in combination with live streams. When a skip occurs, there is usually no visible re-buffering
information on the screen.
4.2.2 Downloading with DASH
The purpose of the employment of DASH is to avoid freezing during the reproduction of the video by adapting the
quality level to the available bandwidth. To avoid a buffer under-run during the download the player can request the
video content with different quality level than originally chosen. The content with lower video quality needs less
download bandwidth and allows to display the video continuously without freezing even in situations with limited
bandwidth. Therefore the employment of DASH can lead to varying resolution and quality levels during the
reproduction. By using DASH it can happen that the same content is downloaded in different quality levels in parallel.
4.3 QoS parameters for TCP-based video services
4.3.0 Paramater and trigger points
In this clause, a set of QoS parameters based and expanding on the streaming QoS parameters as defined in ETSI
TS 102 250-2 [i.1] is proposed for measuring TCP-based video services.
Table 1 gives an overview of the proposed QoS parameters and provides a mapping of these parameters to the phases
introduced in clause 4.1. Furthermore, a parameter type is assigned for each QoS parameter in order to determine the
calculation method to be used for the respective parameter.
ETSI
13 ETSI TR 101 578 V1.2.1 (2015-07)
Table 1: Overview of QoS parameters and mapping to typical phases of TCP-based video services
Related Phase(s) QoS parameter name QoS parameter type
IP service access Player IP Service Access Failure Ratio Failure Ratio
IP service access Player IP Service Access Time Duration
Player download Player Download Cut-off Ratio Cut-off Ratio
Player download Player Download Time Duration
IP service access, Player download Player Session Failure Ratio Failure Ratio
IP service access, Player download Player Session Time Duration
Streaming access Video IP Service Access Failure Ratio Failure Ratio
Streaming access Video IP Service Access Time Duration
Buffering Video Reproduction Start Failure Ratio Failure Ratio
Buffering Video Reproduction Start Delay Duration
Streaming access, Buffering Video Play Start Failure Ratio Failure Ratio
Streaming access, Buffering Video Play Start Time Duration
Pre-download IP Service Access Failure Ratio Failure Ratio
Pre-download IP Service Access Time Duration
Streaming access, Buffering, Playout Video Session Cut-off Ratio Cut-off Ratio
Streaming access, Buffering, Playout Video Session Time Duration
Streaming access, Buffering, Playout Impairment Free Video Session Ratio Calculation
Download Video Expected Size Size
Download Video Downloaded Size Size
Download Video Compression Ratio Calculation
Download Video Transfer Cut-off Ratio Cut-off Ratio
Download Video Transfer Time Duration
Download Video Mean User Data Rate Calculation
Playout Video Playout Cut-off Ratio Cut-off Ratio
Playout Video Playout Cut-off Time Duration
Playout Video Expected Duration Duration
Playout Video Playout Duration Duration
Playout Video Freeze Occurrences Count
Playout Accumulated Video Freezing Duration Calculation
Playout Video Skip Occurrences Count
Playout Accumulated Video Skips Duration Calculation
Playout Video Maximum Freezing Duration Calculation
Playout Video Freezing Impairment Ratio Failure Ratio
Playout Video Freezing Time Proportion Calculation
Whole session End-to-End Session Failure Ratio Failure Ratio

Within table 1, the following QoS parameter types are defined:
• Calculation;
• Count;
• Duration;
• Size;
• Cut-off Ratio; and
• Failure Ratio.
The type "Calculation" is assigned to QoS parameters getting calculated based on other QoS parameters or other
measurable qualities within the same single measurement, e.g. durations of single freezes or single skips.
The type "Count" is assigned to QoS parameters where the QoS parameter is calculated by counting occurrences of a
certain event during a time period between a start trigger point and a stop trigger point, both observed during a single
measurement. The following equations define the abstract equation to be used to calculate such a parameter:
stop trigger
Count = occurence(t ,event)
i
∑
i=start trigger
ETSI
14 ETSI TR 101 578 V1.2.1 (2015-07)
1, if event occurs at time t
occurrence(t,event) = {
0, else
The type "Duration" is assigned to QoS parameters where the QoS parameter represents an expected or an actual time
period between a start trigger point and a stop trigger point, both observed during a single measurement. The following
equation defines the abstract equation to be used to calculate such a parameter:
Duration [s] =()t - t [s]
stop trigger start trigger
The type "Size" is assigned to QoS parameters where the QoS parameter is determined by the size of a quantity, e.g. the
expected or the actual size of a video.
The type "{Failure | Cut-off} Ratio" is assigned to QoS parameters representing a failure or Cut-off ratio. The following
equation defines the abstract equation to be used to calculate such a QoS parameter. Here, the term "unsuccessful
attempt" should be understood in the way that, during a single measurement, the stop trigger point of the QoS parameter
has not been observed within a given time after having observed the respective start trigger point.
unsuccessful attempts
{Failure | Cut - off} Ratio [%] = ×100

all attempts
For the computation of the QoS parameter with type "Calculation", "Count" or "Size", further information is given for
each QoS parameter within the following clauses, if applicable.
Table 2 gives an overview of the trigger points used for the QoS parameter definition. For each trigger point, an ID is
introduced. This ID will later be used as a reference within the QoS parameter definitions.
ETSI
15 ETSI TR 101 578 V1.2.1 (2015-07)
Table 2: Overview of the trigger points used for the QoS parameter definition
Trigger
Abstract description Technical description/protocol part
ID
tr-1 Start of player download TCP SYN towards streaming platform
Alternative: First HTTP GET request for the player sent
(see note 1)
If the respective HTTP header is not accessible due to
encryption of TCP segment data then the corresponding
player event can be used.
tr-2 First packet of player received HTTP 200 OK for the player request received (in TCP
segment data, if it is accessible there).

If the respective HTTP header is not accessible due to
encryption of TCP segment data then the corresponding
player event can be used.
tr-3 End of player download Last packet of the player received

If the respective HTTP packet is not accessible due to
encryption of TCP segment data then the corresponding
player event can be used.
tr-4 Start of video download (pressing TCP SYN towards streaming platform
"Play") Alternative: First HTTP GET request for video payload sent
(see note 2)
If the respective HTTP packet is not accessible due to
encryption of TCP segment data then the corresponding
player event can be used.
tr-5 Start of video transfer Reception of the HTTP 200 OK for the video payload in
TCP segment data
If the respective HTTP header is not accessible due to
encryption of TCP segment data then the corresponding
player event can be used.
tr-6 Start of video playout (first frame n. a.
displayed in player)
tr-7 End of video transfer Reception of the last packet of the video payload

If the respective HTTP packet is not accessible due to
encryption of TCP segment data then the corresponding
player event can be used.
tr-8 Intended end of video playout reached n. a.
NOTE 1: The HTTP GET can be used instead of TCP SYN sent to the streaming platform. This is reasonable for
the following reason: During a measurement, several sockets might be opened and when the
HTTP GET for the player payload is sent out, it might not be said for certain, which socket will be used
for the player download. Here, it is up to the reader to choose the trigger point suiting best the actual
needs and/or situation.
NOTE 2: In comparison to e.g. the respective trigger point defined in ETSI TS 102 250-2 [i.1] for the Streaming
Service Non-Accessibility, the HTTP GET can be used instead of TCP SYN sent to the streaming
platform. This is reasonable for the following reason: During e.g. a YouTube™ measurement, many
sockets might be opened and when the HTTP GET for the video payload is sent out, it might not be said
for certain, which socket will be used for the video content download. Other content like video
information, etc. might also be downloaded over the same socket prior to the HTTP GET being sent out
in order to receive the video payload. Especially in this case, the usage of TCP SYN would be
misleading. Here, it is up to the reader to choose the trigger point suiting best the actual needs and/or
situation.
4.3.1 Player IP Service Access Failure Ratio [%]
Start Stop
QoS parameter description trigger trigger
ID ID
The overall failure ratio for the player access. tr-1 tr-2

ETSI
16 ETSI TR 101 578 V1.2.1 (2015-07)
4.3.2 Player IP Service Access Time [s]
Start Stop
QoS parameter description trigger trigger
ID ID
The time it took for the player download to start. tr-1 tr-2

4.3.3 Player Download Cut-off Ratio [%]
Start Stop
QoS parameter description trigger trigger
ID ID
The overall cut-off ratio for the player download. tr-2 tr-3

4.3.4 Player Download Time [s]
Start Stop
QoS parameter description trigger trigger
ID ID
The time it took to download the player. tr-2 tr-3

4.3.5 Player Session Failure Ratio [%]
Start Stop
QoS parameter description trigger trigger
ID ID
The overall failure ratio for the player access and download. tr-1 tr-3
NOTE: This parameter combines the player IP service access and player data
download.
4.3.6 Player Session Time [s]
Start Stop
QoS parameter description trigg
...