WO2013029214A1

WO2013029214A1 - Video quality monitor and method for determining a network video quality measure in a communication network

Info

Publication number: WO2013029214A1
Application number: PCT/CN2011/078966
Authority: WO
Inventors: Martin Adams; Dan Jurca; Renaud Cuny; Sergio BAKER
Original assignee: Huawei Technologies Co., Ltd.
Priority date: 2011-08-26
Filing date: 2011-08-26
Publication date: 2013-03-07

Abstract

The invention relates to a video quality monitor (101) for determining a network video quality measure (O) for a plurality of video clients (103_ 1,..., 103_N) in a communication network (115), each video client (103_1,..., 103_N) employing a video buffer for buffering video information receivable over the communication network (115). The video quality monitor (101 ) comprises: a data interface (107) configured to capture network data packets (113) comprising video information, the data interface (107) being configured to determine a network rate r(t) and a video playback rate v(t) from the captured network data packets (113); and a processor (111) being configured to emulate a storage capacity behavior of a set of video buffers to determine a set of video quality measures, each video quality measure being associated with a video buffer, each video buffer being associated with a probability of appearance in the communication network (115), the processor (111) being further configured to assign a probability of appearance of a respective video buffer to an associated video quality measure to obtain a statistical distribution of the video quality measures in the communication network (115), the statistical distribution of the video quality measures forming the network video quality measure (O).

Description

DESCRIPTION

Video Quality Monitor and Method for determining a network video quality measure in a communication network

BACKGROUND OF THE INVENTION

The present invention relates to a video quality monitor and a method for determining a network video quality measure for a plurality of video clients in a communication network.

Video streaming or progressive download is a popular application within the Internet. A video streaming client connected via an ISP (Internet Service Provider); e.g. a mobile or fixed operator, requests a streaming server, located somewhere within the ISP network or outside in the Internet, to send a video stream. One of the protocols that can be used is HTTP over TCP/IP. In contrast to accessing a web page or to traditional video downloading, the video client starts displaying the content of the requested file before the entire source file has been downloaded successfully by the client.

Video content transmission in IP networks is affected by the transport

characteristics of the underlying transmission networks, such as bandwidth, delay, jitter and packet loss. The end user perception will be impaired by initial buffering, i.e. the time from the request until the playback of the video file will start, but also from video stalling during the playback followed by re-buffering as soon as the receive buffer in the client application has drained completely and no further content is available. This is usually the case when the provided average bandwidth by the transport network is lower than the video stream bit rate. A buffer emulator inside the monitoring system is required that calculates the buffer level and provides further information about the re-buffering characteristics. The results computed by the buffer emulator greatly depend on the input parameters to the model. While the instantaneous rate of the network, r(t), can be computed/estimated by observing the traffic of the session, and the video playback rate, v(t), can be obtained by DPI on some of the packets from the media file, the buffer size value, b, is an unknown parameter, which must be guessed. This parameter is intrinsic to the video player used by the user, and is not transmitted through the network during the video streaming session. Hence it cannot be discovered by the monitoring system. Moreover, different players can have different values for the buffer size parameter. An error in the estimation of this parameter in the buffer emulator, will lead to erroneous computations and results produced by the monitoring system. Such an error will lead to an erroneous interpretation of the user experienced quality by the network operator, and will render the monitoring system useless. SUMMARY OF THE INVENTION

It is the object of the invention to provide a concept for video session monitoring which is robust against erroneous buffer size parameter prediction. This object is achieved by the features of the independent claims. Further implementation forms are apparent from the dependent claims, the description and the figures.

The invention is based on the finding that associating reliability information to the information on the buffer size improves the robustness of the monitoring system. For each information on the buffer size, which the monitoring system receives, it can produce a measure for the Quality of Experience (QoE) which the user perceives and it can provide the network operator with a reliability for that QoE measure. The monitoring system may compute different buffer models based on different buffer sizes by using the information on the buffer size and the associated reliability information in order to provide a highly accurate buffer model of the receive buffer in the video client. By combining these different possibilities for the buffer sizes in the video client, wherein the different possible buffer sizes are weighted by their associated reliability information or probabilities, the buffer model becomes a stochastic buffer model which is non-sensitive or at least less sensitive to erroneous buffer size parameter prediction. The statistical distribution of video quality measures derived from the individual buffer models in the communication network forms a network video quality measure. Video session monitoring becomes robust against errors in the assumed buffer size. Thus, a concept for video session monitoring which is robust against erroneous buffer size parameter prediction can be provided.

In order to describe the invention in detail, the following terms, abbreviations and notations will be used: Buffer size b: represents the minimum amount of video information in seconds to be buffered at the client player before the video file starts displaying on the user device screen, r(t): represents the instantaneous network rate allocated by the transport network to a video session for transmitting the network packets comprising the video information related to the respective video session . Equivalent terms are: network packet rate, network video packet rate, network rate, instantaneous network rate, session rate, instantaneous session rate, v(t): represents the rate at which the received and buffered network packets comprising video information related to the video session, in short also referred to as video packets, must be decoded by the video player in order to ensure continuous playback of the video on the user screen. This value characterizes an encoded video stream and is set during the encoding process. Equivalent terms are: video rate, video bitrate, video playback rate, video consumption rate or video encoding rate, i.e. the rate at which the video was source encoded, DPI: deep packet inspection - is a method to inspect network packets and extract relevant information from the packet payload, SPI: Shallow Packet Inspection - is a method to inspect network packets and extract relevant information from the packet headers, up to application layer protocol headers,

OSI model: Open Systems Interconnection model,

L2: any generic layer 2 communication protocol in the OSI model,

L1 : any generic layer 1 communication protocol in the OSI model, KPI: Key Performance Indicator. KPI is a term for a type of measure of

performance. KPIs give a good understanding of what is important for the network service provider,

KQI: Key Quality Indicator. KQI is a term for a type of measure of quality. KQIs provide an overview of the network quality to the network service provider,

MOS: Mean Opinion Score. MOS provides a numerical indication of the perceived quality of received media after transmission, CDR: Call Data Record, CDR is a record containing details of a session, xDR: Extended Data Record. xDR is a record containing details of a session,

TCP: Transmission Control Protocol. TCP is one of the core protocols of the Internet Protocol Suite. TCP is one of the two original components of the suite, complementing the Internet Protocol (IP), and therefore the entire suite is commonly referred to as TCP/IP. TCP provides reliable, ordered delivery of a stream of bytes from a program on one computer to another program on another computer, TCP FIN/ACK: sequence of TCP messages to signal the end of a TCP session,

TCP RST: Reset message sent by TCP to end a TCP session,

HTTP: Hypertext Transfer Protocol. HTTP is a networking protocol for distributed, collaborative, hypermedia information systems. HTTP is the foundation of data communication for the World Wide Web,

IP: Internet Protocol. The Internet Protocol is the principal communications protocol used for relaying datagrams, i.e. data packets, across a data network using the Internet Protocol Suite. IP is responsible for routing packets across network boundaries, it is the primary protocol that establishes the Internet. IP has the task of delivering datagrams from the source host to the destination host solely based on their addresses. For this purpose, IP defines addressing methods and structures for datagram encapsulation,

Data network or simply referred to as a network, is a collection of computers and devices interconnected by communications channels that facilitate

communications and allows sharing of resources and information among interconnected devices,

Service: a service is a mechanism to enable access to one or more capabilities, where the access is provided using a prescribed interface and is exercised consistent with constraints and policies as specified by the service description; a service in a data network refers to a set of related software or hardware

functionalities, together with the policies that should control its usage, Session: a session is a semi-permanent interactive information interchange, also known as a dialogue, a conversation or a meeting, between two or more communicating devices, or between a computer and a user. A session is set up or established at a certain point in time, and torn down at a later point in time. An established communication session may involve more than one message in each direction. A session is typically, but not always, stateful, meaning that at least one of the communicating parts needs to save information about the session history in order to be able to communicate, as opposed to stateless communication, where the communication consists of independent requests with responses,

Segment: a segment is a group of sessions,

Video server: a video server is a computer based device, also called a 'host', dedicated to delivering video,

Client, video client: a client is an application, a system or a device that accesses a remote service on another computer system, known as a server, by way of a network. A video client is a client dedicated to accessing a video service on a video server, alternatively, the client is an application, a system or a device for a peer-to-peer application, e.g. a video client for a video conference application,

RTP: Real-Time Transport Protocol,

RTCP: Real-Time Transport Control Protocol,

API: Application Programming Interface,

MT: Monitoring tool,

NP: Network Probe, SA: Software Agent,

OCRF: Outcome computation and reporting function. According to a first aspect, the invention relates to a video quality monitor for determining a network video quality measure for a plurality of video clients in a communication network, each video client employing a video buffer for buffering video information receivable over the communication network, the quality monitor comprising: a data interface configured to capture network data packets. The network data packets comprise video information of a video session or video stream and may be formed by video packets of a video packet stream. The data interface is configured to determine a network rate r(t) and a video playback rate v(t) from the captured network data packets; and a processor being configured to emulate a storage capacity behavior of a set of video buffers to determine a set of video quality measures, each video quality measure being associated with a video buffer of the set of video buffers, each video buffer being associated with a probability of appearance in the communication network, the processor being further configured to assign a probability of appearance of a respective video buffer to an associated video quality measure to obtain a statistical distribution of the video quality measures in the communication network, the statistical distribution of the video quality measures forming the network video quality measure.

By applying this video quality monitor, the monitoring will be robust against erroneous predictions of buffer sizes and hence erroneous result reporting, and also against changes of buffer size values by service providers. Associating video buffers with their probability of appearance in the communication network offers the network operator a larger view of the performance of video services in his network, and helps him improve its operations. The video quality monitor offers the network operator the flexibility to configure the monitoring process, and to use the video qualification and monitoring solution for specialised test cases that are important to the operator.

The data interface captures network data packets. A network data packet may correspond to a video packet, it may also correspond to other data packets being transmitted over the communication network. The network rate r(t) is a rate offered by the communication network to a video session initiated by the video client and the video playback rate v(t) is a rate at which video packets of the video session are consumed by the video client. The storage capacity or buffer size may depend on the network rate r(t) computed by following messages between the video clients and a video server and the storage capacity may depend on the video rate v(t) captured from metadata of packets, in particular of first packets, of the video file. The data interface may retrieve the video rate v(t) by DPI on the packets of the video session.

