FR3029057A1

FR3029057A1 - Procede de diffusion et synchronisation de donnees dans un reseau mobile opportuniste

Info

Publication number: FR3029057A1
Application number: FR1402622A
Authority: FR
Inventors: Farid Benbadis; Jeremie Leguay; Vania Conan; Florian Cosnier
Original assignee: Thales SA
Current assignee: Thales SA
Priority date: 2014-11-21
Filing date: 2014-11-21
Publication date: 2016-05-27
Anticipated expiration: 2034-11-21
Also published as: FR3029057B1

Abstract

L'invention propose un procédé de diffusion de données et un procédé de synchronisation de données qui permettent l'échange de contenus multimédia via toute application logicielle en exploitant au mieux les ressources de communication en mode infrastructure et en mode ad-hoc.

Description

1 Procédé de diffusion et synchronisation de données dans un réseau mobile opportuniste L'invention concerne le domaine de la distribution de contenus multimédia au sein d'un réseau hétérogène comportant des terminaux mobiles qui peuvent être connectés de manière intermittente à un serveur de contenu au travers d'un réseau d'infrastructure mais qui peuvent également être connectés directement entre eux lorsqu'ils sont en portée radio.

L'invention porte sur un procédé de diffusion et de synchronisation de données dans un réseau mobile opportuniste qui peut fonctionner alternativement en réseau d'infrastructure ou en réseau ad hoc. L'invention est implémentée en tant qu'interface de programmation logicielle pour des applications logicielles destinées à diffuser des contenus 15 multimédia, par exemple des contenus audio, vidéos, texte, ou encore des messages de groupe ou des positions de géolocalisation. Dans les réseaux mobiles opportunistes, la connectivité des terminaux avec l'infrastructure ou avec les autres terminaux peut être intermittente, ce 20 qui perturbe le fonctionnement des applications logicielles embarquées sur les terminaux. Un réseau mobile peut être hétérogène, c'est-à-dire que les terminaux mobiles du réseau peuvent être équipés d'un système de communication par réseau d'infrastructure, par exemple un système LTE (Long Term Evolution), 25 mais aussi d'un système de communication en mode ad-hoc tel que le système Wifi. Ces deux modes de communication peuvent être utilisés pour se connecter à un réseau d'infrastructure mais la connectivité peut être dégradée voir interrompue lorsque par exemple les conditions de 30 propagations sont difficiles, l'élongation radio trop grande ou la vitesse du terminal trop élevée. Par ailleurs, le système WiFi en mode ad-hoc peut être 3029057 2 utilisé pour établir des communications directes entre les terminaux. Ces opportunités de communication ne peuvent exister que si les noeuds sont en portée et bénéficient d'une bonne liaison radio. Ces communications ont généralement une durée de vie plus courte que celles passant par 5 l'infrastructure à cause de la mobilité des terminaux et de la portée radio plus faible. Dans le contexte de connectivité des réseaux mobiles opportunistes, l'implémentation de services de données n'est pas optimale. En effet, les applications mobiles sont généralement constituées d'un client, embarqué 10 sur un terminal mobile, et d'un serveur hébergé dans un serveur d'infrastructure. Chaque application logicielle doit donc être adaptée spécifiquement pour gérer les déconnections sur le lien d'infrastructure entre le serveur et le terminal mobile. Par ailleurs lorsque le terminal retrouve de la connectivité avec le serveur, les applications logicielles essaient de 15 manière non coordonnée d'échanger des données avec leurs serveurs respectifs, ce qui pose des problèmes de congestion et peut être inefficace lorsque les opportunités de communication sont de courtes durées. Un problème existe donc pour gérer, de façon transparente pour une 20 application logicielle, les ruptures de connectivité avec un serveur d'infrastructure en utilisant les fonctionnalités de communication en mode ad-hoc disponibles sur les terminaux mobiles. Les applications logicielles doivent pouvoir diffuser, synchroniser, mettre à jour leur contenu quel que soit l'état de la connectivité entre le 25 terminal et le réseau d'infrastructure et en utilisant au mieux les ressources de communication disponibles. Les références [1], [2] et [3] décrivent plusieurs méthodes de diffusion de contenus dans des réseaux hétérogènes mais ces méthodes présentent 30 l'inconvénient de ne pas permettre une gestion transparente pour 3029057 3 l'application logicielle des pertes de connectivité avec le réseau d'infrastructure. L'invention propose un procédé de diffusion de données et un procédé 5 de synchronisation de données qui permettent l'échange de contenus multimédia via toute application logicielle en exploitant au mieux les ressources de communication en mode infrastructure et en mode ad-hoc. L'invention a pour objet un procédé, exécuté par un terminal client, de 10 synchronisation de données multimédia organisées au sein d'un flux de données multimédia appartenant à une application logicielle et comprenant une pluralité d'entrées, ledit terminal client étant apte à communiquer avec un serveur d'infrastructure selon un mode de communication infrastructure et apte à communiquer avec au moins un autre terminal selon un mode de communication ad-hoc, ledit procédé comprenant les étapes suivantes : - Recevoir une information relative à la connectivité entre le terminal client et un serveur d'infrastructure, - Si la connectivité avec le serveur d'infrastructure est établie, transmettre au serveur d'infrastructure une requête de synchronisation de contenus pour récupérer au moins une nouvelle entrée d'un flux de données, - Si la connectivité avec le serveur d'infrastructure est inexistante, rechercher au moins un terminal mobile, dit terminal serveur, ayant une connectivité établie avec ledit terminal client, o Recevoir dudit terminal serveur une liste de flux de données auxquels ledit terminal serveur est abonné, o Transmettre audit terminal serveur une requête de synchronisation de contenus pour récupérer au moins une nouvelle entrée d'un flux de données auquel ledit terminal client et ledit terminal serveur sont abonnés, 3029057 4 - Recevoir, de la part du serveur d'infrastructure ou du terminal serveur, au moins une entrée appartenant audit flux de données conformément à ladite requête de synchronisation de contenus.

