KR100808981B1 - Timing of quality of experience metrics - Google Patents

Abstract

The invention relates, among other things, to a quality feedback method in a streaming service in which at least one media stream 101 is streamed to a client 601, comprising the steps of: determining a quality feedback value in accordance with at least one quality metric 304, at least A corresponding timestamp metric is defined for each of the quality metrics, and each of the at least one timestamp metrics is based on at least one timestamp metric, based on the relative media playback time of the at least one media stream 101. Determining 305 a timestamp associated with the quality feedback value, and reporting 306 the quality feedback value and the associated timestamp to the server 600. The relative media play time is derived from the real time transport protocol 102 timestamps, the normal play time supported by the real time streaming protocol 109, the time stamps of the real time transport control protocol, or the timestamps of the session initiation protocol. This is preferable.

Description

Timing of quality of experience metrics

The present invention relates to a method, a computer program, a server and a protocol for providing feedback on quality in a streaming service in which at least one media stream is streamed to a client.

Streaming, on the one hand, relates to the ability of an application located in a client to continuously play these streams while synchronized media streams such as speech, audio and video streams are being transmitted to the client via a data network. Streaming, on the other hand, is also related to real-time low-delay applications, such as interactive applications.

Applications that can be built on top of streaming services can be divided into on-demand and live information transfer applications. The first category is music and news-on-demand applications. Live transmission of radio and television programs are examples of the second category. Real-time low-delay applications are, for example, multimedia (video) telephone or IP-enabled voice information delivery (VoIP) and any type of interactive multimedia application.

Streaming over fixed Internet Protocol (IP) networks is already a major application today. Although the Internet Engineering Task Force (IETF) and the World Wide Web Consortium (W3C) have developed a set of protocols used for fixed IP streaming services, a fully standardized streaming framework has not yet been defined. For third generation mobile communication systems in accordance with standards developed by the Third Generation Joint Project (3GPP), 3G packet-switched streaming services (PSS, 3GPP TS 26.233, TS 26.234) are available for 3G applications such as download applications and multimedia content. It bridges the gap between multi-media messaging services (MMS) and conversation and streaming services.

PSS enables mobile streaming applications, where the complexity of the terminals is lower than required for conventional services, since no media input devices and encoders are needed and less complex protocols can be used. Because. PSS includes a basic set of streaming control protocols, transport protocols, media codecs and scene description protocols.

1 schematically illustrates a PSS protocol stack 1 that controls the transfer of both streamable and non-streamable content between a content or media server and client.

Streamable content 101 such as video, audio and speech is first converted to a payload format of real time transport protocol (RTP) 102 at the adaptation layer 103. The RTP, defined by the IETF, uses the services of the Basic User Datagram Protocol (UDP) 104, and then provides a means for transmitting real-time or streaming data using the basic IP Protocol 105 services.

