KR101054132B1 - How to Report Quality Metrics for Packet-Switched Streaming - Google Patents

Abstract

A method of reporting quality metrics for packet switched streaming in a wireless network between a server and a client, comprising: transmitting content data from a server to a client using a real-time streaming protocol; Reporting at least one quality metric relating to the server from the client using both an unreliable transport mechanism such as UDP and at least one trusted transport mechanism such as TCP.

Description

Quality metrics reporting method for packet-switched streaming {A METHOD OF REPORTING QUALITY METRICS FOR PACKET SWITCHED STREAMING}

The present invention relates to a method for reporting quality metrics for packet switched streaming, and is particularly suitable for, but not limited to, 3GPP streaming services (PSS).

In general, quality metrics are used for reporting in 3GPP Packet Switched Streaming Services (PSS), where the service provider (server) needs information about the reception quality of the video stream delivered to the client (eg, 3GPP TS26.234). V 5.3.0 Release 5). In order for the server to collect this information, the client must send feedback information about the reception quality to the server. Since the intervening network and the status of the client itself can affect the reception quality of the video stream, this information can only be generated at the client. The reported metrics (e.g., lost during a streaming session) should be measured because information about delivery quality should be measured, not about the quality of the content (e.g., poor quality due to poor encoding of the video). Packet volume) is objective. Since all of the above metrics are not subjective and objective, they can be generated automatically by the client without any interaction with the user.

Packet-switched streaming services in 3GPP networks are based on mechanisms developed for streaming on the wired Internet. Thus, known transport protocols such as RTP / RTCP are used for data transmission (actual streaming), while RTSP is used to control streaming sessions. It has been known that standardized mechanisms are not sufficient in reporting quality metrics for perceived quality at the receiver. For example, the information sent by an RTCP receiver report may be used so that the sender can only obtain basic metrics about the quality of the delivered stream, such as the number of group members, the RTT estimate for the receiver, and the cumulative number of lost packets. Do it. They are not sufficient to notify the server of the quality of streaming to each recipient. For example, the cumulative number of lost packets does not provide accurate information about the lost RTT or which packets were actually received or lost. This fact impedes proper adaptation (rate and quality) and billing schemes by the server, and thus becomes more critical as streaming services become more prevalent. Therefore, an extension mechanism is needed. In summary, there are two major problems with RTCP based quality metric reporting.

The transport protocol used for the RTCP message (usually UDP) is not reliable and therefore cannot reliably determine the quality metric.

The information contained in the RTCP receiver reporting is very limited, giving the operators no degree of freedom to specify their own quality metrics.

A detailed overview of 3GPP PSS and the protocol used above is given in 3GPP TS26.234 V 5.3.0 Release 5. RTCP is an RTP control protocol used to distribute control information for RTP-based data transfers. Two important message types in RTCP are the transmit and receive reports used to exchange information about data transmitted over RTP (eg, the total amount of packets sent by the transmitter). For streaming, i.e. if the RTP session is based on UDP, RTCP data will also be transmitted over UDP. Since UDP is an unreliable protocol, lossless transmission of RTCP data cannot be guaranteed. To avoid RTCP messages consuming too much bandwidth, RTCP send and receive reports can only be sent at predetermined intervals (eg, one receive report every 5 seconds). Thus, the information that can be transmitted through the transmission and reception reports is very limited and may not be sufficient to generate timely useful quality metrics. In particular, RTCP is an exemplary basic metric, supplying RTT measurements from the transmitter to each receiver, delay jitter, cumulative number of packet losses, the highest sequence number received, and packet counts for packets sent by the transmitter.

As mentioned earlier, these metrics are very limited and not scalable, so that new and existing applications (MPEG4 video and AMR audio) are able to set a set of metrics to properly report the reception quality of each receiver. Lacks.

RTSP is a signaling protocol used in PSS and is used to control and establish a streaming session. This allows the client to start or stop the stream and jump to any time position in the stream. In general, RTSP data is transmitted reliably over the TCP protocol. Following the control information, additional information about the data transfer characteristics is exchanged between the server and the client via RTSP. In addition, certain information may be exchanged during the streaming session.

The quality metric defines a particular set of parameters that are reported from the client to the server, and the operator can determine the quality of the stream delivery to the client by the quality metric. There are various ways of using the information obtained by those quality metrics. For example, the charging model may be based on such information, or the operator may only collect the data for his own statistics. To date, there is no known parameter set for all kinds of applications, and it is controversial whether a particular parameter set will meet the needs of all operators in the future. There is clearly a limited set of quality metrics needed in all cases, such as the total amount of lost packets provided by RTCP, an approximate estimate of RTT to the client, and an estimate of delay jitter. However, although there are many application specific parameters, other parameters become important when content encoded in a particular format is streamed.

