WO2024208886A1

WO2024208886A1 - Method and device for source selection in peer-assisted network coded streaming

Info

Publication number: WO2024208886A1
Application number: PCT/EP2024/059041
Authority: WO
Inventors: Ludvig Carl Henrik NORING; Janusz Klejsa; Sylvia Todorova KOUYOUMDJIEVA
Original assignee: Dolby International AB
Current assignee: Dolby International AB
Priority date: 2023-04-04
Filing date: 2024-04-03
Publication date: 2024-10-10
Anticipated expiration: 2025-10-04

Abstract

The present disclosure relates to a method for downloading content from multiple sources over a network, a source selection proxy implementing the method and a computer program product comprising instructions which, when the program is executed by a computer, causes the computer to carry out the method. The method comprises downloading content from each source in an initial source set, the initial source set comprising at least one first type source, and determining a goodput rate of the network encoded content being downloaded from the initial source set. The method further comprises comparing the goodput rate to a goodput threshold and, if the goodput rate is below a goodput threshold, the method comprises forming an updated source set by adding a second type source to the initial source set and continuing downloading the network encoded content from each source in the updated source set.

Description

METHOD AND DEVICE FOR SOURCE SELECTION IN PEER-ASSISTED

NETWORK CODED STREAMING

CROSS-REFERENCE TO RELATED APPLICATIONS

[0001] This application claims the benefit of priority from U.S. Provisional Application Ser. No. 63,494,074, filed on 4 April 2023, which is incorporated by reference herein in its entirety.

TECHNICAL FIELD OF THE INVENTION

[0002] The present invention relates to a method and system for downloading content from multiple content sources.

BACKGROUND OF THE INVENTION

[0003] In the field of multimedia content delivery, content streaming (e.g., over the internet) is one of the most popular methods for delivering content to a user. Content streaming is very convenient, and playback of streamed content can be achieved on many types of devices including stationary playback devices (such as smart TVs or Hi-Fi systems) and portable playback devices (such as smartphones, laptops, tablets, AR/VR wearables, or automotive infotainment systems).

[0004] The multimedia content can for example be in the form of video and/or audio content stored on one or more servers that are accessible by a user device (often referred to as a client or client device) by using a media player that connects to the one or more servers over a network and requests the desired multimedia content. The one or more servers receives the requests and in response transmits the requested multimedia content to the client which performs playback of the multimedia content. The multimedia content is stored on the one or more servers and can be transmitted to the client in a segmented form meaning that the client does not need to receive a whole multimedia file (e.g., a full music audio track or a full movie) before playback can start, and it is able to play the content in a segment by segment fashion at the same time as when the content is being downloaded.

[0005] Devices and systems that store multimedia content for streaming to clients, e.g., content servers, are often referred to as Points of Presence (PoPs) and the client may have access to multiple PoPs when initiating a multimedia stream whereby a specific PoP is selected, e.g., based on the geographical location of the client and/or PoP or the throughput the PoP can deliver. The PoP could be one or more dedicated multimedia content streaming servers that form a Content Delivery Network (CDN), wherein a CDN typically offers high capacity and reliable PoPs located centrally in the network. The PoP could also be a streaming device that is located closer to the edge of the network (compared to the CDNs that are located deeper in the network), e.g., the PoP could be a peer or an edge cache. The PoPs closer to the edge of the network typically offer less reliability (e.g., when they are peers) compared to PoPs in CDNs but the PoPs closer to the edge of the network could be more abundant or cheaper to operate.

GENERAL DISCLOSURE OF THE INVENTION

[0006] A drawback with the existing solutions is that, when many clients access the same content at the same time (e.g., massive streaming scenarios), throughput bottlenecks appear upstream in the network closer to the more central PoPs. For example, a throughput bottleneck may appear due to large workload imposed on the one or more CDN servers. Another reason for throughput bottlenecks appearing in streaming scenarios has to do with limitations of the Boarder Gateway Protocol (BGP), which governs routing between Autonomous Systems (AS) of the Internet. The BGP is constructed around the concept of the shortest path, which e.g., means that the BGP cannot route around congestion that may appear (e.g., in massive streaming scenarios). This means that if a specific source is used for delivery of the content, it can be affected by a network bottleneck even if there are multiple network paths available for a connection between the specific source and a client.

[0007] In the case of multi source delivery to a client, it is important to establish a strategy for using the multiple sources. This can be done, for example, by scheduling of byte ranges to be delivered by the respective sources. However, if some of the sources are not reliable, there is a risk that bytes to be received from a non-performing or under-performing source do not arrive in time, which can impact the quality of experience on the client. Thus, some management strategy mitigating the risks due to such unreliable sources is needed. Alternatively, one can employ network coded delivery, which simplifies the usage of multiple sources and enables aggregation of throughput from the multiple sources. A network code is a so-called fountain code. This means that data at the PoPs is stored as so-called network coded symbols by means of so-called block network code (e.g., network coded data may be received at a PoP, or non-network coded data may be generated via an encoding process performed at the PoP). A block of data can be decoded on the client if enough of linearly independent symbols are delivered from the sources. Therefore, one does not need to schedule delivery of specific byte ranges from specific sources, but rather make sure that a sufficient number of (innovative symbols, i.e., linearly independent) network coded symbols is delivered from the respective sources. [0008] A drawback of the multisource delivery is due to the fact that it can generate a significant amount of in-flight data. For single source delivery, the amount of in-flight data upon a content request is proportional to a product of network bandwidth and the network delay. For multisource delivery, however, the amount of in-flight data is proportional to the product of the number of sources and the single path in-flight data. Significant amounts of in-flight data imply a waste of bandwidth. Such surplus data sent from the PoPs is generally undesired, especially if the PoPs are located within CDNs. Therefore, an efficient strategy of using the multiple sources is needed.

[0009] It is a purpose of the present invention to overcome at least some of the shortcomings of the prior solutions and provide a method for streaming content which alleviates, mitigates or removes congestion and bottlenecks occurring during massive streaming scenarios. [0010] According to a first aspect of the invention, a method is provided for downloading content from multiple sources over a network. The method comprising the steps of downloading network encoded content from each source in an initial source set, the initial source set comprising at least one source of a first type, wherein the network encoded content being coded with a network code. The method further comprises determining a goodput rate of the network encoded content being downloaded from the initial source set, comparing the goodput rate to a goodput threshold and, if the goodput rate is below a goodput threshold, forming an updated source set by adding a source of a second type to the initial source set, wherein the second type source is a different source type than the first source type . Additionally, the method comprises continuing downloading the network encoded content from each source in the updated source set.

[0011] The present invention is at least based on the observation that content can be downloaded from different types of sources, a first type and a second type, whereby content is requested from the second type of source in response to the initial source set comprising one or more the first type sources not being able to maintain a goodput exceeding the goodput threshold.

[0012] In some implementations, the initial source set comprises only first type sources. It is also envisaged that the initial source set comprises both first and second type sources.

[0013] In some implementations, the first type source is an edge source, such as a peer or an edge-cache, and the second type of source is a central source, such as a source belonging to a Content Delivery Network CDN.

[0014] The throughput available at PoPs located at the edge of the network (e.g., within single AS) is typically much higher compared to the throughput available upstream in the network, especially for modern access technologies (e.g., FTTX). By using multimedia content encoded with network code efficient content delivery from multiple sources is achieved and by prioritizing content download from nodes at the network edge (e.g., peers or edge caches), nodes located deeper in the network (e.g., CDNs) are offloaded and/or subject to less requests for content (e.g., consumption of resources associated with requesting and receiving content from deeper nodes is minimized or avoided). Furthermore, by determining a goodput and using the goodput to determine when a reliable central network source (such as a CDN) is needed to support the streaming process, the central network source is only used when necessary, which minimizes the load on the central network source. That is, the method is adaptive and adapts to changing streaming conditions. In other words, the present invention attempts to identify a set of sources to be used with a goal to reduce the amount of content that is requested from CDNs. [0015] In some implementations, the second type source is an edge source, such as a peer or an edge-cache, and the first type of source is a central source, such as a source belonging to a Content Delivery Network CDN.

