WO2016055574A1

WO2016055574A1 - Determination of bitrate request

Info

Publication number: WO2016055574A1
Application number: PCT/EP2015/073268
Authority: WO
Inventors: Erlendur Karlsson
Original assignee: Telefonaktiebolaget L M Ericsson (Publ)
Priority date: 2014-10-10
Filing date: 2015-10-08
Publication date: 2016-04-14

Abstract

There is presented mechanisms for determining a bitrate request (BRR) for a multimedia encoder of a transmitting electronic device, A method is performed by a receiving electronic device. The method comprises estimating receive bitrate and send bitrate of packets received from the transmitting electronic device using a model of packet arrival time as a function of at least packet send time. The method comprises estimating congestion induced delay of the packets based on the model of packet arrival time and classifying the estimated congestion induced delay into one of at least two classes based on at least one of the model of packet arrival time, receive bitrate and send bitrate. At least one of the at least two classes comprises at least two subclasses. The method comprises determining the BRR based on what class or subclass the congestion induced delay has been classified into and based on at least one of the receive bitrate and the send bitrate. Determination of the BRR differs for each class and subclass.

Description

DETERMINATION OF BITRATE REQUEST

TECHNICAL FIELD

Embodiments presented herein relate to bitrate requests, and particularly to a method, an electronic device, a computer program, and a computer program product for determining a bitrate request for a multimedia encoder of an electronic device.

BACKGROUND

In communication networks, there is always a challenge to obtain good performance and capacity for a given communications protocol, its parameters and the physical environment in which the communication network is deployed.

For example, real time communication (RTC) services are being deployed at an increasing rate over all types of communication networks. In many of these communication networks the available channel bandwidth is varying with time and in many cases this variation can be very significant over very short time intervals. This is especially true for wireless communication networks such as LTE (Long Term Evolution). These time variations of available bandwidth are often due to varying load over the communication network channel and in wireless (radio based) communication networks this may also be due to physical changes over the radio network (e.g. due to device movement in the communication network).

Such services put extensive requirements on the communications network and when multimedia such as audio and video are transmitted from one device to another device over the communications network, it is not uncommon that the capacity of the communications network is lower than what is required by the multimedia session to give the end-user a desired user experience. One non-limiting example is video telephony over a 3G network where on the one hand, High Definition (HD) video transmission with a bitrate of several Mbit/s could be needed to deliver a high quality end- user experience, whilst on the other hand, such a high bitrate could by the communications network only be supported under benign conditions.

As a result of varying network performance, running a multimedia session service with a high fixed bitrate over wireless communications networks (or other communications networks with time-varying throughput

characteristics) may lead to quality problems and unsatisfied end-users. To mitigate this some existing services have implemented mechanisms to cope with temporarily congested networks by means of rate adaptation. Through various techniques the multimedia stream is adapted with the goal to suit present conditions of the communications channel.

In general terms, it is common that the end-user equipment and/or the network nodes of the communications network measures the perceived end- user quality or other Quality of Service (QoS) parameters such as media delay, delay jitter and packet loss that may have a correlation with the perceived end-user quality. These measurements may then be used to control the multimedia bitrate, and thus the bandwidth consumption, used by the electronic device for transmitting the multimedia stream.

However, there is still a need for improved bitrate determination.

SUMMARY

An object of embodiments herein is to provide efficient bitrate determination. According to a first aspect there is presented a method for determining a bitrate request (BRR) for a multimedia encoder of a transmitting electronic device. The method is performed by a receiving electronic device. The method comprises estimating receive bitrate and send bitrate of packets received from the transmitting electronic device using a model of packet arrival time as a function of at least packet send time. The method comprises estimating congestion induced delay of the packets based on the model of packet arrival time and classifying the estimated congestion induced delay into one of at least two classes based on at least one of the model of packet arrival time, receive bitrate and send bitrate. At least one of the at least two classes comprises at least two subclasses. The method comprises determining the BRR based on what class or subclass the congestion induced delay has been classified into and based on at least one of the receive bitrate and the send titrate. Determination of the BRR differs for each class and subclass.

Advantageously, this provides efficient bitrate determination.

Advantageously, this enables an accurate BRR to be determined for multimedia packet transmission in wide range of network scenarios, especially LTE networks.

Advantageously, this enables a good balance between a high degree of utilization of the available throughput and a low latency to be achieved.

Advantageously, the classification into classes and subclasses enables each congestion induced delay in class and subclass to be handled efficiently.

Advantageously this may improve network efficiency for multimedia sendees.

Advantageously this may improve the Quality of Service, and thus the end- user experience.

Advantageously this may enable network costs to be reduced. Advantageously this may enable an efficient way to handle significant drops in channel quality, such as during handovers in cellular communications networks.

According to a second aspect there is presented an electronic device for determining a BRR for a multimedia encoder of a transmitting electronic device. The electronic device comprises a processing unit. The processing unit is configured to estimate receive bitrate and send bitrate of packets received from the transmitting electronic device using a model of packet arrival time as a function of at least packet send time. The processing unit is configured to estimate congestion induced delay of the packets based on the model of packet arrival time and classify the estimated congestion induced delay into one of at least two classes based on at least one of the model of packet arrival time, receive bitrate and send bitrate. At least one of the at least two classes comprises at least two subclasses. The processing unit is configured to determine the BRR based on what class or subclass the congestion induced delay has been classified into and based on at least one of the receive bitrate and the send bitrate. Determination of the BRR differs for each class and subclass.

According to a third aspect there is presented a computer program for determining a bitrate request for a multimedia encoder of a transmitting electronic device, the computer program comprising computer program code which, when run on a processing unit of a receiving electronic device causes the processing unit to perform a method according to the first aspect.

According to a fourth aspect there is presented a computer program product comprising a computer program according to the third aspect and a computer readable means on which the computer program is stored.

It is to be noted that any feature of the first, second, third and fourth aspects may be applied to any other aspect, wherever appropriate. Likewise, any advantage of the first aspect may equally apply to the second, third, and/or fourth aspect, respectively, and vice versa. Other objectives, features and advantages of the enclosed embodiments will be apparent from the following detailed disclosure, from the attached dependent claims as well as from the drawings.

Generally, all terms used in the claims are to be interpreted according to their ordinary meaning in the technical field, unless explicitly defined otherwise herein. All references to "a/an/the element, apparatus, component, means, step, etc." are to be interpreted openly as referring to at least one instance of the element, apparatus, component, means, step, etc., unless explicitly stated otherwise. The steps of any method disclosed herein do not have to be performed in the exact order disclosed, unless explicitly stated.

BRIEF DESCRIPTION OF THE DRAWINGS