Multimedia content that is not created for streaming purposes (e.g., MMS clips that are rearranged on a terminal device), non-streamable content such as still images, bitmap and vector graphics, text, timed text, and synthetic audio ( 106 is transmitted by a hypertext transfer protocol (HTTP) 107 that uses a basic transmission control protocol (TCP) 108 and basic IP 105 services added thereto.

For non-streamable content 106 the built-in session setup and control specifications of HTTP 107 are sufficient for such content delivery, whereas for streamable content, clients from content servers, such as via RTP / UDP / IP, can be streamed. In order to start, stop, and pause the streaming video sent to the network, an advanced session establishment and control protocol must be exercised. This task is performed by the Real Time Streaming Protocol (RTSP) 109, which can utilize either Basic TCP 108 or Basic UDP 104. The RTSP needs at least presentation description 110 to establish a streaming session. Such presentation description 110 may be used, for example, as a session description protocol (SDP) file format. The SDP file includes information for receiving the media, such as a description of the session, such as a session name and author, media type to be displayed, addresses, ports, formats, and the like, and a bitrate of media.

When streaming content is to be viewed on the client side, for example on a mobile terminal, the user of the terminal is first provided with a universal resource identifier (URI) for the specific content suitable for his terminal. The URI may come from a WWW server, a wireless application protocol (WAP) server, or may be manually entered through the terminal's keyboard. This URI specifies the address of the streaming or RTSP server and the content on that server or another content server. The corresponding SDP file can now be obtained in a number of ways. It may be given in any link in the HTML page the user has downloaded, such as via embedded tags, or directly by typing it as a URI. The SDP file, i.e., the presentation description 110, is now transmitted via HTTP 107 as indicated in the middle column of the protocol stack of FIG. Alternatively, it may be obtained via RTSP 109 signaling, for example by using the DESCRIBE (explain) method of RTSP 109 as indicated in the right column of the protocol stack of FIG. 1. Presentation techniques may be transmitted by the RTP 102 as well. However, for the sake of simplicity of presentation, this possibility is excluded in FIG. 1.

Subsequent session establishment is the process by which the browser or user of the mobile terminal tries to cause the streaming client to establish a session with the content server. The terminal is expected to have an active radio bearer that enables IP based packet transmission at the start of session establishment signaling.

The subsequent streaming service setup is done by sending an RTSP SETUP message for each media stream selected by the client. This returns the UDP 104 and / or TCP 108 ports so that they can be used for their respective media streams. The client sends an RTSP PLAY message to the content server, which then starts sending one or more streams over the IP network.

In order to provide service providers in PSS systems with a means of evaluating end-user streaming experience, streaming quality of service metrics have been introduced in PSS systems. 3GPP Technical Document (Tdoc) S4-030860: 29th 3GPP TSG-SA4 Meeting in Pere: Proposed in Draft Rel-6 PSS Quality Metrics Permanent Document v0.10. The streaming client evaluates information about the quality of the actual streaming application and feeds it back to the streaming server, where the quality is defined in terms of the quality metrics. The streaming server may be an RTSP server, for example, and the quality metrics may be transmitted using the RTSP and SDP, for example.

The service is transparent to RAN and CN types, so only streaming clients and streaming servers are affected by the PSS quality metrics. One conclusion of this is that the measurement will not depend on information from protocol layers below the RTP layer (eg, UDP, IP, PDCP, SNDCP, LLC, RLC, MAC, Physical Layer).

A terminal of a PSS system that provides quality feedback performs a quality measurement according to a measurement rule, collects the measured values into the streaming client quality metrics, and reports the metrics to the streaming server. This requirement does not rule out the possibility that the streaming client reports raw quality measurements into quality metrics to be processed by the streaming server.

The streaming server is responsible for signaling the quality metrics reporting of the streaming client and collecting the quality metrics for this streaming client. The streaming server processes the quality metrics of the received streaming client to build a total quality metric. For example, the streaming server receives a report of the original lost packets to calculate the minimum, maximum, average, Avg, and standard packet loss rates of a particular streaming client.

The following seven quality metrics are defined in Tdoc S4-030860:

Corruption duration

The damage sustainer is the period from the first damaged frame to the end of the first good frame or report period following it (doubled earlier). The unit of this metric is expressed in seconds and may be a fractional value.

Rebuffering  Permanent ( Rebuffering  duration)

This metric can only be applied to audio, video, and speech, not to other media types. The unit of this metric is expressed in seconds and may be a fractional value. Rebuffering is defined as any time delay during the playback period due to inevitable events on the client side.

Initial buffering time

Initial buffering is the time from the receipt of the first RTP packet before the start of playback. The unit of this metric is expressed in seconds and may be a fractional value.

Consecutive missing content Packet  Number of content packets lost in succession

The number of consecutively missing content packets per media channel

Number of bytes presented to the media decoder

This parameter is the cumulative number of bytes provided to the media decoder.

Number of detected bit-errors

This is the number of bit errors detected at the application level. Low level errors will be handled at the link layer (either discarded or propagated to the application layer).

Number of corrected bit-errors}

Number of bit errors corrected at the application level. Low level errors will be handled at the link layer (either discarded or propagated to the application layer).

The purpose of the quality metric definition is to obtain consistent measurements across content type, terminals, radio access network (RAN) types.

The limitation is to minimize the size and complexity at the terminal of the quality metrics report that will be sent to the streaming server.

Substantial quality matrix feedback may be conveyed to the PSS server using the RTSP SET_PARAMETER method with the feedback header 2 as shown in FIG. 2, but in certain cases, other information may be It may be more efficient to use methods, for example a TEARDOWN message or a PAUSE message.

