Systems and methods for sharing bandwidth across multiple video streams

CA 02886681 2015-03-30

WO 2014/066600 PCT/US2013/066548

Systems and Methods for Sharing Bandwidth Across Multiple Video Streams

Field of the Disclosure

[0001] The present disclosure relates generally to wireless networks and more particularly to systems and methods for sharing bandwidth across multiple video streams in a wireless network.

Background

[0002] In wireless networks, available effective bandwidth can vary from time to time depending on the channel conditions. For video over wireless networks and for good user experience, video senders need to adapt transmission bit rate based on available bandwidth. The video senders can rely on feedback from receivers to “guess” the available bandwidth. The feedback can include a RTP Control Protocol (RTCP) receiver report in Real-time Transport Protocol (RTP) for User Datagram Protocol (UDP) based systems or the effective throughput as seen by the sender in case of Hypertext Transfer Protocol (HTTP) based systems. Note, this feedback is on a perstream basis, e.g. for each RTP media stream, there is a corresponding RTCP feedback channel which carries feedback about that and only that media stream. In clients (receivers) which receive more than one video stream at a time, various problems exist in conventional systems and methods. For example, since RTCP receiver reports are independent and are specific to a stream, the actions taken in response to these reports are applied only to those streams. For example, bit rate upshifts and downshifts will happen independently for each stream. The feedback intervals usually will not be aligned (though equal in duration) as each stream is an independent session and could have been established at different times. Due to the non-alignment, a spurt in losses may or may not result in all streams downshifting at the same time and some may not downshift at all. Similarly, not having any losses over a period of time may or may not result in all streams upshifting and some may not upshift at all. This unsynchronized behavior will cause some streams downshift too much and some other streams upshift too much, resulting in asymmetric profiles.

CA 02886681 2015-03-30

WO 2014/066600

PCT/US2013/066548

From a user perspective, this would result in seeing one stream with good quality and another stream with bad quality on a same wireless connection.

[0003] Accordingly, there is a need for fairly sharing bandwidth across multiple video streams in a wireless network. Similarly, in some situations there could be a need for the client to differentiate between multiple streams in terms of quality in lossy conditions, during the session. It might want to accord higher priority to some streams compared to others.

Brief Description of the Figures

[0004] The accompanying figures, where like reference numerals refer to identical or functionally similar elements throughout the separate views, together with the detailed description below, are incorporated in and form part of the specification, and serve to further illustrate embodiments of concepts that include the claimed invention, and explain various principles and advantages of those embodiments.

[0005] FIG. f is a block diagram of a multiple video stream system for fairly sharing bandwidth in a wireless network in accordance with some embodiments.

[0006] FIG. 2 is a block diagram of an exemplary operation of five video streams sent wirelessly to a client device with five profiles in accordance with some embodiments.

[0007] FIG. 3 is a flowchart of a client-based method for fairly sharing bandwidth across multiple video streams in accordance with some embodiments.

[0008] FIG. 4 is a flowchart of a RTP protocol method for use with the client-based method of FIG. 3 in accordance with some embodiments.

[0009] FIG. 5 is a flowchart of an averaged report method for use with the clientbased method of FIG. 3 in accordance with some embodiments.

[0010] FIG. 6 is a flowchart of a manipulated report method for use with the clientbased method of FIG. 3 in accordance with some embodiments.

[0011] FIG. 7 is a flowchart of an upshift/downshift method for use with the clientbased method of FIG. 3 in accordance with some embodiments.

CA 02886681 2015-03-30

WO 2014/066600

PCT/US2013/066548

[0012] FIG. 8 is a flowchart of a UDP method for use with the client-based method of

FIG. 3 in accordance with some embodiments.

[0013] FIG. 9 is a flowchart of a server-based method for fairly sharing bandwidth across multiple video streams in accordance with some embodiments.

[0014] FIG. 10 is a flowchart of a Transmission Control Protocol (TCP) method for use with the server-based method of FIG 9 in accordance with some embodiments.

[0015] FIG. 11 is a diagram of an exemplary operation of an average report method in accordance with some embodiments.

[0016] FIG. 12 is a diagram of an exemplary operation of a manipulated report method in accordance with some embodiments.

[0017] FIG. 13 is a block diagram of a server for use in the system of FIG. 1 and the various methods in accordance with some embodiments.

[0018] FIG. 14 is a block diagram illustrates the client device 12 for use in the system 10 and the various methods in accordance with some embodiments.

[0019] Skilled artisans will appreciate that elements in the figures are illustrated for simplicity and clarity and have not necessarily been drawn to scale. For example, the dimensions of some of the elements in the figures may be exaggerated relative to other elements to help to improve understanding of embodiments of the present invention.

[0020] The apparatus and method components have been represented where appropriate by conventional symbols in the drawings, showing only those specific details that are pertinent to understanding the embodiments of the present invention so as not to obscure the disclosure with details that will be readily apparent to those of ordinary skill in the art having the benefit of the description herein.

Detailed Description

[0021] In an exemplary embodiment, a client-based method includes receiving a plurality of video streams at a client device over a wireless connection, wherein each

CA 02886681 2015-03-30

WO 2014/066600