The inventive concept is now described, by way of example, with reference to the accompanying drawings, in which: Fig. la schematically illustrates a general communications network where embodiments presented herein may apply;

Fig, ib schematically illustrates parts of a communications network according to an embodiment;

Fig. 2 schematically illustrates packet transmission and reception in a communications network according to Fig, la or Fig. lb;

Figs. 3a and 3b schematically illustrate examples of electronic devices according to embodiments;

Fig. 4 schematically illustrates a computer program product according to an embodiment;

Figs. 5,6, and 19 are flowcharts of methods according to embodiments; and

Figs. 7 to 18 are simulation results according to embodiments,

DETAILED DESCRIPTION

The inventive concept ^'will now be described more fully hereinafter with reference to the accompanying drawings, in which certain embodiments of the inventive concept are shown, This inventive concept may, however, be embodied in many different forms and should not be construed as limited to the embodiments set forth herein; rather, these embodiments are provided by way of example so that this disclosure will be thorough and complete, and will fully convey the scope of the inventive concept to those skilled in the art. Like numbers refer to like elements throughout the description. Any step or feature illustrated by dashed lines should be regarded as optional.

Fig. la shows a schematic overview of an exemplifying communications network 11 where embodiments presented herein can be applied. The communications network 11 comprises a network node (NN) 13, such as a radio access network node, providing network coverage over cells (not shown). An electronic device (ED) 12a, 12b positioned in a particular cell is thus provided network service by the network node 13 serving that particular cell. As the skilled person understands, the communications network 11 may comprise a plurality of network nodes 13 and a plurality of EDs 12a, 12b operatively connected to at least one of the plurality of network nodes 13.

The network node 13 is operatively connected to a core network 14. The core network 14 may provide services and data to the electronic device 12a, 12b operatively connected to the network node 13 from an external Internet Protocol (IP) packet switched data network 15. At least parts of the communications network 11 may generally comply with any one or a combination of W-CDMA (Wideband Code Division Multiplex Access), LTE (Long Term Evolution), EDGE (Enhanced Data Rates for GSM Evolution, Enhanced GPRS (General Packet Radio Service)), CDMA2000 (Code

Division Multiple Access 2000), WiFi, microwave radio links, HSPA (High Speed Packet Access), etc., as long as the principles described hereinafter are applicable. An electronic device 12c, i2d may further have a wired connection to the external IP packet switched data network 15. Examples of electronic devices 12a, 12b, 12c, I2d include, but are not limited to end-user equipment such as mobile phones, tablet computers, laptop computers, and stationary computers. The electronic device 12a, 12b, 12c, I2d may alternatively be a server. In general terms, an electronic device 12a, 12b, 12c, I2d as herein disclosed may have either a wireless connection, or a wired connection, or both a wireless connection and a wired connection to the IP packet switched network 15. Hence the communications network 11 may comprise any combinations of purely wirelessly connected electronic devices 12a, 12b purely wired connected electronic devices 12c, i2d, and electronic devices with both wireless and wired connections. In Fig. la transmission links from the electronic devices 12a, 12c are schematically illustrated at reference 16a and reception links to the electronic devices 12a, 12c are schematically illustrated at reference 16b.

One example of communications services and data which may be

communicated through the communications system 11 is multimedia communications. In multimedia communications multimedia streams are communicated between two electronic devices 12a, 12b , 12c, 12b (such as from electronic device 12a to electronic device 12b on transmission link 16a, or vice versa, such as from electronic device 12b to electronic device 12a o reception link 16b) or between a server of the IP network 15 and at least one electronic device 12a, 12b, 12c, I2d (such as from the server to at least one electronic device 12a, 12b, 12c, i2d or from a at least one electronic device 12a, 12b, 12c, I2d to the server). The multimedia stream may comprise payload data in the form of audio and video content. The audio and video content may be synchronized. As the skilled person understands the multimedia streams may comprise further payload data. To be able to deliver the best quality of experience to the end-users over network channels with greatly varying throughput it is important that such communications services have a mechanism to adapt the sending bit rate of the multimedia streams to the available channel throughput at any given time. This mechanism is generally referred to as rate adaptation. A typical rate adaptation control loop between a transmitting electronic device 12a, 12c and a receiving electronic device 12b, i2d is illustrated in Fig. lb. In more detail, Fig. lb schematically illustrates a first electronic device 12a, 12c (hereinafter referred to as a transmitting electronic device 12a, 12c) acting as a transmitter of multimedia content and a second electronic device 12b, I2d (hereinafter referred to as a receiving electronic device 12b, I2d) acting as a receiver of the transmitted multimedia content. The multimedia content is transmitted over a communications channel 17 comprising a transmission link 16a and a reception link 16b. The electronic device 12a, 12b, 12c, I2d comprises a transmitter (Tx) 19a and a receiver (Rx) 19b for communication with another electronic device 12a, 12b, 12c, I2d. Transmitters 19a and receivers 19b are as such known in the art and will therefore not be further described herein. The electronic device 12a, 12c further comprises a multimedia encoder 18 for encoding multimedia. The multimedia encoder 18 may comprise an audio encoder and/or a video encoder. The electronic device I2d, I2d may comprise a multimedia decoder (not illustrated) for decoding multimedia. The multimedia decoder may thus comprise an audio decoder and/or a video decoder. Multimedia encoders 18 and decoders are as such known in the art and will therefore not be further described herein. The electronic device 12a, 12c is configured to transmit multimedia content (as encoded by the multimedia encoder 18), via the transmitter 19a and over the communications channel 17, to (the receiver 19b of) the electronic device 12b, I2d. The received multimedia content may then be provided to the

multimedia decoder for decoding. The received multimedia content may additionally or alternatively be stored in a storage medium for later decoding.

The multimedia content is transmitted using a bitrate as specified by a bitrate request (BRR). The BRR is determined by a rate controller 20 of the electronic device 12b, i2d and transmitted from the electronic device 12b, I2d to the electronic device 12a, 12c over the communications channel 17.

Commonly, the electronic device 12a, 12c is configured to transmit

multimedia content over a non-ideal communications channel 17 and the electronic device 12b, I2d intended to receive the multimedia content measures the quality of the received bit stream. The results of the

measurement may be translated into a BRR that is provided to the electronic device 12a, 12c, For example, if the electronic device 12b, I2d detects that the bitrate used for transmitting the multimedia content most likely is too high it will transmit a BRR to the electronic device 12a, 12c to lower its bitrate.

Common parameters to measure are inter-arrival delay, delay jitter and packet loss. Principles of how the BRR is determined may be defined by an adaptation scheme.

In more detail, the rate controller 20 may be configured to receive