5 Selon un aspect particulier du procédé de synchronisation de données selon l'invention, l'étape de transmission au serveur d'infrastructure ou au terminal serveur d'une requête de synchronisation de contenus est exécutée successivement à la réception d'une notification émise par le serveur d'infrastructure ou le terminal serveur, informant de la mise à jour d'un flux de 10 données auquel ledit terminal client est abonné. Selon un aspect particulier du procédé de synchronisation de données selon l'invention, l'étape de transmission au serveur d'infrastructure d'une requête de synchronisation de contenus est exécutée successivement à la réception d'une information de rétablissement de connectivité entre le 15 terminal client et le serveur d'infrastructure. Selon un aspect particulier du procédé de synchronisation de données selon l'invention, la requête de synchronisation de contenus contient un identifiant du terminal client. Selon un aspect particulier du procédé de synchronisation de données 20 selon l'invention, la requête de synchronisation de contenus contient une information sur la position géographique du terminal client. L'invention a également pour objet un procédé, exécuté par un terminal mobile dit terminal serveur, de diffusion de données multimédia 25 organisées au sein d'un flux de données multimédia appartenant à une application logicielle et comprenant une pluralité d'entrées, ledit terminal mobile étant apte à communiquer avec un serveur d'infrastructure selon un mode de communication infrastructure et apte à communiquer avec au moins un autre terminal selon un mode de communication ad-hoc, ledit procédé 30 comprenant les étapes : 3029057 - Créer au moins une nouvelle entrée appartenant à un flux de données préalablement créé, - Recevoir une information relative à la connectivité entre le terminal serveur et un serveur d'infrastructure, 5 - Si la connectivité avec le serveur d'infrastructure est établie, transmettre au serveur d'infrastructure au moins une nouvelle entrée créée par le terminal serveur ou reçue par un autre terminal, - Si la connectivité avec le serveur d'infrastructure est inexistante, 10 rechercher les terminaux mobiles, dits terminaux clients, ayant une connectivité établie avec ledit terminal serveur et, - Transmettre aux dits terminaux clients une liste de flux de données auxquels ledit terminal serveur est abonné, - Recevoir, de la part d'au moins un terminal client, une 15 requête de synchronisation de contenus pour récupérer au moins une nouvelle entrée d'un flux de données auquel ledit terminal serveur et ledit terminal client sont abonnés, - Transmettre, audit terminal client abonné, au moins une entrée appartenant audit flux de données conformément à 20 ladite requête de synchronisation de contenus. L'invention a encore pour objet un procédé, exécuté par un serveur d'infrastructure, de diffusion de données multimédia organisées au sein d'un flux de données multimédia appartenant à une application logicielle et 25 comprenant une pluralité d'entrées, ledit serveur d'infrastructure étant apte à communiquer avec au moins un terminal mobile selon un mode de communication infrastructure, ledit procédé comprenant les étapes suivantes : - Recevoir au moins une nouvelle entrée appartenant à un flux de 30 données préalablement créé, 3029057 6 - Recevoir, de la part d'au moins un terminal client abonné audit flux de données, une requête de synchronisation de contenus pour récupérer au moins une nouvelle entrée dudit flux, - Transmettre, audit terminal client abonné, au moins une entrée 5 appartenant audit flux de données conformément à ladite requête de synchronisation de contenus. Selon un aspect particulier du procédé de diffusion de données multimédia selon l'invention, ledit procédé comprend en outre l'étape suivante : 10 - Lorsqu'un terminal client rétabli une connectivité avec le serveur d'infrastructure après une perte de connectivité, notifier ledit terminal client de la mise à jour dudit flux de données pendant la période durant laquelle la connectivité était perdue. Selon un aspect particulier du procédé de diffusion de données 15 multimédia selon l'invention, la réception d'une nouvelle entrée provient d'un serveur de contenus ou d'un terminal mobile ayant une connectivité établie avec le serveur d'infrastructure. Selon un aspect particulier du procédé de diffusion de données multimédia selon l'invention, ledit procédé comprend en outre l'étape 20 suivante exécutée après la réception ou la création d'au moins une nouvelle entrée appartenant à un flux de données préalablement créé : - Notifier tous les terminaux clients ayant une connectivité établie avec le serveur d'infrastructure ou le terminal serveur et abonnés audit flux de données, de la mise à jour dudit flux de données.

