FR3046008A1 - Systeme de repartition de charge geolocalise - Google Patents

Abstract

L'invention concerne un procédé de traitement par un système de répartition de charge, le procédé étant apte à répartir entre une première pluralité de serveurs de cache la charge imposée par une pluralité de requêtes, respectivement émises par une pluralité de terminaux répartis sur une pluralité de zones géographiques.

Description

Système de répartition de charge géolocalisé

La présente invention appartient au domaine de la gestion de la charge imposée à des serveurs distants. Elle concerne en particulier un procédé apte à répartir la charge imposée par une pluralité de requêtes, respectivement émises par une pluralité de terminaux, entre une pluralité de serveurs de cache.

On entend par « serveur » ou « serveur distant », tout type de dispositif électronique apte à recevoir ou émettre des données. Un ordinateur, un serveur vidéo, un téléphone portable, une montre connectée, un serveur de cache, un distributeur automatique de billets sont des exemples de serveur.

On entend par « serveur de cache », un serveur qui enregistre, par exemple temporairement, des copies de données provenant d'une autre source de données, afin de diminuer le temps d'accès à ces données.

En effet, il est fréquent qu’une petite partie des données/services accessibles via un serveur soit effectivement consultée par les utilisateurs ou par un processeur. Par exemple, sur un serveur stockant 10 To de données, il est possible que 90 pourcents des requêtes portent sur un unique ensemble de données de 250 Go. Ainsi, pour soulager la charge du serveur, il a pu être proposé de mettre en place un serveur de cache stockant l’ensemble de données de 250Go. Les requêtes sont alors directement orientées vers le serveur de cache qui peut satisfaire 90 pourcents des requêtes mais doit transmettre les 10 pourcents de requêtes restantes au serveur stockant les 10 To de données.

Toutefois, l’utilisation d’un serveur de cache peut ne pas être suffisante si le nombre de requêtes est trop important.

Une autre méthode a pu être proposée pour réduire l’encombrement d’un serveur soumis à un trop grand nombre de requêtes. Cette méthode repose sur l’utilisation de dispositifs de répartition de charge, « load-balancer » en anglais. Ces dispositifs réorientent les requêtes vers différents serveurs aptes à traiter ces requêtes. En particulier, les requêtes sont réorientées vers les serveurs de traitement présentant la charge la plus faible.

Le nombre de serveur de traitement doit toutefois être conséquent pour que le dispositif de répartition de charge puisse toujours trouver un serveur de traitement disponible.

En particulier, lorsque la charge imposée au dispositif de répartition varie fortement au cours du temps, il faut prévoir un nombre suffisant de serveurs lorsque la charge est maximale, même si cela n’arrive statistiquement que sur une période très courte.

Ainsi, les systèmes actuels permettant de traiter un nombre important de requêtes sont complexes et coûteux en ce qu’ils imposent un grand nombre de serveurs de traitement.

La présente invention vient améliorer la situation. A cet effet, un premier aspect de l’invention concerne un procédé de traitement par un système de répartition de charge, le procédé étant apte à répartir entre une première pluralité de serveurs de cache la charge imposée par une pluralité de requêtes, respectivement émises par une pluralité de terminaux répartis sur une pluralité de zones géographiques, au moins un serveur de cache, parmi la première pluralité de serveurs de cache, stockant, pour chaque zone géographique parmi la pluralité de zones géographiques, au moins un contenu dédié à ladite zone géographique, le procédé comprenant l’exécution, par le système de répartition, des étapes suivantes : - réception d’une requête, émise par un terminal, d’accès à un contenu dédié à la zone géographique, dite zone géographique du terminal, dans laquelle le terminal est localisé, la requête comprenant une information de localisation du terminal ; - recherche, à partir de l’information de localisation du terminal, d’au moins un serveur de cache stockant le contenu dédié à la zone géographique du terminal parmi la première pluralité de serveurs de cache ; - sur détection du serveur de cache stockant le contenu dédié à la zone géographique du terminal, transmission de la requête vers le serveur de cache détecté.

On entend par « contenu », tout type de contenu lisible par un dispositif électronique. Typiquement, un contenu peut être des données d’informations, un fichier texte, un service de banque en ligne, un contenu multimédia, un service de diffusion d’une radio, etc. Un contenu multimédia comprend au moins un élément parmi des données vidéo, des données d’image, des données audio, des données de texte, un fichier vidéo, un fichier audio, un flux audio, un flux vidéo, le flux audio d’une station de radio, le flux vidéo d’une chaîne de télévision, une image, des données de mouvement, etc. Dans la suite de la description, l’invention est décrite dans son application à un contenu correspondant à des données d’information, et en particulier aux données LIST décrites ci-après en référence aux figures 2 et 3.

On entend par « contenu dédié à une zone géographique » un contenu dont au moins une propriété est caractéristique de la zone géographique. Un fichier décrivant des informations caractéristiques de la zone géographique, un flux vidéo accessible au moins sur la zone géographique ou un article de presse sur un événement ayant eu lieu dans la zone géographique sont des exemples de contenus dédiés à la zone géographique.

La requête d’accès à un contenu dédié à la zone géographique doit être interprétée de manière générique, dans le sens où la requête ne comprend pas nécessairement d’information sur la zone géographique en question. En effet, cette requête peut juste indiquer un message de type : « je souhaite accéder à un contenu dédié à la zone géographique dans laquelle je me situe, bien que j’ignore les coordonnées de cette zone géographique». Comme cela est expliqué ci-après en référence à la figure 2, la requête comprend une information de localisation du terminal qui peut être interprétée par le système de répartition pour trouver la zone géographique correspondant à cette information de localisation du terminal.

On entend par « zone géographique du terminal, dans laquelle le terminal est localisé », la zone géographique dans laquelle le terminal est physiquement ou virtuellement situé. En effet, l’invention est également directement applicable au cas où le terminal se localise dans une zone géographique donnée alors qu’il est physiquement situé à une autre localisation. Dans ce cas l’information de localisation du terminal correspond à la localisation virtuelle, souhaitée par le terminal et/ou l’utilisateur du terminal, et non à la localisation physique du terminal.

La prise en compte de la position géographique du terminal dans la sélection d’un serveur de cache a pour effet de simplifier et de rationaliser l’architecture d’un système de traitement en limitant le nombre de serveurs. Cette simplification est fondée sur une meilleure utilisation des propriétés des serveurs de cache.