information on the send and arrival times of the received multimedia packets or frames, to analyze the information to estimate the congestion state of the communications channel 17 (or parts thereof), to decide if the multimedia send bitrate needs to be changed or not and if so, to evaluate the appropriate bitrate, and to send a BRR to the transmitting electronic device 12a, 12c through the feedback path as defined by the link 16b. In this respect, the multimedia encoder 18 may, as disclosed above, generate encoded audio and/ or video packets (or frames). Assuming that the multimedia encoder 18 is configured to generate at least two parallel streams of audio and/or video packets (or frames), the rate controller 20 may be configured to split up the stream of multimedia packets or frames received by the receiver 19b of the electronic device 12b, I2d, for example according to different types of multimedia content (say, audio or video) and treat them separately. However, the BRR determined by the rate controller 20 may be a joint BRR for all the streams of multimedia packets or frames.

Each multimedia stream commonly has a bitrate range [MinOperativeBitrate, MaxOperativeBitrate] over which it is meaningful to transmit the

multimedia. In general terms, if the bitrate is lower than

MinOperativeBitrate, the quality of the rendered multimedia stream is considered to be too low to be acceptable. Similarly, if the bitrate is higher than MaxOperativeBitrate, the bitrate over MaxOperativeBitrate is commonly not considered to increase the quality of the rendered multimedia stream to the extent that it is worth the extra bandwidth. This may be referred to as quality saturation.

The rate controller 20 may therefore be configured to utilize the available throughput over the multimedia path to determine a BRR that enables low latency to be maintained. In terms of BRR this may imply the rate controller 20 to request the transmitting electronic device 12a, 12c to transmit the multimedia at the MaxOperativeBitrate whenever possible, and when this is not possible to request the transmitting electronic device 12a, 12c to transmit at a bitrate that is slightly lower than the available bitrate. This should be accomplished while maintaining low latency. It may further be advantageous to achieve fairness between multimedia streams that are being transmitted over the same multimedia path, where the available throughput is less than the sum of the desired bitrates for the multimedia streams.

In general terms, congestion induced delay builds up over a multimedia path when the multimedia path throughput is less than the sending bitrate since this will cause multimedia packets to pile up in the first in first out (FIFO) buffer(s) of the multimedia path as illustrated in Fig. 2, thus causing congestion delay). Fig. 7 illustrates a schematic, non-limiting, illustrative example of a congestion induced delay pulse that is not properly dealt with. The top part of Fig. 7 illustrates how bitrate for a communications link 16a varies over a period of 55 seconds. The bottom part of Fig. 7 illustrates how the congestion induced delay for the same communications link 16a varies over a period of 55 seconds depending on the bitrate variations. The congestion induced delay starts increasing at the time 40 seconds and continues to increase until the time 49 seconds, when the congestion induced delay has reached over 2 seconds. The bitrate starts decreasing at the time 40 seconds, but not enough to keep the congestion induced delay under what is considered as reasonable values. Ideally the height of these congestion induced delay pulses should be kept below 300-400 milliseconds (ms) and the duration of the increase- period should be kept below 500 ms. The congestion induced delay should not be allowed to increase over a period of 9 seconds. Delay based rate adaptation mechanisms as implemented in the rate controller 20 typically use the difference between the receive time differences of received packets/frames and the send time differences of sent

packets/frames to estimate the severity of the congestion and respond in an effort to bring this difference back to zero. There has according to the prior art been proposed a delay based rate adaption method to the RMCAT working group in IETF for WEBRTC that is based on monitoring the multimedia link congestion by observing the difference in intra frame delay between the transmitting electronic device 12a, 12c and the receiving electronic device 12b, I2d, see sections 1, 2, 3, and 4 of "A Google Congestion Control Algorithm for Real-Time Communication draft-alvestrand-rmcat-congestion-03" by H. Lundin et ai, February 14, 2014.

In more detail, assuming a multimedia encoder 18 is generating multimedia packets and that these packets are transmitted by the transmitter 19a of the transmitting electronic device 12a, 12c at the times t_n and that these packets are received at the receiver 19b of the receiving electronic device 12b, I2d at the times τ_η, then a packet is delayed relative to its predecessor if τ_η— τ_η→ > t_n - t_n→. The congestion induced delay is defined as d_n = (τ„ - T_n_ _t) - (t_n - t_n→) and is modelled as dn = dL_n + m_n + v_{n >} where C is the channel capacity of the link i6a, where dl_n = L_n - L_n__t is the packet size difference between two adjacent packets, where m„ is buffering related delay, and where v_n represents samples of a white zero means stochastic process. A Kalman filtering approach is then used to recursively estimate 1/C and m_n and then use the estimate fh_n (where rh_n is an estimate of m_n) to classify the link 16 as follows: n_n > Thr · Over used link

|m„l < Thr ·■ Normal link

h_n < Thr · Under used link where Thr denotes a threshold value.

However, simulation results as well as measurements in live networks have indicated that the above summarized approach does note provide good ut ilization of the available throughput. Further, when the network load increases the heights of the congestion induced delay pulses increase to unacceptable levels.

This is clearly evident from the performance results from particular cellular and basic test cases that are being standardized in the RMCAT group at IETF. The particular cellular test cases are two parameterizations of the test case "Varying Network Load" described in section 3.1 of "Evaluation Test Cases for Interactive Real-Time Media over Cellular Networks draft-sarker-rmcat- cellular-eval-test-cases-01" by Z. Sarker et al_} June 27, 2014, (hereinafter denoted "Cellular test cases") and the particular basic test cases is a

parameterization of the test case "Variable Available Capacity with Multiple RMCAT flows" and a parameterization of the test case "Congested Feedback Link" described in sections 5.2 and 5.3, respectively, of "Test Cases for Evaluating RMCAT Proposals draft-sarker-rmcat-eval-test-o l" by Z. Sarker et al, June 1 , 2014, (hereinafter denoted "Basic test cases").

Figs, 9 and 10 illustrate such poor performance in the Cellular test cases for the respective test configurations: Test 1 (Round trip time (RTT) 150 ms, user speed 3 km/s, AQM off), and Test 2 (Round trip time (RTT) 150 ms, user speed 30 km/s, AQM off), where AQM is short for active queue management. The plots show the cumulative distribution functions (CDFs) for the 90-95% maximum latency tail and the average bitrate per user for 2, 6, 10, and 14 users per cell. Figs. 11 and 12 illustrate such poor performance in the Basic test cases for the respective test configurations: Test 1 (V riable Available Capacity), and Test 6 (Congested Feedback Link) for a one way delay (OWD) of 50 ms.

From Figs, 9-12 it is clear that the bitrate never comes up to reasonable levels and a very slight drop in throughput results in a considerably high and long congestion induced delay pulse.