Referring, for example, to a video stream provided by a video server to a video client in a video session, the buffer size of the video client may be different for different video clients or different instances of a video client. The buffer size may, for example, depend on the video playback rate v(t), which corresponds to the rate at which the video of the video stream was source encoded, and/or to the network rate r(t). The video client may be implemented to adapt the buffer size dependent on the video playback rate v(t), which corresponds to the rate at which the video of the video stream was source encoded, and/or to the network rate r(t). The video client may be adapted to apply a first buffer size for a first video playback rate v(t), a first network rate r(t) or to a first combination of a video playback rate and a network rate. The video client may be adapted to apply a second buffer size for a second video playback rate v(t), which is different to the first video playback rate, for a second network rate r(t), which is different to the first network rate, or to a second combination of a video playback rate and a network rate, which is different to the first combination of a video playback rate and a network rate. The video client may be implemented to use a smaller buffer size for a video stream with a smaller video playback rate and/or in case of a smaller network rate and to use a higher buffer size for a larger video playback rate and/or a higher network rate. The same applies for video clients for video conferences. By emulating the storage capacity behaviour of different buffers, or in other words the storage capacity behaviour respectively buffer behaviour of buffers with different buffer sizes, and assigning corresponding probability values to the respective buffers, which may also be referred to as buffer instances, a more detailed and more reliable assessment of the user perceived quality for a video stream can be obtained. Implementation forms of the first aspect may emulate the storage behaviour of buffers with different buffer sizes for the same video and the same video playback rate, thus reflecting the different user perceived qualities caused by different network rates and/or different buffer sizes. In a first possible implementation form of the video quality monitor according to the first aspect, the data interface is configured to receive feedback information indicating a video quality measure from a video client.

By receiving feedback information on the video quality measure, the video quality monitor may adapt the assigned probabilities of appearances to the received feedback information in order to improve the storage emulation. By receiving feedback information from one video client, the video quality monitor is able to also improve the accuracy of storage capacity emulations of other video clients which have similar video buffer characteristics.

In a second possible implementation form of the video quality monitor according to the first aspect as such or according to any of the preceding implementation forms of the first aspect, the video quality measure indicates at least one of: a set of stalls, a duration of stalls, an average set of stalls per session, an average stall duration per session, a time to stall start and a combination thereof. In a third possible implementation form of the video quality monitor according to the first aspect as such or according to the first or second implementation form of the first aspect, the data interface is configured to transmit a request towards a video client from the plurality of video clients over the communication network, the request requesting a transmission of feedback information indicating the video quality measure towards the video quality monitor (101 ).

The network operator is able to find out about the direct perception of the user and to match the emulation of the storage capacity associated to that user with the user's real perception. Thus, the network operator can improve the accuracy of his model by using user feedback.

In a fourth possible implementation form of the video quality monitor according to the first aspect as such or according to any of the preceding implementation forms of the first aspect, the processor is configured to associate either a first video buffer of the set of video buffers being associated with a first probability of appearance or a second video buffer of the set of video buffers being associated with a second probability of appearance to the video quality measure, and to adapt the first probability of appearance if the video quality measure is assigned to the first video buffer, or to adapt the second probability of appearance if the video quality measure is assigned to the second video buffer.

The network operator is able to find out about the perception of the user and to directly measure the user's quality of experience. The probabilities of appearance may be matched according to the feedback information indicating the satisfaction of the user with the video session and indirectly with the emulation of the storage capacity behavior.

In a fifth possible implementation form of the video quality monitor according to the first aspect as such or according to any of the preceding implementation forms of the first aspect, the processor (1 1 1 ) is configured to emulate the storage capacity behavior of each video buffer from the set of video buffers using a set of possible buffer sizes B=(bi, b2, ...,bi,...,b_n) and a set of probabilities of appearance

P=(pi,p₂, ...,Pi, ...,p_n) associated to the set of possible buffer sizes B. Associating a set of probabilities of appearance P=(pi,p₂, ...,Pi, ...,p_n) to a set of possible buffer sizes

...,bi, ...,b_n) means that a value p, from P is associated to a value b, from B, for all i from 1 to n.

Emulating the storage capacity by individual buffer sizes is close to the buffer model of a client terminal. The client allocates a specific amount of memory from the available local memory for storing the video session before playback. A buffer size can exactly describe the amount of memory allocated by the client. As one client may allocate different memories for different video connections, where the allocated memories may vary depending on the video resolution or available storage capacity in the client, or different clients may allocate different memory sizes depending on their configuration information, using probabilities of

appearances for the possible buffer sizes are the optimal strategy for dealing with a lot of different client environments. The video quality monitor considers each client environment and weights its occurrence with a client-dependent probability of appearance.

In a sixth possible implementation form of the video quality monitor according to the first aspect as such or according to any of the preceding implementation forms of the first aspect, the processor (11 1 ) is configured to emulate the storage capacity behavior of the respective video buffer using the network rate, the video playback rate and a buffer emulator model.

The data interface determines the network rate r(t) and the video playback rate v(t) from the captured video packets The data interface may use deep packet inspection to acquire precise information on the video playback rate v(t). The network rate r(t) can be computed by observing the size and number of the video packets that go through the network on a given time interval. When having acquired both rates, a buffer emulator model can be derived describing the inflow of video packets into the buffer by the network rate r(t) and the outflow of video packets from the buffer by the video playback rate v(t). As both rates are available, the buffer model may accurately describe the physical buffer in the client. A leaky bucket buffer model may be used for example.

The buffer emulator mechanism is configured for increased robustness of the computed outcomes against erroneous buffer size parameter estimation. The buffer emulator computes the video experience of the user, i.e. initial buffering time, number of re-bufferings and duration of re-bufferings, for a series of buffer size values.

In a seventh possible implementation form of the video quality monitor according to the sixth implementation form of the first aspect, the buffer emulator model comprises a plurality of buffer emulator instances, each of the buffer emulator instances emulating a different storage capacity behavior for different buffer sizes of video buffers. The buffer emulator mechanism is configured for increased robustness of the computed outcomes against erroneous buffer size parameter estimation. The buffer emulator computes the video experience of the user, i.e. initial buffering time, number of re-bufferings and duration of re-bufferings, for a series of buffer size values. Given a set of possible values for the buffer size parameter b, the model computes one quality outcome for each value. Furthermore, the model can attach a certain probability for each value in the set of values for the buffer size parameter. The probability values and the buffer size values can be adjusted through processing of user feedback. The displayed result can either contain all outcomes, one for each buffer parameter value, and/or an average value computed from the probabilities attached to the buffer size values and the associated outcome. In an eight possible implementation form of the video quality monitor according to the seventh implementation form of the first aspect, each of the buffer emulator instances are provided to respectively determine an individual video quality measure related to the corresponding buffer emulator instance.

By using individual quality measures, the behavior of a terminal opening different players for different sessions which players may have different buffer sizes may be monitored by the network operator.

In a ninth possible implementation form of the video quality monitor according to the eighth implementation form of the first aspect, the processor is configured to average over the individual video quality measures Oi ,Oi,O_n and to determine the network video quality measure O based on the averaged individual quality measures Οι,0,,Ο_η.

By averaging the individual video quality measures, the network video quality measure has a higher significance, as it is determined by using a broader data basis.

In a tenth possible implementation form of the video quality monitor according to the first aspect as such or according to any of the preceding implementation forms of the first aspect, the processor is configured to determine the network video quality measure as one or a combination of a set of the individual video quality measures 0=(Oi ,02, ... ,Ο,, ... ,O_n), a set of the individual video quality measures together with their associated probabilities of appearance

O=(Oi ,pi,O2,P2,- - ,Oi,pi...,On,Pn) and an average value computed by accumulation of the individual video quality measures weighted with their associated

probabilities of appearance, in particular weighted according to the following formula O=(Oipi+O₂p2⁺- - -⁺OiPi+...+O_nPn)- By forming combinations or average values of the individual video quality measures, the informative value of the video quality measure is improved.

In an eleventh possible implementation form of the video quality monitor according to the first aspect as such or according to any of the preceding implementation forms of the first aspect, the processor is configured to organize the network video quality measure as an extended data record xDR and to transmit the extended data record xDR towards the communication network, in particular towards a monitoring device (201 ) in the communication network.

By using an extended data record, all information about the video session is available in a single record. The network operator is provided with clearly arranged information in order to efficiently check a huge number of video sessions. In a twelfth possible implementation form of the video quality monitor according to the first aspect as such or according to any of the previous implementation forms of the first aspect, the video quality monitor is formed as terminal agent software (301 ), the terminal agent software (301 ) being executable in an end user device or as a network probe (303) on a network interface.

The video quality monitor may be flexibly applied to the application of interest. The same device may be implemented in hardware or in software.

In a thirteenth possible implementation form of the video quality monitor according to the first aspect as such or according to any of the preceding implementation forms of the first aspect, the data interface is configured to capture data packets of an HTTP video streaming session or data packets of an RTP video streaming session. The video quality monitor can be implemented in HTTP/RTP video streaming monitoring systems and is appropriate for both terminal based passive monitoring systems for HTTP/RTP video streaming, as well as for network based passive monitoring systems for the same service. The video quality monitor can also be applied in HTTP/RTP video streaming passive monitoring systems for both fixed and mobile networks.

In a fourteenth possible implementation form of the video quality monitor according to the first aspect as such or according to any of the preceding implementation forms of the first aspect, the data interface is configured to transmit a control signal towards a remote video server transmitting the network data packets, the control signal indicating to reduce or to increase the video playback rate in dependence on the network video quality measure.

If the network video quality measure exceeds an upper threshold, the video session has a high quality which allows the user to receive packets with a higher video playback rate. In such a situation, the control signal indicates the remote video server to increase the video playback rate. If the network video quality measure drops below a lower threshold, the video session has a poor quality and the user will not be able to receive packets with the currently received video playback rate. In such a situation, the control signal indicates the remote video server to reduce the video playback rate. The control signal can indicate a reduction or increase depending on a number of stalls. When the number of stalls is above an upper limit, the control signal may indicate the remote video server to reduce the video playback rate. When the number of stalls falls below a lower limit, the control signal may indicate the remote video server to increase the video playback rate.

The video quality monitor is able to influence the remote video server in order to avoid overflows or underflows of the physical buffer in the video client. As far as the emulated storage capacity matches or nearly matches the storage capacity of the video client, the remote video server can be efficiently controlled by the video quality monitor. As such a control is commonly not allowed for the video client, it is allowed for the video quality monitor which is a certified network element.