Un serveur de cache est particulièrement efficace quand les requêtes qui lui sont faites sont homogènes. En effet, le serveur de cache a pour propriété de fournir directement, et donc rapidement, un ensemble restreint de contenus. Il importe donc d’orienter vers le serveur de cache des requêtes qui pointent vers cet ensemble restreint de contenus.

Pour trouver un ensemble restreint de contenu, il faut déterminer quels sont les contenus les plus demandés. Or, si les requêtes sont hétérogènes, il n’y a pas vraiment de contenus particulièrement demandés. Il faut donc essayer de regrouper les requêtes pour qu’elles forment des ensembles homogènes.

En orientant une requête à partir de la zone géographique sur laquelle est situé le terminal émettant cette requête, l’invention permet simplement ce regroupement des requêtes en ensembles homogènes. Les requêtes émises par des terminaux situés sur une même zone géographique sont en effet statistiquement plus proches les unes des autres que des requêtes émises par des terminaux géographiquement éloignés.

En particulier, l’existence de contenus spécifiquement dédiés à une zone géographique rend encore plus pertinente la répartition géolocalisée des requêtes vers les serveurs de cache. Un contenu spécifique à une zone géographique donnée n’a en effet aucune raison d’être requis par un terminal situé sur une zone géographique autre que la zone géographique donnée.

Dans un mode de réalisation, l’étape de recherche d’au moins un serveur de cache comporte les sous-étapes de : - détermination d’une zone géographique parmi la pluralité de zones géographiques correspondant à l’information de localisation du terminal, la zone géographique déterminée correspondant à ladite zone géographique du terminal ; - détermination dudit au moins un serveur de cache stockant le contenu dédié à partir de la zone géographique déterminée, correspondant à la zone géographique du terminal.

Tout type de dispositif de géolocalisation (GPS, utilisation de données réseaux, etc.) suffit ainsi au terminal pour envoyer la requête. En particulier, le terminal n’a pas à connaître le maillage du territoire en zones géographiques car l’étape d’association d’une zone géographique à la position du terminal est sous-traitée au système de répartition.

Dans un autre mode de réalisation, le système de répartition comporte, pour chaque zone géographique parmi la pluralité de zones géographiques, un serveur de répartition de charge dédié à ladite zone géographique. Dans ce mode de réalisation, une deuxième pluralité de serveur de cache, comprise dans la première pluralité de serveurs de cache, est déterminée à partir de la zone géographique du terminal. Le procédé comporte alors en outre, postérieurement à l’étape de détermination, les étapes de : - transmission de la deuxième pluralité de serveur de cache à un serveur de répartition de charge dédié à la zone géographique du terminal ; - sélection par le serveur de répartition de charge dédié à la zone géographique du terminal, d’un serveur de cache parmi la deuxième pluralité de serveurs de cache ; - transmission de la requête vers le serveur de cache sélectionné.

Ainsi, il est possible de dimensionner le nombre de serveurs de cache par zone géographique. Cette propriété est particulièrement intéressante lorsque la densité de population est inégalement répartie sur un territoire. En effet, les zones géographiques comprenant des agglomérations densément peuplées peuvent ainsi être couvertes par un nombre important de serveurs de cache afin d’assumer une charge importante. A l’inverse, les zones faiblement peuplées peuvent n’être couvertes que par un faible nombre de serveurs de cache.

Dans un mode de réalisation, le système de répartition comporte, pour chaque zone géographique parmi la pluralité de zones géographiques, un serveur de mise à jour, à partir d’une base de données, du contenu dédié à ladite zone géographique. Le procédé comporte alors en outre les étapes, mises en œuvre par le serveur de mise à jour dédié à la zone géographique du terminal, de : - recherche dans la base de données d’au moins une modification du contenu dédié à ladite zone géographique du terminal ; - sur détection d’une modification, extraction du contenu modifié depuis la base de données vers le serveur de mise à jour ; - transmission à la deuxième pluralité de serveurs de cache d’une requête de mise à jour comprenant le contenu modifié.

On entend par « contenu modifié » un contenu présent dans la base de données pour lequel l’étape de recherche a révélé que ce contenu avait été modifié dans la base de données par rapport au contenu stocké sur la deuxième pluralité de serveurs de cache.

La première pluralité de serveurs de cache peut ainsi être mise à jour de manière centralisée par le biais d’une unique base de données.

En particulier, la recherche d’une modification est effectuée cycliquement par le serveur de mise à jour dédié à la zone géographique du terminal. Les moments où la base de données sera sollicitée peuvent donc être précisément prévus. En particulier, il est possible de prévoir de décaler les cycles de chacun des serveurs de mise à jour pour que la base de données soit sollicitée de la manière la plus continue possible.

Dans un autre mode de réalisation, le serveur de cache sélectionné est celui présentant, à l’instant où la sélection est faite, la charge la plus faible parmi la deuxième pluralité de serveurs de cache. Les serveurs de cache sont ainsi utilisées de manière homogène ce qui augmente leur durée de vie et maximise la charge qui peut être imposée à la deuxième pluralité de serveurs de cache.

Dans un mode de réalisation, le procédé comporte en outre, préalablement à l’étape de réception de la requête par le système de répartition, les étapes de : - acquisition de coordonnées de géo-positionnement par satellite, GPS ; - approximation des coordonnées pour l’obtention d’une approximation correspondant à l’information de localisation du terminal. L’approximation des coordonnées GPS simplifie les calculs effectuées pour déterminer la zone géographique du terminal à partir de l’information de localisation du terminal et réduit la taille de la requête d’accès à un contenu dédié.

Un deuxième aspect de l’invention concerne un système de répartition de charge apte à répartir entre une première pluralité de serveurs de cache la charge imposée par une pluralité de requêtes, respectivement émises par une pluralité de terminaux répartis sur une pluralité de zones géographiques, au moins un serveur de cache, parmi la première pluralité de serveurs de cache, stockant, pour chaque zone géographique parmi la pluralité de zones géographiques, au moins un contenu dédié à ladite zone géographique, le système de répartition comprenant : - un récepteur pour la réception d’une requête, émise par un terminal, d’accès à un contenu dédié à la zone géographique, dite zone géographique du terminal, dans laquelle le terminal est localisé, la requête comprenant une information de localisation du terminal ; - un processeur apte à chercher, à partir de l’information de localisation du terminal, au moins un serveur de cache stockant le contenu dédié à la zone géographique du terminal parmi la première pluralité de serveurs de cache ; - un transmetteur pour, sur détection du serveur de cache stockant le contenu dédié à la zone géographique du terminal, transmettre de la requête vers le serveur de cache détecté.