25 Selon un aspect particulier du procédé de diffusion de données multimédia selon l'invention, la notification vers un terminal client n'est exécutée que si, à l'instant où le flux de données est mis à jour, toutes les transmissions précédentes d'entrées vers ce terminal client sont achevées. Selon un aspect particulier du procédé de diffusion de données 30 multimédia selon l'invention, la notification et la transmission d'entrées vers un terminal client ne sont exécutées que pour des terminaux clients 3029057 7 appartenant à une liste de clients autorisés et/ou dont la position géographique est comprise dans une zone géographique donnée. Selon un aspect particulier de l'invention, la requête de synchronisation de contenus comporte la requête des N dernières entrées 5 ajoutées au flux, N étant un nombre entier supérieur à un. Selon un aspect particulier de l'invention, la requête de synchronisation de contenus comporte la requête de toutes les entrées ajoutées depuis une date donnée. Selon un aspect particulier de l'invention, la requête de 10 synchronisation de contenus comporte la requête d'au moins une entrée d'un type multimédia prédéfini. Selon un aspect particulier de l'invention, la requête de synchronisation de contenus comporte la requête de toutes les entrées ajoutées à un flux depuis la dernière requête de synchronisation de contenus 15 à ce flux transmise par le terminal émetteur de ladite requête. Selon un aspect particulier de l'invention, lesdits procédés sont implémentés par une interface de programmation avec une application logicielle. L'invention a également pour objet un terminal mobile comprenant une 20 base de données contenant au moins un flux de données multimédia appartenant à une application logicielle et comprenant une pluralité d'entrées, des premiers moyens de communication pour communiquer avec un serveur d'infrastructure selon un mode de communication infrastructure, des seconds moyens de communication pour communiquer avec un autre 25 terminal mobile selon un mode de communication ad-hoc et un processeur configuré pour exécuter le procédé de synchronisation de données et le procédé de diffusion de données multimédia selon l'invention. L'invention a également pour objet un serveur d'infrastructure comprenant une base de données contenant au moins un flux de données 30 multimédia appartenant à une application logicielle et comprenant une pluralité d'entrées, des moyens de communication pour communiquer avec 3029057 8 un terminal mobile selon un mode de communication ad-hoc et un processeur configuré pour exécuter le procédé de diffusion de données multimédia selon l'invention. L'invention a également pour objet un programme d'ordinateur 5 comportant des instructions pour l'exécution du procédé de synchronisation de données et du procédé de diffusion de données multimédia selon l'invention. D'autres caractéristiques et avantages de la présente invention 10 apparaîtront mieux à la lecture de la description qui suit en relation aux dessins annexés qui représentent : Les figures la-1f, plusieurs schémas illustrant le principe général de fonctionnement de l'invention, La figure 2, un synoptique de l'architecture du logiciel selon l'invention 15 implémenté dans un serveur d'infrastructure d'une part et dans un terminal mobile d'autre part, La figure 3, un diagramme illustrant, selon un premier aspect de l'invention, les échanges intervenant entre un serveur d'infrastructure et plusieurs terminaux clients, 20 La figure 4, un diagramme illustrant, selon un deuxième aspect de l'invention, les échanges intervenant entre deux terminaux clients lorsque la connectivité avec le serveur d'infrastructure est rompue, La figure 5, un diagramme illustrant, selon un troisième aspect de l'invention, les échanges intervenant entre un serveur d'infrastructure 25 et plusieurs terminaux clients lorsque la connectivité avec le serveur d'infrastructure est rétablie suite à une perte de connectivité, Les figures 1a à 1f illustrent le principe général de fonctionnement de l'invention. Des terminaux mobiles T1 ,T2 hébergent une application logicielle 30 apte à communiquer avec un ou plusieurs serveur(s) de contenus qui sont hébergés sur des serveurs d'infrastructure SE1,SE2. Les serveurs de 3029057 9 contenus contiennent des flux de contenus Cl ,C2 auxquels les utilisateurs des terminaux mobiles T1,T2 sont abonnés. Les flux de contenus peuvent contenir tout type de contenus audio, vidéo, texte ou plus généralement tout type de contenu multimédia. Les applications logicielles peuvent être des 5 applications de messagerie ou des applications de diffusion et d'échange de contenus en ligne, par exemple des journaux en ligne ou encore des applications d'édition collaborative de contenus. Les serveurs de contenus sont mis à jour régulièrement. La figure la illustre deux terminaux mobiles T1,T2 abonnés à des flux 10 hébergés par deux serveurs d'infrastructure SE1,SE2. Les terminaux mobiles sont notifiés par les serveurs lorsqu'un nouveau contenu est disponible. La figure lb illustre la synchronisation, par les terminaux mobiles T1,T2, des contenus Cl ,C2 disponibles sur les serveurs SE1,SE2. La figure 1 c illustre la possibilité, pour les utilisateurs, d'enrichir les 15 contenus Cl ,C2 qu'ils viennent de recevoir, par exemple en ajoutant des commentaires textuels COM1,COM2 aux contenus multimédia. La figure 1 d montre la synchronisation automatique des nouveaux contenus COM1,COM2 créés sur les terminaux mobiles T1,T2 pour qu'ils soient acheminés vers les serveurs de contenus SE1,SE2.

