[go: up one dir, main page]

WO2020193429A1 - Procédé d'obtention d'un segment de données par un dispositif client apte à communiquer avec une pluralité de réseaux de diffusion de contenu - Google Patents

Procédé d'obtention d'un segment de données par un dispositif client apte à communiquer avec une pluralité de réseaux de diffusion de contenu Download PDF

Info

Publication number
WO2020193429A1
WO2020193429A1 PCT/EP2020/057862 EP2020057862W WO2020193429A1 WO 2020193429 A1 WO2020193429 A1 WO 2020193429A1 EP 2020057862 W EP2020057862 W EP 2020057862W WO 2020193429 A1 WO2020193429 A1 WO 2020193429A1
Authority
WO
WIPO (PCT)
Prior art keywords
network
client device
data
score
segment
Prior art date
Application number
PCT/EP2020/057862
Other languages
English (en)
Inventor
Axel DELMAS
Paul-Louis AGENEAU
Original Assignee
Streamroot
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Streamroot filed Critical Streamroot
Priority to JP2021555572A priority Critical patent/JP2022525217A/ja
Priority to AU2020249319A priority patent/AU2020249319A1/en
Priority to EP20712568.3A priority patent/EP3942778A1/fr
Priority to CA3133413A priority patent/CA3133413A1/fr
Priority to SG11202110485QA priority patent/SG11202110485QA/en
Priority to KR1020217034291A priority patent/KR20210139431A/ko
Publication of WO2020193429A1 publication Critical patent/WO2020193429A1/fr

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/60—Scheduling or organising the servicing of application requests, e.g. requests for application data transmissions using the analysis and optimisation of the required network resources
    • H04L67/63—Routing a service request depending on the request content or context
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00—Arrangements for monitoring or testing data switching networks
    • H04L43/08—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters
    • H04L43/0876—Network utilisation, e.g. volume of load or congestion level
    • H04L43/0882—Utilisation of link capacity
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/61—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/80—Responding to QoS
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H04L67/1001—Protocols in which an application is distributed across nodes in the network for accessing one among a plurality of replicated servers
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/56—Provisioning of proxy services
    • H04L67/568—Storing data temporarily at an intermediate stage, e.g. caching
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W24/00—Supervisory, monitoring or testing arrangements
    • H04W24/08—Testing, supervising or monitoring using real traffic
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W48/00—Access restriction; Network selection; Access point selection
    • H04W48/18—Selecting a network or a communication service