In the feedback header 2 of FIG. 2, the stream-url is an RTSP session or media control URL identifier for the feedback parameter. The metrics field in the parameter specification contains the metrics / measurement names (eg damage persisters, etc.). The value field indicates the result. It is possible for the same event to occur more than once during the monitoring period. In this case, the metric value occurs more than once, indicating the number of events on the server. The optional range field indicates the reporting period.

An optional Timestamp field in the feedback header 2 of FIG. 2 indicates a time when an event (or measurement) occurs after the start of a session or when a metric is calculated.

In Tdoc S4-030860, according to the timestamp field, there is no definition of a time base to be used and a definition of "start session".

Thus, it is not clear which time base will be used for the determination of timestamps. There may be different possibilities, for example the absolute session time after the start of the session and the like. The absolute session time is the time when the session took place, such as May 10, 2004 12:20:22 to 13:20:22. However, if absolute session time is used, for example as a timestamp for corruption reporting, it can be readily seen that this timestamp is not only related to the event to be reported, but also to all events that occurred before the session. For example, after a long initial buffering time and then several rebuffers occurred during the session, subsequent reporting of corruption persisters is assigned a timestamp delayed by the initial buffering and the rebufferings, The loss of accuracy. The same thing happens if streaming is resumed after being paused by the client. If reconstruction or analysis of such damage is done at the streaming server based on the quality report, all timestamps related to previous events, such as initial buffering, rebuffering, stoppage, etc., should be taken into account when interpreting the current timestamp.

Even when all timestamps of the preceding events are available at the streaming server, reconstruction or interpretation may not be possible at all unless the session start is clearly defined. The session start can be interpreted, for example, as the time when the first RTP packet was received by the streaming client, the time when the first media frame was played, or some other.

Even when the timebase and session start time are clearly defined, the timestamp value of some of the defined metrics may vary between different clients or different sessions of the same client. This is particularly due to the fact that quality metrics that may be measured at the client side depend on the processing power and workload of the terminal on which the streaming client is set up. For example, if the timestamp of the fourth metric, i.e., the number of missed RTP packets during a session, is defined as the time just before decoding commences, the time required for the terminal to reach the mark is dependent upon the processing power and the workload. Can be influenced.

As a result, the streaming server and the streaming client may have different interpretations of the reported quality metrics, and the clients may report different quality metrics for the same streaming qualities. After all, due to the ambiguity of the reported time stamps, the streaming server cannot correctly interpret the streaming quality.

In view of the problems described above, it is an object of the present invention, in particular, to provide a more precise and clear reporting on the timing of quality feedback values in streaming services, computer programs, computer program products, systems, clients, servers, and To propose a protocol.

A quality feedback method is proposed in a streaming service in which at least one media stream is streamed to a client, the method comprising: determining a quality feedback value according to at least one quality metric, corresponding timestamp metric for each of the at least one quality metric Determine a timestamp associated with the quality feedback value according to at least one timestamp metric, when each of the at least one timestamp metrics is based on a relative media playback time of the at least one media stream, and Reporting the quality feedback value and the associated timestamp to a server.

The at least one media stream may be, for example, a continuous media stream that may contain video, audio, or speech information that is continuously transmitted from a server, such as a content server, to the client, and displayed on a terminal on which the client is established through a tuning scheme. do. Alternatively, the at least one media stream may be a media stream of a real time low delay application, such as a multimedia (video) phone stream or a VoIP media stream or a media stream of any type of interactive multimedia application. This streaming occurs during a streaming session, in which several media streams can be streamed simultaneously to the client. The streaming may be based, for example, on protocols such as real time transport protocol (RTP), and may be controlled by additional protocols such as real time streaming protocol (RTSP) or session initiation protocol (SIP), where streaming is initiated, terminated and / or Pause can be enabled. The RTSP or SIP may be operated by protocol entities in the client and the server, and may be based on session description protocol (SDP). The server may be co-located or even the same with the content server where the media is substantially generated, or may be another instance. The quality of the streaming is determined at the client site according to the at least one quality metric, such as, for example, a damage persister or a rebuffer event, and is reported as a quality feedback value through the protocol on which streaming is based or the protocol controlling streaming. The quality metric basically defines how the quality feedback value is calculated. The at least one quality metric may be defined by the protocol controlling streaming, such that the at least one quality metric from a group of several quality metrics defined by the protocol is present during or even after session establishment. Can be compromised between and the server. For each of the at least one quality metrics, a respective timestamp metric is defined, for example, by the protocol or the like that controls the streaming. The timestamp metric basically defines how the timestamp associated with the quality feedback value defined by the quality metric should be determined. The at least one timestamp metric is based on the relative media playback time of the at least one media stream. The relative media playback time represents the temporal progression of the at least one media stream playback, separate from any absolute time base, i.e. without pause or delay intervals of playback, which occurred during streaming. The relative media playback time may thus be related to the sampling time of the continuous media during recording in the digital format. For example, the relative media play time may be represented by RTP timestamps provided by RTP or normal play time (NPT) provided by RTSP, or timestamps or timing information provided by SIP or RTCP. . The quality feedback value and associated timestamp are then reported to the server, such as through the protocol on which streaming is based or through the protocol controlling the streaming. If the protocol controlling the streaming is RTCP or SIP, then the reported quality feedback value and associated timestamp are determined by an entity such as a network entity such as a Call State Control Function (CSCF) to perform quality measurements. It may be desirable to be captured or recognized. The time stamp may be a forced or optional parameter in the RTP / RTSP / RTCP / SIP header.