20 La figure le illustre le cas d'une rupture de connectivité entre les terminaux T1,T2 et les serveurs d'infrastructure SE1,SE2. Dans ce cas, les terminaux T1,T2 peuvent communiquer entre eux en mode ad-hoc, si ils sont en portée radio l'un de l'autre, et s'échanger leurs contenus ou de nouveaux contenus qu'ils ont créés.

25 La figure If illustre le cas d'une reprise de connectivité entre l'un des terminaux T1 et les serveurs de contenus SE1,SE2. Dans ce cas, le terminal T1 synchronise avec les serveurs les nouveaux contenus qu'il a créés ou qu'il a récupérés depuis le terminal T2 pendant la rupture de connectivité.

30 Les figures la-If montrent le fonctionnement général de l'invention qui permet aux applications des terminaux mobiles T1,T2 de ne pas être 3029057 10 pénalisées du fait de ruptures de connectivités avec les serveurs de contenus. Les flux de contenus hébergés sur les serveurs et sur les terminaux 5 sont composés d'entrées qui peuvent contenir différents contenus multimédias, par exemple des articles, des positions géolocalisées, des commentaires ou encore des pièces jointes, des liens vers d'autres entrées ou encore des attributs géographiques. Les flux de contenus peuvent être organisés à l'air d'une 10 représentation dans un format Atom XML. La figure 2 représente l'architecture logicielle du système selon l'invention. Sur la figure 2 sont représentés schématiquement un serveur 15 d'infrastructure SE1, un premier terminal mobile T1 et un second terminal mobile T2. L'invention est implémentée sous une forme logicielle à la fois dans le serveur d'infrastructure SE1 et dans les terminaux mobiles T1,T2. Plus précisément, elle est implémentée sous la forme d'une interface de 20 programmation logicielle ou API de l'acronyme anglo-saxon « Application Programming Interface » qui vient s'insérer entre une application logicielle de diffusion de contenus et les couches logicielles réseau. L'interface de programmation logicielle selon l'invention est alors commune à plusieurs applications logicielles de diffusion de contenus de natures différentes. Un 25 des avantages de l'invention est de permettre à toute application de diffusion de contenus de paramétrer l'interface de programmation selon l'invention afin de gérer la diffusion et la synchronisation de contenus de manière transparente au sein du réseau et en fonction de l'état des connectivités au sein de ce réseau.

30 3029057 11 L'interface de programmation selon l'invention implémentée sur le serveur d'infrastructure SE1 communique avec une application APP de diffusion de contenus qui est elle-même alimentée par un serveur de contenus. Cette interface de programmation comporte notamment : 5 - une base de données D1 pour stocker les flux de données générés ou reçus par l'application APP, - un module de gestion des contenus C_API qui implémente les échanges de contenus avec les terminaux mobiles T1,T2, gère les notifications et les requêtes, 10 - un module d'administration A_API qui permet d'administrer les contenus en ajoutant, supprimant ou mettant à jour les entrées des flux. Ce module permet aussi d'administrer les types de flux pouvant être lus et modifiés par les terminaux, les droits d'accès sur chaque flux pour des utilisateurs individuels ou en groupe et les politiques de synchronisation de 15 contenus, - un module d'authentification et de configuration AC_API qui a pour rôle d'authentifier les utilisateurs qui souhaitent s'abonner ou avoir accès à un flux et de transmettre aux terminaux authentifiés une mise à jour de leur configuration en termes de droits d'accès et de souscription aux flux.

20 L'interface de programmation implémentée sur un terminal mobile T1 communique également avec une application APP de diffusion de contenus hébergée sur le terminal via un module d'interface APP_API. Cette interface de programmation comporte également : 25 Une base de données D2 pour stocker les flux reçus ou générés par le terminal, Un module de gestion des contenus CSM qui a pour rôle : o L'ajout, la suppression et la mise à jour du contenu dans la base de données D2, 30 o La synchronisation de contenu avec le serveur d'infrastructure SE1, 3029057 12 La synchronisation de contenu entre deux terminaux mobiles en mode direct lorsque le serveur n'est pas en connectivité avec le terminal. Un module d'authentification et de configuration ACM chargé de la 5 communication avec le module correspondant AC API du serveur, Un module de gestion des interfaces radios NM qui permet de communiquer au module de gestion des contenus CSM les ruptures ou établissement de connectivité avec le serveur ou avec d'autres terminaux mobiles. La connectivité entre le terminal T1 et le serveur 10 SE1 est, par exemple, établie par un module de communications LTE. La connectivité entre deux terminaux est, par exemple, établie par un module de communications WIFI. L'architecture logicielle décrite à la figure 2 est donnée à titre illustratif 15 et ne doit pas être interprétée limitativement. Sans sortir du cadre de l'invention, toute autre architecture logicielle permettant de mettre en oeuvre les mêmes fonctionnalités et permettant d'exécuter les procédés de diffusion de contenu et de synchronisation de contenu décrits par la suite peut remplacer l'architecture décrite à la figure 2.