[0016] Accordingly, content is downloaded from central sources mainly wherein, in response to the one or more central sources not being able to sustain a goodput exceeding the goodput threshold, an edge source is further used to download content. This reduces the utilization of central sources as instead of requesting content from one or more additional central sources to maintain a sufficient goodput, content is requested from one or more additional edge sources.

[0017] In the below, the first type sources will be assumed to be edge sources, such as peer sources or edge cache sources, and the second type sources will be assumed to be central sources, such as sources being part of a CDN unless otherwise is specified. However, it is understood that in many implementations a first type source could also denote a central source and a second type source could denote an edge source.

[0018] In the case of multimedia streaming, an adaptive bitrate (ABR) streaming approach is often used, where a single item of content is typically available in multiple bitrate versions. In this case a client selects an appropriate bitrate version, which is suitable for the throughput observed on that client. A set of multiple bitrate versions is often referred to as a bitrate ladder. Such a bitrate ladder comprises at least a low bitrate version associated with the low Quality of Experience (QoE) and a high bitrate version associated with the high QoE. A content player operating on the client includes an ABR policy that, for example, attempts to maximize the QoE while minimalizing the probability of not receiving a segment in time, which would lead to an interruption of the playout and a rebuffering event. In the description of the presented invention, the term QoE or QoE level is associated with a capability of successfully delivering a bitrate version associated with that QoE. Therefore, a reduction of QoE would mean that an ABR policy in a client observes a reduced throughput, thus it decides to request a version of the content associated with a lower bitrate. Conversely, preserving a QoE means that the ABR policy continues to request segments of the content associated with the bitrate providing this particular QoE. The proposed invention assumes a generic ABR policy built into a content player on the client, and it focuses on generating sustainable throughput.

[0019] In general, the invention attempts to reduce the utilization of the central PoPs by using PoPs at the edge of the network. This is achieved by either refraining from requesting content from central PoPs until absolutely necessary to maintain the QoE or by requesting content from additional edge PoPs, instead of additional central PoPs, when a set of central PoPs struggle to maintain the QoE. However, PoPs at the edge of the network can be unreliable (e.g., if such a PoP is a peer, which can go offline at any time). Thus, there is a risk that usage of edge located PoPs would adversely affect the QoE on the client. For example, if due to fluctuation of peer’s bandwidth, not enough symbols are delivered in time needed to decode a segment of content, the content player may decide to switch to a lower bitrate, and this would negatively impact the QoE. The proposed invention comprises methods that reevaluate the composition of a set of sources to make sure that the event of not being able to decode a segment happens with very low probability. The invention uses the property of coded delivery and the fact that centrally located PoPs (such as PoPs forming a part of a CDN) are generally reliable.

[0020] A sustainable QoE level may refer to a state of a content player, where it is capable to play out in time the content encoded at the bitrate associated with this QoE. In other words, the delivery of the content at the specific bitrate required by this QoE is sustainable, and all the segments can be delivered before the player has to play them out. A non-sustainable QoE level may refer to the situation where the content player needs to request segments at a lower bitrate to facilitate in-time playout of the segments. In other words, the player needs to reduce the QoE level to achieve a new sustainable QoE level for the currently observed throughput. In addition to the term QoE level, the term QoE is also used synonymously (if there is no ambiguity).

[0021] Additionally, the “cost” (in terms of risking degraded streaming performance for other users, upkeep, equipment required to be maintained by a streaming provider) between using the central network sources and the edge network sources is asymmetrical. For example, the egress bandwidth generated from CDNs typically incurs an operational cost for streaming service providers. On the other hand, the cost of having a client download content from an edge source is zero or negligible. Therefore, reduction of the utilization of CDNs during content download can be provided by PoPs at the edge of the network which can e.g. reduce the egress bandwidth of the CDNs and/or reduce the total number requests directed to the CDNs. However, there is also an asymmetry in terms of reliability between the two types of sources. For example, central sources are expected to be highly reliable, as they are expected to be always available in the network, while edge sources might have a limited lifetime, e.g., they might not be present in the network at all times. Moreover, central sources typically facilitate storage of all content while this may not always be possible for edge sources (e.g., a peer operating within an internet browser would have constrained storage capacity). The decreased reliability of the edge source could be expected to negatively affect the QoE when these sources are used meaning that there could be a trade-off between the cost and, for instance, the average QoE when balancing the usage of central sources and edge sources. However, with the above method the source selection achieves reduction in the level of utilization of the central sources while quality of the download, such as the QoE is with a high probability maintained. In other words, the method maximizes central source utilization without impacting the QoE. For instance, this allows fewer, less capable and/or more cost efficient central sources to be used without negatively impacting the QoE, even in massive streaming scenarios.

[0022] In some implementations, obtaining a goodput threshold comprises obtaining a current QoE level associated with the content and determining the goodput threshold based on the goodput rate required to sustain the current QoE level.

[0023] That is, the method prioritizes download from first type sources (edge sources) and the method comprises initiating downloading from second type sources (a central or edge source) when there is a risk that QoE is degraded if download from the first type sources continues without support from a second type source. On the other hand, as long as the QoE can be sustained, the method results in a reduction in the utilization level of the second type sources. [0024] In some implementations, the method comprises intercepting a content request from a content player and obtaining the QoE level based on the content request from the content player. Accordingly, the method can operate with any type of content.

[0025] According to a second aspect of the invention there is provided a computer device comprising processor configured to perform the method according to the first aspect. In some implementations, the computer device is used as source selection proxy that selects sources, requests content from the selected sources on behalf of a content player and delivers the content to the content player once it has been received.

BRIEF DESCRIPTION OF THE DRAWINGS

[0026] Aspects of the present invention will be described in more detail with reference to the appended drawings, showing currently preferred embodiments. [0027] Figure l is a block-diagram showing schematically a client comprising a content player and a source selection proxy communicating with sources of different types according to some implementations.

[0028] Figure 2 is a flow-chart describing a method for selecting sources from which content is to be requested, according to some implementations.

[0029] Figure 3 is a block-diagram showing details of a source selection proxy according to some implementations.

[0030] Figure 4 is a flow-chart describing how the decision of whether or not to initialize content download from second type sources is made, according to some implementations.

[0031] Figure 5 is a graph illustrating an example of how the utilization of a second type source is reduced (e.g. in terms of number of content requests) with the method for source selection according to some implementations.

[0032] Figure 6 is a flow-chart describing an alternative version of how the decision of whether or not to initialize content download from second type sources is made, according to some implementations.

DETAILED DESCRIPTION OF CURRENTLY PREFERRED EMBODIMENTS

[0033] Systems and methods disclosed in the present application may be implemented as software, firmware, hardware or a combination thereof. In a hardware implementation, the division of tasks does not necessarily correspond to the division into physical units; to the contrary, one physical component may have multiple functionalities, and one task may be carried out by several physical components in cooperation.

[0034] The computer hardware may for example be a server computer, a client computer, a personal computer (PC), a tablet PC, a set-top box (STB), a personal digital assistant (PDA), a cellular telephone, a smartphone, an AR/VR wearable, automotive infotainment system, a web appliance, a network router, switch or bridge, or any machine capable of executing instructions (sequential or otherwise) that specify actions to be taken by that computer hardware. Further, the present disclosure shall relate to any collection of computer hardware that individually or jointly execute instructions to perform any one or more of the concepts discussed herein.

[0035] Certain or all components may be implemented by one or more processors that accept computer-readable (also called machine-readable) code containing a set of instructions that when executed by one or more of the processors carry out at least one of the methods described herein. Any processor capable of executing a set of instructions (sequential or otherwise) that specify actions to be taken are included. Thus, one example is a typical processing system (e.g., computer hardware) that includes one or more processors. Each processor may include one or more of a CPU, a graphics processing unit, and a programmable DSP unit. The processing system further may include a memory subsystem including a hard drive, SSD, RAM and/or ROM. A bus subsystem may be included for communicating between the components. The software may reside in the memory subsystem and/or within the processor during execution thereof by the computer system.