Since it is not entirely clear how operators use quality metrics, it would be desirable for any kind of application to find a solution that would allow the operators to define their own quality metrics. However, this is outside the scope of the present invention. It is assumed that the challenge of the quality metric on transmissions, what kind of transmissions are required for each parameter, and which peers are responsible for each parameter, is known to the server and client.

In summary, existing methods only allow a limited feasibility for reporting quality metrics from client to server in PSS. This is not enough for the operator to get a detailed and accurate report on the quality of the video stream received at the client.

It is therefore an object of the present invention to provide a method for reporting quality metrics in a PSS that can give additional information to the operator. This object is solved by the method according to claim 1. Preferred embodiments of the method are included in various dependent claims.

The basic idea of the present invention is to combine an unreliable transport mechanism and a reliable transport mechanism to report quality metrics from client to server. For example, unreliable but minimal quality metrics may be obtained from standard RTCP receiver reporting. Since this information is always available, it should be used as the minimum information if no additional information is supplied from the client.

Quality metrics provide a statistical measure of the quality of service. This information can be used for streaming applications such as determining network management, or rate adaptation and proper scheduling of data packets, for example to deliver better quality to clients. This allows the operator to obtain information about the state of the network and take countermeasures if the delivered quality is below a certain level.

Information about the quality delivered may be used for user billing. If the quality metric indicates that a user has received a data stream of a poor quality, the charging rate for the service can be reduced compared to the user receiving the stream at full quality. To do this, because the client must pay for the actual quality experienced, a certain delivery parameter value is needed, such as the total number of I-frames displayed or the number of times the client had to reroute.

The parameters used for the quality metric can be classified into two categories. One group is defined by parameters that are transmitted reliably periodically and the other group is defined by parameters that are transmitted reliably (both during the session or at the end). An example for the first group is the ratio of lost packets to the total number of outgoing packets, while the amount of rebuffering by the client is an example of the second group. In particular, for the second group, it will be important to transmit these data reliably since they will only be transmitted once. The loss of this data is fatal and means that this quality metric is not available on the server. This is different from data such as the number of received packets transmitted periodically. Loss means that the information available at the server is inaccurate until new data containing this information arrives at the server.

The server also has the opportunity to request that certain quality metrics be sent from the client in a reliable manner. This is also useful if data sent without reliability has not reached the server for a longer period of time. This allows the server to obtain information even if the client application is not properly closed (for example, the application crashes). This data may not be up-to-date, but the server has the opportunity to get at least some information.

Other parameters, such as the number of times a client has refurbished or the total time spent buffering, are sent only once but must be sent in a reliable manner. One possibility used herein to illustrate the invention is to transmit these parameters using the RTSP protocol at the end of the streaming session.

In addition to the minimal set of quality metrics, the operator should be able to easily define additional metrics as needed. Therefore, a message format must be available that can cope with both reliable and unreliable transport mechanisms. In the case of RTCP, an Extended Report Block (XR) is used for this. For RTSP, the protocol itself includes intentionally loosely defined methods, such as the GET_PARAMETER and SET_PARAMETER methods, to facilitate the integration of new parameters.

In addition to network operators, content providers may also be interested in quality metrics. This is because they are of great interest in having good quality of streaming and also, if necessary, making the necessary changes, for example, to obtain an appropriate encoding rate. Without the quality metric, the content provider would not be able to provide the appropriate content to the operator.

The invention will be described in more detail with reference to the accompanying drawings.

1 is a typical server client configuration for realizing a method according to the present invention;

2 is a schematic communication diagram illustrating the method of the present invention.

As shown in FIG. 1, a typical system comprising a server and a client includes a wireless communication network operated by an operator. Content to be delivered from the server to the client is supplied in advance or in real time by a content provider connected to the server. In transmitting the content data to the client, the server uses RTP / RTCP. RTP sessions are sent over UDP (unreliable protocol), and RTCP data used to control streaming sessions will also be sent over UDP. The client sends the recipient report by using RTCP messages at predetermined reporting intervals (based on UDP) or by using RTSP on a reliable transport protocol such as TCP.

The method of the present invention employs a synthetic quality metric reporting mechanism that combines reliable and unreliable transmission of quality metrics. Since two delivery methods are available, the client and server need to implement a mechanism to coordinate quality metric transmission. In general, the client actively sends quality metrics to the server. Alternatively, the server actively requests quality metrics from the client, and the client responds with a message containing the requested information.

For unreliable transmissions, existing mechanisms and message formats (RTCP reception and transmission reporting) should be used. The operator may use an extension mechanism such as RTP Extended Reporting XR to enable the transmission of additional quality metrics. This periodic message has the advantage that an operator can obtain a quality metric over time (e.g., 53 packets lost in the first 3 minutes of the streaming session and 33 packets lost in the subsequent 2 minutes).

