WO2008040677A1 - Procédé de gestion de canaux de communication, signal et terminal correspondants - Google Patents
Procédé de gestion de canaux de communication, signal et terminal correspondants Download PDFInfo
- Publication number
- WO2008040677A1 WO2008040677A1 PCT/EP2007/060272 EP2007060272W WO2008040677A1 WO 2008040677 A1 WO2008040677 A1 WO 2008040677A1 EP 2007060272 W EP2007060272 W EP 2007060272W WO 2008040677 A1 WO2008040677 A1 WO 2008040677A1
- Authority
- WO
- WIPO (PCT)
- Prior art keywords
- content
- channel
- request
- terminal
- transmitted
- Prior art date
Links
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
- H04L65/1066—Session management
- H04L65/1101—Session protocols
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/04—Protocols specially adapted for terminals or networks with limited capabilities; specially adapted for terminal portability
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
- H04L65/60—Network streaming of media packets
- H04L65/61—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio
- H04L65/611—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio for multicast or broadcast
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
- H04L65/80—Responding to QoS
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/14—Session management
Landscapes
- Engineering & Computer Science (AREA)
- Multimedia (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Business, Economics & Management (AREA)
- General Business, Economics & Management (AREA)
- Mobile Radio Communication Systems (AREA)
Abstract
L'invention concerne un procédé de gestion de canaux de communication pour la transmission de contenus multimédia d'au moins un serveur (35) vers au moins un terminal de radiocommunication (36). Selon l'invention, un tel procédé comprend les étapes suivantes : - transmission d'un premier contenu (37) dans un premier canal; - restitution progressive dudit premier contenu (37) dans un terminal; - émission par ledit terminal d'une requête (38) pour un deuxième contenu (39), ladite requête (38) comprenant une information de contrôle indiquant si ledit deuxième contenu (39) doit être transmis dans ledit premier canal, ou dans un second canal; - restitution progressive dudit deuxième contenu (39).
Description
Procédé de gestion de canaux de communication, signal et terminal correspondants.
1. Domaine de l'invention
Le domaine de l'invention est celui de la restitution de contenus multimédia sur un terminal de radiocommunication, par exemple de type radiotéléphone, PDA (en anglais « Personal Digital Assistant », en français « assistant numérique personnel »), ordinateur portable, etc.
Plus précisément, l'invention repose sur la transmission d'un contenu multimédia, d'une portion de ce contenu, et/ou d'éléments représentatifs de celui- ci, vers un terminal de radiocommunication, par l'intermédiaire d'un ou plusieurs canaux de transmission.
On entend notamment par contenu multimédia un ensemble composé d'au moins une scène graphique animée, encore appelée scène multimédia, et d'une série de commandes permettant de faire évoluer cette scène d'un état à un autre. Une scène multimédia correspond notamment à l'agencement d'un ensemble d'objets graphiques dans le temps et dans l'espace, avec lesquels l'utilisateur du terminal de radiocommunication peut interagir.
On entend aussi par service multimédia une succession de contenu maintenant pour l'utilisateur une impression de continuité, que cette continuité soit obtenue par mises à jour successives de la même scène multimédia ou par juxtaposition de scènes multimédia successives.
L'invention trouve des applications dans tous les domaines nécessitant une représentation des signaux sous forme d'un agencement spatio-temporel d'objets graphiques, avec interactivité. Notamment, l'invention s'applique aux formats de description de scènes graphiques déjà connus tels que le MPEG-4/BIFS (en anglais « Binary Format Scène », en français « format binaire pour scène »), le SVG (en anglais « Scalable Vector Graphics », en français « graphiques vectoriels adaptables »), le SMIL (en anglais « Synchronized Multimedia Intégration Language », en français « langage d'intégration multimédia synchronisés »), le XHTML (en anglais « extensible
HyperText Markup Language », en français « langage de balisage hypertexte extensible »), etc.
Par exemple, l'invention trouve des applications lors de l'utilisation de formats de description de scènes graphiques tels que ceux cités précédemment sur des canaux de transmission de type HTTP (« Hyper Text Transport Protocol ») sur TCP/IP (« Transmission Control Protocol / Internet Protocol »), ou RTP (« Real Time Protocol »), et plus généralement sur les types de canaux de transmission utilisés entre autres par les normes DVB (Digital Video Broadcast), DMB (Digital Multimedia Broadcast), 3GPP (Third Génération Partnership Project), OMA (Open Mobile Alliance), etc.. 2. Art antérieur
Des techniques de transmission d'un contenu multimédia vers un terminal de radiocommunication sont déjà connues.
Classiquement, selon une première technique de transmission, la conception d'un service, c'est-à-dire l'offre d'une information à un utilisateur d'un terminal de radiocommunication, met en œuvre le schéma suivant : un contenu initial est envoyé sur le terminal ; l'utilisateur le consomme au fur et à mesure de l'envoi du contenu, et fait une requête ; - un contenu de réponse est alors envoyé sur le terminal de radiocommunication, alors que l'envoi du premier contenu est encore actif. Il y a alors un choix sur le terminal : soit le premier contenu doit être arrêté et le second contenu (contenu de réponse) peut alors utiliser le même canal de transmission que le premier contenu ; soit le premier contenu doit continuer à être reçu et joué en parallèle avec le second contenu.
Le service est donc conçu comme une suite de contenus envoyés au terminal de l'utilisateur en réponse à des requêtes interactives dans un certain
nombre de canaux de transmission. Les techniques connues ne permettent pas de décider, au moment de la réception du contenu réponse, de couper la première communication (transmission du premier contenu) et de réutiliser ce canal, ou d'ouvrir un nouveau canal de communication indépendant pour le contenu réponse.
Par exemple, si l'utilisateur demande un service de téléchargement de musique, le contenu initial envoyé sur le terminal comprend un premier flux de musique.
L'utilisateur le consomme, c'est-à-dire écoute le flux de musique, et fait une requête pour obtenir des informations sur la musique.
Un nouveau contenu de réponse, comprenant les informations demandées, est alors envoyé sur le terminal de radiocommunication.
Selon un premier comportement possible, le canal de transmission du premier contenu est toujours coupé lors de la réception d'un second contenu, ce qui garantit que le terminal n'utilise qu'un seul canal de communication (encore appelé canal de transmission) à la fois. Cependant, un inconvénient de ce comportement est qu'il ne permet pas de mettre en œuvre des services mixtes de coopération de réseau dont une partie est transmise sur un canal de communication, et une autre partie est simultanément transmise sur un autre canal de communication, ce second canal pouvant être d'un autre type que le premier. Par conséquent, ce comportement est particulièrement adapté aux terminaux très contraints qui ne permettent pas d'ouvrir plus d'un canal de communication à la fois.
Selon un deuxième comportement possible, le premier canal de communication est toujours maintenu ouvert lors de la réception du second contenu, ce qui permet de mettre en œuvre des services utilisant la coopération de réseaux, dont une partie est transmise sur un canal de communication, et une autre partie est simultanément transmise sur un autre canal de communication, ce second canal pouvant être d'un autre type que le premier. Par contre, ce comportement présente des inconvénients majeurs :
il ne permet pas de faire fonctionner un ou plusieurs services sur des terminaux très contraints qui ne permettent pas d'ouvrir plus d'un canal de communication à la fois ; il ne permet pas de couper la communication lors de la réception du second contenu, ce qui force le terminal à consommer le reste du premier contenu.De ce fait, même si le serveur a arrêté d'envoyer des données pour ce premier contenu, les tampons de transmission du réseau sont pleins et plusieurs secondes de contenu vont encore être reçues et donc consommer inutilement des ressources sur le terminal. Le serveur du premier contenu peut aussi être distinct du serveur du second contenu, et donc ne pas être informé de la requête, et par conséquent poursuivre l'envoi jusqu'à la fin initialement prévue du premier contenu.
Selon un troisième comportement possible, la réception du premier contenu est coupée dès l'émission de la requête d'un second contenu, ce qui garantit que le terminal n'utilise qu'un seul canal de communication à la fois.
Cependant, un inconvénient de ce comportement est qu'il ne permet pas de mettre en œuvre des services mixtes de coopération de réseau dont une partie est transmise sur un canal de communication, et une autre partie est simultanément transmise sur un autre canal de communication, ce second canal pouvant être d'un autre type que le premier. Par conséquent, ce comportement est particulièrement adapté aux terminaux très contraints qui ne permettent pas d'ouvrir plus d'un canal de communication à la fois
3. Objectifs de l'invention L'invention a notamment pour objectif de pallier ces inconvénients de l'art antérieur.
Un objectif de l'invention, selon au moins un mode de réalisation, est de mettre en œuvre une telle technique permettant de réutiliser un canal de communication déjà ouvert pour la réception d'un contenu précédent lors de la réception d'un nouveau contenu.
Un autre objectif de l'invention, selon au moins un mode de réalisation, est de mettre en œuvre une telle technique utilisable en particulier sur les terminaux très contraints qui ne permettent pas d'ouvrir plus d'un canal de communication à la fois, pour les services qui peuvent être exécutés sur de tels terminaux. Un autre objectif de l'invention, selon au moins un mode de réalisation, est de mettre en œuvre une technique économe en termes de ressources, garantissant que le terminal n'utilise qu'un seul canal de communication à la fois, pour les services qui peuvent être exécutés dans ces conditions.
Un autre objectif de l'invention, selon au moins un mode de réalisation, est de mettre en œuvre une technique permettant la gestion du nombre de canaux de communication utilisés à chaque instant par le terminal.
Un autre objectif de l'invention, selon au moins un mode de réalisation, est de mettre en œuvre une technique permettant la réutilisation, pour la réception d'un nouveau contenu ou d'une nouvelle portion du contenu, d'un canal particulier parmi les canaux de communication déjà ouverts.
Un autre objectif de l'invention, selon au moins un mode de réalisation, est de mettre en œuvre une telle technique permettant de mettre en œuvre des services utilisant la coopération de réseaux et dont une partie est transmise sur un canal de communication, et une autre partie est simultanément transmise sur un autre canal de communication, ce second canal pouvant être d'un autre type que le premier.
Notamment, l'invention a pour objectif de fournir une telle technique présentant de meilleures performances en termes de fluidité des services au niveau du terminal de radiocommunication.
4. Exposé de l'invention L'invention propose une solution nouvelle qui ne présente pas l'ensemble de ces inconvénients de l'art antérieur, sous la forme d'un procédé de gestion de canaux de communication pour la transmission de contenus multimédia d'au moins un serveur vers au moins un terminal de radiocommunication.
Selon l'invention, un tel procédé comprend les étapes suivantes : - transmission d'un premier contenu dans un premier canal ;
restitution (ou consommation) progressive dudit premier contenu dans un terminal ; émission par ledit terminal d'une requête pour un deuxième contenu, ladite requête comprenant une information de contrôle indiquant si ledit deuxième contenu doit être transmis dans ledit premier canal, ou dans un second canal ; restitution progressive dudit deuxième contenu.
Ainsi, l'invention permet la restitution progressive d'un premier contenu
(par exemple en mode « streaming ») transmis via un premier canal de communication, et la restitution d'un deuxième contenu suite à une requête du terminal, transmis via le premier canal de communication ou via un deuxième canal.
En particulier, ces différents contenus peuvent être transmis par des serveurs distincts, mais à destination d'un même terminal. Il est également important de noter que les différents canaux de communication mis en œuvre peuvent être de différents types (par exemple un canal bidirectionnel téléphonique et un canal monodirectionnel de diffusion).
Ainsi, une requête pour un deuxième contenu comprend une information de contrôle indiquant si le deuxième contenu doit être transmis dans le premier canal, ou dans un second canal, en fonction du type de contenu par exemple. Puis, en réponse à cette requête, le deuxième contenu peut être transmis dans le canal de communication du premier contenu, interrompant ainsi la transmission du premier contenu, ou dans un autre canal de communication.
Par exemple, dans le cadre de terminaux fortement contraints, on peut réutiliser le premier canal de communication pour transmettre le deuxième contenu, évitant ainsi à ces terminaux d'avoir à ouvrir un deuxième canal de communication qui serait de mauvaise qualité.
Selon un mode de réalisation particulier de l'invention, la restitution progressive du premier contenu se poursuit tant qu'une réponse à la requête n'est pas reçue.
L'auteur d'un service peut ainsi concevoir son service de manière à faire patienter un utilisateur du terminal pendant les temps d'attente d'une réponse à une requête, en continuant à présenter sur le terminal le contenu en cours de consommation. Selon un aspect particulier de l'invention, si l'information de contrôle prévoit l'utilisation d'un second canal, les premier et deuxième contenus sont restitués progressivement au moins partiellement de façon simultanée.
Ainsi, le deuxième contenu peut être affiché dans une scène multimédia associée au premier contenu. En particulier, cette scène multimédia peut avoir été modifiée (au moyen des commandes de modification de scène) de façon à améliorer la perception du deuxième contenu : par exemple, le volume sonore associé au premier contenu est diminué lors de la restitution du deuxième contenu.
Selon un autre aspect de l'invention, si l'information de contrôle prévoit l'utilisation du premier canal uniquement, le deuxième contenu est restitué progressivement en remplacement du premier contenu.
De plus, selon une variante, le terminal émet une requête d'interruption de la transmission du premier contenu à destination du serveur correspondant, c'est- à-dire à destination du serveur fournissant le premier contenu au terminal. Selon un mode de réalisation particulier de l'invention, l'information de contrôle est un attribut d'un élément d'une scène multimédia portant un lien vers le serveur transmettant ledit deuxième contenu.
On définit ainsi un nouvel attribut, noté par exemple lsr:ConnectionPipe, permettant d'indiquer si le deuxième contenu doit être transmis dans le premier canal, ou dans un deuxième canal.
On constate que dans le standard HTML (Hyper Text Markup Language), un élément a peut également posséder un nouvel attribut, de type « target ».
Toutefois, il est important de remarquer que cet attribut « target » définit uniquement des aspects relatifs à la restitution. Plus précisément, cet attribut définit l'espace où la réponse à la requête va être présentée, c'est-à-dire l'endroit
dans la scène multimédia où le deuxième contenu va être restitué, mais ne définit pas les conditions de distribution des contenus, et notamment quel canal de communication peut être utilisé.
De même, des paramètres XLink, tels que définis dans les formats LASeR et SAF, définissent également des aspects relatifs à la restitution. Plus précisément, ces paramètres définissent la façon de consommer un deuxième contenu lié à un premier contenu, reçu en réponse à une requête séparée de celle pour le premier contenu (contenu principal).
De nouveau, il est important de noter qu'aucun de ces paramètres ne concerne le mode de distribution ou la gestion des canaux de communication utilisés, comme le propose l'invention selon au moins un mode de réalisation.
En particulier, selon un mode de réalisation particulier de l'invention, ledit attribut peut prendre une des au moins trois valeurs suivantes : nouveau canal ; - canal courant ; identificateur d'un canal prédéterminé.
Par exemple, l'attribut peut prendre la valeur « new » (en français
« nouveau ») pour définir un nouveau canal, ou bien la valeur « current » (en français « courant ») pour définir le canal courant, ou encore utiliser un nom de canal de communication (par exemple « canal X ») pour identifier un canal prédéterminé.
Selon une caractéristique particulière de l'invention, le procédé de gestion met en œuvre une étape d'émission par le terminal d'une requête de fermeture explicite d'un canal de communication ouvert, en le désignant par son identificateur.
En utilisant le format XML, cette requête de fermeture, encore appelée « directive », peut être notée <ClosePipe name= « canal X »/>.
Un autre aspect de l'invention concerne un signal de gestion de canaux de communication pour la mise en oeuvre du procédé de gestion de canaux de communication décrit précédemment. Plus précisément, un tel signal émis par un
terminal de radiocommunication, comprend un champ d'information de contrôle indiquant si un deuxième contenu doit être transmis dans le premier canal, ou dans un second canal de communication.
En particulier, le champ d'information de contrôle peut prendre une des valeurs suivantes : nouveau canal ; canal courant ; identificateur d'un canal prédéterminé.
De plus, un tel signal peut comprendre une requête de fermeture explicite d'un canal de communication ouvert en le désignant par son identificateur.
Encore un autre aspect de l'invention concerne un terminal de radiocommunication destiné à recevoir au moins un contenu multimédia diffusé par au moins un serveur.
Un tel terminal comprend des moyens de : - restitution progressive d'un premier contenu transmis dans un premier canal ;
- émission d'une requête pour un deuxième contenu, ladite requête comprenant une information de contrôle indiquant si ledit deuxième contenu doit être transmis dans ledit premier canal, ou dans un second canal ;
- restitution progressive dudit deuxième contenu.
Un tel terminal est notamment adapté à mettre en œuvre le procédé de gestion des canaux de communication décrit précédemment.
En particulier, un tel terminal comprend des moyens spécifiques permettant de mettre en œuvre indépendamment chaque étape du procédé de gestion des canaux de communication.
Finalement, un autre mode de réalisation de l'invention concerne un ou plusieurs produits programmes d'ordinateur téléchargeables depuis au moins un réseau de communication et/ou enregistrés sur un support lisible par ordinateur et/ou exécutables par un processeur, comprenant des instructions de code de
programme pour la mise en œuvre d'au moins certaines étapes du procédé de gestion des canaux de transmission décrit précédemment.
5. Liste des figures
D'autres caractéristiques et avantages de l'invention apparaîtront plus clairement à la lecture de la description suivante d'un mode de réalisation particulier, donné à titre de simple exemple illustratif et non limitatif, et des dessins annexés, parmi lesquels : les figures IA et IB illustrent respectivement la restitution d'un premier contenu en parallèle à la restitution d'un second contenu dans deux canaux de communication, et la restitution d'un second contenu suite à l'interruption de la restitution d'un premier contenu dans un même canal de communication ; la figure 2 illustre un exemple d'ouverture et de fermeture d'un second canal de communication selon un mode de réalisation particulier de l'invention ; la figure 3 présente le principe général de l'invention, selon lequel un premier contenu, puis un deuxième contenu sont transmis à un terminal de radiocommunication, suite à une requête du terminal ; la figure 4 illustre les différentes étapes mises en œuvre selon un mode de réalisation particulier de l'invention.
6. Description d'un mode de réalisation de l'invention
Le principe général de l'invention repose sur la transmission d'un serveur vers un terminal d'un premier contenu dans un premier canal de communication, et sur la restitution (consommation) progressive de ce premier contenu, avec possibilité d'interaction avec l'utilisateur du terminal. Plus précisément, un mode de réalisation particulier de l'invention prévoit la transmission à un serveur d'une information de contrôle, lors d'une requête émise par un terminal pour demander la transmission d'un deuxième contenu, indiquant si ce deuxième contenu doit être transmis dans le premier canal, ou dans un deuxième canal de transmission. Lors de la réception de la réponse à la requête, le terminal peut déterminer si la
réception du premier contenu doit être interrompue et si le second contenu doit réutiliser le même canal de transmission que le premier contenu, ou si la réception et la consommation du premier contenu doit être poursuivie en parallèle de la réception et de la consommation de la réponse à la requête transmise dans un autre canal de transmission.
Ainsi, l'invention propose une approche tout à fait nouvelle et inventive de la transmission d'un contenu multimédia vers un terminal de radiocommunication reposant sur la gestion des canaux de communication utilisés lors de l'envoi successif de réponses à des requêtes au sein d'un même service. Plus précisément, selon un mode de réalisation particulier, l'invention propose de signaler dans un nouveau contenu envoyé en réponse à une requête l'information permettant de gérer la réutilisation ou non d'un canal de communication déjà en cours d'utilisation.
En particulier, ce signal de transmission d'un nouveau contenu peut contenir une information selon laquelle le canal utilisé par le contenu précédemment envoyé et encore en cours de consommation (premier contenu), doit être coupé ou pas. De plus, ce signal peut contenir une information selon laquelle le nouveau contenu (deuxième contenu) envoyé en réponse à une requête doit réutiliser le canal déjà en cours d'utilisation pour le contenu précédemment envoyé et encore en cours de consommation (c'est-à-dire ré-utiliser le premier canal de communication). Par ailleurs, ce signal peut contenir un identificateur pour le canal de communication à utiliser pour le nouveau contenu envoyé en réponse à la requête.
En effet, on considère que l'utilisation de l'un et/ou l'autre des canaux de communication est dépendant du type de service demandé lors d'une requête, et doit donc découler des intentions de l'auteur d'un contenu. Par conséquent, le « comportement » des canaux de communication est modifié selon la situation rencontrée.
Jusqu'à présent, des raisons liées au type de contenu et à la situation de service ne permettaient pas de décider, au moment de la requête, de couper ou non
la réception du premier contenu. Selon l'invention, si le contenu est un flux de musique par exemple, il est envisageable que l'auteur souhaite que l'utilisateur puisse continuer à écouter cette musique pendant l'attente liée au temps de transmission de la requête au serveur, au temps de réaction du serveur et au temps de retour de la réponse à la requête.
On illustre ainsi en relation avec les figures 3 et 4 un exemple de mise en œuvre de l'invention.
On considère pour ce faire un unique serveur 35, fournissant un service à un terminal de radiocommunication 36. Il est bien entendu que l'invention couvre également le cas de la transmission d'informations de plusieurs serveurs à au moins un terminal de radiocommunication.
On considère selon cet exemple que le serveur 35 transmet au cours d'une première étape 41 un premier contenu 37 au terminal de communication 36.
Au cours d'une étape 42, le premier contenu 37 (ou au moins une partie de ce contenu) est restitué progressivement sur le terminal 36. Autrement dit, on utilise une transmission en mode « streaming ».
Si l'utilisateur du terminal 36 souhaite recevoir un deuxième contenu, il émet à destination du serveur 35 une requête 38 au cours d'une étape 43, demandant au serveur 35 de lui envoyer le deuxième contenu. Selon un mode de réalisation particulier de l'invention, la requête 38 comprend également une information de contrôle indiquant si le deuxième contenu doit être transmis dans le premier canal, ou dans un second canal.
Selon ce mode de réalisation particulier, tant que la réponse à la requête 38 n'est pas reçue, le terminal 36 continue à restituer le premier contenu au cours de l'étape 43.
Selon une autre approche, il est possible d'interrompre la restitution du premier contenu immédiatement après l'émission de la requête ou après un laps de temps prédéterminé.
Finalement, au cours d'une étape 44, le deuxième contenu 39 est transmis (dans le premier ou dans un second canal de communication) et restitué sur le terminal.
On décrit ci-après, en relation avec la figure , un exemple de mode de réalisation particulier de l'invention s'appuyant (de façon non exclusive mais simplement illustrative) sur l'utilisation d'un environnement LASeR (en anglais « Lightweight Application Scène Représentation », en français « Représentation de scènes applicatives légères ») et SAF (en anglais « Simple Aggregation Format »). Soit un service au format LASeR de téléchargement de morceaux de musique. On rappelle qu'un service est une succession de contenus, maintenant pour l'utilisateur une impression de continuité, un contenu étant un ensemble composé d'au moins une scène graphique animée, encore appelée scène multimédia, et d'une série de commandes permettant de faire évoluer cette scène d'un état à un autre. Par exemple, cette continuité peut être obtenue par mises à jour successives de la même scène multimédia, le service étant alors conçu de manière à ce que l'utilisateur ne voit pas de changement de page, et toutes les réponses à des requêtes de l'utilisateur étant des mises à jour partielles de la scène courante. Dans ce cas, il n'y a pas de remplacement d'une scène par une autre. Il est à noter que, classiquement, le remplacement est le moment préféré pour récupérer toutes les ressources, et en particulier tout canal de communication ouvert.
Dans cet exemple de réalisation, le service commence par des écrans successifs de choix d'un premier morceau de musique. On considère que l'utilisateur a choisi un morceau. Lors d'une interaction locale (choix du morceau), une requête est construite puis envoyée au serveur. Le serveur répond sous la forme d'une mise à jour de la scène comportant un élément audio avec ses éléments de contrôle accompagnés d'un flux de musique. Ce flux de musique est joué, par le terminal, à réception. On considère que l'utilisateur interagit encore avec le service. Certaines interactions sont purement locales, et ne donnent pas
lieu à des requêtes vers le serveur. Pour les interactions qui donnent lieu à un dialogue avec le serveur, il faut distinguer deux types de situation : un premier type de situation où la réponse à la requête ne remet pas en cause la consommation du flux de musique ; - un second type de situation où la réponse à la requête suppose que la consommation du flux de musique s'arrête.
Dans le premier type de situation, la requête est, par exemple, une demande d'information complémentaire sur le flux de musique, comme par exemple une demande de présentation de la pochette du CD, ou une demande d'achat de l'album physique. Dans ce cas, le flux de musique est transmis dans un premier canal de communication. La réponse à la requête est quant à elle transmise dans un deuxième canal de communication, puis décodée et rendue dans la scène qui restitue le flux de musique. Par exemple, cette réponse est restituée sous la forme d'information présentée dans une fenêtre temporaire superposée aux éléments graphiques liés au contrôle de la consommation du flux, appelés précédemment éléments de contrôle.
Dans le second type de situation, la requête est, par exemple, une demande d'un deuxième flux de musique. Il faut dans ce cas arrêter de consommer le premier flux avant de commencer à consommer le deuxième flux. En particulier, le serveur du deuxième flux peut être différent du serveur du premier flux Par conséquent il n'est pas certain que le serveur du premier flux soit au courant de la requête demandant un deuxième flux, et continue donc la transmission du premier flux. Il est donc de la responsabilité du terminal de couper la communication du premier flux, que ce soit pour informer le serveur de l'arrêt de la consommation et/ou pour éviter d'avoir à supprimer des paquets du premier flux contenus dans les différentes zones de tampon du réseau. En effet, ces zones tampons correspondent souvent à plusieurs secondes de contenu, de 2 à 10 secondes selon les situations, ce qui est coûteux en terme de ressources.
Il est donc important de pouvoir, au moment de la réception de chaque réponse :
- soit poursuivre la consommation d'un flux en cours et utiliser un nouveau canal de communication pour la réponse ;
- soit arrêter la consommation d'un flux en cours et réutiliser un même canal de communication pour la consommation de la réponse. Selon ce mode de réalisation de l'invention, cette décision peut être prise grâce à une information de contrôle contenue dans les informations de scène, par exemple dans les commandes permettant de faire évoluer la scène d'un état à un autre.
Par exemple, on suppose que la requête est transmise par l'intermédiaire de l'activation d'un élément a de la scène, par exemple un objet graphique de la scène. Un tel élément comprend plusieurs attributs, tels que définis dans les formats LASeR et SAF. Par exemple, l'activation de l'élément a se traduit par un appel à une URL contenue dans l'attribut xlink:href de cet élément a.
Selon ce mode de réalisation, on définit un nouvel attribut lsrxonnectionPipe ajouté à l'élément a. On considère que cet attribut peut prendre les valeurs :
- « new » définissant un nouveau canal de communication,
- « current » définissant le canal de communication courant (en général, le premier canal de communication) ou - un identificateur d'un canal prédéterminé, par exemple sous la forme du nom d'un canal de communication.
Utiliser un nom de canal de communication « X » est équivalent à donner la valeur « new » à l'attribut lsrxonnectionPipe, et permet en plus de couper ultérieurement le canal par une commande explicite, par exemple <ClosePipe name=«X»/> en format XML.
En reprenant la première situation évoquée précédemment, selon laquelle la réponse à la requête ne remet pas en cause la consommation du flux de musique, l'attribut lsrxonnexionPipe doit avoir la valeur « new » ou le nom d'un deuxième canal de communication différent du nom du premier canal de communication en cours d'utilisation pour le flux de musique. Si ce premier canal
de communication en cours d'utilisation pour le flux de musique n'a pas de nom, alors l'attribut lsrxonnexionPipe peut avoir la valeur « new » ou le nom d'un canal de communication quelconque.
De même, en reprenant la deuxième situation évoquée précédemment, selon laquelle la réponse à la requête arrête la consommation du flux de musique, l'attribut lsrxonnexionPipe doit avoir la valeur « current » ou le nom du premier canal de communication, en cours d'utilisation pour le flux de musique. Si ce premier canal de communication en cours d'utilisation pour le flux de musique n'a pas de nom, alors l'attribut lsrxonnexionPipe doit avoir la valeur « current ». On décrit ci-après un exemple d'algorithme utilisé pour la mise en oeuvre de l'invention, illustré au moyen de fragments de scène. On comprend que dans une situation de service au format LASeR, l'équivalent binaire de ces fragments de scène serait transmis.
L'annexe 1, qui fait partie intégrante de la description présente un fragment pour la scène comprenant le flux de musique « au » en cours de consommation et comprenant deux requêtes possibles, une requête reql pour une demande d'affichage de la pochette, correspondant à la première situation et une requête req2 pour une demande de transmission d'un second flux, correspondant à la deuxième situation. Par exemple, la figure IA illustre la première situation, selon laquelle le flux de musique « au » est transmis dans un premier canal de communication et la requête ne remet pas en cause la consommation du flux « au ». Lors de la réception 10 de la réponse à la requête reql, le terminal ne coupera pas la réception du flux de musique « au », et les informations d'affichage de la pochette « poch » seront transmises dans un deuxième canal de communication.
La figure IB illustre quant à elle la deuxième situation, selon laquelle le flux de musique « au » est transmis dans un premier canal de communication et la requête remet en cause la consommation du flux « au ».Lors de la réception 11 de la réponse à la requête req2, le terminal coupera cette réception. Par conséquent, le flux de musique « au » n'est plus transmis dans le premier canal de
communication et un deuxième flux noté « track » est transmis dans ce premier canal. Selon une variante, ce deuxième flux noté « track » peut être transmis dans un deuxième canal de communication.
On décrit désormais en relation avec la figure 2 un autre exemple d'application de l'invention est décrit dans le cadre d'un service dont la partie principale est diffusée sans voie de retour, autrement dit en mode « broadcast »
(diffusion), par exemple dans un environnement DVB-H. Des améliorations de ce service peuvent être requises de manière interactive sur un canal avec voie de retour, par exemple avec une connexion téléphonique mobile GSM, GPRS ou UMTS.
La caractéristique principale d'un tel service est que le terminal reste connecté pendant toute la durée d'une émission sur le canal DVB-H, pour continuer à recevoir le flux d'informations de base du service. Par exemple, l'utilisateur est en train de visionner un journal télévisé (JT). On note 21 le début du journal télévisé, transmis sur le canal DVB-H 20.
Au cours de ce journal, des informations supplémentaires sont régulièrement proposées sous la forme d'un bandeau défilant dans lequel des zones d'interaction (zones cliquables) donnent accès à des contenus supplémentaires. Voici deux exemples de contenus supplémentaires : - lors de l'interview d'une chanteuse à succès, encore appelé scène
« interview », une écoute de ses trois derniers succès est proposée ; - lors d'un sujet sur une catastrophe naturelle, encore appelé scène « catastrophe », un don en ligne à une organisation caritative est proposé. Lors de la scène « catastrophe », une zone cliquable apparaît. L'utilisateur clique pour demander le formulaire de don. Ce formulaire de don est spécifique de l'opérateur téléphonique, et donc envoyé sur un canal téléphonique. Un objet de la scène « catastrophe «correspondant à l'élément a configuré comme suit est activé : <a id="req" lsr : connexionPipe="new"
xlink : href="http : / / * . org/serv?gif t " /> Lors de l'activation de cette zone cliquable, une requête req 22 est envoyée à un serveur. A la réception de la réponse 23, le canal DVB-H 20 est maintenu et un canal téléphonique (par exemple de type UMTS) 24 est créé pour la gestion du formulaire de don. A la fin de l'opération, la transmission d'information est terminée et le canal de transmission 24 utilisé pour la réception du formulaire de don est naturellement clos 25 par le serveur.
Lors de la scène « interview », une zone cliquable apparaît. L'utilisateur clique pour demander l'écoute du premier morceau (« requête chanson 1 »(req3) 26). Pour des raisons externes, les trois morceaux ne peuvent pas faire partie des données liées à l'émission du journal télévisé mais doivent être reçus par un canal téléphonique. Un objet de la scène « interview «correspondant à l'élément a configuré comme suit est activé :
<a id="req3" lsr : connexionPipe="song" xlink:href="http: //* . org/serv?song=l"/>
Lors de l'activation de cette zone cliquable, la requête 26 pour la première chanson est envoyée. A la réception de la réponse 27, le canal DVB-H est maintenu, même si le volume sonore du journal télévisé est temporairement réduit à 0. Un autre canal de communication UMTS 28, nommé « song » est ouvert, et la chanson commence à être jouée. L'utilisateur continue à voir le journal, avec les zones cliquables, pendant qu'il écoute la chanson. Il souhaite alors passer à la seconde chanson et active une autre zone cliquable. Un objet de la scène « interview «correspondant à un élément a configuré comme suit est activé :
<a id="req4" lsr : connexionPipe≈" song" xlink:href="http: //* . org/serv?song=2"/>
Lors de l'activation de cette seconde zone cliquable, la requête 29 (req4) pour la seconde chanson est envoyée. Dans cet exemple, la première chanson continue à être jouée. A la réception de la seconde réponse 30, la connexion sur le canal « song » est coupée pour que le canal puisse être réutilisé pour la seconde chanson. Le contenu des tampons de la première chanson est détruit. La seconde
chanson commence à être jouée sur le canal « song ». L'utilisateur souhaite alors revenir au journal télévisé et transmet une requête (req5) 31 de retour JT. Un objet correspondant à un élément conditionnel configuré comme suit est activé :
<lsr : conditional id="req5"> <lsr : ClosePipe name="song"/>
... autres commandes liées au retour au JT... ... dont le retour du volume sonore normal du JT... </lsr : conditional>
A la suite de cette opération, le canal de transmission 28 « song » utilisé pour les deux chansons est fermé et la consommation du flux DVB-H 20 seulement continue.
ANNEXE 1
<saf : SAFSession ...>
<saf : sceneHeader .../> ... (flux d'image utilisés par la scène) ...
<saf :mediaHeader streamID="au" ...entête flux audio... /> <saf : sceneUnit ...> <lsr :NewScene>
<audio xlink:href="stream: au".../>
<a id="reql" lsr : connexionPipe="new" xlink:href="http: //* . org/serv?poch=6553"/>
<a id="req2" lsr : connexionPipe="current" xlink:href="http: //* . org/serv?track=7554"/>
</lsr :NewScene> </saf : sceneUnit> ... paquets audio ad lib ...
Claims
1. Procédé de gestion de canaux de communication pour la transmission de contenus multimédia d'au moins un serveur (35) vers au moins un terminal de radiocommunication (36), caractérisé en ce qu'il comprend les étapes suivantes : transmission (41) d'un premier contenu (37) dans un premier canal ; restitution progressive (42) dudit premier contenu (37) dans un terminal ;
- émission (43) par ledit terminal d'une requête (38) pour un deuxième contenu (39), ladite requête (38) comprenant une information de contrôle indiquant si ledit deuxième contenu (39) doit être transmis dans ledit premier canal, ou dans un second canal ;
- restitution progressive (44) dudit deuxième contenu (39).
2. Procédé de gestion de canaux de communication selon la revendication 1 , caractérisé en ce que ladite restitution progressive dudit premier contenu se poursuit tant qu'une réponse à ladite requête n'est pas reçue.
3. Procédé de gestion de canaux de communication selon l'une quelconque des revendications 1 et 2, caractérisé en ce que, si ladite information de contrôle prévoit l'utilisation d'un second canal, les premier et deuxième contenus sont restitués progressivement au moins partiellement de façon simultanée.
4. Procédé de gestion de canaux de communication selon l'une quelconque des revendications 1 et 2, caractérisé en ce que, si ladite information de contrôle prévoit l'utilisation dudit premier canal uniquement, ledit deuxième contenu est restitué progressivement en remplacement dudit premier contenu.
5. Procédé de gestion de canaux de communication selon l'une quelconque des revendications 1 à 4, caractérisé en ce que ladite information de contrôle est un attribut d'un élément d'une scène multimédia portant un lien vers le serveur transmettant ledit deuxième contenu.
6. Procédé de gestion de canaux de communication selon la revendication 5, caractérisé en ce que ledit attribut peut prendre une des au moins trois valeurs suivantes : nouveau canal ; - canal courant ; identificateur d'un canal prédéterminé.
7. Procédé de gestion de canaux de communication selon la revendication 6, caractérisé en ce qu'il met en œuvre une étape d'émission par ledit terminal d'une requête de fermeture explicite d'un canal de communication ouvert, en le désignant par son identificateur.
8. Signal de gestion de canaux de communication pour la mise en oeuvre du procédé de gestion de canaux de communication selon l'une quelconque des revendications 1 à 7, ledit signal étant émis par un terminal de radiocommunication, caractérisé en ce qu'il comprend un champ d'information de contrôle indiquant si un deuxième contenu doit être transmis dans le premier canal, ou dans un second canal de communication.
9. Signal de gestion selon la revendication 8, caractérisé en ce que ledit champ d'information de contrôle peut prendre une des au moins trois valeurs suivantes : nouveau canal ; canal courant ; identificateur d'un canal prédéterminé.
10. Signal de gestion selon la revendication 9, caractérisé en ce qu'il comprend une requête de fermeture explicite d'un canal de communication ouvert en le désignant par son identificateur.
11. Terminal de radiocommunication (36) destiné à recevoir au moins un contenu multimédia diffusé par au moins un serveur (35), caractérisé en ce qu'il comprend des moyens de : restitution progressive d'un premier contenu transmis dans un premier canal ; émission d'une requête pour un deuxième contenu, ladite requête comprenant une information de contrôle indiquant si ledit deuxième contenu doit être transmis dans ledit premier canal, ou dans un second canal ; restitution progressive dudit deuxième contenu.
Priority Applications (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US12/444,540 US9166861B2 (en) | 2006-10-06 | 2007-09-27 | Method for managing communication channels, corresponding signal and terminal |
| EP07820660A EP2077016A1 (fr) | 2006-10-06 | 2007-09-27 | Procédé de gestion de canaux de communication, signal et terminal correspondants |
Applications Claiming Priority (4)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| FR0608822A FR2924885A1 (fr) | 2006-10-06 | 2006-10-06 | Procede de gestion de canaux de communication, signal et terminal correspondants |
| FR0608822 | 2006-10-06 | ||
| FR0610362 | 2006-11-27 | ||
| FR0610362A FR2924886B1 (fr) | 2006-10-06 | 2006-11-27 | Procede de gestion de canaux de communication, signal et terminal correspondants. |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| WO2008040677A1 true WO2008040677A1 (fr) | 2008-04-10 |
Family
ID=38870290
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| PCT/EP2007/060272 WO2008040677A1 (fr) | 2006-10-06 | 2007-09-27 | Procédé de gestion de canaux de communication, signal et terminal correspondants |
Country Status (4)
| Country | Link |
|---|---|
| US (1) | US9166861B2 (fr) |
| EP (1) | EP2077016A1 (fr) |
| FR (1) | FR2924886B1 (fr) |
| WO (1) | WO2008040677A1 (fr) |
Families Citing this family (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| AU2015229129B2 (en) * | 2014-03-14 | 2019-11-14 | The General Hospital Corporation | System and method for spiral volume imaging |
| MX369226B (es) * | 2014-10-21 | 2019-11-01 | Sony Corp | Aparato de recepcion, metodo de recepcion, aparato de transmision, y metodo de transmision. |
| US11336744B2 (en) | 2018-01-16 | 2022-05-17 | Comcast Cable Communications, Llc | Methods and systems for communicating relevant content |
Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20050069225A1 (en) * | 2003-09-26 | 2005-03-31 | Fuji Xerox Co., Ltd. | Binding interactive multichannel digital document system and authoring tool |
| US6882639B1 (en) * | 1998-09-21 | 2005-04-19 | Nortel Networks Limited | Telecommunications middleware |
Family Cites Families (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US7844491B1 (en) * | 1999-10-19 | 2010-11-30 | Netzero, Inc. | Sponsorship/advertising for an internet client |
| US6516191B1 (en) * | 1999-11-24 | 2003-02-04 | At&T Corp. | Hypermedia links that address traffic channels in a wireless communication system |
| EP1463309A1 (fr) * | 2003-03-26 | 2004-09-29 | THOMSON Licensing S.A. | Traitement d'un format de flux de données pour la réception audiovisuelle mobile |
| WO2005048510A2 (fr) * | 2003-11-05 | 2005-05-26 | Arris International, Inc. | Procede et systeme de transmission de paquets de trafic de donnees et video par le meme dispositif |
| US20080046937A1 (en) * | 2006-07-27 | 2008-02-21 | LaSean T. Smith | Playing Content on Multiple Channels of a Media Device |
-
2006
- 2006-11-27 FR FR0610362A patent/FR2924886B1/fr active Active
-
2007
- 2007-09-27 US US12/444,540 patent/US9166861B2/en not_active Expired - Fee Related
- 2007-09-27 WO PCT/EP2007/060272 patent/WO2008040677A1/fr active Application Filing
- 2007-09-27 EP EP07820660A patent/EP2077016A1/fr not_active Withdrawn
Patent Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US6882639B1 (en) * | 1998-09-21 | 2005-04-19 | Nortel Networks Limited | Telecommunications middleware |
| US20050069225A1 (en) * | 2003-09-26 | 2005-03-31 | Fuji Xerox Co., Ltd. | Binding interactive multichannel digital document system and authoring tool |
Also Published As
| Publication number | Publication date |
|---|---|
| US9166861B2 (en) | 2015-10-20 |
| FR2924886B1 (fr) | 2013-03-22 |
| FR2924886A1 (fr) | 2009-06-12 |
| EP2077016A1 (fr) | 2009-07-08 |
| US20100029313A1 (en) | 2010-02-04 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| KR101731133B1 (ko) | 주문형 제공을 위한 스트리밍 콘텐츠의 어셈블링 | |
| EP3127336B1 (fr) | Dispositif et procédé de commande a distance de la restitution de contenus multimedia | |
| US20120143994A1 (en) | Selectively receiving media content | |
| US20120079000A1 (en) | Selectively receiving media content | |
| EP3646548B1 (fr) | Procédé de transmission d'un contenu audio interrompu dans un récepteur hybride, système, récepteur et programme associé au procédé | |
| FR2845555A1 (fr) | Procedes de reception et de diffusion de television interactive et dispositifs associes | |
| US20120079062A1 (en) | Selectively receiving media content | |
| US20220060532A1 (en) | Method for transmitting resources and electronic device | |
| EP1579319B1 (fr) | Dispositifs et procédés de décision conditionnelle d'exécution de services reçus et de constitution de messages d'informations associés, des services, et produits associés | |
| WO2007031570A1 (fr) | Transmission d' un contenu multimedia vers un terminal de radiocommunication | |
| WO2011073586A1 (fr) | Pre-chargement de contenu entre un serveur de contenu et au moins un terminal | |
| WO2008040677A1 (fr) | Procédé de gestion de canaux de communication, signal et terminal correspondants | |
| WO2020188218A1 (fr) | Procédé de gestion de contenus multimédia et dispositif pour la mise en oeuvre du procédé | |
| EP1850602B1 (fr) | Procédé et système pour accélérer l'accès à un contenu à partir d'un terminal mobile | |
| FR2924885A1 (fr) | Procede de gestion de canaux de communication, signal et terminal correspondants | |
| EP4055831A1 (fr) | Procédé de gestion de zapping de contenus multimédias numériques obtenu par téléchargement progressif adaptatif (has), dispositif de gestion, lecteur de flux multimédia et programme d'ordinateur correspondants | |
| Ekudden et al. | On-demand mobile media- A rich service experience for mobile users | |
| EP2854415B1 (fr) | Procédé de transmission dynamique de données d'information relatives à un programme audio et/ou vidéo | |
| KR20200018890A (ko) | 무선 스트리밍 방법 | |
| FR3096210A1 (fr) | Procédé de transmission d’un contenu numérique ayant plusieurs versions accessibles depuis un serveur de contenus à destination d’un terminal de restitution. | |
| FR3093603A1 (fr) | Procédé de navigation accélérée dans un contenu numérique obtenu par téléchargement progressif adaptatif (HAS), gestionnaire, lecteur de flux multimédia et programme d’ordinateur correspondants. | |
| Patel et al. | An Aggregate Functional Software Architecture on Android for End-2-End Real-Time Interactive Content Management to Cater IPTV Services on Digital Handheld Devices | |
| SP et al. | ARobust CLIENT ARCHITECTURE ON ANDROID TO CATER END-2-END REAL-TIME CONTENT MANAGEMENT AND PERSONALIZED IPTV SERVICES TO MOBILE INTERNET DEVICES | |
| WO2016156386A1 (fr) | Système de diffusion de contenus audio et/ou vidéo par un réseau wifi local, et appareils mettant en œuvre le procédé |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| WWE | Wipo information: entry into national phase |
Ref document number: 200780044554.X Country of ref document: CN |
|
| 121 | Ep: the epo has been informed by wipo that ep was designated in this application |
Ref document number: 07820660 Country of ref document: EP Kind code of ref document: A1 |
|
| NENP | Non-entry into the national phase |
Ref country code: DE |
|
| WWE | Wipo information: entry into national phase |
Ref document number: 2007820660 Country of ref document: EP |
|
| WWE | Wipo information: entry into national phase |
Ref document number: 12444540 Country of ref document: US |