PCT/US2013/066548 of the plurality of video streams operates at one of a plurality of associated profiles, determining feedback for each of the plurality of video streams, determining modified feedback for each of the plurality of video streams based on the feedback for each of the plurality of video streams, and transmitting the modified feedback for each of the plurality of video streams to an associated source of each of the plurality of video streams.

[0022] In another exemplary embodiment, a server-based method includes transmitting a plurality of video streams to a client device from at least one server, wherein each of the plurality of video streams operates at one of a plurality of associated profiles, receiving feedback for each of the plurality of video streams, wherein the feedback is modified by at least one server such that each of the plurality of video streams has substantially a same bandwidth, determining if adjustments are required to associated profiles of each of the plurality of video streams, and, if adjustments are required, transmitting the plurality of video streams at different associated profiles of the plurality of associated profiles based on the adjustments.

[0023] In yet another exemplary embodiment, a client device includes a network interface communicatively coupled to a wireless network, a processor communicatively coupled to the network interface, and memory storing instructions that, when executed, cause the processor and the network interface to: receive a plurality of video streams at a client device over the wireless network, wherein each of the plurality of video streams operates at one of a plurality of associated profiles, determine feedback for each of the plurality of video streams, determine modified feedback for each of the plurality of video streams based on the feedback for each of the plurality of video streams, and transmit the modified feedback for each of the plurality of video streams to an associated source of each of the plurality of video streams.

[0024] Referring to FIG. 1, in an exemplary embodiment, a block diagram illustrates a multiple video stream system 10 for fairly sharing bandwidth in a wireless network. In particular, the system 10 includes a client device 12 with a wireless connection 14 to a network 16. For example, the client device 12 can include a digital cellular phone,

CA 02886681 2015-03-30

WO 2014/066600

PCT/US2013/066548 a smart phone, a personal digital assistant, a tablet device, an ultra book, a net book, a laptop, a mobile data terminal, a desktop with a wireless interface, or the like. The system 10 further includes one or more servers 20 which are communicatively coupled to the network 16. In an exemplary embodiment, the network 16 can include the Internet, Virtual Private Networks (VPNs), Local Area Networks (LANs), Wireless provider networks (e.g., 3G, 4G, etc.), Wireless LAN (WiFi), and combinations thereof. That is, the client device 12 can connect to a wireless network which is communicatively coupled to a private or public IP network (such as Internet). The servers 20 can connect to a LAN which is communicatively coupled to the network (such as Internet). In FIG. 1, these various networks are singularly illustrated by the network 16 for illustration purposes.

[0025] In operation, the system 10 includes the servers 20 and the client device 12 streaming multiple video streams therebetween with various mechanisms for effective bit rate management of the multiple video streams in a consolidated or collective manner. Importantly, these mechanisms in the system 10 ensure a user of the client device 12 does not see one stream go down to the lowest profile (i.e., lowest quality) where as the other streams stay at higher profile (i.e., higher quality), when all the streams are sharing the same physical medium and are expected to see same channel conditions. In various exemplary embodiments, the system 10 can utilize RTCP, RTP, UDP, HTTP, etc. RTCP and RTP are defined in RFC 3550 (July 2003), “RTP: A Transport Protocol for Real-Time Applications,” the contents of which are incorporated by reference herein.

[0026] Variously, bit rate management systems and methods are implemented in the system 10 in a manner fully preserving operation of the various standards and protocols thereby not impacting interoperability with existing devices. These bit rate management systems and methods can be implemented in one of the client device 12 or the servers 20. For example, if the bit rate management systems and methods are implemented in the client device 12, the server 20 could operate fully in accordance with existing standards and protocols without modification thereof. Conversely, if the bit rate management systems and methods are implemented in the server 20, the client device 12 could operate fully in accordance with existing standards and protocols

CA 02886681 2015-03-30

WO 2014/066600

PCT/US2013/066548 without modification thereof. No extensions are required to RTP, RTCP, etc. protocol messages so the bit rate management systems and methods can operate with any standards compliant devices.

[0027] Referring to FIG. 2, in an exemplary embodiment, a block diagram illustrates an exemplary operation 25 of five video streams 26 sent wirelessly to a client device with five profiles 28. As described herein, in lossy wireless networks, the available effective bandwidth could vary from time to time, depending on the channel conditions. To improve user experience, video senders (e.g., the servers 20) adapt their bit rate based on available bandwidth. The video senders rely on feedback from the receivers (e.g., the client device 12) to “guess” the available bandwidth. The feedback is usually one of the following: RTCP Receiver report in RTP/UDP-based systems or effective throughput as seen by the sender in case of HTTP based systems. As described herein, a profile defines how a source is transmitted from the video sender to the client in terms of bit rates, frame rates, resolution, etc. It is expected that each source will have multiple profiles that may be upshifted or downshifted to/from based on current channel conditions. RTP/RTCP receiver reports are described in RFC 3550 and extensions are described in RFC 3611 (November 2003), “RTP Control Protocol Extended Reports (RTCP XR),” the contents of which are incorporated by reference herein.