[0036] The one or more processors may operate as a standalone device or may be connected, e.g., networked to other processor(s). Such a network may be built on various different network protocols, and may be the Internet, a Wide Area Network (WAN), a Local Area Network (LAN), or any combination thereof.

[0037] The software may be distributed on computer readable media, which may comprise computer storage media (or non-transitory media) and communication media (or transitory media). As is well known to a person skilled in the art, the term computer storage media includes both volatile and non-volatile, removable and non-removable media implemented in any method or technology for storage of information such as computer readable instructions, data structures, program modules or other data. Computer storage media includes, but is not limited to, physical (non-transitory) storage media in various forms, such as EEPROM, flash memory or other memory technology, CD-ROM, digital versatile disks (DVD) or other optical disk storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other medium which can be used to store the desired information and which can be accessed by a computer. Further, it is well known to the skilled person that communication media (transitory) typically embodies computer readable instructions, data structures, program modules or other data in a modulated data signal such as a carrier wave or other transport mechanism and includes any information delivery media.

[0038] Fig. 1 is a block-diagram depicting a client 30 streaming content from multiple available sources 11, 12, 13, 21, 22, 23 (PoPs). The available sources comprise first type sources 11, 12, 13 forming a first type source set 10 and second type sources 21, 22, 23 forming a second type source set 20. Each source 11, 12, 13, 21, 22, 23 is configured to transmit encoded content to a client 30 in response to receiving a content request from the client 30. The content may be provided to each source 11, 12, 13, 21, 22, 23, from an upstream source without network coding whereby the source 11, 12, 13, 21, 22, 23 performs the encoding of the content with network code. Alternatively, the content is provided to each source 11, 12, 13, 21, 22, 23 already encoded with network code from elsewhere, e.g. a central upstream server. The content (with or without network coding) is temporarily stored by each source 11, 12, 13, 21, 22, 23 or forwarded to a client 30 requesting the content. [0039] The client 30 comprises a content player 37 configured to render and playback media content provided to it. The content player 37 may comprise a buffer for temporarily storing content prior to playback. The content player 37 may be any type of content player, such as a media player. In some implementations, the content player 37 is an adaptive bitrate (ABR) content player 37 configured to request content of different bitrates based on an ABR policy and a content bitrate ladder (also referred to as a content manifest). The content bitrate ladder indicates a set of different versions of the media content that the ABR content player 37 can request. The bitrate ladder may also indicate a download metric (such as an average goodput rate required to sustain the associated version) associated with each content version. The content bitrate ladder is obtained by the ABR content player 37 from a server 40 and/or from one of the available PoPs, indicating to the ABR content player 37 which versions that are available. The ABR content player 37 is configured, based on its ABR policy and properties of the streaming process, to request one of the versions of the content indicated in the content bitrate ladder. For example, the ABR content player 37 requests the version with the highest QoE (e.g., highest video and/or audio quality) which the ABR policy deems can be sustained based on the properties of the streaming process.

[0040] The ABR policy may be buffer-based wherein the ABR content player 37 determines a streaming process property being the amount (e.g., the duration) of content stored in the content player’s 37 buffer and determines a content version to be requested based on the amount of the content in the buffer. For example, if there is much content in the buffer the ABR content player 37 will request a higher quality version of the content and if there is less content in the buffer (e.g., risking that playback becomes interrupted as the buffer becomes emptied) the ABR content player 37 will request a lower quality version.

[0041] Additionally or alternatively, the ABR policy may be throughput- or goodput-based wherein the ABR content player 37 determines a streaming process property being goodput rate or throughput rate and determines a content version to be requested based on the determined goodput rate or throughput rate. For example, if the goodput rate or throughput rate is high the ABR content player 37 will request a higher quality version of the content and if the goodput rate or throughput rate is low the ABR content player 37 will request a lower quality version.

[0042] Additionally, for both buffer-based and throughput/goodput-based ABR policies it is envisaged that the ABR content player 37 measures the variance of the streaming process property and makes the version selection further based on the variance. For example, a large variance may result in the ABR policy opting for a lower quality version compared to if the variance is smaller. [0043] The ABR content player 37 is configured to reevaluate the version selection repeatedly, such as once for each segment that is downloaded.

[0044] The different versions of the content indicated in the content bitrate ladder offer different QoE to a user. For example, the different quality versions may differ in at least one of resolution (SD, HD or UHD), encoding format (H.264 or H.265), compression, frame size, color depth etc. for video content and differ in at least one of sampling rate, bits per sample, compression, number of channels etc. for audio content. A content version at the top of the content bitrate ladder offers content playback that is perceived as higher quality but is also associated with higher requirements imposed on the reliability and throughput of the connections to the PoPs. The ABR content player 37 strives to obtain as high quality version of the content as possible without the playback being interrupted in order to offer the highest possible QoE to the user.

[0045] It is also envisaged that the content player 37 is a non-ABR content player 37 and always requests the same version of the content.

[0046] The content player 37 is configured to send a content request to a source selection proxy 31 in the client 30. The source selection proxy 31 is configured to select, from an available set of PoPs, to which PoPs the request of the content player 37 shall be transmitted. That is, the source selection proxy 31 is configured to determine which PoPs that are to be used for downloading the media content version requested by the content player 37. The PoPs may also be referred to as sources 11, 12, 13, 21, 22, 23 and the available set of sources 11, 12, 13, 21, 22, 23 comprises two subsets, a first type source set 10 comprising available first type sources 11, 12, 13 and a second type source set 20 comprising available second type sources 21, 22, 23. The first type source set 10 may comprise sources 11, 12, 13 closer to the edge of the network, e.g., peers or edge cache, and the second type source set 20 may comprise sources 21, 22, 23 that are more centrally located in the network with respect to the first type source set 10, e.g., PoPs within a Content Delivery Network (CDN). That is, the second type source may be sources belonging to a CDN and the first type source may be non-CDN sources, such as a peer or an edge cache. The source selection proxy 31 is configured to select which source(s) 11, 12, 13, 21, 22, 23 should be used for downloading content such that the utilization of the second type sources 21, 22, 23 is minimized while maintaining a QoE level that is requested by the content player 37.

[0047] That is, the source selection proxy 31 may be configured to select which sources to request content from according to first decision scheme. The first decision scheme being configured to prioritize use of edge sources 11, 12, 13 when downloading content unless the resulting QoE will be affected negatively, only then can the source selection proxy 31 request content from one or more central sources 21, 22, 23 of the second type source set 20. Alternatively, the source selection proxy 31 is configured to select which sources 11, 12, 13, 21, 22, 23 to request content from according to a second decision scheme. The second decision scheme being configured to download content from one or more central sources and if the goodput falls below the goodput threshold the source selection proxy 31 request content from one or more edge source. That is, it may be desirable to keep downloading content from a set central sources until the goodput falls below the goodput threshold, then the source selection proxy 31 is configured to first attempt to increase the goodput by requesting content from an edge source instead of from an additional central source.

[0048] Additionally or alternatively, the source selection proxy 31 may be configured to select sources 11, 12, 13, 21, 22, 23 from which content should be requested according to other decision schemes. An example of a third decision scheme is when the source selection proxy 31, to maintain the QoE, may be configured to request content from an additional edge source 11, 12, 13 (first type source) while downloading content from a set of sources comprising one or more edge sources 11, 12, 13 or only edge sources 11, 12, 13. If a goodput that is below the goodput threshold is detected, the source selection proxy 31 may be configured to request content from an additional edge source 11, 12, 13 in an attempt to maintain a goodput sufficient to maintain the QoE. As edge sources 11, 12, 13 may be unreliable there is a risk that the additional edge source 11, 12, 13 is not sufficient to maintain the goodput, whereby content may be requested from yet another edge source 11, 12, 13. The source selection proxy 31 may be configured to make a predetermined number of attempts by introducing additional edge sources 11, 12, 13 before resorting to the above mentioned strategy of requesting content from a central source 21, 22, 23.