According to a first aspect of the invention, a timestamp can be assigned to each quality feedback value, wherein the timestamp metric of the timestamp is uniquely defined for the quality metric of the quality feedback value. Thus, the ambiguity caused by using generic timestamp metrics for different quality metric classes is eliminated.

Further, according to the second aspect of the present invention, since the timestamp metric is based on relative media playback time, such as time base, it is independent of absolute session time and delays caused by events that occurred before the actual event reported. It is irrelevant to the processing power and workload of the terminal where the client is set up. The use of relative media play time may allow the use of session start definition to be discarded.

According to the method of the invention, said streaming of said at least one media stream is preferably based on real time transport protocol (RTP). The RTP may operate between the client and content server, may use user datagram protocol (UDP) services, and then may use Internet protocol (IP) services.

According to the method of the present invention, the relative media play time is derived from RTP timestamps provided in a header of at least one protocol data unit of the RTP. The RTP timestamp reflects the sampling instant of the first octet in the RTP protocol unit (or packet), or if the stored data is transmitted in the at least one media stream rather than in real time, the RTP timestamp is The next frame may come from a fictitious presentation timeline derived from wall clock time to determine when another unit is displayed.

According to the method of the invention, said streaming is at least partly controlled by the Real Time Streaming Protocol (RTSP). The RTSP may be based on the presentation description provided by the session description protocol (SDP). The RTSP is operated by the client and the server to enable for example to start, stop and end streaming.

According to the method of the invention, it may be preferred that the relative media play time is derived from the normal play time (NPT) provided by the RTSP. The NPT may indicate the absolute position of the stream with respect to the start of the presentation. The NPT can be derived from RTP timestamps.

According to the method of the present invention, the at least one quality metric defines the quality metric value that will be a time duration of an event, and the corresponding timestamp metric is indicative of a particular frame of the at least one media stream before the event occurs. It would be desirable to define the timestamp to be the relative media playback time.

According to the method of the present invention, it will be preferred that the event is a damage persister and the particular frame is the last good frame in the playback order before the damage occurs.

According to the method of the present invention, it will be preferred that the event is a rebuffer duration and the particular frame is the last played frame prior to the occurrence of the rebuffering.

According to the method of the present invention, the event is preferably the number of consecutively missing content packets, and the specific frame is preferably the last received frame in the playback order before the successive missing packets occur.

According to the method of the present invention, the at least one quality metric defines the quality metric value to be the number of events, and the corresponding timestamp metric is relative to a particular frame of the at least one media stream before the number of events is measured. It would be desirable to define the timestamp that will be the media playback time.

According to the method of the present invention, the number of events will preferably be the number of bytes to indicate to the media decoder, the number of detected bit errors, or the number of corrected bit errors, wherein the particular frame is before the number of events is measured. This is the decoded final frame.

According to the method of the present invention, the quality feedback value and the associated timestamp will preferably be reported to the server via the RTSP. The quality feedback value and the timestamp may be included, for example, in the header of the RTSP protocol data unit.

According to the method of the invention, it will be preferred that said streaming is at least partially controlled by Session Initiation Protocol (SIP). The quality feedback value and associated timestamp reported through the SIP would then preferably be captured or recognized by an entity such as a network entity such as a call state control function (CSCF) for quality measurement.