[0028] The video sender, e.g. the servers 20, can employ the following techniques. The video sender can maintain a pre-defined set of profiles, e.g. the profiles 28, and typically with each profile has a different bit rate and possibly different resolution and frame rate. Depending on the feedback and “guessed-channel-bandwidth”, the video sender moves to the profile best suited for that channel condition. The feedback report is usually for a pre-defined interval (e.g., in case of RTCP, it is the receiver report (RR) interval or, in the case of HTTP, it is effective throughput as seen by the sender during that interval). Multiple such reports (consecutive) are considered for taking a decision to downshift (move to a lower profile) or upshift (move to an upper profile) to avoid taking decisions based on random one-time events. The video sender will upshift or downshift depending on whether it sees increase or decrease in

CA 02886681 2015-03-30

WO 2014/066600

PCT/US2013/066548 bandwidth. Advantageously, this helps the end users receive a better viewing experience.

[0029] In the exemplary operation 25, the client device is viewing the five streams 26 simultaneously. Each of the streams 26 has five corresponding profiles 28 and a default profile (designated with a (D) in FIG. 2). These profiles and default profiles can be preconfigured by the administrator based on the client network and other conditions. Note, the default profile does not need to be the middle profile 34. For example, taking Source A (Src A) as an example, the profile Pal has a lower bit rate, lower resolution, and/or lower frame rate from the profile Pa2, the profile Pa2 is lower than the profile Pa3, etc. When the client connects to the video sender, the video sender typically starts with the default profile. If the video sender sees bad channel conditions, the video sender downshifts to a lower profile, and if the video sender sees good channel conditions, the video sender tries to upshift to a higher profile.

[0030] In conventional systems and methods the feedback is on a per-stream basis. In the system 10 and with the bit rate management systems and methods implemented thereon, the feedback is on an aggregate basis across all of the streams. In an exemplary embodiment, using RTCP, the feedback is modified at the client device 12 such that each of the servers 20 upshifts or downshifts each of the video streams in a uniform manner. In such configurations, the servers 20 can be fully compliant to RTCP without requiring modifications to implement the bit rate management systems and methods. Here, the client device 12 also sends the RTCP RR reports in a fully compliant manner to RTCP with preprocessing done of the data to ensure that the video streams are handled in the uniform manner. In another exemplary embodiment, the servers 20 can utilize the effective throughput in HTTP to ensure the video streams are handled in the uniform manner.

[0031] Accordingly, with the bit rate management systems and methods, one of the streams 26 does not downshift its profile 28 while another one of the streams 26 upshifts its profile 28. The existing standards and protocols include feedback loops to manage video streams over varying channels such as wireless. However, this feedback loops operate autonomously on separate streams on the same physical link.

CA 02886681 2015-03-30

WO 2014/066600

PCT/US2013/066548

The bit rate management systems and methods utilize these feedback loops by managing the input or output on either side of these feedback loops to maintain compliance to existing standards and protocols while simultaneously removing this autonomous operation on separate streams on the same physical link. Thus, the bit rate management systems and methods provide uniform viewing of multiple video streams in a standards compliant manner without modifying the over air signaling, all modifications are either done at the client device 12 or the server 20.

[0032] Referring to FIG. 3, in an exemplary embodiment, a flowchart illustrates a client-based method 30 for fairly sharing bandwidth across multiple video streams. In an exemplary embodiment, the client-based method 30 can be implemented by the client device 12 in the system 10. For example, the client device 12 can include a network interface communicatively coupled to a wireless network, such as via the wireless connection 14, a processor communicatively coupled to the network interface, and memory storing instructions that, when executed, cause the processor and the network interface to perform the various steps described herein. The client-based method 30 includes receiving a plurality of video streams at a client device over a wireless connection, wherein each of the plurality of video streams operates at one of a plurality of associated profiles (step 31).

[0033] The client-based method 30 includes determining feedback for each of the plurality of video streams (step 32). The client-based method 30 contemplates use with various protocols which rely on feedback loops from the client device to the associated video sources to determine whether appropriate adjustments. For example, the client-based method 30 contemplates use with RTP, RTCP, UDP, etc., and not with Transmission Control Protocol (TCP) which is a connection-oriented protocol with the video sources already knowing throughput without requiring feedback from the client device. An objective of the client-based method 30 is to modify inputs or outputs of these feedback loops such that there are no modifications or extensions to existing protocols (i.e., RTP, RTCP, UDP, etc.) and such that the plurality of video streams are seen in a consistently similar manner, i.e. such that each of the plurality of video streams has about the same amount of bandwidth on the same wireless connection.

CA 02886681 2015-03-30

WO 2014/066600

PCT/US2013/066548

[0034] The feedback can include any mechanism that alerts the associated sources of each of the plurality of video streams to required adjustments (or not). In an exemplary embodiment, the feedback can be packet loss ratio (or packet loss rate) over some reporting interval, e.g. 5s. This feedback tells the associated sources whether or not the plurality of video streams need to be adjusted (i.e., upshifted or downshifted in profile). The client-based method 30 includes determining modified feedback for each of the plurality of video streams based on the feedback for each of the plurality of video streams (step 33). An objective of the client-based method 30 is to modify this feedback at the client device so as to ensure consistency in the plurality of video streams and to maintain operation in accordance with existing standards and protocols. Finally, the client-based method includes transmitting the modified feedback for each of the plurality of video streams to an associated source of each of the plurality of video streams (step 34).

