FR3094164A1 - 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
FR3094164A1
FR3094164A1 FR1902989A FR1902989A FR3094164A1 FR 3094164 A1 FR3094164 A1 FR 3094164A1 FR 1902989 A FR1902989 A FR 1902989A FR 1902989 A FR1902989 A FR 1902989A FR 3094164 A1 FR3094164 A1 FR 3094164A1
Authority
FR
France
Prior art keywords
network
client device
data
segment
score
Prior art date
Legal status (The legal status 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 status listed.)
Granted
Application number
FR1902989A
Other languages
English (en)
Other versions
FR3094164B1 (fr
Inventor
Axel DELMAS
Paul-Louis AGENEAU
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Streamroot SAS
Original Assignee
Streamroot SAS
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
Priority to FR1902989A priority Critical patent/FR3094164B1/fr
Application filed by Streamroot SAS filed Critical Streamroot SAS
Priority to PCT/EP2020/057862 priority patent/WO2020193429A1/fr
Priority to US16/825,809 priority patent/US11528658B2/en
Priority to EP20712568.3A priority patent/EP3942778A1/fr
Priority to SG11202110485QA priority patent/SG11202110485QA/en
Priority to AU2020249319A priority patent/AU2020249319A1/en
Priority to KR1020217034291A priority patent/KR20210139431A/ko
Priority to JP2021555572A priority patent/JP2022525217A/ja
Priority to CA3133413A priority patent/CA3133413A1/fr
Publication of FR3094164A1 publication Critical patent/FR3094164A1/fr
Application granted granted Critical
Publication of FR3094164B1 publication Critical patent/FR3094164B1/fr
Priority to US18/078,945 priority patent/US20230354173A1/en
Active legal-status Critical Current
Anticipated expiration legal-status Critical

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

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é. Figure pour l’abrégé : Figure 2

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
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.
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.
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.
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.
On a représenté enfigure 1un 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 1a, 1b, qui seront désignés dispositifs tiers par contraste avec le dispositif client 1.
Les dispositifs 1a et 1b sont configurés de la même manière que le dispositif 1.
L’un quelconque des dispositifs 1, 1a, 1b 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 à lafigure 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 xiassocié au CDN d’indice i. Le score xiest 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 xicroî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 Pila 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 xicroî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 :
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 Pjassocié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 d’exploration C. 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é Pjde tirer un CDN d’indice j parmi les N CDNs disponibles est de la forme suivante :
Recourir au paramètre d’exploration C est avantageux car permet d’ajuster le caractère plus ou moins exploratoire du tirage aléatoire. 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 1a ou 1b, 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 ville, 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 xiau 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 xien 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 xitient 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, 1b 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 1b, 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 apparaitre 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.
HANDICAP_BASE = 10
ERROR_PERCENTAGE_BASE = 10
CAUTIOUSNESS in [0, +Inf[
ALPHA in ]0, 1] # bandwidth smoothing EWMA factor
BETA in ]0, 1] # error rate estimation EWMA factor
GAMMA in ]0, 1[ # handicap exponential decrease
for each CDN:
score = weight * bandwidth / HANDICAP_BASE ^ hpw
probability = score ^ CAUTIOUSNESS
on success:
// EWMA for bandwidth smoothing
bandwidth = (1 - ALPHA) * bandwidth + ALPHA * measured_bandwidth
// EWMA for error rate estimation
error_rate = (1 - BETA) * error_rate
on error:
hpw = Min(100, hpw + ERROR_PERCENTAGE_BASE ^ (error_rate * 100))
// EWMA for error rate estimation
error_rate = (1 - BETA) * error_rate + BETA
on tick:
// hpw multiplicative decrease with time
hpw = (1. - GAMMA) * hpw
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 GAMMA 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 ^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 ^ hpw. Donc dans cet exemple le dénominateur vaudra 10^10.

Claims (19)

  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 d’exploration, 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 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.
  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’exploration 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 indicative d’une qualité de transmission de segments de données depuis le même réseau à au moins un dispositif tiers (1a, 1b) 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 (1a, 1b).
  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 l’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 de 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.
FR1902989A 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 Active FR3094164B1 (fr)

Priority Applications (10)

Application Number Priority Date Filing Date Title
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
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
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
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
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
KR1020217034291A KR20210139431A (ko) 2019-03-22 2020-03-20 복수 개의 콘텐츠 전송 네트워크와 통신할 수 있는 클라이언트 디바이스에 의하여 데이터 세그멘트를 획득하기 위한 방법
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
US16/825,809 US11528658B2 (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
JP2021555572A JP2022525217A (ja) 2019-03-22 2020-03-20 複数のコンテンツデリバリネットワークと通信可能なクライアント装置によるデータセグメントの取得方法
US18/078,945 US20230354173A1 (en) 2019-03-22 2022-12-10 Method for obtaining a data segment by a client device capable of communicating with a plurality of content delivery networks

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR1902989 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 (2)

Publication Number Publication Date
FR3094164A1 true FR3094164A1 (fr) 2020-09-25
FR3094164B1 FR3094164B1 (fr) 2021-10-29

Family

ID=67107877

Family Applications (1)

Application Number Title Priority Date Filing Date
FR1902989A Active 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

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
US20100094965A1 (en) * 2008-10-15 2010-04-15 Patentvc Ltd. Erasure-coded content assembly and retransmission
EP2468030B1 (fr) * 2009-08-19 2016-07-20 Opanga Networks, Inc. Distribution améliorée de données basée sur l'analyse en temps réel de la qualité des communications par réseau et du trafic
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
WO2014096463A1 (fr) * 2012-12-21 2014-06-26 Koninklijke Kpn N.V. Émission en continu à faible latence
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
EP3183884B1 (fr) * 2014-09-22 2020-07-01 ARRIS Enterprises LLC Qualité d'expérience vidéo basée sur une estimation de qualité vidéo
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
US10701119B2 (en) * 2015-06-16 2020-06-30 Apple Inc. Adaptive video streaming using dynamic radio access network information
CA3010043C (fr) * 2015-12-29 2020-10-20 DISH Technologies L.L.C. Routage dynamique de distribution de contenu et procedes et systemes associes
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
EP3840392A1 (fr) * 2016-09-08 2021-06-23 InterDigital CE Patent Holdings Procédé et appareil destinés à la distribution de contenu multimédia
US10341241B2 (en) * 2016-11-10 2019-07-02 Hughes Network Systems, Llc History-based classification of traffic into QoS class with self-update
CN110301143B (zh) * 2016-12-30 2022-04-22 英特尔公司 用于无线电通信的方法和设备
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
US10839304B2 (en) * 2017-01-25 2020-11-17 Pearson Education, Inc. Platform-agnostic Bayes net content aggregation system and method
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
US11250720B2 (en) * 2018-03-30 2022-02-15 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
KR20210139431A (ko) 2021-11-22
US20200305070A1 (en) 2020-09-24
EP3942778A1 (fr) 2022-01-26
WO2020193429A1 (fr) 2020-10-01
US11528658B2 (en) 2022-12-13
US20230354173A1 (en) 2023-11-02
AU2020249319A1 (en) 2021-10-28
CA3133413A1 (fr) 2020-10-01
JP2022525217A (ja) 2022-05-11
SG11202110485QA (en) 2021-10-28
FR3094164B1 (fr) 2021-10-29

Similar Documents

Publication Publication Date Title
EP3949434A1 (fr) Procédé de diffusion de contenus en streaming dans un réseau pair à pair
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
EP3281411A1 (fr) Procédé de lecture en continu sur un équipement client d'un contenu diffusé au sein d'un réseau pair à pair
FR2851389A1 (fr) Procede et dispositif de gestion de requetes dans une architecture du type client-serveur
FR2866183A1 (fr) Procedes d'emission et de reception d'une animation, et dispositifs associes
EP3840335B1 (fr) Réception d'un contenu numérique en mode truque
EP3205067B1 (fr) Diffusion de contenus en streaming dans un réseau pair à pair
EP3314830B1 (fr) Adaptation d'un profil de transmission d'une communication web temps reel
FR2897961A1 (fr) Procede de gestion de l'execution d'un jeu video pour la diffusion en temps reel de publicites dynamiques
FR2952203A1 (fr) Procede de generation d'un flux web et un systeme associe
BE1029303B1 (fr) Procédé et système d'affichage digital
WO2018109407A1 (fr) Procédé et dispositif de mise à jour
EP4272449A2 (fr) Contrôle de la transmission d'au moins un contenu depuis un equipement fournisseur vers un noeud d'ingestion
FR2941110A1 (fr) Procede et dispositif de prediction d'un etat de pertes d'un reseau de communication
FR3135857A1 (fr) Gestion de la restitution d’un contenu multimédia sur plusieurs écrans.
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
FR3111454A1 (fr) Procédé et système d'adaptation d'un réseau de neurones utilisé dans un réseau de télécommunications
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
FR3140504A1 (fr) Gestion de la lecture d’un contenu multimédia
FR3079704A1 (fr) Communication par video conference
WO2014091131A1 (fr) Sélection multicritères de systèmes de diffusion de contenu
WO2017109362A1 (fr) Procédés et serveurs de transmission et de réception de documents comprenant des images
FR2834839A1 (fr) Procede et dispositif de gestion des transmissions de donnees numeriques multimedia

Legal Events

Date Code Title Description
PLFP Fee payment

Year of fee payment: 2

PLSC Publication of the preliminary search report

Effective date: 20200925

PLFP Fee payment

Year of fee payment: 3

PLFP Fee payment

Year of fee payment: 4

PLFP Fee payment

Year of fee payment: 5