FR 3052318 A1 20171208 FR 1655058 A 20160603 1 PROCEDE D'ACCES A UN SERVICE TRANSMIS EN MODE TELEDIFFUSION SUR UN RESEAU MOBILE La présente invention concerne la transmission de données telles que des données multimédia, diffusées en temps réel (en direct) ou en temps différé, à la demande. La présente invention concerne en particulier la fourniture de contenus ou services MBMS (Multimedia Broadcast and Multicast Service) par l'intermédiaire de réseaux mobiles ou cellulaires. Les réseaux de communication mobiles sont largement déployés pour fournir des services de communication variés, tels que des services de communication vocale, des services de messagerie, des services de transmission de vidéo, ou de données sous la forme de paquets. Ces 10 réseaux mobiles sont généralement des réseaux à accès multiple, capables de supporter un grand nombre d'utilisateurs en partageant les ressources disponibles. Les réseaux de communication mobiles peuvent comprendre des stations de base assurant la communication entre les réseaux mobiles et les 15 terminaux des utilisateurs, chaque terminal d'utilisateur pouvant disposer dans un réseau d'un lien de communication montant, du terminal d'utilisateur vers une station de base, et d'un lien de communication descendant, de la station de base vers le terminal d'utilisateur. Le projet 3GPP-LTE (Third Generation Partnership Project - Long 20 Term Evolution) constitue une avancée majeure dans le domaine des technologies des réseaux cellulaires telles que GSM (Global System for Mobile communications) et UMTS (Universal Mobile Telecommunications System). LTE fait référence à une couche physique fournissant un moyen efficace de transmettre à la fois des données et des informations de contrôle 25 entre les stations de base et les terminaux d'utilisateurs. Le projet 3GPP-LTE définit notamment deux modes de communication entre les terminaux d'utilisateurs et les stations de base, à savoir le mode monodiffusion ou point à point (unicast), le mode de multidiffusion ou point à multipoint (multicast) ou le mode télédiffusion 30 (broadcast). Dans le mode monodiffusion, des signaux porteurs d'information sont transmis directement à un unique terminal d'utilisateur. Dans les modes 3052318 2 multidiffusion et télédiffusion, une ou plusieurs stations de base diffusent des signaux porteurs d'information d'une manière synchronisée à tous les terminaux d'utilisateurs se trouvant à la portée des stations de base. Les terminaux récepteurs sont identifiés dans le mode multidiffusion, mais pas 5 dans le mode télédiffusion. Les modes de multidiffusion et télédiffusion permettent d'utiliser plus efficacement les ressources du réseau que le mode monodiffusion, lorsque les mêmes informations sont demandées en même temps par plusieurs utilisateurs, comme des informations relatives à un événement, transmises en direct ou en temps réel. La demande de services basés sur le mode multidiffusion ou télédiffusion tend à se développer rapidement, notamment pour limiter la saturation des réseaux mobiles. La transmission d'informations telles que des contenus vidéo, peut être effectuée par différents moyens dans les réseaux de communication. Dans le cas d'un contenu vidéo par exemple, cette transmission peut être effectuée de la source du contenu à l'écran d'affichage de différentes manières selon le mode monodiffusion, ou multidiffusion ou télédiffusion. Dans le mode monodiffusion, le contenu est transmis directement à un terminal d'utilisateur ciblé. A cet effet, le terminal ciblé doit disposer d'une adresse URL (Uniform Resource Locator) de la source du contenu, typiquement un serveur vidéo, et peut émettre une commande HTTP GET à destination du serveur vidéo. En réponse à cette commande, le contenu peut être transmis en mode monodiffusion sous la forme de séquences de petits fichiers appelés "segments" comme dans le format DASH (Dynamic Adaptive Streaming over HTTP) ou HLS (HTTP Live Streaming), ce qui permet de restituer le contenu pendant son acquisition et/ou de le stocker pour une restitution ultérieure. Les transmissions en mode multidiffusion ou télédiffusion, telles que celles offertes par le service eMBMS (Evolved Multimedia Broadcast / Multicast Service), présentent différentes spécificités du fait qu'elles sont effectuées avec plusieurs terminaux récepteurs. Pour établir de telles transmissions, les terminaux récepteurs peuvent obtenir des informations sur un contenu diffusé avant que l'application concernée installée dans les terminaux soit activée pour obtenir ces informations. Chaque terminal récepteur peut stocker ces informations dans une mémoire cache locale. Lorsque l'application concernée est activée et transmet une adresse URL 3052318 3 pour demander ces informations, l'adresse URL générée peut pointer sur les informations déjà stockées dans la mémoire cache locale plutôt que sur le serveur fournissant le contenu, comme dans le mode monodiffusion. L'environnement DASH combiné au mode de transport de fichiers 5 FLUTE (File Delivery over Unidirectional Transport) peut être utilisé en mode multidiffusion ou télédiffusion. Selon cette combinaison, un contenu peut être converti en segments DASH qui sont assemblés en paquets par un moteur FLUTE FPE (FLUTE Package Engine) qui transmet les paquets dans le réseau. La structure des segments DASH est spécifiée par le format 10 ISOBMFF (ISO Base Media File Format) ou par le format MPEG2 TS (MPEG Transport Stream). Une méthode MooD (MBMS operation on Demand) a été proposée pour passer à la volée, d'une manière transparente pour l'utilisateur, du mode monodiffusion au mode télédiffusion et réciproquement, lors de la 15 transmission d'un contenu en temps réel ou en direct, notamment en fonction du nombre d'utilisateurs demandant le contenu dans une région où est situé le terminal de l'utilisateur. Cette méthode est spécifiée notamment dans les documents 3GPP TS 26.346 et 3GPP TR 26.849). Selon cette méthode, les passages entre les modes monodiffusion et télédiffusion sont réalisés à 20 l'initiative du réseau en fonction du nombre de demandes d'un même contenu, émises par les utilisateurs. Lors de l'accès à nouveau contenu, le terminal peut avoir besoin de déterminer si le contenu est diffusé en mode télédiffusion. A cet effet, le terminal d'utilisateur doit requérir la liste des contenus diffusés dans ce mode 25 ou susceptibles de l'être. Il peut également accéder à une adresse diffusant tous les contenus actuellement accessibles en mode télédiffusion. Ces opérations permettent d'obtenir des métadonnées relatives à chaque contenu disponible, incluant notamment des données d'accès au contenu diffusé en mode télédiffusion et des données d'horaire de diffusion. Il s'avère 30 que les métadonnées transmises pour un seul contenu sont volumineuses. Le nombre de contenus susceptibles d'être diffusés en mode télédiffusion dans une région tend à augmenter et peut devenir important dans un avenir proche. Il en résulte que l'acquisition de ces données pour tous les contenus possibles peut représenter pour les terminaux d'utilisateurs une charge 35 considérable en termes de volume de données à recevoir, de traitement, et 3052318 4 de stockage, et donc en termes de consommation électrique pour les terminaux et de consommation de bande passante pour les réseaux. En outre, lorsqu'il s'agit de basculer du mode monodiffusion vers le mode télédiffusion, le terminal d'utilisateur dispose déjà de toutes les métadonnées 5 nécessaires pour accéder au contenu en mode télédiffusion, sauf les métadonnées relatives à l'adresse d'accès du contenu en mode télédiffusion. Il s'avère également que la liste des contenus susceptibles d'être diffusés en mode télédiffusion est figée peut varier très fréquemment, et ne contient pas notamment des contenus transmis en temps différé et des 10 contenus accessibles par contournement ("over-the-top services"), c'est-à- dire des contenus non référencés par l'opérateur de réseau assurant la distribution des contenus. Il s'agit par exemple de contenus vidéo diffusés par des fournisseurs de contenu tels que YouTube ou Netflix. Il est donc souhaitable de permettre aux terminaux d'utilisateur de 15 pouvoir déterminer simplement si un contenu particulier est disponible en mode télédiffusion et de requérir les données nécessaires pour accéder à ce contenu, sans avoir à recevoir des informations relatives à tous les autres contenus disponibles dans le mode télédiffusion. Il peut être également souhaitable de permettre à un serveur donnant accès à des contenus en 20 mode monodiffusion de déterminer facilement le nombre de terminaux d'utilisateurs souhaitant accéder à un même contenu, afin de transmettre le contenu en mode monodiffusion ou télédiffusion en fonction de ce nombre. Il peut également être souhaitable de pouvoir diffuser un contenu en mode télédiffusion, y compris lorsque le contenu n'est pas produit en temps réel ou 25 diffusé en direct. Des modes de réalisation concernent un procédé d'accès à un service de diffusion de contenu, en temps réel ou différé, accessible sur un serveur de contenu, le procédé étant mis en oeuvre dans un terminal d'utilisateur connecté à un réseau mobile ou sans fil, et comprenant des 30 étapes consistant à : obtenir une adresse d'accès à un service, transmettre à un serveur de diffusion de services, une requête de métadonnées contenant une adresse d'accès à un service accessible en mode monodiffusion, et si le service est disponible en mode télédiffusion, recevoir des métadonnées relatives au service, contenant des données d'adresse d'accès au service en 35 mode télédiffusion et des données d'horaire de diffusion, et recevoir le 3052318 5 contenu correspondant au service en mode télédiffusion à un moment conforme aux données d'horaire de diffusion. Selon un mode de réalisation, le procédé comprend une étape de réception par le terminal d'utilisateur d'une notification indiquant que le 5 service demandé peut être disponible en mode télédiffusion à l'issue d'un délai d'attente spécifié dans la notification, si le service peut devenir disponible en mode télédiffusion. Selon un mode de réalisation, le procédé comprend une étape de programmation de la transmission au serveur de diffusion d'une nouvelle 10 requête de métadonnées d'accès au service, en tenant compte du délai d'attente reçu dans la notification. Des modes de réalisation peuvent également concerner un produit programme d'ordinateur directement chargeable dans une mémoire interne d'un terminal et comprenant des portions de code qui lorsqu'elles sont 15 exécutées par le terminal configurent le terminal pour mettre en oeuvre les étapes du procédé défini précédemment. Des modes de réalisation peuvent également concerner un procédé de fourniture d'un service de diffusion de contenu, en temps réel ou différé, accessible sur un serveur de contenu, mis en oeuvre par un serveur de 20 diffusion par l'intermédiaire d'un réseau mobile ou sans fil, le procédé comprenant des étapes consistant à : recevoir d'un terminal d'utilisateur une requête de métadonnées contenant une adresse d'accès à un service accessible en mode monodiffusion, déterminer si le service est disponible en mode télédiffusion, et si le service est disponible en mode télédiffusion, 25 transmettre au terminal d'utilisateur des métadonnées relatives au service, contenant des données d'adresse d'accès au service en mode télédiffusion et des données d'horaire de diffusion, et transmettre en mode télédiffusion un contenu correspondant au service à un moment conforme aux données d'horaire de diffusion. 30 Selon un mode de réalisation, le procédé comprend une étape de transmission par le serveur de diffusion au terminal d'utilisateur d'une notification indiquant que le service demandé peut être disponible en mode télédiffusion à l'issue d'un délai d'attente spécifié dans la notification, si le service peut devenir disponible en mode télédiffusion, 3052318 6 Selon un mode de réalisation, le procédé comprend une étape de mémorisation par le serveur de diffusion que le service a été demandé à partir d'une zone du réseau mobile définie par une donnée de localisation figurant dans la requête de métadonnées, en relation avec la donnée de 5 localisation et des identifiants du service. Selon un mode de réalisation, le procédé comprend des étapes consistant à : compter par le serveur de diffusion un nombre de terminaux d'utilisateur ayant émis une requête d'accès au service à partir de la zone du réseau définie par la donnée de localisation, et lorsque le nombre de 10 terminaux d'utilisateurs ayant émis une requête d'accès au service dans la zone du réseau mobile, dépasse une valeur de seuil, programmer par le serveur de diffusion la diffusion du service en mode télédiffusion à un horaire de diffusion. Selon un mode de réalisation, la diffusion du service en mode 15 télédiffusion comprend des étapes consistant à : télécharger et mémoriser par le serveur de diffusion des métadonnées relatives au service, mettre à jour par le serveur de diffusion les métadonnées relatives au service pour donner au service une nouvelle adresse d'accès correspondant au serveur de diffusion, et pour y mentionner des horaires de diffusion du service en 20 mode télédiffusion, télécharger par le serveur de diffusion le contenu fourni par le service depuis un serveur de contenu identifié dans les métadonnées téléchargées, et stocker localement le contenu pour le transmettre en mode télédiffusion en respectant un horaire spécifié par les données d'horaire de diffusion. 25 Selon un mode de réalisation, le service appartient à un groupe de services comprenant : des services d'accès à des contenus transmis en temps réel, des services de fourniture de contenus transmis en mode continu, des services de téléchargement de fichiers, et des services de fourniture de flux RSS ou Atom. 30 Selon un mode de réalisation, la requête de métadonnées comprend au moins l'une des données suivantes : des données relatives aux capacités du terminal d'utilisateur, une langue souhaitée pour la fourniture du service, un délai d'attente ou une plage horaire de disponibilité d'un utilisateur du terminal pour accéder au service, des données de localisation du terminal 35 d'utilisateur, une date de début de contenu à transmettre dans le cas où le 3052318 7 service fournit un flux RSS ou Atom, et une référence à une partie du contenu fourni par le service, attendue par l'utilisateur du terminal. Selon un mode de réalisation, les métadonnées comprennent des données d'identification d'un réseau mobile ou sans fil dans lequel le service 5 sera fourni en mode télédiffusion, et optionnellement, des données de localisation du réseau. Des modes de réalisation peuvent également concerner un produit programme d'ordinateur directement chargeable dans une mémoire interne d'un serveur et comprenant des portions de code qui lorsqu'elles sont 10 exécutées par le serveur configurent le serveur pour mettre en oeuvre les étapes du procédé mis en oeuvre par un serveur de diffusion, défini précédemment. Des modes de réalisation peuvent également concerner un serveur de diffusion et un terminal configurés pour mettre en oeuvre les procédés 15 définis précédemment. Des exemples de réalisation de l'invention seront décrits dans ce qui suit, à titre non limitatif en relation avec les figures jointes parmi lesquelles : la figure 1 représente schématiquement un système fournissant des 20 services de monodiffusion et de télédiffusion de contenus, la figure 2 représente schématiquement différentes couches logicielles mises en oeuvre dans un terminal mobile pour accéder à des contenus transmis en monodiffusion ou télédiffusion, la figure 3 représente des étapes d'un procédé de transmission de 25 contenus entre un serveur de contenu et un terminal mobile, selon un mode de réalisation, la figure 4 représente des données structurées transmises au terminal mobile pour accéder à un contenu, la figure 5 représente des étapes d'un procédé de transmission d'un 30 contenu entre un serveur de contenu et un terminal mobile, selon un autre mode de réalisation, la figure 6 représente des étapes d'un procédé de transmission de contenus entre un serveur de contenu et un terminal mobile, selon un autre mode de réalisation, 3052318 8 La figure 1 représente un système offrant des services de fourniture de contenus tels que des contenus multimédia en mode continu (streaming) ou par téléchargement de fichiers, ces contenus étant transmis en monodiffusion ou télédiffusion. Ce système comprend un ou plusieurs 5 serveurs de contenu CNTP, un ou plusieurs réseaux IPN de transmission par paquets selon le protocole IP (Internet Protocol), un ou plusieurs serveurs BMS offrant des services MBMS (Multimedia Broadcast and Multicast Service) ou eMBMS (extended MBMS), reliés aux serveurs de contenus CNTP par un ou plusieurs des réseaux IPN, des réseaux mobiles MNT, une 10 ou plusieurs passerelles MGW établissant chacune un lien entre l'un des réseaux IPN et l'un des réseaux mobiles, et des terminaux mobiles UM connectés chacun à un ou plusieurs des réseaux mobiles MNT. Les réseaux mobiles peuvent comprendre des réseaux cellulaires tels que 3G, LTE (4G), 5G, ou encore des réseaux sans fil tels que WiFi, Wimax, Bluetooth. 15 Les contenus diffusés par les serveurs de contenu peuvent être des données multimédia (vidéo, audio, pages web), ou des fichiers contenant de telles données multimédia ou une application susceptible d'être installée dans l'un des terminaux UM, ou encore des flux RSS (Really Simple Syndication ou Rich Site Summary) ou Atom. Les terminaux UM peuvent être 20 des téléphones "intelligents" (smartphones) ou des tablettes numériques, ou tout type d'ordinateur disposant de circuits pour se connecter à l'un des réseaux mobiles MNT et pour restituer un contenu multimédia fourni par l'un des serveurs de contenu CNTP, La figure 2 représente différentes couches logicielles mises en oeuvre 25 dans un terminal mobile UM pour accéder à des contenus transmis en monodiffusion ou télédiffusion. Ces couches logicielles correspondent aux couches réseau telles que définies dans le modèle OSI (Open System Interconnection). Ces couches logicielles comprennent une couche applicative APPS regroupant toutes les applications installées dans le 30 terminal mobile et accédant à des couches de services de réception de contenu. Les couches de service de réception sont de deux types permettant de recevoir des contenus soit exclusivement en mode monodiffusion UC, soit en mode MBMS mettant en oeuvre l'un ou l'autre des modes mono- et télédiffusion UC / BC. Ces couches comprennent des éléments relatifs à la 35 sécurité qui ne sont pas représentés. 3052318 9 En partant du plus haut niveau, sous la couche applicative APPS, les couches logicielles spécifiques du mode monodiffusion UC comprennent, en parallèle, un service SANU d'annonce fournissant des métadonnées relatives aux contenus fournis par des services de contenus, des services ADPU de 5 procédures de fourniture associées, regroupant notamment un service FREP de réparation de fichier pour traiter les erreurs de transmission, et un service RAPR de rapport sur la qualité de la réception fournissant des données statistiques relatives à la réception qui peuvent être transmises par exemple au serveur BMS. Les données produites par les couches SANU et ADPU 10 sont transmises par une couche UHT mettant en oeuvre le protocole HTTP (HyperText Transfer Protocol). Les données transmises par la couche UHT sont encapsulées et transmises par une couche UTCP de transport mettant en oeuvre le protocole TCP (Transmission Control Protocol). Les données transmises par la couche UTCP sont mises en paquets par une couche IPUC 15 de réseau mettant en oeuvre le protocole IP, Enfin une couche PTPB de liaison point à point correspondant à la mise en oeuvre d'un canal de transmission par radio, transmet les paquets IP produits par la couche IPUC. En partant du plus haut niveau sous la couche applicative APPS, les couches logicielles spécifiques du mode MBMS (UC / BC) comprennent, en 20 parallèle, un service SANN d'annonce des flux disponibles, notamment les flux transmis en mode télédiffusion, un service DWL de téléchargement de fichiers de différents formats, des services ADP de procédures de fourniture associées, et des services STCD de transmission de contenu en mode continu. Les services STCD incluent des CODECs audio, vidéo, voix, texte, 25 etc., et un service DSHC de réception de flux mettant en oeuvre le protocole DASH. Le service ADP comprend notamment un service FMRP de réparation de fichier pour traiter les erreurs de transmission en mode télédiffusion. En dessous de la couche STCD, se trouvent un service RTPF de formatage de flux transmission, incluant notamment des services SRTP, 30 RTP, RTCP de transport et de contrôle de transport de flux en temps réel, sécurisés ou non, et un service FEC de réparation de fichiers pour corriger les éventuelles erreurs de transmission. En dessous de la couche DSHC, se trouve une couche HTPC mettant en oeuvre le protocole HTTP. En dessous des couches DSHC, DWL, FMRP et SANN se trouve une couche FLT 35 mettant en oeuvre le protocole FLUTE incluant un service FFEC de 3052318 10 correction d'erreur de transmission. En dessous des couches RTPF (FEC) et FLT, se trouve une couche MUDP mettant en oeuvre le protocole UDP (User Datagram Protocol). En dessous de la couche HTPC, se trouve une couche MTC mettant en oeuvre le protocole TCP. En dessous des couches MUDP et 5 MTC, se trouve une couche de réseau IPMU mettant en oeuvre le protocole IP en mode point à point ou point à multipoint. Enfin, une couche MTB de liaison point à point ou à multipoint assure la transmission des paquets IP générés par la couche IPMU. La figure 3 représente des étapes S1 à S16 d'une procédure d'accès 10 par un terminal mobile UM à un service de fourniture d'un contenu diffusé en temps réel ou en temps différé, le contenu étant accessible sur un serveur de contenu CNTS. Dans le terminal UM, cette procédure est mise en oeuvre par une application APP d'accès et de restitution de contenus, un module DSHC configuré pour recevoir des contenus au format DASH ou HLS, un module 15 LHPC de mise en cache pour stocker temporairement des données reçues, et un module MBMC mettant en oeuvre le protocole MBMS. Le terminal UM communique avec le serveur de contenu CNTS par l'intermédiaire d'un serveur BMS comprenant une fonction de serveur proxy PXSF et une fonction d'annonce SANF de services de diffusion de contenu disponibles, en 20 liaison avec le service d'annonce SANU ou SANN (figure 2). Le serveur BMS est configuré pour assurer la liaison entre tous les terminaux mobiles situés dans une zone géographique d'un réseau mobile MNT lié à un opérateur de réseau mobile et des serveurs de contenus connectés au réseau IPN. L'application APP peut être configurée pour donner accès à des contenus 25 par téléchargement de fichiers ou en mode continu. Les contenus peuvent être par exemple des contenus multimédia (contenus audio, vidéo, pages HTML, etc.) ou des applications à télécharger et installer dans le terminal mobile UM. Les étapes S1 à S4 sont exécutées successivement. A l'étape S1, 30 l'application APP émet une requête d'accès à un service SVC pour obtenir un contenu particulier transmis en temps réel ou en temps différé. Une transmission en temps réel désigne une transmission effectuée avec une latence, selon les cas, de quelques dizaines de millisecondes à quelques dizaines de secondes entre la production du contenu et la réception de celui- 35 ci par le terminal UM. 3052318 11 Selon un mode de réalisation, la requête comprend des données MURI permettant d'identifier le service demandé. A l'étape S2, cette requête est reçue par le module DSHC qui émet une requête au module MBMC pour déterminer si le service SVC demandé peut transmettre le contenu requis en 5 mode télédiffusion. A l'étape S3, le module MBMC reçoit cette requête contenant les données d'identification MURI du service, et émet une requête de données de diffusion sous la forme de métadonnées, relatives au service SVC identifié par les données MURI, à destination du serveur BMS assurant la liaison entre le réseau IPN et la région (groupe de cellules) du réseau MNT 10 où est situé le terminal UM. A l'étape S4, la fonction d'annonce SANF du serveur BMS reçoit cette requête et recherche l'identifiant de service SVC dans une liste de services exclus du mode de télédiffusion. Si le service correspondant à l'identifiant de service SVC ne peut pas être transmis en mode télédiffusion, les étapes S13 à S16 sont exécutées, sinon les étapes 15 S5 à S12 sont exécutées. A l'étape S13, la fonction d'annonce SANF émet un message d'erreur ERR. Le message d'erreur ERR est reçu par le module MBMC du terminal UM et retransmis au module DSHC à l'étape S14. A l'étape S15, le module DSHC retransmet le message d'erreur à l'application APP. A l'étape S16, 20 l'application APP accède d'une manière classique au service SVC en mode monodiffusion UC, soit en mode continu (streaming), soit en téléchargeant un ou plusieurs fichiers incluant le contenu requis. A cet effet, le module DSHC accède directement au serveur de contenu CNTS, le module MBMC n'étant pas sollicité. Cependant, des mécanismes sont prévus pour notifier à 25 un terminal accédant à un service en mode monodiffusion que ce service est maintenant accessible en mode télédiffusion. Ces mécanismes permettent également au terminal de passer au mode télédiffusion d'une manière transparente pour l'utilisateur. Il est à noter qu'à l'étape S2, le terminal UM peut déjà stocker les 30 métadonnées relatives au service SVC demandé. Cela signifie que le service est ou sera disponible en mode télédiffusion. Dans ce cas, seules les étapes S9 à S11 peuvent être exécutées à la suite de l'étape S2. Par ailleurs, la requête émise à l'étape 51 peut également permettre au terminal UM d'obtenir des métadonnées nécessaires à l'accès au service SVC en mode 35 monodiffusion. Cette requête étant alors traitée par le serveur de contenu CNTS. 3052318 12 A l'étape S5, la fonction d'annonce SANF détermine si le serveur BMS dispose des données (métadonnées) MTD relatives au service SVC requis correspondant aux données d'identification MURI du service SVC. Le serveur BMS mémorise dans une base de données MB (figure 1) des 5 métadonnées relatives à des services en cours de diffusion en mode télédiffusion, ou programmés pour être transmis en mode télédiffusion ou encore susceptibles d'être diffusés dans ce mode. Les métadonnées relatives à un service programmé pour être diffusé en mode télédiffusion spécifient des horaires de programmation durant lesquels le service sera 10 diffusé en mode télédiffusion. Si les métadonnées MTD sont disponibles sur le serveur BMS pour le service SVC, les étapes S8 à S12 sont exécutées, sinon les étapes S6 à S12 sont exécutées. A l'étape S6, le serveur BMS transmet une requête des métadonnées MTD au serveur de contenu CNTS désigné dans les données d'identification SID du service SVC. A l'étape S7, 15 le serveur BMS reçoit du serveur CNTS les métadonnées MTD correspondant au service SVC. A l'étape S8, la fonction d'annonce SANF du serveur BMS peut déterminer d'après les métadonnées MTD reçues pour le service SVC, si celui-ci peut être disponible mode de télédiffusion. Ainsi, un service peut être déterminé non disponible en mode télédiffusion notamment 20 en fonction de critères de taille de contenu, de débit binaire (bitrate), de codecs, de type de compression, d'horaire de diffusion, et selon que le contenu correspondant est produit en temps réel ou non. Si le service SVC ainsi identifié ne peut pas être transmis en mode télédiffusion, les étapes S13 à S16 sont exécutées, sinon, la fonction d'annonce SANF du serveur 25 BMS mémorise les métadonnées reçues dans la base de données MB, et les étapes S9 à S12 sont exécutées. A l'étape S9, les métadonnées MTD relatives au service SVC sont transmises au terminal mobile UM. Les métadonnées MTD sont reçues et mémorisées par le module MBMC du terminal UM et transmises au module 30 DSHC à l'étape S10, puis à l'application APP, à l'étape S11. A l'étape S12, l'application APP accède au service SVC d'une manière classique, soit en mode télédiffusion BC si le serveur BMS diffuse déjà le service dans ce mode, soit en mode monodiffusion UC. 3052318 13 Les étapes S6 et S7 sont exécutées notamment dans le cas où le service SVC demandé n'est pas connu du serveur BMS, comme un contenu par contournement (OTT). Les données MURI transmises à l'étape S3, permettant d'identifier le 5 service demandé SVC, peuvent comprendre un identifiant URI (Uniform Resource Identifier) du service, tel qu'une adresse URL (Uniform Resource Locator) d'accès à des métadonnées MPD relatives au service, ou une adresse URL du contenu sur le serveur de contenu CNTS, dans le cas d'un fichier à télécharger ou d'un contenu accessible en mode continu. Il peut 10 s'agir également d'une adresse URL d'un flux RSS 2.0 ou Atom. Les données MURI contenues dans la requête émise à l'étape S1 peuvent également comprendre : - des données relatives aux capacités du terminal UM (résolution d'écran, codecs disponibles, ...), 15 - des données de localisation du terminal UM dans le réseau mobile MNT et/ou géographiques (par exemple point GPS), - une ou plusieurs langues souhaitées pour le contenu, sous la forme de voix ou de sous-titres, - un délai d'attente ou une plage horaire spécifiant quand l'utilisateur est 20 disponible pour accéder au service SVC, - une date de début du contenu attendu pour un flux RSS ou Atom, - une référence d'une partie du contenu à transmettre, par exemple sous la forme d'un numéro de segment de début et/ou de fin, d'un ensemble de segments du contenu à transmettre, ou sous la forme d'un pourcentage 25 par rapport à la durée totale ou la taille totale du contenu, à partir du début et/ou de la fin du contenu, à ne pas recevoir. Les données MURI peuvent faire partie de l'identifiant URI ou de l'adresse URL, par exemple dans un format associant une clé ky à une valeur kyVal " ?ky=" + "kyVal", le caractère " ?" étant utilisé comme 30 séparateur des différentes données spécifiées dans l'identifiant UR, et la clé ky spécifiant le type de la donnée dont la valeur est spécifiée par kyVal. Ces données peuvent également être mentionnées dans une entête de requête HTTP. Plusieurs services d'accès à un même contenu peuvent être mis en 35 oeuvre pour tenir compte des capacités des différents terminaux mobiles 3052318 14 susceptibles d'accéder au contenu, chaque service fournissant le contenu d'une manière adaptée aux capacités d'un type de terminal donné. Ainsi, à l'étape S4, le serveur BMS peut vérifier si le service demandé SVC est disponible compte tenu des capacités du terminal UM et des données de 5 langues souhaitées figurant dans les données MURI. Ainsi, l'étape S13 peut être exécutée si le service demandé SVC n'est pas disponible compte tenu des capacités du terminal, ou encore s'il n'est pas disponible durant la plage horaire spécifiée dans les données MURI. Après l'étape S3 et avant l'étape S8, le serveur BMS peut répondre à 10 la requête émise à l'étape S1 en fournissant dans les métadonnées MPD une ou plusieurs plages horaires durant lesquelles le contenu correspondant au service SVC sera diffusé en mode télédiffusion. Après l'étape S1 et avant que le contenu correspondant au service soit disponible en mode télédiffusion, le terminal UM peut émettre une notification pour indiquer au 15 serveur BMS qu'il ne souhaite plus accéder au service SVC. La figure 4 représente la structure de la base de données MB contenant les métadonnées MTD relatives aux différents services pouvant être transmis en mode télédiffusion par le serveur BMS. La base de données MB comprend une liste USDL contenant un ou plusieurs éléments de 20 description de service USR1, USR2, USRn. Chacun de ces éléments peut référencer une instance de métadonnées FECD de réparation de flux par FEC. Chaque élément de description de service USRi comprend un élément MPDR de description de présentation de contenu, au moins un élément DELM de méthode de fourniture de contenu, et au plus un élément SCHR de 25 programmation. Chaque élément MPDR comprend un identifiant référençant des métadonnées MPD de description d'un contenu. Chaque élément DELM référence des métadonnées SESD de description de session, des métadonnées SECD de description de sécurité et des métadonnées ADPD de procédure de fourniture associée. Chaque élément de programmation 30 SCHR référence des métadonnées SCHD de description de programmation et les métadonnées SCHD peuvent comprendre une référence à des métadonnées FLTD de description de filtrage. Les métadonnées MPD de description de contenu peuvent comprendre notamment une ou plusieurs références de métadonnées ISGD de description d'un segment 35 d'initialisation. 3052318 15 Les métadonnées MTD relatives à un service peuvent également comprendre un identifiant du réseau mobile ou sans fil donnant accès au service, et éventuellement des données de localisation géographique du réseau si celui-ci n'est présent que localement, par exemple dans une ville, 5 un quartier de ville ou un bâtiment. De cette manière, si l'utilisateur se trouve à proximité du réseau, il peut être informé qu'il peut avoir accès à un service en se rendant en un lieu précis. La figure 5 représente des étapes S21 à S40 d'un procédé d'accès à un service de fourniture de contenu, requis par un terminal mobile UM, selon 10 un mode de réalisation. Le service concerné donne accès à un flux transmis en temps réel, ou en temps différé comme un fichier à télécharger ou un contenu accessible en mode continu. Il peut s'agir également d'un flux RSS 2.0 ou Atom. Les étapes S21 à S24 qui sont exécutées successivement, correspondent aux étapes S1 à S4. A l'étape S21, l'application APP émet 15 une requête d'accès à un service SVC pour obtenir un contenu particulier, la requête contenant des données MURI permettant d'identifier le service demandé. Aux étapes S22 et S23, cette requête est transmise au serveur BMS par l'intermédiaire du module MBMC. A l'étape S24, la fonction d'annonce 20 SANF du serveur BMS reçoit cette requête et recherche l'identifiant de service SVC dans la liste de services exclus du mode télédiffusion et dans la base de métadonnées MB des services en cours ou susceptibles d'être transmis en mode télédiffusion par le serveur BMS. Plusieurs services d'accès à un même contenu peuvent être mis en oeuvre pour tenir compte 25 des capacités des différents terminaux mobiles susceptibles d'accéder au contenu, chaque service fournissant le contenu d'une manière adaptée aux capacités d'un type de terminal donné. Ainsi, à l'étape S24, le serveur BMS peut vérifier si le service demandé SVC est disponible compte tenu des capacités du terminal UM et des données de langues souhaitées figurant 30 dans les données MURI. Les étapes S13 à S16 peuvent être exécutées si le service demandé SVC est exclu du mode télédiffusion ou s'il n'est pas disponible compte tenu des capacités du terminal, ou encore s'il n'est pas disponible durant la plage horaire spécifiée dans les données MURI, et/ou dans la région du réseau MNT où se trouve le terminal. Les étapes S25 à 3052318 16 S28 sont exécutées si le service correspondant à l'identifiant de service SVC n'est pas exclu du mode télédiffusion. Si le service correspondant à l'identifiant de service SVC peut être accessible en mode télédiffusion, mais ne figure pas dans la base de 5 données MB, les étapes S25 à S28 sont exécutées, sinon l'étape S40 est exécutée. A l'étape S25, le serveur BMS (par exemple la fonction d'annonce SANF du serveur BMS) mémorise dans une base de données MB que le terminal UM a demandé l'accès au service SVC. A l'étape S26, le serveur BMS transmet au terminal UM un message de réponse RetL indiquant que le 10 service demandé SVC n'est pour l'instant pas accessible en mode télédiffusion, mais peut l'être plus tard, notamment si un nombre suffisant de terminaux d'utilisateurs demandent l'accès au service SVC. Le message RetL peut mentionner un délai d'attente à l'issue duquel le terminal UM peut réémettre la requête émise à l'étape S21. Ce message est reçu par le 15 module MBMC du terminal UM, puis retransmis au module DSHC à l'étape S27, et enfin transmis à l'application APP à l'étape S28. Après l'étape S28, l'utilisateur du terminal UM peut alors décider d'attendre que le service SVC soit accessible en mode télédiffusion, ou bien décider d'accéder au service SVC en mode monodiffusion en exécutant l'étape S16 (figure 3). 20 Le message RetL peut également indiquer si le terminal UM doit fournir des rapports de consommation du service demandé. Si l'utilisateur du terminal UM décide d'accéder au service SVC sans attendre l'horaire spécifié dans le message RetL, c'est-à-dire en mode monodiffusion, le terminal peut fournir des rapports de consommation du service conformément à ce qui est 25 indiqué dans le message RetL et aux données ADPD des métadonnées du service. Ainsi, les données ADPD peuvent spécifier notamment quelles informations doivent figurer dans les rapports de consommation, et à quelle adresse et à quels moments ces rapports doivent être transmis. En parallèle des étapes S21 à S28, le serveur BMS comptabilise 30 (étape S25) les demandes de services des utilisateurs reçues à l'étape S23 et exécute les étapes S29 à S38. En particulier, la fonction SANF comptabilise le nombre de terminaux UM ayant demandé l'accès à un même service de fourniture d'un même contenu pour chaque information de localisation (dans les données MURI) reçue des terminaux. A l'étape S29, le 35 serveur BMC détermine si un service est demandé par un nombre suffisant 3052318 17 de terminaux pour justifier de donner accès au service en mode télédiffusion. A cet effet, la fonction SANF du serveur BMS compare ce nombre de terminaux avec une valeur de seuil. A l'étape S30, tant que le nombre de terminaux UM accédant à un même service ne dépasse pas la valeur de 5 seuil dans une zone du réseau MNT, l'étape S29 est exécutée à nouveau. Sinon les étapes S31 à S38 sont exécutées. A l'étape S31, la fonction SANF du serveur BMS émet une requête de métadonnées MTD relatives au service SVC pour lequel une transmission en mode télédiffusion est justifiée. A l'étape S32, la requête de métadonnées est 10 transmise par une fonction STF du serveur BMS au serveur de contenu CNTS fournissant le service SVC. A l'étape S32, le serveur BMS peut également demander des segments d'initialisation ISGD du service. A l'étape S33, le serveur CNTS reçoit la requête de métadonnées et transmet en réponse au serveur BMS les métadonnées MTD(SVC) demandées pour le 15 service SVC. A l'étape S34, une fonction STF du serveur BMS reçoit les métadonnées et génère des métadonnées unifiées UMTD à partir des métadonnées MTD reçues. A cet effet, le serveur BMS définit une ou plusieurs tranches horaires durant lesquelles le contenu sera diffusé en mode télédiffusion. Les métadonnées unifiées UMTD sont dérivées des 20 métadonnées reçues MTD en y précisant notamment une adresse URL où le service sera accessible en mode télédiffusion, ainsi que des informations relatives à des horaires de diffusion. Ces métadonnées sont stockées dans la base MB. A partir des métadonnées reçues MTD, le serveur peut vérifier la taille du contenu correspondant au service. A l'étape S35, les métadonnées 25 UMTD sont transmises à la fonction de serveur SANF du serveur BMS. Dans le cas où le service demandé SVC est un service de téléchargement d'un fichier, le serveur BMS peut générer lui-même les métadonnées correspondant au service. A l'étape S36, la fonction SANF met à jour la base de données MB contenant les métadonnées d'accès aux services 30 susceptibles d'être transmis en mode télédiffusion, en y inscrivant les métadonnées UMTD reçues et les segments d'initialisation ISGD reçus. En parallèle à l'étape S36, la fonction STF transmet au serveur CNTS une requête de contenu CNT correspondant au service SVC. A l'étape S38, le serveur CNTS transmet le contenu CNT(SVC) demandé au serveur BMS. Le 35 serveur BMS stocke localement le contenu CNT pour le mettre à la 3052318 18 disposition des terminaux UM situés dans une zone de service du serveur BMS dans le réseau mobileMNT. A l'étape S39 qui est identique à l'étape S23, le module MBMC demande à nouveau les métadonnées MTD du service SVC. Cette étape 5 peut être exécutée à la suite de l'étape S26 après un temps d'attente spécifié dans le message RetL. A l'étape S40 qui suit l'étape S39, les métadonnées UMTD qui sont maintenant disponibles dans la base de données MB gérée par la fonction SANF, sont transmises du serveur BMS au module MBMC du terminal UM, en réponse à la requête émise à l'étape S39. Le terminal UM 10 dispose ainsi des métadonnées lui permettant d'accéder au service SVC en mode télédiffusion, dès que celui-ci sera diffusé dans ce mode. Il est à noter que le service SVC peut être transmis en mode télédiffusion avant l'horaire de programmation spécifié dans le message RetL. Dans ce cas, si le terminal UM accède déjà au service SVC en mode 15 monodiffusion, il peut alors basculer dans le mode télédiffusion de la manière classique, transparente pour l'utilisateur. A l'heure annoncée dans les métadonnées MTD de transmission du contenu correspondant au service en mode télédiffusion, le terminal UM peut également déclencher lui-même l'accès au service dans ce mode. 20 La figure 6 représente des étapes S41 à S47 d'un procédé d'accès à un service de fourniture d'un contenu requis par un terminal mobile UM en mode télédiffusion, selon un autre mode de réalisation. A la réception des métadonnées pour le service SVC à l'étape S40, le terminal UM (la fonction applicative) commande le module MBMC pour activer une session FLUTE 25 pour le service SVC. Le module MBMC se met alors en attente des segments du contenu correspondant au service. A l'étape S41, à l'heure indiquée dans les données d'horaire de programmation des métadonnées MTD du service SVC, le serveur BMS transmet sous la forme de segments le contenu CNT correspondant au service SVC dans une session FLUTE. A 30 l'étape S42, le module MBMC reçoit ces segments qui sont stockés par exemple dans une mémoire cache par le module LHPC du terminal UM. A l'étape S43, le module LHPC notifie à l'application APP que le service demandé est accessible en mode télédiffusion. L'application APP du terminal UM peut signaler la réception de cette notification à l'utilisateur du terminal. A 35 l'étape S44, l'utilisateur commande le terminal pour qu'il utilise le contenu 3052318 19 CNT reçu, par exemple en l'affichant sur un écran du terminal (dans le cas d'une image, d'un contenu vidéo, d'un fichier texte ou multimédia), ou en le diffusant par des haut-parleurs (dans le cas d'un contenu vidéo ou audio), ou encore en l'exécutant (dans le cas d'une application ou d'un programme 5 d'installation d'une application). Il est à noter que les étapes S29, S30 peuvent être exécutées en permanence lorsque les terminaux d'utilisateurs accèdent à des services notamment en mode monodiffusion. Ainsi, à l'étape S29, le serveur BMS comptabilise le nombre de terminaux UM accédant à un même service de 10 fourniture d'un même contenu en mode monodiffusion, et détermine si un service est demandé par un nombre de terminaux suffisant pour justifier de donner accès au service en mode télédiffusion. Si tel est le cas, les étapes S31 à S38 sont exécutées. Lorsqu'un service est mis à la disposition des terminaux en mode télédiffusion, les terminaux accédant au service en mode 15 monodiffusion peuvent être notifiés de la mise à disposition du service en mode télédiffusion. Les terminaux UM peuvent alors accéder au service en mode télédiffusion en demandant les métadonnées correspondantes UMTD (étape S40), et basculer du mode monodiffusion au mode télédiffusion à l'horaire où le service est disponible dans ce mode. 20 Les étapes S29 et S30 peuvent également être exécutées pour traiter des notifications de consommation de services transmises par les terminaux d'utilisateur UM dans la zone couverte par le serveur BMS, les notifications de consommation étant traitées pour évaluer le nombre de terminaux accédant à un service en mode monodiffusion ou télédiffusion. En particulier, 25 les notifications de consommation émises par les terminaux d'utilisateur permettent au serveur BMS de déterminer lorsqu'un terminal d'utilisateur accède ou n'accède plus à un service, que ce soit en mode monodiffusion ou en mode télédiffusion. Le serveur BMS peut ainsi également prendre la décision d'arrêter la transmission d'un contenu en mode télédiffusion lorsque 30 le nombre de terminaux d'utilisateurs accédant au contenu est insuffisant pour justifier le mode télédiffusion. Chaque terminal d'utilisateur peut envoyer régulièrement une notification d'usage d'un service et/ou émettre une telle notification lorsqu'il ouvre et ferme l'accès à un service. A l'étape S40, le serveur BMS peut transmettre au terminal UM non 35 pas les métadonnées MTD du service demandé à l'étape S21, mais simplement une adresse URL où les métadonnées sont disponibles. Cette 3052318 20 adresse URL peut être déterminée par le serveur BMS à partir des métadonnées MTD du service obtenues à l'étape S33. Cette adresse URL peut spécifier un identifiant du service, un nom de fichier dans le cas d'un service de téléchargement de fichier, et des informations d'horaire de 5 programmation du service, telles que des heures de début et de fin de diffusion du contenu correspondant au service en mode télédiffusion. L'adresse URL ainsi transmise peut permettre au terminal de recevoir les métadonnées du service transmises en mode télédiffusion. Dans le cas où les données MURI référencent une partie du contenu 10 correspondant au service demandé SVC, le serveur BMS vérifie également à l'étape S4, S24, si la partie demandée du contenu est ou sera disponible en mode télédiffusion. Durant l'étape S11, seule la partie demandée du contenu peut être téléchargée par le terminal UM. Un flux RSS ou Atom se présente sous la forme d'une liste 15 d'éléments, chaque élément référençant un contenu pouvant être transmis en mode monodiffusion ou télédiffusion. Ainsi, l'étape S24 est exécutée pour chaque élément d'un flux RSS ou Atom, cette étape étant suivie des étapes S13 à S16 si le contenu ne peut pas être transmis en mode télédiffusion, des étapes S39 à S47 si le contenu est transmis dans ce mode, et des étapes 20 S25 à S28 si le contenu peut dans un avenir proche être transmis dans ce mode. Il apparaîtra clairement à l'homme de l'art que la présente invention est susceptible de diverses variantes de réalisation et diverses applications. En particulier, l'invention n'est pas limitée à la combinaison d'une opération 25 de mémorisation par le serveur de diffusion BMS de la requête de métadonnées (étape S25), et d'une opération d'émission de la notification RetL indiquant que le service demandé sera peut être disponible plus tard (étapes S26 à S28). En effet, le terminal UM, en particulier le module MBMC, peut émettre par exemple périodiquement la requête de métadonnées pour 30 l'accès au service en mode télédiffusion (étapes S23, S39) sans avoir besoin de recevoir la notification RetL, et le serveur BMS peut déterminer que le nombre de terminaux ayant demandé un service est suffisant pour le transmettre en mode télédiffusion à partir de notifications de consommation de service transmises par les terminaux d'utilisateurs accédant à un service 35 en mode monodiffusion. REVENDICATIONS1. Procédé d'accès à un service (SVC) de diffusion de contenu, en temps réel ou différé, accessible sur un serveur de contenu, le procédé étant mis en oeuvre dans un terminal d'utilisateur (UM) connecté à un réseau mobile ou sans fil (MNT), et comprenant des étapes consistant à : obtenir une adresse d'accès à un service, transmettre à un serveur de diffusion (BMS) de services, une requête de métadonnées contenant une adresse d'accès à un service (SVC) accessible en mode monodiffusion, et si le service est disponible en mode télédiffusion, recevoir des métadonnées (MTD) relatives au service, contenant des données d'adresse d'accès au service en mode télédiffusion et des données d'horaire de diffusion, et recevoir le contenu correspondant au service en mode télédiffusion à un moment conforme aux données d'horaire de diffusion. 2. Procédé selon la revendication 1, comprenant une étape de réception par le terminal d'utilisateur (UM) d'une notification (RetL) indiquant que le service demandé (SVC) peut être disponible en mode télédiffusion à l'issue d'un délai d'attente spécifié dans la notification, si le service peut devenir disponible en mode télédiffusion. 3. Procédé selon la revendication 2, comprenant une étape de programmation de la transmission au serveur de diffusion (BMS) d'une nouvelle requête de métadonnées d'accès au service, en tenant compte du délai d'attente reçu dans la notification (RetL). 4. Produit programme d'ordinateur directement chargeable dans une mémoire interne d'un terminal et comprenant des portions de code qui lorsqu'elles sont exécutées par le terminal configurent le terminal pour mettre en oeuvre les étapes du procédé selon l'une des revendications 1 à 3. 30 5. Procédé de fourniture d'un service (SVC) de diffusion de contenu, en temps réel ou différé, accessible sur un serveur de contenu, mis en 3052318 22 oeuvre par un serveur de diffusion (BMS) par l'intermédiaire d'un réseau mobile ou sans fil (MNT), le procédé comprenant des étapes consistant à : recevoir d'un terminal d'utilisateur une requête de métadonnées contenant une adresse d'accès à un service (SVC) accessible en mode 5 monodiffusion, déterminer si le service est disponible en mode télédiffusion, et si le service est disponible en mode télédiffusion, transmettre au terminal d'utilisateur des métadonnées (MTD) relatives au service, contenant des données d'adresse d'accès au service en mode télédiffusion et des 10 données d'horaire de diffusion, et transmettre en mode télédiffusion un contenu correspondant au service à un moment conforme aux données d'horaire de diffusion. 6. Procédé selon la revendication 5, comprenant une étape de 15 transmission par le serveur de diffusion au terminal d'utilisateur d'une notification (RetL) indiquant que le service demandé peut être disponible en mode télédiffusion à l'issue d'un délai d'attente spécifié dans la notification, si le service peut devenir disponible en mode télédiffusion, 20 7. Procédé selon la revendication 6, comprenant une étape de mémorisation par le serveur de diffusion (BMS) que le service (SVC) a été demandé à partir d'une zone du réseau mobile (MNT) définie par une donnée de localisation figurant dans la requête de métadonnées, en relation avec la donnée de localisation et des identifiants du service. 25 8. Procédé selon l'une des revendications 5 à 7, comprenant des étapes consistant à : compter par le serveur de diffusion (BMS) un nombre de terminaux d'utilisateur (UM) ayant émis une requête d'accès au service (SVC) à partir de la zone du réseau définie par la donnée de localisation, et lorsque le nombre de terminaux d'utilisateurs ayant émis une requête d'accès au service dans la zone du réseau mobile, dépasse une valeur de seuil, programmer par le serveur de diffusion la diffusion du service en mode télédiffusion à un horaire de diffusion. 3052318 23 9. Procédé selon l'une des revendications 5 à 8, dans lequel la diffusion du service en mode télédiffusion comprend des étapes consistant à. télécharger et mémoriser par le serveur de diffusion (BMS) des 5 métadonnées (MTD) relatives au service, mettre à jour par le serveur de diffusion les métadonnées relatives au service pour donner au service une nouvelle adresse d'accès correspondant au serveur de diffusion, et pour y mentionner des horaires de diffusion du service en mode télédiffusion, 10 télécharger par le serveur de diffusion le contenu (CNT) fourni par le service depuis un serveur de contenu (CNTS) identifié dans les métadonnées téléchargées, et stocker localement le contenu pour le transmettre en mode télédiffusion en respectant un horaire spécifié par les données d'horaire de diffusion. 15 10. Procédé selon l'une des revendications 1 à 9, dans lequel le service (SVC) appartient à un groupe de services comprenant : des services d'accès à des contenus transmis en temps réel, des services de fourniture de contenus transmis en mode continu, 20 des services de téléchargement de fichiers, et des services de fourniture de flux RSS ou Atom. 11. Procédé selon l'une des revendications 1 à 10, dans lequel la requête de métadonnées comprend au moins l'une des données suivantes : 25 des données relatives aux capacités du terminal d'utilisateur (UM), une langue souhaitée pour la fourniture du service (SVC), un délai d'attente ou une plage horaire de disponibilité d'un utilisateur du terminal pour accéder au service, des données de localisation du terminal d'utilisateur, 30 une date de début de contenu à transmettre dans le cas où le service fournit un flux RSS ou Atom, et une référence à une partie du contenu fourni par le service, attendue par l'utilisateur du terminal. 3052318 24 12. Procédé selon l'une des revendications 1 à 11, dans lequel les métadonnées (MTD) comprennent des données d'identification d'un réseau mobile ou sans fil (MNT) dans lequel le service sera fourni en mode télédiffusion, et optionnellement, des données de localisation du réseau. 13. Produit programme d'ordinateur directement chargeable dans une mémoire interne d'un serveur et comprenant des portions de code qui lorsqu'elles sont exécutées par le serveur configurent le serveur pour mettre en oeuvre les étapes du procédé selon l'une des revendications 5 à 12. 14. Serveur de diffusion (BMS) configuré pour mettre en oeuvre le procédé selon l'une des revendications 5 à 13. 15. Terminal d'utilisateur configuré pour mettre en oeuvre le procédé 15 selon l'une des revendications 1 à 3. 5 10