[0035] The determination of the modified feedback can be performed using various techniques by the client device to ensure consistency between the plurality of video streams. In an exemplary embodiment, the modified feedback can include sending “averaged” reports to the associated sources. Here, the client device can group the individual streams as one stream when computing the packet loss ratio (PFR). The weighted average PFR computed across multiple streams, can be forwarded as the PFR for individual streams. With this, the associated sources treat all the plurality of video streams similarly, i.e. the upshift or downshift will happen for all the streams at the same time.

[0036] In another exemplary embodiment, the modified feedback can include sending “manipulated” reports to the associated sources. Here, the client device sends reports based on what the client device wants to the associated sources to see, rather than what the client device actually sees on the plurality of video streams. For example, if the associated sources are sending two streams at 380 and 280 kbps respectively, but the client device is receiving them at 360 kbps and 280 kbps, and the client device wants them to share the available 640 kbps bandwidth equally, the client device reports the losses in such a way that both the streams move up to 320 kbps. In this “manipulated” report method, the client device may not see the associated sources

CA 02886681 2015-03-30

WO 2014/066600

PCT/US2013/066548 operating at the same profile for all the streams, as the client device is actually determining what the absolute bit rate should be for each stream.

[0037] Referring to FIG. 4, in an exemplary embodiment, a flowchart illustrates a RTP protocol method 40 for use with the client-based method 30 of FIG. 3. The RTP protocol method 40 includes utilizing Real Time Control Protocol and Real Time Protocol between the client device and the associated source of each of the plurality of video streams (step 41). Again, as described herein, an objective of the RTP protocol method 40 is to maintain standards compliant over-the-air signaling between the client device and the associated sources. The RTP protocol method 40 includes operating each of the associated sources of each of the plurality of video streams in accordance with the Real Time Control Protocol and the Real Time Protocol (step 42). The RTP protocol method 40 includes determining the modified feedback by the client device (step 43).

[0038] The RTP protocol method 40 further includes transmitting the modified feedback for each of the plurality of video streams to the associated source of each of the plurality of video streams without requiring extensions or modifications to the Real Time Control Protocol and the Real Time Protocol (step 44). The RTP protocol method 40 further includes determining the feedback for each of the plurality of video streams utilizing packet loss ratio (step 45). The RTP protocol method 40 further includes transmitting the modified feedback in a Receiver Report packet to each of the associated sources of each of the plurality of video streams. Of note, the Receiver Report packet is defined in RFC 3550.

[0039] Referring to FIG. 5, in an exemplary embodiment, a flowchart illustrates an averaged report method 50 for use with the client-based method 30 of FIG. 3. For example, the averaged report method 50 can be an implementation of the “averaged” reports described herein. The averaged report method 50 includes grouping the plurality of video streams as a single stream for determining the feedback (step 51). Note, the plurality of video streams is still received and displayed separately, but are grouped for feedback determination. The averaged report method 50 includes computing a packet loss ratio across the single stream (step 52).

io

CA 02886681 2015-03-30

WO 2014/066600

PCT/US2013/066548

[0040] The averaged report method 50 further includes determining a weighted average of the packet loss ratio (step 53). For example, this determination can be done through the following equation:

PLR,

<img file="CA2886681A1_D0001.tif" />

Where PLR_t is the overall packet loss ratio (PLR), PLR; is the PLR of individual video stream i with i being the number of video streams, and R; is the bit rate of the individual video streams.

[0041] The averaged report method 50 further includes transmitting the weighted average in a Receiver Report packet to each of the associated sources of each of the plurality of video streams (step 54). Finally, the averaged report method 50 includes upshifting or downshifting to one of the plurality of associated profiles at each of the associated sources of each of the plurality of video streams in a similar, uniform manner upon receipt of the weighted average in the Receiver Report packet.

[0042] Referring to FIG. 6, in an exemplary embodiment, a flowchart illustrates a manipulated report method 60 for use with the client-based method 30 of FIG. 3. For example, the manipulated report method 60 can be an implementation of the “manipulated” reports described herein. The manipulated report method 60 includes determining an available bandwidth for the client device over the wireless connection (step 61). The manipulated report method 60 includes determining a current bandwidth for each of the plurality of video streams, wherein the current bandwidth for each of the plurality of video streams is based on the feedback for each of the plurality of video streams (step 62).

[0043] The manipulated report method 60 includes determining the modified feedback for each of the plurality of video streams such that each of the plurality of video streams utilizes a substantially same amount of the available bandwidth (step 63). In an exemplary embodiment, at least two of the plurality of video streams are operating at different profiles of the plurality of associated profiles. Specifically, the manipulated report method 60 does not necessarily upshift and/or downshift the

CA 02886681 2015-03-30

WO 2014/066600

PCT/US2013/066548 plurality of video streams in a consolidated or uniform manner. Rather, the manipulated report method 60 seeks to manage the expected bit rate at the client device such that each of the plurality of video streams has substantially the same amount of bandwidth.