[0049] An example of a fourth decision scheme is that the source selection proxy 31, to maintain the QoE, may be configured to request content from an additional central source 21, 22, 23 (second type source) while downloading content from a set of sources comprising one or more central sources 21, 22, 23 or only central sources 21, 22, 23. In some situations, initiation of content download from an additional central source 21, 22, 23 is deliberately avoided unless necessary for sustaining the QoE and/or a goodput exceeding the goodput threshold. However, to avoid interruption in the playback there are cases where content is requested from an additional central source 21, 22, 23 even if one or more central sources 21, 22, 23 is already used for downloading content. For instance, if no edge sources 11, 12, 13 are available, or the available edge source are known to be unable to provide sufficient goodput, the source selection proxy 31 may be configured to request content from an additional central source 21, 22, 23. [0050] The source selection 31 proxy may be configured to apply one or more decision schemes and/or be configured to adaptively switch between decision schemes. For instance, if only central sources 21, 22, 23 are available, the source selection proxy 31 employs the fourth decision scheme and if only edge sources 11, 12, 13 are available the source selection proxy employs the third decision scheme. If both central sources 21, 22, 23 and edge sources 11, 12, 13 the source selection proxy may employ any one of the first through fourth decision schemes. For example, it is envisaged that at the start of the streaming process, the fourth decision scheme is utilized relying mainly on central sources 21, 22, 23. After a predetermined amount of time when the download is stable, the method starts shedding central sources 21, 22, 23 and replacing them with one or more edge sources 11, 12, 13. The method may then utilize decision scheme one and request content mainly or only from edge sources 11, 12, 13 whereby one or more central sources 21, 22, 23 are utilized only when necessary for maintaining the QoE.

[0051] The source selection proxy 31 facilitates usage of any generic content player 37, meaning that the content player 37 as such does not need to be adapted for the multisource delivery. The source selection proxy 31 performs the source selection algorithm that will be explained in further detail in the below, and requests content from the one or more sources 11, 12, 13, 21, 22, 23 it selects on behalf of the content player 37. The source selection algorithm performed by the source selection proxy 31 is separate from the version or QoE selection that may be performed by the content player 37. In some implementations, the source selection proxy 31 will allocate content requests between the selected sources 11, 12, 13, 21, 22, 23 with a flow controller implementing a flow control policy that is explained in further detail in the below. The flow control policy is also separate from the source selection algorithm performed by the source selection proxy 31 and the version or QoE selection performed by the content player 37.

[0052] The source selection proxy 31 receives the content it requests on behalf of the content player 37 from the selected sources 11, 12, 13, 21, 22, 23, decodes it with a network decoder, and then provides the decoded content over to the content player 37.

[0053] To facilitate efficient multisource content streaming, the content is encoded with network code (e.g., the encoding is performed by the sources 11, 12, 13, 21, 22, 23) prior to being transmitted to the client 30. For example, the content is divided into a plurality of subsequent segments, wherein each segment is encoded with network code prior to being transmitted to the client 30. The network coding enables each segment to be split into a plurality of symbols which can be transmitted independently from each other. For example, some symbols of a particular segment may be received from a first source 11 whereas some symbols are received from a different second source 12. The symbols are collected by the client 30 and decoded to generate the content segment. [0054] The encoding of the content may be performed by the sources 11, 12, 13, 21, 22, 23 or the encoding of the content is performed elsewhere (e.g. in an upstream server communicating with the sources 11, 12, 13, 21, 22, 23) with the sources 11, 12, 13, 21, 22, 23 receiving and storing the content prior to transmitting it to clients 30 upon request.

[0055] Typically, the central sources of the second type source set 20 are highly reliable sources (compared to those of the edge sources of the first type source set 10) and it is assumed that any second type source 21, 22, 23 contains all the content (e.g., all the segments) the content player 37 requests. Additionally, a second type source 21, 22, 23 (which e.g. is a dedicated server of a CDN) is essentially always available and constantly ready to receive content requests and transmit content to the client 30 in response.

[0056] However, the sources of the first type source set 10 are in general less reliable meaning for example that the content requested from a certain first type source 11 may only be partially available at the certain first type source 11 (for example due to storage constraints in the first type source 11) or not available at all meaning that the content may be requested again, from another source. Additionally, a first type source 11, 12, 13 is also less reliable than a second type source 21, 22, 23 in terms of being at all available/online for receiving requests, and while a member of the second type source set 20 is typically accessible at essentially all times a member of the first type source set 10 may be available irregularly and/or intermittently. For example, a peer is an example of a first type source 11, 12, 13 and a peer may e.g. only be available while some other user is streaming content, meaning that the peer can become unavailable suddenly and unexpectedly if the other user aborts the streaming process.

[0057] The usage of network coding facilitates dealing streaming situations containing sources of different types, with varying reliability, since network code is a so-called fountain code allowing content to be requested from multiple sources 11, 12, 13, 21, 22, 23 without depending on receiving any specific packet from a specific source 11, 12, 13, 21, 22, 23. Therefore, it is expected that the more linearly independent sources 11, 12, 13, 21, 22, 23 that are utilized, the higher the probability of downloading the required data even if some of the sources 11, 12, 13, 21, 22, 23 are unreliable. On the other hand, simply downloading from more sources will lead to increased congestion in the network which is why the source selection proxy 31 is made adaptive to be able to deal with a situation where some of the sources are not reliable (e.g., do not have the exact content that is requested) without increasing the number of sources.

[0058] With further reference to fig. 2, the operation of the source selection proxy 31 will now be described in further detail. [0059] At step SI the source selection proxy 31 intercepts the request from the content player 37. The request comprises a content version identifier (e.g., a requested QoE level) and may indicate a goodput required to sustain the requested content version.

[0060] At step S2, the source selection proxy 31 determines if there are any available first type sources in the first type source set 10. The first source type may be edge sources or central sources. In the below any first type source is assumed to be an edge source and any second type source is assumed to be a central source, but the same method is also performed when any first type source is a central source, and any second type source is an edge source.

[0061] In some implementations, the source selection proxy 31 receives a list of available sources 11, 12, 13, 21, 22, 23 and the type of each available source. The list of available sources may be updated repeatedly, e.g., as first or second type sources become available or unavailable. That is, the first type source set 10 and second type source set 20 may be updated repeatedly.

[0062] The source selection proxy 31 may at step S2 have access to information indicating the expected performance (e.g., in terms of latency and/or bandwidth) of the available sources

11, 12, 13, 21, 22, 23 allowing the source selection proxy 31 to make an informed decision regarding which source(s) 11, 12, 13, 21, 22, 23 to select. For example, the expected performance of one source 12 may be based on previous downloads from the same source 12. To this end, the source selection proxy 31 can make an informed decision and select one or more sources from the first type source set 10 that are expected to be able to sustain the QoE indicated by the content player’ s 37 request that was intercepted at step S 1. The source selection proxy 31 may be configured to prioritize selecting first type sources 11, 12, 13 so as to reduce load on the second type sources 21, 22, 23. For example, the source selection proxy 31 may be configured to first try to meet the goodput required to sustain the QoE with one or more source from the first type source set 10 and, if this is not possible, it resorts to using a second type source(s) 21, 22, 23 as well or instead of one or more first type sources 11, 12, 13.

[0063] In the case the first source type set 10 is empty or the source(s) available in the first source type set 10 is expected to not meet the goodput required for the requested QoE, the method proceeds to step S8 and starts downloading content from one or more sources selected from the second type source set 20 instead of, or in addition to, one or more first type sources 11,

12, 13.

[0064] As mentioned in the above, the content may be divided into consecutive encoded segments, whereby one or more segments of the content is downloaded before download of one or more subsequent segments is initiated. In such implementations, the source selection proxy 31 may check whether one or more first type sources 11, 12, 13 were used in downloading a previous segment and use the same first type sources 11, 12, 13 again, for a subsequent segment. [0065] If no first type sources 11, 12, 13 are available, the source selection proxy 31 will request the content on behalf of the content player 37 using second type sources 21, 22, 23 and initialize content download from at least one second type source 21, 22, 23 at step S8.