For these particular cellular setups the average bitrate should be considerably higher when the number of electronic devices 12a, 12b per cell is less than or equal to 6, and the height of the congestion induced delay pulses increases rapidly to unacceptable levels with the increased load (number of electronic devices 12a, 12b per cell). The bitrate and delay plots shown in Fig. 7 illustrate the bitrate and delay sequences for one of the electronic devices 12b in the first test configuration, which exemplifies how high and wide the delay pulses can get with the above summarized rate adaptation mechanism.

The embodiments disclosed herein relate to alternative (delay based) mechanisms for bitrate control where, for example, the above noted performance deficiencies are avoided, or at least reduced. The embodiments disclosed herein particularly relate to determining a bitrate request (BRR) for a multimedia encoder 18 of a transmitting electronic device 12a, 12c. In order to determine the BRR there is provided an electronic device acting as a receiving electronic device 12b, i2d, a method performed by the electronic device, a computer program comprising code, for example in the form of a computer program product, that when run on a processing unit of the electronic device, causes the processing unit to perform the method.

Fig. 3a schematically illustrates, in terms of a number of functional units, the components of an electronic device 12a, 12b, 12c, I2d according to an embodiment. A processing unit 21 is provided using any combination of one or more of a suitable central processing unit (CPU), multiprocessor, microcontroller, digital signal processor (DSP), application specific integrated circuit (ASIC), field programmable gate arrays (FPGA) etc., capable of executing software instructions stored in a computer program product 31 (as in Fig. 4), e.g. in the form of a storage medium 23. Thus the processing unit 21 is thereby configured to execute methods as herein disclosed. The processing unit 21 may thus implement the functionality of the rate controller 20.

The storage medium 23 may also comprise persistent storage, which, for example, can be any single one or combination of magnetic memory, optical memory, solid state memory or even remotely mounted memory. The electronic device 12a, 12b, 12c, i2d may further comprise a communications interface 22 for communications with at least one of another electronic device 12a, 12b, 12c, I2d, a network node 13, and a service providing network 15. As such the communications interface 22 may comprise one or more

transmitters and receivers, comprising analogue and digital components and a suitable number of antennas for radio communications or suitable number of wired ports for wired communications. The communications interface 22may thus implement the functionality of the transmitter 19a and the receiver 19a.

The processing unit 21 controls the general operation of the electronic device 12a, 12b, 12c, I2d e.g. by sending data and control signals to the

communications interface 22 and the storage medium 23, by receiving data and reports from the communications interface 22, and by retrieving data and instructions from the storage medium 23. Other components, as well as the related functionality, of the electronic device 12a, 12b, 12c, I2d are omitted in order not to obscure the concepts presented herein.

Fig. 3b schematically illustrates, in terms of a number of functional modules, the components of an electronic device 12a, 12b, 12c, I2d according to an embodiment. The electronic device 12a, 12b, 12c, I2d of Fig. 3b comprises a number of functional modules; an estimate module 21a configured to perform below step S102, S104, Si02b, and a determine module 21b

configured to perform below step S106, Si04b, Si 04c, Sio6b, Si04e. The electronic device 12a, 12b, 12c, i2d of Fig. 3b may further comprises a number of optional functional modules, such as any of an acquire module 21c configured to perform below step Si04a, Si02a, Si04d, an update module 2id configured to perform below step Sio6a, and a classify module 2ie configured to perform below steps S104, Si 04! The functionality of each functional module 2ia-e will be further disclosed below in the context of which the functional modules 2ia-e may be used. In general terms, each functional module 2ia-e may be implemented in hardware or in software. Preferably, one or more or all functional modules 2ia-e may be implemented by the processing unit 21, possibly in cooperation with functional units 22 and/or 23. The processing unit 21 may thus be configured to from the storage medium 23 fetch instructions as provided by a functional module 2ia-e and to execute these instructions, thereby performing any steps as will be disclosed hereinafter.

Fig. 4 shows one example of a computer program product 31 comprising computer readable means 33. On this computer readable means 33, a computer program 32 can be stored, which computer program 32 can cause the processing unit 21 and thereto operatively coupled entities and devices, such as the communications interface 22 and the storage medium 23, to execute methods according to embodiments described herein. The computer program 32 and/ or computer program product 31 may thus provide means for performing any steps as herein disclosed. In the example of Fig. 4, the computer program product 31 is illustrated as an optical disc, such as a CD (compact disc) or a DVD (digital versatile disc) or a Blu-Ray disc. The computer program product 31 could also be embodied as a memory, such as a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM), or an electrically erasable programmable read-only memory (EEPROM) and more particularly as a non-volatile storage medium of a device in an external memory such as a USB (Universal Serial Bus) memory or a Flash memory, such as a compact Flash memory. Thus, while the computer program 32 is here schematically shown as a track on the depicted optical disk, the computer program 32 can be stored in any way which is suitable for the computer program product 31.

Figs. 5 and 6 are flow chart illustrating embodiments of methods for determining a bitrate request (BRR) for a multimedia encoder 18 of a transmitting electronic device 12a, 12c. The methods are performed by an electronic device 12a, 12b, 12c, I2d acting as a receiving electronic device 12b, I2d. The methods are advantageously provided as computer programs 32.

Reference is now made to Fig. 5 illustrating a method for determining a BRR for a multimedia encoder 18 of a transmitting electronic device 12a, 12c as performed by a receiving electronic device 12b, I2d according to an

embodiment.

The processing unit 21 of the recei ving electronic device 12b, I2d is configured to, in a step S102, estimate receive bitrate and send bitrate of packets received from the transmitting electronic device 12a, 12c. The receive bitrate and send bitrate are estimated using a model. The model expresses packet arrival time as a function of at least packet send time. In this respect the estimate module 21a may comprise instructions that when executed by the receivin electronic device 12b, I2d causes the processing unit 21 to estimate the receive bitrate in order for the electronic device 12b, i2d to perform step S102. The processing unit 21 of the receiving electronic device 12b, i2d is configured to, in a step, S104 estimate congestion induced delay of the packets. The estimation of the congestion induced delay is based on the model of packet arrival time. The processing unit 21 of the receiving electronic device 12b, i2d is further configured to, in step S104, classify the estimated congestion induced delay into one of at least two classes. The classification is based at least one of the model of packet arrival time, receive bitrate and send bitrate. At least one of the at least two classes comprises at least two subclasses. In this respect the estimate module 21a and the classify module 2ie may comprise instructions that when executed by the receiving electronic device 12b, I2d causes the processing unit 21 to estimate the receive bitrate in order for the electronic device 12b, I2d to perform step S104.