[0044] Referring to FIG. 7, in an exemplary embodiment, a flowchart illustrates an upshift/downshift method 70 for use with the client-based method 30 of FIG. 3. The upshift/downshift method 70 includes, subsequent to transmitting the modified feedback and if the modified feedback is above a downshift threshold, receiving the plurality of video streams at the client device over the wireless connection with each of the plurality of video streams downshifted to one of the plurality of associated profiles (step 71). The upshift/downshift method 70 includes, subsequent to transmitting the modified feedback and if the modified feedback is below an upshift threshold, receiving the plurality of video streams at the client device over the wireless connection with each of the plurality of video streams upshifted to one of the plurality of associated profiles (step 72).

[0045] The upshift/downshift method 70 includes, subsequent to the upshift, if the client device experiences packet losses below a threshold, maintaining the plurality of video streams upshifted to one of the plurality of associated (step 73). The upshift/downshift method 70 further includes if the client device experiences packet losses at or above the threshold, performing a back-off process until the client device experiences packet losses below the threshold (step 74). The upshift/downshift method 70 further includes performing the back-off process by backing off a stream of the plurality of streams with a highest bit rate and continuing backing off subsequent streams of the plurality of streams with next highest bit rates until the client device experiences packet losses below the threshold (step 75).

[0046] Referring to FIG. 8, in an exemplary embodiment, a flowchart illustrates a UDP method 80 for use with the client-based method 30 of FIG. 3. The UDP method 80 includes operating each of the associated source of each of the plurality of video streams in accordance with the User Datagram Protocol (step 81). The UDP method 80 further includes determining the modified feedback by the client device as an

CA 02886681 2015-03-30

WO 2014/066600

PCT/US2013/066548 average packet loss ratio across all of the plurality of video streams (step 82). Finally, the UDP method 80 includes transmitting the modified feedback for each of the plurality of video streams to the associated source of each of the plurality of video streams without requiring extensions or modifications to the User Datagram Protocol (step 83).

[0047] Referring to FIG. 9, in an exemplary embodiment, a flowchart illustrates a server-based method 90 for fairly sharing bandwidth across multiple video streams. In an exemplary embodiment, the server-based method 90 can be implemented by the server 20 in the system 10. For example, the server 20 can include a network interface communicatively coupled to a network, such as the network 16, a processor communicatively coupled to the network interface, and memory storing instructions that, when executed, cause the processor and the network interface to perform the various steps described herein. The server-based method 90 includes transmitting a plurality of video streams to a client device from at least one server, wherein each of the plurality of video streams operates at one of a plurality of associated profiles (step 91).

[0048] The server-based method 90 further includes receiving feedback for each of the plurality of video streams, wherein the feedback is modified by one of the client device and the at least one server such that each of the plurality of video streams has substantially a same bandwidth (step 92). The feedback can be modified via the various methods described herein. The server-based method 90 includes determining if adjustments are required to associated profiles of each of the plurality of video streams (step 93). Finally, server-based method 90 can include, if adjustments are required, transmitting the plurality of video streams at different associated profiles of the plurality of associated profiles based on the adjustment (step 94).

[0049] Referring to FIG. 10, in an exemplary embodiment, a flowchart illustrates a TCP method 100 for use with the server-based method 90 of FIG 9. The TCP method 100 includes transmitting the plurality of video streams to the client device from the at least one server utilizing Transmission Control Protocol (step 101). The TCP method 100 further includes receiving the feedback at the at least one server via throughput

CA 02886681 2015-03-30

WO 2014/066600

PCT/US2013/066548 over the Transmission Control Protocol (step 102). Finally, the TCP method 100 includes adjusting the plurality of video streams in a consolidated manner based on the throughput over the Transmission Control Protocol (step 103).

[0050] Referring to FIG. 11, in an exemplary embodiment, a diagram illustrates an exemplary operation 200 of an average report method. The exemplary operation 200 includes five streams 202 to the client device 12 showing packet loss ratio for a plurality of reporting intervals 204 (labeled 204-1, 204-2, 204-n). In the first reporting interval 204-1, stream 1 has PLR = 20%, stream 2 has PLR = 25%, stream 3 has PLR = 16%, stream 4 has PLR = 19%, and stream 5 has PLR = 0%. This yields an average PLR = 16% which is reported to each of the associated sources of each of the streams 202. That is, stream 1 reports PLR = 16% even though it’s actual PLR = 20%, etc. Assuming a threshold of 15%, each of the streams will downshift in the reporting interval 204-1. In the reporting interval 204-2, each stream has PLR = 0% except the stream 5 which has PLR = 20%. Thus, in the reporting interval 204-2, each stream reports PLR = 4% based thereon.

[0051] Referring to FIG. 12, in an exemplary embodiment, a diagram illustrates an exemplary operation 250 of a manipulated report method. In particular, the exemplary operation 250 is illustrated with two graphs 252, 254 of four streams 256. The graph 252 represents actual loss experienced by each of the four streams 256, i.e. 30%, 25%, 16%, and 29%. The graph 254 represents the actual loss reported by each of the four streams 256 using the manipulated report method. In particular, the client receiving the four streams 256 manipulates the actual reports sent to a server. In the exemplary operation 250, the first stream has a high priority, so the client manipulates the packet loss ratio to 0% and reports 0%. The actual loss of the first stream, i.e. 30%, can be equally distributed across the remaining streams, i.e. 10% each. Thus, using the manipulated report method, the first stream 1 is not downshifted because of the manipulated reports.