According to the method of the present invention, the relative media play time would preferably be derived from a time base provided by the SIP, in particular from SIP time stamps provided in a header of at least one protocol data unit of the SIP.

According to the method of the present invention, it may be preferred that said streaming is at least partly controlled by a real time transmission control protocol (RTCP). It would then be desirable for the quality feedback value and associated timestamp reported through the RTCP to be captured or recognized by an entity such as a network entity such as a call state control function (CSCF) for quality measurement.

According to the method of the invention, it may be preferred that the relative media playback time is derived from a time base provided from the RTCP, in particular RTCP timestamps provided in the header of at least one protocol data unit of the RTCP.

According to the method of the present invention, it would be desirable for the reported quality feedback value and associated time stamps to be captured in some case and used to analyze the streaming quality.

According to the method of the invention, it may be preferred that said streaming service is a packet switched streaming service (PSS) of a 3G mobile communication system.

Further proposed is a computer program containing instructions operative to cause a processor to perform the steps of the method described above.

Further proposed is a computer program product having a computer program with instructions operative to cause a processor to perform the steps of the method described above.

Further proposed is a quality feedback system in a streaming service, the system comprising at least one server and at least one client, at least one media stream being streamed to the at least one client, wherein a quality feedback value is determined according to at least one quality metric. And a timestamp associated with the quality feedback value is determined according to at least one timestamp metric, each corresponding to at least one quality metric and based on a relative media playback time of the at least one media stream. A feedback value and the associated timestamp are reported to the at least one server.

Further proposed is a client of a streaming service, the client comprising: means for receiving at least one media stream streamed to the client, means for determining a quality feedback value according to at least one quality metric, each of the at least one quality metric For, a corresponding timestamp metric is defined, wherein each of the at least one timestamp metrics is based on the relative media playback time of the at least one media stream, the quality feedback value according to the at least one timestamp metric. Means for determining an associated time stamp, and means for reporting the quality feedback value and the associated time stamp to a server. The client may be understood to be one of at least two parties involved in a real-time low-delay application session, which may be controlled by SIP, such as multimedia (video) telephone or VoIP, for example.

A server of a streaming service is further proposed, in which at least one media stream is streamed to a client in a streaming service, a quality feedback value is determined according to at least one quality metric, correspondingly defined for each of the at least one quality metric and the at least one According to at least one timestamp metric based on the relative media playback time of the media stream, when a timestamp associated with the quality feedback value is determined, the server may determine the quality feedback value and the associated timestamp reported by the client. Means for receiving. The server may be understood to be one of at least two parties involved in a real time low latency application session, which may be controlled by SIP, such as multimedia (video) telephone or VoIP, for example.

Further protocols to be used in the streaming service are proposed, and when at least one media stream is streamed to the client in the streaming service, the protocol defines at least one quality metric and at least one timestamp metric for each of the at least one quality metric. Wherein each of the at least one timestamp matrix is based on a relative media playback time of the at least one media stream.

According to the protocol of the present invention, it may be preferable that the protocol is RTSP combined with a session description protocol (SDP).

According to the protocol of the present invention, it may be preferred that the protocol is RTCP.

These and other aspects of the invention will be apparent from and elucidated with reference to the embodiments to be described hereinafter.

In the drawing:

1 is a schematic representation of a packet switched streaming service (PSS) protocol stack according to the prior art,

2: Real Time Streaming Protocol (RTSP) negotiation header according to the prior art,

3: a flowchart of the method of the invention, and

4 is a schematic representation of a system according to the invention.

The present invention proposes clear and uniformly specified timestamp metrics (timestamp semantics) for each defined quality metric, thereby providing both successive continuity, such as synchronized video and audio transmission and rendering. Eliminate ambiguity in reporting timing of quality feedback values in streaming services for real-time low-delay applications, such as multimedia applications and interactive applications. The timestamp metrics can be, for example, the normal play time (NPT) available if the Real-Time Streaming Protocol (RTSP) is used, or each RTP (Real-Time Transport Protocol, Real-Time). Relative media playback, which may come from an RTP provided by a time transport protocol and included in each RTP header, or from a time base or timestamps of a real time transmission control protocol (RTCP) or session initiation protocol (SIP). Based on time.