For reliable transmission, TCP based protocols can be used. One feasible is to use the RTSP already in use in the streaming session.

2 shows an example of reporting a composite quality metric. Periodic and unreliable reports are sent continuously during the streaming session. The server requests a particular quality metric at a particular point in time during the streaming session. The client responds to this request by reliably transmitting the requested information. In addition, at the end of the streaming session, the client reliably sends several quality metrics to the server. This new method allows the operator to obtain the desired quality metric while keeping the additional traffic generated by the report as small as possible.

Mechanisms that allow the server to explicitly request certain quality metrics are particularly useful in the case of wireless networks such as 3GPP. In such networks, higher loss rates are expected than in wired networks, for example in handovers. Thus, the server may not be able to receive periodic and unreliable reports for a long time. With this new mechanism, the server has the opportunity to request this information from the client when it is really needed.

In the following, an example of a quality metric to be transmitted with reliability is described.

Parameters considered to be important are the number of video I-frames or the number of P-frames / B-frames indicated by the client. In addition, the minimum frame rate, average frame rate, and maximum frame rate measured during the duration of the session constitute a more important quality metric. In addition, the number of times a client has refurbished or the length of time the client spends buffering (seconds) is also an important quality metric. Finally, the time length in seconds between the data stream request from the receiver (ie, RTSP “playback”) and the initially rendered data content packet constitutes a parameter representing the total stream setup time. As mentioned previously, all of the above quality parameters should preferably be transmitted reliably through a reliable transmission mechanism such as RTSP at the end of the session.

In addition, examples of parameters for unreliable transmission of quality metrics are described. The parameters mentioned hereinafter may be transmitted using, for example, the RTP extended report block XR mechanism and the message format defined therein.

The first metric is the degree of packet reordering that requires the use of reporting block extensions for RTCP.

Similarly, the minimum, average, or maximum value of consecutively lost content data packets per media channel is a preferred quality metric for unreliable transmission.

In addition, a minimum, average, or maximum packet delay (in milliseconds) may be transmitted.

A typical quality metric is constructed by the last received RTCP sequence number, ie the most recent RTCP sequence number received per media channel. This is useful for determining how far the user has played the data stream. Another example is the cumulative number of successfully received content packets per media channel. Since the receiver reports lost packets, the number of received packets can be determined at the sender side. Similarly, the expected number of content packets per media channel can be derived from the RTCP sender report sent from the server. Finally, packet jitter constitutes the amount of delay variation.

Next, a simple example is used to show how the method according to the invention can be realized. For simplicity of explanation, in this example only five quality metrics are reported. The small metric set is assumed to be already defined by an attribute in the PSS framework, for example "3gpp-video-qos-profile-1". In addition, it is assumed that the method of transmitting each parameter (reliably and unreliably) and the peer making a report or querying the report are also defined by the above attributes. "3gpp-video-qos-profile-1" in this case defines the quality of service QoS metric profile for the video. This is known to the server and the client. For example, if some parameters are not so important for a particular application, the server may move from a reliable transmission to an unreliable transmission, or vice versa. There are several ways to negotiate the correct set of quality metric parameters. An example of the negotiation is shown below.

Through RTSP, quality metric negotiation between client and server will begin as follows (C is client and S is server).

If the server does not support such a set of parameters, it will respond like this.

On the other hand, if the server supports the requested set of parameters, it responds as follows.

The above description indicates that the server supports the requested quality metric reporting profile, and also that quality metric reporting profile is applied to the video session (with payload type value 98).

As noted above, the server may decide to move some parameters from a reliable transmission to an unreliable transmission. In this case, if the server determines that the quality metric of "number of displayed video I-frames or P-frames / B-frames" is not important, this quality metric can be set for unreliable transmission as follows. .

The above description indicates that the server supports the requested quality metric reporting profile, and also that quality metric reporting profile is applied to the video session (with payload type value 98). In this case, the setting for the reliable transmission "number of displayed video I-frames or P-frames / B-frames" is transmitted reliably, because the server also determines that it is more reasonable to do so.

If the negotiation is not successful, the client may decide to request a different quality metric profile or other file, or the server may reliably send what was originally intended to move to an unreliable transmission. It is about implementation and is outside the scope of this document.

For example, assume that three metrics in "3gpp-video-qos-profile-1" are reported periodically from the client to the server through RTCP reporting extensions or other means: average packet delay, maximum packet delay, and packet jitter. . An example of the message format for unreliable reporting using the RTCP reporting extension is shown below.

At the end of the streaming session, the client reliably sends the other two quality metrics (the number of rebuffers and the rebuffer time) via an RTSP SET_PARAMETER message as shown below.