[0052] Referring to FIG. 13, in an exemplary embodiment, a block diagram illustrates the server 20 for use in the system 10 and the various methods. The server 20 can be a digital computer that, in terms of hardware architecture, generally includes a

CA 02886681 2015-03-30

WO 2014/066600

PCT/US2013/066548 processor 302, input/output (I/O) interfaces 304, a network interface 306, a data store 308, and memory 310. It should be appreciated by those of ordinary skill in the art that FIG. 13 depicts the server 20 in an oversimplified manner, and a practical embodiment may include additional components and suitably configured processing logic to support known or conventional operating features that are not described in detail herein. The components (302, 304, 306, 308, and 310) are communicatively coupled via a local interface 312. The local interface 312 can be, for example but not limited to, one or more buses or other wired or wireless connections, as is known in the art. The local interface 312 can have additional elements, which are omitted for simplicity, such as controllers, buffers (caches), drivers, repeaters, and receivers, among many others, to enable communications. Further, the local interface 312 can include address, control, and/or data connections to enable appropriate communications among the aforementioned components.

[0053] The processor 302 is a hardware device for executing software instructions. The processor 302 can be any custom made or commercially available processor, a central processing unit (CPU), an auxiliary processor among several processors associated with the server 20, a semiconductor-based microprocessor (in the form of a microchip or chip set), or generally any device for executing software instructions. When the server 20 is in operation, the processor 302 is configured to execute software stored within the memory 310, to communicate data to and from the memory 310, and to generally control operations of the server 20 pursuant to the software instructions. The I/O interfaces 304 can be used to receive user input from and/or for providing system output to one or more devices or components. User input can be provided via, for example, a keyboard, touch pad, and/or a mouse. System output can be provided via a display device and a printer (not shown). I/O interfaces 304 can include, for example, a serial port, a parallel port, a small computer system interface (SCSI), a serial ATA (SATA), a fibre channel, Infiniband, iSCSI, a PCI Express interface (PCI-x), an infrared (IR) interface, a radio frequency (RF) interface, and/or a universal serial bus (USB) interface.

[0054] The network interface 306 can be used to enable the server 20 to communicate on a network, such as the network 16 to receive parameters associated with mobile

CA 02886681 2015-03-30

WO 2014/066600 PCT/US2013/066548 devices. The network interface 306 can include, for example, an Ethernet card or adapter (e.g., lOBaseT, Fast Ethernet, Gigabit Ethernet, lOGbE) or a wireless local area network (WLAN) card or adapter (e.g., 802.11a/b/g/n). The network interface 306 can include address, control, and/or data connections to enable appropriate communications on the network. A data store 308 can be used to store data. The data store 308 can include any of volatile memory elements (e.g., random access memory (RAM, such as DRAM, SRAM, SDRAM, and the like)), nonvolatile memory elements (e.g., ROM, hard drive, tape, CDROM, and the like), and combinations thereof. Moreover, the data store 308 can incorporate electronic, magnetic, optical, and/or other types of storage media. In one example, the data store 308 can be located internal to the server 20 such as, for example, an internal hard drive connected to the local interface 312 in the server 20. Additionally in another embodiment, the data store 308 can be located external to the server 20 such as, for example, an external hard drive connected to the I/O interfaces 304 (e.g., SCSI or USB connection). In a further embodiment, the data store 308 can be connected to the server 20 through a network, such as, for example, a network attached file server.

[0055] The memory 310 can include any of volatile memory elements (e.g., random access memory (RAM, such as DRAM, SRAM, SDRAM, etc.)), nonvolatile memory elements (e.g., ROM, hard drive, tape, CDROM, etc.), and combinations thereof. Moreover, the memory 310 can incorporate electronic, magnetic, optical, and/or other types of storage media. Note that the memory 310 can have a distributed architecture, where various components are situated remotely from one another, but can be accessed by the processor 302. The software in memory 310 can include one or more software programs, each of which includes an ordered listing of executable instructions for implementing logical functions. The software in the memory 310 includes a suitable operating system (O/S) 314 and one or more programs 316. The operating system 314 essentially controls the execution of other computer programs, such as the one or more programs 316, and provides scheduling, input-output control, file and data management, memory management, and communication control and related services. The one or more programs 316 may be configured to implement the

CA 02886681 2015-03-30

WO 2014/066600

PCT/US2013/066548 various processes, algorithms, methods, techniques, etc. described herein. For example, the programs 316 can be configured to enable the methods described herein. [0056] Referring to FIG. 14, in an exemplary embodiment, a block diagram illustrates the client device 12 for use in the system 10 and the various methods. The client device 12 can be a digital device that, in terms of hardware architecture, generally includes a processor 412, input/output (I/O) interfaces 414, a radio 416, a data store 418, and memory 422. It should be appreciated by those of ordinary skill in the art that FIG. 14 depicts the client device 12 in an oversimplified manner, and a practical embodiment can include additional components and suitably configured processing logic to support known or conventional operating features that are not described in detail herein. The components (412, 414, 416, 418, and 422) are communicatively coupled via a local interface 424. The local interface 424 can be, for example but not limited to, one or more buses or other wired or wireless connections, as is known in the art. The local interface 424 can have additional elements, which are omitted for simplicity, such as controllers, buffers (caches), drivers, repeaters, and receivers, among many others, to enable communications. Further, the local interface 424 may include address, control, and/or data connections to enable appropriate communications among the aforementioned components.