According to a second aspect, the invention relates to a video quality monitoring method for determining a network video quality measure for a plurality of video clients in a communication network, each video client employing a video buffer for buffering video information receivable over the communication network, the video quality monitoring method comprising: capturing network data packets comprising video information, the data interface being configured to determine a network rate and a video playback rate from the captured network data packets; and emulating a storage capacity behavior of a set of video buffers to determine the set of video quality measures, each video quality measure being associated with a video buffer, each video buffer being associated with a probability of appearance in the communication network; and assigning a probability of appearance of a respective video buffer to an associated video quality measure to obtain a statistical distribution of the video quality measures in the communication network, the statistical distribution of the video quality measures forming the network video quality measure. By applying this video quality monitoring method, the monitoring will be robust against erroneous predictions of buffer sizes and hence erroneous result reporting, and also against changes of buffer size values by service providers. Associating video buffers with their probability of appearance in the communication network offers the network operator a larger view of the performance of video services in his network, and helps him improve its operations. The video quality monitor offers the network operator the flexibility to configure the monitoring process, and to use the video qualification and monitoring solution for test cases that seem interesting to him. The explanations for the first aspect and its implementation forms apply equally for the second aspect and its implementation forms. According to a third aspect, the invention relates to a computer program having a program code for executing the video quality monitoring method according to the second aspect when the computer program is run on a computer.

The explanations for the first and second aspect and their implementation forms apply equally for the third aspect and its implementation forms.

According to a fourth aspect, the invention relates to a computer program product comprising the computer program according to the third aspect.

The explanations for the third aspect and its implementation forms apply equally for the fourth aspect and its implementation forms. According to a fifth aspect, the invention relates to a video quality monitoring system comprising the video quality monitor according to the first aspect as such or according to any of the preceding implementation forms of the first aspect, a plurality of video clients and at least one video server, wherein the plurality of video clients are configured to initiate video sessions with the at least one video server; and wherein the video quality monitor is configured to determine a network video quality measure for the plurality of video clients.

The explanations for the first to fourth aspect and their implementation forms apply equally for the fifth aspect and its implementation forms.

Traditional monitoring systems for HTTP/RTP video streaming are only capable of displaying one quality result based on one buffer size value. If the assumed buffer size value is wrong, the quality result will be wrong too. Video quality monitoring systems according to the fifth aspect allow computing a set of quality results, given a set of input buffer size values. This will increase the robustness of the video quality monitoring system when the buffer size parameter is uncertain, and allows offering a probabilistic result, when a set of probabilities is attached to the set of buffer size values. The result is achieved by performing parallel computations, one for each buffer value, on the same monitored session. This allows the flexibility for the network operator utilizing this monitoring system to choose the desired outcome, to configure the initial set of buffer values and their attached probabilities, and to modify these values according to the monitoring scope.

A network operator who offers its own video services and their custom player can use the video quality monitoring system according to the fifth aspect to verify the quality of the streamed videos for different values of the buffer in the player. Based on the monitored results, he can optimize the player parameters. The network operator can use the same video quality monitoring system to monitor streaming sessions coming from different video service providers who utilize different players with different buffer sizes. In this case, the network operator can program the video quality monitoring system with the various buffer sizes, and correlate the results obtained to the results of the service provider acting in a monitored session. The network operator can monitor the quality of the streaming sessions in his network for different buffer sizes of a player, and make a recommendation for the optimal buffer size for streaming applications running through his network.

According to a sixth aspect, which may be a further implementation form of the previous aspects and their implementation forms, the invention relates to a passive monitoring system for HTTP or RTP video streaming services which utilizes a buffer emulator in order to compute quality indicators for the session, as perceived by the client, wherein: the buffer emulator takes as input video session information, in particular a video bitstream rate;

the buffer emulator takes as input network information during the session, in particular a network instantaneous rate available to a session of the video streaming services; - the buffer emulator takes as input a set of one or more buffer size values;

- the buffer emulator performs separate, e.g. parallel, computations of session quality indicators, one for each buffer size value in the set of buffer size values

- the buffer emulator reports the obtained session quality indicators which comprise a number of video stalls during one session, a duration of the video stalls, an initial buffering time, a start time of a video stall. In a first possible implementation form of the passive monitoring system according to the sixth aspect, the buffer emulator takes as additional input a set of probabilities attached to the set of buffer values, one probability value for each buffer value. In a second possible implementation form of the passive monitoring system according to the sixth aspect, the reporting of the buffer emulator comprises a set of quality indicators, one for each buffer value in the set of buffer size values.

In a third possible implementation form of the passive monitoring system according to the sixth aspect as such or according to the first implementation form of the sixth aspect, the reporting of the buffer emulator comprises a set of pairs comprising a quality indicator and a probability value, with one pair for each buffer value in the set of buffer size values. In a fourth possible implementation form of the passive monitoring system according to the sixth aspect as such or according to the first implementation form of the sixth aspect, the reporting of the buffer emulator comprises an average quality indicator, computed over the quality indicators and the associated buffer values probabilities. In a fifth possible implementation form of the passive monitoring system according to the sixth aspect as such or according to the first implementation form of the sixth aspect, the reporting of the buffer emulator comprises a set of pairs comprising a quality indicator and a probability value, together with an average quality indicator, obtained over the set of pairs.

In a sixth possible implementation form of the passive monitoring system according to the sixth aspect as such or according to any of the previous implementation forms of the sixth aspect, the passive monitoring system is applied to fixed or mobile networks.

In a seventh possible implementation form of the passive monitoring system according to the sixth aspect as such or according to any of the previous implementation forms of the sixth aspect, the passive monitoring system is deployed as a terminal agent software in the end user device, or as a network probe on a network interface.

In an eighth possible implementation form of the passive monitoring system according to the sixth aspect as such or according to the first implementation form of the sixth aspect, the sets of buffer size values and probabilities are computed based on user feedback.

In a ninth possible implementation form of the passive monitoring system according the eighth implementation form of the sixth aspect, the user feedback comprises one quality value for the video session which gets correlated to one quality value from the buffer emulator report, thus identifying a probable buffer value for the given session.

In a tenth possible implementation form of the passive monitoring system according to the eighth implementation form of the sixth aspect or according to the ninth implementation form of the sixth aspect, the probable buffer value is used to update the set of buffer values and the probability set.

In an eleventh possible implementation form of the passive monitoring system according to the eighth, ninth or tenth implementation forms of the sixth aspect, the newly computed sets for buffer values and probabilities are updated into the buffer emulator for further use in video session monitoring.

According to a seventh aspect, the invention relates to a buffer emulator configured to emulate a buffer of a video client, wherein

- the buffer emulator takes as input from a monitoring tool, a set of initial buffer size parameter values: B=(bi, b2,...b,,...);

- for each value b, in B, the buffer emulator receives from the monitoring tool one attached probability p,, of a set of probabilities P = (pi, P2, ...,ρ,,...), wherein a sum of all probabilities in the set P equals 1 ;

- for each buffer size value b, in B, the buffer emulator starts the monitoring process for a given video session, taking as input a network instantaneous rate, video parameters and the buffer size b,;

- for each monitoring process, the buffer emulator produces one outcome: O,

= O(bi) = {Initial Buffer time, Nr of Video freezes, Duration of each video freeze}.

The buffer emulator mechanism provides an increased robustness of the computed outcomes against erroneous buffer size parameter estimation. The buffer emulator computes the video experience of the user, i.e. initial buffering time, number of re-bufferings and duration of re-bufferings, for a series or set of buffer size values. Given a set of possible values for the buffer size parameter b, the model computes one quality outcome for each value. Furthermore, the model can attach a certain probability for each value in the set of values for the buffer size parameter. The probability values and the buffer size values can be adjusted through processing of user feedback. The displayed result can either contain all outcomes, one for each buffer parameter value, and/or an average value computed from the probabilities attached to the buffer size values and the associated outcome.

In a first possible implementation form of the buffer emulator according to the seventh aspect, the buffer emulator outputs towards the monitoring tool the set of outcomes, with the probabilities attached O = {(Oi,pi ),(02,P2),■■■}■ In a second possible implementation form of the buffer emulator according to the seventh aspect, the buffer emulator outputs the average outcome computed from the individual outcomes O,, and the attached probabilities p,.

In a third possible implementation form of the buffer emulator according to the seventh aspect, a monitoring tool correlates the results with the outcome of the buffer emulator upon reception of user feedback and estimates the real buffer size for that session

In a fourth possible implementation form of the buffer emulator according to the seventh aspect, the monitoring tool updates the buffer size value set, and the attached probability set, and updates the buffer emulator with the new values based on the real buffer size of that session.

The data network can for example be a network used for transmission in wireless networks, in particular in GSM/UMTS/LTE cellular networks and WLAN. According to an alternative implementation form, the data network is a network used for transmission in wired networks, operating in a circuit-switched or packet-switched manner. According to an implementation form, the data network is IP-based, ATM- based or TDM-based. According to an implementation form, the data network is an XDSL network. According to an implementation form, the data network is an optical data network. According to an implementation form, the data network is an electrical data network. According to an implementation form, the data network provides optical and electrical transmission.

The invention can be implemented in digital electronic circuitry, or in computer hardware, firmware, software, or in combinations thereof.

BRIEF DESCRIPTION OF THE DRAWINGS

Further embodiments of the invention will be described with respect to the following figures, in which:

Fig. 1 shows a block diagram of a video quality monitor according to an implementation form; Fig. 2 shows a block diagram of a video quality monitor according to an implementation form;

Fig. 3 shows a block diagram of a video quality monitoring method for determining a network video quality measure in a communication network according to an implementation form;

Fig. 4 shows a block diagram of a video quality monitor according to an implementation form; Fig. 5 shows a block diagram of a buffer emulator according to an implementation form;

Fig. 6 shows an equation system according to a leaky bucket principle for calculating performance indicators using a buffer emulator according to an implementation form. Fig. 7 shows a graph of a video session modeled by a buffer emulator accord an implementation form;

Fig. 8 shows two graphs of one and the same video session modeled by a buffer emulator emulating the buffer based on different buffer sizes according to an implementation form;

Fig. 9 shows a block diagram of a video quality monitor according to an implementation form;

Fig. 10 shows a block diagram of a video quality monitoring system according to an implementation form;

Fig. 1 1 shows a block diagram of a computer program according to an

implementation form;

Fig. 12 shows a block diagram of a computer program according to an

implementation form. DETAILED DESCRIPTION OF EMBODIMENTS OF THE INVENTION