20 La figure 3 décrit le fonctionnement, selon l'invention, des échanges entre un serveur d'infrastructure SE et deux terminaux clients CL_1,CL_2 lorsque la connectivité est établie entre ces deux terminaux et le serveur. Un client administrateur CL_AD associé à l'application de diffusion de 25 contenus gérée crée 101 un flux de contenus et en informe le serveur SE. Le client administrateur CL_AD peut ensuite créer CE des entrées associées à ce flux et les transmettre 104 au serveur pour les ajouter au flux. Les clients CL_1,CL_2 peuvent s'abonner 102,103 à un ou plusieurs flux hébergés par le serveur SE.

30 Le serveur SE implémente une gestion de notifications GN qui est configurée pour générer une notification dès qu'un flux est mis à jour puis 3029057 13 transmettre 105,106 cette notification aux terminaux clients CL_1,CL_2 abonnés au flux. Selon une variante de l'invention, la gestion des notifications GN peut être optionnelle. Dans ce cas, les clients CL_1,CL_2 transmettent 5 directement au serveur SE des requêtes 107,109 de synchronisation de contenus, sinon les requêtes 107,109 ne sont émises que sur réception d'une notification du serveur. Sur réception d'une requête de synchronisation de contenus 107,109, le serveur diffuse 108,110 aux clients CL_1,CL_2 les contenus mis à jour 10 selon la politique de synchronisation qu'ils ont choisi et paramétré. Selon une variante de l'invention, une nouvelle notification informant de la création d'un nouveau contenu n'est émise par le serveur SE que si, à l'instant où le flux de données est mis à jour, toutes les transmissions précédentes d'entrées vers un terminal client abonné sont achevées. Ainsi, 15 on évite les problèmes éventuels de congestion. Les nouvelles entrées associées à un flux peuvent être créées par le client administrateur CL AD ou directement par un terminal client CL_1,CL_2. Dans ce second cas, les nouvelles entrées créées sont transmises par le terminal client au serveur SE pour que le flux soit mis à 20 jour. La figure 4 décrit le fonctionnement de l'invention lorsqu'une perte de connectivité avec le serveur d'infrastructure SE intervient. Les clients CL_1,CL_2 exécutent un test de connectivité TC leur 25 permettant d'une part de détecter l'absence de connectivité avec le serveur d'infrastructure SE et d'autre part d'établir une connectivité en mode ad-hoc avec les terminaux voisins. Lorsqu'une connectivité ad-hoc est établie entre deux terminaux, ils échangent la liste des flux TF1,TF2 auxquels ils sont abonnés.

30 Si un client CL_1 crée CE une nouvelle entrée pour un flux auquel un autre client CL _2 est abonné. Le client CL_1 créateur de l'entrée peut 3029057 14 envoyer directement une notification 201 de mise à jour du flux au client abonné CL_2 qui répond par une requête de synchronisation de contenus 202. Le client CL_1 transmet alors les nouveaux contenus au client CL_2 en fonction de sa politique de synchronisation.

5 Dans l'exemple illustré à la figure 4, le premier client CL_1 agit comme un serveur vis-à-vis du second client CL_2. La figure 5 illustre le fonctionnement de l'invention lors d'une reprise de connectivité de deux terminaux clients CL_1,CL_2 avec le serveur 10 d'infrastructure SE. Lorsque le serveur SE détecte la reprise de connectivité avec les clients CL_1,CL_2, il peut les notifier 301, 305 de la mise à jour des flux auxquels ils sont abonnés pendant la rupture de connectivité. Alternativement, les clients CL_1,CL_2 peuvent également 15 directement, lorsque la reprise de connectivité avec le serveur est détectée, transmettre au serveur une requête de synchronisation de contenus 302,306 qui ont été mis à jour pendant la période de déconnexion. Le serveur transmet 303,307 aux terminaux clients les contenus mis à jour en fonction de leur politique de synchronisation.

20 Un terminal client CL_1 transmet 304 également au serveur les entrées qu'il a créé ou qu'il a récupéré depuis un autre terminal client CL_2 pendant la période de déconnexion avec le serveur. Un problème particulier se pose dans le cas du scénario suivant.

25 Lorsque un premier client CL_1 est déconnecté du serveur SE, il génère un nouveau contenu NC. Ce contenu NC est transmis à un second client CL_2 en mode ad-hoc. Le second client CL_2 se reconnecte ensuite au serveur SE avant le premier client CL_1. Le nouveau contenu NC est transmis du second client CL_2 au serveur SE. Le premier client CL_1 se reconnecte 30 ensuite au serveur SE. Le serveur va alors transmettre, directement ou sur requête du premier client CL_1, le nouveau contenu NC au premier client 3029057 15 CL_1. Dans ce scénario, on voit que le premier client CL_1 va recevoir un contenu qu'il a lui-même créé et qu'il a déjà sauvegardé. En outre, comme ce contenu NC est transmis par le serveur, il possède un identifiant global différent et le premier client CL_1 ne peut donc pas identifier ce contenu NC 5 reçu comme étant un contenu qu'il a déjà sauvegardé. Pour pallier ce problème, une solution consiste à associer à chaque contenu créé par un terminal, un identifiant local. Lorsque le contenu est transmis par un terminal vers le serveur, ce dernier ajoute un identifiant global au contenu. Le contenu possède à la fois un identifiant global et un identifiant local. L'identifiant local permet aux terminaux qui reçoivent ce contenu envoyé par le serveur de vérifier si ils n'ont pas déjà une copie de ce contenu sauvegardé en examinant cet identifiant local. Les requêtes de synchronisation de contenus générées par les 15 terminaux clients peuvent contenir un identifiant du terminal client mais également une information sur la position géographique du terminal client. Ces informations peuvent être utilisées par le serveur, ou par un terminal agissant en tant que serveur, pour gérer les politiques de droit d'accès aux contenus des flux. Par exemple certains terminaux peuvent être interdits 20 d'accès en fonction de leur identifiant ou de leur position géographique. On décrit à présent les différentes variantes de réalisation des requêtes de synchronisation de contenus émises par un terminal vers le serveur d'infrastructure ou vers un autre terminal.