The processing unit 21 of the receiving electronic device 12b, I2d is configured to, in a step, S106, determine the BRR. The BRR is determined based on what class or subclass the congestion induced delay has been classified into. The determination is based on at least one of the receive bitrate and the send bitrate. Determination of the BRR differs for each class and subclass. In this respect the determine module 21b may comprise instructions that when executed by the receiving electronic device 12b, I2d causes the processing unit 21 to determine the BRR in order for the electronic device 12b, i2d to perform step S106.

This enables a high degree of utilization of the available throughput to be achieved whilst keeping the height of congestion induced delay pulses relatively low over a wide range of network scenarios for the majority of end- users.

Embodiments relating to further details of determining a BRR for a multimedia encoder 18 of a transmitting electronic device 12a, 12c will now be disclosed. Reference is now made to Fig, 6 illustrating methods for determining a BRR for a multimedia encoder 18 of a transmitting electronic device 12a, 12c as performed by a receiving electronic device 12b, I2d according to further embodiments. There may be different ways to classify the estimated congestion induced delay into one of the at least two classes. Different embodiments relating thereto will now be described in turn.

As noted above, there are at least two classes. According to an embodiment there are at least three classes. The rate controller 20 may estimate the congestion induced delay from the arrival delay model and may classify the delay increase as smooth or abrupt and handle these two delay classes separately. These two classes of congestion induced delays are exemplified well in Fig, 17, see below.

No congestion delay may define a third class. One of the at least two classes may thus correspond to a situation where the congestion induced delay being below a packet delay threshold value. Additionally or alternatively, one of the at least two classes may thus corresponds to a situation where a difference between an actual value of the congestion induced delay and a predicted value of the congestion induced delay is below a packet delay threshold value. The rate controller 20 may thus operate in three distinct states, or modes, of operation; a normal (non-congested) state, a smooth (or slow) congestion state, and an abrupt (or fast) congestion state. The transition from the normal state is thus to one of two possible congestions states, i.e., either to the smooth congestion state or the abrupt congestion state. There may be different ways to determine what model to use. Different embodiments relating thereto will now be described in turn. What model to use to estimate receive bitrate of next packets may depend on in which class of the at least two classes the estimated congestion induced delay has been classified. For example, during the normal (non-congested) state, a slightly simpler arrival time predictor model (than used in the two congestion states) may be used to monitor if there is a transition to one of the two congestion states.

One of the at least two classes may correspond to smooth congestion induced delay. The congestion may be considered smooth when the rate of the congestion induced delay increase is moderate. A state transition to the smooth congestion state may then be performed by the rate controller 20 when the moderately increasing delay has reached a certain threshold.

Hence, the congestion induced delay may be classified as smooth if the congestion induced delay is above a packet delay threshold value and a rate of the congestion induced delay increases slower than a rate threshold. For example, the congestion induced delay may be above the packet delay threshold value if an estimated packet arrival time f„ of the packets exceeds a threshold (see below). In one embodiment this condition is thus evaluated by the rate controller 20 checking if the estimated arrival time f_n exceeds a threshold.

Additionally or alternatively, determining that the congestion induced delay is above the packet delay threshold value may comprise the processing unit 21 to, in an optional step Si 04a, acquire time intervals over which an estimated send bitrate exceeds that of the estimated receive bitrate, to, in an optional step 8104b, determine a total bitrate difference over the time

intervals, and, to, in an optional step Si 04c, determine when the total bitrate difference exceeds the packet delay threshold value multiplied with a current estimate of the receive bitrate. In another embodiment this condition is thus evaluated by the rate controller 20 keeping track of time intervals over which the estimated send bitrate exceeds that of the estimated receive bitrate, summing up the total bit difference over that time interval, and checking when that sum exceeds a delay threshold multiplied with the current estimate of the receive bitrate.

One of the at least two classes may correspond to abrupt congestion induced delay. The congestion may be considered abrupt when the rate of the congestion induced delay increase is steep. An abrupt delay change may be detected through the use of prediction models. The congestion induced delay may thus be classified as abrupt if the congestion induced delay is above a packet delay threshold value and a rate of the congestion induced delay increases faster than a rate threshold. The abrupt congestion induced delay may be detected by means of a prediction model.

When an abrupt congestion induced delay has been detected, data may be gathered over a few packets (or frames) to enable a further classification into subclasses of which type of abrupt congestion it is. Hence, the processing unit 21 may be configured to, in an optional step Si04d, acquire further packets to determine which subclass to classify the received packets. The appropriate response may then be taken.

There ma be different ways to classify the estimated congestion induced delay into one of the at least two subclasses. Different embodiments relating thereto will now be described in turn. The class corresponding to abrupt congestion induced delay may comprise at least two subclasses. For example, there may be at least three subclasses. Particularly, for the abrupt delay class the rate controller 20 may classify if the delay increase is monotonically increasing, step-like, or represents a short delay pulse. One of the at least two subclasses may correspond to a monotonically increasing congestion induced delay. Monotonically increasing does not mean strictly monotonically increasing as the data used to classify the congestion induced delay may comprise additional zero-mean delay jitter that makes the data not strictly monotonically increasing. A monotonically increasing congestion induced delay may by the rate controller 20 be handled by updating the receive bitrate estimate and sending a new bitrate request if required. Hence, the processing unit 21 may be configured to, in a case the congestion induced delay has been classified as monotonically increasing congestion induced delay, in an optional step Sio6a, update the estimated receive bitrate and send bitrate and determine an updated BRR. One of the at least two subclasses may correspond to a step-like increasing congestion induced delay. In general terms, the characteristics of the congestion induced delay in cellular communication networks may differ from other types of communication networks. Commonly, a congestion induced delay pulse increases monotonically (apart from additional zero mean delay jitter), when congestion occurs. This is, however, not always the case in cellular communication networks. There the delay increase may be regarded as more step-like, as illustrated in Fig. 8, where three steps are highlighted with dotted areas. In situations like this it may be important to detect and react to the first step with appropriate measures to hinder further delay increase. This may imply that a reactive action should be performed by the rate controller 20 in about 250 ms or less. This may be difficult, if not impossible, to achieve using known filtering mechanisms and may require special detection and handling of such step-like increases. There may be different ways to determine the BR in a case the congestion induced delay has been classified as step-like increasing congestion induced delay. For example, the processing unit 21 may be configured to, in an optional step Sio6b, determine the BRR based on evaluating at least one test case the congestion induced delay has been classified as step-like increasing congestion induced delay. In more detail, the BRR may be determined based on a function that provides a BRR for a particular sequence of step-like increases. The function may be based on a lookup table. Derivation of function can be based on trial and error. In general terms, during a derivation process of the function, the function may be evaluated in a heuristic manner based on trial and error tuning on several test cases. During such a derivation process the function may thus be parameterized based on (trial-and-error) experiments over a large set of test cases.