RTCP is based on the periodic transmission of control packets to all parties during a session, using the same distribution mechanism as the data packets. The underlying protocol must provide multiplexing of data and control packets using separate port numbers, including for example UDP. RTCP can in particular provide feedback on the quality of the data distribution. This is an integral part of RTP as a transport protocol and is related to the flow and congestion control functions of other transport protocols. Feedback may be directly useful for adaptive encoding control, but experiments with IP multicasting have revealed that it is also important to identify errors in the distribution with feedback from the receivers. Sending the received feedback report to all parties allows one party to estimate whether the problems are local or global. When using a distribution mechanism such as IP multicast, an entity that is not otherwise involved in the session, such as a network service provider, may receive feedback information and act as a third party monitor to diagnose network problems. In particular, RTCP can support or provide timestamps.

SIP is an application layer control protocol that can establish, change, and terminate multimedia sessions (conferences), such as Internet telephone calls. SIP may invite parties to already existing sessions, such as multicast conferences. Media can be added (and removed) to an existing session. SIP transparently supports name mapping and redirection services to support personal mobility-users can have an externally visible identifier regardless of their network location.

SIP is not a vertically integrated communication system. Rather, SIP is an element that can be used with other IETF protocols to build a complete multimedia structure. Typically, these structures include RTP for transmitting real-time data and providing QoS feedback, real-time streaming protocol for controlling transmission of streaming media (RTSP), and media for controlling gateways to a public switched telephone network (PSTN). Protocols, such as Media Gateway Control Protocol (MEGACO), and Session Description Protocol (SDP) for describing multimedia sessions. Thus, SIP will have to be used in conjunction with other protocols to provide complete services to users. However, the basic functionality and operation of SIP does not depend on any of those protocols.

In particular, SIP provides a timestamp field in its headers. The timestamp header field may indicate, for example, when one party sent a request to another party.

When SIP or RTCP is used, streaming occurs between two parties in a session (eg, set up in two terminals), and it may be useless for one party to report quality feedback values and related timestamps to the other party. Thus, it is desirable to provide a network entity such as, for example, a call state control function (CSCF) to recognize these reported quality feedback values and associated timestamps and use them to interpret the quality of streaming between the two parties.

Through the proposed timestamp metrics, different streaming servers and streaming clients report the reported quality, such as quality of experience (QoE) metrics, as in packet-switched streaming services (PSS) in 3G mobile communication systems. You will have interpretations of quality feedback in metrics or interactive applications, and enable correct interpretation of streaming quality experiences. Using a streaming server or QoE metric solver to map NPTs to real-time, time-related interpretations of session quality can be made.

For each quality metric defined in 3GPP Technical Document S4-030860, a timestamp metric as defined in the present invention will be described later, where the term NPT / RTP swim stamp is used where NPT is relative media when NPT is available. It is to be understood that if used as the play time, and only the RTP timestamps are available, they are used as the relative media play time.

Corruption duration

This time stamp indicates the time when the damage occurred. The value of the timestamp is equal to the NPT / RTP timestamp of the last good frame in playback order before corruption occurs. If there was no good frame before the damage, the time stamp is set to zero.

The damage persistence metrics apply not only to audio, video, or speech media, but also to timed text streams, such as a medium.

Rebuffering  Permanent ( Rebuffering  duration)

This timestamp indicates the time when rebuffering occurred. The value of the timestamp is equal to the NPT / RTP timestamp of the last played back before rebuffering occurs.

Initial buffering time

This timestamp semantics are not specified and their values are undefined.

Consecutive missing content Of packets  Number of content packets lost in succession

This timestamp indicates the time when consecutive missing packets occurred. The value of this timestamp is equal to the NPT / RTP timestamp of the last received RTP packet in reproduction order before generation of consecutive missing packets. If no RTP packet was received before the drop of consecutive packets, the timestamp is set to zero.

Number of bytes presented to the media decoder

This timestamp indicates the time when the number of bytes provided to the media decoder was measured. The value of the timestamp is equal to the NPT / RTP timestamp of the last decoded frame before the number of bytes provided to the media decoder is measured. If no frames were decoded before such a measurement, the timestamp is set to zero.

Number of detected bit-errors

This timestamp indicates the time when the number of detected bit errors was measured. The value of the timestamp is equal to the NPT / RTP timestamp of the last decoded frame before the number of detected bit errors is measured. If no frames were decoded before such a measurement, the timestamp is set to zero.