Fig. 1 shows a block diagram of a video quality monitor 101 for determining a network video quality measure O for a plurality of video clients 103 1 , ... , 103_N in a communication network 1 15 according to an implementation form. The video quality monitor 101 comprises a data interface 107 to capture network data packets 1 13, the network data packets 113 comprising video information of a video session, e.g. a video stream. When a video session is initialized between one of the video clients 103 1 , ... , 103_N, e.g. a video client 103, and a video server 105, the network data packets 1 13 comprise video session initiation packets which are sent between the video client 103 and the video server 105 in order to initialize a video session. When the video session is set up, the network packets are formed by video packets, i.e. data packets including the video content of a video file. The network data packets may also include other types of packets. The data interface 107 determines a network rate r(t) and a video playback rate v(t) from the captured network data packets. The network rate r(t) is a rate offered by the communication network 1 15 to the video session and the video playback rate v(t) is a rate at which video packets of the video session are consumed by the video client 103. The video quality monitor 101 comprises a processor 1 1 1 to emulate a storage capacity behavior of a set of video buffers to determine a set of video quality measures, each video quality measure being associated with a video buffer, each video buffer being associated with a probability of appearance in the communication network. The processor 1 11 is further configured to assign a probability of appearance of a respective video buffer to an associated video quality measure to obtain a statistical distribution of the video quality measures in the communication network 1 15, the statistical distribution of the video quality measures forming the network video quality measure O.

Fig. 2 shows a block diagram of a video quality monitor 101 according to an implementation form. The video quality monitor 101 corresponds to the video quality monitor 101 described with respect to Fig. 1 , wherein the data interface 107 is further configured to send a request, e.g. a questionnaire, 21 1 about a video session between a video client 103 and a video server 105 to the video client 103 and to receive feedback information 213 with respect to the questionnaire 211 from the video client 103. The video quality monitor 101 provides information on a buffer size B of a buffer in the video client 103 based on the feedback information 213 and the video quality monitor 101 determines associated reliability information P indicating a reliability of the information on the buffer size B based on the feedback information 213.

According to an implementation form, the video quality monitor 101 can be implemented in any network node, e.g. in an E-UTRAN, in a router, in a serving gateway or in a packet data network gateway. According to an implementation form, the video quality monitor 101 can be implemented in a video server of a service provider and/or in a user equipment or user terminal.

According to an implementation form, the video quality monitor 101 is configured to capture video resolution information from the video server of the service provider and to capture client display resolution information from the user equipment or the video client, respectively.

According to an implementation form, the video quality monitor 101 is placed in an LTE/EPC (Long Term Evolution/Evolved Packet Core) network between a video server and a video client. The video server is implemented within a service provider in the Internet and implements the protocol stack HTTP over TCP over IP over L1/L2 and the video client is implemented within a user equipment implementing the protocol stack HTTP over TCP over IP over PDCP (Packet Data convergence Protocol) over RLC (Radio Link Control) over MAC (Media Access Control) over L1. The video quality monitor 101 is placed at the end-to-end communication path between the video server and the video client and has contact to the TCP layers of video server and video client as well as to the HTTP layers. Other protocol stacks related to other communication networks can be envisioned too, e.g., a laptop connected to a fixed network will have a protocol stack HTTP/TCP/I P/L2/L1 , where L1 and L2 are layer 1 and layer 2 protocols and are abstracted by the TCP/IP communication paradigm. L1 and L2 can be any protocol for Layer 1 and Layer 2 communication according to the OSI model.

According to an implementation form, the video quality monitor 101 is a Network Monitoring Probe placed at TCP/HTTP level to monitor and qualify a HTTP video streaming session. According to an implementation form, the end-to-end communication path is between the video server and a mobile client accessing an LTE network. The video quality monitor 101 accesses the TCP layer and can be placed anywhere in the communication path, including the end devices.

Fig. 3 shows a block diagram of a video quality monitoring method for determining a network video quality measure for a plurality of video clients in a communication network, each video client employing a video buffer for buffering video information receivable over the communication network, according to an implementation form. The method comprises capturing 401 network data packets, the network data packets. The method comprises determining 403 a network rate and a video playback rate from the captured network data packets. The method comprises emulating 405 a storage capacity behavior of a set of video buffers to determine the set of video quality measures, each video quality measure being associated with a video buffer, each video buffer being associated with a probability of appearance in the communication network. The method comprises assigning 407 a probability of appearance of a respective video buffer to an associated video quality measure to obtain a statistical distribution of the video quality measures in the communication network, the statistical distribution of the video quality measures forming the network video quality measure. Fig. 4 shows a block diagram of a video quality monitor 600 according to an implementation form of a video quality monitor 101 as described based on Figs. 1 and 2. The video quality monitor 600 comprises a data interface 607 and a processor 61 1. The processor 611 comprises a buffer emulator 613 and a computation and reporting unit, also denoted as Video Model 615. The data interface 607 captures network data packets sent on the communication network between a video client and a video server; in other words, it captures network traffic 601 of the communication network and performs deep packet inspection (DPI) and/or shallow packet inspection (SPI) for the video session. The data interface 607 retrieves session and application information 602 by DPI or SPI from the network traffic 601 and provides this retrieved information 602 to the buffer emulator 613 of the processor 611 . The session and application information 602 comprises a network rate r(t), which is the rate by which the video session is offered by the network, and a video playback rate v(t), which is the rate by which a video file downloaded from a video server is played on a player at the video client. The data interface 607 retrieves further video parameters 603 of the session, e.g. frame rate, encoder type or motion vectors, by DPI on incoming packets of the network traffic 601 and provides these video parameters 603 to the computation and reporting unit 615 (Video Model) of the processor 611 . The buffer emulator 613 provides network impairment information 604, which may be computed according to the methods as described below with respect to Figures 5 and 6, to the computation and reporting unit 615. The computation and reporting unit 615 computes quality measurements 605 or quality information based on the video parameters 603 delivered by the data interface 607 and based on the network impairment information delivered by the buffer emulator 613. According to an implementation form, the video quality monitor 600 is part of a passive monitoring system intended to analyse the quality of an HTTP video streaming session. The video quality monitor 600 is configured to analyse the packets of the session in real time. Based on the obtained information from these packets, either through deep packet inspection (DPI), or shallow packet inspection (SPI), or by computing statistics on the observed packets, the video quality monitor 600 computes a quality score for the session, which reflects the user experienced quality for the given session. In order to do so, the video quality monitor 600 emulates the video player at the user side, and infers what the user is actually seeing on its screen. With this respect, DPI is used in order to obtain information about the played video, i.e., name, duration, resolution, encoding format, bitrate, and internal computation mechanisms are used in order to predict the way the video information, that is packets or frames, are displayed on the user screen. To this end, the video quality monitor 600 emulates the buffer existing in the user player, and based on this emulation, estimates network impairment information 604, which comprises video quality measures like the time it takes until the player starts displaying the video on the screen, the number of times the player stops for re-buffering, and the duration of these interruption periods and other Key Performance Indicators. This computation is performed by monitoring the

transmitted packets through the network, their size, order, and arrival time, among others. According to implementation forms, these data packets are HTTP packets, TCP segments, and TCP ACK packets. Having all this information, the video quality monitor 600 accounts for the display quality of the video on the user screen, taking into account both video metrics, and network influences on the transmission process.

The buffer emulator 613 inside the video quality monitor 600 is a crucial

computational element, which can estimate the influence of the network status on the transmission process for the packets belonging to the video session. The input parameters for the buffer emulator 613 are the buffer size value b, the

instantaneous network rate r(t) provided to the video session, and the video playback rate v(t), also called video consumption rate or bitrate of the video which is described below with respect to Fig. 5. The internal computations of the buffer emulator 613 predict, based on these parameters: i) the initial buffering time, before the player starts displaying the video information, ii) the times at which the video freezes on the screen due to buffer underflow and iii) the time it takes to refill the buffer and resume playback.

According to an implementation form, the video quality monitor 600 is configured to qualify video sessions based on HTTP video streaming. HTTP video streaming or also called progressive download is the most popular technique to stream video over the internet. Most of the biggest video service providers use this technique to stream the videos to the users. The technique allows a user to download and play in almost real time a video which is made available by a service provider. The user's computer/playing device requires normally a web browser installed, e.g. Internet Explorer (IE), Firefox or Google Chrome, with the Adobe Flash Player plug-in on top. The service provider offers the desired video with the help of a web server, e.g. apache or lighttpd servers. The end to end communication is established through the HTTP/TCP protocol stack between the web browser on the user side and the web server at the provider side. The video file is

progressively downloaded or streamed from the server into the player buffer at the user side. Once a sufficient amount of video information is available in the client buffer, the player will start displaying the video. The user experience in watching the video depends mostly on two factors: i) the quality of the video offered by the service provider, which usually translates into video resolution parameters and bitrate of the video stream, and ii) the network performance during the streaming process which comprises the available network bandwidth for the session, the packet loss rate and the packet delay. When the network performance is below that required by the video streaming session, the user will experience frequent video freezes on the screen. This is due to the fact that the player buffer is empty and needs to refill with video packets before video display can resume. Such behaviour leads to a degradation of the user quality of experience related to the video streaming service. The video quality monitor 600 is able to detect such degradation of the user quality and inform the service provider about the performance degradation.

More and more, network operators for both fixed and mobile networks want to monitor the quality of their network as perceived by their customers. The video quality monitor 600 provides a tool to the network operators and service providers to retrieve such information and helps them to improve their business, keep their customers happy, reduce the customer churn and increase their customer base. Service monitoring is a key component of a network monitoring solution, as it can estimate the quality of the services accessed by the clients through the network, and hence is closest to the experience perceived by the users when using the network. Active or passive service monitoring solutions comprising video quality monitors 600 according to implementation forms can be deployed by network operators in order to assess the quality of the services in the network. Active solutions imply the deployment of specialized equipment in the network (sometimes also outside it) which initiate artificial service sessions in order to monitor their behaviour. The results are aggregated, and it is inferred that the real users using the same services in the network in similar conditions will observe similar service quality levels. Such a method is usually expensive to deploy, and does not monitor the real service sessions initiated by the network users.

Passive monitoring solutions imply the deployment of either terminal software agents in the user devices or of network passive probes on the network interfaces on the end-to-end path of the service sessions or of solutions using both terminal agent and probes.

According to an implementation form, the video quality monitor 600 is

implemented as terminal software in the user device being part of a passive monitoring system. According to an implementation form, the video quality monitor 600 is implemented as a network passive probe on a network interface on the end- to-end path of the service session and is part of a passive monitoring system. According to an implementation form, the video quality monitor 600 is part of a passive monitoring system and is implemented as terminal software in the user device and is implemented as a network passive probe on a network interface.