25 Selon une première variante, la requête de synchronisation de contenus contient un nombre N d'entrées souhaitées par le terminal. Autrement dit un terminal peut requérir les N dernières entrées ajoutées au flux. Optionnellement, la requête de synchronisation peut également définir 30 un nombre c maximum de commentaires par entrée que le terminal souhaite requérir. Un avantage de cette première variante est de limiter la quantité de 3029057 16 données à envoyer au terminal pour prendre en compte les contraintes de bande passante. Un autre avantage est de limiter le nombre d'entrées transmises lorsque le terminal se reconnecte au serveur après une longue période de déconnexion.

5 Selon une deuxième variante, la requête de synchronisation de contenus contient une date d passée à partir de laquelle le terminal souhaite recevoir toutes les nouvelles entrées qui ont été ajoutées. Autrement dit, un terminal peut spécifier dans sa requête de 10 synchronisation de contenus qu'il ne souhaite pas recevoir les entrées qui ont été générées avant une date d donnée. Ce mécanisme nécessite de sauvegarder la date de génération de chaque entrée. Un avantage de cette variante est de permettre à l'utilisateur de récupérer uniquement les contenus associés à une date.

15 Selon une troisième variante, la requête de synchronisation de contenus contient un identifiant unique du terminal requêteur. Le serveur garde la trace, pour chaque flux, de la dernière entrée transmise à chaque terminal et peut transmettre à un terminal toutes les entrées qui ont été 20 générées depuis la dernière entrée transmise au terminal. Un avantage de cette variante est de permettre à un utilisateur de récupérer uniquement les contenus qu'il n'a pas déjà reçus. Selon une quatrième variante, la requête de synchronisation de 25 contenus contient un type d'entrée souhaité. Par type d'entrée, on entend la nature du contenu associé à l'entrée, qu'il soit par exemple textuel, audio, image, vidéo ou une combinaison de plusieurs de ces types. Un terminal peut choisir de ne recevoir qu'un seul type de contenu, par exemple uniquement les contenus textuels. Un avantage de cette variante est de 30 prendre en compte les contraintes de bande passante du terminal en limitant les contenus transmis à ceux qui consomment peu de bande passante. Par 3029057 17 exemple, des contenus textuels sont moins consommateurs de débit que les contenus vidéo. Alternativement, le type d'entrée définit dans la requête de synchronisation de contenus peut correspondre au type « maximum » que 5 souhaite recevoir le terminal dans une liste de types ordonnés selon leur besoins en bande passante. Par exemple, la liste des types ordonnés peut être la suivante {texte, audio, image, vidéo). Si le type spécifié dans la requête de synchronisation est le type image, cela signifie que le terminal souhaite recevoir tous les contenus dont le type est inférieur ou égal au type 10 image dans la liste des types ordonnés, autrement dit les contenus de type texte, audio ou image mais pas les contenus vidéo. Toutes les variantes de mise en oeuvre des requêtes de synchronisation décrites ci-dessus peuvent être utilisées séparément ou 15 conjointement avec d'autres variantes. Par exemple, il est possible de combiner un critère de nombre d'entrées maximum souhaité avec un critère de type d'entrée souhaité.

20 3029057 18 Références [1] John Whitbeck, Yoann Lopez, Jérémie Leguay, Vania Conan, Marcelo Dias de Amorim. Push-and-track: Saving infrastructure bandwidth through opportunistic forwarding. Pervasive and Mobile Computing Journal. 2012. 5 [2] Vincent Lenders, Martin May, Gunnar Karlsson, and Clemens Wacha. Wireless ad hoc podcasting. SIGMOBILE Mob. Comput. Commun. Rev., 12(1):65-67, 2008. [3] Julien Haillot, Frédéric Guidec. A Protocol for Content-Based Communication in Disconnected Mobile Ad Hoc Networks. Mobile 10 Information Systems, 2010, 6 (2), pp. 123-154

Claims