[0066] The content transmitted by the selected sources 11, 12, 13, 21, 22, 23 and received by the client 30 is encoded with network code. For example, it is the sources 11, 12, 13, 21, 22, 23 which has encoded the content with network code or the sources 11, 12, 13, 21, 22, 23 store content that has been encoded with network code elsewhere. That is, the content received by the client may be encoded with a first encoding layer that the media player is capable of ingesting (e.g., MPEG-3 coding for audio or H.265 coding for video) wherein the first encoding layer is encapsulated in a second encoding layer being a network code. With network coding efficient download from multiple sources simultaneously is facilitated. The network code may be linear code, such as random linear code, RaptorQ code, Reed-Solomon code, Luby Transform code or the like. The network code may be implemented as a block code or as a convolutional code.

[0067] With network coding and content segmentation, the content is divided into a plurality of consecutive segments, with each segment representing a (potentially partially overlapping) time portion of the content. Each segment is then encoded with a network code into a set of symbols that can be transmitted independently of each other and reassembled at the client to form the encoded segment. By decoding the network coded segment, the client 30 can obtain a segment of content in a format that is ingestible by the content player 30.

[0068] As an illustrative example, video streaming is considered wherein a portion of the video (e.g., 2 seconds) forms a segment and is encoded with network code to form N symbols. The symbols are transmitted to the client 30 from one or more sources (PoPs) 11, 12, 13, 21, 22, 23 and when the client 30 has a sufficient number of symbols it decodes the symbols to obtain the portion of video that can be played by the content player 37.

[0069] The source selection proxy 31 will wait at step S9 for a sufficient number of symbols to be received so that decoding of the segment can be completed. After the segment has been decoded, the source selection proxy 31 provides the decoded content to the content player 37 at step S10 wherein the decoded content is stored in the buffer of the content player 37 or played-back immediately.

[0070] Turning back to step S2 involving the source selection proxy 31 determining whether there are any available first type source(s) 11, 12, 13. If it is determined that there are available first type sources 11, 12, 13 the method goes to step S3 and the source selection proxy 31 will selected one or more first type sources 11, 12, 13 and initialize downloading content from one or more first type sources 11, 12, 13. In some implementations, the source selection proxy 31 will, provided there are available first type sources 11, 12, 13, initialize downloading only from first type sources 11, 12, 13. In other words, if there is at least one first type source 11, 12, 13 the source selection proxy 31 may refrain from downloading from any member of the second type source set 20 unless this is initiated later in step S6 (as will be described in the below). This will alleviate the second type sources 21, 22, 23 as the source selection proxy 31 prioritizes download from first type sources 11, 12, 13. The selected first type sources 11, 12, 13 are referred to as an initial set of sources and may, as indicated in the above, contain first type sources only.

[0071] At step S5, the source selection proxy 31 determines a goodput rate of the content downloaded from one or more first type sources 11, 12, 13. The goodput rate may be the aggregated goodput of all (first type) sources used to download content. For example, the goodput is the goodput measured at the output of the network decoder. The goodput at this location, downstream of the network decoder, is also the goodput which will affect the selection of the ABR policy in the content player 37. As an alternative, it is also possible to determine the goodput based on the rate at which encoded symbols arrive at the network decoder and a metric indicating an amount of overhead of these symbols.

[0072] Optionally, the method involves step S4 of waiting a predetermined time T1 until the goodput rate first is measured to allow downloading process from the selected first type sources 11, 12, 13 to ramp up, which may provide a more accurate measurement of the goodput rate.

[0073] The method then goes to step S6 wherein the goodput rate is compared to a goodput threshold.

[0074] The goodput threshold may be based on the version (QoE) requested by the content player 37 which the source selection proxy 31 can obtain by intercepting the requests from the content player 37. The version or QoE may indicate, or be associated with, a goodput rate required to sustain the version or QoE selected by the content player 37, this goodput rate is then used as the goodput threshold such that the source selection proxy 31 can select sources that reduces the utilization of the central sources while maintaining a goodput exceeding the goodput threshold. The version or QoE requested by the content player 37 may change over time, meaning that also the goodput threshold, based on the requested version or QoE, may also change over time.

[0075] In some implementations, a target QoE is defined and available to the source selection. For example, the target QoE is the highest available QoE. To allow the content player 37 to rapidly start playback at the target QoE the source selection proxy 31 may be configured to always include one or more second type sources 21, 22, 23 as long as the QoE currently requested by the content player 37 is a lower QoE with respect to the target QoE. [0076] If the measured goodput rate exceeds the goodput threshold this may be an indication that the selected first type sources 11, 12, 13 are capable of sustaining a download rate sufficient to sustain the QoE. Accordingly, the source selection proxy 31 will continue to download the content from the selected one or more first type sources 11, 12, 13. At step S7, the source selection proxy 31 checks if sufficient content has been downloaded to start decoding. If this is the case, the method goes to step S10, decodes the content and provides the decoded content to the content player 37 for playback. If the content that has been downloaded is not sufficient to start decoding at step S7, the method goes to back to step S5 and measures the goodput again at S5.

[0077] Optionally, the source selection proxy 31 waits at S 11 for a duration of T2 prior to again determining the goodput rate at step S5. That is, the goodput rate is measured and compared to the goodput threshold repeatedly at intervals of T2 during download to determine if a second type source 21, 22, 23 should be used. Alternatively, the goodput is determined substantially continuously or instead of repeatedly/substantially continuously measuring the goodput the goodput is measured once per segment, and the method goes to step S9 if the evaluation of step S7 is negative, and awaits the decoding to complete.

[0078] Accordingly, the source selection proxy 31 will repeat steps S5, S6, S7 and Si l as long as the first type sources 11, 12, 13 can sustain a download goodput rate exceeding the goodput threshold until the segment has been received and can be decoded, whereby the process is repeated for the next segment.

[0079] If it is determined at step S6 that the measured goodput rate is below the goodput threshold, there is a risk that the current QoE cannot be sustained with the current selection of first type sources 11, 12, 13. The method then goes to step S8 and starts downloading from at least one second type source 21, 22, 23 in addition to, or instead of, downloading from the selected first type sources 11, 12, 13. That is, the source selection proxy 31 forms an updated source set comprising at least one second type source 21, 22, 23 and optionally, one or more first type sources 11, 12, 13.

[0080] In this way, the number of content requests transmitted to second type sources 21, 22, 23 will be reduced as the central sources 21, 22, 23 are only used when necessary to maintain a goodput rate exceeding the goodput threshold. By selecting a goodput threshold equal to the goodput required to maintain a requested QoE the utilization reduction of central sources is achieved without any tradeoff in QoE.

[0081] Fig. 3 is a block diagram showing the details of a source selection proxy 31 according to some implementations. As seen, the source selection proxy 31 operates between the content player 37 and the sources of the first type source set 10 and the second type source set 20.

[0082] The source selection proxy 31 comprises an interception unit 36 which intercepts content requests from the content player 37. The content request indicates a version or a QoE of the content that is requested by the content player 37 and this request is passed to a source selection algorithm 33 that determines whether sources of the first type source set 10, second type source set 20, or both sets should be used when downloading the requested content. The content is divided into consecutive segments that are encoded with network code. Each network code encoded segment is further divided into symbols that are transmitted from the sources 11, 21 to the source selection proxy 31. The symbols are obtained and temporarily stored in the network decoder 35 of the source selection proxy 31. When a sufficient number of symbols of a segment has been received, the network decoder 35 will be able to decode the segment and provide decoded content of the segment to the content player 37 (optionally via the interceptor 36). The sufficient number of symbols required for starting the decoding process may be equal to all symbols of the segment or a subset of the symbols. For example, there exist network coding techniques that allow the decoding to start when only a subset of the symbols have been received, whereby the decoding is completed after all symbols have been received.

[0083] Information pertaining to the operation of the decoder 35, the rate at which symbols are received by the decoder 35 or the rate at which decoded content is outputted by the decoder 35 will be passed to a bandwidth estimator 34. For example, the bandwidth estimator 34 obtains an indication of the rate at which the network decoder 35 receives symbols from each of the respective sources and a size of each symbol, allowing the bandwidth estimator 34 to estimate a throughput rate for the source selection proxy 31. For example, the network decoder 35 obtains X symbols of N kB in size per second from a first source and Y symbols per second of a N kB size from a second source allowing the bandwidth estimator to estimate the throughput as (X+Y)N kB per second.