These video quality monitors 600 can monitor the user session in real-time by analysing the packets that are transmitted through the network for the given session. Both the video quality monitor 600 implemented in the terminal agent and the video quality monitor 600 implemented in the network probe use algorithms and service models in order to infer the quality of the session as experienced by the user, starting from the information that is obtained by looking at the session packets traversing the network. This method provides information in real-time about the user session, which is preferred by most network operators. According to an implementation form, the video quality monitor 600 is configured to capture TCP traffic 601 and TCP/IP traffic 601 in the data network. TCP provides a communication service at an intermediate level between an application program and the Internet Protocol (IP). That is, when an application program, e.g. the video client desires to send a large chunk of data across the Internet using IP, instead of breaking the data into IP-sized pieces and issuing a series of IP requests, the software can issue a single request to TCP and let TCP handle the IP details. IP works by exchanging pieces of information called packets. A packet is a sequence of octets and consists of a header followed by a body. The header describes the packet's destination and, optionally, the routers to use for forwarding until it arrives at its destination. The body contains the data IP is transmitting. Due to network congestion, traffic load balancing, or other unpredictable network behavior, IP packets can be lost, duplicated, or delivered out of order. TCP detects these problems, requests retransmission of lost data, rearranges out-of-order data, and even helps minimize network congestion to reduce the occurrence of the other problems. Once the TCP receiver has reassembled the sequence of octets originally transmitted, it passes them to the application program. Thus, TCP abstracts the application's communication from the underlying networking details. Therefore, data interfaces 607 of video quality monitors 600 according to

implementation forms can connect to the TCP layer without caring about transmission in lower protocol layers.

TCP is optimized for accurate delivery rather than timely delivery, and therefore, TCP sometimes incurs relatively long delays (in the order of seconds) while waiting for out-of-order messages or retransmissions of lost messages. It is not particularly suitable for real-time applications such as Voice over IP. For such applications, protocols like the Real-time Transport Protocol (RTP) running over the User Datagram Protocol (UDP) are usually recommended instead. Data interfaces 607 of video quality monitors 600 according to alternative implementation forms connect to the UDP layer or the RTP layer. Thus, they can be applied for Voice over IP applications. According to some implementation forms, the video quality monitor 600 is used for HTTP video streaming monitoring systems using the HTTP layer. The Hypertext Transfer Protocol (HTTP) is a networking protocol for distributed, collaborative, hypermedia information systems. HTTP is the foundation of data communication for the World Wide Web. According to an implementation form, RFC 2616, which defines HTTP/1.1 , is used as version of the HTTP protocol.

HTTP is an Application Layer protocol designed within the framework of the Internet Protocol Suite. The protocol definitions presume a reliable Transport Layer protocol for host-to-host data transfer. The Transmission Control Protocol (TCP) is the dominant protocol in use for this purpose. According to

implementation forms, the data interface 607 of the video quality monitor 600 is configured to connect to an end-to-end communication path at TCP layer between the video server and the video client. However, HTTP has found application even with unreliable protocols, such as the User Datagram Protocol (UDP) in methods such as the Simple Service Discovery Protocol (SSDP). According to

implementation forms, the data interface 607 of the video quality monitor 600 is configured to connect to an end-to-end communication path at UDP layer between the video server and the video client. HTTP/1 .1 can reuse a connection multiple times, to download, for instance, images for a just delivered page. According to implementation forms, the data interface 607 of the video quality monitor 600 is configured to connect to an end- to-end communication path at HTTP layer between the video server and the video client in order to reuse connections multiple times. Hence video quality monitors 600 according to implementation forms experience less latency as the

establishment of TCP connections presents considerable overhead. HTTP functions as a request-response protocol in the client-server computing model. In HTTP, a web browser, for example, acts as the video client, while an application running on a computer hosting a web site functions as a video server. The video client submits an HTTP request message to the video server. The video server, which stores content, or provides resources, such as HTML files, or performs other functions on behalf of the video client, returns a response message to the video client. A response contains completion status information about the request and may contain any content requested by the video client in its message body. Video quality monitors 600 according to implementation forms are able to capture the communication between the video client and the video server. The video client is referred to as a user agent (UA) or as a web browser or web crawler. Video quality monitors 600 according to implementation forms are implemented in user agents, web browsers and/or web crawlers.

The HTTP protocol is designed to permit intermediate network elements to improve or enable communications between clients and servers. According to implementation forms, the video quality monitor 600 is placed in the client or in the server or in any of the intermediate network elements. High-traffic websites often benefit from web cache servers that deliver content on behalf of the original, so- called origin server to improve response time. According to implementation forms, the video quality monitor 600 is placed in an origin server. HTTP proxy servers at network boundaries facilitate communication when clients without a globally routable address are located in private networks by relaying the requests and responses between clients and servers. According to implementation forms, the video quality monitor 600 is placed in a HTTP proxy server.

According to an implementation form, the video quality monitor 600 is configured to qualify video sessions based on RTP video streaming. RTP video streaming is different from HTTP video streaming mainly in the protocol stack and nature of protocols used for the transmission of the video information. While HTTP video streaming uses a reliable transmission paradigm implemented by the use of the TCP transmission protocol, RTP streaming uses the unreliable UDP protocol, with extra mechanisms for compensation of network packet loss, implemented at the edge, at the application level. However, from the video player point of view, at the client side, the two streaming solutions are similar. The player still implements a video buffer which stores the received video packets from the network until the play time. Also for the RTP case, the player displays the video information from the buffer, and it stalls (video freeze) in case the buffer is empty. In such a case, the re-buffering is performed in a similar case, as explained above. In the case of an RTP video session, the data interface 607 is configured to capture the required information from DPI on the video packets in a similar manner as in the HTTP case. The data interface 607 captures RTP packets and RTCP reports and provides the information to the qualification unit 61 1 which provides qualification information 605 based on the information of the data interface 607. The buffer emulator 613 and the computation and reporting unit 615 correspond to the buffer emulator 613 and the computation and reporting unit 615 as described above with respect to the HTTP video session implementation form.

Fig. 5 shows a block diagram of a buffer emulator 700 according to an

implementation form. The buffer emulator 700 emulates, i.e. reconstructs, a receive buffer in the video client. That means, the buffer emulator 700 provides a buffer model of the receive buffer in the video client. The buffer emulator 700 comprises a buffer 701 which is configured to buffer multiple video packets, wherein Fig. 5 depicts a first video packet 703 no. i, a second video packet 705 no. i+1 and further video packets 707. The buffer 701 has a buffer size b. The buffer size b which represents a size of the receive buffer in the video client corresponds to a number of memory cells for storing video packets of a video file which are stored in the receive buffer before playback or to a number of seconds, or other time measures, of the video buffered for playback. The larger the size of the receive buffer emulated by the buffer 701 is, the more data packets can be stored in the receive buffer of the video client before the video is played and the less buffer stall events will occur.

Video packets are received by the network with an instantaneous network rate r(t), also called network packet rate and buffered in the receive buffer 701 , wherein each of the buffered video packets is provided to a video playback unit for playing the video with a video playback rate v(t). Depending on the instantaneous network rate r(t), the receive buffer and thus the emulated buffer 701 is filled with video packets 703, 705, 707 until the buffer size b representing the size of the receive buffer in the video client is reached. When the buffer 701 is filled up to the buffer size b, the receive buffer in the video client is filled up and the video client starts playing the video at the video playback rate v(t). If the network rate r(t) is greater than the video playback rate v(t), the buffer 701 is filled with video packets 703, 705, 707 . If the video playback rate v(t) is greater than the network rate r(t), the receive buffer in the video client and so the emulated buffer 701 drains and eventually can become empty, causing the video to stall on the client display. The buffer size b may form a minimum constraint on how much should be buffered before video playback is started or restarted after a freeze. If the buffer is already filled up to the buffer size b with packets, the client can still store network packets as they arrive according to the network rate r(t), hence increasing the amount of packets that are available in the receive buffer and in the emulated buffer 701 . v(t) and r(t) are related to the end-to-end communication path. r(t) is also called the instantaneous network rate and can be obtained by observing and monitoring the packets of the video session. v(t) is the video playback rate, i.e. the bitrate, and can be obtained by deep packet inspection (DPI) on the first packets of the video session. v(t) is a parameter included in the video metadata in some packets of the video file containing the video. According to an implementation form, the buffer 701 does not have an upper limit. So even if the network rate r(t) is higher than the video playback rate v(t), packets can still be loaded and stored in an ever increasing buffer. The buffer size b may represent the minimum amount of data that must be downloaded in order for the video playback to start. The buffer emulator 700 is a crucial computational element, which can assess the influence of the network status on the transmission process for the packets belonging to the video session. The input parameters for the buffer emulator 700 are the buffer size b, the network rate r(t) provided to the video session, and the video playback rate v(t) of the video file as can be seen from Figure 7. The internal computations of the buffer emulator 700 can predict based on these parameters: i) the initial buffering time, before the player starts displaying the video information, ii) the times at which the video freezes on the screen due to receive buffer underflow and iii) the time it takes to refill the receive buffer in the video client and resume playback.

Fig. 6 shows an equation system according to a leaky bucket principle for calculating performance indicators using a buffer emulator 700 according to an implementation form; As aforementioned, the parameter r(t) is the network rate or the instantaneous network rate and can be obtained by observing and monitoring the packets of the session server. v(t) is the video playback rate or bitrate, and can be obtained by deep packet inspection (DPI) on the first packets of the video session. v(t) is a parameter included in the video metadata in the first packets of the video file containing the video, b is the buffer size, taken as input parameter or obtained by evaluating the client capabilities information received from the client application on the video client or received from other network devices. Based on this model and computation, the buffer emulator 700 is able to predict the number of times the user player had to re-buffer, and the duration of these re-buffering intervals in order to assess the user's quality of experience. The buffer emulator 700 emulates the receive buffer in the video client

according to a buffer model as depicted in Fig. 5. Time ti is the time required for filling the buffer 701 , i.e. for initializing the buffer 701 . ti is calculated by using the minimum argument with respect to time t, for which the integral of r(t) integrated from 0 to ti is greater than the product of v(t) and b, wherein r(t) is the network rate and v(t) is the video playback rate and b is the buffer size of the emulated buffer 701. The time interval from ti to indicates the

playback time. Time t2 is calculated by using the minimum argument with

respect to time t, for which the integral of r(t) integrated from 0 to t2 is smaller than the integral of v(t) integrated from ti to t.2. The time interval from t2 to

indicates the stall time. t3 is calculated by using the minimum argument with respect to time t, for which the integral of r(t) integrated from t2 to is greater than the product of v(t) and b. During the time interval from t2 to .3, the buffer 701 is refilled at the network rate r(t) until the buffer size b is reached again.

The times ti to .2 and t3 are performance indicators which represent a performance of the video client. They depend on the buffer size b modeling a size of the receive buffer in the video client. The higher the accuracy of the buffer size b is with respect to the size of the receive buffer, the higher is the precision of the

performance indicators ti to .2 and .3.

Based on this model and computation, the video quality monitor and the

monitoring system can predict the number of times the user player had to re-buffer, and the duration of these re-buffering intervals. This information is later integrated into an algorithm which can compute the quality of the video session, as perceived by the user.

