FR3053556A1 - Procede et dispositif de gestion d'une session de transmission d'un flux video - Google Patents

Procede et dispositif de gestion d'une session de transmission d'un flux video Download PDF

Info

Publication number
FR3053556A1
FR3053556A1 FR1656270A FR1656270A FR3053556A1 FR 3053556 A1 FR3053556 A1 FR 3053556A1 FR 1656270 A FR1656270 A FR 1656270A FR 1656270 A FR1656270 A FR 1656270A FR 3053556 A1 FR3053556 A1 FR 3053556A1
Authority
FR
France
Prior art keywords
session
terminal
video stream
transmission
network
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
FR1656270A
Other languages
English (en)
Inventor
Gael Fromentoux
Frederic Fieau
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Orange SA
Original Assignee
Orange SA
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Orange SA filed Critical Orange SA
Priority to FR1656270A priority Critical patent/FR3053556A1/fr
Priority to PCT/FR2017/051558 priority patent/WO2018002469A1/fr
Publication of FR3053556A1 publication Critical patent/FR3053556A1/fr
Pending legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/63—Control signaling related to video distribution between client, server and network components; Network processes for video distribution between server and clients or between remote clients, e.g. transmitting basic layer and enhancement layers over different transmission paths, setting up a peer-to-peer communication via Internet between remote STB's; Communication protocols; Addressing
    • H04N21/647—Control signaling between network components and server or clients; Network processes for video distribution between server and clients, e.g. controlling the quality of the video stream, by dropping packets, protecting content from unauthorised alteration within the network, monitoring of network load, bridging between two different networks, e.g. between IP and wireless
    • H04N21/64723—Monitoring of network processes or resources, e.g. monitoring of network load
    • H04N21/64738—Monitoring network characteristics, e.g. bandwidth, congestion level
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/24—Monitoring of processes or resources, e.g. monitoring of server load, available bandwidth, upstream requests
    • H04N21/2401—Monitoring of the client buffer
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/63—Control signaling related to video distribution between client, server and network components; Network processes for video distribution between server and clients or between remote clients, e.g. transmitting basic layer and enhancement layers over different transmission paths, setting up a peer-to-peer communication via Internet between remote STB's; Communication protocols; Addressing
    • H04N21/637—Control signals issued by the client directed to the server or network components
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/63—Control signaling related to video distribution between client, server and network components; Network processes for video distribution between server and clients or between remote clients, e.g. transmitting basic layer and enhancement layers over different transmission paths, setting up a peer-to-peer communication via Internet between remote STB's; Communication protocols; Addressing
    • H04N21/647—Control signaling between network components and server or clients; Network processes for video distribution between server and clients, e.g. controlling the quality of the video stream, by dropping packets, protecting content from unauthorised alteration within the network, monitoring of network load, bridging between two different networks, e.g. between IP and wireless
    • H04N21/64746—Control signals issued by the network directed to the server or the client
    • H04N21/64761—Control signals issued by the network directed to the server or the client directed to the server
    • H04N21/64769—Control signals issued by the network directed to the server or the client directed to the server for rate control
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/63—Control signaling related to video distribution between client, server and network components; Network processes for video distribution between server and clients or between remote clients, e.g. transmitting basic layer and enhancement layers over different transmission paths, setting up a peer-to-peer communication via Internet between remote STB's; Communication protocols; Addressing
    • H04N21/647—Control signaling between network components and server or clients; Network processes for video distribution between server and clients, e.g. controlling the quality of the video stream, by dropping packets, protecting content from unauthorised alteration within the network, monitoring of network load, bridging between two different networks, e.g. between IP and wireless
    • H04N21/64784—Data processing by the network

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Computer Security & Cryptography (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

Le procédé selon l'invention de gestion d'une session de transmission d'un flux vidéo entre un serveur de contenus et un terminal via un réseau de télécommunications, comprend, suite à une détection (F10) d'un démarrage de la session : - une étape (F50) d'obtention d'informations représentatives de conditions de transmission du flux vidéo expérimentées lors de la session sur le réseau ; - si lesdites conditions de transmission ne sont pas considérées comme favorables (F60) : ○ une étape d'obtention (F90) d'un état courant d'un buffer utilisé par un module de restitution du terminal pour la restitution du flux vidéo et représentatif d'un niveau de remplissage du buffer ; et ○ une étape de sélection (F110) d'au moins une politique de priorisation à appliquer à la transmission du flux vidéo vers le terminal tant que la session de transmission se trouve dans une période de démarrage au regard d'un critère prédéterminé et que le niveau de remplissage du buffer est inférieur à un seuil de remplissage prédéterminé.

Description

© N° de publication : 3 053 556 (à n’utiliser que pour les commandes de reproduction)
©) N° d’enregistrement national : 16 56270 ® RÉPUBLIQUE FRANÇAISE
INSTITUT NATIONAL DE LA PROPRIÉTÉ INDUSTRIELLE
COURBEVOIE © Int Cl8 : H 04 N 21/2343 (2017.01), H 04 N 21/437
DEMANDE DE BREVET D'INVENTION A1
©) Date de dépôt : 30.06.16. (© Priorité : (© Demandeur(s) : ORANGE Société anonyme — FR.
©) Date de mise à la disposition du public de la demande : 05.01.18 Bulletin 18/01. @ Inventeur(s) : FROMENTOUX GAEL et Fl EAU FREDERIC.
©) Liste des documents cités dans le rapport de recherche préliminaire : Se reporter à la fin du présent fascicule
(© Références à d’autres documents nationaux apparentés : ©) Titulaire(s) : ORANGE Société anonyme.
©) Demande(s) d’extension : © Mandataire(s) : CABINET BEAU DE LOMENIE.
PROCEDE ET DISPOSITIF DE GESTION D'UNE SESSION DE TRANSMISSION D'UN FLUX VIDEO.
FR 3 053 556 - A1
Le procédé selon l'invention de gestion d'une session de transmission d'un flux vidéo entre un serveur de contenus et un terminal via un réseau de télécommunications, comprend, suite à une détection (F10) d'un démarrage de la session:
- une étape (F50) d'obtention d'informations représentatives de conditions de transmission du flux vidéo expérimentées lors de la session sur le réseau;
- si lesdites conditions de transmission ne sont pas considérées comme favorables (F60):
O une étape d'obtention (F90) d'un état courant d'un butter utilisé par un module de restitution du terminal pour la restitution du flux vidéo et représentatif d'un niveau de remplissage du butter; et
O une étape de sélection (F110) d'au moins une politique de priorisation à appliquer à la transmission du flux vidéo vers le terminal tant que la session de transmission se trouve dans une période de démarrage au regard d'un critère prédéterminé et que le niveau de remplissage du butter est inférieur à un seuil de remplissage prédéterminé.
Figure FR3053556A1_D0001
Figure FR3053556A1_D0002
Arrière-plan de l'invention
L'invention se rapporte au domaine général des télécommunications.
Elle concerne plus particulièrement la transmission de flux vidéo entre un serveur de contenus et un terminal dans un réseau de télécommunications.
Les opérateurs des réseaux de télécommunications et les fournisseurs de contenus, en particulier vidéo, collaborent aujourd'hui de plus en plus afin de mieux faire correspondre les besoins des applications utilisant ces contenus et les capacités des réseaux. Il s'agit notamment d'optimiser la livraison des contenus au travers des réseaux afin d'améliorer ainsi la qualité de service perçue par les clients des fournisseurs de contenus.
Un axe d'amélioration de cette qualité de service (ou d'expérience perçue par les clients) visé spécifiquement par les fournisseurs de contenus consiste notamment en la diminution de la latence constatée entre la demande de service faite par un client auprès d'un serveur de contenus pour accéder à un flux vidéo et le visionnage par ce client des premières images du flux vidéo. La contrainte imposée par les fournisseurs de contenus est que le client n'attende pas trop longtemps le début du visionnage du flux vidéo qu'il a demandé sous peine de se démotiver et d'abandonner sa session de communication avec le serveur de contenus. Aucune limitation n'est attachée à la nature du service auquel accède le client pour visionner le flux : il peut s'agir indifféremment d'un service de vidéo à la demande, de navigation web, de diffusion en temps réel de type « streaming », etc.
Cette contrainte est d'autant plus critique lorsque le client accède au serveur de contenus via un réseau de télécommunications mobile, tel que par exemple un réseau cellulaire (par exemple le réseau 4G - Quatrième Génération) ou un réseau WIFI (WIreless FIdelity), dont les conditions de transmission peuvent fluctuer en fonction de divers paramètres (environnement, mobilité, charge de la cellule, etc.).
Objet et résumé de l'invention
L'invention permet notamment de répondre à ce problème en proposant un procédé de gestion d'une session de transmission d'un flux vidéo entre un serveur de contenus et un terminal via un réseau de télécommunications, ce procédé de gestion comprenant, suite à une détection d'un démarrage de la session :
— une étape d'obtention d'informations représentatives de conditions de transmission du flux vidéo expérimentées lors de la session sur le réseau ;
— si lesdites conditions de transmission ne sont pas considérées comme favorables :
o une étape d'obtention d'un état courant d'un buffer utilisé par un module de restitution du terminal pour la restitution du flux vidéo et représentatif d'un niveau de remplissage du buffer ; et o une étape de sélection d'une politique de priorisation à appliquer à la transmission du flux vidéo vers le terminal tant que la session de transmission se trouve dans une période de démarrage au regard d'un critère prédéterminé et que le niveau de remplissage du buffer est inférieur à un seuil de remplissage prédéterminé. Corrélativement, l'invention vise également un dispositif de gestion d'une session de transmission d'un flux vidéo entre un serveur de contenus et un terminal via un réseau de télécommunications, ce dispositif de gestion comprenant :
— un module de détection d'un démarrage de la session ;
— un premier module d'obtention, activé sur détection d'un démarrage de la session par le module de détection et configuré pour obtenir des informations représentatives de conditions de transmission du flux vidéo expérimentées lors de la session sur le réseau ;
— des modules activés si lesdites conditions de transmission ne sont pas considérées comme favorables par le premier module d'obtention comprenant :
o un deuxième module d'obtention, configuré pour obtenir un état courant d'un buffer utilisé par un module de restitution du terminal pour la restitution du flux vidéo et représentatif d'un niveau de remplissage du buffer ; et o un module de sélection, configuré pour sélectionner au moins une politique de priorisation à appliquer à la transmission du flux vidéo vers le terminai tant que la session de transmission se trouve dans une période de démarrage au regard d'un critère prédéterminé et que le niveau de remplissage du buffer est inférieur à un seuil de remplissage prédéterminé.
Les modules du dispositif de gestion peuvent être localisés par exemple dans un point d'accès PoP (pour Point of Presence) au réseau de l'opérateur.
Afin de diminuer la latence au démarrage de la restitution d'un flux vidéo sur le terminal d'un utilisateur, l'invention propose de prioriser temporairement les données relatives à ce flux vidéo lorsque la session de transmission vidéo expérimente des conditions de transmission défavorables sur le réseau (par exemple une charge trop importante sur la cellule à laquelle est rattachée le terminal pour un réseau cellulaire, ou une mauvaise réception radioélectrique due par exemple à un mauvais positionnement du terminal dans la cellule) et est donc susceptible d'être affectée par une latence importante. Par prioriser, on entend ici donner une importance préférentielle à ces données, autrement dit favoriser leur transmission vers le terminal par rapport aux données d'autres flux vidéo.
Cette priorisation temporaire est appliquée tant que la session de transmission se trouve dans une période de démarrage et tant qu'un buffer utilisé par un module de restitution (aussi couramment désigné par « player ») du terminal lors de la restitution du flux vidéo n'atteint pas un niveau de remplissage satisfaisant pour assurer une restitution du flux vidéo à l'utilisateur du terminal. Les inventeurs ont en effet relié l'état de ce buffer à la latence expérimentée par le terminal au début de la session vidéo : si le terminal a engrangé suffisamment de données relatives au flux vidéo dans ce buffer (autrement dit, si le niveau de remplissage de ce buffer est supérieur à un niveau de remplissage donné), on peut s'attendre à une visualisation rapide et correcte du flux par l'utilisateur sur son terminal, de sorte qu'il n'est pas nécessaire d'intervenir. En revanche, si le niveau de remplissage du buffer est insuffisant à un moment quelconque de la période de démarrage, l'invention propose de remédier à cette situation qui peut s'avérer rédhibitoire pour l'utilisateur du terminal en rendant prioritaires les données du flux vidéo destiné au terminal. On anticipe de la sorte d'éventuelles difficultés de l'utilisateur à accéder au contenu du flux vidéo qu'il a requis.
Les conditions d'arrêt de la priorisation (période de démarrage et niveau de remplissage du buffer insuffisant) permettent avantageusement de se focaliser sur le démarrage de la session et sur les réels besoins de l'utilisateur du terminal. On considère par exemple que la session de transmission du flux vidéo se trouve dans une période de démarrage si une période de temps écoulée depuis le démarrage de la session de transmission est inférieure à une période maximale prédéterminée ou si une quantité de données relatives au flux vidéo émise par le serveur de contenus est inférieure à une quantité maximale prédéterminée.
L'invention permet de donner la priorité à certains flux vidéo sans pour autant désorganiser la transmission simultanée des autres flux vidéo sur le réseau à destination d'autres utilisateurs. La priorisation proposée par l'invention n'a en effet pas vocation à durer plus que nécessaire ni à s'appliquer lorsque les conditions de transmission expérimentées par le terminal ne le justifient pas (ex. conditions de propagation radio favorables et/ou buffer utilisé par le module de restitution (player) suffisamment rempli pour permettre un accès au flux vidéo rapide par l'utilisateur).
En diminuant ainsi la latence au démarrage de la restitution d'un flux vidéo, l'invention permet d'améliorer l'expérience perçue par l'utilisateur et d'éviter les abandons de sessions déplorés auprès des utilisateurs en cas de démarrage trop lent de la restitution.
Dans un mode particulier de réalisation, l'état courant du buffer est obtenu à partir d'un message de signalisation émis par le terminal dans une session de signalisation établie avec le serveur de contenus pour la session de transmission du flux vidéo.
Le message de signalisation et la session de signalisation sont par exemple conformes au protocole SPUD (Session Protocol for User Datagrams). Le protocole SPUD n’est qu’un exemple et il est possible d’utiliser d’autres protocoles de coopération entre équipements d’extrémités (serveurs de contenus, terminaux d’utilisateur) et équipements intermédiaires aptes à modifier ou inspecter les trafics de données (e.g. DPI).
Le protocole SPUD est un protocole actuellement en cours de normalisation auprès de l'IETF (Internet Engineering Task Force, documents draft-trammell-spud-req-04” et drafthildebrand-spud-prototype-03), mettant en œuvre une collaboration entre les acteurs de l'Internet parmi lesquels les opérateurs des réseaux de télécommunications et les fournisseurs de contenus. Ce protocole a pour objet de diffuser des messages, aussi appelés « advices », transportant des recommandations liées aussi bien aux services qu'au réseau. Il permet en particulier à des équipements d'extrémité (ex. terminaux clients ou serveurs de contenus ici) d'échanger des advices avec d'autres équipements intermédiaires du réseau par lesquels transitent les données pour adapter le comportement de ces équipements aux contraintes des applications activées sur les équipements d'extrémité. Un tel équipement intermédiaire est ici par exemple le dispositif de gestion selon l'invention. On note que conformément au protocole SPUD, les sessions de signalisation sont établies en marge des sessions de transmission auxquelles elles sont rattachées (i.e. il s'agit de sessions distinctes), une fois que les sessions de transmission ont été établies entre les protagonistes (i.e. terminal et serveur de contenus).
L'invention tire donc profit, dans ce mode de réalisation, de l'existence de ce protocole et de ses nombreuses possibilités pour véhiculer jusqu'au dispositif de gestion des informations sur le terminal et plus particulièrement sur l'état du buffer utilisé par le player du terminal pour la restitution du flux vidéo. Le dispositif de gestion est ici un équipement intermédiaire entre le terminal et le serveur de contenus, mais qui grâce au protocole SPUD, peut accéder à différentes informations véhiculées entre le terminal et le serveur de contenus, même si le serveur de contenus n'est pas sous le contrôle de l'opérateur du réseau. L'invention profite donc des évolutions proposées aujourd'hui pour les applications web pour obtenir diverses informations permettant d'optimiser le démarrage d'une session de transmission de flux vidéo et favoriser les communications entre applications et réseau.
On note que le protocole SPUD, dans sa version actuelle telle que spécifiée par l'IETF, n'inclut pas d'options permettant de remonter des informations depuis le terminal jusqu'au serveur de contenus relatives à un état physique du terminal, telles que par exemple le niveau de remplissage du buffer utilisé par le player du terminal pour la restitution du flux. L'invention propose donc d'enrichir la signalisation actuelle proposée par le protocole SPUD avec de nouvelles options permettant d'optimiser la fourniture de contenus vidéo, ce protocole se prêtant particulièrement bien à la mise en œuvre de l'invention.
L'invention ne se limite toutefois pas à l'utilisation du protocole SPUD pour véhiculer les informations du terminal jusqu'au dispositif de gestion. D'autres protocoles, comme par exemple le protocole http (HyperText Transfert Protocol), peuvent être utilisés en variante.
Dans un mode particulier de réalisation, la détection du démarrage de la session de transmission vidéo comprend une détection de l'établissement de la session de signalisation entre le terminal et le serveur de contenus.
L'établissement de la session de signalisation, en particulier dans le cas du protocole SPUD, est aisément détectable et permet d'identifier facilement qu'une session de transmission vidéo est démarrée.
Dans un mode particulier de réalisation, le procédé comprend en outre une étape préliminaire de détermination si la session de transmission du flux vidéo est ou non une session dite collaborative, une politique de priorisation n'étant appliquée à la transmission du flux vidéo que si la session de transmission est une session collaborative.
L'invention permet ainsi de prioriser certaines sessions dites collaboratives au détriment d'autres sessions non collaboratives. La notion de « session collaborative » dépend d'un critère prédéterminé : il peut s'agir par exemple de sessions associées à des fournisseurs de contenus avec lesquels l'opérateur du réseau a des accords, ou de sessions attachées à des terminaux spécifiques (ex. terminaux d'utilisateurs ayant un statut particulier dans le réseau), à des utilisateurs particuliers (ex. identités et/ou souscriptions particulières), à un domaine/sous domaine particulier, à des identifiants particuliers (ex. adresse IP), etc. et pour lesquelles le dispositif de gestion selon l'invention a préférentiellement accès à tout ou partie de la signalisation échangée dans la session de signalisation.
Ainsi, différents paramètres peuvent être considérés pour identifier si une session est collaborative ou non, en fonction du critère utilisé pour définir ces sessions. Par exemple, si on s'intéresse aux fournisseurs de contenus à proprement parler, une adresse IP du serveur véhiculée dans la signalisation émise par le terminal peut être utilisée et confrontée à des adresses IP rattachées à des serveurs de fournisseurs de contenus avec lesquels une collaboration a été établie.
Dans un autre mode de réalisation, les étapes d'obtention d'un état courant du buffer et l'étape de sélection d'au moins une politique de priorisation sont conditionnées par la détection d'un jeton valide dans un message de signalisation émis par le terminal.
Un tel jeton peut par exemple comprendre un identifiant, éventuellement chiffré. Il peut être utilisé pour identifier facilement des sessions collaboratives par exemple.
Dans un mode particulier de réalisation, ladite au moins une politique de priorisation est sélectionnée parmi au moins :
— une politique de suppression de données émises sur le réseau et relatives à au moins un flux vidéo d'au moins une session de transmission établie avec au moins un autre terminal ;
— une politique de suppression de données émises sur le réseau et relatives à au moins un flux vidéo d'au moins une session de transmission établie avec au moins un autre terminal lorsque ladite au moins une session de transmission présente une latence supérieure à un seuil de latence prédéterminé ; et — une politique d'adaptation d'une vitesse d'envoi vers le terminal, par un équipement intermédiaire entre le serveur de contenus et le terminal, des données relatives au flux vidéo de la session de transmission en fonction d'un niveau de remplissage d'un buffer de l'équipement intermédiaire et d'un débit du réseau expérimenté par le terminal.
Ces différentes politiques de priorisation permettent d'agir rapidement sur la transmission des données du flux vidéo destiné au terminal. En effet, du fait de la période limitée durant laquelle la priorisation des données est appliquée (période de démarrage de la session de transmission du flux vidéo seulement), une réponse rapide et efficace doit être apportée.
Les deux premières politiques précitées visant à supprimer des données relatives à des flux vidéo échangés dans le cadre de sessions non destinées au terminal permettent de privilégier de façon efficace les données de la session de transmission du terminal. Les sessions de transmission dont les données sont supprimées sont par exemple les sessions identifiées comme non collaboratives. Les deux premières politiques favorisent ainsi les sessions de transmission de flux vidéo en provenance de serveurs avec lesquels des collaborations avec l'opérateur du réseau ont été établies ou à destination de terminaux privilégiés par l'opérateur. Pour un réseau de télécommunications mobile tel qu'un réseau cellulaire ou un réseau 4G, la suppression de données à transmettre a un effet immédiat sur l'allocation des ressources destinées au terminal dont on cherche à favoriser la transmission du flux, qui devient plus favorable, permettant ainsi d'améliorer les conditions de transmission du flux vidéo vers le terminal.
On note que la deuxième politique de suppression des données prend avantageusement en compte la latence des sessions en plus du caractère collaboratif ou non collaboratif de la session. En effet, les inventeurs ont constaté que lorsque cette latence est trop importante, il est inutile de transmettre les données vers le terminal les ayant requis, car celui-ci n'est pas en mesure de les recevoir. Cette deuxième politique de suppression permet donc de limiter l'impact de cette politique sur les autres utilisateurs.
La troisième politique de priorisation proposée ci-dessus est particulièrement efficace et permet de ne pas saturer le lien entre le terminal et le serveur de contenus, notamment dans le cas où plusieurs sessions de transmission sont priorisées simultanément conformément à l'invention.
Bien entendu, cette liste n'est pas exhaustive et d'autres politiques peuvent être envisagées, comme par exemple une combinaison de tout ou partie des politiques de priorisation précitées.
Dans un mode particulier de réalisation, ladite au moins une politique de priorisation sélectionnée est notifiée dans un message de signalisation émis dans la session de signalisation établie avec le serveur de contenus, ce message de signalisation requérant l'application de ladite au moins une politique de priorisation sélectionnée par au moins un équipement intermédiaire entre le serveur et le terminal par lequel transite le flux vidéo.
Dans un mode préférentiel, la session de signalisation utilisée pour notifier ladite au moins une politique de priorisation aux équipements participant à la transmission du flux vidéo est une session conforme au protocole SPUD et le message de signalisation utilisé est un « advice » prévu par ce protocole. La mise en œuvre de l'invention est ainsi grandement facilitée.
Ainsi, non seulement l'invention propose d'utiliser des sessions de signalisation existantes pour véhiculer dans le réseau et aux différents équipements intermédiaires participant à la transmission du flux entre le serveur de contenus et le terminal des informations applicatives, mais ces mêmes sessions de signalisation sont également mises à profit pour notifier la politique de priorisation sélectionnée par le dispositif de gestion et la faire appliquer.
En particulier, la session de signalisation ainsi établie en marge de la session de transmission permet au dispositif de gestion d'obtenir facilement des informations du terminal et de transmettre facilement les décisions prises quant à la priorisation des données relatives au flux. C'est le cas par exemple lorsque l'équipement (ou un des équipements) appliquant à proprement parler la politique de priorisation sélectionnée au flux vidéo est un serveur intermédiaire placé en amont de l'accès du terminal au réseau ou n'est pas sous le contrôle direct de l'opérateur du réseau. Ce serveur peut être par exemple un serveur de livraison ou streamer rattaché à un réseau de diffusion de contenus opérant pour le compte du fournisseur de contenus ou agissant comme fournisseur de contenus.
Dans un mode particulier de réalisation, le procédé de gestion selon l'invention comprend une étape de mise à jour de ladite au moins une politique de priorisation durant la période de démarrage de la session de transmission en fonction de l'état courant du buffer et/ou des conditions de transmission courantes du flux vidéo expérimentées lors de la session sur le réseau.
Une telle mise à jour peut être liée à différents facteurs. Ainsi par exemple, les conditions de transmission expérimentées sur le réseau par la session vidéo peuvent avoir évolué et rendu inadaptée la politique de priorisation sélectionnée. Selon un autre exemple, l'état du buffer peut ne pas évoluer comme souhaité et nécessiter l'adoption d'une autre politique de priorisation, etc. Le dispositif de gestion selon l'invention peut être configuré pour obtenir périodiquement ou à des instants prédéterminés les informations concernant les conditions de transmission de la session et/ou l'état du buffer de sorte à pouvoir intervenir rapidement et adapter efficacement sa politique de priorisation. On note que cette mise à jour n'est réalisée conformément à l'invention que si l'on se trouve toujours dans la période de démarrage de la session.
Dans un mode particulier de réalisation, le procédé comprend :
— durant l'application de ladite au moins une politique de priorisation sélectionnée, au moins une étape d'obtention d'informations représentatives de conditions de transmission du flux vidéo expérimentées lors de la session sur le réseau ; et — une étape d'interruption de l'application de ladite au moins une politique de priorisation sélectionnée si lesdites conditions de transmission sont considérées comme favorables.
Ainsi, la mise à jour de ladite au moins une politique de priorisation peut également consister en une cessation de la priorisation si celle-ci ne s'avère plus nécessaire. De cette sorte, on limite l'impact sur les autres sessions de transmission établies sur le réseau de la priorisation des données du flux vidéo destiné au terminal.
Dans un mode particulier de réalisation, les différentes étapes du procédé de gestion sont déterminées par des instructions de programmes d'ordinateurs.
En conséquence, l'invention vise aussi un programme d'ordinateur sur un support d'informations, ce programme étant susceptible d'être mis en œuvre dans un dispositif de gestion ou plus généralement dans un ordinateur, ce programme comportant des instructions adaptées à la mise en œuvre des étapes d’un procédé de gestion tel que décrit ci-dessus.
Ce programme peut utiliser n'importe quel langage de programmation, et être sous la forme de code source, code objet, ou de code intermédiaire entre code source et code objet, tel que dans une forme partiellement compilée, ou dans n'importe quelle autre forme souhaitable.
L'invention vise aussi un support d'informations ou d'enregistrement lisible par un ordinateur, et comportant des instructions d'un programme d'ordinateur tel que mentionné cidessus.
Le support d'informations ou d'enregistrement peut être n'importe quelle entité ou dispositif capable de stocker le programme. Par exemple, le support peut comporter un moyen de stockage, tel qu'une ROM, par exemple un CD ROM ou une ROM de circuit microélectronique, ou encore un moyen d'enregistrement magnétique, par exemple une disquette (floppy dise) ou un disque dur.
D'autre part, le support d'informations ou d'enregistrement peut être un support transmissible tel qu'un signal électrique ou optique, qui peut être acheminé via un câble électrique ou optique, par radio ou par d'autres moyens. Le programme selon l'invention peut être en particulier téléchargé sur un réseau de type Internet.
Alternativement, le support d'informations ou d'enregistrement peut être un circuit intégré dans lequel le programme est incorporé, le circuit étant adapté pour exécuter ou pour être utilisé dans l'exécution du procédé en question.
L'invention vise également un système de communication comprenant :
— au moins un terminal ;
— au moins un serveur de contenus, apte à fournir un flux vidéo audit terminal lors d'une session de transmission établie avec le terminal ; et — un dispositif de gestion de cette session de transmission conforme à l'invention ; et — au moins un équipement intermédiaire entre le serveur de contenus et le terminal par lequel transite le flux vidéo et apte à appliquer une politique de priorisation sélectionnée par le dispositif de gestion le cas échéant pour ladite session de transmission.
On note que le dispositif de gestion et l'équipement intermédiaire peuvent être, dans un mode particulier de réalisation, colocalisés sur un même équipement.
On peut également envisager, dans d'autres modes de réalisation, que le procédé de gestion, le dispositif de gestion et le système de communication selon l'invention présentent en combinaison tout ou partie des caractéristiques précitées.
Brève description des dessins
D'autres caractéristiques et avantages de la présente invention ressortiront de la description faite ci-dessous, en référence aux dessins annexés qui en illustrent un exemple de réalisation dépourvu de tout caractère limitatif. Sur les figures :
— la figure 1 représente, de façon schématique, un système de communication conforme à l'invention, dans un mode particulier de réalisation, ce système comprenant un dispositif de gestion de sessions de transmission de flux vidéo conforme à l'invention ;
— la figure 2 représente, de façon schématique, l'architecture matérielle du dispositif de gestion de la figure 1 ;
— la figure 3 représente, sous forme d'ordinogramme les principales étapes d'un procédé de gestion d'une session de transmission d'un flux vidéo conforme à l'invention ; et — la figure 4 représente, sous forme de diagramme, les messages de signalisation échangés lors de la mise en œuvre de l'invention.
Description détaillée de l'invention
La figure 1 présente, dans son environnement, un système de communication 1 conforme à l'invention, dans un mode particulier de réalisation.
Dans ce mode de réalisation, le système de communication 1 comprend :
— un terminal 2 d'un utilisateur U ; et — un ou plusieurs serveur de contenus 3 aptes à fournir des flux vidéo, notamment au terminal
2. Ces flux vidéo peuvent être fournis par les serveurs de contenus 3 dans le contexte de divers services, comme par exemple un service de navigation web, un service de vidéo à la demande, un service de diffusion en temps réel (« streaming »), etc.
Dans l'exemple envisagé à la figure 1, le terminal 2 est un terminal mobile apte à communiquer sur un réseau de télécommunications mobile cellulaire AN (réseau d'accès) tel que par exemple un réseau 4G et sur lequel l'utilisateur U peut visualiser des flux vidéo transmis via le réseau mobile AN. Le terminal mobile 2 est équipé à cet effet d'un écran 2A et d'un module de restitution vidéo 2B (ou player vidéo) comprenant un buffer 2C permettant d'engranger des données relatives au flux vidéo en vue de leur restitution en continu sur l'écran 2A du terminal 2.
Aucune limitation n'est toutefois attachée à la nature du réseau sur lequel le terminal 2 est susceptible de communiquer. Il peut s'agir en variante d'un réseau WIFI, 3G, etc.
Le réseau de télécommunications mobile AN comprend, de façon connue, une ou plusieurs stations de base permettant de couvrir les différentes cellules du réseau. On suppose que le terminal mobile 2 est rattachée à la station de base 4.
Le réseau mobile AN est relié ici à un cœur de réseau IP CN via une passerelle convergente (passerelle opérateur) ou CGW (pour Convergent GateWay) 5. De façon connue, une telle passerelle CGW 5 permet avantageusement de relier plusieurs réseaux d'accès fixes, WIFI et mobiles à un même cœur de réseau IP. Elle se trouve entre le réseau mobile AN et le réseau cœur CN, et est localisée ici dans un point d'accès 6 au cœur de réseau CN désigné plus communément par PoP pour « Point of Presence ». Un tel PoP peut concentrer dans un local technique unique différents types d'équipements destinés à interagir.
Dans le mode de réalisation décrit ici, le PoP 6 comprend en outre un serveur 7 de livraison ou streamer apte à délivrer les contenus vidéos hébergés par les serveurs de contenus 3. Ce serveur de livraison 7 est à proprement parler un cache disposant d'un buffer de stockage des données qu'il reçoit, connu en soi.
Le cœur de réseau CN est relié ici au réseau public Internet dans lequel se trouvent les serveurs de contenus 3. Les flux vidéo transitent entre les serveurs de contenus 3 et le terminal 2 par des routeurs, dont un routeur R, représenté dans le réseau CN à titre d'exemple dans la figure
1. Dans l'exemple envisagé ici, les serveurs de contenus 3 sont contrôlés par un opérateur distinct de l'opérateur du réseau d'accès AN et du cœur de réseau CN. Toutefois cette hypothèse n'est pas limitative en soi. Par exemple, un serveur de contenus 3 peut très bien se trouver dans un autre PoP de l'opérateur du réseau CN, suite à des accords spécifiques avec le fournisseur de contenus. Dans ce cas les flux vidéo n'ont pas besoin de transiter par le réseau public Internet.
Dans la suite de la description on désigne indifféremment par réseau de télécommunications, un unique réseau ou un réseau constitué de plusieurs (sous-)réseaux par le(s)quel(s) transitent les communications établies entre le terminal 2 et les serveurs de contenus 3 se trouvant dans le réseau Internet. Dans l'exemple envisagé à la figure 1, le réseau de télécommunications au sens de l'invention comprend ainsi le réseau d'accès AN, le cœur de réseau CN et le réseau Internet. Aucune limitation n'est attachée cependant à la composition de ce réseau.
Comme mentionné précédemment, un problème critique auquel sont confrontés aujourd'hui les opérateurs des réseaux de télécommunications, et incidemment les fournisseurs de contenus proposant des contenus vidéo à leurs clients via ces réseaux, est de limiter la latence expérimentée par les clients au démarrage de leurs sessions de transmission de flux vidéo. Par latence, on entend la durée s'écoulant entre le moment où le client choisit un flux vidéo et active son téléchargement sur le serveur de contenus et le moment où la restitution du flux vidéo débute effectivement sur le terminal du client.
L'invention permet avantageusement de diminuer cette latence en priorisant, sous certaines conditions, les données relatives au flux vidéo sélectionné par le client durant la période de démarrage de la session de transmission de ce flux vidéo. A cet effet, le système de communication 1 comprend un dispositif de gestion de sessions de transmission de flux vidéo conforme à l'invention. Dans le mode de réalisation décrit ici, le dispositif de gestion selon l'invention est intégré dans la passerelle de convergence 5, au niveau du PoP 6. Dans la suite de la description, le dispositif de gestion est donc également référencé par 5, comme la passerelle de convergence.
Dans le mode de réalisation décrit ici, le dispositif de gestion 5 a l'architecture matérielle d'un ordinateur, telle que représentée à la figure 2.
Il comprend notamment un processeur 8, une mémoire vive 9, une mémoire morte 10, une mémoire flash non volatile 11 ainsi que des moyens de communication 12 lui permettant de communiquer notamment avec le terminal 2 sur le réseau de télécommunications mobile AN et avec des équipements du cœur de réseau CN et du réseau Internet, comme par exemple avec les serveurs de contenus 3. De tels moyens sont connus en soi et ne sont pas décrits plus en détail ici. On note ici que ces moyens de communication mettent également en œuvre le protocole SPUD, comme décrit plus en détail ultérieurement.
La mémoire morte 10 du dispositif de gestion 5 constitue un support d'enregistrement conforme à l'invention, lisible par le processeur 8 et sur lequel est enregistré ici un programme d'ordinateur PROG conforme à l'invention.
Le programme d'ordinateur PROG définit des modules fonctionnels et logiciels ici, configurés pour mettre en œuvre les étapes du procédé de gestion de sessions de transmission de flux vidéo selon l'invention. Ces modules fonctionnels s'appuient sur et/ou commandent les éléments matériels 8-12 du dispositif de gestion 5 cités précédemment. Ils comprennent notamment ici, comme illustré sur la figure 1 :
— un module de détection 5A d'un démarrage d'une session de transmission d'un flux vidéo entre un serveur de contenus 3 du réseau Internet et un terminal, tel que le terminal 2 ;
— un premier module d'obtention 5B, activé sur détection d'un démarrage d'une session de transmission d'un flux vidéo par le module de détection 4A et configuré pour obtenir des informations représentatives de conditions de transmission du flux vidéo expérimentées lors de la session sur le réseau séparant le terminal 2 du serveur de contenus 3 fournissant le flux vidéo ;
— des modules activés si lesdites conditions de transmission ne sont pas considérées comme favorables par le premier module d'obtention 5B ces modules comprenant :
o un deuxième module d'obtention 5C, configuré pour obtenir un état courant du buffer 2C du player vidéo 2B utilisé par le terminal 2 pour la restitution du flux vidéo et représentatif d'un niveau de remplissage du buffer ; et o un module de sélection 5D, configuré pour sélectionner une politique de priorisation à appliquer à la transmission du flux vidéo vers le terminal 2 tant que certaines conditions sont respectées. Ces conditions sont, conformément à l'invention, que la session de transmission se trouve dans une période de démarrage au regard d'un critère prédéterminé détaillé ultérieurement et que le niveau de remplissage du buffer 2C est inférieur à un seuil de remplissage prédéterminé noté THR1.
Les fonctions de ces différents modules sont décrites plus en détail maintenant, en référence aux figures 3 et 4.
La figure 3 représente les principales étapes du procédé de gestion d'une session de transmission d'un flux vidéo selon l'invention, telles qu'elles sont mises en œuvre, dans un mode particulier de réalisation, par le dispositif 5 de gestion de la figure 1 pour gérer une session de transmission d'un flux vidéo requis par le terminal 2 auprès d'un des serveurs de contenus vidéo 3 se trouvant dans le réseau Internet. Cette gestion réalisée par le dispositif 5 de gestion s'appuie sur différents messages de signalisation échangés entre les différentes entités (terminal 2, serveur de contenus 3, dispositif de gestion 5), représentés en complément sous forme de diagramme à la figure 4.
On désigne par 3-1 le serveur de contenus auprès duquel le terminal 2 sollicite l'obtention d'un flux vidéo, par exemple par l'intermédiaire ici d'un portail web. Cette transmission de flux vidéo entre le serveur de contenus 3-1 et le terminal 2 est encadrée par une session de transmission https VIDEO_S établie de façon connue en soi entre le serveur de contenus 3-1 et le terminal 2 (étape E10 sur la figure 4). Le flux vidéo transmis dans cette session transite via différents équipements de réseau, et notamment via le PoP 6.
On suppose ici que suite à l'établissement de la session de transmission vidéo VIDEO_S, une session de signalisation conforme au protocole SPUD est établie entre le terminal 2 et le serveur de contenus 3-1. L'établissement d'une telle session SPUD est réalisé via l'envoi d'un message d'initialisation SPUD OPEN par le terminal 2 au serveur de contenus 3-1 spécifiant la source (src=terminal 2) et le destinataire (dest=serveur 3-1) (étape E20). Le serveur de contenus
3-1 répond à ce message d'initialisation via un message SPUD ACK (étape E30). On désigne par SPUD_S cette session.
De façon connue, la session de signalisation SPUD_S est établie en marge (i.e. en plus) de la session de transmission VIDEO_S (c'est une session distincte de la session vidéo). Elle permet l'échange de données applicatives et réseau entre le terminal 2 et le serveur de contenus 3-1. Par ailleurs, de manière avantageuse, le protocole SPUD offre la possibilité à des équipements intermédiaires du réseau d'intercepter les messages s'échangeant dans cette session de signalisation SPUD et d'accéder aux informations qu'elle véhicule (lorsque celles-ci ne sont pas protégées). C'est le cas notamment pour le PoP 6 par lequel transite la session de transmission VIDEO_S et la session de signalisation SPUD associée, et plus particulièrement pour dispositif de gestion 5 embarqué dans ce PoP 6.
En référence à la figure 3, le dispositif de gestion 5 détecte ainsi, via son module de détection 5A, le démarrage de la session de transmission VIDEO_S via la détection de l'initialisation de la session de signalisation SPUD_S, c'est-à-dire du message SPUD OPEN (étape F10).
Dans une variante de réalisation, le module de détection 5A associe un instant Tl à la détection du message SPUD OPEN d'initialisation de la session SPUD_S et un instant T2 à la détection du message d'acquittement SPUD ACK envoyé par le serveur 3-1. La différence entre T2 et Tl permet au module de détection 5A d'avoir une estimation plus précise du début de la session de transmission.
Dans une autre variante encore, le début de la session de transmission peut être détecté en analysant les requêtes et les paquets provenant de l'adresse IP du serveur 3-1.
On suppose, dans le mode de réalisation décrit ici, que seules les sessions de transmission dites collaboratives sont priorisées. Par « collaboratives », on entend ici qu'un accord a été établi préalablement entre l'opérateur du réseau transportant les sessions de transmission et l'opérateur des serveurs de contenus 3 pour gérer les sessions véhiculant les flux vidéo proposé par les serveurs de contenus 3 conformément à l'invention. On suppose ici que cet accord permet au dispositif de gestion 5 de pouvoir accéder et analyser au moins une partie des informations véhiculées dans les sessions SPUD associées aux sessions de transmission des flux vidéo pour mettre en œuvre l'invention. De façon similaire, un tel service peut être proposé aux utilisateurs des terminaux susceptibles d'accéder aux contenus offerts par les serveurs 3. Dans le mode de réalisation décrit ici, une liste COLLAB_L identifiant l'ensemble des serveurs de contenus (ex. via leur adresse IP (Internet Protocol) ou un autre identifiant) concernés par l'accord et/ou les terminaux ayant souscrit auprès de l'opérateur du réseau pour que leurs sessions de transmission soient priorisées le cas échéant conformément à l'invention, est stockée par exemple dans la mémoire non volatile 11 du dispositif de gestion 5. Cette liste COLLAB_L regroupe donc toutes les informations nécessaires pour distinguer les sessions de transmission collaboratives des sessions qui ne le sont pas.
Le dispositif de gestion 5 analyse donc, par l'intermédiaire ici de son module de détection 5A, la session de transmission VIDEO_S et détermine si cette session VIDEO_S est une session collaborative ou pas (étape test F20). A cet effet, le module de détection 5A extrait certains paramètres de la session VIDEO_S comme par exemple l'adresse IP du serveur de contenus 3-1. Puis il compare cette adresse IP aux identifiants de serveurs de contenus présents dans la liste COLLAB_L. On suppose ici que le serveur de contenus 3-1 est identifié dans la liste COLLAB_L (réponse oui à l'étape test F20). Le module de détection 5A en conclut que la session VIDEO_S est collaborative.
Si le module 5A détermine que la session SPUD_S est non collaborative (réponse non à l'étape test E20), alors le procédé de gestion s'arrête (étape F40).
Dans le mode de réalisation décrit ici, le module 5A détermine ensuite si un jeton (ou « token ») valide est présent dans le message d'initialisation SPUD OPEN de la session SPUD envoyé à l'étape F20 (étape test F30). La détection de ce jeton sert à valider que la session de transmission VIDEO_S est bien collaborative.
Un tel jeton peut être chiffré ou non. Dans le mode de réalisation décrit ici, la détection d'un jeton valide conditionne la gestion de la session de transmission VIDEO_S associée à la session SPUD_S conformément à l'invention. Autrement dit, si un tel jeton valide n'est pas présent dans la session SPUD_S (réponse non à l'étape F30), le procédé de gestion selon l'invention n'est pas mis en œuvre (étape F40).
On suppose ici que le module 5A détecte la présence d'un jeton valide dans le message de signalisation SPUD OPEN envoyé à l'étape F20 (réponse oui à l'étape F30). Il en déduit que la session de transmission VIDEO_S est collaborative, autrement dit que les données associées au flux vidéo de cette session vont être gérés et éventuellement priorisés conformément à l'invention.
Cette détection déclenche l'application des étapes du procédé de gestion selon l'invention à la session de transmission VIDEO_S.
Plus particulièrement, cela déclenche l'obtention par le premier module d'obtention 5B d'informations représentatives de conditions de transmission du flux vidéo expérimentées par le terminal 2 sur le réseau lors de la session VIDEO_S, et en particulier sur le réseau d'accès AN (étape F50).
Ces informations sont obtenues par exemple ici via la solution technique MTG (Mobile Thoughput Guidance), normalisée par l'IETF et qui permet à un réseau cellulaire de remonter quasiment en temps réel des informations sur les conditions de transmission du flux vidéo. Ces informations comprennent notamment ici des informations remontées par la station de base 4 sur la cellule à laquelle est rattachée le terminal 2 (ex. identifiant de cellule ou « cell-id »), la localisation du terminal 2, la charge de la cellule, et une indication de débit (ou bande passante) expérimenté par le terminal 2.
Elles sont émises dans la signalisation véhiculée par la session de transmission VIDEO_S (cf. étape E40 sur la figure 4).
Bien entendu, si le réseau d'accès n'est pas un réseau cellulaire mais par exemple un réseau WIFI, d'autres techniques connues peuvent être envisagées pour accéder à ces informations.
Les informations obtenues par le premier module d'obtention 5B sont ensuite analysées par celui-ci pour déterminer si les conditions de transmission dont bénéficient la session de transmission VIDEO_S sont favorables (étape test F60). Par « favorables », on entend ici que les conditions expérimentées par la session sont suffisamment bonnes pour permettre au terminal 2 d'accéder au flux vidéo sans latence excessive. Ceci est déterminé ici par le premier module d'obtention 5B en comparant la charge de la cellule à laquelle est rattaché le terminal 2 par rapport à un seuil THR2 prédéterminé. Ce seuil peut être déterminé expérimentalement.
En variante, si le réseau d'accès AN est un réseau WIFI et non un réseau cellulaire, le module d'obtention 5B compare le nombre de connexions actives sur le point d'accès WIFI considéré par rapport à un nombre de connexions maximum.
D'autres paramètres parmi les informations MTG peuvent être pris en compte par le premier module d'obtention 5B pour déterminer si les conditions de transmission sont favorables ou non, comme par exemple le débit expérimenté par le terminal 2, ou l'identifiant de la cellule, etc.
Si les conditions sont favorables (réponse oui à l'étape test F60), aucun traitement n'est appliqué par le dispositif de gestion 5 et le procédé s'achève (étape F40).
En revanche, si le premier module d'obtention 5B détermine que les conditions ne sont pas favorables (réponse non à l'étape test F60), un temporisateur TEMP est armé par le premier module d'obtention 5B pour une durée T prédéterminée (étape F70). Cette durée T est choisie pour représenter le démarrage de la session de transmission vidéo. Elle peut être choisie expérimentalement, en fonction de retours des fournisseurs de contenus sur les pratiques des utilisateurs et de leurs retours d'expérience (par exemple sur ce qui semble acceptable pour un utilisateur comme latence avant d'accéder à un flux vidéo via son terminal, ceci constituant un critère prédéterminé au sens de l'invention). Par exemple, cette durée est choisie égale à T=2s.
Puis, la priorisation des données relatives au flux vidéo du terminal 2 est déclenchée (étape F80), via l'activation du deuxième module d'obtention 5C et du module de sélection 5D.
Plus particulièrement, le deuxième module d'obtention 5C obtient tout d'abord un état courant STATE du buffer 2C du player 2B du terminal 2 pour la restitution du flux vidéo (étape F90). Cet état courant est représentatif ici d'un niveau de remplissage du buffer 2C avec des données relatives au flux vidéo. Cet état est obtenu ici par le deuxième module d'obtention 5C via un message de signalisation émis par le terminal 2 à destination du serveur de contenus 3-1 dans la session de signalisation SPUD_S (étape E50 de la figure 4), message auquel le serveur de contenus 3-1 répond via un message SPUD ACK (étape E60 de la figure 4). La session SPUD_S étant une session collaborative transitant par le PoP 6, le dispositif de gestion 5, et en particulier son deuxième module d'obtention 5C, peut accéder à la session SPUD_S, l'analyser et obtenir l'état courant du buffer 2C utilisé par le terminal 2. On suppose ici que le terminal 2 est configuré pour émettre périodiquement l'état de son buffer 2C dans un message de signalisation sur la session SPUD_S.
En variante, d'autres informations en plus de l'état du buffer peuvent être obtenues par le deuxième module d'obtention 5B à partir des messages de signalisation échangés dans la session de signalisation SPUD_S, telles que par exemple un type de terminal auquel appartient le terminal 2, un type de service auquel le terminal 2 accède, etc.
En référence de nouveau à la figure 3, l'état STATE du buffer 2C (niveau de remplissage) du player 2B du terminal 2 est ensuite comparé par le module d'obtention au seuil de remplissage prédéterminé THR1 (étape test F100). Ce seuil est choisi préférentiellement de sorte à garantir que les données relatives au flux vidéo engrangées dans le buffer 2C du player 2B du terminal 2 sont en quantité suffisante pour démarrer la visualisation du flux vidéo par l'utilisateur du terminal. On note que par niveau de remplissage on entend ici soit une valeur relative (ex. un pourcentage de remplissage du buffer dès lors que sa taille est connue), soit une valeur absolue (ex. quantité de données stockées dans le buffer ou temps de restitution du flux disponible dans le buffer exprimé en secondes). Le seuil de remplissage THR1 dépend bien entendu de la capacité du terminal 2 et de la qualité de la vidéo reçue ; il peut, à titre indicatif, varier de quelques secondes (ex. 20s) à plusieurs minutes.
Si le deuxième module d'obtention 5B détermine que le niveau de remplissage du buffer 2C est inférieur au seuil THR1 et que le temporisateur TEMP est toujours armé (autrement dit, que la session de transmission se trouve toujours dans une période de démarrage ou encore que la durée T n'est pas encore écoulée) (réponse oui à l'étape test F100), le module 5D de sélection sélectionne une politique de priorisation des données relatives au flux vidéo transmis dans la session VIDEO_S (étape F110).
Si l'une quelconque des deux conditions précitées n'est pas respectée (i.e. le niveau de remplissage STATE est supérieur au seuil THR.1 et/ou le temporisateur TEMP est arrivé à échéance, autrement dit la session de transmission VIDEO_S n'est plus dans une période de démarrage) (réponse non à l'étape test F100), le procédé de gestion s'achève (étape F40).
Dans le mode de réalisation décrit ici, le module 5D de sélection sélectionne comme politique de priorisation une politique POLI qui consiste à supprimer les données relatives aux flux vidéo des sessions de transmission non collaboratives des terminaux appartenant à la même cellule que le terminal 2.
La politique de priorisation POLI sélectionnée par le module 5D de sélection est ensuite notifiée par le dispositif de gestion 5 dans un message MESS(POLl) de signalisation émis dans la session de signalisation SPUD_S à destination d’un routeur R sur la route entre le terminal 2 et le serveur de contenu 3-1 (étape F120, étapes E70 et E80 de la figure 3). Ce message SPUD MESS(POLl) est par exemple un « advice » SPUD qui requiert l'application de la politique de priorisation POLI. Plus particulièrement ici, il requiert la suppression des données relatives aux flux vidéo des sessions de transmission non collaboratives des terminaux appartenant à la même cellule que le terminal 2. Cette politique POLI est destinée à être appliquée par au moins un routeur R du réseau Internet et/ou du cœur de réseau CN par lesquels transitent les sessions de transmission de flux vidéo, et en particulier les sessions de transmission non collaboratives..
Dans un autre mode de réalisation, le module 5D de sélection sélectionne comme politique de priorisation une politique P0L2 qui consiste à supprimer les données relatives aux flux vidéo des sessions de transmission non collaboratives des terminaux appartenant à la même cellule que le terminal 2 et qui présentent une latence supérieure à un seuil de latence prédéterminé TH3. Cette politique P0L2 est destinée à être appliquée également par les routeurs du réseau Internet et/ou du cœur de réseau CN par lesquels transitent les sessions de transmission de flux vidéo, et en particulier les sessions de transmission non collaboratives, d'une façon similaire à la politique POLI.
Dans un autre mode de réalisation encore, le module 5D de sélection sélectionne comme politique de priorisation une politique POL3 qui consiste à adapter la vitesse d'envoi des données vers le terminal en fonction du niveau de remplissage du buffer du terminal et du débit expérimenté par celui-ci. Cette politique P0L3 comprend également ici une redirection de la session de transmission VIDEO_S vers le streamer 7, afin que le flux vidéo destiné au terminal 2 transite par le streamer 7 (le streamer 7 est ainsi un équipement intermédiaire au sens de l'invention). Cette redirection de la session de transmission VIDEO_S vers le streamer 7 est mise en œuvre par le serveur 3-1, qui applique ainsi la politique POL3 sélectionnée par le dispositif de gestion 5 et notifiée dans la session SPUD_S entre le terminal 2 et le serveur 3-1. Alternativement, cette redirection peut être effectuée par un routeur; dans ce cas la politique P0L3 est notifiée dans la session SPUD_S entre le terminal 2 et un routeur R, de façon similaire aux politiques POLI ou POL2.
Dans le mode de réalisation décrit ici, suite à la redirection du flux vidéo destiné au terminal 2, le streamer 7 stocke les données relatives au flux vidéo (i.e. il agit comme un cache) et en application de la politique POL3, module la vitesse d'envoi des données stockées au terminal 2 afin de diminuer la latence expérimentée par l'utilisateur du terminal 2. Plus particulièrement, il module la vitesse d'envoi des données vers le terminal 2 en fonction ici du niveau courant de remplissage de son buffer (i.e. buffer du streamer 7) et du débit du réseau expérimenté par le terminal 2. Cette information est supposée ici disponible dans les informations MTG remontées à l'étape F50.
La vitesse d'envoi des données est modulée ici par le streamer 7 en organisant les données sous forme de bursts qui sont envoyés vers le terminal 2 durant la période de démarrage T. Pour ne pas saturer le lien entre le streamer 7 et le terminal 2, la taille des bursts est choisie de sorte à être conforme au débit du terminal 2 (i.e. à la bande passante dont il dispose). Plus précisément, le streamer 7 choisit ici comme taille de burst B, une fonction de la bande passante dont dispose le terminal 2, de la taille du buffer du streamer 7 et de la taille moyenne d'un paquet du flux vidéo.
Dans un autre mode de réalisation encore, le module 5D de sélection peut sélectionner comme politique de priorisation, une combinaison d'au moins deux politiques sélectionnées parmi les politiques de priorisation POLI, POL2 et POL3 ou d'autres politiques de priorisation pouvant être envisagées. Par exemple, le module 5D de sélection peut sélectionner comme politique de priorisation la combinaison formée de la politique POLI (suppression des paquets des flux vidéo des sessions non collaboratives), et P0L3 (redirection de la session de transmission du terminal 2 vers le streamer 7 et modulation de la vitesse d'envoi des paquets au terminal 2 en fonction du débit dont dispose le terminal 2).
On note qu'une seule politique de priorisation peut être définie par défaut au niveau du module de sélection 5D ou en variante, plusieurs politiques peuvent être définies et l'une d'elles sélectionnée en fonction de divers facteurs comme par exemple la charge du réseau d'accès (charge de la cellule à laquelle est rattachée le terminal 2), la nature de la session, ou encore plusieurs politiques peuvent être définies et hiérarchisées et sélectionnées ensuite suivant l'ordre ainsi établi.
Suite à l'application de la politique sélectionnée POLI par le module de sélection 5D, une surveillance est maintenue par le dispositif de gestion 5 pour détecter si les critères conditionnant l'application de la priorisation des données relatives au flux vidéo du terminal 2 sont toujours respectés (étape test F130). Ces critères comprennent ici la vérification que la session de transmission VIDEO_S est toujours dans une période de démarrage (temporisateur non échu) et que le niveau de remplissage du buffer est inférieur au seuil de remplissage THR1.
Ils peuvent aussi comprendre la vérification que les conditions de transmission du flux vidéo expérimentées par la session VIDEO_S sur le réseau sont toujours défavorables.
Si l'un quelconque de ces critères n'est plus respecté (réponse non à l'étape test F130), la priorisation est interrompue (étape F40).
Si tous les critères sont respectés (réponse oui à l'étape test F130), la priorisation est maintenue (étape F140). Dans le mode de réalisation décrit ici, le module de sélection 5D détermine alors si une mise à jour de la politique de priorisation est nécessaire, par exemple en fonction de l'état courant du buffer et/ou de conditions de transmission courantes du flux vidéo expérimentées lors de la session sur le réseau. Les informations courantes sur l'état du buffer et sur les conditions de transmission peuvent être obtenues via la session de signalisation SPUD_S et les informations MTG remontées périodiquement ou en temps réel par la station de base 4, comme indiqué précédemment (étapes E90, E100 et E110 de la figure 4).
Ainsi par exemple, si l'état courant du buffer est toujours inférieur au seuil de remplissage THR1 à l'issue d'une période Tupd prédéterminée (inférieure bien entendu à la période de démarrage T), le module de sélection 5D peut sélectionner une nouvelle politique de priorisation, telle que par exemple la politique POL2 ou POL3 ou une combinaison des politiques POLI, POL2 et/ou POL3 suivant un ordre préétabli (étape F140).
Lorsque le temporisateur arrive à échéance, la priorisation est interrompue (étape F40). Le dispositif de gestion 5 notifie cette interruption dans un message de signalisation SPUD MESS(STOP POLI) émis dans la session SPUD_S (étape E120 de la figure 3). Ce message est par exemple un « advice » SPUD requérant l'interruption de l'application de la politique POLI (ou de la politique de priorisation en cours si celle-ci a été mise à jour pendant l'étape F140).
L'invention propose ainsi une technique (et une architecture à l'appui de cette technique) consistant à prioriser les données relatives à un flux vidéo transmis vers un terminal dans une session vidéo durant la période de démarrage de la session pour diminuer la latence perçue par l'utilisateur du terminal. On note que dans le mode de réalisation décrit ici, pour déterminer si la session vidéo est dans une période de démarrage, une durée T associée à cette période a été considérée et un temporisateur a été armé pour cette période. En variante, la période de démarrage peut être identifiée en fonction d'une quantité de données (ex. nombre de paquets de données) relatives au flux vidéo émise par le serveur de contenus et comparée à une quantité maximale prédéterminée.

Claims (16)

  1. REVENDICATIONS
    1. Procédé de gestion d'une session de transmission (VIDEO_S) d'un flux vidéo entre un serveur de contenus (3-1) et un terminal (2) via un réseau de télécommunications, ledit procédé de gestion comprenant, suite à une détection (F10) d'un démarrage de la session :
    — une étape (F50) d'obtention d'informations représentatives de conditions de transmission du flux vidéo expérimentées lors de la session sur le réseau ;
    — si lesdites conditions de transmission ne sont pas considérées comme favorables (F60) :
    o une étape d'obtention (F90) d'un état courant d'un buffer utilisé par un module de restitution du terminal pour la restitution du flux vidéo et représentatif d'un niveau de remplissage du buffer ; et o une étape de sélection (Fl 10) d'au moins une politique de priorisation à appliquer à la transmission du flux vidéo vers le terminal tant que la session de transmission se trouve dans une période de démarrage au regard d'un critère prédéterminé et que le niveau de remplissage du buffer est inférieur à un seuil de remplissage prédéterminé.
  2. 2. Procédé selon la revendication 1 dans lequel ledit état courant du buffer est obtenu à partir d'un message de signalisation émis par le terminal dans une session de signalisation (SPUD_S) établie avec le serveur de contenus en association avec la session de transmission du flux vidéo.
  3. 3. Procédé selon la revendication 2 dans lequel le message de signalisation et la session de signalisation sont conformes au protocole SPUD.
  4. 4. Procédé selon la revendication 2 ou 3 dans lequel la détection (F10) du démarrage de la session de transmission vidéo comprend une détection de l'établissement de la session de signalisation entre le terminal et le serveur de contenus.
  5. 5. Procédé selon l'une quelconque des revendications 2 à 4 comprenant en outre une étape préliminaire (F20,F30) de détermination si la session de signalisation associée à la session de transmission du flux vidéo est ou non une session dite collaborative, une politique de priorisation n'étant appliquée à la transmission du flux vidéo que si la session de signalisation est une session collaborative.
  6. 6. Procédé selon l'une quelconque des revendications 1 à 5 dans lequel les étapes d'obtention d'un état courant du buffer et l'étape de sélection d'au moins une politique de priorisation sont conditionnées par la détection (F30) d'un jeton valide dans un message de signalisation émis par le terminal.
  7. 7. Procédé selon l'une quelconque des revendications 1 à 6 dans lequel ladite au moins une politique de priorisation est sélectionnée parmi au moins :
    — une politique de suppression de données émises sur le réseau et relatives à au moins un flux vidéo d'au moins une session de transmission établie avec au moins un autre terminal ;
    — une politique de suppression de données émises sur le réseau et relatives à au moins un flux vidéo d'au moins une session de transmission établie avec au moins un autre terminal lorsque ladite au moins une session de transmission présente une latence supérieure à un seuil de latence prédéterminé ; et — une politique d'adaptation d'une vitesse d'envoi vers le terminal, par un équipement intermédiaire entre le serveur de contenus et le terminal, des données relatives au flux vidéo de la session de transmission en fonction d'un niveau de remplissage d'un buffer de l'équipement intermédiaire et d'un débit du réseau expérimenté par le terminal.
  8. 8. Procédé selon l'une quelconque des revendications 2 à 4 dans lequel la politique de priorisation sélectionnée est notifiée (F120) dans un message de signalisation émis dans la session de signalisation établie avec le serveur de contenus, ledit message de signalisation requérant l'application de ladite au moins une politique de priorisation par au moins un équipement intermédiaire entre le serveur de contenus et le terminal par lequel transite le flux vidéo.
  9. 9. Procédé selon l'une quelconque des revendications 1 à 8 comprenant une étape de mise à jour (F140) de ladite au moins une politique de priorisation durant la période de démarrage de la session de transmission en fonction de l'état courant du buffer et/ou de conditions de transmission courantes du flux vidéo expérimentées lors de la session sur le réseau.
  10. 10. Procédé selon l'une quelconque des revendications 1 à 9 comprenant :
    — durant l'application de ladite au moins une politique de priorisation sélectionnée, au moins une étape d'obtention (F130) d'informations représentatives de conditions de transmission du flux vidéo expérimentées lors de la session sur le réseau ; et — une étape d'interruption (F40) de l'application de ladite au moins une politique de priorisation sélectionnée si lesdites conditions de transmission sont considérées comme favorables.
  11. 11. Procédé selon l'une quelconque des revendications 1 à 10 dans lequel la session de transmission se trouve dans une période de démarrage si une période de temps écoulée depuis le démarrage de la session de transmission est inférieure à une période maximale prédéterminée ou une quantité de données relatives au flux vidéo émise par le serveur de contenus est inférieure à une quantité maximale prédéterminée.
  12. 12. Programme d'ordinateur (PROG) comportant des instructions pour l'exécution des étapes du procédé de gestion selon l'une quelconque des revendications 1 à 11 lorsque ledit programme est exécuté par un ordinateur.
  13. 13. Support d'enregistrement lisible par un ordinateur sur lequel est enregistré un programme d'ordinateur comprenant des instructions pour l'exécution des étapes du procédé de gestion selon l'une quelconque des revendications 1 à 11.
  14. 14. Dispositif de gestion (5) d'une session de transmission (VIDEO_S) d'un flux vidéo entre un serveur de contenus et un terminal via un réseau de télécommunications, ledit dispositif de gestion comprenant :
    — un module de détection (5A) d'un démarrage de la session ;
    — un premier module d'obtention (5B), activé sur détection d'un démarrage de la session par le module de détection et configuré pour obtenir des informations représentatives de conditions de transmission du flux vidéo expérimentées lors de la session sur le réseau ;
    — des modules activés si lesdites conditions de transmission ne sont pas considérées comme favorables par le premier module d'obtention comprenant :
    o un deuxième module d'obtention (5C), configuré pour obtenir un état courant d'un buffer utilisé par un module de restitution du terminal pour la restitution du flux vidéo et représentatif d'un niveau de remplissage du buffer ; et o un module de sélection (5D), configuré pour sélectionner au moins une politique de priorisation à appliquer à la transmission du flux vidéo vers le terminal tant que la session de transmission se trouve dans une période de démarrage au regard d'un critère prédéterminé et que le niveau de remplissage du buffer est inférieur à un seuil de remplissage prédéterminé.
  15. 15. Dispositif de gestion (5) selon la revendication 14 caractérisé en ce qu'il est compris dans un point d'accès (6) au réseau.
  16. 16. Système de communication (1) comprenant :
    — au moins un terminal (2) ;
    — au moins un serveur de contenus (3-1), apte à fournir un flux vidéo audit terminal lors d'une session de transmission établie avec le terminal ; et — un dispositif de gestion (5) de cette session de transmission selon la revendication 14 ; et — au moins un équipement intermédiaire (7, R) entre le serveur de contenus et le terminal par lequel transite le flux vidéo et apte à appliquer au moins une politique de priorisation sélectionnée par le dispositif de gestion le cas échéant pour ladite session de transmission.
    1/3
FR1656270A 2016-06-30 2016-06-30 Procede et dispositif de gestion d'une session de transmission d'un flux video Pending FR3053556A1 (fr)

Priority Applications (2)

Application Number Priority Date Filing Date Title
FR1656270A FR3053556A1 (fr) 2016-06-30 2016-06-30 Procede et dispositif de gestion d'une session de transmission d'un flux video
PCT/FR2017/051558 WO2018002469A1 (fr) 2016-06-30 2017-06-15 Procédé et dispositif de gestion d'une session de transmission d'un flux vidéo

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR1656270 2016-06-30
FR1656270A FR3053556A1 (fr) 2016-06-30 2016-06-30 Procede et dispositif de gestion d'une session de transmission d'un flux video

Publications (1)

Publication Number Publication Date
FR3053556A1 true FR3053556A1 (fr) 2018-01-05

Family

ID=57583157

Family Applications (1)

Application Number Title Priority Date Filing Date
FR1656270A Pending FR3053556A1 (fr) 2016-06-30 2016-06-30 Procede et dispositif de gestion d'une session de transmission d'un flux video

Country Status (2)

Country Link
FR (1) FR3053556A1 (fr)
WO (1) WO2018002469A1 (fr)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2024138451A1 (fr) * 2022-12-28 2024-07-04 Intel Corporation Appareils, dispositifs, procédés et programmes informatiques pour un nœud travailleur et un serveur edge

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP2665239A1 (fr) * 2012-05-14 2013-11-20 Alcatel-Lucent Nýud de réseau sensible à la diffusion adaptative, client et procédé avec marquage prioritaire
US20150304737A1 (en) * 2014-04-17 2015-10-22 Samsung Electronics Co. Ltd. QoE PROVISIONING METHOD AND APPARATUS FOR MOBILE VIDEO APPLICATION

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP2665239A1 (fr) * 2012-05-14 2013-11-20 Alcatel-Lucent Nýud de réseau sensible à la diffusion adaptative, client et procédé avec marquage prioritaire
US20150304737A1 (en) * 2014-04-17 2015-10-22 Samsung Electronics Co. Ltd. QoE PROVISIONING METHOD AND APPARATUS FOR MOBILE VIDEO APPLICATION

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
SMITH H M ET AL: "FAIR LINK SHARING WITH LAYERED MULTICAST VIDEOCONFERENCING", GLOBECOM'00. 2000 IEEE GLOBAL TELECOMMUNICATIONS CONFERENCE. SAN FRANCISCO, CA, NOV. 27 - DEC. 1, 2000; [IEEE GLOBAL TELECOMMUNICATIONS CONFERENCE], NEW YORK, NY : IEEE, US, vol. 3, 27 November 2000 (2000-11-27), pages 1360 - 1364, XP001195656, ISBN: 978-0-7803-6452-3 *

Also Published As

Publication number Publication date
WO2018002469A1 (fr) 2018-01-04

Similar Documents

Publication Publication Date Title
US20150256577A1 (en) Directing Fragmented Content
EP3155823B1 (fr) Gestion par un équipement intermédiaire de la qualité de transmission d'un flux de données vers un terminal mobile
EP2025181B1 (fr) Systeme d'acces a un service de television sur ip dans un reseau a architecture ims
EP2366238B1 (fr) Procede et systeme de regulation du trafic de redemarrage dans un reseau de telecommunications
WO2015044597A1 (fr) Procédé d'accès d'un utilisateur a au moins un service de communication fourni par l'intermédiaire d'un centre informatique d'un système d'informatique en nuage
EP3646196B1 (fr) Procédé et dispositif de téléchargement de contenu audiovisuel
EP3807760B1 (fr) Procédé d'installation d'une fonction réseau virtualisée
EP2706730B1 (fr) Procédé et dispositif de suggestion d'applications
EP2332332A1 (fr) Procede et dispositif de redirection d'une requete de controle d'un flux de donnees
FR3053556A1 (fr) Procede et dispositif de gestion d'une session de transmission d'un flux video
EP3149918B1 (fr) Téléchargement de contenu et mise a disposition de réseaux
FR2962284A1 (fr) Procede, dispositif et systeme de gestion de sessions de communication
EP2105854A1 (fr) Procédé de détermination de données complémentaires relatives à au moins un contenu, procédé pour transmettre ces données complémentaires, dispositif de traitement et serveur d'applications associés
EP3777106A1 (fr) Procédé de gestion d'un groupe d'équipements, serveur et système associés
EP3840300B1 (fr) Réception d'un flux de données via une passerelle de communication
FR3019429A1 (fr) Procede et dispositif de controle d'un telechargement de contenus multimedia
WO2013045815A1 (fr) Procede et dispositif de gestion dynamique de la distribution de donnees dans un reseau de telecommunications
EP4409864A1 (fr) Procédé de controle d'un accès à un service applicatif mis en oeuvre dans un réseau de télécommunications, procédé de traitement d'un message de controle d'un accès audit service applicatif, dispositifs, équipement de controle, équipement client, système et programmes d'ordinateur correspondants
EP4335144A1 (fr) Parametrage d'un terminal
FR2979505A1 (fr) Procede d'insertion d'un equipement intermediaire permettant le controle a distance de la qualite d'une communication
FR2988885A1 (fr) Base de donnees, serveur hss, et serveurs de controle d'un reseau ims
FR3131815A1 (fr) Procédé, dispositif et système de modification d’une infrastructure de communication
WO2010112738A1 (fr) Procede d'envoi d'un message de notification, serveur de sessions d'acces et systeme de communications
WO2011101576A1 (fr) Gestion d'acces a un service dans un reseau
WO2013102716A1 (fr) Procede dynamique de determination d'une liste de services dans un reseau sip

Legal Events

Date Code Title Description
PLFP Fee payment

Year of fee payment: 2

PLSC Publication of the preliminary search report

Effective date: 20180105