One of the at least two subclasses may correspond to a short delay pulse. In general terms, one frequently occurring delay phenomenon in cellular communication networks (but also in other types of communication networks) are high but short delay pulses (commonly causing a delay of 50- 150 ms and having a duration of only a few frames). These short delay pulses may occur when the network scheduler freezes a particular user out for a short period of time (say, 50-150 ms), after which the network scheduler gives the user the bandwidt needed to transmit all its packets. According to embodiments presented herein these kind of delay pulses are not reacted upon as they are considered only to constitute a disturbance that needs no handling. Hence, the processing unit 21 may be configured to, in an optional step Sio6c, leave the BRR unchanged in a ease the congestion induced delay has been classified as a short delay pulse.

As the skilled person understands, the above disclosed classes and subclasses are just some examples of classes and subclasses; other classifications and special handling of those may be used as the need arises.

There may be different ways to determine if the congestion induced delay has been relieved. Different embodiments relating thereto will now be described in turn. Once in a congested state the rate controller 20 may evaluate a condition to determine when the congestion has been relieved and the state should transit back to the normal state. This may be handled by noting the delay before the congestion state was entered and checking when the delay is back to that level again.

In general terms, the congestion induced delay may be considered as repealed when the estimated congestion induced delay is back to zero, below some threshold, or when the total delay is back to a level where it was before congestion was detected. Thus, the processing unit 21 ma be configured to, in an optional step Si04e, determine whether the congestion induced delay has been repealed by comparing a current estimated congestion induced delay to a threshold. The threshold may thus correspond to a level of no congestion induced delay, or to a level of congestion induced delay being below a delay threshold. The processing unit 21 may then be configured to, in an optional step Si04f, classify the estimated congestion induced delay in the class of the at least two classes that corresponds to no congestion induced delay if the congestion induced delay has been evaluated as repealed, There may be different ways to estimate the receive bitrate and/or send bitrate. Different embodiments relating thereto will now be described in turn. As noted above, a model may be used for expressing the packet arrival time as a function of the packet send time (and optionally other components). By means of this model, recursive estimates of the arrival time may be obtained from noisy arrival time values through a least squares estimation. Hence, recursive estimates of the packet arrival time may be obtained from

modelling noisy packet arrival time values as a function of at least packet send time. These estimations of the arrival times may be used in the estimation of the immediate receiving bitrate. That is, the recursive estimates of the packet arrival time may be used to estimate an immediate receiving bitrate. The recursive estimates of the packet arrival time may thus be obtained through a least squares estimation involving the noisy packet arrival time values and the arrival time model.

The arrival time model used to monitor the congestion induced delay may estimate the packet arrival time f„ based on a number of param eters.

Particularly, wherein the model of packet arrival time may be expressed as a function of path capacity C, packet size L_n, a constant time offset T, packet send time t„, a time scaling actor , and a white zero mean stochastic process v_n. One example of the arrival time model used to monitor the congestion induced delay (i.e., an example of how to express the packet arrival time as a function of at least packet send time) is given by:

T_n = ~ L_n + T + at_n + v_n. (1) Using the available data, the parameters i/C, Γ and may be estimated in a least squares estimation that minimizes the modelling error ||τ„— τ_η ||² where

for some vector length N + 1 that may vary with time.

To estimate the receive bitrate a filtered version of the arrival time may be used. This may be obtained from the least squares estimate of the arrival time f_n. Hence, the processing unit 21 may be configured to, in an optional step Si02a, acquire filtered arrival time values from the recursive estimates of the packet arrival time; and, in an optional step Si02b, estimate the receive bitrate based on the filtered arrival time values.

Congestion induced delay of the packets may then be determined if a-i≥ 8, where 8 is a threshold value. Further, no congestion induced delay of the packets may be determined if |α-ι | < 8, where 8 is a threshold value. Yet further, recovery of congestion induced delay of the packets may be determined if a-i < δ, where δ is a threshold value. The congestion induced delay may thus be monitored through the congestion criterions: a - 1 > 5 Congestion Send bitrate > Receive bitrate

\a - 1| < δ Normal (no congestion) Send bitrate « Receive bitrate a - 1 < δ Congestion recovery Send bitrate < Receive bitrate

One particular embodiment based on at least some of the above disclosed embodiments and examples for determining a BRR for a multimedia encoder 18 of a transmitting electronic device 12a, 12c as performed by a receiving electronic device 12b, I2d will now be presented.

For each received media packet the rate controller 20 obtains the packet data size (L„), the packet send time (t_n), and the packet arrival time (½) and performs state-specific updates according to the following, with references being made to the flow chart of Fig. 19:

S202: Arrival time models are updated. One way to implement step S202 is to perform step Sio6a.

S204: Send and receive bitrate estimations are evaluated. One way to implement step S204 is to perform step S102, Si02a, Siozb, and/or Si04a. S206: State transition conditions are evaluated and the state is updated if a particular state transition condition is met. One way to implement step S206 is to perform step 8104_» 8104b, Si04c, Si04d, 81040, and/or S104I

S208: A check is performed regarding if a new BRR is needed. If a new BRR is needed the new BRR is sent. One way to implement step S208 is to perform step S106, Sio6a, Sio6b, and/or Sio6c.

Figs. 13-18 show performance comparisons between the herein disclosed inventive concept ("Inv. Cone") for determining a BRR for a multimedia encoder 18 of a transmitting electronic device 12a, 12c and the prior art ("Prior Art") mentioned above for four test cases specified by the Internet Engineering Task Force (IETF) real Time Protocol Media Congestion

Avoidance Techniques (RMCAT) working group as currently specified at https://datatracker.ietf.org/wg/rmcat/charter/. Of the four test cases chosen two test cases are from the Cellular - Varying Network Load test cases described in detail in Section 3.1 at https://tools.ietf.org/pdf/draft-sarker- rmcat-cellular-eval-test-cases-oo.pdf:

• Cell TC 5 - Varying Network Load

Round Trip Time: 150 msec, User Speed 3 km/hour

• Cell TC 7 - Varying Network Load

Round Trip Time: 150 msec, User Speed 30 km/hour

The other two are from the Basic test cases described in Section 4 at

https://tools.ietf.org/pdf/draft-sarker-rmcat-eval-test-oo.pdf:

• Basic TC 1 - Variable Available Capacity

Described in detail in Section 4.1

· Basic TC 6 - Congested Feedback Link

Described in detail in Section 4.6.

Fig. 13 provides performance results for the herein disclosed inventive concept for the cellular down link test case with round trip time (RTT) of 150 ms, user speed 3 km/h and AQM off. The plots show the cumulative distribution functions (CDFs) for the 90-95% max latency tail and the average bitrate per user for 2, 6, 10, and 14 users per cell.