Un troisième aspect de l’invention concerne un terminal apte à transmettre la requête d’accès à un contenu dédié à la zone géographique du terminal envoyée au système de répartition selon le deuxième aspect de l’invention.

Un quatrième aspect de l’invention concerne un serveur de répartition de charge dédié à ladite zone géographique et compris dans le système de répartition de charge selon le deuxième aspect de l’invention, le serveur de répartition de charge étant à apte à répartir la charge sur une deuxième pluralité de serveurs de cache, la deuxième pluralité de serveurs de cache, comprise dans la première pluralité de serveurs de cache, étant déterminée à partir de la zone géographique du terminal, le serveur de répartition de charge comprenant : - un récepteur pour recevoir la requête ; - un processeur apte à sélectionner un serveur de cache parmi la deuxième pluralité de serveurs de cache ; - un transmetteur pour transmettre la requête vers le serveur de cache sélectionné. D’autres caractéristiques et avantages de l’invention apparaîtront à l’examen de la description détaillée ci-après, et des dessins annexés sur lesquels: la figure 1 illustre un contexte de mise en œuvre d’un procédé de traitement, relatif à la transmission d’information à un terminal sur la disponibilité d’au moins un réseau apte à diffuser un contenu multimédia à l’endroit où est localisé le terminal, selon un mode de réalisation de l’invention ; la figure 2 est un diagramme illustrant les étapes d’un procédé de traitement, relatif à la transmission d’information à un terminal sur la disponibilité d’au moins un réseau apte à diffuser un contenu multimédia à l’endroit où est localisé le terminal, selon un mode de réalisation de l’invention ; la figure 3 est un schéma illustrant le système destiné à transmettre des informations à un terminal sur la disponibilité d’au moins un réseau apte à diffuser un contenu multimédia à l’endroit où est localisé le terminal, selon un mode de réalisation de l’invention ; la figure 4 est un diagramme illustrant les étapes d’un procédé de mise à jour de la base de données du système, selon un mode de réalisation de l’invention ; la figure 5 illustre un contexte technique de mise en œuvre d’un procédé de traitement, relatif à la gestion de la charge, selon un mode de réalisation de l’invention ; la figure 6A est un diagramme illustrant les étapes d’un procédé de traitement, relatif à la gestion de la charge, selon un mode de réalisation de l’invention ; la figure 6B est un schéma illustrant la gestion des requêtes par le système, selon un mode de réalisation de l’invention ; la figure 7 illustre un microcontrôleur, selon un mode de réalisation de l’invention. L’invention est décrite ci-après dans son application, non limitative, à la transmission d’information à un terminal sur la disponibilité d’au moins un réseau apte à diffuser un contenu multimédia à l’endroit où est localisé le terminal. Le contenu multimédia ici décrit est de type flux audio, et plus particulièrement à la diffusion de stations de radio. D’autres applications telles que la diffusion d’un flux vidéo, comme la TNT, ou la diffusion d’un contenu vidéo ponctuel, comme le téléchargement d’un film, sont également envisageables.

Le procédé et les dispositifs de traitement par un système de répartition de charge sont plus particulièrement décrits aux figures 5 à 6B.

La figure 1 illustre un contexte d’utilisation de l’invention, selon un mode de réalisation. Un terminal UE est situé dans une zone géographique, ici référencée (i ; j), comprise dans un territoire plus vaste. Par exemple, le territoire français peut-être découpé en zones géographiques carrées pour former une matrice de I lignes et J colonnes. D’autres formes et répartition du territoire en zones géographiques sont possibles, il est ainsi possible de séparer le territoire en zones et sous-zones, de prévoir des zones rectangulaires ou hexagonales, de ne pas prendre en compte certaines zones du territoire, etc. Dans la suite de la description, l’exemple du territoire français sera pris. L’invention est décrite ci-après dans son application, non limitative, pour un terminal UE de type smartphone, pour téléphone intelligent en français. Comme mentionné ci-avant, d’autres types de terminaux sont possibles et notamment un terminal de type autoradio.

