FR 3068553 A1 20190104 FR 1756374 A 20170706 Partage de ressources radio pour des serveurs de contenu 1. Domaine de l'invention L'invention se situe dans le domaine de la transmission de données au travers des réseaux mobiles en mode paquet, par exemple de celui de la transmission de contenus multimédia provenant de fournisseurs différents vers des terminaux mobiles connectés à un réseau d'accès 3G, 4G, ou 5G. 2. Etat de la technique antérieure Le trafic vidéo représente jusqu'à 70% du trafic total sur les réseaux mobiles. L'utilisation de ce que l'on nomme le réseau d'accès mobile, dont l'utilisation des fréquences et des antennes par exemple, représente quant à elle plus de 80% des coûts du réseau mobile. Lorsqu'un utilisateur souhaite consommer un contenu sur son terminal mobile, ce contenu est sur un serveur de contenu, par exemple un serveur de cache, qui est contrôlé par un fournisseur de contenus. Actuellement, le serveur de contenu envoie alors le contenu demandé découpé en morceaux qu'il estime que le réseau d'accès mobile sera en mesure de livrer jusqu'au terminal mobile. Le terme morceau désigne une des parties d'un flux, de taille variable ou constante; le flux est reconstitué lorsque tous les morceaux sont reçus correctement par une application tournant sur le terminal. Ceci n'est pas satisfaisant car le serveur de contenu n'a aucune assurance que le réseau d'accès sera effectivement en mesure de livrer chacun des morceaux dans un temps acceptable. En effet, il faut aussi que les morceaux arrivent au terminal avant que l'application sur le terminal, par exemple un lecteur ("player" en anglais) de contenu multimédia, par exemple une vidéo, ne demande à les consommer ; cela créée sinon un blocage de la vidéo sur le lecteur, situation appelée famine. Pour cette raison, il a été imaginé que le serveur de contenu puisse réserver 2 des ressources radio auprès d'un élément de réseau de l'opérateur mobile. Par exemple pour le réseau LIE (technologie mobile dite 4G), le 3GPP a défini dans le document TS36.213 plusieurs classes de service dites COI (Channel Quality Indicator, indicateur de qualité de canal, en anglais). A chaque COI sont associés des garanties 5 en termes de transmission des données (délai, priorité, taux d'erreur, etc.). Ainsi, il est possible d'associer à un flux (identifié par ses adresses d'origine et de destination) un COI auquel est associé un débit plus ou moins garanti. Ainsi, le serveur de contenu peut, pour chacun de ses flux, réserver une classe de service COI, ce qui revient à réserver un débit dont il a besoin afin que le contenu soit reçu par le terminal en 10 respectant une certaine qualité de service. L'application des paramètres de qualité s'applique par flux. Le trafic de données associé à un flux se verra donc appliqué le même traitement pour tous les morceaux du flux, alors que les conditions impactant la qualité varient dans le temps même pour des contenus non-temps réel. 15 Les utilisateurs d'un même réseau d'accès mobile demandent leurs contenus indépendamment les uns des autres, et il n'est pas envisageable que les fournisseurs de contenu acceptent de se concerter entre eux lorsqu'ils réservent des débits auprès d'un réseau d'accès radio, pour des raisons commerciales et de complexité de mise en oeuvre d'une telle concertation. Il en résulte une consommation sous-optimale des 20 ressources radio du réseau d'accès mobile, entre autre parce que les fournisseurs de contenus ne partagent, ni entre eux, ni avec les opérateurs de réseaux d'accès mobile, les informations qu'ils détiennent sur leurs utilisateurs et la façon dont ceux-ci consomment leurs contenus. 25 Un des buts de l'invention est de remédier à ces inconvénients de l'état de la technique. 3. Exposé de l'invention 30 L'invention vient améliorer la situation à l'aide d'un procédé de réservation de 3 blocs de ressource physique d'un réseau d'accès mobile, mis en oeuvre par un serveur de contenu configuré pour émettre un flux de données demandé par un terminal connecté au réseau d'accès mobile avec un niveau de qualité déterminé, le procédé comprenant : 5 - détermination d'une valeur d'un nombre de blocs à réserver, en fonction de paramètres liés au flux de données, et du niveau de qualité déterminé, - émission d'une première demande de réservation de blocs de ressource, comprenant la valeur déterminée du nombre de blocs à réserver, vers une entité de contrôle du réseau d'accès mobile, 10 - réception d'une réponse d'allocation de blocs de ressource en provenance de l'entité de contrôle, comprenant une valeur d'un nombre de blocs alloués au serveur de contenu. L'unité de base des ressources radio utilisées par une antenne de 15 radiocommunications pour envoyer ou recevoir des données correspond à une bande de fréquence disponible sur un intervalle de temps, et est appelée bloc de ressource physique (physical resource block, en anglais), ou plus simplement "RB". C'est principalement l'utilisation des RB qui génère les coûts du réseau d'accès mobile. Il est plus facile pour un contrôleur d'antenne de garantir, pour un flux de 20 données, l'allocation d'un nombre de RBs, qui sont les unités de base incompressibles de la transmission radio, que l'allocation d'une bande passante, ou débit, qui est susceptible de varier en fonction de conditions qui ne sont pas toujours sous le contrôle du réseau d'accès mobile ou de l'antenne. Avantageusement, grâce au procédé de réservation proposé, un serveur de 25 contenu peut réserver une quantité de RB, plutôt qu'une promesse de débit, comme dans la technique antérieure. Le serveur de contenu connait les caractéristiques du flux demandé par le terminal, c'est-à-dire le débit nécessaire et le volume total des données du flux, ainsi que la qualité du canal utilisé par le terminal consommateur du flux, c'est-à-dire le 30 paramètre COI. La détermination du nombre de blocs en fonction du débit et du COI 4 peut être par exemple réalisée par consultation de tables de correspondance propres aux fabricants d'antennes. Selon un aspect du procédé de réservation, la détermination d'une valeur d'un 5 nombre de blocs à réserver est faite aussi en fonction d'un coût unitaire par bloc. Grâce à cet aspect, un serveur de contenu connaissant le prix à payer par RB est incité à la modération dans une demande de réservation de RBs. Selon un aspect du procédé de réservation, il comprend, préalablement à la 10 réception de la réponse d'allocation : - réception d'une réponse de réservation en provenance de l'entité de contrôle, comprenant un paramètre relatif à un coût unitaire d'un bloc, - émission d'une deuxième demande de réservation de blocs de ressource, comprenant une valeur révisée du nombre de blocs à réserver, déterminée au 15 moins en fonction du coût unitaire. Grâce à cet aspect, un serveur de contenu peut obtenir le prix à payer par RB directement de l'entité de contrôle auprès de laquelle il a fait sa demande de réservation de RBs, et réviser le nombre de RB qu'il souhaite réserver. Cette entité de contrôle connait les demandes des autres serveurs de contenu, pour un même 20 intervalle de temps, et peut ajuster le prix en fonction d'un équilibre recherché entre l'offre, c'est-à-dire le total des RB disponibles, et la demande, c'est-à-dire le nombre total de RBs dont la réservation est demandée par des serveurs de contenu. L'invention vient améliorer la situation également à l'aide d'un procédé 25 d'allocation de blocs de ressource physique d'un réseau d'accès mobile, pour une pluralité de serveurs de contenu configurés pour émettre des flux de données vers des terminaux connectés au réseau d'accès mobile, le procédé comprenant : - réception de premières demandes de réservation de blocs, en provenance de la pluralité de serveurs de contenu, une première demande d'un serveur de contenu 30 comprenant une valeur d'un nombre de blocs demandés par ce serveur de 5 contenu, - calcul d'un écart entre un nombre de blocs disponibles dans le réseau d'accès mobile, et le total des nombres de blocs demandés, - détermination, au moins en fonction de l'écart, de valeurs de nombres de blocs 5 alloués aux serveurs de contenus, - émission de réponses d'allocation de blocs vers la pluralité de serveurs de contenus, une réponse d'allocation à un serveur de contenu comprenant la valeur du nombre de blocs qui sont alloués à ce serveur de contenu. 10 Avantageusement, grâce au procédé d'allocation proposé, l'entité de contrôle, un serveur de type MEC par exemple, recevant des demandes de ressources radio de la part des serveurs de contenu peut allouer précisément des RB, plutôt que, comme dans la technique antérieure, des débits qui sont susceptibles de varier en fonction de conditions qui ne sont pas toujours sous le contrôle du réseau d'accès mobile, de 15 l'antenne, ou de l'entité de contrôle du réseau d'accès mobile. Selon un aspect du procédé d'allocation, un coût unitaire par bloc est déterminé, et le procédé comprend en outre, préalablement à la détermination des nombres de blocs alloués : 20 - ajustement du coût unitaire au moins en fonction de l'écart, - émission de réponses de réservation vers la pluralité de serveurs de contenu, comprenant une information relative au coût unitaire, - réception de deuxièmes demandes de réservation de blocs, en provenance de la pluralité de serveurs de contenus, une deuxième demande d'un serveur de 25 contenu comprenant une valeur révisée du nombre de blocs demandés par ce serveur de contenu, - calcul de l'écart entre le nombre de blocs disponibles, et le total des nombres révisés de blocs demandés. Lorsqu'une entité de contrôle d'un réseau d'accès mobile reçoit, pour sa zone, 30 c'est-à-dire par exemple pour une cellule couverte par son ou ses antennes, des 6 demandes de réservation pour un nombre total de RB supérieur à ce qui est disponible pour l'intervalle de temps visé par toutes les demandes, le réseau n'alloue pas immédiatement aux serveurs de contenu demandeurs des RB par approximation, en tentant d'approcher au mieux possible la demande, comme cela est fait dans la 5 technique antérieure. Au lieu de cela, le réseau n'alloue pas immédiatement de ressources et répond aux demandeurs avec un prix unitaire de RB modifié, et attend une deuxième réponse de réservation, dans un cycle d'ajustement. Si la ressource demandée est rare, c'est-à-dire si la demande excède l'offre, le prix unitaire de la ressource est augmenté par le réseau, par rapport au prix courant 10 préalablement connu des demandeurs. De cette manière, les serveurs de contenu peuvent par la suite émettre une deuxième demande de réservation en connaissance du prix unitaire révisé. Comme un serveur de contenu connait des caractéristiques propres à son utilisateurs et/ou au contenu que cet utilisateur demande, il pourra ajuster sa demande 15 de réservation en fonction de l'importance qu'il accorde à cette demande de contenu. Avec un coût unitaire augmenté, il aura tendance à diminuer le nombre de RB qu'il souhaite réserver, sauf si l'importance accordée est grande. Les autres serveurs de contenu qui sont en compétition pour les mêmes ressources sur le même intervalle de temps auront le même comportement, ce qui aura pour résultat de modérer le nombre 20 total de RB demandés, et ainsi de diminuer l'écart entre ce total et le nombre de RB disponibles. Ce cycle d'ajustement, qui peut être vu comme un cycle de négociation entre offreur et demandeurs, peut être répété autant de fois qu'il faut afin que cet écart disparaisse, ou s'arrêter lorsqu'une limite de temps est atteinte, afin de ne pas induire 25 de retard dans la livraison des contenus. Si la ressource devient abondante, c'est-à-dire si l'offre excède la demande, le prix unitaire de la ressource est diminué par le réseau, par rapport au prix courant préalablement connu des demandeurs. De cette manière, les serveurs de contenu pourront revoir à la hausse leurs demandes de réservation respectives, ce qui 30 permettra au réseau de distribuer toutes ses ressources. 7 Le procédé proposé s'applique quelle que soit l'échelle du réseau d'accès mobile. Par simplicité, "réseau d'accès mobile" est limité ici à une cellule à titre d'exemple, mais le même principe peut être appliqué à n'importe quelle échelle, que ce soit à l'échelle d'une seule cellule 4G ou 5G, à l'échelle de l'ensemble des toutes les 5 cellules d'un opérateur mobile national, ou à tout autre échelle intermédiaire. Après un ou plusieurs cycles d'ajustement du coût unitaire d'un RB, lorsque l'écart entre offre et demande est devenu inférieur à un seuil, ou lorsqu'une limite de temps écoulé depuis la toute première demande de réservation est atteinte, le réseau 10 alloue les RB aux différents serveurs de contenu. Le réseau peut attribuer les RB en cherchant à s'approcher le plus possible de la demande. Si l'écart n'est pas nul, le réseau peut le réduire à zéro en augmentant ou diminuant proportionnellement toutes les demandes de ressources. 15 Le procédé de réservation qui vient d'être décrit, combiné au procédé d'allocation qui vient d'être décrit, contribuent ensemble à faire converger offre et demande de ressources radio dans un système impliquant un opérateur de réseau d'accès mobile et des fournisseurs de contenu, sans qu'ils ne doivent partager plus d'informations concernant leurs utilisateurs et/ou les contenus demandés, comparé aux 20 techniques antérieures où offre et demande ne convergent pas. L'invention concerne aussi un dispositif de réservation de blocs de ressource physique d'un réseau d'accès mobile, compris dans un serveur de contenu configuré pour émettre un flux de données demandé par un terminal connecté au réseau d'accès 25 mobile avec un niveau de qualité déterminé, le dispositif comprenant : - un module de détermination d'une valeur d'un nombre de blocs à réserver, en fonction de paramètres liés au flux de données, et du niveau de qualité déterminé, - un émetteur d'une première demande de réservation de blocs de ressource, comprenant la valeur déterminée du nombre de blocs, vers une entité de contrôle 30 du réseau d'accès mobile, 8 - un récepteur d'une réponse d'allocation de blocs de ressource en provenance de l'entité de contrôle, comprenant une valeur d'un nombre de blocs alloués au serveur de contenu. 5 Selon un aspect du dispositif de réservation, le module de détermination est également apte à, et configuré pour prendre en compte un coût unitaire par bloc de ressource, le récepteur est également apte à, et configuré pour recevoir une réponse de réservation, comprenant un paramètre relatif au coût unitaire, et l'émetteur est également apte à, et configuré pour émettre une deuxième demande de réservation de 10 blocs de ressource, comprenant une valeur révisée d'un nombre de blocs à réserver, déterminé au moins en fonction du coût unitaire. Ce dispositif, apte à mettre en oeuvre dans tous ses modes de réalisation le procédé de réservation qui vient d'être décrit, est destiné à être mis en oeuvre dans un 15 serveur de contenu, ou serveur de cache, ou tout autre entité apte à émettre un flux de données multimédia vers un terminal mobile. L'invention concerne de même un dispositif d'allocation de blocs de ressource physique d'un réseau d'accès mobile, pour une pluralité de serveurs de contenu 20 configurés pour émettre des flux de données vers des terminaux connectés au réseau d'accès mobile, le dispositif comprenant : - un récepteur de premières demandes de réservation de blocs, en provenance de la pluralité de serveurs de contenu, une première demande d'un serveur de contenu comprenant une valeur d'un nombre de blocs demandés par ce serveur 25 de contenu, - un module de calcul d'un écart entre un nombre de blocs disponibles dans le réseau d'accès mobile, et le total des nombres de blocs demandés, - un module de détermination, au moins en fonction de l'écart, de valeurs de nombres de blocs alloués aux serveurs de contenus, 30 - un émetteur de réponses d'allocation de blocs vers la pluralité de serveurs de 9 contenus, une réponse d'allocation à un serveur de contenu comprenant la valeur du nombre de blocs qui sont alloués à ce serveur de contenu. Selon un aspect du dispositif d'allocation, il comprend en outre un module 5 d'ajustement du coût unitaire en fonction de l'écart calculé, l'émetteur étant en outre apte à émettre des réponses de réservation vers la pluralité de serveurs de contenu, comprenant une information relative au coût unitaire, et le récepteur étant apte à recevoir des deuxièmes demandes de réservation de blocs, en provenance de la pluralité de serveurs de contenus, une deuxième demande d'un serveur de contenu 10 comprenant un nombre révisé de blocs demandés par ce serveur de contenu. Ce dispositif d'allocation, 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 une entité ou serveur de contrôle en contact avec le réseau d'accès 15 mobile, apte à gérer le trafic vers des terminaux mobiles, ainsi qu'a accéder à des informations en temps réel sur le fonctionnement de la partie radio d'une station de base du réseau d'accès mobile. L'invention concerne encore un système de partage de blocs de ressource 20 physique d'un réseau d'accès mobile, comprenant au moins deux dispositifs de réservation conforme à celui qui vient d'être décrit, et un dispositif d'allocation conforme à celui qui vient d'être décrit, le dispositif d'allocation étant connecté aux dispositifs de réservation et à une station de base. 25 L'invention concerne aussi un programme d'ordinateur, comprenant des instructions pour la mise en oeuvre des étapes du procédé de réservation de blocs de ressource physique d'un réseau d'accès mobile qui vient d'être décrit, lorsque ce programme est exécuté par un processeur. L'invention vise aussi un support d'informations lisible par un serveur de 30 contenu, et comportant des instructions d'un programme d'ordinateur tel que mentionné ci-dessus. L'invention concerne aussi un programme d'ordinateur, comprenant des instructions pour la mise en oeuvre des étapes du procédé d'allocation de blocs de 5 ressource physique d'un réseau d'accès mobile qui vient d'être décrit, lorsque ce programme est exécuté par un processeur. L'invention vise aussi un support d'informations lisible par un serveur de contrôle connecté à une station de base, et comportant des instructions d'un programme d'ordinateur tel que mentionné ci-dessus. 10 Ces programmes peuvent 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. 15 Les supports d'informations peuvent être n'importe quelle entité ou dispositif capable de stocker le programme. Par exemple, un 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 20 une disquette (floppy disc) ou un disque dur. D'autre part, un 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 par d'autres moyens. Les programmes selon l'invention peuvent être en particulier téléchargés sur un réseau de type Internet. 25 Alternativement, un support d'informations peut être un circuit intégré dans lequel un programme est incorporé, le circuit étant adapté pour exécuter ou pour être utilisé dans l'exécution des procédés en question. 10 4. Présentation des figures 30 11 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, parmi lesquels : 5 - la figure 1 illustre une configuration d'un réseau d'accès mobile du type cellulaire et les interactions entre entités d'un tel réseau lors de l'accès de deux terminaux utilisateur à des contenus multimédia sur deux serveurs de contenu, selon un mode de réalisation de l'invention ; - la figure 2 illustre les étapes d'une méthode de réservation et d'une méthode 10 d'allocation de blocs de ressource physique d'un réseau d'accès mobile, selon plusieurs modes de réalisation de l'invention ; - la figure 3 illustre un exemple de structure de dispositif de réservation de blocs de ressource physique d'un réseau d'accès mobile, selon différents modes de réalisation de l'invention ; et 15 - la figure 4 illustre un exemple de structure de dispositif de d'allocation de blocs de ressource physique d'un réseau d'accès mobile, selon différents modes de réalisation de l'invention. 5. Description détaillée d'au moins un mode de réalisation de l'invention 20 Dans la suite de la description, on présente des exemples de plusieurs modes de réalisation de l'invention se basant sur la technologie dite MEC (pour "Mobile Edge Computing" en anglais), en cours de standardisation auprès de l'ETSI (pour "European Telecommunications Standards lnstitute" en anglais), mais l'invention s'applique 25 également à d'autres architectures de réseau d'accès mobile. La figure 1 illustre une configuration d'un réseau d'accès mobile du type cellulaire et les interactions entre entités d'un tel réseau lors de l'accès de deux terminaux utilisateur à des contenus multimédia sur deux serveurs de contenu, selon 30 un mode de réalisation de l'invention. 12 La technologie d'informatique de bord (ou bordure ou périphérie) de réseau cellulaire, technologie MEC offre la possibilité de tirer parti d'une localisation en bord de réseau cellulaire pour optimiser des applications dédiées aux utilisateurs d'un tel réseau cellulaire. Il apparaît ainsi que la technologie MEC pourrait être adaptée aux 5 diverses problématiques de la diffusion de contenus multimédia dans un réseau cellulaire et dans un environnement multiutilisateurs. Le serveur de contrôle 200 est un tel serveur de type MEC et est localisé entre le réseau PDN et la station de base 100 qui gère la partie radio du réseau cellulaire MAN (ou réseau d'accès mobile, par généralisation). Sa situation permet au serveur de 10 contrôle 200 de gérer le trafic de, et vers, les terminaux mobiles 100a et 100b d'utilisateurs, ainsi que d'accéder à des informations en temps réel sur le fonctionnement de la partie radio du réseau. Un dispositif d'allocation de blocs de ressource physique d'un réseau d'accès mobile mettant en oeuvre la technique décrite est compris dans le serveur de contrôle 200. La station de base 100 est par exemple 15 un eNodeB de la technologie mobile 4G. Le réseau PDN est par exemple le réseau coeur de l'opérateur du réseau cellulaire, ou le réseau Internet, ou englobe les deux à la fois. Les contenus multimédia demandés respectivement par les terminaux 100a et 100b sont hébergés par les serveurs de contenus 300a et 300b. Les serveurs 300a et 20 300b, sont par exemple des serveurs dit de cache, sur lesquels les demandes de contenu sont redirigées par d'autres serveurs plus en amont et directement sollicités par les terminaux mobiles demandeurs. Un serveur de contenu ou cache émet un contenu multimédia demandé vers un terminal demandeur sous forme de flux de données, coupé en morceaux successifs dont la taille est variable et déterminée selon 25 plusieurs critères, tels que la taille de la mémoire tampon du terminal, et également les caractéristiques radio du réseau d'accès mobile MAN. La façon dont est indirectement déterminée la taille des morceaux fait l'objet des méthodes de réservation et d'allocation de blocs proposées ci-après. Par simplicité, les exemples de mode de réalisation sont présentés sur la base de 2 terminaux 30 mobiles 100a et 100b, et de 2 serveurs 300a et 300b, mais les méthodes proposées 13 s'appliquent à un nombre quelconque de serveurs de contenus distincts servant au moins autant de terminaux distincts, un serveur de contenu pouvant servir plus d'un terminal. Par simplicité également, le sens donné à "terminal" est le même que "logiciel 5 client du terminal". Dans ce document, plusieurs logiciels clients tournant sur le même terminal physique sont à considérer comme autant de terminaux, s'ils reçoivent des flux de la part de serveurs de contenu différents. La figure 2 illustre les étapes d'une méthode de réservation et d'une méthode 10 d'allocation de blocs de ressource physique d'un réseau d'accès mobile, selon plusieurs modes de réalisation de l'invention. Lors d'une étape E100a connue, une requête pour un contenu multimédia émanant du terminal 100a est reçue par le serveur de contenu 300a, de façon directe ou indirecte via un serveur de tête de réseau, ou via un serveur de référencement de 15 contenu, par exemple. En plus d'un identifiant du contenu demandé qui permet au serveur de contenu d'en connaitre des caractéristiques telles que son volume total, son ou ses types d'encodage, sa catégorie (publicité, clip musical, etc.), cette requête peut également comprendre un ou plusieurs paramètres caractéristiques du terminal 100a et de sa connexion au réseau d'accès mobile, tels que par exemple un COI (Channel 20 Quality Indicator, ou indicateur de qualité de canal, en anglais), un état de remplissage d'une mémoire tampon. Le serveur de contenu 300a peut aussi déduire l'état de remplissage de la mémoire tampon à partir d'un décompte des morceaux de flux déjà émis. De façon similaire, lors d'une étape E100b connue, une requête pour un 25 contenu multimédia émanant du terminal 100b est reçue par le serveur de contenu 300b. Il est supposé que les serveurs de contenu 300a et 300b sont gérés par des fournisseurs de contenus indépendants l'un de l'autre, et ne partageant aucune information sur leurs utilisateurs ou les contenus qu'ils demandent. 30 Lors d'une étape El a, le serveur de contenu 300a détermine un nombre N0a 14 de blocs, appelés RBs, à réserver auprès du serveur de contrôle 200, en fonction de paramètres liés au contenu demandé, c'est-à-dire liés au flux de données nécessaire à mettre en oeuvre pour livrer ce contenu, et en fonction de paramètres liés au terminal, c'est-à-dire liés à un niveau de qualité compatible avec les conditions du terminal 100a 5 et de sa liaison radio avec le réseau d'accès mobile MAN. Connaissant la technologie radio utilisée, par exemple LIE, le COI du terminal, la bande passante du canal utilisée (LIE channel bandwidth) et la correspondance entre le COI et le nombre de bits par milliseconde, ainsi que le type de MIMO utilisé, le serveur peut déduire la consommation instantanée du terminal en RB par kilo octet. 10 Le COI change dans le temps en fonction de plusieurs paramètres : distance du terminal par rapport à la station, interférences, présence d'obstacles à la propagation (pluie, arbre, etc.), le paramètre le plus impactant étant la distance entre le terminal et la station de base 100. Cette information peut être remontée régulièrement par le terminal ce qui suppose une confiance de la part du fournisseur de contenu, ou être 15 fournie par le serveur 200. La technologie radio utilisée est une information fournie par le terminal. La bande passante du canal correspond à la taille de la bande de fréquences utilisée par la station, octroyée à l'opérateur du réseau d'accès mobile. Elle permet de connaître la division en nombre de RBs. Il s'agit d'une information statique fournie aux 20 serveurs de contenu 300a et 300b lors d'une phase d'initialisation. La correspondance entre le COI et le "TBS" (Transport Block Size, c'est-à-dire le nombre de bits émis par ms) dépend de l'équipement que la station de base 100 utilise. Cette information qui n'est pas statique est connue du serveur de contrôle 200 et peut être transmise au serveurs de contenu 300a et 300b de façon dynamique au 25 cours du temps. Le TBS dépend également de la bande passante du canal. A un COI et une bande passante correspond un TBS. Le MIMO utilisé, 2x2 ou 4x4 par exemple, dépend de l'équipement que la station de base utilise. Cette information peut être fournie par le serveur de contrôle 200 aux serveurs de contenu 300a et 300b à l'initialisation. 30 Par exemple, supposant: 15 - une bande passante du canal de 20 MHZ, divisée en 100 RB (par intervalle de temps) - un COI = 15 correspondant à un TBS = 75376 bits par ms. - un MIMO 2x2, 5 100 RB permettent l'envoi de 75376 x 2 (MIMO 2x2 utilisé) bits, c'est à dire 150752 bits. La capacité de 1 RB est donc de 1507 bits. Donc, si lors de l'étape El a, le serveur de contenu 300a a déterminé qu'il souhaite transmettre au terminal 100a un morceau de flux dont le volume est de 0,9 Mo, le nombre N0a de RBs qu'il doit réserver dans ces conditions est de 600. 10 De façon similaire, lors d'une étape El b, le serveur de contenu 300b détermine aussi un nombre de blocs RB à réserver auprès du serveur de contrôle 200, dont la valeur est NOb. Lors d'une étape E2a, le serveur de contenu 300a émet une première demande de réservation pour un nombre de blocs égal à N0a, à destination du serveur de 15 contrôle 200. Cette demande peut être transportée dans un message utilisant un protocole quelconque, par exemple une requête http avec un corps XML comprenant un paramètre . Lors d'une étape E2b, le serveur de contenu 300b émet une première demande de réservation pour un nombre de blocs égal à N0b, aussi à destination du serveur de 20 contrôle 200. On comprend que ces deux premières demandes de réservation sont faites par les serveurs de contenu 300a et 300b sans concertation l'un avec l'autre, et sans connaissance du nombre total de blocs dont dispose le serveur de contrôle 200 pour satisfaire leurs demandes respectives de réservation. Le serveur de contrôle 200 connait, pour tout intervalle de temps, le nombre de 25 blocs RB disponibles, Ndis, pour l'émission de données par voie radio électrique à partir de la station de base 100 vers tous les terminaux mobiles attachés à la station de base et ayant fait des réservations de ressource, c'est-à-dire, dans notre exemple simplifié, le nombre de blocs disponibles pour l'émission de données de la station de base 100 vers les 2 terminaux 100a et 100b. 30 Lors d'une étape E3, le serveur de contrôle 200 calcule un écart entre Ndis, le 16 nombre de blocs disponibles, et la somme des blocs demandés en réservation, c'est-à-dire N0a+NOb. Si cet écart est petit, par exemple inférieur ou égal à un seuil S déterminé, le serveur de contrôle 200 décide, lors d'une étape E4, d'allouer à chacun des serveurs 5 de contenu 300a et 300b un nombre proche ou égal aux nombres de blocs RB qu'ils ont demandés (respectivement N0a et N0b). Si l'écart est grand mais que l'offre est supérieure à la demande, le serveur de contrôle 200 fait de même. Si l'écart est grand, par exemple supérieur au seuil S, et si l'offre est inférieure à la demande, le serveur de contrôle 200 décide alors d'entrer dans un cycle C de 10 négociation avec les terminaux demandeurs 100a et 100b, dont le but est de réduire l'écart entre l'offre (le nombre de blocs disponibles, Ndis) et la demande (le nombre de blocs demandés, N0a+N0b). Au moins un cycle C de négociation peut être nécessaire pour faire converger offre et demande, et un seul sera décrit. Les étapes du cycle C de négociation sont 15 indiquées par une lettre C suivie d'autres caractères. Lors d'une étape 04, comme la demande est supérieure à l'offre, le serveur de contrôle 200 décide de modifier le coût d'utilisation des blocs RB par les terminaux. Initialement, ce coût peut être inexistant, ou d'une valeur connue des terminaux. Par simplicité, il est considéré que, en dehors du cycle C, le coût unitaire du RB est 20 standard et constant ou ne change pas assez fréquemment pour avoir un impact sur les demandes de réservation faites par les serveurs de contenu lors des étapes précédentes E2a et E2b. Lors d'une étape C5a, le serveur de contrôle 200 émet donc une réponse de réservation vers le serveur de contenu 300a, non pas pour lui indiquer que sa 25 demande est satisfaite, ou pour lui indiquer le nombre de RB qui lui est alloué, mais pour lui fournir une information relative à une modification du coût unitaire du RB. Cette information peut être la nouvelle valeur du coût unitaire du RB, ou la valeur d'un surcoût par rapport au coût unitaire standard du RB. Cette réponse peut être transportée dans un message utilisant un protocole quelconque, par exemple une 30 requête http avec un corps XML comprenant un paramètre . 17 De façon similaire, lors d'une étape C5b, le serveur de contrôle 200 émet une réponse de réservation également vers le serveur de contenu 300b, comprenant la même information relative à la modification du coût unitaire du RB. Lors d'une étape C6a, le serveur de contenu 300a détermine un nouveau 5 nombre de blocs RB à réserver, NCla, auprès du serveur de contrôle 200, en fonction des paramètres liés au contenu demandé et en fonction de paramètres liés au terminal, comme lors de l'étape El a, à la différence que dans cette étape C6a, le serveur de contenu 300a détermine ce nouveau nombre de blocs à réserver également en fonction de la valeur du coût unitaire modifié du RB, reçue lors de l'étape C5a. Même 10 si un coût par RB augmenté par le serveur de contrôle 200 est fait avec l'objectif d'inciter le serveur de contenu 300a à diminuer le nombre de RB dont il demande la réservation, il peut décider de maintenir le même nombre, par exemple parce qu'il a obtenu une indication que la mémoire tampon du terminal 100a est vide ou presque vide. Aussi, si par exemple le serveur de contenu 300a sert des flux distincts à 15 plusieurs terminaux dans le même réseau d'accès mobile (la même cellule), et pas seulement au terminal 100a, il peut décider de diminuer le nombre de RB dont il demande la réservation pour une partie des terminaux, et de le maintenir pour certains terminaux privilégiés, tout en diminuant le nombre total pour l'ensemble des terminaux qu'il sert. 20 De façon similaire, lors d'une étape C6b, le serveur de contenu 300b détermine un nouveau nombre de blocs RB, NC1b, à réserver auprès du serveur de contrôle 200. Lors d'une étape C7a, le serveur de contenu 300a émet une deuxième demande de réservation pour un nombre de blocs égal à NC1 a, à destination du serveur de contrôle 200. 25 De façon similaire, lors d'une étape C7b, le serveur de contenu 300a émet une deuxième demande de réservation pour un nombre de blocs égal à NC1b, à destination du serveur de contrôle 200. Cette deuxième demande peut être transportée dans un message utilisant un protocole quelconque, par exemple une requête http avec un corps XML comprenant un paramètre . 30 Lors d'une étape C8, le serveur de contrôle 200, ayant reçu les deuxièmes 18 demandes de réservation des serveurs de contenu 300a et 300b, calcule un écart entre Ndis, le nombre de blocs disponibles, et la somme des blocs demandés en réservation, c'est-à-dire NC1a+NC1b. Si cet écart est petit, par exemple inférieur ou égal au seuil S déterminé, le 5 serveur de contrôle 200 décide de sortir du cycle C de négociation et de mettre en oeuvre l'étape E4 déjà décrite, c'est-à-dire d'allouer à chacun des serveurs de contenu 300a et 300b un nombre proche ou égal aux nombres de blocs RB qu'ils ont demandés (respectivement NC1a et NC1b). Lors de l'étape E4, particulièrement lorsqu'elle est effectuée après au moins 10 une itération du cycle C, il est avantageux que le serveur de contrôle 200 mémorise le nombre de blocs alloués à chacun des serveurs de contenus ainsi que le coût unitaire par bloc RB utilisé, pour des fins de facturation ultérieure aux opérateurs gérant les serveurs de contenu. Si par contre l'écart calculé lors de l'étape 08 est grand, par exemple supérieur 15 au seuil S, le serveur de contrôle 200 décide alors de rester dans le cycle C de négociation, en mettant en oeuvre une nouvelle fois toutes les étapes du cycle C, de l'étape 04 jusqu'à l'étape 08. Si l'écart reste grand après plusieurs itérations du cycle C de négociation, une autre condition pour sortir du cycle peut être un temps maximum écoulé depuis la 20 première itération, ou un nombre maximum de d'itérations, autrement dit l'atteinte d'une limite au nombre de deuxièmes demandes de réservation que peuvent émettre les serveurs de contenu. Suite à l'étape E4 de détermination de nombres de blocs RB alloués, le serveur de contrôle 200 en informe les serveurs de contenu. 25 Lors d'une étape E5a, le serveur de contrôle 200 émet une réponse d'allocation au serveur 300a comprenant une information relative au nombre de blocs RB qui sont alloués pour la transmission des données du serveur 300a par la station de base 100 vers le terminal 100a. Cette réponse peut être transportée dans un message utilisant un protocole quelconque, par exemple une requête http avec un corps XML 30 comprenant un paramètre . 19 De façon similaire, lors d'une étape E5b, le serveur de contrôle 200 émet une réponse d'allocation au serveur 300b comprenant une information relative au nombre de blocs RB qui sont alloués pour la transmission des données du serveur 300b par la station de base 100 vers le terminal 100b. 5 Lors d'une étape E6a, le serveur de contenu 300a détermine en fonction du nombre de RB alloués le volume de données faisant partie d'un flux, ou morceaux de flux, qu'il devra transférer à la station de base 100 pour qu'elle l'émette vers le terminal 100a. Cette détermination est l'opération inverse de l'étape El a, où le serveur 300a déterminait un nombre de RB en fonction de paramètres liés au flux de données. 10 De façon similaire, lors d'une étape E6b, le serveur de contenu 300b détermine en fonction du nombre de RB alloués la taille d'un morceau de flux. Lors d'une étape E300a connue, en réponse à la requête pour un contenu multimédia émanant du terminal 100a émise lors de l'étape E100a, le serveur de contenu 300a émet son morceau de flux vers le terminal 100a au travers de la station 15 de base 100. De façon similaire, lors d'une étape E300b connue, en réponse à la requête pour un contenu multimédia émanant du terminal 100b émise lors de l'étape E100b, le serveur de contenu 300b émet son morceau de flux vers le terminal 100b au travers de la station de base 100. 20 En relation avec la figure 3, on présente maintenant un exemple de structure d'un dispositif de réservation de blocs de ressource physique d'un réseau d'accès mobile, selon un aspect de l'invention. Le dispositif 300 de réservation de blocs de ressource physique d'un réseau 25 d'accès mobile met en oeuvre le procédé de réservation de blocs de ressource physique d'un réseau d'accès mobile, dont différents modes de réalisation viennent d'être décrits. Un tel dispositif 300 peut être mis en oeuvre dans un serveur de contenu, un serveur de cache, ou tout autre serveur apte émettre des flux de données multimédia 30 vers des terminaux mobile. 20 Par exemple, le dispositif 300 comprend une unité de traitement 330, équipée par exemple d'un microprocesseur pP, et pilotée par un programme d'ordinateur 310, stocké dans une mémoire 320 et mettant en oeuvre le procédé de réservation selon l'invention. A l'initialisation, les instructions de code du programme d'ordinateur 310 5 sont par exemple chargées dans une mémoire RAM, avant d'être exécutées par le processeur de l'unité de traitement 330. Le dispositif 300 comprend également : - un module 301 de détermination, apte à, et configuré pour déterminer un nombre de blocs de ressource à réserver, en fonction de paramètres 10 liés à un flux de données entre le dispositif 300 et un terminal mobile, et d'un niveau de qualité d'une connexion d'un terminal à un réseau d'accès mobile, - un émetteur 302 apte à, et configuré pour émettre une première demande de réservation de blocs de ressource (ResReq), comprenant 15 une valeur d'un nombre de blocs déterminée par le dispositif 300, vers une entité de contrôle du réseau d'accès mobile, - un récepteur 303 apte à, et configuré pour recevoir une réponse d'allocation de blocs de ressource en provenance de l'entité de contrôle (AllocRep), comprenant une valeur d'un nombre de blocs alloués au flux. 20 Avantageusement, le module 301 est également apte à, et configuré pour prendre en compte un coût unitaire par bloc de ressource. Avantageusement, le récepteur 303 est également apte à, et configuré pour recevoir une réponse de réservation (ResRep), comprenant un paramètre relatif à un coût unitaire d'un bloc de ressource. 25 Avantageusement, l'émetteur 302 est également apte à, et configuré pour émettre une deuxième demande de réservation de blocs de ressource (ResReq), comprenant une valeur révisée d'un nombre de blocs à réserver, déterminé au moins en fonction du coût unitaire d'un bloc de ressource. 30 En relation avec la figure 4, on présente maintenant un exemple de structure 21 d'un dispositif d'allocation de blocs de ressource physique d'un réseau d'accès mobile, selon un aspect de l'invention. Le dispositif 200 d'allocation de blocs de ressource physique d'un réseau d'accès mobile met en oeuvre le procédé d'allocation de blocs de ressource physique 5 d'un réseau d'accès mobile, dont différents modes de réalisation viennent d'être décrits. Un tel dispositif 200 peut être mis en oeuvre dans un serveur de contrôle, connecté à une station de base et apte à gérer le trafic de, et vers, des terminaux mobiles, ainsi qu'a accéder à des informations en temps réel sur le fonctionnement de la partie radio de la station de base. Ce serveur de contrôle est par exemple de type 10 MEC (Mobile Edge Computing). Par exemple, le dispositif 200 comprend une unité de traitement 230, équipée par exemple d'un microprocesseur uP, et pilotée par un programme d'ordinateur 210, stocké dans une mémoire 220 et mettant en oeuvre le procédé de réservation selon l'invention. A l'initialisation, les instructions de code du programme d'ordinateur 210 15 sont par exemple chargées dans une mémoire RAM, avant d'être exécutées par le processeur de l'unité de traitement 230. Le dispositif 200 comprend également : - un récepteur 201 apte à, et configuré pour recevoir des demandes de réservation de blocs de ressource (ResReq), comprenant une valeur 20 d'un nombre de blocs demandé par des serveurs de contenu, - un module 202 de calcul, apte à, et configuré pour calculer un écart entre un nombre de blocs disponibles dans le réseau d'accès mobile, et le total des nombres de blocs demandés, - un module 203 de détermination, apte à, et configuré pour déterminer 25 au moins en fonction de l'écart calculé, des valeurs de nombres de blocs alloués aux serveurs de contenus, - un émetteur 204 apte à, et configuré pour émettre des réponses d'allocation de blocs de ressource (AllocRep), comprenant des valeurs de nombres de blocs qui sont alloués aux serveurs de contenu. 30 Avantageusement, le dispositif 200 comprend également un module 205 22 d'ajustement, apte à, et configuré pour ajustement du coût unitaire au moins en fonction de l'écart. Avantageusement, l'émetteur 204 est également apte à, et configuré pour émettre des réponses de réservation vers les serveurs de contenu (ResRep), 5 comprenant une information relative au coût unitaire. Les modules décrits en relation avec les figures 3 et 4 peuvent être matériels ou logiciels. Ces figures 3 et 4 illustrent seulement une manière particulière, parmi plusieurs 10 possibles, de réaliser les procédés détaillés ci-dessus, en relation avec les figures 1 et 2. En effet, la technique de l'invention se réalise indifféremment sur une machine de calcul reprogrammable (un ordinateur PC, un processeur DSP ou un microcontrôleur) exécutant un programme comprenant une séquence d'instructions, ou sur une machine de calcul dédiée (par exemple un ensemble de portes logiques comme un 15 FPGA ou un ASIC, ou tout autre module matériel). Dans le cas où l'invention est implantée sur une machine de calcul reprogrammable, le programme correspondant (c'est-à-dire la séquence d'instructions) pourra être stocké dans un médium de stockage amovible (tel que par exemple une disquette, un CD-ROM ou un DVD-ROM) ou non, ce médium de stockage étant lisible 20 partiellement ou totalement par un ordinateur ou un processeur. Les exemples de réalisation de l'invention qui viennent d'être présentés ne sont que quelques-uns des modes de réalisation envisageables. Ils montrent que l'invention permet d'obtenir une consommation optimale des ressources radio du réseau d'accès 25 mobile, sans que les fournisseurs de contenus ne partagent, ni entre eux, ni avec les opérateurs de réseaux d'accès mobile, les informations qu'ils REVENDICATIONS1. Procédé de réservation de blocs de ressource physique d'un réseau d'accès mobile (MAN), mis en oeuvre par un serveur de contenu (300a, 300b) configuré pour émettre un flux de données demandé par un terminal (100a, 100b) connecté au réseau d'accès mobile avec un niveau de qualité déterminé, le procédé comprenant : - détermination (El a, El b) d'une valeur d'un nombre de blocs à réserver, en fonction de paramètres liés au flux de données, et du niveau de qualité déterminé, - émission (E2a, E2b) d'une première demande de réservation de blocs de ressource, comprenant la valeur déterminée du nombre de blocs à réserver, vers une entité de contrôle (200) du réseau d'accès mobile, - réception (E5a, E5b) d'une réponse d'allocation de blocs de ressource en provenance de l'entité de contrôle, comprenant une valeur d'un nombre de blocs alloués au serveur de contenu. 2. Procédé de réservation selon la revendication 1, où la détermination d'une valeur d'un nombre de blocs à réserver est faite aussi en fonction d'un coût unitaire par bloc. 3. Procédé de réservation selon l'une des revendications 1 ou 2, comprenant, préalablement à la réception (E5a, E5b) de la réponse d'allocation : - réception (C5a, C5b) d'une réponse de réservation en provenance de l'entité de contrôle (200), comprenant un paramètre relatif à un coût unitaire d'un bloc, - émission (C7a, C7b) d'une deuxième demande de réservation de blocs de ressource, comprenant une valeur révisée du nombre de blocs à réserver, déterminée (C6a, C6b) au moins en fonction du coût unitaire. 4. Procédé d'allocation de blocs de ressource physique d'un réseau d'accès mobile (MAN), pour une pluralité de serveurs de contenu (300a, 300b) configurés pour émettre des flux de données vers des terminaux (100a, 100b) connectés au réseau d'accès mobile, le procédé comprenant : 24 - réception (E2a, E2b) de premières demandes de réservation de blocs, en provenance de la pluralité de serveurs de contenu, une première demande d'un serveur de contenu comprenant une valeur d'un nombre de blocs demandés par ce serveur de contenu, 5 - calcul (E3, 08) d'un écart entre un nombre de blocs disponibles dans le réseau d'accès mobile, et le total des nombres de blocs demandés, - détermination (E4), au moins en fonction de l'écart, de valeurs de nombres de blocs alloués aux serveurs de contenus, - émission (E5a, E5b) de réponses d'allocation de blocs vers la pluralité de serveurs 10 de contenus, une réponse d'allocation à un serveur de contenu comprenant la valeur du nombre de blocs qui sont alloués à ce serveur de contenu. 5. Procédé d'allocation selon la revendication 4, où un coût unitaire par bloc est déterminé, et où le procédé comprend en outre, préalablement à la détermination (E4) 15 des nombres de blocs alloués : - ajustement (04) du coût unitaire au moins en fonction de l'écart, - émission (05a, 05b) de réponses de réservation vers la pluralité de serveurs de contenu, comprenant une information relative au coût unitaire, - réception (07a, 07b) de deuxièmes demandes de réservation de blocs, en 20 provenance de la pluralité de serveurs de contenus, une deuxième demande d'un serveur de contenu comprenant une valeur révisée du nombre de blocs demandés par ce serveur de contenu, - calcul (08) de l'écart entre le nombre de blocs disponibles, et le total des nombres révisés de blocs demandés. 25 6. Dispositif de réservation de blocs de ressource physique d'un réseau d'accès mobile (MAN), compris dans un serveur de contenu (300a, 300b) configuré pour émettre un flux de données demandé par un terminal (100a, 100b) connecté au réseau d'accès mobile avec un niveau de qualité déterminé, le dispositif comprenant : 30 - un module de détermination (301) d'une valeur d'un nombre de blocs à réserver, 25 en fonction de paramètres liés au flux de données, et du niveau de qualité déterminé, - un émetteur (302) d'une première demande de réservation (ResReq) de blocs de ressource, comprenant la valeur déterminée du nombre de blocs, vers une entité 5 de contrôle du réseau d'accès mobile, - un récepteur (303) d'une réponse d'allocation (AllocRep) de blocs de ressource en provenance de l'entité de contrôle, comprenant une valeur d'un nombre de blocs alloués au serveur de contenu. 10 7. Dispositif de réservation selon la revendication 6, où le module de détermination (301) est également apte à, et configuré pour prendre en compte un coût unitaire par bloc de ressource, où le récepteur (303) est également apte à, et configuré pour recevoir une réponse de réservation (ResRep), comprenant un paramètre relatif au coût unitaire, et où l'émetteur (302) est également apte à, et configuré pour émettre 15 une deuxième demande de réservation (ResReq) de blocs de ressource, comprenant une valeur révisée d'un nombre de blocs à réserver, déterminé au moins en fonction du coût unitaire. 8. Dispositif d'allocation de blocs de ressource physique d'un réseau d'accès mobile 20 (MAN), pour une pluralité de serveurs de contenu (300a, 300b) configurés pour émettre des flux de données vers des terminaux (100a, 100b) connectés au réseau d'accès mobile, le dispositif comprenant : - un récepteur (201) de premières demandes de réservation (ResReq) de blocs, en provenance de la pluralité de serveurs de contenu, une première demande d'un 25 serveur de contenu comprenant une valeur d'un nombre de blocs demandés par ce serveur de contenu, - un module de calcul (202) d'un écart entre un nombre de blocs disponibles dans le réseau d'accès mobile, et le total des nombres de blocs demandés, - un module de détermination (203), au moins en fonction de l'écart, de valeurs de 30 nombres de blocs alloués aux serveurs de contenus, 26 - un émetteur (204) de réponses d'allocation de blocs vers la pluralité de serveurs de contenus, une réponse d'allocation à un serveur de contenu comprenant la valeur du nombre de blocs qui sont alloués à ce serveur de contenu. 5 9. Dispositif d'allocation selon la revendication 8, comprenant en outre un module d'ajustement (205) du coût unitaire en fonction de l'écart calculé, où l'émetteur (204) est en outre apte à émettre des réponses de réservation (ResRep) vers la pluralité de serveurs de contenu (300a, 300b), comprenant une information relative au coût unitaire, et où le récepteur (201) est apte à recevoir des deuxièmes demandes de réservation 10 (ResReq) de blocs, en provenance de la pluralité de serveurs de contenus, une deuxième demande d'un serveur de contenu comprenant un nombre révisé de blocs demandés par ce serveur de contenu. 10. Système de partage de blocs de ressource physique d'un réseau d'accès mobile 15 (MAN), comprenant au moins deux dispositifs de réservation (300a, 300b) conforme à la revendication 6, et un dispositif d'allocation (200) conforme à la revendication 8, le dispositif d'allocation étant connecté aux dispositifs de réservation et à une station de base (100). 20 11. Programme d'ordinateur, comprenant des instructions pour la mise en oeuvre des étapes du procédé de réservation de blocs de ressource physique d'un réseau d'accès mobile selon la revendication 1, lorsque ce programme est exécuté par un processeur. 12. Support d'informations lisible par un serveur de contenu, et comportant des 25 instructions d'un programme d'ordinateur conforme à la revendication 11. 13. Programme d'ordinateur, comprenant des instructions pour la mise en oeuvre des étapes du procédé d'allocation de blocs de ressource physique d'un réseau d'accès mobile selon la revendication 4, lorsque ce programme est exécuté par un processeur. 30 27 14. Support d'informations lisible par un serveur de contrôle connecté à une station de base, et comportant des instructions d'un programme d'ordinateur conforme à la revendication 13. 5