According to implementation forms, the equation system of Fig. 6 and the buffer emulator 700, as described with respect to Fig. 5 are implemented in video streaming monitoring systems and other network monitoring/emulation/simulation systems. However, the equation system requires as input the buffer size value b. If erroneous values of the buffer size b are delivered as input to the equation system, because the input buffer size parameter b is not known, erroneous results will be obtained. Therefore, video quality monitors 101 according to implementation forms implementing this equation system are configured to receive information on the buffer size B together with associated reliability information P for the buffer size information B in order to determine a reliability for the determined quality measure. A video quality monitor 101 according to an implementation form evaluates different quality values based on different assumptions for the buffer size and combines these different quality values to a single quality value which reliability is higher than any reliability of the individual quality values.

Fig. 7 shows a graph of a video session modeled by a buffer emulator 700 according to an implementation form. The dotted line 901 represents the incoming rate of the video packets

according to the instantaneous network rate r(t). The continuous line 903

represents the consumption of the video information by the player at the

video playback rate v(t) and the corresponding display of video information on the user screen. t1 represents the initial buffering time, during which the player buffer modeled by the emulated buffer 701 gets filled up to level b, before the video starts displaying. t2 represents the time when a buffer

underflow occurs. The video playback is stopped, that is video play stalls, and the player attempts to refill the buffer up to level b, before displaying the video restarts. The buffer gets refilled at time t3, and the video is continued on the user screen. In the interval between t2 and t3 the user experiences a video freeze on the screen.

The diagram illustrates two data rates, a first data rate is the network rate r(t) illustrated by the dotted line 901 and a second data rate is the video playback rate v(t) illustrated by the continuous line 903. The network rate r(t) can be captured by following messages between the video client and the video server. The video playback rate v(t) can be captured from first packets of the video file. During a first time interval from 0 to ti of initial buffering the buffer 701 is filled with video packets at the network rate r(t). During this time

interval there is no playback of video at the video client. At time ti the buffer 701 is filled with video packets up to the buffer size b 407 and the video client starts playback. During a second time interval from ti to the continuous line 903 illustrates continuous playing of the video on the user screen at the video playback rate v(t) which is a continuous rate. During this time interval, data packets are received from the network at the network rate r(t). However, as can be seen from the figure, the network rate r(t) is smaller than the video playback rate v(t), resulting in a drain of the buffer 701 , such that at time .2 the buffer 701 is empty and no more packets are available for playback. Thus, at time video play stalls. The buffer 701 has to be filled again at the third time interval from time .2 to time .3, in which time interval the video is not played by the video client. At time t3 enough video packets were delivered by the network at the network rate r(t) to fill the buffer 701 up to the buffer size b. Then, the video client resumes playing the video.

As can be seen from the figure, the video is played continuously by the video client, if the network rate r(t) is greater than the video playback rate v(t). If the network rate r(t), however, is smaller than the video playback rate v(t), the buffer 701 is draining until it gets empty and video play stalls. The

computation of times t1 , t2 and t3 is performed according to the leaky bucket principle as displayed in Fig. 6.

Fig. 8 shows two graphs of one and the same video session modeled by a buffer emulator 700 emulating the buffer 701 based on different buffer sizes bi and b2 according to an implementation form. The results computed by the buffer emulator 700 greatly depend on the input parameters to the model. While the network rate r(t) can be computed/estimated by observing the traffic of the session, and the video playback rate v(t) can be obtained by DPI on some of the packets from the media file, the buffer size value b is an unknown parameter, which must be guessed. This parameter is intrinsic to the video player used by the user, and is not transmitted through the network during the video streaming session. Hence it cannot be discovered by the video quality monitor 101 . Moreover, different players can have different values for the buffer size parameter. An error in the estimation of this parameter in the buffer emulator, will lead to erroneous computations and results produced by the video quality monitor 101 . Such an error will lead to an erroneous interpretation of the user experience equality by the network operator, and will render the video quality monitor 101 useless, as seen in the example of Figure 8.

The diagram illustrates three data rates, a first data rate is the network rate r(t) illustrated by the dotted line 1001 , a second data rate is the video

playback rate v(t) modeled by a buffer emulator 700 based on a first buffer size bi illustrated by the dashed line 1003 and a third data rate is the video playback rate v(t) modeled by a buffer emulator 700 based on a second

buffer size b2 illustrated by the continuous line 1005 . The first buffer size bi corresponds to the buffer size b as depicted in Fig. 7 and thus, the second data rate illustrated by the dashed line 1003

corresponds to the data rate illustrated by the continuous line 903 as

depicted in Fig. 7. During a first time interval from 0 to ti of initial buffering the buffer 701 is filled with video packets at the network rate r(t). During this time interval there is no playback of video at the video client. At time ti the buffer 701 is filled with video packets up to the first buffer size bi and the video client starts playback. During a second time interval from ti to t.2, the video is continuously played at the video client. During this time interval, data packets are received from the network at the network rate r(t). However, as the

network rate r(t) is smaller than the video playback rate v(t), the buffer 701 drains and gets empty at time t2 such that playback stops. The buffer 701 is refilled during the third time interval from time .2 to time .3, in which the video is not played by the video client. At time t3 enough video packets were

delivered by the network at network rate r(t) to refill the buffer 701 up to the first buffer size bi . Then, the video client resumes playing the video.

A complete different situation occurs for emulating the buffer 701 with the second buffer size b2 which is greater than the first buffer size bi . During a time interval from 0 to U of initial buffering the buffer 701 is filled with video packets at the network rate r(t). During this time interval there is no playback of video at the video client. At time t₄ the buffer 701 is filled with video packets up to the second buffer size b2 and the video client starts playback. At a time starting from t₄, the video is continuously played at the video client. At this time, data packets are received from the network at the network rate r(t). as the network rate r(t) is greater than the video playback rate v(t), the buffer 701 does not drain and stays filled with video packet such that playback is not interrupted. The user does not experience any video freeze, and observes a good video quality.

If b2 is the real buffer size of the receive buffer in the video client and bi is the buffer size delivered to the buffer emulator 700, the qualification unit 101

measures a bad video quality while the user experiences a good video quality. If bi is the real buffer size of the receive buffer in the video client and b2 is the buffer size delivered to the buffer emulator 700, the qualification unit 101 measures a good video quality while the user experiences a bad video quality. Thus, the performance of the qualification unit 101 depends on the accuracy of the buffer size b, delivered to buffer emulator 700.

Fig. 9 shows a block diagram of a video quality monitor 1100 according to an implementation form. The video quality monitor 1100 comprises a data interface 1 107 and a processor 1 1 1 1. The processor 11 1 1 comprises a buffer emulator 1 1 13 and a computation and reporting unit 1 115. The buffer emulator 1 1 13 comprises a set of buffer emulator instances 11 13 1 , 1113 i , 1 1 13_n . The data interface 1 107 captures network data packets sent between the video client and the video server and retrieves a network rate r(t) and a video playback rate v(t) from the captured data packets. The data interface 1 107 provides the network rate r(t) and the video playback rate v(t) to the processor 1 1 11 . The data interface 1 107 further provides the buffer size B=(bi, b2, ...,bi, ...,b_n) and the reliability information P=(pi,p₂, ...,Pi, ...,p_n) to the processor 11 1 1. Buffer size B and reliability information P were captured by the video quality monitor 1 100 by sending a request 211 to the video client and receiving feedback information according to the mechanism as described with respect to Fig. 2. Alternatively, buffer size B and reliability

information P were provided to the video quality monitor 1 100 by another network element, e.g. a network management unit. In this implementation form, each of the buffer emulator instances 11 13 1 , 1113_i, 1 13_n receives different data values of the buffer size B=(bi, b2,...,bi, ...,b_n) and the associated reliability information P=(pi,p₂, ...,Pi, ...,p_n) from the video client or the network management unit, respectively. Additionally, each of the buffer emulator instances 1 1 13 1 , 1 1 13_i,

1 1 13_n receives the same data value for the network rate r(t) and the video playback rate v(t) from the data interface 1 11 1. Based on this input data, each of the buffer emulator instances 11 13 1 , 1 113_i, 1 1 13_n emulates a different buffer size of the receive buffer in the video client, determines an individual quality measure Οι,0,,Ο_η and provides this individual quality measure Οι,0,,Ο_η

associated with its reliability information pi,Pi,p_n to the computation and reporting unit 1 1 15. The computation and reporting unit 1 115 aggregates the individual quality measures Οι,0,,Ο_η and determines the quality measure O based on the individual quality measures Οι,0,,Ο_η and the reliability information pi ,ρ,, Ρη - r(t) is the instantaneous rate offered by the network to the video session.

According to an implementation form, r(t) is obtained by the data interface 1107 by following incoming TCP packets and TCP ACK packets for the monitored session. According to an alternative implementation form, RTP packets and RTCP reports are used. v(t) is the video playback rate, i.e. the bitrate, or the rate at which the video packets are consumed by the player from the buffer, at normal playback rate. The video playback rate is obtained by the data interface 1 107 through DPI on the traversing packets belonging to the session/video file. We call b, as one specific value for the player buffer size parameter, b, is one value from the set B, containing multiple values for the buffer size parameter. B=(bi, b2,...bi, ...b_n) is the set of all values for the buffer size parameter, where n is the total number of values available. Each value b, in the set B has a probability value p, associated to it. P=(pi, P2, ..-Pi, ...p_n) is the set of probabilities for the buffer values. According to an implementation form, the sum of all probabilities p, in set P is equal to 1 .

According to an implementation form, the sets B and P are received from a network unit or from the video client through a questionnaire. According to an alternative implementation form, the sets B and P are preconfigured in the video quality monitor 1 100. We define as O,, the output of the computations performed by the buffer emulator, given the buffer size parameter value b,. O, can be expressed as a set of KPIs (key performance indicators), e.g., Number of Stalls, Duration of Stalls, Average Number of Stalls per Session, Average Stall Duration per Session, Time To Stall Start, etc., or any other value computed as a formula of these KPIs. The set of KPIs and the computation on this set is based on the buffer formulas as presented in Figure 6. They are organized as an extended data record (xDR) and forwarded to a monitoring device as described below with respect to Figures 10 to 12.

According to an implementation form, once a new HTTP or RTP video streaming session is identified by the video quality monitor 1 100, an instance of the buffer emulator 1 1 13_1 , 1 113_i, 11 13_n is created, and the input parameters are initialized (e.g., v(t), B, P). At the same time, r(t) starts to be monitored for this session and is fed as an instantaneous, real-time input parameter to the buffer emulator 1 1 13. Applying the formulas in Figure 6, the buffer emulator 11 13 can compute the set of KPIs of interest, and can apply any other formula on this set of KPIs in order to compute the output O,. The buffer emulator 1 1 13 spawns n parallel computation of the output, one for each buffer value b,. These n computation processes are represented as the the buffer emulator instances 1113_1 , 1113_i, 1113_n in Fig.9.