[0057] The processor 412 is a hardware device for executing software instructions. The processor 412 can be any custom made or commercially available processor, a central processing unit (CPU), an auxiliary processor among several processors associated with the client device 12, a semiconductor-based microprocessor (in the form of a microchip or chip set), or generally any device for executing software instructions. When the client device 12 is in operation, the processor 412 is configured to execute software stored within the memory 422, to communicate data to and from the memory 422, and to generally control operations of the client device 12 pursuant to the software instructions. In an exemplary embodiment, the processor 412 may include a mobile optimized processor such as optimized for power consumption and mobile applications. The I/O interfaces 414 can be used to receive user input from and/or for providing system output. User input can be provided via, for example, a keypad, a touch screen, a scroll ball, a scroll bar, buttons, bar code scanner, and the

CA 02886681 2015-03-30

WO 2014/066600

PCT/US2013/066548 like. System output can be provided via a display device such as a liquid crystal display (LCD), touch screen, and the like. The I/O interfaces 414 can also include, for example, a serial port, a parallel port, a small computer system interface (SCSI), an infrared (IR) interface, a radio frequency (RF) interface, a universal serial bus (USB) interface, and the like. The I/O interfaces 414 can include a graphical user interface (GUI) that enables a user to interact with the client device 12 Additionally, the I/O interfaces 414 may further include an imaging device, i.e. camera, video camera, etc.

[0058] The radio 416 enables wireless communication to an external access device or network. Any number of suitable wireless data communication protocols, techniques, or methodologies can be supported by the radio 416, including, without limitation: RF; LMR; IrDA (infrared); Bluetooth; ZigBee (and other variants of the IEEE 802.15 protocol); IEEE 802.11 (any variation); IEEE 802.16 (WiMAX or any other variation); Direct Sequence Spread Spectrum; Frequency Hopping Spread Spectrum; Long Term Evolution (LTE); cellular/wireless/cordless telecommunication protocols (e.g. 3G/4G, etc.); wireless home network communication protocols; paging network protocols; magnetic induction; satellite data communication protocols; wireless hospital or health care facility network protocols such as those operating in the WMTS bands; GPRS; proprietary wireless data communication protocols such as variants of Wireless USB; and any other protocols for wireless communication. The data store 418 can be used to store data. The data store 418 can include any of volatile memory elements (e.g., random access memory (RAM, such as DRAM, SRAM, SDRAM, and the like)), nonvolatile memory elements (e.g., ROM, hard drive, tape, CDROM, and the like), and combinations thereof Moreover, the data store 418 can incorporate electronic, magnetic, optical, and/or other types of storage media.

[0059] The memory 422 can include any of volatile memory elements (e.g., random access memory (RAM, such as DRAM, SRAM, SDRAM, etc.)), nonvolatile memory elements (e.g., ROM, hard drive, etc.), and combinations thereof. Moreover, the memory 422 may incorporate electronic, magnetic, optical, and/or other types of storage media. Note that the memory 422 can have a distributed architecture, where various components are situated remotely from one another, but can be accessed by

CA 02886681 2015-03-30

WO 2014/066600

PCT/US2013/066548 the processor 412. The software in memory 422 can include one or more software programs, each of which includes an ordered listing of executable instructions for implementing logical functions. In the example of FIG. 13, the software in the memory system 422 includes a suitable operating system (O/S) 426 and programs 428. The operating system 426 essentially controls the execution of other computer programs, and provides scheduling, input-output control, file and data management, memory management, and communication control and related services. The programs 428 can include various applications, add-ons, etc. configured to provide end user functionality with the client device 12. For example, exemplary programs 428 can include, but not limited to, a web browser, social networking applications, streaming media applications, games, mapping and location applications, electronic mail applications, financial applications, and the like.

[0060] In an exemplary embodiment, the programs 428 include instructions that, when executed, cause the processor and the network interface to receive a plurality of video streams at a client device over the wireless network, wherein each of the plurality of video streams operates at one of a plurality of associated profiles, determine feedback for each of the plurality of video streams, determine modified feedback for each of the plurality of video streams based on the feedback for each of the plurality of video streams, and transmit the modified feedback for each of the plurality of video streams to an associated source of each of the plurality of video streams.

[0061] The instructions, when executed, can further cause the processor and the network interface to: utilize Real Time Control Protocol and Real Time Protocol between the associated source of each of the plurality of video streams, determine the feedback for each of the plurality of video streams utilizing packet loss ratio, and transmit the modified feedback in a Receiver Report packet for each of the plurality of video streams to the associated source of each of the plurality of video streams without requiring extensions or modifications to the Real Time Control Protocol and the Real Time Protocol. The instructions, when executed, can further cause the processor and the network interface to: group the plurality of video streams as a single stream for determining the feedback, compute a packet loss ratio across the single