Definitions

  • the present invention relates to a method of obtaining a data segment by a client device capable of communicating with a plurality of content delivery networks.
  • the invention advantageously (but not exclusively) finds an application in the context of playing a multimedia stream comprising such data segments.
  • a content delivery network (Content Delivery Network, abbreviated as CDN in the following) comprises one or more servers networked through the Internet and which cooperate in order to make content or data available to client devices. owned by users.
  • the same data segment may be available from several competing CDNs.
  • a client device can have the choice between several CDNs to obtain this segment of data.
  • the invention aims to allow a client device to choose a CDN from which to obtain a data segment among several available CDNs, taking into account the data transmission conditions between these CDNs and the client device, but in a more flexible than with the approach mentioned in the introduction.
  • a method for obtaining a data segment by a client device capable of communicating with a plurality of content distribution networks comprising steps of: - for each network of the plurality of networks, calculating a score associated with the indicative network a quality of data transmission from the network to the client device,
  • the random selection being adapted so that a probability of drawing a network from the plurality associated with a score indicative of a first transmission quality is greater than a probability of drawing a network of the plurality associated with a score indicative of a second transmission quality lower than the first transmission quality
  • the method according to the first aspect of the invention can also include the following characteristics or steps, taken alone or combined with one another when technically possible.
  • the random draw may depend on an exploration parameter, the random draw then being suitable for:
  • the method may further comprise steps of
  • At least two networks of the plurality, or even all of the networks of the plurality, preferably have non-zero probabilities of being drawn.
  • the steps of calculating score, random selection, and solicitation are preferably repeated for several data segments belonging to a set of data such as a multimedia stream or a file.
  • the data segment belongs to a data set, and the scores are initialized to initial values before the device obtains any segment of the data set.
  • the initial score value of one of the plurality's network is determined based on information indicative of a transmission quality of data segments from the same network to at least one third-party device different from the client device.
  • This information is for example provided to the client device by an aggregation server capable of communicating with each third-party device.
  • the score of this first network is preferably updated taking into account the effective transmission quality of at least one segment transmitted by the first network to the client device.
  • the score of this second network is preferably updated. taking into account the value of the score of the first network.
  • the method may include calculating a bandwidth heuristic indicative of a bandwidth available for transmission of data segments through a network of the plurality to the client device, the score associated with that network being dependent on the band heuristic. calculated pass.
  • the method may include calculating a transmission error heuristic associated with a network of the plurality, the transmission error heuristic being indicative of transmission errors of data segments having previously been requested by the client device from the network, the score associated with this network depending on the calculated transmission error heuristic.
  • the transmission error heuristic associated with one of the plurality's network varies so as to make it less likely that the network will be randomized when the network fails to transmit a segment of data to the client device.
  • the transmission error heuristic associated with a network of the plurality varies by an amount which itself increases with a number of past segment transmission errors associated with that network.
  • the transmission error heuristic associated with a network varies so as to make it more likely that the network will be randomized when the network is successful in transmitting a data segment to the client device.
  • the transmission error heuristic of a network varies so as to make it more likely that the network is randomized, when no data segment is transmitted from the network to the client device within a predetermined period of time. .
  • the score associated with a network may also depend on a predefined weight specific to this network, this weight being for example a constant.
  • a method for reading by a client device of a multimedia stream comprising a plurality of data segments, the method comprising obtaining at least one of the data segments. by means of the method according to the first aspect of the invention.
  • a computer program product comprising program code instructions for the execution of the steps of the method according to the first aspect or the second aspect of the invention, when this program is executed by a client device.
  • a medium readable by a client device on which is stored a computer program comprising program code instructions for the execution of the steps of the method according to the first aspect or according to the second aspect of the invention.
  • a client device intended to obtain a data segment
  • the client device comprising a communication interface for communicating with a plurality of content distribution networks, and a processing unit. configured to control the implementation of the steps of the method according to the first aspect or according to the second aspect of the invention.
  • FIG. 1 schematically represents a client device according to an embodiment of the invention and several content distribution networks.
  • FIG. 2 is a flowchart of steps of a method for obtaining a data segment according to an embodiment of the invention.
  • FIG. 1 shows a client device 1 capable of communicating with a plurality of content distribution networks (CDNs). Only two CDNs referenced CDN1 and CDN2 are shown in this figure, but a set of N CDNs indexed from 1 to N.
  • CDNs content distribution networks
  • each CDN includes at least one server, it being understood that these CDNs can include more than a single server, as mentioned in the introduction.
  • Each CDN stores data segments belonging to the same data set.
  • all CDNs include the entire dataset, that is, all segments of that dataset.
  • the dataset can be a data file, intended to be referenced in a file system for access to that file.
  • the dataset is a media stream in the form of one or more files.
  • the segments of the considered data set are ordered among themselves.
  • the segments correspond to different portions of the binary forming the file, each portion having a relative address (offset) of its own with respect to the start address of the file.
  • the segments of a multimedia stream are temporally ordered: each segment is associated with or includes a time stamp of its own.
  • the different timestamps make it possible to determine in which order the different segments of the multimedia stream should be read by a player.
  • a time window corresponding to the N last minute or last million hours is available on the content network.
  • data set is understood to mean the collection of multimedia data which form this time window.
  • a new video segment is generated by a live encoder, it is added back to the dataset while the oldest segment expires and is removed from the dataset.
  • a data segment designates a portion of the data set which is capable of being transmitted to the client device 1 independently of the other segments of the data set. data from the same data set.
  • the client device 1 also includes a communication interface 2 for communicating with the various CDNs, and in particular receiving segments of the data set from these CDNs.
  • the client device 1 further comprises a memory 4 for storing segments received via the communication interface 2, and a processing unit 6 configured to process the data segments contained in the memory 4.
  • the processing unit 6 comprises for example at least one processor configured to execute a computer program comprising code instructions implementing this processing.
  • the processing unit 6 includes a reader configured to read the data segments.
  • a reader comprises a decoder configured to decode the segments, and an output arranged at the output of the decoder to restore a content of segments, such as a display screen in the case of a video segment, or a speaker in the case of an audio segment.
  • the processing unit 6 is configured to assemble the different segments which form this file once they have been received, so as to form a copy of the referenced file in a system of client device files 1.
  • the processing unit 6 is also configured to select from among the different CDNs a CDN to be requested in order to obtain a data segment to be processed. This selection is for example implemented in the computer program comprising code instructions implementing the subsequent processing of these segments, or else implemented in a separate selection program.
  • the client device 1 is aware of the various CDNs which it can access. For example, the addresses of these CDNs are stored in the memory 4 of the client device 1.
  • an aggregation server 8 with which the client device 1 is able to communicate.
  • the aggregation server includes a memory and a processing unit configured to apply calculations to data it receives from the aggregation server.
  • client device 1 as well as other client devices 1 a, 1 b, which will be referred to as third-party devices in contrast to client device 1.
  • Devices 1 a and 1 b are configured in the same way as device 1.
  • Any of the devices 1, 1 a, 1 b can take the form of, for example, a desktop computer, a television set, a laptop computer, a tablet, a smartphone, etc.
  • processing unit 6 calculates a score x, associated with the CDN of index i.
  • the score x is indicative of a quality of data transmission from the CDN of index i to the client device 1 (step 100). This calculation 100 will be more fully detailed below.
  • a score x increases with the quality of data transmission from this CDN to the client device 1.
  • a score of 10 indicates better data transmission quality than a score of 5, for example.
  • the processing unit 6 implements a random drawing of a CDN among the different CDNs (step 102).
  • P the probability of drawing the CDN of index i among the N CDNs available via this random drawing 102.
  • the random draw 102 is adapted so that the probability of drawing a CDN associated with a score indicative of relatively high transmission quality is greater than the probability of drawing a CDN associated with a score indicative of relatively low transmission quality.
  • This random draw 102 is also such that at least two of the N CDNs, or even all of the CDNs, have non-zero probabilities of being drawn.
  • the random draw step 102 may comprise the following substeps.
  • the processing unit 6 calculates the selection probabilities P j associated with the scores X j .
  • the processing unit 6 then implements a uniform random selection of a number in an interval whose length is equal to the sum of the probabilities Pj.
  • This interval is the union of N distinct sub-intervals respectively associated with the different CDNs.
  • the sub-interval associated with the CDN of index j is of length equal to the probability Pj.
  • the CDN drawn at random during step 102 is the CDN associated with the subinterval including the number drawn.
  • the random draw 102 preferably depends on a parameter C, called the exploration parameter.
  • the random drawing is adapted to increase the probability of drawing the network associated with the highest score among all the scores calculated relative to the probabilities of drawing the other networks of the plurality, when the value of the exploration parameter varies in a first direction , and / or decrease the probability of drawing the network associated with the highest score among all the scores calculated relative to the probabilities of drawing the other networks of the plurality, when the value of the exploration parameter varies in a second direction opposite to the first sense.
  • the probability P j of extracting a CDN of index j among the N CDNs available is of the following form:
  • the exploration parameter C can be fixed, but can also be adjusted dynamically (the case of such a dynamic adjustment is detailed later).
  • the network having been drawn randomly is then requested by the client device 1 for the client device 1 to obtain a segment of the data set (step 104).
  • This request 104 comprises for example the transmission by the client device 1 via the communication interface 2 of a segment request intended for the drawn CDN, and the transmission by the CDN drawn from the segment targeted by the request, in response to this one.
  • a solicitation 104 of the CDN pulled by the client device may be successful or unsuccessful. Indeed, errors may occur during this solicitation: the request may not reach the drawn CDN; the pulled CDN may not output the requested segment at all due to an internal bug; finally, the pulled CDN may send the segment requested by client device 1, but this segment may not be transmitted correctly to client device 1.
  • client device 1 may repeat solicitation step 104 until the data segment is obtained. However, it is preferable not to repeat such a request immediately: we will focus on this embodiment below.
  • the processing unit 6 can control the reading of the data segment by a reader (the processing of the segment is a reading).
  • processing unit 6 checks whether all the segments which form the file have been received. If so, processing unit 6 assembles all the segments so as to reconstruct a copy of the file and reference it in a file system. Otherwise, the unit waits for other data segments in the file.
  • the processing unit 6 evaluates the effective quality of the transmission of the segment which has been received from the CDN previously drawn randomly (step 106).
  • This assessment may include calculating a bandwidth heuristic indicative of a bandwidth available for data transmission from the pulled CDN to the client device 1.
  • the bandwidth heuristic depends on an instantaneous bandwidth made available to the client device 1 in order to obtain the segment of the CDN drawn during step 104.
  • This instantaneous bandwidth is typically calculated in the form of a ratio between the time taken to obtain the segment and the size of this segment.
  • the request 104 of the pulled CDN can result in success (a data segment is obtained by the client device 1) or in failure (the client device 1 does not receive the data segment).
  • the evaluation of the effective quality of the transmission of the segment may include the calculation of a transmission error heuristic, this transmission heuristic being indicative of transmission errors of data segments having previously been requested by the client device to the network (in particular the segment that the client device requested from the pulled CDN, during the solicitation step 104).
  • Such transmission errors can in practice be measured by the client device 1 at a session layer (typically HTTP) or at a higher level layer in the OSI model, such as an application layer.
  • a session layer typically HTTP
  • a higher level layer in the OSI model such as an application layer.
  • errors can be of various types: 404 error (or 40X or 50X), timeout error (the segment was not obtained within the allotted time given by an http download module of the client device 1), temporary network disconnection from the client device 1, error on the HTTPS handshake, error relating to browser security (CORS, mixed content HTTP / HTTPS), etc.
  • Each calculated heuristic is stored in the memory 4 of the client device 1.
  • the processing unit 6 can assess a risk of degradation of processing conditions by the client device 1 of the data set comprising the data segment , and modify the value of the exploration parameter C according to the assessed degradation risk (step 108).
  • These processing conditions are for example conditions for reading the data segment by the client device 1 when this set is a multimedia stream to be played,
  • the evaluation of the risk of degradation of the reading conditions of the multimedia stream to be played implemented during step 108 can take into account the change in the filling rate of a buffer upstream of the player of the client device. 1. Indeed, such a filling rate can indicate whether or not the reading of the stream risks being interrupted if the CDN pulled during step 102 is not of optimal quality and the downloading of a segment from this pulled CDN is taking longer than expected (this interrupt typically occurs when the drive needs to process a new segment, but the buffer is empty). If, for example, it has been detected that there is a high risk of degradation of these processing conditions, it may be preferable for safety reasons to make the draft less exploratory by varying the value of C. In the absence of risk or at the time of a lower risk of degradation, one can authorize oneself to request other CDNs than the one considered of better quality; in other words, the value of C can in this case be modified to make the drawing more exploratory.
  • Another way to assess the risk of degradation of the processing conditions of the dataset is to consult the results obtained during step 106. Typically, if the transmission of the segment that the device requested from the pulled CDN to the during step 104 failed, the risk increases.
  • the steps 100, 102, 104, 106, 108 represented in FIG. 2 form an iteration of the method.
  • Several iterations of the process are implemented over time, with each iteration aimed at obtaining and processing a new segment of the data set. For example, a new iteration is implemented for each new segment that the client device 1 must obtain and process.
  • a new random draw is implemented at the same time.
  • step 102 of a following iteration A different CDN than the one that failed to provide the segment is likely to be pulled and will then be requested by the client device 1 to provide the same segment.
  • repeating step 100 implies that multiple score calculations are performed over time for a given CDN.
  • a single score variable for a given CDN is allocated in memory.
  • each score is updated.
  • the score of each CDN changes over time.
  • a CDN can see its quality score decrease or increase, which obviously has an influence on the subsequent random draw.
  • the client device 1 can send to the aggregation server 8 information indicative of a quality of transmission of data segments to this client device 1, from one or the other of the CDNs (step 110).
  • This information can include at least one of the following data associated with a given CDN: • the score calculated for this CDN during an implementation of step 100,
  • step 110 it is not necessary for the client device 1 to implement this step of sending information 110 to the aggregation server at each iteration. It may also be provided to trigger step 110 asynchronously with respect to the other steps shown in Figure 2. In practice, provision is made to aggregate the most granular information on the client side and send it to the aggregation server 8 periodically.
  • the process ends after all segments of the dataset have been received by and processed by client device 1.
  • the scores of the different CDNs are initialized to initial values.
  • these initial values are different and proportional to respective weights associated with these different CDNs.
  • the initial values can be determined autonomously by the client device 1. They are for example stored in advance in memory 4. However, in a particularly advantageous embodiment, the aggregation server 8 supplies the client device 1 with information which makes it possible to define the initial values of the scores associated with the different CDNs.
  • the initial values supplied by the aggregation server 8 to the client device 1 depend on information that has been previously reported by at least one third-party device that has implemented the same method as the client device 1 (on has indeed seen previously that the client device 1 itself sends all or part of the scores it calculates to the aggregation server 8 during step 110).
  • the aggregation server 8 directly provide the initial score value of a CDN index i to the client device 1.
  • the aggregation server 8 aggregates the information it receives from at least one third-party device such as 1a or 1b, and which concerns the CDN of index i.
  • the aggregation server 8 provides the client device with more granular information than scores, for example the heuristics discussed previously.
  • the heuristics managed by the device 1 are themselves initialized to the values received from the aggregation server 8. These initial heuristic values then make it possible to calculate the initial values of the scores during the first implementation of the l. 'calculation step 100.
  • the calculation step 100 is implemented in the same way in the first iteration and in the subsequent iterations.
  • the aggregated information may only include the following information:
  • Calling on the aggregation server 8 allows the scores to be initialized to more relevant initial values. As a result, the process will be more efficient in obtaining and processing the first segments of the considered dataset.
  • the term "solicited” implicitly refers to solicitation step 104 and the dataset discussed so far.
  • a "solicited" CDN has therefore been drawn randomly at least once during an implementation of step 102 and has provided at least one segment of the considered data set to the client device 1.
  • the evaluation step 106 has therefore been implemented at least once for this CDN of index i, for at least one segment previously transmitted by the CDN of index i and received by the client device 1.
  • a new segment of the data set must now be obtained by the client device 1 in order to process it in a new iteration, called the current iteration.
  • the processing unit 6 updates the score x, as a function of at least one heuristic (bandwidth heuristic and / or error heuristic) associated with the CDN d index i and previously calculated. In this way, the new score x, takes into account the conditions under which the client device 1 has already received segments of the CDN of index i.
  • heuristic bandwidth heuristic and / or error heuristic
  • the score value of a CDN remains at its initial value until that CDN is requested.
  • the appearance of such deviations can occur when the client device 1 receives initial heuristics values which depend on heuristics calculated by third-party devices benefiting from a quality of communication with CDNs very different from that seen by the client device 1
  • the client device 1 benefits from a good connection to the CDNs (by optical fiber for example) while the third-party devices 1a, 1b benefit from a less efficient connection to these CDNs (ADSL for example).
  • ADSL a less efficient connection to these CDNs
  • the client device 1 initializes its own heuristics to values depending on heuristic values reported by third-party devices 1a or 1b, these initial heuristic values (and therefore the initial score values calculated on their basis by the device client 1) will reflect poorly the real conditions of communication between the CDNs and the client device 1. This is why an update of a heuristic associated with a CDN by the client device may reveal a significant difference between the value of heuristics resulting from this update and the heuristics of other
  • the CDN score of index i is updated by processing unit 6 using previously evaluated heuristics, as indicated above. This update varies the value of the i-index CDN score by a certain factor (equal to the ratio of the score after update to the score before update).
  • the processing unit 6 calculates an update factor of a CDN of index j not yet requested, from the update factor of the CDN of index i.
  • the factor of update calculated for the CDN of index j, not yet requested is proportional to the update factor of the CDN of index i already requested.
  • the update factor calculated for the CDN of index j, not yet requested is proportional to an average of the respective update factors of several CDNs that have already been requested, for example all the CDNs that have already been requested. solicited to obtain segments of the dataset.
  • the processing unit 6 updates the score of the CDN of index j by multiplying its current value by the update factor that has just been calculated for the CDN of index j.
  • the unit updates the existing heuristics associated with the CDN having been drawn during the step of random drawing of the. current iteration, so that these heuristics take into account the conditions under which the reference segment was received during the solicitation step 104 of the current iteration of the drawn CDN.
  • the bandwidth heuristic updated during the current iteration takes into account the instantaneous bandwidth that was used during the reception of the reference segment, but also of the instantaneous bandwidth that was used. during every other segment of the dataset, previously transmitted by the CDN of index i in previous iterations.
  • the bandwidth heuristic is calculated as a sliding average, for example exponential (exponential weighted moving average or EWMA).
  • EWMA exponential weighted moving average
  • the transmission error heuristic is set during the current iteration so as to evolve according to certain advantageous rules. If the CDN pulled during the current iteration failed to transmit the reference segment to client device 1 during solicitation step 104 of the current iteration, the error heuristic associated with the pulled CDN is set. updated so as to make the random selection of this CDN less likely during a next iteration of the process. For example, the error heuristic is updated in this case so as to decrease the value of the score of this CDN during a subsequent implementation of step 100.
  • the associated error heuristic to the drawn CDN is updated so as to make the random selection of this CDN more probable during a following iteration of the method.
  • the error heuristic is updated in this case to increase the score value of this CDN on a subsequent implementation of step 100.
  • the error heuristic associated with other CDNs can also be updated, according to the following modalities.
  • Processing unit 6 determines when the CDN not pulled during the current iteration was last accessed. To determine this, the unit can count time, or count a number of segments or iterations of the process.
  • the processing unit 6 notices that a CDN of index i not drawn during the current iteration has not been drawn in a given period of time (for example, the last K segments received come from 'other CDNs than the CDN of index i, or else no segment has been received from the CDN of index i for X seconds), the error heuristic of this CDN of index i is updated in such a way in making the random selection of the network of index i more probable during a following iteration of the method.
  • This mechanism ultimately amounts to establishing a principle of limitation: it is accepted that a CDN that has not been sanctioned for a sufficiently long period is more likely to be requested in the future, even if this CDN had been sanctioned. before this period.
  • the on error branch is executed during a segment transmission error from the CDN to the client device 1.
  • the on success branch is executed when device 1 successfully receives a segment from the CDN.
  • the variable measured bandwidth is the instantaneous bandwidth measured for the last segment received by the client device 1 of the CDN in question.
  • the bandwidth heuristic associated with a CDN is here the variable bandwidth.
  • the score calculated for a CDN depends on this variable. This bandwidth heuristic is revised upwards if measured_bandwidth>bandwidth; otherwise, it is revised downwards.
  • the error heuristic associated with a CDN corresponds here to the term HANDICAP BASE raised to the power hpw.
  • the hpw value is increased when the client device 1 detects a segment transmission error coming from the CDN in question, and this increase is itself increasing with the term error rate (see the term ERROR_PERCENTAGE_BASE raised to the power error_rate in case of passing in the on error branch).
  • the on tick branch corresponds to the prescription principle mentioned above: it is executed when a counter expires. In practice, this branch is executed periodically for each CDN. At each pass, the hpw value associated with a given CDN is reduced, for example by 1% every second if GAAAAAA is equal to 0.01.
  • the predefined weight for a given CDN is the data weight.
  • the probability variable does not correspond directly to a probability Pi discussed previously (with a value between 0 and 1). To obtain this probability, can for example divide this value by the sum of the probability variables of all the CDNs.
  • hpw is equal to 0, and error rate is equal to 0.01
  • the (constant) parameter BETA is equal to 0.1
  • HANDICAP BASE and ERROR PERCENTAGE BASE are equal to 10.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Multimedia (AREA)
  • Environmental & Geological Engineering (AREA)
  • Computer Security & Cryptography (AREA)
  • Information Transfer Between Computers (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • User Interface Of Digital Computer (AREA)
  • Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)

Abstract

Il est proposé un procédé d'obtention d'un segment de données par un dispositif client apte à communiquer avec une pluralité de réseaux de diffusion de contenu (CDN1, CDN2), le procédé comprenant des étapes suivantes : pour chaque réseau de la pluralité de réseaux, calcul (100) d'un score associé au réseau indicatif d'une qualité de transmission de données depuis le réseau au dispositif client; tirage aléatoire (102) d'un réseau dans la pluralité de réseaux, le tirage aléatoire étant adapté pour qu'une probabilité de tirer un réseau de la pluralité associé à un score indicatif d'une première qualité de transmission soit supérieure à une probabilité de tirer un réseau de la pluralité associé à un score indicatif d'une deuxième qualité de transmission inférieure à la première qualité de transmission; et sollicitation (104) du réseau tiré pour que le dispositif client obtienne le segment de données du réseau tiré.

Description

Procédé d’obtention d’un segment de données par un dispositif client apte à communiquer avec une pluralité de réseaux de diffusion de contenu
DOMAINE DE L'INVENTION
La présente invention concerne un procédé d’obtention d’un segment de données par un dispositif client apte à communiquer avec une pluralité de réseaux de diffusion de contenu.
L’invention trouve avantageusement (mais pas exclusivement) application dans le cadre de la lecture d’un flux multimédia comprenant de tels segments de données.
ETAT DE LA TECHNIQUE
De façon connue, un réseau de diffusion de contenu (Content Delivery Network, abrégé en CDN dans la suite) comprend un ou plusieurs serveurs reliés en réseau à travers Internet et qui coopèrent afin de mettre à disposition du contenu ou des données à des dispositifs clients détenus par des utilisateurs.
Un même segment de données peut être disponible auprès de plusieurs CDNs concurrents. Autrement dit, un dispositif client peut avoir le choix entre plusieurs CDNs pour obtenir un ce segment de données.
Il pourrait être envisagé de sélectionner parmi les différents CDNS disponibles le CDN offrant la meilleure qualité de transmission de contenu au dispositif client.
Si cette approche est intéressante à court terme, elle l’est beaucoup moins à moyen ou long terme. En effet, la qualité de transmission offerte par un CDN est susceptible de varier fortement dans le temps, si bien qu’un CDN considéré comme optimal en termes de qualité de transmission à un instant donné peut devenir sous-optimal à un instant ultérieur.
EXPOSE DE L'INVENTION
L’invention vise à permettre à un dispositif client de choisir un CDN auprès de qui obtenir un segment de données parmi plusieurs CDNs disponibles, en tenant compte des conditions de transmission de données entre ces CDNs et le dispositif client, mais d’une manière plus flexible qu’avec l’approche évoquée en introduction.
Il est donc proposé, selon un premier aspect de l’invention, un procédé d’obtention d’un segment de données par un dispositif client apte à communiquer avec une pluralité de réseaux de diffusion de contenu, le procédé comprenant des étapes de : - pour chaque réseau de la pluralité de réseaux, calcul d’un score associé au réseau indicatif d’une qualité de transmission de données depuis le réseau au dispositif client,
- tirage aléatoire d’un réseau dans la pluralité de réseaux, le tirage aléatoire étant adapté pour qu’une probabilité de tirer un réseau de la pluralité associé à un score indicatif d’une première qualité de transmission soit supérieure à une probabilité de tirer un réseau de la pluralité associé à un score indicatif d’une deuxième qualité de transmission inférieure à la première qualité de transmission,
- sollicitation du réseau tiré pour que le dispositif client obtienne le segment de données du réseau tiré.
Le procédé selon le premier aspect de l’invention peut également comprendre les caractéristiques ou étapes suivantes, prises seules ou combinées entre elles lorsque cela est techniquement possible.
Le tirage aléatoire peut dépendre d’un paramètre d’exploration, le tirage aléatoire étant alors adapté pour :
- faire croître la probabilité de tirer le réseau associé au score le plus élevé parmi tous les scores calculés relativement aux probabilités de tirer les autres réseaux de la pluralité, lorsque la valeur du paramètre d’exploration varie dans un premier sens, et/ou
- faire décroître la probabilité de tirer le réseau associé au score le plus élevé parmi tous les scores calculés relativement aux probabilités de tirer les autres réseaux de la pluralité, lorsque la valeur du paramètre d’exploration varie dans un deuxième sens opposé au premier sens.
Le procédé peut comprendre en outre des étapes de
- évaluation d’un risque de dégradation de conditions de traitement par le dispositif client d’un ensemble de données comprenant le segment de données, telles que des conditions de conditions de lecture par le dispositif client d’un flux multimédia comprenant le segment de données,
- modification de la valeur du paramètre d’exploration d’après le risque de dégradation évalué.
Au moins deux réseaux de la pluralité, voire tous les réseaux de la pluralité, ont de préférence des probabilités non nulles d’être tirés.
Les étapes de calcul de score, de tirage aléatoire, et de sollicitation sont de préférence répétées pour plusieurs segments de données appartenant à un ensemble de données tel qu’un flux multimédia ou un fichier. De préférence, le segment de données appartient à un ensemble de données, et les scores sont initialisés à des valeurs initiales avant que le dispositif n’obtienne un quelconque segment de l’ensemble de données.
Par exemple, la valeur initiale du score d’un réseau de la pluralité est déterminée en fonction d’informations indicative d’une qualité de transmission de segments de données depuis le même réseau à au moins un dispositif tiers différent du dispositif client.
Ces informations sont par exemple fournies au dispositif client par un serveur d’agrégation apte à communiquer avec chaque dispositif tiers.
Si un premier réseau de la pluralité a déjà été sollicité par le dispositif client pour obtenir au moins un segment de données appartenant à l’ensemble de données depuis l’initialisation, le score de ce premier réseau est de préférence mis à jour en tenant compte de la qualité de transmission effective d’au moins un segment transmis par le premier réseau au dispositif client.
Si par ailleurs un deuxième réseau de la pluralité n’a pas encore été sollicité par le dispositif client pour obtenir de segment de données appartenant à l’ensemble de données depuis l’initialisation, le score de ce deuxième réseau est de préférence mis à jour en tenant compte de la valeur du score du premier réseau.
Le procédé peut comprendre le calcul d’une heuristique de bande passante indicative d’une bande passante disponible pour la transmission de segments de données par un réseau de la pluralité au dispositif client, le score associé à ce réseau dépendant de l’heuristique de bande passante calculée.
A titre alternatif ou complémentaire, le procédé peut comprendre le calcul d’une heuristique d’erreurs de transmission associée à un réseau de la pluralité, l’heuristique d’erreurs de transmission étant indicative d’erreurs de transmission de segments de données ayant préalablement été demandés par le dispositif client au réseau, le score associé à ce réseau dépendant de l’heuristique d’erreurs de transmission calculée.
De préférence, l’heuristique d’erreurs de transmission associée à un réseau de la pluralité varie de manière à rendre moins probable le tirage aléatoire du réseau, lorsque le réseau échoue à transmettre un segment de données au dispositif client.
De préférence, l’heuristique d’erreurs de transmission associée à un réseau de la pluralité varie d’une quantité qui elle-même croît avec un nombre d’erreurs de transmission de segments passées associé à ce réseau. De préférence, l’heuristique d’erreurs de transmission associée à un réseau varie de manière à rendre plus probable le tirage aléatoire du réseau, lorsque le réseau réussit à transmettre un segment de données au dispositif client.
De préférence, l’heuristique d’erreurs de transmission d’un réseau varie de manière à rendre plus probable le tirage aléatoire du réseau, lorsqu’aucun segment de données n’est transmis depuis le réseau au dispositif client dans une période de temps prédéterminée.
Le score associé à un réseau peut en outre dépendre d’un poids prédéfini propre à ce réseau, ce poids étant par exemple une constante.
Il est également proposé, selon un deuxième aspect de l’invention, un procédé de lecture par un dispositif client d’un flux multimédia comprenant une pluralité de segments de données, le procédé comprenant l’obtention d’au moins un des segments de données au moyen du procédé selon le premier aspect de l’invention.
Il est également proposé, selon un troisième aspect de l’invention, un produit programme d'ordinateur comprenant des instructions de code de programme pour l'exécution des étapes du procédé selon le premier aspect ou le deuxième aspect de l’invention, lorsque ce programme est exécuté par un dispositif client.
Il est également proposé, selon un quatrième aspect de l’invention, un support lisible par un dispositif client sur lequel est stocké un programme d'ordinateur comprenant des instructions de code de programme pour l'exécution des étapes du procédé selon le premier aspect ou selon le deuxième aspect de l’invention.
Il est également proposé, selon un cinquième aspect de l’invention, un dispositif client destiné à obtenir un segment de données, le dispositif client comprenant une interface de communication pour communiquer avec une pluralité de réseaux de diffusion de contenu, et une unité de traitement configurée pour commander la mise en œuvre des étapes du procédé selon le premier aspect ou selon le deuxième aspect de l’invention.
DESCRIPTION DES FIGURES
D’autres caractéristiques, buts et avantages de l’invention ressortiront de la description qui suit, qui est purement illustrative et non limitative, et qui doit être lue en regard des dessins annexés sur lesquels :
La figure 1 représente de manière schématique un dispositif client selon un mode de réalisation de l’invention et plusieurs réseaux de diffusion de contenu. La figure 2 est un organigramme d’étapes d’un procédé d’obtention d’un segment de données selon un mode de réalisation de l’invention.
Sur l’ensemble des figures, les éléments similaires portent des références identiques.
DESCRIPTION DETAILLEE DE L'INVENTION
On a représenté en figure 1 un dispositif client 1 apte à communiquer avec une pluralité de réseaux de diffusion de contenu (CDNs). Seuls deux CDNs référencés CDN1 et CDN2 sont représentés sur cette figure, mais on considéra plus généralement dans la suite un ensemble de N CDNs indicés de 1 à N.
Comme indiqué schématiquement sur la figure 1 , chaque CDN comprend au moins un serveur, étant entendu que ces CDNs peuvent comprendre plus qu’un seul serveur, comme évoqué en introduction.
Chaque CDN stocke des segments de données appartenant à un même ensemble de données. Par exemple, tous les CDNs comprennent l’ensemble de données complet, c’est-à-dire tous les segments de cet ensemble de données.
L’ensemble de données peut être un fichier de données, destiné à être référencé dans un système de fichiers en vue d’un accès à ce fichier. Alternativement, l’ensemble de données est un flux multimédia se présentant sous la forme d’un ou plusieurs fichiers.
Les segments de l’ensemble de données considéré sont ordonnés entre eux. Dans le cas d’un ensemble de données de type fichier, les segments correspondent à différentes portions du binaire formant le fichier, chaque portion ayant une adresse relative (offset) qui lui est propre par rapport à l’adresse de début du fichier.
Les segments d’un flux multimédia sont temporellement ordonnés : chaque segment est associé à ou comprend un horodatage qui lui est propre. Les différents horodatages permettent de déterminer dans quel ordre les différents segments du flux multimédia doivent être lus par un lecteur.
Dans le cas particulier d'un flux multimédia en direct (« live ») et plus généralement d'un flux DVR, seulement une fenêtre temporelle correspondant aux N dernière minutes, ou M dernières heures, est disponible sur les réseaux de contenus. Dans ce cas on entend par ensemble de données la collection des données multimédia qui forment cette fenêtre temporelle. Lorsqu'un nouveau segment vidéo est généré par un encodeur live, il est rajouté à l'ensemble de données alors que le segment le plus ancien expire et est retiré de l'ensemble de données. Quelle que soit la forme que revêt l’ensemble de données, on considère dans le présent texte qu’un segment de données désigne une portion de l’ensemble de données qui est susceptible d’être transmise au dispositif client 1 indépendamment des autres segments de données du même ensemble de données.
Le dispositif client 1 comprend par ailleurs une interface de communication 2 pour communiquer avec les différents CDNs, et notamment recevoir de ces CDNs des segments de l’ensemble de données.
Le dispositif client 1 comprend par ailleurs une mémoire 4 pour mémoriser des segments reçus via l’interface de communication 2, et une unité de traitement 6 configurée pour traiter les segments de données contenus dans la mémoire 4.
L’unité de traitement 6 comprend par exemple au moins un processeur configuré pour exécuter un programme d’ordinateur comprenant des instructions de code implémentant ce traitement.
Dans le cas où l’ensemble de données est un flux multimédia, l’unité de traitement 6 comprend un lecteur configuré pour lire les segments de données. De façon conventionnelle, un tel lecteur comprend un décodeur configuré pour décoder les segments, et une sortie agencée en sortie du décodeur pour restituer un contenu de segments, telle qu’un écran d’affichage dans le cas d’un segment vidéo, ou un haut-parleur dans le cas d’un segment audio.
Dans le cas où l’ensemble de données est un fichier, l’unité de traitement 6 est configurée pour assembler les différents segments qui forment ce fichier une fois ceux-ci reçus, de sorte à former une copie du fichier référencée dans un système de fichiers du dispositif client 1.
L’unité de traitement 6 est par ailleurs configurée pour sélectionner parmi les différents CDNs un CDN à solliciter pour obtenir un segment de données à traiter. Cette sélection est par exemple implémentée dans le programme d’ordinateur comprenant des instructions de code implémentant le traitement ultérieur de ces segments, ou bien implémenté dans un programme de sélection à part.
Le dispositif client 1 a connaissance des différents CDNs auxquels il peut accéder. Sont par exemple mémorisées dans la mémoire 4 du dispositif client 1 des adresses de ces CDNs.
On a également représenté en figure 1 un serveur d’agrégation 8 avec lequel le dispositif client 1 est à apte à communiquer. Le serveur d’agrégation comprend une mémoire et une unité de traitement configurée pour appliquer des calculs à des données qu’il reçoit du dispositif client 1 ainsi que d’autres dispositifs clients 1 a, 1 b, qui seront désignés dispositifs tiers par contraste avec le dispositif client 1 .
Les dispositifs 1 a et 1 b sont configurés de la même manière que le dispositif 1 .
L’un quelconque des dispositifs 1 , 1 a, 1 b peut se présenter par exemple sous la forme d’un ordinateur de bureau, un téléviseur, un ordinateur portable, une tablette, un smartphone, etc.
Il va maintenant être décrit un procédé de traitement de l’ensemble de données discuté précédemment par le dispositif client 1 .
En référence à la figure 2, les étapes suivantes sont mises en œuvre pour un segment de de l’ensemble de données à traiter.
Pour tout i allant de 1 à N, l’unité de traitement 6 calcul un score x, associé au CDN d’indice i. Le score x, est indicatif d’une qualité de transmission de données depuis le CDN d’indice i au dispositif client 1 (étape 100). Ce calcul 100 sera plus amplement détaillé dans la suite.
Bien que l’inverse puisse être envisagé, il est détaillé dans la suite un mode de réalisation dans lequel la valeur d’un score x, croît avec la qualité de transmission de données de ce CDN au dispositif client 1 . Autrement dit, un score de 10 indique une qualité de transmission de donnée supérieure qu’un score de 5 par exemple.
L’unité de traitement 6 met en œuvre un tirage aléatoire d’un CDN parmi les différents CDNs (étape 102).
Dans la suite, on note P, la probabilité de tirer le CDN d’indice i parmi les N CDNs disponibles via ce tirage aléatoire 102.
Le tirage aléatoire 102 est adapté pour que la probabilité de tirer un CDN associé à un score indicatif d’une qualité de transmission relativement élevée soit supérieure à la probabilité de tirer un CDN associé à un score indicatif d’une qualité de transmission relativement petite.
Ce tirage aléatoire 102 est par ailleurs tel que qu’au moins deux des N CDNs, voire tous les CDNs, ont des probabilités non nulles d’être tirés.
Dans le cas où la valeur d’un score x, croît avec la qualité de transmission de données de ce CDN au dispositif client 1 , la propriété ci-dessus du tirage aléatoire se traduit de la manière suivante :
Figure imgf000009_0001
En pratique, l’étape 102 de tirage aléatoire peut comprendre les sous-étapes suivantes.
• L’unité de traitement 6 calcule les probabilités de tirage Pj associées aux scores Xj.
• L’unité de traitement 6 met ensuite en œuvre un tirage aléatoire uniforme d’un nombre dans un intervalle dont la longueur est égale à la somme des probabilités Pj . Cet intervalle est l’union de N sous-intervalles distincts respectivement associés aux différents CDNs. Pour tout j allant de 1 à N, le sous-intervalle associé au CDN d’indice j est de longueur égale à la probabilité Pj .
• Le CDN tiré aléatoirement au cours de l’étape 102 est le CDN associé au sous- intervalle incluant le nombre tiré.
Le tirage aléatoire 102 dépend de préférence d’un paramètre C, dit paramètre d’exploration. Le tirage aléatoire est adapté pour faire croître la probabilité de tirer le réseau associé au score le plus élevé parmi tous les scores calculés relativement aux probabilités de tirer les autres réseaux de la pluralité, lorsque la valeur du paramètre d’exploration varie dans un premier sens, et/ou faire décroître la probabilité de tirer le réseau associé au score le plus élevé parmi tous les scores calculés relativement aux probabilités de tirer les autres réseaux de la pluralité, lorsque la valeur du paramètre d’exploration varie dans un deuxième sens opposé au premier sens.
Par exemple, la probabilité Pj de tirer un CDN d’indice j parmi les N CDNs disponibles est de la forme suivante :
Figure imgf000010_0001
Recourir au paramètre C est avantageux car permet d’ajuster le caractère plus ou moins exploratoire du tirage aléatoire (d’où son nom de paramètre « d’exploration ») . Lorsque la formule ci-dessus est utilisée, si la valeur du paramètre C est élevée, le tirage aléatoire 102 aura tendance à privilégier un tirage du CDN considéré être de qualité maximale au détriment des autres CDNs. Avec un C de valeur moindre, un tel avantage aura moins de poids, si bien que des CDNs suboptimaux en termes de qualité de transmission auront davantage de chance d’être tirés au cours de l’étape 102.
Le paramètre d’exploration C peut être fixe, mais peut également être ajusté dynamiquement (le cas d’un tel ajustement dynamique est détaillé plus loin) .
Le réseau ayant été tiré aléatoirement est ensuite sollicité par le dispositif client 1 pour que le dispositif client 1 obtienne un segment de l’ensemble de données (étape 104). Cette sollicitation 104 comprend par exemple l’émission par le dispositif client 1 via l’interface de communication 2 d’une requête de segment à destination du CDN tiré, et la transmission par le CDN tiré du segment visé par la requête, en réponse à celle-ci.
Une sollicitation 104 du CDN tiré par le dispositif client peut se solder par un succès ou par un échec. En effet, des erreurs peuvent survenir au cours de cette sollicitation : la requête peut ne pas parvenir au CDN tiré ; le CDN tiré peut ne pas émettre du tout le segment demandé en raison d’un bug interne ; enfin, le CDN tiré peut émettre le segment demandé par le dispositif client 1 mais ce segment peut ne pas être transmis correctement jusqu’au dispositif client 1.
Si le segment n’est pas reçu par le dispositif client 1 , alors le dispositif client 1 peut répéter l’étape de sollicitation 104 jusqu’à obtenir le segment de données. Toutefois, il est préférable de ne pas répéter une telle sollicitation immédiatement : on va s’intéresser dans la suite à ce mode de réalisation.
Si le segment est bien reçu par le dispositif client au cours de cette étape de sollicitation 104, le segment est mémorisé dans la mémoire 4 en vue d’être traité par l’unité de traitement 6. Par exemple, dans le cas où le segment de données venant d’être reçu fait partie d’un flux multimédia à lire, l’unité de traitement 6 peut commander la lecture du segment de données par un lecteur (le traitement du segment est une lecture).
Dans le cas où le segment de données fait partie d’un fichier à référencer dans un système de fichiers, l’unité de traitement 6 vérifie si tous les segments qui forment le fichier sont été reçus. Si oui, l’unité de traitement 6 assemble tous les segments de sorte à reconstruire une copie du fichier et la référence dans un système de fichiers. Sinon, l’unité se met en attente d’autres segments de données du fichier.
Par ailleurs, l’unité de traitement 6 évalue la qualité effective de la transmission du segment qui a été reçu du CDN préalablement tiré aléatoirement (étape 106).
Cette évaluation peut comprendre le calcul d’une heuristique de bande passante indicative d’une bande passante disponible pour la transmission de données depuis le CDN tiré au dispositif client 1.
Typiquement, l’heuristique de bande passage dépend d’une bande passante instantanée mise à disposition du dispositif client 1 pour obtenir le segment du CDN tiré au cours de l’étape 104. Cette bande passante instantanée se calcule typiquement sous la forme d’un rapport entre la durée prise pour obtenir le segment et la taille de ce segment. On a vu précédemment que la sollicitation 104 du CDN tiré peut se solder par un succès (un segment de données est obtenu par le dispositif client 1 ) ou par un échec (le dispositif client 1 ne reçoit pas le segment de données). Aussi, l’évaluation de la qualité effective de la transmission du segment peut comprendre le calcul d’une l’heuristique d’erreurs de transmission, cette heuristique de transmission étant indicative d’erreurs de transmission de segments de données ayant préalablement été demandés par le dispositif client au réseau (notamment le segment que le dispositif client a demandé auprès du CDN tiré, au cours de l’étape de sollicitation 104).
De telles erreurs de transmission peuvent en pratique être mesurées par le dispositif client 1 au niveau d’une couche session (typiquement HTTP) ou au niveau d’une couche de niveau supérieur dans le modèle OSI, telle qu’une couche applicative.
Ces erreurs peuvent être de natures diverses : erreur 404 (ou 40X ou 50X), erreur de timeout (le segment n'a pas été obtenu dans le temps imparti donné par un module de téléchargement http du dispositif client 1 ), déconnexion réseau temporaire du dispositif client 1 , erreur sur le handshake HTTPS, erreur en rapport aux sécurités des navigateurs (CORS, mixed content HTTP/HTTPS), etc.
Chaque heuristique calculée est mémorisée dans la mémoire 4 du dispositif client 1 .
Par ailleurs, si les probabilités de tirages discutées précédemment dépendent du paramètre d’exploration C, l’unité de traitement 6 peut évaluer un risque de dégradation de conditions de traitement par le dispositif client 1 de l’ensemble de données comprenant le segment de données, et modifier la valeur du paramètre d’exploration C d’après le risque de dégradation évalué (étape 108).
Ces conditions de traitement sont par exemple des conditions de lecture du segment de données par le dispositif client 1 lorsque cet ensemble est un flux multimédia à jouer,
Concrètement, l’évaluation du risque de dégradation des conditions de lecture du flux multimédia à jouer mise en œuvre au cours de l’étape 108 peut prendre en considération l’évolution du taux de remplissage d’un tampon en amont du lecteur du dispositif client 1 . En effet, un tel taux de remplissage peut indiquer si la lecture du flux risque ou non de s’interrompre si le CDN tiré au cours de l’étape 102 n’est pas de qualité optimale et que le téléchargement d’un segment auprès de ce CDN tiré prend plus de temps que prévu (cette interruption survenant typiquement lorsque le lecteur a besoin de traiter un nouveau segment, mais que le tampon est vide). Si, par exemple, il a été détecté qu’il existe un risque de dégradation élevé de ces conditions de traitement, il peut être préférable par mesure de sécurité de rendre le tirage moins exploratoire en faisant varier la valeur de C. En l’absence de risque ou lors d’un risque de dégradation plus faible, on peut s’autoriser à solliciter d’autres CDNs que celui considéré de meilleure qualité ; autrement dit, la valeur de C peut être dans ce cas modifiée pour rendre le tirage davantage exploratoire.
Une autre façon d’évaluer le risque de dégradation des conditions de traitement de l’ensemble de données est de consulter les résultats obtenus au cours de l’étape 106. Typiquement, si la transmission du segment que le dispositif a demandé au CDN tiré au cours de l’étape 104 a échoué, le risque augmente.
Les étapes 100, 102, 104, 106, 108 représentées sur la figure 2 forment une itération du procédé. Plusieurs itérations du procédé sont mises en œuvre au cours du temps, chaque itération visant à obtenir et traiter un nouveau segment de l’ensemble de données. Par exemple, une nouvelle itération est mise en œuvre pour chaque nouveau segment que le dispositif client 1 doit obtenir et traiter.
Au vu du caractère probabiliste de la sélection d’un CDN pour obtenir un segment de l’ensemble de données, il est quasi certain que plusieurs CDNs seront sollicités par le dispositif client 1 avant ou au cours du traitement de l’ensemble de données, surtout si le nombre de segment de cet ensemble est important.
En particulier, lorsque le dispositif client 1 n’obtient pas un segment de données d’un CDN tiré au cours d’une mise en œuvre de l’étape de sollicitation 104 d’une itération, un nouveau tirage aléatoire est mis en œuvre au cours de l’étape 102 d’une itération suivante. Un autre CDN que celui ayant échoué à fournir le segment a des chances d’être tiré et sera ensuite sollicité par le dispositif client 1 pour fournir le même segment.
Par ailleurs, la répétition de l’étape 100 implique que plusieurs calculs de score sont effectués au cours du temps pour un CDN donné. De préférence, est allouée en mémoire une seule variable de score pour un CDN donnée. Lors d’une nouvelle mise en œuvre de l’étape 100, chaque score est mis à jour. Ainsi, le score de chaque CDN évolue au cours du temps. Un CDN peut voir son score de qualité diminuer ou augmenter, ce qui a bien évidemment une influence sur le tirage aléatoire ultérieur.
Le dispositif client 1 peut envoyer au serveur d’agrégation 8 des informations indicatives d’une qualité de transmission de segments de données vers ce dispositif client 1 , depuis l’un ou l’autre des CDNs (étape 110). Ces informations peuvent comprendre au moins une des données suivantes associées à un CDN donné : • le scores calculé pour ce CDN au cours d’une mise en œuvre de l’étape 100,
• une heuristiques calculée pour ce CDN au cours d’une mise en œuvre de l’étape 106 (heuristique de bande passante et/ou d’erreurs de transmissions), ces informations étant plus granulaires que le score,
• le nombre et/ou la taille de segments de l’ensemble de données qui ont été téléchargés avec succès par le dispositif client 1 depuis le CDN, le nombre et/ou la d’erreurs de téléchargement de segments qu’a rencontrées le dispositif client 1 en sollicitant le CDN, ces informations étant encore plus granulaires que les heuristiques
• des informations permettant d’identifier les ensembles de données auxquels les segments téléchargés appartiennent.
Il n’est toutefois pas nécessaire que le dispositif client 1 mette en œuvre cette étape d’envoi d’informations 110 au serveur d’agrégation à chaque itération. Il peut être également prévu de déclencher l’étape 110 de manière asynchrone par rapport aux autres étapes représentées en figure 2. En pratique, on prévoir d’agréger les informations les plus granulaire côté client et les envoie au serveur d’agrégation 8 périodiquement.
Le procédé se termine une fois que tous les segments de l’ensemble de données ont été reçus par le dispositif client 1 et traités par ce dernier.
Il va à présent être détaillé comment les scores associés aux différents CDNs sont calculés au cours du procédé dans différents situations. Ces situations dépendent de l’itération considérée et de la question de savoir si ces CDNS ont déjà été sollicités par le dispositif client 1 .
Initialisation des scores
Lors de l’étape de calcul 100 de la toute première itération du procédé, les scores des différents CDNs sont initialisés à des valeurs initiales.
Ces valeurs initiales sont par exemple égales, auquel cas les CDNs auront tous les mêmes chances d’être tirés lors que du tirage aléatoire 102 mis en œuvre au cours de la première itération.
En variante, ces valeurs initiales sont différentes et proportionnelles à des poids respectifs associés à ces différents CDN.
Les valeurs initiales peuvent être déterminées de manière autonome par le dispositif client 1 . Elles sont par exemple mémorisées à l’avance dans la mémoire 4. Toutefois, dans un mode de réalisation particulièrement avantageux, le serveur d’agrégation 8 fournit au dispositif client 1 des informations qui permettent de définir les valeurs initiales des scores associés au différents CDNs.
Dans ce mode de réalisation, les valeurs initiales que fournit le serveur d’agrégation 8 au dispositif client 1 sont fonction d’informations ayant été préalablement remonté par au moins un dispositif tiers ayant mis en œuvre le même procédé que le dispositif client 1 (on a en effet vu précédemment que le dispositif client 1 envoie lui-même toute ou partie des scores qu’il calcule au serveur d’agrégation 8 au cours de l’étape 110).
Il pourrait être envisagé que le serveur d’agrégation 8 fournisse directement la valeur initiale du score d’un CDN d’indice i au dispositif client 1 . Dans ce cas, le serveur d’agrégation 8 agrège les informations qu’il reçoit d’au moins un dispositif tiers tel que 1 a ou 1 b, et qui concerne le CDN d’indice i.
Il est toutefois préférable que le serveur d’agrégation 8 fournisse au dispositif client des informations plus granulaires que des scores, par exemples les heuristiques discutées précédemment. Dans ce cas, les heuristiques gérées par le dispositif 1 sont elles même initialisées aux valeurs reçues du serveur d’agrégation 8. Ces valeurs initiales d’ heuristiques permettent ensuite de calculer les valeurs initiales des scores au cours de la première mise en œuvre de l’étape de calcul 100. En d’autres termes, dans ce mode de réalisation, l’étape de calcul 100 est mise en œuvre de la même manière dans la première itération et dans les itérations subséquentes.
Par ailleurs, il est préférable d’appliquer certains filtres avantageux sur les informations fournies par le serveur d’agrégation 8 au dispositif client 1 . Ainsi, les informations agrégées peuvent ne comprendre que les informations suivantes :
• les informations se rapportant à une fenêtre glissante de durée prédéterminée, afin de ne considérer que des mesures récentes,
• les informations remontées seulement par des dispositifs tiers sélectionnés d’après un critère de proximité réseau avec le dispositif client 1 (même FAI, même pays, voire même vîlle, ou même même ASN).
• Les informations concernant le même diffuseur : en effet, les utilisateurs de TF1 et M6 n'obtiennent pas nécessairement les mêmes performances pour un même CDN. En effet chaque CDN a plusieurs sous-réseaux de serveurs plus ou moins performant.
• Les informations concernent le même ensemble de données que celui que doit traiter le dispositif 1 : En effet un contenu populaire va être caché sur beaucoup de serveurs du CDN, alors qu'un contenu peu populaire peut ne pas être caché du tout. Ceci peut avoir un impact conséquent sur les performances d’un CDN.
Solliciter le serveur d’agrégation 8 permet d’initialiser les scores à des valeurs initiales plus pertinentes. En conséquence, le procédé sera plus efficace pour obtenir et traiter les premiers segments de l’ensemble de données considéré.
Une fois la première itération terminée, tous les scores ont bien une valeur (une valeur initiale), et l’un des CDNs a été tiré sur la base de sa valeur initiale, puis sollicité pour que le dispositif obtienne un premier segment de l’ensemble de données. Toutefois, tous les autres CDNs (au nombre de N-1 ) n’ont pas encore été sollicités par le dispositif client 1 pour l’obtention d’un segment de l’ensemble de données.
Mise à jour du score d’un CDN ayant déjà été sollicité
Supposons à présent que le CDN d’indice i a été sollicité par le dispositif client 1 au cours d’au moins une itération antérieure. Dans la suite, le terme « sollicité » se réfère implicitement à l’étape de sollicitation 104 et à l’ensemble de données discuté jusqu’ici. Autrement dit, un CDN « sollicité » a donc été tiré aléatoirement au moins une fois au cours d’une mise en œuvre de l’étape 102 et a fourni au moins un segment de l’ensemble de données considéré au dispositif client 1 . L’étape d’évaluation 106 a donc été mise en œuvre au moins une fois pour ce CDN d’indice i, pour au moins un segment transmis antérieurement par le CDN d’indice i et reçu par le dispositif client 1 .
Un nouveau segment de l’ensemble de données, dit segment de référence, doit à présent être obtenu par le dispositif client 1 en vue de le traiter dans une nouvelle itération, dite itération courante.
Comme l’itération courante n’est pas la première itération, une valeur a déjà été déterminée pour le score x, au cours de l’étape de calcul 100 d’une itération précédant l’itération courante.
Lors de l’étape 100 de l’itération courante, l’unité de traitement 6 met à jour le score x, en fonction d’au moins une heuristique (heuristique de bande passante et/ou heuristique d’erreurs) associée au CDN d’indice i et antérieurement calculée. De cette manière, le nouveau score x, tient compte des conditions dans lesquelles le dispositif client 1 a déjà reçu des segments du CDN d’indice i.
Mise à jour du score d’un CDN non encore sollicité Une question qui se pose de savoir comment mettre à jour, lors de l’étape 100 d’une itération courante, le score d’un CDN n’ayant pas encore été sollicité. En effet, ce CDN n’a pas encore transmis de segment de l’ensemble de données au dispositif client.
Une possibilité est de tout simplement ne pas mettre à jour le score d’un CDN non encore sollicité. Dans un tel mode de réalisation, la valeur du score d’un CDN reste à sa valeur initiale jusqu’à ce que ce CDN soit sollicité.
Toutefois, ceci présente l’inconvénient de créer des écarts potentiellement grands entre les scores des CDNs déjà sollicités et les scores des CDNs non encore sollicités par le dispositif client 1. De tels écarts sont susceptibles de pénaliser de manière injuste les CDNs non encore sollicités lors d’un tirage aléatoire 104.
L’apparition de tels écarts peut survenir lorsque le dispositif client 1 reçoit des valeurs initiales d’heuristiques qui dépendent d’heuristiques calculées par des dispositifs tiers bénéficiant d’une qualité de communication avec des CDNs très différente de celle vue par le dispositif client 1. Supposons par exemple que le dispositif client 1 bénéficie d’une bonne connexion aux CDNs (par fibre optique par exemple) tandis que les dispositifs tiers 1a, 1 b bénéficie d’une connexion moins performantes à ces CDNs (ADSL par exemple). Si le dispositif client 1 initialise ses propres heuristiques à des valeurs dépendant de valeurs d’heuristiques remontées par les dispositifs tiers 1a ou 1 b, ces valeurs initiales d’heuristiques (et par conséquent les valeurs initiales de scores calculées sur leur base par le dispositif client 1 ) refléteront mal les conditions réelles de communication entre les CDNs et le dispositif client 1. C’est pourquoi une mise à jour d’une heuristiques associée à un CDN par le dispositif client pourra faire apparaître un écart important entre la valeur d’heuristique résultant de cette mise à jour et les heuristiques d’autres CDNS restées à leur valeur initiale.
Pour éviter cet effet de bord, il est préférable, lors de l’étape de calcul de score 100 d’une itération courante différente de la première itération, de mettre à jour le score d’un CDN non encore sollicité en fonction du score mis à jour pour au moins un CDN ayant déjà été tiré lors d’une itération antérieure.
Par exemple, supposons qu’un CDN d’indice i a été tiré lors de l’itération précédant l’itération courante. Lors de l’itération courante, le score du CDN d’indice i est mis à jour par l’unité de traitement 6 à l’aide d’heuristiques préalablement évaluées, comme indiqué précédemment. Cette mise à jour fait varier la valeur du score du CDN d’indice i d’un certain facteur (égal au rapport entre le score après mis à jour et le score avant mis à jour).
L’unité de traitement 6 calcule un facteur de mise à jour d’un CDN d’indice j non encore sollicité, à partir du facteur de mise à jour du CDN d’indice i. Par exemple, le facteur de mise à jour calculé pour le CDN d’indice j, non encore sollicité, est proportionnel au facteur de mise à jour du CDN d’indice i déjà sollicité. En variante, le facteur de mise à jour calculé pour le CDN d’indice j, non encore sollicité, est proportionnel à une moyenne des facteurs de mise à jour respectifs de plusieurs CDNs ayant déjà été sollicités, par exemple tous les CDNs ayant déjà été sollicités pour obtenir des segments de l’ensemble de données.
Ensuite, l’unité de traitement 6 met à jour le score du CDN d’indice j en multipliant sa valeur courante par le facteur de mise à jour qui vient d’être calculé pour le CDN d’indice j.
Bien qu’intéressant pour éviter des écarts de scores importants injustifiés, il est préférable de limiter dans le temps ce mécanisme d’alignement de scores de CDNs non encore sollicités sur des scores de CDNs déjà sollicités. Pour cela, il est avantageux de faire varier le facteur de mise à jour calculé pour un CDN non encore sollicité avec l’indice de l’itération courante et/ou du nombre total de segments déjà obtenus par le dispositif client 1 , de sorte à rapprocher le facteur de mise à jour de 1. Ainsi, l’effet d’alignement suscité par le facteur de mise à jour d’un CDN non encore sollicité décroît dans le temps.
Mise à jour des heuristiques
Les étapes de tirage aléatoire 102 et de sollicitation 104 décrites précédemment en relation avec la figure 2 sont mises en œuvre au cours d’une itération courante quelconque.
Par ailleurs, lors de l’étape d’évaluation 106 d’une itération courante différente de la première itération, l’unité met à jour les heuristiques existantes associées au CDN ayant été tiré au cours de l’étape de tirage aléatoire de l’itération courante, de sorte que ces heuristiques tiennent compte des conditions dans lequel le segment de référence a été reçu au cours de l’étape de sollicitation 104 de l’itération courante du CDN tiré.
Ainsi, l’heuristique de bande passante mise à jour au cours de l’itération courante tient compte de la bande passante instantanée qui a été utilisée au cours de la réception du segment de référence, mais également de la bande passage instantanée qui a été utilisée au cours de chaque autre segment de l’ensemble de données, transmis antérieurement par le CDN d’indice i au cours d’itérations antérieures.
De préférence, l’heuristique de bande passante est calculée comme une moyenne glissante, par exemple exponentielle (exponential weighted moving average ou EWMA en anglais). De cette manière, il est fait en sorte que l’heuristique de bande passante accorde davantage de poids à un segment reçu récemment qu’à un segment reçu auparavant.
Par ailleurs, l’heuristique d’erreurs de transmission est mise au cours de l’itération courante de sorte à évoluer selon certaines règles avantageuses. Si le CDN tiré au cours de l’itération courante a échoué à transmettre le segment de référence au dispositif client 1 au cours de l’étape de sollicitation 104 de l’itération courante, l’heuristique d’erreurs associée au CDN tiré est mise à jour de manière à rendre moins probable le tirage aléatoire de ce CDN au cours d’une itération suivante du procédé. Par exemple, l’heuristique d’erreurs est mise à jour dans ce cas de manière à diminuer la valeur du score de ce CDN lors d’une mise en œuvre suivante de l’étape 100.
A l’inverse, si le CDN tiré au cours de l’itération courante a réussi à transmettre le segment de référence au dispositif client 1 au cours de l’étape de sollicitation 104 de l’itération courante, l’heuristique d’erreurs associée au CDN tiré est mise à jour de manière à rendre plus probable le tirage aléatoire de ce CDN au cours d’une itération suivante du procédé. Par exemple, l’heuristique d’erreurs est mise à jour dans ce cas de manière à augmenter la valeur du score de ce CDN lors d’une mise en œuvre suivante de l’étape 100.
Par ailleurs, l’heuristique d’erreurs du réseau tiré au cours de l’itération courante varie d’une quantité qui elle-même croit avec un nombre d’erreurs de transmission de segments passées associé à ce réseau. Ce mécanisme sanctionne ainsi de plus en plus fortement un CDN accumulant des erreurs de transmission de segments.
L’heuristique d’erreurs associé aux autres CDNs (c’est-à-dire ceux n’ayant pas été tirés au cours de l’itération courante) peut également être mise à jour, selon les modalités suivantes.
L’unité de traitement 6 détermine quand le CDN non tiré au cours de l’itération courante a été sollicité pour la dernière fois. Pour déterminer cela, l’unité peut compter le temps, ou bien compter un nombre de segments ou d’itérations du procédé.
Si l’unité de traitement 6 s’aperçoit qu’un CDN d’indice i non tiré au cours de l’itération courante n’a pas été tiré dans une période de temps donnée (par exemple, les K derniers segments reçus proviennent d’autres CDNs que le CDN d’indice i, ou bien aucun segment n’a été reçu du CDN d’indice i depuis X secondes), l’heuristique d’erreurs de ce CDN d’indice i est mise à jour de manière à rendre plus probable le tirage aléatoire du réseau d’indice i au cours d’une itération suivante du procédé. Ce mécanisme revient finalement à instaurer un principe de prescription : on accepte qu’un CDN n’ayant pas été sanctionné durant une période suffisamment longue ait davantage de chances d’être sollicité à l’avenir, et ce même si ce CDN avait été sanctionné avant cette période.
Tous les principes évoqués ci-dessus peuvent être implémentés de manières très diverses. A titre d’exemple, l’encart ci-dessous illustre le pseudo-code d’un mode de réalisation possible des étapes de calcul des scores, des probabilités et des heuristiques susmentionnées.
Figure imgf000020_0001
Voici quelques explications sur ce pseudocode d’exemple, qui comprend une boucle qui itère sur chaque CDN :
• La branche on error est exécutée lors d’une erreur de transmission de segment par le CDN au dispositif client 1.
• La branche on success est exécutée lorsque le dispositif 1 reçoit avec succès un segment du CDN.
• La variable measured bandwidth est la bande passante instantanée mesurée pour le dernier segment reçu par le dispositif client 1 du CDN considéré.
• L’heuristique de bande passante associée à un CDN est ici la variable bandwidth.
Comme on peut le constater, le score calculé pour un CDN dépend de cette variable. Cette heuristique de bande passante est revue à la hausse si measured_bandwidth > bandwidth ; sinon, elle est revue à la baisse. • L’heuristique d’erreurs associé à un CDN correspond ici au terme HANDICAP BASE élevé à la puissance hpw. La valeur hpw est augmentée lorsque le dispositif client 1 détecte une erreur de transmission de segment en provenance du CDN considéré, et cette augmentation est elle-même croissante avec le terme error rate (voir le terme ERROR_PERCENTAGE_BASE élevée à la puissance error_rate en cas de passage dans la branche on error).
• La branche on tick correspond au principe de prescription mentionné précédemment : elle est exécutée à l’expiration d’un compteur. En pratique cette branche est exécutée périodiquement pour chaque CDN. A chaque passage, la valeur hpw associée à un CDN donnée est réduite, par exemple de 1 % à chaque seconde si GAAAAAA vaut 0.01 .
• Le poids prédéfini pour un CDN donnée est la donnée weight.
• La variable probability ne correspond pas directement à une probabilité Pi discutée précédemment (de valeur comprise entre 0 et 1 ). Pour obtenir cette probabilité, peut par exemple diviser cette valeur par la somme des variables probability de tous les CDNs.
Pour prendre un exemple concret, si par exemple juste avant une erreur, hpw vaut 0, et error rate vaut 0.01 , le paramètre (constant) BETA vaut 0.1 , et HANDICAP BASE et ERROR PERCENTAGE BASE valent 10. A l’itération suivante, hpw sera mis à jour et vaudra 10 L 1 = 10 (par ailleurs error rate vaudra (1 -0.1 )*0.01 + 0.1 = 0.109 après avoir été mis à jour). On obtient le score final avec la formule score = weight * bandwidth / HANDICAP_BASE L hpw. Donc dans cet exemple le dénominateur vaudra 10L 10.

Claims

REVENDICATIONS
1 . Procédé d’obtention d’un segment de données par un dispositif client apte à communiquer avec une pluralité de réseaux de diffusion de contenu (CDN1 , CDN2), le procédé comprenant des étapes de :
- pour chaque réseau de la pluralité de réseaux, calcul (100) d’un score associé au réseau indicatif d’une qualité de transmission de données depuis le réseau au dispositif client,
- tirage aléatoire (102) d’un réseau dans la pluralité de réseaux, le tirage aléatoire étant adapté pour qu’une probabilité de tirer un réseau de la pluralité associé à un score indicatif d’une première qualité de transmission soit supérieure à une probabilité de tirer un réseau de la pluralité associé à un score indicatif d’une deuxième qualité de transmission inférieure à la première qualité de transmission,
- sollicitation (104) du réseau tiré pour que le dispositif client obtienne le segment de données du réseau tiré.
2. Procédé selon la revendication précédente, dans lequel le tirage aléatoire (102) dépend d’un paramètre, le tirage aléatoire étant adapté pour :
- faire croître la probabilité de tirer le réseau associé au score le plus élevé parmi tous les scores calculés relativement aux probabilités de tirer les autres réseaux de la pluralité, lorsque la valeur du paramètre varie dans un premier sens, et/ou
- faire décroître la probabilité de tirer le réseau associé au score le plus élevé parmi tous les scores calculés relativement aux probabilités de tirer les autres réseaux de la pluralité, lorsque la valeur du paramètre varie dans un deuxième sens opposé au premier sens.
3. Procédé selon la revendication précédente, comprend en outre des étapes de
- évaluation d’un risque de dégradation de conditions de traitement par le dispositif client d’un ensemble de données comprenant le segment de données, telles que des conditions de conditions de lecture par le dispositif client d’un flux multimédia comprenant le segment de données,
- modification de la valeur du paramètre d’après le risque de dégradation évalué.
4. Procédé selon l’une des revendications précédentes, dans lequel au moins deux réseaux de la pluralité, voire tous les réseaux de la pluralité, ont des probabilités non nulles d’être tirés.
5. Procédé selon l’une des revendications précédentes, dans lequel les étapes de calcul de score, de tirage aléatoire, et de sollicitation sont répétées pour plusieurs segments de données appartenant à un ensemble de données tel qu’un flux multimédia ou un fichier.
6. Procédé selon l’une des revendications précédentes, dans lequel le segment de données appartient à un ensemble de données, et dans lequel les scores sont initialisés à des valeurs initiales avant que le dispositif n’obtienne un quelconque segment de l’ensemble de données, la valeur initiale du score d’un réseau de la pluralité étant par exemple déterminée en fonction d’informations indicatives d’une qualité de transmission de segments de données depuis le même réseau à au moins un dispositif tiers (1a, 1 b) différent du dispositif client, les informations étant par exemple fournies au dispositif client par un serveur d’agrégation apte à communiquer avec chaque dispositif tiers (1 a, 1 b).
7. Procédé selon la revendication précédente, dans lequel si un premier réseau de la pluralité a déjà été sollicité par le dispositif client pour obtenir au moins un segment de données appartenant à l’ensemble de données depuis l’initialisation, le score de ce premier réseau est mis à jour en tenant compte de la qualité de transmission effective d’au moins un segment transmis par le premier réseau au dispositif client.
8. Procédé selon la revendication précédente, dans lequel si par ailleurs un deuxième réseau de la pluralité n’a pas encore été sollicité par le dispositif client pour obtenir de segment de données appartenant à l’ensemble de données depuis l’initialisation, le score de ce deuxième réseau est mis à jour en tenant compte de la valeur du score du premier réseau.
9. Procédé selon l’une des revendications précédentes, comprenant le calcul d’une heuristique de bande passante indicative d’une bande passante disponible pour la transmission de segments de données par un réseau de la pluralité au dispositif client, le score associé à ce réseau dépendant de l’heuristique de bande passante calculée.
10. Procédé selon l’une des revendications précédentes, comprenant le calcul d’une heuristique d’erreurs de transmission associée à un réseau de la pluralité, l’heuristique d’erreurs de transmission étant indicative d’erreurs de transmission de segments de données ayant préalablement été demandés par le dispositif client au réseau, le score associé à ce réseau dépendant de G heuristique d’erreurs de transmission calculée.
11 . Procédé selon la revendication précédente, dans lequel l’heuristique d’erreurs de transmission associée à un réseau de la pluralité varie de manière à rendre moins probable le tirage aléatoire du réseau, lorsque le réseau échoue à transmettre un segment de données au dispositif client.
12. Procédé selon la revendication précédente, dans lequel l’heuristique d’erreurs de transmission associée à un réseau de la pluralité varie d’une quantité qui elle-même croît avec un nombre d’erreurs de transmission de segments passées associé à ce réseau.
13. Procédé selon l’une des revendications 10 à 12, dans lequel l’heuristique d’erreurs de transmission associée à un réseau varie de manière à rendre plus probable le tirage aléatoire du réseau, lorsque le réseau réussit à transmettre un segment de données au dispositif client.
14. Procédé selon l’une des revendications 10 à 13, dans lequel l’heuristique d’erreurs de transmission d’un réseau varie de manière à rendre plus probable le tirage aléatoire du réseau, lorsqu’aucun segment ée données n’est transmis depuis le réseau au dispositif client dans une période de temps prédéterminée.
15. Procédé selon l’une des revendications précédentes, dans lequel le score associé à un réseau dépend d’un poids prédéfini propre à ce réseau.
16. Procédé de lecture par un dispositif client d’un flux multimédia comprenant une pluralité de segments de données, le procédé comprenant l’obtention d’au moins un des segments de données au moyen du procédé selon l’une des revendications précédentes.
17. Produit programme d'ordinateur comprenant des instructions de code de programme pour commander l'exécution des étapes du procédé selon l’une des revendications précédentes, lorsque ce programme est exécuté par une unité de traitement (6).
18. Support lisible (4) par un dispositif client (1 ) sur lequel est stocké un programme d'ordinateur comprenant des instructions de code de programme pour l'exécution des étapes du procédé selon l’une des revendications 1 à 16.
19. Dispositif client (1 ) comprenant une interface de communication (2) pour communiquer avec une pluralité de réseaux de diffusion de contenu (CDN1 , CDN2), et une unité de traitement (6) configurée pour commander la mise en œuvre des étapes du procédé selon l’une des revendications 1 à 16.
PCT/EP2020/057862 2019-03-22 2020-03-20 Procédé d'obtention d'un segment de données par un dispositif client apte à communiquer avec une pluralité de réseaux de diffusion de contenu WO2020193429A1 (fr)

Priority Applications (6)

Application Number Priority Date Filing Date Title
JP2021555572A JP2022525217A (ja) 2019-03-22 2020-03-20 複数のコンテンツデリバリネットワークと通信可能なクライアント装置によるデータセグメントの取得方法
AU2020249319A AU2020249319A1 (en) 2019-03-22 2020-03-20 Method for obtaining a data segment by means of a client device capable of communicating with a plurality of content delivery networks
EP20712568.3A EP3942778A1 (fr) 2019-03-22 2020-03-20 Procédé d'obtention d'un segment de données par un dispositif client apte à communiquer avec une pluralité de réseaux de diffusion de contenu
CA3133413A CA3133413A1 (fr) 2019-03-22 2020-03-20 Methode pour obtenir un segment de donnees par un dispositif client capable de communiquer avec plusieurs reseaux de distribution de contenu
SG11202110485QA SG11202110485QA (en) 2019-03-22 2020-03-20 Method for obtaining a data segment by a client device capable of communicating with a plurality of content delivery networks
KR1020217034291A KR20210139431A (ko) 2019-03-22 2020-03-20 복수 개의 콘텐츠 전송 네트워크와 통신할 수 있는 클라이언트 디바이스에 의하여 데이터 세그멘트를 획득하기 위한 방법

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FRFR1902989 2019-03-22
FR1902989A FR3094164B1 (fr) 2019-03-22 2019-03-22 Procédé d’obtention d’un segment de données par un dispositif client apte à communiquer avec une pluralité de réseaux de diffusion de contenu

Publications (1)

Publication Number Publication Date
WO2020193429A1 true WO2020193429A1 (fr) 2020-10-01

Family

ID=67107877

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2020/057862 WO2020193429A1 (fr) 2019-03-22 2020-03-20 Procédé d'obtention d'un segment de données par un dispositif client apte à communiquer avec une pluralité de réseaux de diffusion de contenu

Country Status (9)

Country Link
US (2) US11528658B2 (fr)
EP (1) EP3942778A1 (fr)
JP (1) JP2022525217A (fr)
KR (1) KR20210139431A (fr)
AU (1) AU2020249319A1 (fr)
CA (1) CA3133413A1 (fr)
FR (1) FR3094164B1 (fr)
SG (1) SG11202110485QA (fr)
WO (1) WO2020193429A1 (fr)

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FR3094597B1 (fr) * 2019-03-27 2021-06-11 Streamroot Procédé de diffusion de contenus en streaming dans un réseau pair à pair
CN113038190A (zh) * 2021-02-23 2021-06-25 北京达佳互联信息技术有限公司 内容分发网络的调度方法和内容分发网络的调度装置

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20030229682A1 (en) * 2001-05-16 2003-12-11 Day Richard David Meta content delivery network system
WO2010045511A2 (fr) * 2008-10-15 2010-04-22 Gal Zuckerman Procédés et systèmes pour distribuer un contenu

Family Cites Families (39)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6687753B2 (en) * 1998-06-25 2004-02-03 International Business Machines Corporation Method and system for providing three-dimensional graphics over computer networks
US7600014B2 (en) * 2000-11-16 2009-10-06 Symantec Corporation Method and system for monitoring the performance of a distributed application
US20150341812A1 (en) * 2003-08-29 2015-11-26 Ineoquest Technologies, Inc. Video quality monitoring
US20050256677A1 (en) * 2004-05-12 2005-11-17 Hayes Dennis P System and method for measuring the performance of a data processing system
US7930393B1 (en) * 2008-09-29 2011-04-19 Amazon Technologies, Inc. Monitoring domain allocation performance
US7827296B2 (en) * 2008-10-15 2010-11-02 Patentvc Ltd. Maximum bandwidth broadcast-like streams
KR101576704B1 (ko) * 2009-08-19 2015-12-10 오팡가 네트웍스, 인크. 사용자 장비의 결정된 리소스 메트릭에 기초한 미디어 콘텐츠 전달의 최적화
US8825886B2 (en) * 2010-07-28 2014-09-02 Hong Kong Applied Science and Technology Research Institute Company Limited System and method for evaluating network transport effects on delivery of media content
US8903935B2 (en) * 2010-12-17 2014-12-02 Ryan Eric GRANT Remote direct memory access over datagrams
US8842057B2 (en) * 2011-09-27 2014-09-23 Z124 Detail on triggers: transitional states
US9667747B2 (en) * 2012-12-21 2017-05-30 Akamai Technologies, Inc. Scalable content delivery network request handling mechanism with support for dynamically-obtained content policies
CN105264826B (zh) * 2012-12-21 2019-12-20 皇家Kpn公司 用于使能低等待时间流式传输的方法和系统
EP3800893B1 (fr) * 2013-07-11 2023-09-06 Dejero Labs Inc. Systèmes et procédés de transmission de flux de données
US9025486B1 (en) * 2013-10-08 2015-05-05 Netscout Systems, Inc. Determining quality of radio access network transmissions
CA2962040C (fr) * 2014-09-22 2020-07-21 Arris Enterprises Llc Qualite d'experience video basee sur une estimation de qualite video
US9497243B1 (en) * 2014-09-30 2016-11-15 Amazon Technologies, Inc. Content delivery
CN105634836B (zh) * 2014-10-27 2020-03-17 香港理工大学 信息处理方法及装置
US9509742B2 (en) * 2014-10-29 2016-11-29 DLVR, Inc. Configuring manifest files referencing infrastructure service providers for adaptive streaming video
US10256942B2 (en) * 2015-01-26 2019-04-09 Sony Corporation Receiver for receiving data in a broadcast system using redundancy data
US9826016B2 (en) * 2015-02-24 2017-11-21 Koninklijke Kpn N.V. Fair adaptive streaming
US10476926B2 (en) * 2015-06-12 2019-11-12 Telefonaktiebolaget Lm Ericsson (Publ) System and method for managing ABR bitrate delivery responsive to video buffer characteristics of a client
EP3311577B1 (fr) * 2015-06-16 2020-05-27 Intel IP Corporation Un élément réseau aidant à la diffusion vidéo en continu adaptative par protocole de transfert hypertexte (dash) transcodant le contenu média à partir d'un ensemble de messages métriques et d'état reçus du client dash et ledit appareil client dash
CA3010038C (fr) * 2015-12-29 2020-09-22 DISH Technologies L.L.C. Procedes et systemes de distribution adaptative de contenu
US20170255875A1 (en) * 2016-03-03 2017-09-07 Pearson Education, Inc. Validation termination system and methods
US9936434B2 (en) * 2016-06-27 2018-04-03 Ringcentral, Inc. Method and phone system for pre-call quality of service assessment of available networks
US20190238940A1 (en) * 2016-09-08 2019-08-01 Interdigital Ce Patent Holdings Method and apparatus for multimedia content distribution
US10341241B2 (en) * 2016-11-10 2019-07-02 Hughes Network Systems, Llc History-based classification of traffic into QoS class with self-update
KR102622783B1 (ko) * 2016-12-30 2024-01-08 인텔 코포레이션 라디오 통신을 위한 방법 및 디바이스
US10432486B2 (en) * 2017-01-06 2019-10-01 Mz Ip Holdings, Llc System and method for updating application clients using a plurality of content delivery networks
US20180211177A1 (en) * 2017-01-25 2018-07-26 Pearson Education, Inc. System and method of bayes net content graph content recommendation
US20190007286A1 (en) * 2017-06-30 2019-01-03 DeviceRadio AB Module for handling a stream of data over multiple wireless communication channels
US10609119B2 (en) * 2017-11-03 2020-03-31 Salesforce.Com, Inc. Simultaneous optimization of multiple TCP parameters to improve download outcomes for network-based mobile applications
US10628252B2 (en) * 2017-11-17 2020-04-21 Google Llc Real-time anomaly detection and correlation of time-series data
US20190261243A1 (en) * 2018-02-20 2019-08-22 Netgear, Inc. Video-based channel selection in a wireless network-connected camera system
US11138897B2 (en) * 2018-03-30 2021-10-05 Pearson Education, Inc. Systems and methods for automated and direct network positioning
US10630990B1 (en) * 2018-05-01 2020-04-21 Amazon Technologies, Inc. Encoder output responsive to quality metric information
US11882024B2 (en) * 2018-06-18 2024-01-23 Cisco Technology, Inc. Application-aware links
US10750404B2 (en) * 2018-07-09 2020-08-18 Vmware, Inc. Systems and methods for mobile network guidance for over-the-top applications
CN109981765B (zh) * 2019-03-18 2023-03-24 北京百度网讯科技有限公司 用于确定内容分发网络的访问路径的方法和装置

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20030229682A1 (en) * 2001-05-16 2003-12-11 Day Richard David Meta content delivery network system
WO2010045511A2 (fr) * 2008-10-15 2010-04-22 Gal Zuckerman Procédés et systèmes pour distribuer un contenu

Also Published As

Publication number Publication date
SG11202110485QA (en) 2021-10-28
KR20210139431A (ko) 2021-11-22
JP2022525217A (ja) 2022-05-11
AU2020249319A1 (en) 2021-10-28
US11528658B2 (en) 2022-12-13
US20200305070A1 (en) 2020-09-24
CA3133413A1 (fr) 2020-10-01
US20230354173A1 (en) 2023-11-02
FR3094164B1 (fr) 2021-10-29
EP3942778A1 (fr) 2022-01-26
FR3094164A1 (fr) 2020-09-25

Similar Documents

Publication Publication Date Title
WO2020193429A1 (fr) Procédé d'obtention d'un segment de données par un dispositif client apte à communiquer avec une pluralité de réseaux de diffusion de contenu
WO2016162639A1 (fr) Procédé de lecture en continu sur un équipement client d'un contenu diffusé au sein d'un réseau pair à pair
WO2015193597A1 (fr) Gestion par un équipement intermédiaire de la qualité de transmission d'un flux de données vers un terminal mobile
WO2006016055A2 (fr) Procede et serveur de referencement de diffusion poste a poste de fichiers demandes par telechargement a ce serveur
EP3205067B1 (fr) Diffusion de contenus en streaming dans un réseau pair à pair
EP3840335B1 (fr) Réception d'un contenu numérique en mode truque
FR2915044A1 (fr) Procede de determination de la dynamique d'un reseau logique
FR2897961A1 (fr) Procede de gestion de l'execution d'un jeu video pour la diffusion en temps reel de publicites dynamiques
BE1029303B1 (fr) Procédé et système d'affichage digital
WO2022144512A2 (fr) Contrôle de la transmission d'au moins un contenu depuis un equipement fournisseur vers un noeud d'ingestion
EP2575307B1 (fr) Technique de distribution d'un contenu dans un reseau de communication
FR2899410A1 (fr) Procede et dispositif d'emission et de reception de paquets de donnees relatifs a un fichier emis de maniere cyclique en mode multicast
FR3031643A1 (fr) Procede de gestion et de fonctionnement protocolaire d'un reseau de distribution de contenu
WO2013045815A1 (fr) Procede et dispositif de gestion dynamique de la distribution de donnees dans un reseau de telecommunications
FR2871595A1 (fr) Procede et dispositif de traitement de requetes generees par un logiciel de navigation
EP2604019B1 (fr) Procédé pour ralentir, voire éliminer, la propagation illégale d'un contenu vidéo protégé et diffusé en streaming dans un réseau pair à pair
WO2014091131A1 (fr) Sélection multicritères de systèmes de diffusion de contenu
WO2019179855A1 (fr) Procede de diffusion d'un contenu

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 20712568

Country of ref document: EP

Kind code of ref document: A1

ENP Entry into the national phase

Ref document number: 2021555572

Country of ref document: JP

Kind code of ref document: A

Ref document number: 3133413

Country of ref document: CA

NENP Non-entry into the national phase

Ref country code: DE

ENP Entry into the national phase

Ref document number: 20217034291

Country of ref document: KR

Kind code of ref document: A

WWE Wipo information: entry into national phase

Ref document number: 2020712568

Country of ref document: EP

ENP Entry into the national phase

Ref document number: 2020249319

Country of ref document: AU

Date of ref document: 20200320

Kind code of ref document: A