Number of corrected bit-errors}

This timestamp indicates when the number of corrected bit errors is measured. The value of the timestamp is equal to the NPT / RTP timestamp of the last decoded frame before the number of corrected bit errors is measured. If no frames were decoded before such a measurement, the timestamp is set to zero.

As can be seen from the timestamp matrix described above, the time or statistic of the event occurrence (damage, rebuffering, initial buffering, loss of consecutive RTP packets) is measured (number of bytes provided to the media decoder, number of detected bit errors, And the number of corrected bits) are substantially positions in the media stream measured at relative media playback time (NPT / RPT timestamps).

The time stamp of the initial buffering time is not specified because the initial buffering occurs only at the beginning of the session, before the start of playback.

According to the reported quality metrics, with the proposed timestamp information, the streaming server can mimic the stream playback or rendering that occurred at the client; As a result, the streaming quality can be sufficiently interpreted.

3 shows a flowchart of a method according to the invention. In step 300, a streaming session is established between the streaming client and the streaming server. At 301, one or more quality metrics are negotiated between the streaming client and the streaming server for use in the quality feedback procedure performed by the streaming client. Both session establishment and negotiation may be based on RTSP or RTCP or SIP combined with SDP. Step 301 may be performed together with step 300. The corresponding timestamp metric may be associated with each quality metric negotiated for the streaming session. In step 302, for example, when a media stream is sent to a streaming client and rendered at the terminal on which the streaming client is set up, substantial streaming begins. During the streaming, in step 303 it is monitored whether quality feedback is requested or not. This can be done, for example, by constantly checking whether any events occur that should be reported to the streaming server according to the negotiated quality metrics. It may be for example a rebuffering event. Alternatively, periodic quality reporting, such as periodic feedback of the number of bytes provided to the media decoder at predetermined time intervals, may have been negotiated. In step 303, both quality feedback and periodic feedback caused by the event occur. If it is determined in step 304 that quality feedback is required, a quality feedback value is determined according to each negotiated quality metric. A corresponding timestamp according to the timestamp metric corresponding to each negotiated quality metric is then determined in step 305. Step 305 may of course be performed the same as before step 304. In either case, the quality feedback value and the corresponding timestamp are reported to the streaming server at step 306, for example via RTSP, RTCP or SIP. After the quality feedback, or if it is determined that no quality feedback is required, it is checked in step 307 whether streaming should be stopped. If this is not the case, then again in step 303 it is checked whether new quality feedback is required.

4 schematically shows the functional components of a system according to the invention. This embodiment refers to a PSS system that controls streaming using RTSP as a representative example. Similarly, SIP also has an additional network instance that recognizes or obtains quality feedback and timestamps sent from client 601 (first party) to server 600 (second party) with a slightly modified underlying protocol stack. It should be noted that together can be used here. The PSS system of FIG. 4 includes a streaming client 601 and a streaming server 600, both of which are capable of running an RTSP, at least one RTSP entity 401, 400. ). RTSP entities 400, 401 utilize services of the underlying protocol layers operated by additional protocol entities, among which TCP / UDP entities 402, 403 and IP entities 404, 405. ) Is only shown. The streaming client 601 is further connected to the streaming quality monitor instance 407. The streaming quality monitor instance monitors the quality of the actual streaming application in relation to the negotiated quality metrics and corresponding timestamp metrics and inputs the monitored quality feedback values into the RTSP entity 401. The streaming quality monitor may be provided by, for example, a terminal on which the streaming client is set. Streaming quality monitor 407 now determines a timestamp according to a timestamp metric corresponding to the quality metric used, and transmits the monitored quality feedback values and the corresponding timestamps via client RTSP 401. To the RTSP peer object of the streaming server 600, where they are entered into the quality data processing instance 406 for evaluation and analysis, e.g. if the rebuffering events are found to be too frequent, the data rate of the streaming application It can be aimed at improving the quality of a streaming application by increasing it, or just using it for statistical quality data collection, billing or other purposes.

The present invention has been described above using the preferred embodiments. It should be apparent to those skilled in the art that other alternative methods and variations may exist and be implemented without departing from the scope and concept of the appended claims. In particular, the invention is in no way limited to the application of 3G wireless communication systems. The present invention can equally be used in all types of wired and wireless data transmission systems with parameter feedback.