Each computation process 1113_1 , 1113_i, 1113_n of the buffer emulator 1113 takes the same input with respect to video and network parameters v(t), r(t), and a different buffer size parameter, together with its attached probability value

(pi,p₂,...,Pi,...,Pn)- The computations performed by each process 1113 1 , 1113 i ,

1113_n are based on the formulas in Figure 6, which can compute the minimum set of KPIs, as mentioned above. The computations performed by each

computation process 1113 1 , 1113 i , 1113_n are similar. However, due to the different buffer size input parameter (bi, b2,...b,, ...b_n), the obtained results (Oi,

O2,... On) differ from one computation process 1113_1 , 1113 i , 1113_n to another.

The results (O1, O2,...O_n) of each computation process 1113_1 , 1113 i , 1113_n , together with the probability (pi,p₂,...,Pi,...,p_n) of the buffer size value (bi, b2,...bi, ...b_n) are reported and aggregated by an Outcome Computation and

Reporting Function (OCRF) in the computation and reporting unit 1115, processed, and reported to the monitoring device as described below with respect to Figures 10 to 12, and above, through an xDR. Once the OCRF aggregates the results (O1, θ2,...Ο_η) and probabilities (pi,p₂,...,Pi,...,p_n) obtained by the computation

processes 1113_1 , 1113 i , 1113_n , it can further process the results (O1, O2,...O_n) before forwarding them to the monitoring device. The reporting is organized as an extended data record (xDR) or may be organized in any other suitable format, e.g. organized in a KPI representation. According to an implementation form, the results O, are aggregated and displayed as such as a set of values O=(Oi, O2,...O_n). According to an implementation form, the results (O1, O2,...O_n) are aggregated together with the probabilities

(pi,p₂,...,Pi,...,p_n) associated to the buffer values (bi, b2,...b,, ...b_n), and displayed as a set of pairs (Ο,, p,). According to an implementation form, the results (O1, θ2,...Ο_η) are aggregated together with the probabilities (pi,p₂,...,Pi,...,p_n)

associated to the buffer values (bi, b2,...b,, ...b_n), and an average value is computed as 0=sum(0 ^*pi). According to an implementation form, the average value O is displayed. According to an implementation form, the average value is computed, and both the result pairs (Ο,, p,) and the average value are displayed. Fig. 10 shows a block diagram of a video quality monitoring system 1200 for monitoring a video session in a communication network between a video client 103 and a video server 105 according to an implementation form. The video quality monitoring system 1200 comprises a video monitoring tool 1210, a monitoring software agent 1220, a network probe 1230, a video client 103 and a video server 105. The video quality monitoring system 1200 comprises

communication paths 1203, 1204, 1205 and 1206 between the different devices configured to monitor a video session between the video client 103 and the video server 105. A communication path 1201 is implemented between the video server 105 and the video client 103 to initiate and perform the video session.

The communication process is started by the video client 103 initiating a video streaming session with the video server 105 using the first communication path 1201 . The network probe (NP) 1230 and the monitoring software agent (SA) 1220 comprise a data interface coupled to the first communication path 1201 . The data interface 1202 is configured to capture the communication traffic on the first communication path 1201 between the video server 105 and the video client 103. Both SA and NP devices 1220 and 1230 or one of them monitor the video session by using their data interface 1202 and compute quality results. According to an implementation form, the SA device 1220 and/or the NP device comprise a video quality monitor 101 , 600, 1 100 as described with respect to one of the Figures 1 , 4 and 9. The network probe 1230 and the monitoring software agent 1220 report the outcome in the form of an extended data record (xDR) to the Video Monitoring Tool (MT) by using the second communication paths 1203 between the network probe 1230 and the Video Monitoring Tool 1210 or between the monitoring software agent 1220 and the Video Monitoring Tool 1210, respectively. The Video Monitoring Tool 1210 asks the video client 103 by using the third communication path 1204 for feedback through a questionnaire. The user provides this asked feedback information to the video client 103 which transmits it to the Video Monitoring Tool 1210 by using the fourth communication path 1205. Then, the Video Monitoring Tool 1210 updates its data base of buffer values B and associated probabilities P according to the feedback information received from the video client 103, and informs the network probe 1230 and the monitoring software agent 1220 by using the fifth communication path 1206. According to an implementation form, the second 1203 and the fifth 1206 communication paths are implemented as a single communication path providing upstream and downstream communications. According to an implementation form, the third 1204 and the fourth 1205 communication paths are implemented as a single communication path providing upstream and downstream communications. According to an implementation form, the monitoring software agent 1220 is implemented in the video client 103. According to an implementation form in which the monitoring software agent 1220 is implemented in the video client 103, the second 1203, the third 1204, the fourth 1205 and the fifth 1206 communication paths are implemented as a single communication path providing upstream and downstream communications.

According to an implementation form, the monitoring software agent 1220 is implemented in a separate hardware device having access to the video client 103. According to an implementation form, the network probe 1230 is implemented in any network node, e.g. in a E-UTRAN, in a router, in a serving gateway or in a packet data network gateway.

According to an implementation form, the network probe 1230 is implemented in the video server 105. According to an implementation form in which the network probe 1230 is implemented in the video server 105, the second 1202, the third 1203 and the sixth 1206 communication paths are implemented as a single communication path providing upstream and downstream communications.

According to an implementation form, the network probe 1230 and the monitoring software agent 1220 are configured to capture video resolution information from the video server 105 and to capture client display resolution information from the video client 103.

According to an implementation form, the network probe 1230 and the monitoring software agent 1220 are placed in an LTE/EPC network between the video server 105 and the video client 103. According to an implementation form, the video server 105 is implemented within a service provider in the Internet and implements the protocol stack HTTP over TCP over IP over L1/L2 and the video client 103 is implemented within a user equipment implementing the protocol stack HTTP over TCP over IP over PDCP over RLC over MAC over L1 . According to an

implementation form, the network probe 1230 and the monitoring software agent 1220 are placed at the end-to-end communication path between the video server 105 and the video client 103 and have contact to the TCP layers of video server 105 and video client 103 as well as to the HTTP layers. According to an

implementation form, the monitoring software agent 1220 is implemented in a laptop connected to a fixed network having a protocol stack HTTP/TCP/I P/L2/L1 , where L1 and L2 are layer 1 and layer 2 protocols and are abstracted by the TCP/IP communication paradigm. L1 and L2 can be any protocol for Layer 1 and Layer 2 communication according to the OSI model.

According to an implementation form, the video quality monitoring system 1200 is a HTTP/RTP video quality monitoring system and is offered in the form of a terminal software agent, where both the video monitoring tool 1210 and the monitoring software agent 1220 are implemented in a user terminal. Due to the reliability based approach of the buffer emulator implemented in the video quality monitoring system 1200, the algorithm of the buffer emulator has an increased robustness to inaccurate predictions of the buffer size value.

According to an implementation form, the buffer emulator of the video quality monitoring system 1200 is implemented on a Flash Player platform of Adobe. The Flash Player is adapted, so that either the video quality monitoring system 1200 comprising the video monitoring tool 1210 and the monitoring software agent 1220 or the monitoring software agent 1220 alone are implemented on the Flash Player customizing a Flash Player according to an implementation form. The buffer size value is one parameter disclosed by the Flash platform through the API as the NetStream:BufferTime parameter. The recommended values are 2s for fast network connections and 10s for slow to medium network connections. Each of these values is associated with a reliability that a fast network connection or a slow network connection is provided. According to other implementation forms, other values for the NetStream:BufferTime parameter together with associated information on a probability for these values are used.

According to an implementation form, the video quality monitoring system 1200 is implemented as a customized video player on a youtube player platform of Youtube. Youtube offers programmers the possibility to customize their own video players, starting from the original youtube player. Similar to the Flash Player, the youtube player API is disclosed to the general public, so that programmers can set their own buffer size parameter. According to an implementation form, the youtube player is adapted, so that either the video quality monitoring system 1200 comprising the video monitoring tool 1210 and the monitoring software agent 1220 or the monitoring software agent 1220 alone are implemented on the youtube player

Fig. 1 1 shows a block diagram of a computer program 1300 according to an implementation form. The computer program 1300 is implemented in a Video Monitoring Tool 1210 as described with respect to Fig. 10 and may be implemented in a video quality monitor 101 as described with respect to Figs. 1 and 2. According to Fig. 10, the network probe 1230 and the monitoring software agent 1220 report the outcome in the form of an extended data record (xDR) to the Video Monitoring Tool 1210 by using the third communication paths 1203 between the network probe 1230 and the Video Monitoring Tool 1210 or between the monitoring software agent 1220 and the Video Monitoring Tool 1210, respectively. The computer program 1300 receives 1303 such xDR. The xDRs are based on the previously available sets of buffer values B and associated probability values P. Based on the results contained in the xDR, the computer program 1300 decides 1305 upon reception of the xDR whether to ask for user feedback for that particular session or not. According to an implementation form, the computer program 1300 uses algorithms for meeting this decision which are general, and ranging from asking user feedback for every received xDR, to randomly picking xDRs for which user feedback is demanded. According to an implementation form, the computer program 1300 utilizes algorithms based on an opportunistic analysis of the xDR results. Once the decision to ask for user feedback is taken, the computer program 1300 proceeds accordingly, by sending 1307 the questionnaire, i.e. the feedback form, to the appropriate user in case of feedback required or by not sending the questionnaire in case of feedback is not required. Furthermore, the computer program 1300 processes, aggregates or integrates and stores 1309 the incoming xDR for further later use. Thereafter, the procedure ends 131 1.

Fig. 12 shows a block diagram of a computer program 1400 according to an implementation form. The computer program 1400 corresponds to the computer program 1300 as described in Fig. 1 1 and is implemented in the Video Monitoring Tool 1210 as described with respect to Fig. 12 and may be implemented in the video quality monitor 101 as described with respect to Figs. 1 and 2.

According to Fig. 10, the user provides the asked feedback information to the video client 103 which transmits it to the Video Monitoring Tool 1210 by using the fifth communication path 1206. When the user completes the questionnaire, its results get sent to the computer program 1400. Upon the reception 1406 of the feedback result, the computer program 1400 updates the sets B and P. In order to facilitate this, the questionnaire contains at least one question regarding the user perceived quality Q_u of the given video session. The procedure followed by the computer program 1400 is as follows: The computer program 1400 correlates 1408 the received feedback with the appropriate xDR based on the user session ID. The user perceived quality Q_u is matched against the quality values reported in the xDR. The computer program 1400 finds the appropriate Q, value in the xDR which best matches the feedback value Q_u. Criteria for best match are set arbitrarily. According to an implementation form, criteria are closest value, minimum square error, etc. The computer program 1400 infers or computes 1410 that bi, i.e. the corresponding buffer value for Q, that is the best buffer value approximation for the given session. The computer program 1400 updates 1412 the buffer value set probabilities P. The update algorithm can be arbitrarily chosen.