[0084] Additionally or alternatively, a bandwidth estimator 34 obtains from the network encoder 35 an indication of an amount of overhead in the network encoded data (e.g., a percentage, ratio or estimated number of bytes per second) whereby the bandwidth estimator 34 can determine the goodput rate based on the amount of overhead and the throughput rate. For example, if the throughput rate is Z kB per second, and the overhead is 20%, the goodput can be estimated as (1 - 0.2)Z kB per second.

[0085] Additionally or alternatively, the bandwidth estimator 34 determines the rate at which decoded content is output by the network decoder 35, this rate is equal to the goodput, allowing the goodput rate to be measured directly. [0086] In some implementations, the network decoder 35, interceptor 36 and/or content player 37 will also determine other parameters related to the download process and transmit these to the source selection algorithm 33. For example, the network decoder 35 conveys information to the source selection algorithm 33 indicating how much (e.g., a ratio or a number of symbols) of an encoded segment that has been received and/or the content player 37 conveys information to the source selection algorithm 33 indicating how much (decoded) content that is stored in the content player’s 37 buffer (e.g., measured in amount of data, playback duration or a fullness level of the buffer).

[0087] The source selection algorithm 33 also receives the requested content version or QoE from the interceptor 36, which has extracted this information from the content player’s 37 requests.

[0088] Accordingly, the source selection algorithm 33 obtains the requested version or QoE and at least one of a throughput rate, goodput rate, and other parameter(s), such as a buffer fullness level, related to the download. Based on this information, the source selection algorithm 33 performs the process described in fig. 2 above and determines whether or not a second type source 21 should be utilized.

[0089] With further reference to fig. 4, the details for determining whether to initiate download from a second type source according to some implementations will now be described in further detail. In fig. 2, step S6 relates to comparing the goodput rate with a goodput threshold to determine whether second type sources are to be used for the download. In some implementations, step S6 will further comprise considering a buffer threshold and a buffer fullness level obtained from the content player 37.

[0090] The buffer fullness level indicates an amount or duration of buffered content available to the content player 37. For example, the buffer fullness level indicates the amount or duration of (decoded) playback-ready content stored in the content player’s 37 buffer.

[0091] As network encoded content is continuously downloaded and stored also in the network decoder 35 prior to being decoded, the amount of content stored in the content player’s 37 buffer may be a slight underestimation of the amount of content available to the content player 37. For instance, if it is likely that an encoded segment that is currently being downloaded and/or decoded by the network decoder 35 will be fully downloaded and/or decoded prior to the content in the media player’s 37 buffer being consumed, the amount of content associated with this encoded segment may be included in the buffer fullness level as well, in addition to the decoded content stored in the content player’s 37 buffer. An example of how the download/decode process of the network decoder 35 can be considered together with the amount of decoded content in the content player’s 37 buffer is described in “METHOD FOR DATA RATE AND BUFFER ESTIMATION FOR MULTI-SOURCE DELIVERY” filed as International Application No. PCT/US2022/044237 on September 21, 2022, hereby incorporated by reference in its entirety. As explained in this reference, an amount of buffered content available to the content player 37 may be determined as the sum of the content stored in the buffer, and the content associated with a segment being currently downloaded multiplied with a weighting factor. In one example implementation, the weighting factor is one if it is likely that the segment will be fully downloaded and decoded prior to the content in the buffer being consumed and zero if it is likely that the segment will not be fully downloaded and decoded prior to the content in the buffer being consumed. In general, it is possible to get a finer granularity estimation of the amount of available content by determining a likelihood of A% that the segment will be fully downloaded and decoded prior to the content in the buffer being consumed, whereby the weighting factor is set to the likelihood A%. That is, the buffer fullness level may be the actual amount of content stored in the content player’s 37 buffer, or the amount of available content which includes the amount of content stored in the content player’s 37 buffer as well as at least a portion of the content associated with a segment being currently downloaded to the network decoder 35.

[0092] At step S61 the source selection algorithm obtains this buffer fullness level (e.g., the amount of content in the buffer or a measure of the available content considering the amount of content in the buffer and the download/decoding progress of the network decoder 35) and compares it to a buffer threshold. If the buffer fullness level exceeds the buffer threshold, the method goes to step S62 comprising comparing the goodput rate to a first goodput threshold. If the goodput rate exceeds the first goodput threshold the method goes to step S7 and continues in accordance with the flowchart of fig. 2. If the goodput rate is determined at step S62 to be below the first goodput threshold the method instead goes to step S8 and continues in accordance with the flowchart of fig. 2 by initiating downloading content from at least one second type source. [0093] On the other hand, if it is determined at step S61 that the buffer level is below the buffer threshold the method instead goes to step S63 comprising comparing the goodput rate to a second goodput threshold. If the goodput rate exceeds the second goodput threshold the method goes to step S7 and continues in accordance with the flowchart of fig. 2. If the goodput rate is determined at step S63 to be below the second goodput threshold the method instead goes to step S8 and continues in accordance with the flowchart of fig. 2 by initiating downloading content from at least one second type source.

[0094] The first goodput threshold is lower with respect to the second goodput threshold. Effectively, this results in a dynamic control of the goodput threshold based on the buffer fullness level. In this way, the source selection algorithm 33 is made more tolerant of lower goodput rates if there is much content available to the content player 37 (e.g., a high buffer fullness level). This effectively avoids downloading from second type sources 21 due to a temporary drop in throughput/goodput from the first type source(s) 11 in situations where sufficient content is available to the content player 37 to continue playback without risking decreased QoE or interruptions.

[0095] As an illustrative example, the buffer threshold may be 10 seconds of content, the first goodput threshold is 5 Mb/s and the second goodput threshold is 8 Mb/s. The source selection algorithm 33 will then repeatedly evaluate step S6 and check whether more than 10 seconds of content is available to the media player 37. As long as this criterion is fulfilled, no additional second type source 21 will be used for download even if the goodput temporarily drops to 6 or even 5.1 Mb/s. On the other hand, if the goodput stays too low for a long period of time, the buffer fullness level will decrease and when the buffer fullness level indicates that less than 10 seconds of content is stored in the buffer the source selection algorithm 33 will initiate downloading from a second type source 21 as soon as the goodput is below the second goodput threshold of 8 Mb/s.

[0096] It is understood that the above values of first and second goodput threshold, and the buffer threshold are merely exemplary and that other values could be assigned depending on e.g. the type of content being streamed (e.g., audio or video or both) and the type of network connection the client uses (e.g., wired, wireless or mobile network). The buffer threshold should be sufficiently high to allow the download from a second type source(s) 21 to ramp up before the buffered content is consumed. The first goodput threshold may be lower than the average goodput required to sustain the current QoE which has the benefit of tolerating low goodput rates without downloading from a second type source(s) 21 (provided sufficient amount of content is available in the content player’s 37 buffer). The second goodput threshold, on the other hand, may be higher than the average goodput rate required to sustain a current QoE, since the second goodput threshold sets a lower bound for the goodput rate used when the buffer fullness level has passed a critical limit meaning that it is desirable to both increase the amount of buffered content while also continuing the playback of the content.

[0097] In this way, by considering the buffer fullness level and the buffer threshold in addition to the goodput rate, a situation is avoided wherein the source selection algorithm 33 starts downloading from the second type source prematurely.

[0098] Additionally or alternatively, another method for avoiding premature download form a second type source(s) 21 is averaging the measured goodput rate and/or buffer level used by the source selection algorithm 33 over time. For example, the goodput rate and/or buffer level can be averaged over the duration of each segment or over the time interval T2 between subsequent measurements, meaning that temporary fluctuations in the goodput or buffer level sustained by a first type source(s) 11 will be tolerated.

