Brevet FR3089087A1 — publié le 20200529

Description Titre de l'invention : Procédé de préemption de ressources de transmission pour l'acheminement de données temps réel 1. Domaine technique [0001] La demande d'invention se situe dans une architecture d'un réseau mobile où les fonctions (le transmission sont mises en oeuvre dans des entités distinctes (lu réseau. L'invention vise à permettre à une application nécessitant la disponibilité rapide de ressources de transmission pour acheminer des données relatives à cette application de préempter (les ressources initialement allouées à une autre application. 2. Etat de la technique [0002] Les réseaux cellulaires traditionnels, ou réseaux d'accès radio (RAN), se composent de nombreuses stations de base autonomes (BTS). Chaque BTS couvre une petite zone, tandis qu'un groupe de BTS assure une couverture sur une zone continue. Chaque BTS traite et transmet son propre signal à destination et en provenance du terminal mobile et achemine les données entre le terminal mobile et le réseau de communications d'un opérateur. Une station d'accès, ici nommée BTS, peut également être une station NodeB, une station eNodeB ou une station d'accès déployée pour les réseaux de génération future et notamment les réseaux dits 5G (de cinquième génération). [0003] Plus récemment, une architecture de station de base distribuée a été introduite par les fournisseurs de matériel de télécommunications. La fleure 1 présente un exemple d'une telle architecture. Dans cette architecture, l'unité de fonction radio, également appelée tête radio distante (RRH (Remote Radio Head)), est reliée à l'unité fonctionnelle numérique, ou unité de bande de base (BBU (Base Band Unit)) par exemple par une fibre. La RRH peut être installée sur le haut de la tour près de l'antenne, réduisant les pertes de transmission. La liaison de fibre entre RRH et BBU permet également une plus grande souplesse dans la planification et le déploiement du réseau. La BBU alloue des ressources radio aux terminaux attachés à la RRH correspondante selon un algorithme de planification (en anglais Se heduling) propre à la politique de l'opérateur gérant l'infrastructure. Ainsi, sur la figure 1, la BBU 1 attribue des ressources radio, par exemple des blocs de ressources (RB (Resources Blocks)) identifiant des fréquences de transmission pendant des intervalles de temps, aux terminaux TI, T2, T3 respectivement attachés aux antennes 1, 2, 3 de la RRH 1. 100041 La plupart des stations de hase modernes utilisent maintenant cette architecture découplée. Par la suite, on distinguera dans les architectures de réseau mobile les Unités Distribuées (DU) et les unités centralisées (CU) telles que présentées dans la figure 2. Notamment, une RRH est ainsi nommée DU et une BBU est une CU. La ré- 2 partition des fonctions élémentaires mises en oeuvre respectivement dans une DU et dans une CU est encore en discussion. Il est vraisemblable qu'une DU supportera les fonctions d'émission et de réception radio telles que la conversion analogique/ numérique et l'amplification des signaux ainsi que la modulation. Une CU peut regrouper entre autres les fonctions de traitement du signal (codage) et d'ordonnancement pour le partage du spectre radio (en anglais radio scheduling) suivant un certain algorithme. Dans les premiers déploiements, la fonction de codage est le plus souvent mis en oeuvre dans une DU. Une DU réside toujours au côté des antennes, tandis que la CU, est placée plus haut dans le réseau, vers les équipements de coeur de réseau. Dans l'évolution des architecture de réseaux mobiles, on envisage le déploiement de pools de CUs et on parle alors d'architecture de type C-RAN (Ccntralized - Radio Access Nctworks) ou môme Cloud-RAN lorsque les CU sont mises en oeuvre dans des espaces de stockage de type cloud. Les CUs partagent des ressources de calcul ainsi que les informations du réseau d'accès pour une utilisation plus effective des ressources radio (réduction des interférences, CoMP (Coordinated Multipoint) permettant la transmission d'un flux de données par plusieurs stations...). [0005] L'interface de communication entre les entités CU et DU n'est pas encore définie. Cette interface est nommée Fs dans les travaux de spécification des réseaux de cinquième génération, un canal Fs-U de cette interface étant destiné à l'acheminement des données des utilisateurs et un canal Fs-C de l'interface étant destiné à l'acheminement des données de contrôle. Plusieurs options sont actuellement en cours de discussion pour la mise en oeuvre de cette interface, comme par exemple l'interface eCPRI (Enhanced Cornillon Public Radio Interface) qui est la version évoluée du CPRI actuellement déployé dans la 4G entre le RRH et le BBU. L'IEEE (Institute of Electrical and Electronics Engineers), par exemple, propose aussi une interface pour la transmission des signaux radio directement sur Ethernet (IEEE 1914.3). [0006] Selon la technique antérieure, où la fonction de codage est mise en oeuvre dans la CU, la CU prend en charge une fonction d'encodage des données, c'est-à-dire qu'elle sélectionne un type de modulation et de codage pour la transmission de données d'une application d'un terminal utilisateur et elle indique à une DU le type de modulation et de codage à utiliser, à quel moment et sur quelle fréquence, c'est-à-dire sur quelles ressources. La CU construit ainsi une table d'ordonnancement, comprenant des RB (Resource Blocks), communiquée à chaque DU. La RB correspond à une bande de fréquence élémentaire (le canal) allouée à un terminal dans un intervalle de temps élémentaire TS (en anglais Time Slot) et pour chaque RB est associée une puissance et une mode de codage et de de modulation(MCS). Cette information MCS indique un type de modulation et de codage attribuée à un terminal. Il peut s'agir par exemple de modulation BPSK, QPSK, 16QAM ou 64QAM. La CU décide donc d'une MCS pour 3 un terminal donné et possiblement pour un flux de données relatif à une application du terminal. La table d'ordonnancement est communiquée à la DU pour la transmission effective des données vers le terminal ou en provenance du terminal sur le lien radio. [0007] Cette répartition des fonctions entre la DU et la CU, et les problèmes de latence sur le lien entre une CU, ou un pool de CUs, et la DU ne permettent pas l'envoi de données urgentes à des terminaux. En effet, une CU doit en effet recevoir les données de l'application, les traiter, élaborer ou mettre à jour une table d'ordonnancement selon un algorithme de scheduling indiqué ci-dessus et transmettre à une DU la table d'ordonnancement mise à jour ou la nouvelle table d'ordonnancement pour prendre en compte la transmission des données urgentes, cc qui peut entraîner un délai non compatible avec les besoins de l'application. [0008] La présente invention a pour objet d'apporter des améliorations par rapport à l'état de la technique. 3. Exposé de l'invention [0009] L'invention vient améliorer la situation à l'aide d'un procédé d'allocation d'au moins une ressource de transmission parmi unc pluralité de ressources, destinée à l'acheminement d'une première donnée relative à une première application dans une infrastructure de communication, le procédé étant mis en oeuvre dans une entité distribuée de gestion de la pluralité de ressources, et comprenant: - Une étape de réception, en provenance d'une entité centralisée de gestion, d'un message d'allocation d'une pluralité de ressources comprenant un ensemble de caractéristiques de transmission d'une deuxième donnée relative à unc deuxième application, - Une étape d'affectation d'au moins une ressource de la pluralité à la transmission de la première donnée, - Une étape de sélection d'une caractéristique de l'ensemble pour la transmission de la deuxième donnée sur les ressources de la pluralité non affectées à la transmission de la première donnée. [0010] Selon la technique antérieure, une entité de type DU, reçoit une table d'ordonnancement comprenant des ressources à allouer pour la transmission de données d'une application et une information sur les caractéristiques de modulation et de codage à utiliser pour la transmission de ces données. La DU, selon la technique antérieure, n'a pas la possibilité d'intervenir sur la table et alloue les ressources conformément à la table reçue d'une entité centralisée de gestion, telle qu'une CU. [0011] L'invention vise à permettre à la DU de pouvoir modifier une instruction reçue de la CU, en accord avec la CU. La CU, plutôt que d'indiquer une seule caractéristique de modulation, indique à la DU que des données d'une application peuvent être transmises en utilisant une des caractéristiques de transmission, telles que des caractéristiques de modulation et de codage transmises Pour une application donnée, la CU indique plusieurs caractéristiques de transmission, laissant la possibilité à la DU d'opter pour l'une de ces caractéristiques en fonction de contraintes liées à l'envoi de données d'une autre application, qu'elle doit transmettre de façon urgente. Le procédé permet ainsi à la DU de préempter des ressources initialement allouées à une application pour la transmission de données d'une autre application tout en garantissant que les données des deux applications sont bien transmises. Cette préemption s'accompagne en effet d'une sélection d'une des caractéristiques de transmission parmi celles reçues, cette caractéristique de transmission étant sélectionnée pour permettre la transmission des données des deux applications via un partage des ressources initialement uniquement allouées à une seule application. [0012] Selon un aspect de l'invention, dans le procédé d'allocation, une ressource comprend une bande de fréquence et une durée. [0013] La possibilité de modifier l'allocation de Transports Blocks correspondant à une ensemble de Resources blocks (bandes de fréquence et durée) indiquée par la CU impose à la DU de sélectionner une caractéristique de transmission (par exemple un code MCS) adaptée à la nouvelle répartition des ressources entre les deux données. [0014] Selon un aspect de l'invention, dans le procédé d'allocation, une ressource comprend une longueur d'onde. [0015] Dans le cas d'un réseau LiFi (Light Fidelity), la pluralité de ressources correspond à une longueur d'onde ou à un ensemble de longueur d'onde, celles-ci pouvant être allouées pour une durée limitée [0016] Selon un autre aspect de l'invention, le procédé d'allocation comprend en outre une étape d'obtention par l'entité distribuée de gestion d'un message comprenant un paramètre déclenchant l'étape d'affectation. [0017] L'affectation par l'entité distribuée de gestion est possiblement déclenchée en fonction de paramètres. Ainsi, un opérateur peut décider de ne pas donner la possibilité à une entité distribuée de modifier une allocation initiale, impactant la qualité d'acheminement des données de la deuxième application sauf si la DU obtient un message comportant un paramètre particulier. Ce paramètre peut être lié à la criticité de première application, à la qualité de service requise pour l'acheminement de données de la première application ou de tout autre paramètre. [0018] Selon un autre aspect de l'invention, dans le procédé d'allocation, le paramètre est obtenu d'un terminal. [0019] Un terminal d'un utilisateur peut ainsi permettre de préempter, sous contrôle de la DU, des ressources de transmission et ainsi permettre que des données urgentes concernant un incident dans une zone géographique soient acheminées en priorité par rapport à des applications moins urgentes pour lesquelles ces ressources préemptées avaient été allouées initialement. [0020] Selon un autre aspect de l'invention, le procédé d'allocation comprend en outre, en préalable à l'étape d'affectation, une étape de sélection d'une caractéristique de modulation et codage pour la transmission de la deuxième donnée. [0021] La technique antérieure ne prévoit pas l'envoi d'une pluralité de caractéristiques de transmission de données d'une application. Alors que selon l'invention, l'entité distribuée peut décider de sélectionner une des caractéristiques pour la transmission des données de la deuxième application, celle-ci pouvant ensuite être modifiée si des données d'une autre application doivent être transmises de façon urgente. [0022] Selon un autre aspect de l'invention, dans le procédé d'allocation, l'ensemble de ca- ractéristiques reçues comprend en outre au moins une information de priorité associée à au moins une caractéristique. [0023] Une information de priorité associée à une caractéristique de transmission, par exemple de modulation et de codage, permet à une CU, en charge de transmettre les caractéristiques, de recommander une caractéristique par rapport à une autre lorsque la DU sélectionne une caractéristique une fois qu'une ressource de transmission a été affectée à une autre application mais aussi au préalable à l'affectation lorsqu'une sélection intervient avant l'affectation. [0024] Selon un autre aspect de l'invention, le procédé d'allocation comprend en outre une étape d'émission à destination de l'entité centralisée d'un message de notification comprenant une indication sur la première donnée. [0025] Dans le cas où la première donnée de la première application correspond à une ap- plication qui peut durer dans le temps, la DU peut avantageusement informer la CU sur cette application de façon à ce que cette dernière puisse prendre en compte cette application pour l'allocation future de ressources de transmission. Ce message de notification permet ainsi à la CU de garder le contrôle sur les ressources allouées et de prendre en compte des interactions avec des applications sur lesquelles la DU n'a pas de contrôle. [0026] Selon un autre aspect de l'invention, dans le procédé d'allocation, le message de noti- fication comprend une prévision de ressources pour la transmission de la première donnée. [0027] L'entité distribuée peut avantageusement transmettre à l'entité centralisée une prévision de ressources requises pour la transmission des données de la première application de façon à ce que l'entité centralisée puisse sélectionner les ressources et les caractéristiques de transmission adaptées à cette prévision. [0028] Selon un autre aspect de l'invention, dans le procédé d'allocation, le message d'allocation est reçu sur une connexion multiplexant les canaux de données utilisateur, de contrôle et de synchronisation des ressources. [0029] L'utilisation par exemple d'un lien de type eCPRI ou IEEE 1914.x pour transmettre 6 le message d'allocation permet de profiter de la richesse fonctionnelle de cette interface et notamment des différents canaux de transmission (plan utilisateur, plan contrôle, plan de synchronisation). D'autres options sont possibles telles que par exemple, des liens de type MPLS (Multiprotocol Label Switching), de type VLAN (Virtualized Local Arca Nctworks). [0030] Selon un autre aspect de l'invention, dans le procédé d'allocation, le message d'allocation comprend en outre une information sur une tranche de réseau, dite slicc, associée à la pluralité de ressources. [0031] Notamment dans les futures générations de réseaux (5G), les services (applications, terminaux, classes de service...) sont associés à des tranches de réseaux mises en oeuvre par un opérateur. Une tranche de réseau correspond à un ensemble de fonctions (élémentaires) mises à disposition de l'acheminement et du traitement de données relatives à un service (au sens large (terminal, application, domaine)) et selon l'invention, pour laquelle on alloue des ressources de transmission, telles que des transports blocks. Les ressources sont avantageusement associées à des tranches de réseau permettant ainsi de pouvoir intervenir sur des ressources appartenant à une tranche ou bien, selon la mise en oeuvre, sur la répartition de ressources entre tranches de réseaux par exemple pour augmenter les ressources d'une tranche associé à des données de type temps réel. [0032] Les différents aspects du procédé d'allocation qui viennent d'être décrits peuvent être mis en oeuvre indépendamment les uns des autres ou en combinaison les uns avec les autres. [0033] L'invention concerne également un dispositif d'allocation d'au moins une ressource de transmission parmi une pluralité de ressources, destinée à l'acheminement d'une première donnée relative à une première application dans une infrastructure de communication, comprenant: - Un récepteur, apte à recevoir, en provenance d'une entité centralisée de gestion, d'un message d'allocation d'une pluralité de ressources comprenant un ensemble de caractéristiques de transmission d'une deuxième donnée relative à une deuxième application, - Un module d'affectation, apte à affecter au moins une ressource de la pluralité à la transmission de la première donnée, - Un module de sélection, apte à sélectionner une caractéristique de l'ensemble pour la transmission de la deuxième donnée sur les ressources de la pluralité non affectées à la transmission de la première donnée. [0034] Ce dispositif, apte à mettre en oeuvre dans tous ses modes de réalisation le procédé d'allocation qui vient d'être décrit, est destiné à être mis en oeuvre dans un équipement de gestion d'un réseau allouant dynamiquement des ressources de transmission à des 7 flux de données. Cela peut être par exemple une station d'accès radio (eNodeB, station d'accès 5G...), un équipement de type RRH voire un équipement de type BBU décentralisé. [0035] L'invention concerne aussi un système d'allocation d'au moins une ressource de transmission parmi une pluralité de ressources, destinée à l'acheminement d'une première donnée relative à une première application dans une infrastructure de communication, comprenant: - une entité distribuée de gestion comprenant un dispositif d'allocation, - une entité centralisée de gestion comprenant: - un module d'affectation, apte à affecter une pluralité de ressources comprenant un ensemble de caractéristiques de transmission à la transmission de la deuxième donnée, - un émetteur, apte à émettre, à destination de l'entité distribuée de gestion, d'un message d'allocation d'une pluralité de ressources comprenant un ensemble de caractéristiques de transmission de la deuxième donnée relative à la deuxième application. [0036] L'invention concerne aussi un programme d'ordinateur comprenant des instructions pour la mise en oeuvre des étapes du procédé d'allocation qui vient d'être décrit, lorsque ce programme est exécuté par un processeur. [0037] Cc 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. [0038] L'invention vise aussi un support d'informations lisible par un ordinateur, et comportant des instructions du programme d'ordinateur tel que mentionné ci-dessus. [0039] Le support d'informations peut être n'importe quelle entité ou dispositif capable de stocker les programmes. 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 ou un disque dur. [0040] D'autre part, le support d'informations 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 pal- d'autres moyens. Le programme selon l'invention peut être en particulier téléchargé sur un réseau de type Internet. [0041] Alternativement, le support d'informations 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. 4. Brève description des dessins [0042] D'autres avantages et caractéristiques de l'invention apparaitront plus clairement à la lecture de la description suivante d'un mode de réalisation particulier de l'invention, donné à titre de simple exemple illustratif et non limitatif, et des dessins annexés, 8 parmi lesquels: présente une vue simplifiée d'une architecture de réseau dans laquelle est mise en oeuvre l'invention selon un aspect de l'invention, Ifig.1l présente une autre vue d'une architecture de réseau selon un autre aspect de l'invention, [0043] [fig.3] présente un aperçu de l'allocation de ressources selon une technique antérieure, [0044] [fig.4] présente un aperçu du procédé d'allocation selon un premier mode de réalisation de l'invention, [0045] [fig.5] présente un aperçu du procédé d'allocation selon un deuxième mode dc réalisation de l'invention, [0046] [fig.6] présente un aperçu du procédé d'allocation selon un troisième mode de réalisation dc l'invention, [0047] [fig.7] présente un exemple de structure d'un dispositif d'allocation selon un aspect de l'invention. 5. Description des modes de réalisation [0048] Dans la suite de la description, on présente des exemples de plusieurs modes de réa- lisation dc l'invention dans une infrastructure de communication mobile. L'invention peut être mise en oeuvre dans tout type d'infrastructure ou des ressources de transmission sont allouées de façon dynamique à des terminaux pour que ceux-ci émettent ou reçoivent des données vers ou en provenance d'une entité distante. [0049] On se réfère tout d'abord à la figure 3 qui présente un aperçu de l'allocation de ressources selon une technique tuitérieure. [0050] Dans cette figure 3, l'entité CU 10, qui est par exemple une BBU, est composée d'un encodeur 102 en charge d'encoder les données conformément à un type de modulation et d'encodage sélectionné et d'une entité 101 d'ordonnancement des ressources de transmission allouées à un terminal donné. [0051] Lors de l'étape El, un serveur applicatif HTTP 400 (HyperText Transfer Protocol) transmet un contenu à destination du terminal 200, celui-ci ayant émis auparavant une requête d'obtention du contenu à destination du serveur 400, cette requête étant non représentée sur la figure 3. A la réception du contenu, l'encodeur 102 de l'entité CU 10 transmet lors de l'étape E2 à destination de l'entité 101 d'ordonnancement une requête pour obtenir un type de modulation et d'encodage ainsi que des ressources de 9 transmission pour l'envoi des données émises par le serveur 400. L'entité 101 d'ordonnancement disposant de ressources de transmission importantes pour ces données, elle répond lors de l'étape E3 en indiquant le type de modulation 256QAM pour l'encodage des données émises par le serveur 400 et elle indique les ressources à utiliser pour ces données. Le type de modulation 256 QAM permet au terminal 200 de bénéficier d'un bon débit pour les données émises par le serveur 400. Lors de l'étape E4, l'encodeur émet à destination de l'entité DU 20, qui peut être une entité RRH, les données reçues du serveur 400. L'entité DU 20 émet ensuite les données à destination du terminal 200 par l'intermédiaire d'une station d'accès, possiblement co-localisée avec l'entité DU 20. La station d'accès, selon la technologie radio utilisée pour émettre les données vers le terminal 200, peut être une station BTS, une station NodeB, une station eNodcB ou bien une station d'accès d'une génération de réseau radio de cinquième génération ou de génération suivante. L'émission des données par l'entité DU 20 vers le terminal 400 est réalisée en utilisant les ressources allouées par l'entité CU 10 et à l'aide du type de modulation et de codage sélectionné par l'entité d'ordonnancement 101. [0052] Lors de l'étape E6, le serveur 500 de données temps réel, tel que par exemple un serveur d'alerte météo, transmet des données à émettre vers le terminal 300, abonné par exemple au service d'alerte météo. L'encodeur 102 reçoit les données du serveur 500 et doit les transmettre sans délai au terminal 300. 11 sollicite alors l'entité 101 d'ordonnancement lors de l'étape E7 pour obtenir des ressources d'émission et un type de modulation et de codage pour ces données temps réel. L'entité d'ordonnancement 101 décide de sélectionner un autre type de modulation pour les données reçues du serveur 400 de façon à pouvoir attribuer des ressources et un type de modulation et de codage pour les données temps réel reçues du serveur 500. Lors de l'étape E8, l'entité 101 détermine et transmet le type de modulation 16QAM pour les données du serveur 400 à émettre vers le terminal 200 ainsi qu'un moindre nombre de ressources en comparaison avec les ressources allouées lors de l'étape E3. Lors de l'étape E9, il détermine et transmet le type de modulation QPSK et certaines ressources initialement allouées aux données émises par le serveur 400 pour les données du serveur 500 à émettre vers le terminal 300. [0053] L'encodeur 102 transmet lors de l'étape EIO les données reçues du serveur 400 ainsi que les données reçues du serveur 500 vers l'entité DU en indiquant les ressources ainsi que les types de modulation et de codage relatifs à ces deux types de données. Ces transmissions peuvent être effectuées dans deux étapes distinctes. [0054] L'étape El l ne représente pas un envoi de message mais indique la latence pour d'une part attribuer des ressources initialement allouées au serveur 400 pour les données temps réel et pour sélectionner un autre type de modulation pour les données du serveur HTTP 400, cette allocation et cette sélection étant rendues nécessaires pour pouvoir acheminer les données temps réel. [0055] Lors de l'étape E12, l'entité DU 20 émet les données temps réel vers le terminal 300 niais le choix du type de modulation peu performant effectué par l'entité 101 d'ordonnancement et les conditions ou la qualité de réception radio du terminal 300 conduisent à un décodage des données rendu périlleux voire impossible pour le terminal 300. [0056] Lors de l'étape El 3, le terminal 200 continue de recevoir les données, mais avec un type de modulation 16QAM, donc avec un débit plus faible qu'auparavant, lorsque le type 256QAM était utilisé. Ce débit n'est donc plus adapté au volume de données transmis par le serveur qui doit ajuster son volume d'envoi pour éviter les pertes de données et la baisse de qualité. [0057] Lors de l'étape E14, toutes les données temps réel ont été acheminées par le serveur 500 vers le terminal 300, et il est alors possible pour l'entité d'ordonnancement de sélectionner à nouveau le type de modulation 256 QAM pour les données émises par le serveur 400 à destination du terminal 200. Le serveur 400 pourra, après quelques secondes, adapter son volume de données émis au débit plus important permis par le nouveau type de modulation. [0058] Cette technique antérieure présente donc au moins deux problématiques. La prise en compte des contraintes des données temps réel n'est pas satisfait par le choix d'un type de modulation et une répartition des ressources de transmission par l'entité 101 d'ordonnancement. En effet, l'entité 10 CU centralisée n'a pas connaissance des conditions radio et la communication des ressources allouées et du type de modulation requiert un délai de transmission entre les entités CU 10 et DU 20. Par ailleurs, les modifications du type de modulation du trafic HTTP, pour permettre la transmission de données temps réel sur des ressources radio partagées pour la transmission des deux types de données (temps réel et HTTP), conduit à une dégradation de qualité de service pour le terminal 200. Le serveur 400 doit en effet asservir l'envoi des données au débit de données vers le terminal 200, ce changement de débit étant constaté par le serveur 400 après un certain délai. [0059] La figure 3 a pour objet de présenter les problèmes posés par la technique antérieure et mieux comprendre le procédé d'allocation dans ses différents modes de réalisation. [0060] On se réfère ensuite à la figure 4 qui présente un aperçu du procédé d'allocation selon un premier mode de réalisation de l'invention. [0061] Dans cette figure 4, une entité CU 10 alloue des ressources de transmission et des ca- ractéristiques de transmission à des terminaux pour que ceux-ci émettent et reçoivent des données. Ces ressources consistent à des bandes de fréquence (ou canal) pendant des intervalles de temps et les caractéristiques de transmission correspondent à des 11 modes de codage et de modulation, par exemple représentés par la caractéristique MCS (Modulation and Coding Systems). Une ressource comprend une caractéristique de transmission selon la technique antérieure. Un même terminal 90 peut se voir allouer plusieurs bandes de fréquences (ou Rcsources Blocks) pendant plusieurs intervalles de temps, ce qui correspond à un Transport Block (un ensemble de RBs). Selon la technique antérieure, l'entité 10 CU ne transmet qu'un mode de modulation pour le terminal 90, voire pour une application spécifique du terminal 90 pour une ressource donnée. Pour attribuer un mode de modulation au terminal 90 attaché à la station d'accès 40, l'entité 10 CU communique une table d'ordonnancement comprenant les différents « resources blocks » et les codes MCS associés alloués aux différents terminaux attachés à la station d'accès 40. Cette table est communiquée à l'entité 20 DU, assurant des fonctions relatives à la transmission des données sur le réseau radio cellulaire. Une entité 10 CU peut transmettre des tables à plusieurs entités de types DU et l'entité 20 DU peut elle-même gérer un ensemble de stations d'accès. La figure 3 ne présente qu'une seule de chacune des entités 10 CU, 20 DU et station d'accès 40 par souci de clarté. [0062] L'entité 10 CU est connecté à un réseau 30. Ce réseau 30 est par exemple connecté à l'internet et permet ainsi aux terminaux attachés à la station d'accès 40, parmi lesquels le terminal 90, de pouvoir accéder à des services et communiquer avec des correspondants fixes ou mobiles. L'entité 10 CU et l'entité 20 DU sont interconnectées via un lien 50 qui peut par exemple être une fibre optique mais il peut s'agir d'un réseau par exemple de type IP (Internet Protocol) ou MPLS (Multi Protocol Label Switching). [0063] Selon un exemple de l'invention, le terminal 90 attaché à la station d'accès 40 veut télécharger des données de type vidéo en streaming. L'entité 10 CU doit donc allouer des ressources de transmission et des caractéristiques de transmission à ce terminal 90 pendant la durée de téléchargement des données. Cette allocation tient compte des autres terminaux attachés à la station d'accès 40, voire à d'autres stations d'accès connectées à l'entité 20 DU pour établir sa table d'ordonnancement. Dans l'exemple, l'entité 10 CU décide de sélectionner deux caractéristiques BI et B2 de transmission pour la ressource MI pour le terminal 90. On note la caractéristique BI relative à la ressource MI MI/B1. Il est à noter que, selon la technique antérieure, une seule caractéristique est associée à une Resource block à un terminal ou à une application du terminal. [0064] Selon un exemple de l'invention, l'entité 10 CU alloue des ressources de transmission pour l'application vidéo de streaming. Elle choisit dans le cas présent deux caractéristiques, c'est-à-dire deux types de codage et de modulation. Par exemple, on considère que la CU 10 sélectionne les MCS QPSK (Quadrature Phase-Shift Keying) correspondant à MI/BI sur la figure et 16QAM (16 - Quadrature Amplitude 12 Modulation) correspondant à M1 /B2. [0065] Selon un exemple, une information sur une tranche de réseau associée aux ressources. Notamment, s'agissant d'une application de vidéo streaming, l'entité 10 CU peut indiquer « Vidéo » pour les ressources allouées indiquant ainsi à la DU que les ressources allouées sont associées à une tranche «Vidéo ». L'entité DU 20 peut ainsi utiliser cette information de tranche pour gérer les données et appliquer des politiques propres aux tranches et aux données associées à ces tranches. Notamment, l'entité DU 20 peut utiliser cette information pour affecter ensuite des ressources, initialement associées à une tranche « Vidéo » à des données « Temps Réel », correspondant à une autre tranche, et à transmettre de façon plus urgente par rapport aux données Vidéo. [0066] Dans le cas A de la figure 3, l'entité DU 20 sélectionne le mode de codage et de mo- dulation le plus performant, à savoir M1 /B2, pour émettre les données vers le terminal 90. Parmi l'ensemble 100 des ressources radio disponibles, un nombre important de ces ressources peut être alloué au flux streaming de l'application vidéo correspondant à M1 sur la figure et le code MCS 16-QAM peut être choisi puisque les ressources disponibles pour les données de streaming vidéo sont importantes. Il est à noter que dans le cas A, des ressources Ll sont allouées à des flux d'applications temps réel, par exemple pour un service de téléphonie. Ces ressources Ll peuvent être allouées par l'entité 10 W. L'ensemble des ressources de transmission de la station 40 sont les ressources 100 correspondant à MI +Li. [0067] Dans le cas B, intervient un événement intempestif. Dans ce cas, il s'agit d'un incident routier requérant que des informations soient diffusées à des terminaux géographiquement présents dans la zone, dont le terminal 90, où l'incident routier est intervenu, certains de ces terminaux étant attachés à la station d'accès 40. Dans ce cas, il faut que des ressources de transmission parmi l'ensemble MI de ressources allouées aux flux de streaming soient allouées en priorité à cet événement intempestif et de façon rapide. Cette nouvelle répartition des ressources entre les flux de données de l'application de streaming vidéo et les flux de données relatives à l'incident routier est gérée par l'entité 20 DU car une nouvelle table d'ordonnancement établie par l'entité 10 CU prendrait trop de temps et ne serait pas compatible avec le besoin temps réel des informations liées à l'incident routier voire avec les conditions de propagation détectées par l'entité DU 20. L'entité 20 DU reçoit des informations d'un serveur 70 d'application de gestion de trafic routier ayant elle-même obtenu une information d'un véhicule 80 sur l'incident routier. L'entité 20 DU décide d'allouer plus de ressources de transmission, c'est-à-dire plus de Resources blocks à l'application de gestion de trafic routier. Il convient en outre que l'entité 20 DU diminue les ressources MI allouées à l'application de streaming vidéo. Cette baisse de ressources à l'application 13 streaming vidéo s'accompagne en outre d'un changement de code MCS parmi les codes reçus précédemment de l'entité 10 CU. Sachant que les ressources M2 sont moins nombreuses que les ressources MI, l'entité 20 DU sélectionne un code MCS moins performant. En l'occurrence, il opte pour le code MCS QPSK (Ml/B1) reçu de l'entité 10 CU. Il est à noter que les flux de données de l'application de streaming et de l'application de gestion de trafic routier peuvent être respectivement acheminés vers le terminal 90 sur des tranches de réseaux (ou network slices en anglais) adaptées aux caractéristiques des flux de données. [0068] On se réfère maintenant à la figure 5 qui présente un aperçu du procédé d'allocation selon un deuxième mode de réalisation de l'invention. [0069] Les entités de la figure 5 sont identiques à la figure 3 à la différence que l'entité distribuée DU 20 est précisée et comprend un encodeur 202 de données temps réel ainsi qu'une entité 201 d'ordonnancement. Selon un exemple, le serveur 500 peut également être intégré à l'entité DU 20 par exemple dans le cas où le serveur 500 est un serveur MEC (Mobile Edge Computing). [0070] Selon un exemple, lors de l'étape FO, l'entité d'ordonnancement 101 émet un message comprenant un paramètre déclenchant l'affectation d'une ressource de transmission, initialement affectée par l'entité CU 10, par l'entité DU 20. Ce paramètre autorise ou non l'entité 20 DU à préempter des ressources allouées par l'entité 10 CU. Ce paramètre peut être associé à des données spécifiques ou pour l'ensemble des données transmises par l'entité 10 CU à l'entité 20 DU. [0071] Les étapes Fl à F3 sont équivalentes aux étapes El à E3 de la figure 3. [0072] Lors de l'étape F4, l'entité 10 CU et plus spécifiquement l'entité 101 d'ordonnancement de l'entité 10 CU transmet à l'entité 201 d'ordonnancement de l'entité 20 DU les ressources allouées pour les données émises par le serveur 400 ainsi que les différents types d'encodage possibles pour les données du service large bande HTTP mis à disposition par le serveur 400. Ces types d'encodage sont par exemple transmis dans un message UserDataChoice sur le canal CM (control and Management) d'un lien eCPRT. [0073] Les informations transmises par l'entité 101 à l'entité 201 sont par exemple les suivantes: [0074] UserDataChoice : [ { //-20Mbps MCS_index:3, // S/N