Fig. 14 provides a performance comparison between the herein disclosed inventive concept and Prior Art for the cellular down link test case with round trip time (RTT) of 150 ms, user speed 3 km/h and AQM off. The plots show the 90-95% max latency tail and the average bitrate per user as a function of the number of users per cell.

Fig. 15 provides performance results for the herein disclosed inventive concept for the cellular down link test case with round trip time (RTT) of 150 ms, user speed 30 km/h and AQM off. The plots show the cumulative distribution functions (CDFs) for the 90-95% max latency tail and the average bitrate per user for 2, 6, 10, and 14 users per cell.

Fig. 16 provides a performance comparison between the herein disclosed inventive concept and Prior Art for the cellular down link test case with round trip time (RTT) of 150 ms, user speed 30 km/h and AQM off. The plots show the 90-95% ma latency tail and the average bitrate per user as a function of the number of users per cell.

Fig. 17 provides a performance comparison between the herein disclosed inventive concept and Prior Art for basic test case 1, Variable Available Capacity, with one way delay (OWD) of 50 ms. Fig. 17 at 1700a compares the results of the herein disclosed embodiments ("Inv. Cone") to the results of prior art ("Prior Art") together with the link capacity ("Link"). Fig. 17 at 1700b shows the active queue management (AQM) packet loss rate in percent. Fig. 17 at 1700c shows the throughput for the herein disclosed embodiments. Fig. 17 at i700d shows the delay for the herein disclosed embodiments. Fig. 17 at v ooe shows the throughput for prior art. Fig. 17 at 170οί shows the delay for prior art. In basic test case 1 the link throughput changes over time between 1000 and 3500 kbps.

The subplot at 1700c shows the performance of the herein disclosed embodiments and in the subplot at 17006 shows the performance of prior art. The media source of the transmitting electronic device 2a, 12c has a target, or maximum, bitrate of 3000 kbps. In the beginning the rate controller 20 keeps instructing the media source to increase the send bitrate since there is no congestion induced delay detected and the target bitrate has not been reached. When the send bitrate exceeds the level of the link throughput (2000 kbps), a small and smooth increase in the delay induced delay is detected and the rate controller 20 instructs the media source to lower its bitrate to a value slightly below the estimated link bitrate. It is assumed that the media source performs as instructed and hence the congestion induced delay quickly decreases back to zero. Since the media source has not reached its target bitrate of 3000 kbps, the rate controller 20, after a short while (1-2 seconds), instructs the media source to slowly increase the bitrate again to see if the link throughput is still limited to 2000 kbps. This again leads to a small and smooth congestion induced delay which the rate controller 20 responds to as disclosed above, i.e., by instructing the media source to lower its bitrate to a value slightly below the estimated link bitrate. The rising parts of the small congestion induced delay pulses shown in the subplot at lyood during the time interval 10-25 seconds exemplify smooth congestion delays and the description just given explains how the rate controller 20 reacts to such smooth congestion delays. At time 50 seconds there is a very abrupt decrease in the link capacity (as it drops from 3500 kbps to 1000 kbps) and this occurs when the media source send bitrate is at 3000 kbps. This leads to a very abrupt congestion induced delay which rises up to 1 second before it decreases down again after the rate controller 20 has detected the congestion delay and the media source has had a chance to respond to the corresponding BRR, as illustrated in the subplot at l ood for the herein disclosed

embodiments. The rising part of this delay pulse is a typical example of an abrupt congestion delay. For the prior art performance in the subplot at i70of the congestion induced delay has, at time 50 seconds, a lower peak but then again the link throughput is only dropping from 1400 kbps down to 1000 kbps as opposed to a drop from 3000 kbps down to 1000 kbps for the invention solution. The congestion induced delay also decreases much slower back to zero, thus resulting in longer total delay and lower bitrate, as shown in the subplot at l ood.

Fig. 18 provides a performance comparison between the herein disclosed inventive concept and Prior Art for basic test case 6, Congested Feedback Link, with one way delay (OWD) of 50 ms. Fig. 18 at 1800a compares the results of the herein disclosed embodiments ("Inv. Cone") to the results of prior art ("Prior Art") together with the link capacity ("Link"). Fig. 18 at 1800b shows the active queue management (AQM) packet loss rate in percent. Fig. 18 at 1800c shows the throughput for the herein disclosed embodiments. Fig. 18 at lSood shows the delay for the herein disclosed embodiments. Fig. 18 at i8ooe shows the throughput for prior art. Fig. 18 at i8oof shows the delay for prior art. The results of Fig. 18 are consistent with the results of Fig. 17; in the results of Fig, 18 the difference between the prior art and the herein disclosed embodiments is even larger with the herein disclosed embodiments yielding lower and shorter congestion induced delay than the prior art.

The inventive concept has mainly been described above with reference to a few embodiments. However, as is readily appreciated by a person skilled in the art, other embodiments than the ones disclosed above are equally possible within the scope of the inventive concept. For example, although the term packet has been used to denote the entity received by the receiving electronic device 12b, i2d from the transmitting electronic device 12a, 12c, each such packet may, or may not, correspond to a single frame. Each such packet and/or frame may correspond to one packet and/or frame of multimedia content.

Claims

1. A method for determining a bitrate request, BRR, for a multimedia encoder (18) of a transmitting electronic device (12a, 12c), the method being performed by a receiving electronic device (12b, I2d), the method

comprising:

estimating (S102) receive bitrate and send bitrate of packets received from the transmitting electronic device using a model of packet arrival time as a function of at least packet send time;

estimating (S104) congestion induced delay of the packets based on the model of packet arrival time and classifying the estimated congestion induced delay into one of at least two classes based on at least one of the model of packet arrival time, receive bitrate and send bitrate, wherein at least one of the at least two classes comprises at least two subclasses; and

determining (S106) the BRR based on what class or subclass the congestion induced delay has been classified into and based on at least one of the receive bitrate and the send bitrate, wherein determination of the BRR differs for each class and subclass.

2. The method according to claim 1, wherein there are at least three classes.

3. The method according to claim 1 or 2, wherein one of the at least two classes corresponds to the congestion induced delay being below a packet delay threshold value.

4. The method according to claim 1, wherein one of the at least two classes corresponds to a difference between an actual value of the congestion induced delay and a predicted value of the congestion induced delay being below a packet delay threshold value.

5. The method according to any of the preceding claims, wherein one of the at least two classes corresponds to smooth congestion induced delay.

6. The method according to claim 5, wherein the congestion induced delay is classified as smooth if the congestion induced delay is above a packet delay threshold value and a rate of the congestion induced delay increases slower than a rate threshold.

7. The method according to claim 6, wherein the congestion induced delay is above the packet delay threshold value if an estimated packet arrival time f„ of the packets exceeds a threshold.