REVENDICATIONS1. Procédé, exécuté par un terminal client (CL_1,CL_2), de synchronisation de données multimédia organisées au sein d'un flux de données multimédia appartenant à une application logicielle et comprenant une pluralité d'entrées, ledit terminal client (CL_1,CL_2) étant apte à communiquer avec un serveur d'infrastructure (SE) selon un mode de communication infrastructure et apte à communiquer avec au moins un io autre terminal (CL_1,CL_2) selon un mode de communication ad-hoc, ledit procédé comprenant les étapes suivantes - Recevoir (TC) une information relative à la connectivité entre le terminal client (CL_1,CL_2) et un serveur d'infrastructure (SE), - Si la connectivité avec le serveur d'infrastructure (SE) est établie, 15 transmettre (107,109) au serveur d'infrastructure (SE) une requête de synchronisation de contenus pour récupérer au moins une nouvelle entrée d'un flux de données, - Si la connectivité avec le serveur d'infrastructure (SE) est inexistante, rechercher au moins un terminal mobile, dit terminal 20 serveur (CL_1), ayant une connectivité établie avec ledit terminal client (CL_2), o Recevoir (TF1) dudit terminal serveur une liste de flux de données auxquels ledit terminal serveur (CL_1) est abonné, o Transmettre (202) audit terminal serveur (CL_1) une 25 requête de synchronisation de contenus pour récupérer au moins une nouvelle entrée d'un flux de données auquel ledit terminal client (CL_2) et ledit terminal serveur (CL_1) sont abonnés, - Recevoir (108,110,203), de la part du serveur d'infrastructure (SE) 30 ou du terminal serveur (CL_1), au moins une entrée appartenant 3029057 20 audit flux de données conformément à ladite requête de synchronisation de contenus.
2. Procédé de synchronisation de données selon la revendication 1 dans 5 lequel l'étape de transmission (107,109,202) au serveur d'infrastructure (SE) ou au terminal serveur (CL_1) d'une requête de synchronisation de contenus est exécutée successivement à la réception d'une notification émise (105,106,201) par le serveur d'infrastructure (SE) ou le terminal serveur (CL_1), informant de la mise à jour d'un flux de données auquel io ledit terminal client (CL_1,CL_2) est abonné.
3. Procédé de synchronisation de données selon la revendication 1 dans lequel l'étape de transmission (302,306) au serveur d'infrastructure (SE) d'une requête de synchronisation de contenus est exécutée 15 successivement à la réception (TC) d'une information de rétablissement de connectivité entre le terminal client et le serveur d'infrastructure.
4. Procédé de synchronisation de données selon l'une des revendications 1 à 3 dans lequel la requête de synchronisation de contenus contient un 20 identifiant du terminal client (CL_1,CL_2).
5. Procédé de synchronisation de données selon l'une des revendications 1 à 4 dans lequel la requête de synchronisation de contenus contient une information sur la position géographique du terminal client (CL_1,CL_2). 25
6. Procédé, exécuté par un terminal mobile dit terminal serveur (CL_1), de diffusion de données multimédia organisées au sein d'un flux de données multimédia appartenant à une application logicielle et comprenant une pluralité d'entrées, ledit terminal mobile (CL_1,CL_2) étant apte à 30 communiquer avec un serveur d'infrastructure (SE) selon un mode de communication infrastructure et apte à communiquer avec au moins un 3029057 21 autre terminal (CL_1,CL_2) selon un mode de communication ad-hoc, ledit procédé comprenant les étapes : - Créer (CE) au moins une nouvelle entrée appartenant à un flux de données préalablement créé, 5 - Recevoir (TC) une information relative à la connectivité entre le terminal serveur (CL_1) et un serveur d'infrastructure (SE), - Si la connectivité avec le serveur d'infrastructure (SE) est établie, transmettre (104,304) au serveur d'infrastructure (SE) au moins une nouvelle entrée créée par le terminal serveur (CL_1) ou reçue par un autre terminal (CL_2), - Si la connectivité avec le serveur d'infrastructure (SE) est inexistante, rechercher les terminaux mobiles, dits terminaux clients (CL_2), ayant une connectivité établie avec ledit terminal serveur (CL_1) et, - Transmettre (TF1) aux dits terminaux clients (CL_2) une liste de flux de données auxquels ledit terminal serveur (CL_1) est abonné, - Recevoir (202), de la part d'au moins un terminal client (CL_2), une requête de synchronisation de contenus pour récupérer au moins une nouvelle entrée d'un flux de données auquel ledit terminal serveur (CL_1) et ledit terminal client (CL_2) sont abonnés, - Transmettre (203), audit terminal client abonné (CL_2), au moins une entrée appartenant audit flux de données conformément à ladite requête de synchronisation de contenus.
7. Procédé, exécuté par un serveur d'infrastructure (SE), de diffusion de données multimédia organisées au sein d'un flux de données multimédia appartenant à une application logicielle et comprenant une pluralité d'entrées, ledit serveur d'infrastructure (SE) étant apte à communiquer 3029057 22 avec au moins un terminal mobile (CL_1,CL_2) selon un mode de communication infrastructure, ledit procédé comprenant les étapes suivantes - Recevoir (104) au moins une nouvelle entrée appartenant à un flux 5 de données préalablement créé (101), - Recevoir (107,109), de la part d'au moins un terminal client (CL_1,CL_2) abonné (102,103) audit flux de données, une requête de synchronisation de contenus pour récupérer au moins une nouvelle entrée dudit flux, 10 - Transmettre (108,110), audit terminal client abonné (CL_1,CL_2), au moins une entrée appartenant audit flux de données conformément à ladite requête de synchronisation de contenus.
8. Procédé de diffusion de données multimédia selon la revendication 7 15 comprenant en outre l'étape suivante : - Lorsqu'un terminal client (CL_1,CL_2) rétabli une connectivité avec le serveur d'infrastructure (SE) après une perte de connectivité, notifier (301,305) ledit terminal client de la mise à jour dudit flux de données pendant la période durant laquelle la connectivité était 20 perdue.
9. Procédé de diffusion de données multimédia selon l'une des revendications 7 ou 8 dans lequel la réception (104) d'une nouvelle entrée provient d'un serveur de contenus (CL_AD) ou d'un terminal 25 mobile (CL_1) ayant une connectivité établie avec le serveur d'infrastructure.
10.Procédé de diffusion de données multimédia selon l'une des revendications 6 à 9 comprenant en outre l'étape suivante exécutée 30 après la réception (104) ou la création (CE) d'au moins une nouvelle entrée appartenant à un flux de données préalablement créé : 3029057 23 - Notifier (105,106,201) tous les terminaux clients ayant une connectivité établie avec le serveur d'infrastructure (SE) ou le terminal serveur (CL 1) et abonnés audit flux de données, de la mise à jour dudit flux de données.
11.Procédé de diffusion de données multimédia selon la revendication 10 dans lequel la notification (105,106,201) vers un terminal client (CL_1,CL_2) n'est exécutée que si, à l'instant où le flux de données est mis à jour, toutes les transmissions précédentes d'entrées vers ce 10 terminal client (CL_1,CL_2) sont achevées.
12.Procédé de diffusion de données multimédia selon l'une des revendications 6 à 11 dans lequel la notification (105,106,201) et la transmission (108,110,203) d'entrées vers un terminal client (CL_1,CL_2) 15 ne sont exécutées que pour des terminaux clients appartenant à une liste de clients autorisés et/ou dont la position géographique est comprise dans une zone géographique donnée. 20
13. Procédé de synchronisation de données selon l'une des revendications 1 à 5 dans lequel la requête de synchronisation de contenus comporte la requête des N dernières entrées ajoutées au flux, N étant un nombre entier supérieur à un. 25
14. Procédé de synchronisation de données selon l'une des revendications 1 à 5 dans lequel la requête de synchronisation de contenus comporte la requête de toutes les entrées ajoutées depuis une date donnée.
15. Procédé de synchronisation de données selon l'une des revendications 1 30 à 5 dans lequel la requête de synchronisation de contenus comporte la requête d'au moins une entrée d'un type multimédia prédéfini. 3029057 24
16. Procédé de synchronisation de données selon l'une des revendications 1 à 5 dans lequel la requête de synchronisation de contenus comporte la requête de toutes les entrées ajoutées à un flux depuis la dernière requête de synchronisation de contenus à ce flux transmise par le 5 terminal émetteur de ladite requête.
17. Procédé de synchronisation de données selon l'une des revendications 1 à 5 dans lesquels lesdits procédés sont implémentés par une interface de programmation (API) avec une application logicielle. 10
18.Procédé de diffusion de données multimédia selon l'une des revendications 6 à 12 dans lequel la requête de synchronisation de contenus comporte la requête des N dernières entrées ajoutées au flux, N étant un nombre entier supérieur à un. 15
19.Procédé de diffusion de données multimédia selon l'une des revendications 6 à 12 dans lequel la requête de synchronisation de contenus comporte la requête de toutes les entrées ajoutées depuis une date donnée. 20
20.Procédé de diffusion de données multimédia selon l'une des revendications 6 à 12 dans lequel la requête de synchronisation de contenus comporte la requête d'au moins une entrée d'un type multimédia prédéfini. 25
21.Procédé de diffusion de données multimédia selon l'une des revendications 6 à 12 dans lequel la requête de synchronisation de contenus comporte la requête de toutes les entrées ajoutées à un flux depuis la dernière requête de synchronisation de contenus à ce flux 30 transmise par le terminal émetteur de ladite requête. 3029057 25
22.Procédé de diffusion de données multimédia selon l'une des revendications 6 à 12 dans lesquels lesdits procédés sont implémentés par une interface de programmation (API) avec une application logicielle. 5
23.Terminal mobile (CL_1) comprenant une base de données contenant au moins un flux de données multimédia appartenant à une application logicielle et comprenant une pluralité d'entrées, des premiers moyens de communication pour communiquer avec un serveur d'infrastructure (SE) io selon un mode de communication infrastructure, des seconds moyens de communication pour communiquer avec un autre terminal mobile (CL_2) selon un mode de communication ad-hoc et un processeur configuré pour exécuter le procédé de synchronisation de données et le procédé de diffusion de données multimédia selon l'une des revendications 1 à 6. 15
24. Serveur d'infrastructure comprenant une base de données contenant au moins un flux de données multimédia appartenant à une application logicielle et comprenant une pluralité d'entrées, des moyens de communication pour communiquer avec un terminal mobile selon un 20 mode de communication ad-hoc et un processeur configuré pour exécuter le procédé de diffusion de données multimédia selon l'une des revendications 7 à 9.
25. Programme d'ordinateur comportant des instructions pour l'exécution du 25 procédé de synchronisation de données et du procédé de diffusion de données multimédia selon l'une des revendications 1 à 17 lorsque ledit programme est exécuté par un ordinateur.