[0099] The sources 11, 21 selected by the source selection algorithm 33 are provided to a flow controller 32 which then transmits the requests to the selected sources 11, 21. The flow controller 32 is configured to request data from the sources 11, 21 designated by the source selection algorithm 33 in way that decreases or minimizes the amount of in-flight data. A method that may be used for achieving this type request allocation between the designated sources 11, 21 is explained in further detail in “DOWNLOAD CONTROL IN MULTI-SERVER COMMUNICATION SYSTEM”, published with International Publication number WO/2020/180988 on September 10, 2020, hereby incorporated by reference in its entirety.

[0100] As explained in this reference, the flow controller 32 may be configured to send initial download requests to the sources 11, 21, receive data associated with these initial download requests and update information regarding quality (e.g., bandwidth and latency) of the communication links over which the requested data is transmitted. Based on the updated quality information of the communication links, the flow controller 32 will then determine how to send the subsequent requests. In other words, while the source selection algorithm 33 determines which sources 11, 21 that are to be used and when, the flow controller 32 will ensure that the sources selected by the source selection algorithm 33 are utilized efficiently. For instance, while data is requested from all sources designated by the source selection algorithm 33 the flow controller 32 controls how much data is to be requested from each source. For example, a source associated with lower latency and higher bandwidth will receive more requests compared to another source associated with higher latency and lower bandwidth.

[0101] The source selection proxy 31 may be configured to use different transport methods for sources of the two different types belonging to the respective. For example, WebRTC data channels or QUIC may be used for downloading from the first type sources 11 (being e.g. peers) and HTTP or QUIC may be used downloading content from the second type sources 21 (being e.g. PoPs belonging to a CDN).

[0102] Fig. 5 is a graph showing an example of how the utilization level of central sources is achieved with the method and source selection proxy described in the above. The horizontal axis denotes time since the downloading of content started and the vertical axis denotes the goodput rate, amount of buffered or available content (e.g., the buffer level or buffer fullness) or the QoE for the lines 51, 52, 53, 54, 55, 56.

[0103] Line 51 indicates the QoE for the content being downloaded and played back. The QoE is stable at the same level throughout the download process. For example, the QoE is stable at the highest possible QoE. [0104] Line 52 indicates the buffer level or amount of (decoded) content available to the content player. At the start of the download at ti there is no content available to the content player however when the download continues the buffer level increases and at time t3 the buffer level has stabilized at a certain amount or duration of content.

[0105] Line 53 indicates the goodput received from a second type source (e.g., a CDN). As seen, line 53 is discontinuous and not present between times t2 and t3. This is the result of the source selection algorithm determining at t2 that the goodput offered by first type sources (indicated with lines 55 and 56) exceeds the goodput threshold and the second type source is not necessary. From t2 to t3 the source selection algorithm only uses first type source(s) and the buffer level (line 52) continues to increase while the QoE (line 51) is stable. At time t3, the goodput offered by the first type sources has dropped dramatically and the source selection algorithm detects this as the measured goodput rate is below the goodput threshold. In response, the source selection algorithm adds a second type source to the list of sources from which the content should be downloaded and from time t3 to t4 data is downloaded from the second type source (line 53) in addition to a small amount of data being downloaded from the first type sources (lines 55 and 56).

[0106] Accordingly, the utilization of the second type sources is effectively mitigated from time t2 to time t3, and only used for downloading content when the goodput of the first type sources drops at t3.

[0107] Line 54 indicates the total aggregated goodput achieved with the first type sources and the second type sources at each point in time. Line 54 indicates goodput just as lines 53, 55, and 56 but is plotted at a different scale. As seen the total aggregated goodput remains stable throughout the download between ti and t4 despite only first type sources being used between t2 and t3 and a second type source being mainly used between t3 and t4. Accordingly, the source selection method achieves efficient utilization reduction of for central sources without a trade-off in QoE or total goodput.

[0108] Fig. 6 is a flow chart describing a simplified method for comparing the goodput threshold to the goodput rate for determining whether an additional second type source should be used for downloading content. Steps SI, S2, S3, S8, S9 and S 10 are analogous to the corresponding steps from fig. 2. In the flowchart of fig. 6, the first source type may be edge sources or central sources. In the below any first type source is assumed to be an edge source and any second type source is assumed to be a central source, but the same method is also performed when any first type source is a central source, and any second type source is an edge source. [0109] Instead of determining a goodput rate and a goodput threshold explicitly, the method of fig. 6 involves implicit determination of whether the goodput rate exceeds the goodput threshold. If it is determined at step S2 that first type sources are available, the downloading of a network encoded segment of content from the first type source(s) is initiated at step S3. The method then goes to step S41 involving waiting a predetermined time T3 prior to going to step S7 involving checking whether the decoding of the segment has been completed or not. If the decoding has been completed after T3 time since downloading started, the method goes to step S10 involving providing the decoded content to the content player. On the other hand, if the decoding of the segment has not been completed at step S7 the method goes to step S8 and starts downloading from at least one additional second type source.

[0110] That is, a goodput rate is determined indirectly by checking whether T3 time was sufficient to allow the segment to be downloaded and decoded. The goodput threshold is indirectly determined by the time T3. It is understood, that for a predetermined segment size, an expected segment decoding size and a requested QoE the waiting time T3 can be set to an appropriate value effectively resulting in a goodput threshold. For example, if the content player requests a QoE that on average requires X Mb/s to sustain, each encoded segment carries Y Mb content of which Z% is overhead data the waiting T3 can be set to Y*(Z/100)/X seconds. For instance, X = 5, Y = 1 and Z=20 resulting in T3 = 160 ms. In other words, to sustain the QoE a new segment should be decoded and provided to the content player every 160 ms and if the method determines at step S7 that this is not the case, the method starts downloading content from an additional second type source at step S8.

[OHl] The above numerical values are merely exemplary and other values could be used in the same manner. Additionally, it is envisaged that T3 may be shortened from the above exemplified time required to sustain a QoE to enhance reliability and bias the downloading towards sustaining the QoE of the stream while also increasing the amount of buffered content. [0112] Unless specifically stated otherwise, as apparent from the following discussions, it is appreciated that throughout the disclosure discussions utilizing terms such as “processing”, “computing”, “calculating”, “determining”, “analyzing” or the like, refer to the action and/or processes of a computer hardware or computing system, or similar electronic computing devices, that manipulate and/or transform data represented as physical, such as electronic, quantities into other data similarly represented as physical quantities.

[0113] It should be appreciated that in the above description of exemplary embodiments of the invention, various features of the invention are sometimes grouped together in a single embodiment, figure, or description thereof for the purpose of streamlining the disclosure and aiding in the understanding of one or more of the various inventive aspects. This method of disclosure, however, is not to be interpreted as reflecting an intention that the claimed invention requires more features than are expressly recited in each claim. Rather, as the following claims reflect, inventive aspects lie in less than all features of a single foregoing disclosed embodiment. Thus, the claims following the Detailed Description are hereby expressly incorporated into this Detailed Description, with each claim standing on its own as a separate embodiment of this invention. Furthermore, while some embodiments described herein include some but not other features included in other embodiments, combinations of features of different embodiments are meant to be within the scope of the invention, and form different embodiments, as would be understood by those skilled in the art. For example, in the following claims, any of the claimed embodiments can be used in any combination.

[0114] Furthermore, some of the embodiments are described herein as a method or combination of elements of a method that can be implemented by a processor of a computer system or by other means of carrying out the function. Thus, a processor with instructions for carrying out such a method or element of a method forms a means for carrying out the method or element of a method. Note that when the method includes several elements, e.g., several steps, no ordering of such elements is implied, unless specifically stated. Furthermore, an element described herein of an apparatus embodiment is an example of a means for carrying out the function performed by the element for the purpose of carrying out the embodiments of the invention. In the description provided herein, numerous specific details are set forth. However, it is understood that embodiments of the invention may be practiced without these specific details. In other instances, well-known methods, structures and techniques have not been shown in detail in order not to obscure an understanding of this description.

[0115] Thus, while there has been described specific embodiments of the invention, those skilled in the art will recognize that other and further modifications may be made thereto without departing from the spirit of the invention, and it is intended to claim all such changes and modifications as falling within the scope of the invention.