Claims (27)

A quality feedback method in a streaming service in which at least one media stream is streamed to a client, Determining 304 a quality feedback value according to at least one quality metric, At least one timestamp when a corresponding timestamp metric is defined for each of the at least one quality metrics and each of the at least one timestamp metrics is based on a relative media playback time of the at least one media stream Determining a timestamp associated with the quality feedback value according to a metric, and Reporting the quality feedback value and the associated timestamp to a server. 2. The method of claim 1, wherein said streaming of said at least one media stream is based on a Real-time Transport Protocol (RTP). 3. The method of claim 2, wherein the relative media playback time is from RTP timestamps provided in a header of at least one protocol data unit of the RTP. 4. The method of any one of claims 1 to 3, wherein the streaming is at least partially controlled by a real-time streaming protocol (RTSP). 5. The method of claim 4, wherein the relative media playback time is derived from normal play time NPT provided by the RTSP. 4. The method of any one of claims 1 to 3, wherein the at least one quality metric defines the quality metric value to be the duration of an event, and the corresponding timestamp metric defines the at least before the event occurs. Defining the timestamp to be the relative media playback time for a particular frame of one media stream. 7. The method of claim 6, wherein the event is a corruption duration and the particular frame is the last good frame in the playback order before the corruption occurs. 7. The method of claim 6, wherein the event is a rebuffering duration, and the specific frame is the last frame played before the rebuffering occurs. 7. The method of claim 6, wherein the event is the number of consecutively lost content packets, and the specific frame is the last received frame in the playback order before generating the consecutive lost packets. 4. The method of any one of claims 1 to 3, wherein the at least one quality metric defines the quality metric value to be event count, and the corresponding timestamp metric is at least one before the event count is measured. Defined as the relative media playback time for a particular frame of two media streams. 11. The method of claim 10 wherein the event count is the number of bytes provided to the media decoder, the number of detected bit errors, or the number of corrected bit errors, and wherein the particular frame is the last decoded frame before the event count is measured. How to. 5. The method of claim 4, wherein the quality feedback value and the associated timestamp are reported to the server (600) via the RTSP (109). The method of claim 1, wherein the streaming is controlled at least in part by a Session Initiation Protocol (SIP). 14. The method of claim 13, wherein the relative media play time is derived from SIP timestamps given in a header of at least one protocol data unit of the SIP. The method of claim 1, wherein the streaming is controlled at least in part by a Real-time Transport Control Protocol (RTCP). 16. The method of claim 15, wherein the relative media playback time is derived from a time base given by the RTCP, in particular RTCP timestamps given in a header of at least one protocol data unit of the RTCP. 17. The method of any of claims 13 to 16, wherein the reported quality feedback value and associated timestamp are obtained by an instance and used to analyze the quality of the streaming. The method of any one of claims 1 to 3, wherein the streaming service is a packet-switched streaming service (PSS) in a 3G mobile communication system. delete A computer-readable storage medium having stored a computer program with instructions operative to cause a processor to perform the steps of the method of claim 1. In the system for quality feedback in streaming service, At least one server, and At least one client, At least one media stream is streamed to the at least one client, a quality feedback value is determined according to at least one quality metric, a timestamp associated with the quality feedback value is correspondingly determined for each of the at least one quality metric and the at least one The quality feedback value and the associated timestamp are reported to the at least one server based on at least one timestamp metric, based on the relative media playback time of the two media streams. In the client at the time of a streaming service, Means for receiving at least one media stream streamed to the client, Means for determining a quality feedback value according to at least one quality metric, For each of the at least one quality metric, a corresponding timestamp metric is defined and at least one timestamp when each of the at least one timestamp metrics is based on a relative media playback time of the at least one media stream Means for determining a timestamp associated with the quality feedback value according to a metric, and Means for reporting the quality feedback value and the associated timestamp to a server. In the server at the time of a streaming service, Means for streaming at least one media stream to a client in a streaming service; And Means for receiving a quality feedback value and an associated timestamp reported by the client to the server, The quality feedback value is determined in accordance with at least one quality metric, and in accordance with at least one timestamp metric correspondingly defined for each of the at least one quality metric and based on the relative media playback time of the at least one media stream. And said timestamp associated with a feedback value is determined. delete delete delete delete

Images