1、 ATIS-0800057 QOS METRICS FOR CONTENT ON DEMAND As a leading technology and solutions development organization, ATIS brings together the top global ICT companies to advance the industrys most-pressing business priorities. Through ATIS committees and forums, nearly 200 companies address cloud service
2、s, device solutions, M2M communications, cyber security, ehealth, network evolution, quality of service, billing support, operations, and more. These priorities follow a fast-track development lifecyclefrom design and innovation through solutions that include standards, specifications, requirements,
3、 business use cases, software toolkits, and interoperability testing. ATIS is accredited by the American National Standards Institute (ANSI). ATIS is the North American Organizational Partner for the 3rd Generation Partnership Project (3GPP), a founding Partner of oneM2M, a member and major U.S. con
4、tributor to the International Telecommunication Union (ITU) Radio and Telecommunications sectors, and a member of the Inter-American Telecommunication Commission (CITEL). For more information, visit . Notice of Disclaimer Measurement Guidelines for DVB Systems. 16 ETSI TS 101 034 v1.1.1, Transport o
5、f MPEG-2-Based DVB Services over IP Based Networks. Broadband Forum4: 17 Broadband Forum TR-98, DSLHomeTMGateway Device Version 1.1 Data Model for TR-069, 2005. 18 Broadband Forum TR-126, Triple-Play Services Quality of Experience (QoE) Requirements, 2006. IETF5: 19 RFC 2330, Framework for IP Perfor
6、mance Metrics, 1998. 20 RFC 2616, Hypertext Transfer Protocol - HTTP/1.1, 1999. 21 RFC 2679 A One-way Delay Metric for IPPM, 1999. 22 RFC 2678, IPPM Metrics for Measuring Connectivity, 1999. 23 RFC 2680, A One-way Packet Loss Metric for IPPM, 1999. 24 RFC 3357, One-way Loss Pattern Sample Metrics, 2
7、002. 25 RFC 3393, IP Packet Delay Variation Metric for IP Performance Metrics (IPPM), 2002. 26 RFC 3432, Network Performance Measurements with Periodic Streams, 2002. 27 RFC 3550, RTP: A Transport Protocol for Real-Time Applications, 2003. 28 RFC 3611, RTP Control Protocol Extended Reports (RTCP XR)
8、, 2003. 29 RFC 3986, Uniform Resource Identifier (URI): Generic Syntax, 2005. 2These documents are available from the International Telecommunications Union. 3These documents are available from the European Telecommunications Standards Institute (ETSI). 4These documents are available from the Broadb
9、and Forum. 5RFC text is available at . ATIS-0800057 5 30 RFC 4737, Packet Reordering Metrics, 2006. 31 RFC 6349, Framework for TCP Throughput Testing, 2011. ISO/IEC: 32 ISO/IEC 23009-1:2012(E), Dynamic Adaptive Streaming over HTTP, 2012.63GPP: 33 3GPP TS 26.247 v10.0.0, Progressive Download and Dyna
10、mic Adaptive Streaming over HTTP (3GP-DASH), 2011.73.2 Informative References Broadband Forum: 34 Broadband Forum TR-135, Data Model for a TR-069 Enabled STB, 2010.4IETF: 35 IETF Draft RTP Control Protocol Extended Reports (RTP XR) - IP Video Metrics Report Blocks.84 Content on Demand 4.1 Service De
11、scription Content on Demand service is defined in ATIS-0800042, IPTV Content on Demand Service 8. CoD relates to the real-time consumption of IPTV content within some finite boundaries of time (i.e., it is not continuous like linear/broadcast TV). The following picture depicts the CoD service domain
12、s. 6This document is available from the International Organization for Standardization at . 7This document is available from the Third Generation Partnership Project (3GPP) at . 8This document is available at . ATIS-0800057 6 Figure 2: CoD Service (ATIS-0800002, Figure 8) Figure 2 indicates that con
13、tent is acquired by the service provider in a first phase (1) for storage in a content library/storage element. The content is then served to individual consumers at a later time (2). All these On Demand services are characterized as functioning unicast streams with trick play commands like pause, p
14、lay, rewind, and fast-forward. CoD services include the process of network attachment and initialization of devices and client discovery, as described in detail in ATIS-0800017 7 for both IMS and non-IMS-based IPTV environments. Figure 6 in ATIS 0800042 8 provides an overview of the phases of CoD se
15、rvice and an overview of content distribution and control paths through the network. This document does not include any metrics associated with these types of processes; however, it does include metrics involved with active services/sessions e.g., signaling associated with trick-play functionality.
16、CoD services utilizing HTTP such as Dynamic Adaptive Streaming over HTTP (DASH) 32 are also included. 4.1.1 Dynamic Adaptive Streaming Services Adaptive streaming technologies over HTTP, such as DASH 32, support services delivering continuous media content to the end user. All resources that compose
17、 the service are typically accessible through HTTP-URLs and the HTTP/1.1 protocol as specified in RFC 2616 20. This enables the use of standard HTTP servers and standard HTTP caches that can be used for hosting and distributing continuous media content. Figure 4 shows the basic principal for service
18、s using adaptive streaming over HTTP. ISO/IEC DASH standard 32 addresses the interfaces between the client and the server only. Specifically, it defines the formats that may be delivered exclusively over the HTTP interface to enable progressive download and streaming services. ATIS-0800057 7 Figure
19、3: Architecture for Progressive Download over HTTP Figure 4: Architecture for Adaptive Streaming Adaptive streaming services require the location from where the media can be streamed and an indication of which formats the content will be made available in. An example of this is described in the Medi
20、a Presentation Description (MPD) file defined in DASH 32. Another format is the M3U playlist. In particular, the MPD defines formats to announce resource identifiers for segments and to provide the context for these identified resources within a media presentation. Resource identifiers are exclusive
21、ly HTTP-URLs; i.e., URLs with a fixed schema of “http:/” or “https:/” as defined in RFC 3986 29. The MPD also enables the restriction of these URLs by a byte range attribute. The segments specify the formats of the entity body of the request response when issuing a HTTP GET request or a partial HTTP
22、 GET with the indicated byte range through HTTP/1.1 to a resource identified in the MPD. The MPD provides sufficient information for a client to provide a streaming service to the user by accessing the segments through the protocol specified in the schema of the defined resources. Such a client is r
23、eferred to as an adaptive streaming client. 4.1.2 Trick Play Many of the QoS aspects of the CoD service are found in the manner in which a user interacts with the Electronic Program Guide (EPG) and uses the trick-play features; i.e., transaction quality issues (see Figure 8). Transaction quality in
24、CoD service is very different from linear (broadcast) IPTV service. Due to the extreme variability in EPG designs and operation, QoS metrics for CoD EPG are for further study, but transaction quality focuses on the following indicators: Play Delay: Timing period from the moment the subject is select
25、ed to the time when the content is displayed. Resume Delay: Timing period from the moment the Play/Resume entry is selected to the time the content is displayed. Stop Delay: Timing period from the moment the Stop play video entry is selected to the time the content stops playing as indicated by the
26、video content display. Pause Delay: Timing period from the moment the Pause video entry is selected to the time the pause action is executed as indicated on the display device. ATIS-0800057 8 Rewind Delay: Timing period from the moment the Rewind video entry is selected to the time the rewind action
27、 is executed as indicated on the display device. Fast Forward Delay: Timing period from the moment the Fast Forward video entry is selected to the time the fast forward action is executed as indicated on the display device. It is suggested that focusing upon initial latency to start the program flow
28、 and the Pause and Play command latencies provides sufficient detail to represent network performance and limits metrics to precise definition. Some commands, such as fast-forward, are more difficult to define in a manner that can be instrumented with encrypted media flows and are thus not included
29、in Table 4. IPTV Terminal Function (ITF) hardware and CoD client application complexity related to video buffering, storage capacity, and advance content download will have a major impact on transaction quality metrics elements and QoE results. The definitions outlined herein are considered in a mod
30、e in which the service (CoD program) is being consumed directly. It does not include service in which programming is downloaded and stored locally for use at another time. CoD streaming services use signaling protocols, like Real Time Streaming Protocol (RTSP), often in conjunction with software gen
31、erally called “middleware”, to enable trick play modes like fast-forward and rewind. For specific RTSP message flows, refer to Appendix A. Trick play modes in progressive download services for CoD and adaptive streaming services like DASH are handled differently than for CoD services. Usually trick
32、play modes are not mandatory features of the service and may vary from implementation to implementation. For example, if a user of an adaptive service pauses a stream, the client would simply stop requesting the next media segment. To continue playback, the client would simply play the not-yet-consu
33、med but downloaded media or request the next media segment from the server. Fast-forward and rewind may be implemented using one or more special media representations in the MPD file (see the DASH standard 32). As an example, Figure 5 shows an interaction with a dynamic adaptive streaming service. T
34、he example shows four media representations with different bitrates/modes (5Mbits, 2Mbits, 0.5Mbits, and a special representation for a trick mode) while the white line indicates the flow between the different media representations (from left to right). A trick play “rewind” command is initiated by
35、a user as indicated in Figure 5. The client switches from the 2Mbit representation of the media to the “Trick Mode” representation. The client displays the media in reverse order using the content from the trick mode representation until the user indicates “play” again. The client then resumes the p
36、layback of the media at the location where the user stopped the rewind in the 5Mbits media representation. Figure 5: HTTP GET Sequence Example including Rewind Trick Play ATIS-0800057 9 4.2 CoD Service Deployments In order to find meaningful performance metrics for the CoD service, it is useful to l
37、ook at the information available in typical network deployments to determine whether a particular metric can be computed. There is quite a bit of variety in IPTV deployments. Each deployment most likely differs in the following: 1. Protocol stack. 2. Encryption. 3. Error correction (i.e., FEC or ret
38、ransmission). The first two determine what type of information is available to help compute audio-video quality metrics. Error correction mechanisms correct many network problems up to a certain point and should result in improved service robustness. 4.2.1 Protocol Stacks Figure 5 below outlines typ
39、ical protocol stacks used for CoD service deployments. It should be noted that the figure does not show a version in which MPEG-4 video packets (Access Units) are mapped directly into RTP packets without the use of a MPEG-2 Transport Stream packet format. This stack is used in some streaming service
40、s, but is not addressed in this document. ATIS-0800057 10 Figure 6: CoD Protocol Stack Example For adaptive streaming-based services over HTTP, service access is achieved by a manifest file (for example, MPD, M3U) or, in the case of a progressive download service, by a URL to the media file. ATIS-08
41、00057 11 Figure 7: Overview of the DASH Protocols Stack NOTE The MPD does not have to be delivered via TCP/HTTP. There can be other mechanisms. 4.2.2 Encryption Encryption can be applied at various levels of the protocol stack. Excluding the packet header and optional adaptation field supports a mor
42、e in-depth packet flow analysis than if they were encrypted. A default scrambling algorithm specified by ATIS IIF for the MPEG2 TS payload (i.e., the PES header, where both the MPEG-TS header and optional adaptation field are not encrypted) is defined in ATIS-0800006, IIF Default Scrambling Algorith
43、m 4. ATIS-0800006 also specifies a scrambling descriptor to signal the scrambling algorithm to be used between two entities that need to communicate (i.e., the ITF and the DRM system). Other scrambling algorithms are allowed and left to specific implementations. In a situation where the scrambling d
44、escriptor is not present or not used, the IPTV receiving device defaults to the use of the default scrambling algorithm defined by the ATIS IIF. For progressive downloading and adaptive streaming, encryption mechanisms have not been defined within ATIS as of yet. At many measurement points, the vide
45、o flows may not be decrypted at the point of measurement. As a result, encryption can affect the extent to which QoS metrics can be reliably measured. This is discussed further in section 6.4. Those restrictions apply for CoD streaming services as well as adaptive streaming services and progressive
46、download services. 4.2.3 Error Correction Mechanisms Some systems have mechanisms for error correction (e.g., FEC and/or retransmission such as RTP retransmission and reliable UDP) in place that can reduce the number of effective losses and their impact on the streams. ATIS-0800005, IPTV Packet Loss
47、 Report 3, indicates the impact of packet loss and discusses various error correction mechanisms to overcome packet losses. ATIS IIF, in ATIS-0800013 6, adopts an AL-FEC mechanism (Annex E) and a retransmission mechanism (Annex F) from ETSI TS 102.034 16. Nonetheless, these error correction mechanis
48、ms have limits and once those limits are passed, artifacts will be experienced by customers. ATIS-0800057 12 The QoS metrics described in this document can be used to measure the effectiveness of error correction mechanisms, but may be limited to the implementation and nature of the correction mecha
49、nism. For example, the effect of a FEC mechanism may only be measurable at the decoder level. 5 CoD Measurement Points Figure 8 below outlines a logical model for a CoD service network design which follows in general the network model concepts defined in ATIS-0800004, Framework for QoS Metrics and Measurements Supporting IPTV Services 2. The foundation model for these services can be found in Figure 8 of ATIS-0800042 8. While there may be a given network organized in a different way, it is believed t