8. The method according to claim 6, wherein determining that the congestion induced delay is above the packet delay threshold value comprises;

acquiring (Si04a) time intervals over which an estimated send bitrate exceeds that of the estimated receive bitrate;

determining (8104b) a total bitrate difference over the time intervals; and

determining (8104c) when the total bitrate difference exceeds the packet delay threshold value multiplied with a current estimate of the receive bitrate.

9. The method according to any of the preceding claims, wherein one of the at least two classes corresponds to abrupt congestion induced delay.

10. The method according to claim 9, wherein the congestion induced delay is classified as abrupt if the congestion induced delay is above a packet delay threshold value and a rate of the congestion induced delay increases faster than a rate threshold.

11. The method according to any of the preceding claims, wherein the abrupt congestion induced delay is detected by means of a prediction model.

12. The method according to claim 8 or 9, wherein the class corresponding to abrupt congestion induced delay comprises at least two subclasses.

13. The method according to any of the preceding claims, wherein there are at least three subclasses.

14. The method according to any of the preceding claims, wherein one of the at least two subclasses corresponds to a monotonically increasing congestion induced delay.

15. The method according to claim 14, wherein in a case the congestion induced delay has been classified as monotonically increasing congestion induced delay, the method further comprising:

updating (Sio6a) the estimated receive bitrate and send bitrate and determining an updated BRR,

16. The method according to any of the preceding claims, wherein one of the at least two subclasses corresponds to a step-like increasing congestion induced delay.

17. The method according to claim 16, wherein in a case the congestion induced delay has been classified as step-like increasing congestion induced delay, the method further comprising:

determining (Sio6b) the BRR based on evaluating at least one test case.

18. The method according to any of the preceding claims, wherein one of the at least two subclasses corresponds to a short delay pulse.

19. The method according to claim 18, wherein in a case the congestion induced delay has been classified as a short delay pulse, the method farther comprising:

leaving (Sio6c) the BRR unchanged.

20. The method according to any of the preceding claims, wherein recursive estimates of the packet arrival time are obtained from modelling noisy packet arrival time values as a function of at least packet send time.

21. The method according to claim 20, wherein the recursive estimates of the packet arrival time are used to estimate an immediate receiving bitrate.

22. The method according to claim 20 or 21, wherein the recursive estimates of the packet arrival time are obtained through a least squares estimation involving the noisy packet arrival time values and arrival time model.

23. The method according to claim 22, further comprising:

acquiring (Si02a) filtered arrival time values from the recursive estimates of the packet arrival time; and

estimating (Si02b) the receive bitrate based on the filtered arrival time values.

24. The method according to any of the preceding claims, further

comprising:

acquiring (Sio4d) further packets to determine which subclass to classify the received packets.

25. The method according to any of the preceding claims, further

comprising:

determining (Si 04ε) whether the congestion induced delay has been repealed by comparing a current estimated congestion induced delay to a threshold.

26. The method according to claim 25, further comprising, if the congestion induced delay has been evaluated as repealed:

classifying (S1041) the estimated congestion induced delay in the class of the at least two classes that corresponds to no congestion induced delay.

27. The method according to any of the preceding claims, wherein what model to use to estimate receive bitrate of next packets depends on in which class of the at least two classes the estimated congestion induced delay lias been classified.

28. The method according to any of the preceding claims, wherein the model of packet arrival time as a function of at least packet send time involves estimating the packet arrival time ?„ based on path capacity C, packet size L_n, a constant time offset T, packet send time t_n, a time scaling actor a, and a white zero mean stochastic process v„.

29. The method according to claim 28, wherein the model of packet arrival time as a function of at least packet send time is given by: im = in + ^T + «t_n + ¾.

30. The method according to claim 28 or 29, wherein congestion induced delay of the packets is determined if a-i≥ 8, where 5 is a threshold value.

31. The method according to claim 28, 29, or 30, wherein no congestion induced delay of the packets is determined if |α-ι|≤ 8, where 8 is a threshold value.

32. The method according to claim 28, 29, 30, or 31, wherein recovery of congestion induced delay of the packets is determined if a-i < 8, where 8 is a threshold value.

33. An electronic device (12b, I2d) for determining a bitrate request, BRR, for a multimedia encoder of a transmitting electronic device (12a, 12c), the electronic device comprising a processing unit (22) configured to:

estimate receive bitrate and send bitrate of packets received from the transmitting electronic device using a model of packet arrival time as a function of at least packet send time;

estimate congestion induced delay of the packets based on the model of packet arrival time and classify the estimated congestion induced delay into one of at least two classes based on at least one of the model of packet arrival time, receive bitrate and send bitrate, wherein at least one of the at least two classes comprises at least two subclasses; and

determine the BRR based on what class or subclass the congestion induced delay has been classified into and based on at least one of the receive bitrate and the send bitrate, wherein determination of the BRR differs for each class and subclass .

34. An electronic device (12b, I2d) for determining a bitrate request, BRR, for a multimedia encoder of a transmitting electronic device (12a, 12c), the electronic device comprising: an estimate module (21a) configured to estimate receive bitrate and send bitrate of packets received from the transmittiEg electronic device using a model of packet arrival time as a function of at least packet send time;

the estimate module (21a) further being configured to estimate congestion induced delay of the packets based on the model of packet arrival time, a classify module (2ie) configured to classify the estimated congestion induced delay into one of at least two classes based on at least one of the model of packet arrival time, receive bitrate and send bitrate, wherein at least one of the at least two classes comprises at least two subclasses; and

a determine module (21b) configured to determine the BRR based on what class or subclass the congestion induced delay has been classified into and based on at least one of the receive bitrate and the send bitrate, wherein determination of the BRR differs for each class and subclass.

35. A computer program (32) for determining a bitrate request, BRR, for a multimedia encoder of a transmitting electronic device (12a, 12c), the computer program comprising computer program code which, when run on a receiving electric device (12b, I2d), causes the processing unit to;

estimate (S102) receive bitrate and send bitrate of packets received from the transmitting electronic device using a model of packet arrival time as a function of at least packet send time;

estimate (S104) congestion induced delay of the packets based on the model of packet arrival time and classify the estimated congestion induced delay into one of at least two classes based on at least one of the model of packet arrival time, receive bitrate and send bitrate, wherein at least one of the at least two classes comprises at least two subclasses; and

determine (Si 06) the BRR based on what class or subclass the congestion induced delay has been classified into and based on at least one of the receive bitrate and the send bitrate, wherein determination of the BRR differs for each class and subclass.

36. A computer program product (31) comprising a computer program (32) according to claim 35 and a computer readable means (33) on which the computer program, is stored.