As noted above, in addition to the reports generated automatically from the client, the server may allow the client to reliably transmit one or more quality metrics when needed. This may be the case, for example, when periodic and unreliable reports do not arrive at the server for some time. An example of requiring three delay metrics is shown here.

Claims (25)

A method of reporting quality metrics for packet switched streaming over a wireless network between a server and a client. Transmitting content data from the server to the client over the wireless network using a real time streaming protocol; Reporting from the client to the server at least one first quality metric relating to the transmitted data stream using an unreliable transmission mechanism; Reporting from the client to the server at least one second quality metric relating to the transmitted data stream using a reliable transmission mechanism. Quality metrics reporting method for packet switched streaming comprising a. The method of claim 1, Negotiating between the server and the client which quality metrics are to be reported using a reliable transmission mechanism, The first quality metric and the second quality metric are reported according to the result of the negotiation. How to report quality metrics for packet switched streaming. The method according to claim 1 or 2, The reported first quality metric is repeated periodically How to report quality metrics for packet switched streaming. The method according to claim 1 or 2, The reported first quality metric is transmitted during an ongoing session. How to report quality metrics for packet switched streaming. The method according to claim 1 or 2, The unreliable transport mechanism or the reliable transport mechanism uses RTP Extended Reporting XR. How to report quality metrics for packet switched streaming. The method according to claim 1 or 2, The reported second quality metric is transmitted during or at the end of the session. How to report quality metrics for packet switched streaming. The method according to claim 1 or 2, The reliable transmission mechanism uses a reliable transmission protocol such as TCP. How to report quality metrics for packet switched streaming. The method according to claim 1 or 2, The reported second quality metric is transmitted on request by the server. How to report quality metrics for packet switched streaming. The method according to claim 1 or 2, The reported second quality metric is the number of I-frames or number of P-frames indicated by the client. How to report quality metrics for packet switched streaming. The method according to claim 1 or 2, The reported second quality metric is at least one of the minimum, average, or maximum video frame rate measured during the duration of the session. How to report quality metrics for packet switched streaming. The method according to claim 1 or 2, The reported second quality metric is the number of times the client rerogate data. How to report quality metrics for packet switched streaming. The method according to claim 1 or 2, The reported second quality metric is the length of time the client spent in buffering How to report quality metrics for packet switched streaming. The method according to claim 1 or 2, The reported second quality metric is the length of time between the stream request from the client and the first data packet indicated by the client. How to report quality metrics for packet switched streaming. The method of claim 9, The reliable transmission mechanism or the unreliable transmission mechanism uses an RTSP protocol. How to report quality metrics for packet switched streaming. The method according to claim 1 or 2, The reported first quality metric is the degree of packet reordering. How to report quality metrics for packet switched streaming. The method according to claim 1 or 2, The reported first quality metric is the most recently received sequence number. How to report quality metrics for packet switched streaming. The method according to claim 1 or 2, The reported first quality metric is the number of successfully received content packets How to report quality metrics for packet switched streaming. The method according to claim 1 or 2, The reported first quality metric is the number of predicted content packets or the number of lost content packets. How to report quality metrics for packet switched streaming. The method according to claim 1 or 2, The reported first quality metric is at least one of a minimum, average, or maximum value of consecutively lost content data packets. How to report quality metrics for packet switched streaming. The method according to claim 1 or 2, The reported first quality metric is at least one of a minimum, average, or maximum value of packet delay. How to report quality metrics for packet switched streaming. The method according to claim 1 or 2, The reported first quality metric is packet jitter How to report quality metrics for packet switched streaming. The method according to claim 1 or 2, If the quality metric to be transmitted using the unreliable transmission mechanism has not been received for a predetermined period of time, the server requests the transmission of the quality metric using the reliable transmission mechanism from the client. How to report quality metrics for packet switched streaming. The method according to claim 1 or 2, The server moves at least one quality metric from a reliable transmission to an unreliable transmission and vice versa. How to report quality metrics for packet switched streaming. A client that reports quality metrics for packet switched streaming over a wireless network between a server and a client. Receiving means for receiving content data from the server through the wireless network using a real time streaming protocol; Report at least one quality metric for the transmitted data stream to the server using an unreliable transport mechanism and report at least one quality metric for the transmitted data stream using at least one reliable transport mechanism. Transmission means reporting to the server Client that includes. A server that receives quality metrics for packet switched streaming over a wireless network between a server and a client. Transmission means for transmitting content data to the client via the wireless network using a real time streaming protocol; Receive at least one first quality metric regarding the transmitted data stream from the client using an unreliable transmission mechanism and at least one second quality metric relating to the transmitted data stream using the reliable transmission mechanism. Receiving means for receiving from the client Server containing.

Images