On suppose que le terminal est ici situé dans une zone géographique (i ; j), avec i e [1; /J et j E [1;/]. Dans cette zone géographique, on suppose en outre que trois réseaux, un de radiodiffusion en modulation de fréquence FM, un réseau cellulaire de radiotéléphonie 4G et un réseau de radiodiffusion sonore numérique DAB sont présents. On suppose également que le réseau FM est ici apte à diffuser les stations radio françaises RFM, MARQUE DEPOSEE, et RFI, MARQUE DEPOSEE, le réseau DAB est ici apte à diffuser les stations radio françaises RFI, NRJ, MARQUE DEPOSEE, et RFM et le réseau 4G est ici apte à diffuser les stations radio françaises RFI, NRJ, RFM et la radio suisse Couleur 3, MARQUE DEPOSEE.

Le terminal UE peut en outre communiquer avec un système SYST. Les échanges avec le système SYST peuvent être assurés par tout type de canal de communication, par exemple par n’importe lequel des réseaux disponibles dans la zone (i ; j) ou par un réseau prédéterminé tel que le réseau 4G.

Comme cela est détaillé ci-après en référence à la figure 2, le terminal UE envoie une requête REQ d’information sur la disponibilité du contenu multimédia comprenant une information de localisation (GPS) du terminal. La requête est alors traitée par le système (voir ci-après les explications données en référence à la figure 2) et le système retourne des données LIST relatives aux réseaux disponibles détectés pour la zone (i ; j). Ces données comprennent typiquement la liste des réseaux disponibles, soit ici : • 4G: RFI, NRJ, RFM, Couleur 3 ; • FM : RFM, RFI ; • DAB : RFI, NRJ, RFM.

Un procédé de traitement selon un mode de réalisation de l’invention est maintenant décrit en référence à la figure 2.

Le procédé peut être mis en œuvre dans différentes situations. Il a pour objet de faciliter et de fluidifier l’accès par l’utilisateur d’un terminal à un contenu multimédia (ici la radio) accessible par différents réseaux. Ainsi, l’utilisateur peut être dans la situation où il se déplace pour arriver dans la zone géographique (i ; j), typiquement quand l’utilisateur sollicite (déverrouillage ou allumage) son smartphone à la suite ou pendant un déplacement en train ou en voiture à grande vitesse.

La configuration du terminal est alors inadaptée aux réseaux disponibles dans la nouvelle zone géographique (i ; j). En effet, le terminal est configuré pour fonctionner sur les réseaux présents dans la zone géographique dans laquelle il était préalablement situé. Dans la situation où l’utilisateur écoute une radio et que le terminal change de zone géographique, la diffusion de la radio peut-être interrompue car le terminal doit changer de configuration pour s’adapter aux réseaux présents dans la nouvelle zone géographique (i ; j).

En outre, l’utilisateur ne connaît pas les différentes stations accessibles dans la nouvelle zone géographique (i ; j). En effet, certains réseaux (typiquement le réseau FM) ne proposent pas les mêmes radios dans toutes les zones géographiques du territoire.

Pour résoudre ces problèmes, le procédé selon un mode de réalisation de l’invention comprend les étapes suivantes. A une première étape 1, le terminal se géolocalise. Pour ce faire, il peut déterminer sa position (latitude et longitude par exemple) au moyen d’un GPS, pour système de position global, ou de tout autre dispositif de géolocalisation. Une information de localisation du terminal, référencée GPS, est obtenue par cette étape de géolocalisation.

Optionnellement, le terminal peut aussi mesurer lors de cette première étape 1 un indicateur de qualité QoS d’un réseau présent dans la zone géographique (i ; j). Ledit réseau présent peut être détecté par le terminal par une étape préliminaire. Alternativement, une liste prédéterminée de réseaux à mesurer peut-être stockée sur le terminal. Les réseaux à mesurer peuvent également être déterminés à partir des données LIST obtenues par le présent procédé pour une zone géographique où le terminal était préalablement situé. L’indicateur de qualité peut être un indicateur de disponibilité du réseau mesuré, un retard lié à la transmission, un rapport de signal sur bruit lié à la transmission, une puissance d’un signal lié à la transmission, une valeur de bruit du signal, un indicateur du nombre de canaux multiplexés sur un même signal analogique, une présence de métadonnées sur le signal, etc.

Egalement de manière optionnelle, le terminal peut mesurer lors de cette première étape 1 un indicateur de retard inter-réseaux AR. L’indicateur de retard inter-réseaux comprend une valeur de retard dans la diffusion d’une radio entre un premier réseau et un deuxième réseau présents dans la zone géographique (i ; j). De même que pour l’indicateur de qualité QoS, lesdits premiers et deuxième réseaux présents peuvent être détectés par le terminal par une étape préliminaire, stockés sur le terminal ou encore déterminés à partir des données LIST obtenues par le présent procédé pour une zone géographique où le terminal était préalablement situé. Le nombre d’indicateurs inter-réseaux peut alors être égal à (a -1) avec a le nombre de réseaux présents dans la zone géographique.

Dans un autre mode de réalisation, les étapes optionnelles de mesure de l’indicateur de qualité QoS et/ou de l’indicateur de retard inter-réseaux Ar peuvent être effectuées après les étapes (décrites ci-après en référence aux étapes 2 à 8) de transmission au terminal des données relatives aux réseaux détectés comme disponibles dans la zone géographique (i ; j) par le système SYST.

Une requête REQ est ensuite générée à l’étape 2, cette requête comprend au moins l’information de localisation, référencée GPS, du terminal acquise à l’étape 1. La requête REQ peut également comprendre le au moins un indicateur de qualité QoS et/ou le au moins un indicateur de retard inter-réseaux AR. Cette requête est ensuite transmise au système SYST aux étapes 3 et 4. L’architecture et le fonctionnement détaillé du système SYST sont décrits ci-après en référence aux figures 3 à 7. A une étape 5, la zone géographique correspondant à l’information de localisation GPS comprise dans la requête est déterminée par le système SYST. Le détail de la détermination de la zone géographique, ensuite appelée zone géographique du terminal, est donné ci-après en référence à l’étape 3 de la figure 6A. Le système SYST comprend une base de données, référencée DB (ou 10) aux figures 3 à 7, stockant, pour chaque zone géographique du territoire, une liste comprenant des indicateurs de disponibilité respectifs des réseaux, parmi tous les réseaux théoriquement disponible sur le territoire, dans ladite zone géographique. A une étape 6, une recherche dans la base de données DB d’un réseau disponible dans la zone géographique (i ; j) déterminée à l’étape 5 est effectuée. Comme détaillé ci-après, la base de données DB peut comprendre une liste des réseaux disponibles pour chaque zone géographique du territoire, aptes à diffuser des radios dans la zone géographique. Lorsqu’au moins un réseau disponible est détecté, des données relatives audit réseau disponible détecté sont extraites de la base de données DB. On considère ci-après que trois réseaux sont détectés pour la zone (i ; j) : les réseaux FM ; DAB et 4G.

Ces données, qui sont stockées dans la base de données DB, correspondent à tout type de données en lien avec les réseaux détectés. En particulier, il peut s’agir d’un identifiant de chacun des réseaux détectés, d’un identifiant des contenus disponibles, d’un indicateur de disponibilité de chacun des réseaux détectés, d’un indicateur de qualité QoS de chacun des réseaux détectés, d’une valeur de retard inter-flux Ar entre chacun des réseaux détectés. Ces différents données peuvent être présentées sous forme de carte de couverture des zones géographiques, comme cela est détaillé ci-après en référence aux figures 3 et 4 Les données aurait ici par exemple pu comprendre les valeurs de Ar(FM ; 4G) ; AR(FM ; DAB) ; Ar(4G ; DAB). Le stockage et la mise à jour de ces données est expliqué ci-après en référence aux figures 3 à 6.

Un identifiant d’un contenu disponible peut-être au moins un élément parmi : • Identifiant interne : cet identifiant est unique et correspond à un contenu pris en compte par la base de données ; • Service Identifier ou (SId) identifie un contenu sur les réseaux DAB, DAB+, DMB et DRM :

• Programme Identification ou PI identifie un contenu sur le réseau FM-RDS • URL : identifie un flux de streaming sur internet.

Les identifiants de chacun des réseaux détectés et/ou des contenus disponibles peuvent être utilisés par le terminal pour suivre un service en mobilité.

Une liste LIST(i ; j) des données extraites associées aux réseaux détectés pour la zone géographique (i ; j) est ensuite générée pour être transmise à l’étape 7. Elle est ensuite reçue par le terminal UE à l’étape 8.

Les données sont utilisées de diverses manières par le terminal. Dans un mode de réalisation, le terminal utilise simplement la liste des réseaux pour proposer directement à l’utilisateur une liste de radios accessibles. Cette liste de radios accessibles peut préciser avec quels réseaux les radios sont accessibles. L’utilisateur dispose ainsi directement et simplement d’une vue d’ensemble sur toutes les radios disponibles dans la zone dans laquelle il est situé.

Les indicateurs de qualités QoS peuvent être utilisés par le terminal pour paramétrer la réception des radios sur le terminal. Ces indicateurs de qualité peuvent également être présentés à l’utilisateur pour l’aider à choisir une radio.

Les valeurs de retard inter-flux Ar(FM ; 4G) ; Ar(FM ; DAB) et Ar(4G ; DAB) sont utilisés pour fluidifier les transitions entre réseaux lorsqu’un premier réseau n’est plus disponible et qu’il faut utiliser un deuxième réseau pour continuer la diffusion.

Prenons l’exemple d’une rupture dans la diffusion de la radio RFM par le réseau FM. Le terminal peut alors chercher à passer sur le réseau DAB pour continuer à diffuser la radio RFM. Or, les temps de propagation des flux audio pour la radio RFM sont différents selon les réseaux ce qui a pour effet d’introduire un décalage temporel entre la radio RFM diffusé par le réseau FM et la radio RFM diffusée par le réseau DAB. Ce décalage est gênant pour l’utilisateur.

Il existe des algorithmes de resynchronisation calculant, à partir de deux signaux identiques et décalés, le décalage entre les signaux. Ces algorithmes sont bien connus et fondés sur un calcul de corrélation entre les deux signaux. De tels algorithmes ne sont toutefois pas toujours présents sur les terminaux car ils peuvent consommer des ressources de calculs et être complexes à implémenter. Dans cette situation, l’utilisateur subit le décalage lors de la transition.

De plus, même quand le terminal comprend un algorithme de resynchronisation, la mise en œuvre de la resynchronisation est largement simplifiée si le retard inter-flux est connu. D’une part, comme le décalage n’est pas initialement connu par l’algorithme de corrélation, l’algorithme doit dimensionner des mémoires tampons, des « buffers » dont le fonctionnement est bien connu, de taille importante afin d’utiliser tout le signal audio disponible. Le coût en ressources (processeur et mémoire vive) et en complexité est donc important. D’autre part, la mise en œuvre de la corrélation entre les deux signaux nécessite de stocker sur des buffers deux signaux (l’objet de la corrélation étant de trouver deux portions de signaux identiques et de calculer le décalage entre ces deux portions). Si le retard inter-flux est connu, il suffit de stocker sur un buffer la portion de signal décalé.

Ainsi, quand la valeur de retard inter-flux est connue du terminal, le terminal peut utiliser un unique buffer pour stocker les parties de signaux décalés.

Ainsi, l’envoi par le système d’une liste informant le terminal de tous les réseaux et de toutes les radios respectivement diffusées par ces réseaux dans la zone géographique (i ; j) résout rapidement et simplement les problèmes de transition et de facilité d’accès aux contenus. En effet, la liste peut comprendre toutes les informations requises pour rendre possible une configuration rapide et précise du terminal comme cela est expliqué ci-avant pour le retard inter-flux. L’architecture du système SYST, selon un mode de réalisation, est maintenant décrite en référence à la figure 3. Ce système comprend un module de traitement 17 composé d’un système de répartition de charge 9, d’un module de calcul de retard inter-flux 11, d’un module de calcul de la qualité des réseaux 12, de la base de données 10, encore appelée base géolocalisée des services, d’un module de vérification des URL de streaming 14 et d’un module 13 d’actualisation de la base de données.

Le système de répartition de charge comporte au moins un serveur de cache et utilisé pour absorber la charge des requêtes et ainsi éviter de congestionner la base de données 10. Il est décrit plus en détail ci-après en référence aux figures 5 et 6.

Le module de calcul de retard inter-flux 11 est utilisé pour calculer une valeur de retard inter-flux pertinente entre chacun des réseaux de chacune des zones géographiques prises en compte par la base de données DB. En particulier, il analyse les valeurs de retard inter-flux reçues de tous les terminaux afin d’en déduire une valeur moyenne.

Ce module met à jour la valeur recalculée dans la base de données, par exemple cycliquement ou sur détection d’une modification importante de la valeur moyenne pour au moins une zone géographique. Il peut posséder sa propre base de données afin d’y stocker les données de retard reçues sur une profondeur temporelle configurable.

Le module de calcul de la qualité des réseaux 12 reçoit, des terminaux, les indicateurs de qualité QoS mesurés. Ce module peut également posséder sa propre base de données afin d’y stocker les indicateurs de qualité reçus des terminaux sur une profondeur temporelle configurable et ainsi de calculer une valeur moyenne de qualité. Le module met à jour la base de données DB avec les valeurs moyennes calculées, par exemple cycliquement ou sur détection d’une modification importante de la valeur moyenne pour au moins une zone géographique.

Le module de vérification des URL de streaming 14 assure la surveillance de la validité des URL utilisées pour les contenus multimédia de type streaming sur IP. Les flux disponibles via le streaming sont des flux audio et/ou vidéo accessibles via internet (et donc via les réseaux Wi-Fi, 4G, etc.), à partir d’au moins une base de données de streaming, ici représenté par le module 16. Le module 14 parcourt la liste des contenus multimédia de la base de données DB et vérifie pour chaque URL présente que le stream (contenus multimédia) est disponible, c'est-à-dire que l’URL est bien valide. Si le stream n’est pas disponible le module peut alors envoyer une notification de disfonctionnement à des terminaux prédéterminés (par exemple tous les terminaux reliés à la base de données DB). Le module 14 peut également être configuré pour supprimer les URL non valides de façon automatique si l’URL reste invalide plus d’un certain temps.

La base de données DB centralise les données et cela par zones géographiques. Comme cela est décrit ci-après en référence aux figures 5 et 6, cette base permet d’alimenter le cache des serveurs de cache. Ces données sont aussi bien mises à jour par intégration des retours des terminaux que par l’utilisation de modèles théoriques.

Le fonctionnement du module 13 d’actualisation de la base de données alimenté par au moins une base de données externe 15, encore appelée base de point de diffusion, est maintenant décrit en référence à la figure 4. Le module 13 comprend un module de management de l’ingestion 13A, un module de calcul des zones de couverture 13B et un module d’ingestion des zones de couverture 13C.

Le module d’ingestion des zones de couverture 13C met à jour la base de données DB en utilisant des cartes de couverture issues du module de calcul des zones de couverture 13B. Les données sont échangées entre les modules sous la forme de l’un au moins des éléments suivants : • image BMP, pour « bitmap » en anglais, géo-localisée où chaque pixel correspond à une zone géographique et ou la valeur de la couleur du pixel donne l’information de qualité de couverture ; • Ensemble de fichiers Shape, comprenant des données de type vectorielles pour caractériser la couverture réseau de chacune des zones géographiques.

Des métadonnées associées aux fichiers comprennent les informations mentionnées ci-avant en référence à la figure 2 qui sont stockées dans la base de données DB.

Le module de calcul de zone de couverture 13B prend en entrée les caractéristiques d’un point de diffusion (position, fréquence, type de modulation, puissance diagramme de l’antenne...) ainsi que la topographie. Il modélise en sortie une carte donnant la qualité de réception autour du point d’émission. Cette carte peut être aux formats mentionnés ci-avant en référence au module d’ingestion des zones de couverture 13C.

Le module 13B produit donc des cartes compatibles avec le format attendu en entrée du module d’ingestion des zones de couverture 13C. La production des cartes de couverture peut nécessiter l’intervention d’un opérateur.

Le module de management de l’ingestion 13A gère la mise à jour de la base de données DB à partir d’une liste de points de diffusion fourni par la base de données externe 15.

Le module 13 A est interfacé avec la base de données externe 15 et doit donc gérer les différences de protocole et formats pour adapter les données avant de les envoyer au module de calcul de zone de couverture 13B

Le module de management de l’ingestion 13A peut contenir une base de données stockant les résultats des dernières requêtes effectuées. Cette base permet alors de déterminer les modifications entre les résultats à une même requête. Seuls seront traités les points de diffusion ayant évolués (ajoutés, supprimés ou modifiés). Ce module peut être remplacé par un opérateur dans le cas où le nombre de cartes à produire n’est pas suffisamment important.

Son fonctionnement est maintenant décrit en détail au procédé illustré à la figure 4, les étapes suivantes sont effectuées : A. Le module de management 13A demande, de façon périodique ou sur action d’un opérateur, la liste des points référencés dans la base de point de diffusion 15. La requête d’obtention REQ UPDT de la liste des points de diffusion peut être adaptée afin d’obtenir la liste des points uniquement pour une radio ou une ville. B. La base 15 retourne la liste UPDT des points de diffusion liés à la requête. C. Le module de management 13A analyse le résultat afin d’obtenir la liste des points de diffusion ayant évolués par rapport au résultat retourné lors de la dernière exécution de cette même requête. Les évolutions sont ensuite traitées de façon synchrone ou asynchrone aux étapes suivantes. D. Le module de management 13A envoie au module de calcul 13B les données PI nécessaires pour produire les cartes de couverture. E. Le module de calcul 13B produit la ou les cartes de couvertures CART. F. Le module de calcul envoie les nouvelles cartes CART et les métadonnées associées au module d’ingestion. G. Le module d’ingestion 13C met à jour la base de données DB en fonction des nouvelles cartes CART envoyées par le module de calcul 13B. Le processus de mise à jour est choisi en fonction du format (bmp ou shape) des cartes envoyées par le module de calcul. Le traitement d’une carte est terminé lorsque l’ensemble des éléments (pixel pour bmp ou shape) qu’elle contient a été mis à jour dans la base de données DB.

H. Le module d’ingestion 13C notifie de la fin de traitement de la carte liée au point PL I. Le module de calcul 13B notifie de la fin de traitement du point PL Le module de management peut alors initier le traitement du point suivant.

Il est ici précisé que le traitement des points de diffusion peut également être réalisé de façon asynchrone. Les étapes H et I sont alors inutiles.

Il est également précisé que le présent procédé de mise à jour de la base de données DB peut être mis en œuvre indépendamment du procédé apte à informer un terminal sur la disponibilité d’au moins un réseau apte à diffuser sur le terminal un contenu multimédia à l’endroit où est localisé le terminal, décrit ci-avant notamment en référence à la figure 2.

La figure 5 illustre un contexte d’utilisation de l’invention, selon un mode de réalisation. De nombreux terminaux UE1 à UE15 cherchent à effectuer des requêtes vers le système de traitement SYST.

Un procédé de répartition de charge utilisé pour répondre à toutes ces requêtes est maintenant décrit en référence à la figure 6A. Les différents dispositifs impliqués dans la mise en œuvre de ce procédé sont également décrit en référence à la figure 6B. A une étape 3, le terminal UE émet la requête REQ comprenant une information GPS de localisation du terminal pour avoir accès à un contenu. Ce contenu correspond par exemple aux données LIST relatives audit réseau disponible détecté décrites ci-avant en référence aux figures 2 et 3.

Comme décrit ci-avant dans le détail en référence aux figures 2 et 3, la requête vise en particulier à obtenir un accès à un contenu dédié à la zone géographique dans laquelle est situé le terminal, dite zone géographique du terminal. Le terminal peut toutefois ignorer que le contenu auquel il souhaite avoir accès est dédié à la zone géographique du terminal et cette information (contenu dédié) peut ne pas être comprise dans la requête.

La requête peut également demander à avoir accès à un contenu dédié à la zone géographique du terminal, sans que cette zone géographique soit connue du terminal. Il faut ici bien faire la distinction entre la zone géographique du terminal et l’information de localisation du terminal. L’information de localisation du terminal correspond à une mesure objective de la localisation du terminal, telle que des coordonnées GPS, un couple latitude longitude, etc. La zone géographique du terminal est comprise sur un territoire dont le maillage en zones géographiques n’est pas nécessairement connu des terminaux. Comme cela est détaillé ci-après, l’association entre l’information de localisation du terminal et la zone géographique du terminal peut être faite au niveau d’un proxy inverse 191. En variante, le terminal peut connaître le maillage et ainsi directement envoyer un identifiant de la zone géographique du terminal dans la requête.

Dans l’exemple de contenu correspondant aux données LIST relatives audit réseau disponible décrites ci-avant en référence aux figures 2 et 3, le contenu est dédié à la zone géographique du terminal car les données LIST décrivent des réseaux spécifiquement disponibles dans la zone géographique du terminal.

La requête est alors reçue à une étape 28 par un répartiteur de charge global 18. Le répartiteur 18 a pour fonction de choisir un proxy inverse parmi les proxys inverses 191, 192, ..., 19N (avec N un entier). La sélection du proxy peut être faite en fonction de divers critères : un choix systématique (proxy 191 par exemple) peut être appliqué, un choix en fonction de la charge de chacun des proxys, etc. Une fois la sélection du proxy inverse effectuée, la requête est transmise au proxy inverse sélectionné.

On suppose ici que le proxy inverse 191 est sélectionné, il reçoit la requête à une étape 29. A une étape 30, le proxy inverse détermine la zone géographique dans laquelle est située le terminal, appelée zone géographique du terminal. Cette zone géographique peut être déterminée à partir de l’information de localisation (mesure GPS typiquement) comprise dans la requête. Elle peut également être directement extraite de la requête si le terminal avait connaissance du maillage du territoire en zones géographiques. On utilise ensuite la référence Zi pour désigner la zone géographique du terminal.

Une fois la zone Zi déterminée, le proxy inverse 191 cherche à une étape 31 un répartiteur de charge géolocalisé 201 apte à répartir la charge entre P (P entier) serveurs de caches 2111 à 21 IP. On appelle deuxième pluralité de serveurs de cache les P serveurs de caches 2111 à211P. Ces P serveurs de caches sont compris dans une première pluralité de serveurs de cache. La première pluralité de serveurs de cache correspond à tous les serveurs de cache disponibles pour le territoire (sur la figure 3 serveurs 2111 à 21 IP et serveurs 21M1 à 21MQ, M et Q entiers). Le répartiteur de charge géolocalisé 201 ainsi que la deuxième pluralité de serveurs de cache 2111 à 21 IP sont dédiés à couvrir la zone géographique Zi. D’autres répartiteurs de charge géolocalisés, tels que le répartiteur 20M, couvrent d’autres zones géographiques. La requête est ensuite transmise à une étape 32 au répartiteur de charge géolocalisé 201.

Le répartiteur de charge géolocalisé 201 sélectionne ensuite, à une étape 33, un serveur de cache apte à traiter la requête. De la même manière que pour le répartiteur de charge global, cette sélection peut être effectuée en fonction de critères variés comme le critère fondé sur l’appréciation de la charge des serveurs de cache. Une fois le serveur de cache sélectionné (on suppose ici que le serveur 2111 est sélectionné), la requête est transmise puis reçue par le serveur 2111 à une étape 4. A un test 35, il est vérifié que le contenu dont l’accès est demandé par la requête est bien disponible au niveau du serveur de cache 2111. En effet, comme expliqué ci-avant, le serveur de cache stocke préférentiellement les contenus les plus fréquemment demandés. Les requêtes orientés vers le serveur de cache 2111 étant émise depuis des terminaux situés dans la zone géographique spécifiquement couverte par le serveur de cache 2111, notamment, les probabilités que le contenu soit bien présent dans le serveur de cache sont élevées. Si le contenu est présent dans le serveur de cache 2111, la requête est traitée et le contenu envoyé par le serveur de cache 2111 à une étape 37. Si le contenu n’est pas présent, la requête est transférée à la base de données 10 qui traite la requête est envoie le contenu.

Pour chaque zone géographique parmi la pluralité de zones géographiques, un serveur de mise à jour, à partir de la base de données DB, du contenu dédié à ladite zone géographique peut être prévu. Par exemple, pour la zone géographique du terminal, le serveur de mise à jour 221 peut être prévu. Ce serveur de mise à jour utilisé pour la mise à jour de la deuxième pluralité de serveurs de cache 2111 à 211P. Les étapes suivantes sont mises en œuvre par le serveur de mise à jour 221 pour mettre à jour la deuxième pluralité de serveurs de cache 2111 à 21 IP : - recherche dans la base de données DB d’au moins une modification du contenu dédié à ladite zone géographique du terminal Z\ ; - sur détection d’une modification, extraction du contenu modifié depuis la base de données DB vers le serveur de mise à jour 221 ; - transmission à la deuxième pluralité de serveurs de cache 2111 à 21 IP d’une requête de mise à jour comprenant le contenu modifié.

Les étapes de mise à jour susmentionnées peuvent être mise en œuvre cycliquement ou sur réception d’une requête de mise à jour.

Il est ici précisé qu’on entend par système de répartition le système comprenant tout type de dispositif apte à effectuer la répartition des requêtes entre les serveurs de cache. En particulier, par rapport aux références de la figure 6B décrites ci-avant, le système de répartition comprend au moins un élément parmi le répartiteur de charge global 18, les proxys inverses 191, 192, ..., 19N, les répartiteurs de charge géolocalisés 201, ..., 20M, les serveurs de mise à jour 221, ..., 22M, les serveurs de cache 2111 à 21 IP ; ... ; 21M1 à 21MQ.

Il est ici précisé que le présent procédé de répartition de charge peut être mis en œuvre indépendamment du procédé apte à informer un terminal sur la disponibilité d’au moins un réseau apte à diffuser sur le terminal un contenu multimédia à l’endroit où est localisé le terminal, décrit ci-avant notamment en référence à la figure 2.

Pour effectuer les étapes susmentionnées du procédé selon l’invention, chaque dispositif UE, ..., 22M décrit ci-avant comprend au moins un microcontrôleur dont le détail est ici décrit en référence à la figure 7.

Ce microcontrôleur peut prendre la forme d’un boîtier comprenant des circuits imprimé, de tout type d’ordinateur ou encore d’un téléphone mobile.

Le microcontrôleur comprend une mémoire vive 26 pour stocker des instructions pour la mise en œuvre par un processeur 25 des étapes du procédé décrit ci-avant en référence aux figures 2 et 3, notamment. Le microcontrôleur peut aussi comporter une mémoire de masse 27 pour le stockage de données destinées à être conservées après la mise en œuvre du procédé.

Le microcontrôleur peut en outre comporter un processeur de signal numérique (DSP) 24. Ce DSP reçoit les données de déperdition pour mettre en forme, démoduler et amplifier, de façon connue en soi ces données.

Le microcontrôleur comporte également une interface d’entrée 23 pour la réception de paramètres et données pour la mise en œuvre du procédé et une interface de sortie 280.

La présente invention ne se limite pas aux formes de réalisation décrites ci-avant à titre d’exemples ; elle s’étend à d’autres variantes.

Ainsi, on a décrit ci-avant un mode de réalisation dans lequel le contenu multimédia diffusé était une radio. Tout type de contenu multimédia comme une chaîne de télévision, un fichier texte ou des données binaires sont toutefois couverts par la présente invention.

De plus, on a décrit ci-avant un mode de réalisation dans lequel les étapes de mise à jour des serveurs de cache étaient mises en œuvre pour un procédé de répartition de charge spécifique. Ces étapes de mise à jour peuvent toutefois être mises en œuvre indépendamment de ce procédé, pour mettre à jour tout type de serveur de cache.

En outre, on a décrit ci-avant un mode de réalisation dans lequel Tinformation de localisation du terminal correspondait à l’endroit où le terminal était physiquement situé. Cette information de localisation du terminal peut toutefois correspondre à une localisation définie par le terminal, qui ne correspond pas physiquement à l’endroit où est localisé le terminal. Ainsi, l’information de localisation du terminal peut par exemple correspondre à une localisation choisie par le terminal et/ou l’utilisateur du terminal.

Claims (10)

1. Revendications

   1. Procédé de traitement par un système de répartition de charge, le procédé étant apte à répartir entre une première pluralité de serveurs de cache (2111 ; ... ; 21 IP ; 21M1 ; ... ; 21MQ) la charge imposée par une pluralité de requêtes, respectivement émises par une pluralité de terminaux (UE1 ; ... ; UE15) répartis sur une pluralité de zones géographiques (Zi ; Zm), au moins un serveur de cache, parmi la première pluralité de serveurs de cache, stockant, pour chaque zone géographique parmi la pluralité de zones géographiques, au moins un contenu dédié à ladite zone géographique, le procédé comprenant l’exécution, par le système de répartition, des étapes suivantes : - réception (29) d’une requête, émise par un terminal (UE), d’accès à un contenu dédié à la zone géographique, dite zone géographique du terminal (Zi), dans laquelle le terminal est localisé, la requête comprenant une information de localisation du terminal ; - recherche (30 ; 31), à partir de l’information de localisation du terminal, d’au moins un serveur de cache stockant le contenu dédié à la zone géographique du terminal parmi la première pluralité de serveurs de cache ; - sur détection du serveur de cache (2111) stockant le contenu dédié à la zone géographique du terminal, transmission (32) de la requête vers le serveur de cache détecté.
2. 2. Procédé selon la revendication 1, dans lequel l’étape de recherche d’au moins un serveur de cache comporte les sous-étapes de : - détermination (30) d’une zone géographique parmi la pluralité de zones géographiques correspondant à l’information de localisation du terminal, la zone géographique déterminée correspondant à ladite zone géographique du terminal ; - détermination (31) dudit au moins un serveur de cache stockant le contenu dédié à partir de la zone géographique déterminée, correspondant à la zone géographique du terminal.
3. 3. Procédé de traitement selon la revendication 2, dans lequel le système de répartition comporte, pour chaque zone géographique parmi la pluralité de zones géographiques, un serveur de répartition de charge dédié à ladite zone géographique, et dans lequel une deuxième pluralité de serveurs de cache (2111 ; ... ; 21 IP), comprise dans la première pluralité de serveurs de cache, est déterminée à partir de la zone géographique du terminal, le procédé comportant en outre, postérieurement à l’étape de détermination, les étapes de : - orientation (32) de la requête vers un serveur de répartition de charge (201) dédié à la zone géographique du terminal, le serveur de répartition de charge répartissant la charge sur la deuxième pluralité de serveurs de cache ; - sélection (33) par le serveur de répartition de charge dédié à la zone géographique du terminal, d’un serveur de cache parmi la deuxième pluralité de serveurs de cache ; - transmission de la requête vers le serveur de cache sélectionné.
4. 4. Procédé selon la revendication 3, dans lequel le système de répartition comporte, pour chaque zone géographique parmi la pluralité de zones géographiques, un serveur de mise à jour, à partir d’une base de données, du contenu dédié à ladite zone géographique, comportant en outre les étapes, mises en œuvre par le serveur de mise à jour (221) dédié à la zone géographique du terminal, de : - recherche dans la base de données d’au moins une modification du contenu dédié à ladite zone géographique du terminal ; - sur détection d’une modification, extraction du contenu modifié depuis la base de données vers le serveur de mise à jour ; - transmission à la deuxième pluralité de serveurs de cache d’une requête de mise à jour comprenant le contenu modifié.
5. 5. Procédé selon la revendication 4, dans lequel la recherche d’une modification est effectuée cycliquement par le serveur de mise à jour dédié à la zone géographique du terminal.
6. 6. Procédé selon l’une des revendications 3 à 5, dans lequel le serveur de cache sélectionné est celui présentant, à l’instant où la sélection est faite, la charge la plus faible parmi la deuxième pluralité de serveurs de cache.
7. 7. Procédé selon l’une des revendications précédentes, comportant en outre, préalablement à l’étape de réception de la requête par le système de répartition, les étapes de : - acquisition de coordonnées de géo-positionnement par satellite, GPS ; - approximation des coordonnées pour l’obtention d’une approximation correspondant à l’information de localisation du terminal.
8. 8. Système de répartition de charge apte à répartir entre une première pluralité de serveurs de cache la charge imposée par une pluralité de requêtes, respectivement émises par une pluralité de terminaux répartis sur une pluralité de zones géographiques, au moins un serveur de cache, parmi la première pluralité de serveurs de cache, stockant, pour chaque zone géographique parmi la pluralité de zones géographiques, au moins un contenu dédié à ladite zone géographique, le système de répartition comprenant : - un récepteur (23) pour la réception d’une requête, émise par un terminal, d’accès à un contenu dédié à la zone géographique, dite zone géographique du terminal, dans laquelle le terminal est localisé, la requête comprenant une information de localisation du terminal ; - un processeur (25) apte à chercher, à partir de l’information de localisation du terminal, au moins un serveur de cache stockant le contenu dédié à la zone géographique du terminal parmi la première pluralité de serveurs de cache ; - un transmetteur (280) pour, sur détection du serveur de cache stockant le contenu dédié à la zone géographique du terminal, transmettre de la requête vers le serveur de cache détecté.
9. 9. Terminal (UE) apte à transmettre la requête d’accès à un contenu dédié à la zone géographique du terminal envoyée au système de répartition selon la revendication 8.
10. 10. Serveur de répartition de charge dédié à ladite zone géographique et compris dans le système de répartition de charge selon la revendication 8, le serveur de répartition de charge étant à apte à répartir la charge sur une deuxième pluralité de serveurs de cache, la deuxième pluralité de serveurs de cache, comprise dans la première pluralité de serveurs de cache, étant déterminée à partir de la zone géographique du terminal, le serveur de répartition de charge comprenant : - un récepteur (23) pour recevoir la requête ; - un processeur (25) apte à sélectionner un serveur de cache parmi la deuxième pluralité de serveurs de cache ; - un transmetteur (280) pour transmettre la requête vers le serveur de cache sélectionné.