According to an implementation form, the update algorithm is as follows: Let N be the total number of user feedbacks received based on which the original sets B and P are computed. Let also n, be the number of occurrences of quality value Q, for buffer value b, in the feedbacks. The sum of n, should be equal to N. Then the probability of buffer value b, is computed as p, = η,/Ν. When the new user feedback arrives, and b, is identified as the most probable buffer value for that session, n, becomes η,+1, N becomes N+1 , and the new set of probabilities is recomputed as Pi=rii/N for all i, using the new values for n, and N. In case the user feedback points to a probable value b, who is not already in the set B, the computer program 1400 includes this value in the new set B. Once the sets B and P are updated, they are sent 1414 to the buffer emulator implemented in the Monitoring software agent 1220 or in the network probe 1230. The buffer emulator performs session monitoring based on the most recent sets B and P. At initialisation time, when N=0, the original sets B and P can be arbitrarily configured. The process ends with step 1416. According to an implementation form, customer questionnaires are used to assess the quality of experience of certain connections, especially those that have low network parameters. The user feedback is organised as a quality scale from 1 to 5, similar to the MOS measure largely used for QoE assessments.

According to an implementation form, the video monitoring tool 1210 is a software monitoring tool which can be installed as an application certain mobile devices. One of its functions is to trigger user questionnaires and gather user feedback on the perceived quality of experience. The user feedback is used in order to increase the accuracy of the video quality monitoring system for video streaming.

Implementation forms are implemented in the field of HTTP/RTP video streaming video quality monitoring systems.

General purpose computers may implement the foregoing methods and computer programs, in which the computer housing may house a CPU (central processing unit), memory such as DRAM (dynamic random access memory), ROM (read only memory), EPROM (erasable programmable read only memory), EEPROM

(electrically erasable programmable read only memory), SRAM (static random access memory), SDRAM (synchronous dynamic random access memory), and Flash RAM (random access memory), and other special purpose logic devices such as ASICs (application specific integrated circuits) or configurable logic devices such GAL (generic array logic) and reprogrammable FPGAs (field programmable gate arrays). Each computer may also include plural input devices (for example, keyboard, microphone and mouse), and a display controller for controlling a monitor.

Additionally, the computer may include a floppy disk drive; other removable media magneto optical media); and a hard disk or other fixed high-density media drives, connected using an appropriate device bus such as a SCSI (small computer system interface) bus, and Enhanced IDE (integrated drive electronics) bus, or an Ultra DMA (direct memory access) bus. The computer may also include a compact disk reader, a compact disk reader/writer unit, or a compact disc jukebox, which may be connected to the same device bus or to another device bus.

The invention envisions at least one computer readable medium. Examples of computer readable media include compact discs, hard disks, floppy disks, tape, magneto optical disks, PROMs (for example, EPROM, EEPROM, Flash EPROM), DRAM, SRAM, SDRAM. Stored on any one or on a combination of computer readable media is software for controlling both the hardware of the computer and for enabling the computer to interact with other elements, to perform the functions described above. Such software may include, but is not limited to, user

applications, device drivers, operating systems, development tools, and so forth. Such computer readable media further include a computer program product including computer executable code or computer executable instructions that, when executed, causes a computer to perform the methods disclosed above. The computer code may be any interpreted or executable code, including but not limited to scripts, interpreters, dynamic link libraries, Java classes, complete executable programs, and the like.

From the foregoing, it will be apparent to those skilled in the art that a variety of methods, systems, computer programs on recording media, and the like, are provided.

The present disclosure also supports a computer program product including computer executable code or computer executable instructions that, when executed, causes at least one computer to execute the performing and computing steps described herein.

The present disclosure also supports a system configured to execute the performing and computing steps described herein. Many alternatives, modifications, and variations will be apparent to those skilled in the art in light of the above teachings. Of course, those skilled in the art readily recognize that there are numerous applications of the invention beyond those described herein. While the present inventions has been described with reference to one or more particular embodiments, those skilled in the art recognize that many changes may be made thereto without departing from the spirit and scope of the present invention. It is therefore to be understood that within the scope of the appended claims and their equivalents, the inventions may be practiced otherwise than as specifically described herein.

Claims

55

CLAIMS:

1 . A video quality monitor (101 ) for determining a network video quality measure (O) for a plurality of video clients (103 1 , 103_N) in a communication network (1 15), each video client (103 1 , 103_N) employing a video buffer for buffering video information receivable over the communication network (1 15), the video quality monitor (101 ) comprising: a data interface (107) configured to capture network data packets (1 13), the network data packets (1 13) comprising video information, the data interface (107) being configured to determine a network rate r(t) and a video playback rate v(t) from the captured network data packets (113); and a processor (11 1 ) configured to emulate a storage capacity behavior of a set of video buffers to determine a set of video quality measures, each video quality measure being associated with a video buffer of the set of video buffers, each video buffer being associated with a probability of appearance in the

communication network (1 15), the processor (1 1 1 ) being further configured to assign a probability of appearance of a respective video buffer to an associated video quality measure to obtain a statistical distribution of the video quality measures in the communication network (1 15), the statistical distribution of the video quality measures forming the network video quality measure (O).

2. The video quality monitor (101 ) of claim 1 , wherein the video quality measure indicates at least one of: a set of stalls, a duration of stalls, an average set of stalls per session, an average stall duration per session, a time to stall start, and a combination thereof.

3. The video quality monitor (101 ) of claim 1 or 2, wherein the data interface (107) is configured to receive feedback information (213) indicating a video quality measure from a video client (103) of the plurality of video clients (103 1 ,

103_N). 56

4. The video quality monitor (101 ) of claim 3, wherein the data interface (107) is configured to transmit a request (21 1 ) towards the video client (103) from the plurality of video clients (103 1 , 103_N) over the communication network (1 15), the request (21 1 ) requesting a transmission of feedback information (213) indicating the video quality measure towards the video quality monitor (101 ).

5. The video quality monitor (101 ) of any of the preceding claims, wherein the processor (1 11 ) is configured

to associate either a first video buffer of the set of video buffers being associated with a first probability of appearance or a second video buffer of the set of video buffers being associated with a second probability of appearance to the video quality measure, and

to adapt the first probability of appearance if the video quality measure is assigned to the first video buffer, or

to adapt the second probability of appearance if the video quality measure is assigned to the second video buffer.

6. The video quality monitor (101 ) of any of the preceding claims, wherein the processor (1 11 ) is configured to emulate the storage capacity behavior of each video buffer from the set of video buffers using a set of possible buffer sizes

B=(bi, b2, ...,bi, ...,b_n) and a set of probabilities of appearance P=(pi,p₂, ...,Pi, ...,p_n) associated to the set of possible buffer sizes B. 7. The video quality monitor (101 ) of one of the preceding claims, wherein the processor (1 11 , 1 1 11 ) is configured to emulate the storage capacity behavior of the respective video buffer using the network rate r(t), the video playback rate v(t) and a buffer emulator model (11 13). 8. The video quality monitor (101 ) of claim 7, wherein the buffer emulator model (1 1 13) comprises a plurality of buffer emulator instances (1 1 13 1 , 11 13 i , 57

1 1 13_n), each of the buffer emulator instances (1 1 13_1 , 1 113_i, 1 113_n) emulating a different storage capacity behavior for different buffer sizes of video buffers. 9. The video quality monitor (101 ) of claim 8, wherein each of the buffer emulator instances (1 113 1 , 1 1 13_i, 1 1 13_n ) is provided to respectively

determine an individual video quality measure (Oi, O,, O_n) related to the

corresponding buffer emulator instance (1 1 13_1 , 1 1 13_i, 1 1 13_n ) . 10. The video quality monitor (101 ) of claim 9, wherein the processor (1 1 1 1 ) is configured to average over the individual video quality measures (Oi, O,, O_n) and to determine the network video quality measure (O) based on the averaged individual quality measures (Oi, O,, O_n). 1 1 . The video quality monitor (101 ) of one of the preceding claims, wherein the processor (111 1 ) is configured to determine the network video quality measure (O) as one or a combination of

a set of the individual video quality measures 0=(Oi,02, ...,Oi, ...,O_n),

a set of the individual video quality measures together with their associated probabilities of appearance 0=(Oi,pi,02,P2,- - -,Oi,pi...,O_n,p_n) and

an average value computed by accumulation of the individual video quality measures weighted with their associated probabilities of appearance, in particular weighted according to the following formula 0=(Oipi+02P2⁺ - ⁺OiPi+...+O_np_n)- 12. The video quality monitor (101 ) of one of the preceding claims, wherein the processor (1 11 ) is configured to organize the network video quality measure (O) as an extended data record xDR and to transmit the extended data record xDR towards the communication network (115), in particular towards a monitoring device (1210) in the communication network (1 15). 58

13. The video quality monitor (101 ) of one of the preceding claims, being formed as terminal agent software (1220), the terminal agent software (1220) being executable in an end user device (103), or as a network probe (1230) on a network interface.

14. The video quality monitor (101 ) of one of the preceding claims, wherein the data interface (107) is configured to capture data packets of an HTTP video streaming session or data packets of an RTP video streaming session. 15. The video quality monitor (101 ) of one of the preceding claims, wherein the data interface (107) is configured to transmit a control signal towards a remote video server (105) transmitting the network data packets, the control signal indicating to reduce or to increase the video playback rate v(t) in dependence on the network video quality measure (O).

16. Video quality monitoring method for determining a network video quality measure (O) for a plurality of video clients (103 1 , 103_N) in a communication network (115), each video client (103 1 , 103_N) employing a video buffer for buffering video information receivable over the communication network (1 15), the video quality monitoring method comprising: capturing (401 ) network data packets (1 13) comprising video information; determining (403) a network rate r(t) and a video playback rate v(t) from the captured network data packets (1 13); and emulating (405) a storage capacity behavior of a set of video buffers to determine a set of video quality measures, each video quality measure being associated with a video buffer of the set of video buffers, each video buffer being associated with a probability of appearance in the communication network (115); and assigning (407) a probability of appearance of a respective video buffer to an associated video quality measure to obtain a statistical distribution of the video 59

quality measures in the communication network (1 15), the statistical distribution of the video quality measures forming the network video quality measure (O).

17. A computer program having a program code for executing the method of claim 16 when run on a computer.

18. A computer program product comprising the computer program of claim 17.