[0116] Various aspects of the present disclosure may be appreciated from the following Enumerated Example Embodiments (EEEs):

EEE1. A method for downloading content from multiple sources over a network, the method comprising: downloading network encoded content from each source in an initial source set, the initial source set comprising at least one source of a first type in the network and the network encoded content being coded with a network code; determining a goodput rate of the network encoded content being downloaded from the initial source set; comparing the goodput rate to a goodput threshold; if the goodput rate is below a goodput threshold: forming an updated source set by adding a source of a second type to the initial source set, wherein the second source type is different than the first source type; and continuing downloading the network encoded content from each source in the updated source set.

EEE2. The method according to EEE1, wherein if the goodput rate is above the goodput threshold, the method comprises: continuing downloading the network encoded content from each source in the initial source set.

EEE3. The method according to any one of the preceding EEEs, wherein the second source type comprises peer sources or edge-cache sources, and the first source type comprises sources belonging to a Content Delivery Network, CDN.

EEE4. The method according to EEE1 or EEE2, wherein the first source type comprises peer sources or edge-cache sources, and the second source type comprises sources belonging to a Content Delivery Network, CDN.

EEE5. The method according to any one of the preceding EEEs, wherein downloading network encoded content comprises downloading a current network encoded segment of a plurality of consecutive network encoded segments.

EEE6. The method according to EEE5, further comprising: downloading a first portion of the current network encoded segment with the initial source set; downloading a remaining portion of the current network encoded segment with the updated source set; and initializing downloading of a subsequent, with respect to the current segment, network encoded segment with the initial source set.

EEE7. The method according to EEE5 or EEE6, further comprising determining the goodput rate by measuring the goodput rate at multiple points in time while downloading the current network encoded segment. EEE8. The method according to EEE7, wherein the goodput rate is averaged over the multiple measurements of the goodput rate.

EEE9. The method according to any one of the preceding EEEs, further comprising: determining a set of accessible first type sources; determining the initial source set by selecting at least one first type source in the set of accessible first type sources; determining a set of accessible second type sources; wherein adding the second type source to the initial source set to form the updated source set comprises selecting a second type source from the set of accessible second type sources.

EEE 10. The method according to EEE9, further comprising repeatedly updating the set of accessible first type sources and the set of accessible second type sources.

EEE11. The method according to any one of the preceding claims, wherein obtaining a goodput threshold comprises: obtaining a current Quality of Experience, QoE, level associated with the content; and determining the goodput threshold based on the goodput rate required to sustain the current QoE level.

EEE 12. The method according to EEE11, further comprising: intercepting a content request from a content player; and obtaining the QoE level based on the content request from the content player.

EEE13. The method according to EEE11 or EEE 12, further comprising: obtaining a target QoE level; comparing the current QoE level with the target QoE level; if the current QoE level indicates a lower QoE compared to the target QoE: forming the updated source set by adding at least one second type source to the initial source set; and downloading network encoded content from each source in the updated source set.

EEE14. The method according to any one of the preceding EEEs, wherein the initial source set comprises at least two first type sources. EEE15. The method according to any one of the preceding EEEs, wherein the initial source set comprises only sources of the first source type.

EEE 16. The method according to any one of the preceding EEEs, further comprising: decoding the network encoded content to obtain decoded content; and providing the decoded content into a buffer, associated with a media player.

EEE 17. The method according to any one of the preceding EEEs, further comprising: obtaining a buffer fullness level, indicating the amount of buffered content stored in the buffer of a content player; if the buffer fullness level exceeds a buffer threshold, setting the goodput threshold to a first goodput threshold; else, setting the goodput threshold to a second goodput threshold; wherein the second goodput threshold is higher compared to the first goodput threshold.

EEE18. A computer program product comprising instructions which, when the program is executed by a computer, causes the computer to carry out the method according to any one of EEE1 to EEE17.

EEE19. A computer-readable storage medium storing the computer program according to EEE18.

EEE20. A computer device comprising a processor configured to carry out the method according to any of EEE 1 to EEE 17.

EEE21. A source selection proxy, comprising a computer device according to EEE20, wherein the source selection proxy is configured to download content requested by a content player.

EEE22. A streaming client device, comprising the source selection proxy according to EEE21, and a content player.

Claims

1. A method for downloading content from multiple sources over a network, the method comprising: downloading network encoded content from each source in an initial source set, the initial source set comprising at least one source of a first type in the network and the network encoded content being coded with a network code; determining a goodput rate of the network encoded content being downloaded from the initial source set; comparing the goodput rate to a goodput threshold; if the goodput rate is below a goodput threshold: forming an updated source set by adding a source of a second type to the initial source set, wherein the second source type is different than the first source type; and continuing downloading the network encoded content from each source in the updated source set.

2. The method according to claim 1, wherein if the goodput rate is above the goodput threshold, the method comprises: continuing downloading the network encoded content from each source in the initial source set.

3. The method according to any one of the preceding claims, wherein the second source type comprises peer sources or edge-cache sources, and the first source type comprises sources belonging to a Content Delivery Network, CDN.

4. The method according to claim 1 or claim 2, wherein the first source type comprises peer sources or edge-cache sources, and the second source type comprises sources belonging to a Content Delivery Network, CDN.

5. The method according to any one of the preceding claims, wherein downloading network encoded content comprises downloading a current network encoded segment of a plurality of consecutive network encoded segments.

6. The method according to claim 5, further comprising: downloading a first portion of the current network encoded segment with the initial source set; downloading a remaining portion of the current network encoded segment with the updated source set; and initializing downloading of a subsequent, with respect to the current segment, network encoded segment with the initial source set.

7. The method according to claim 5 or claim 6, further comprising determining the goodput rate by measuring the goodput rate at multiple points in time while downloading the current network encoded segment.

8. The method according to claim 7, wherein the goodput rate is averaged over the multiple measurements of the goodput rate.

9. The method according to any one of the preceding claims, further comprising: determining a set of accessible first type sources; determining the initial source set by selecting at least one first type source in the set of accessible first type sources; determining a set of accessible second type sources; wherein adding the second type source to the initial source set to form the updated source set comprises selecting a second type source from the set of accessible second type sources.

10. The method according to claim 9, further comprising repeatedly updating the set of accessible first type sources and the set of accessible second type sources.

11. The method according to any one of the preceding claims, wherein obtaining a goodput threshold comprises: obtaining a current Quality of Experience, QoE, level associated with the content; and determining the goodput threshold based on the goodput rate required to sustain the current QoE level.

12. The method according to claim 11, further comprising: intercepting a content request from a content player; and obtaining the QoE level based on the content request from the content player.

13. The method according to claim 11 or claim 12, further comprising: obtaining a target QoE level; comparing the current QoE level with the target QoE level; if the current QoE level indicates a lower QoE compared to the target QoE: forming the updated source set by adding at least one second type source to the initial source set; and downloading network encoded content from each source in the updated source set.

14. The method according to any one of the preceding claims, wherein the initial source set comprises at least two first type sources.

15. The method according to any one of the preceding claims, wherein the initial source set comprises only sources of the first source type.

16. The method according to any one of the preceding claims, further comprising: decoding the network encoded content to obtain decoded content; and providing the decoded content into a buffer, associated with a media player.

17. The method according to any one of the preceding claims, further comprising: obtaining a buffer fullness level, indicating the amount of buffered content stored in the buffer of a content player; if the buffer fullness level exceeds a buffer threshold, setting the goodput threshold to a first goodput threshold; else, setting the goodput threshold to a second goodput threshold; wherein the second goodput threshold is higher compared to the first goodput threshold.

18. A computer program product comprising instructions which, when the program is executed by a computer, causes the computer to carry out the method according to any one of claims 1-17.

19. A computer-readable storage medium storing the computer program according to claim 18.

20. A computer device comprising a processor configured to carry out the method according to any one of claims 1-17.

21. A source selection proxy, comprising a computer device according to claim 20, wherein the source selection proxy is configured to download content requested by a content player.

22. A streaming client device, comprising the source selection proxy according to claim

21, and a content player.