CA 02886681 2015-03-30

WO 2014/066600

PCT/US2013/066548 stream, determine a weighted average of the packet loss ratio, and transmit the weighted average in a Receiver Report packet to each of the associated sources of each of the plurality of video streams.

[0062] The instructions, when executed, can further cause the processor and the network interface to: determine an available bandwidth for the client device over the wireless connection, determine a current bandwidth for each of the plurality of video streams, wherein the current bandwidth for each of the plurality of video streams is based on the feedback for each of the plurality of video streams, and determine the modified feedback for each of the plurality of video streams such that each of the plurality of video streams utilizes a substantially same amount of the available bandwidth.

[0063] The instructions, when executed, can further cause the processor and the network interface to: operate between each of the associated source of each of the plurality of video streams in accordance with the User Datagram Protocol, determine the modified feedback as an average packet loss ratio across all of the plurality of video streams, and transmit the modified feedback for each of the plurality of video streams to the associated source of each of the plurality of video streams without requiring extensions or modifications to the User Datagram Protocol.

[0064] In the foregoing specification, specific embodiments have been described. However, one of ordinary skill in the art appreciates that various modifications and changes can be made without departing from the scope of the invention as set forth in the claims below. Accordingly, the specification and figures are to be regarded in an illustrative rather than a restrictive sense, and all such modifications are intended to be included within the scope of present teachings.

[0065] The benefits, advantages, solutions to problems, and any element(s) that may cause any benefit, advantage, or solution to occur or become more pronounced are not to be construed as a critical, required, or essential features or elements of any or all the claims. The invention is defined solely by the appended claims including any amendments made during the pendency of this application and all equivalents of those claims as issued.

CA 02886681 2015-03-30

WO 2014/066600

PCT/US2013/066548

[0066] Moreover in this document, relational terms such as first and second, top and bottom, and the like may be used solely to distinguish one entity or action from another entity or action without necessarily requiring or implying any actual such relationship or order between such entities or actions. The terms comprises, comprising, “has”, “having,” “includes”, “including,” “contains”, “containing” or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises, has, includes, contains a list of elements does not include only those elements but may include other elements not expressly listed or inherent to such process, method, article, or apparatus. An element proceeded by “comprises ...a”, “has ...a”, “includes ...a”, “contains ...a” does not, without more constraints, preclude the existence of additional identical elements in the process, method, article, or apparatus that comprises, has, includes, contains the element. The terms “a” and “an” are defined as one or more unless explicitly stated otherwise herein. The terms “substantially”, “essentially”, “approximately”, “about” or any other version thereof, are defined as being close to as understood by one of ordinary skill in the art, and in one non-limiting embodiment the term is defined to be within 10%, in another embodiment within 5%, in another embodiment within 1% and in another embodiment within 0.5%. The term “coupled” as used herein is defined as connected, although not necessarily directly and not necessarily mechanically. A device or structure that is “configured” in a certain way is configured in at least that way, but may also be configured in ways that are not listed.

[0067] It will be appreciated that some embodiments may be comprised of one or more generic or specialized processors (or “processing devices”) such as microprocessors, digital signal processors, customized processors and field programmable gate arrays (FPGAs) and unique stored program instructions (including both software and firmware) that control the one or more processors to implement, in conjunction with certain non-processor circuits, some, most, or all of the functions of the method and/or apparatus described herein. Alternatively, some or all functions could be implemented by a state machine that has no stored program instructions, or in one or more application specific integrated circuits (ASICs), in which each function

CA 02886681 2015-03-30

WO 2014/066600

PCT/US2013/066548 or some combinations of certain of the functions are implemented as custom logic.

Of course, a combination of the two approaches could be used.

[0068] Moreover, an embodiment can be implemented as a computer-readable storage medium having computer readable code stored thereon for programming a computer (e.g., comprising a processor) to perform a method as described and claimed herein. Examples of such computer-readable storage mediums include, but are not limited to, a hard disk, a CD-ROM, an optical storage device, a magnetic storage device, a ROM (Read Only Memory), a PROM (Programmable Read Only Memory), an EPROM (Erasable Programmable Read Only Memory), an EEPROM (Electrically Erasable Programmable Read Only Memory) and a Flash memory. Further, it is expected that one of ordinary skill, notwithstanding possibly significant effort and many design choices motivated by, for example, available time, current technology, and economic considerations, when guided by the concepts and principles disclosed herein will be readily capable of generating such software instructions and programs and ICs with minimal experimentation.

[0069] The Abstract of the Disclosure is provided to allow the reader to quickly ascertain the nature of the technical disclosure. It is submitted with the understanding that it will not be used to interpret or limit the scope or meaning of the claims. In addition, in the foregoing Detailed Description, it can be seen that various features are grouped together in various embodiments for the purpose of streamlining the disclosure. This method of disclosure is not to be interpreted as reflecting an intention that the claimed embodiments require more features than are expressly recited in each claim. Rather, as the following claims reflect, inventive subject matter lies in less than all features of a single disclosed embodiment. Thus the following claims are hereby incorporated into the Detailed Description, with each claim standing on its own as a separately claimed subject matter.