FR 3060930 A1 20180622 FR 1662805 A 20161219 1 Procédé de gestion d'une requête de délestage de code, procédé de délestage de code informatique, dispositifs, équipement serveur, équipement terminal et programmes d'ordinateurs associés 1. Domaine de l'invention Le domaine de l'invention est celui des réseaux de télécommunications mobiles, en particulier celui d'un équipement d'accès radio hébergeant un serveur disposant de capacités de calcul. Plus précisément, l'invention propose une technique permettant à un équipement mobile de délester ou déporter l'exécution de code de programme informatique au niveau de cet équipement d'accès radio. L'invention s'applique à tous les services proposés par un terminal mobile à son utilisateur, dont l'exécution nécessite des ressources importantes de calcul ou de stockage et/ou est soumise à des contraintes temps réel, tels que les jeux vidéo, la réalité virtuelle ou augmentée, la reconnaissance faciale, ou plus généralement toute application de traitement d'images ou de contenu multimédia. 2. Art antérieur On connait du document intitulé « Mobile-Edge Computing - Introductory technical white paper », publié par le « European Telecommunications Standard Institute (ETSI) en septembre 2014, une architecture de réseau de télécommunications mobiles, selon laquelle un équipement d'accès radio, par exemple de type « e-nodeB » selon la technologie LTE (pour « Long Term Evolution », en anglais), spécifiée par la 4ème génération de la norme 3GPP ou 4G (pour « Third Generation Partnership Project » en anglais), est associé à un équipement serveur, agencé pour mettre d'importantes capacités de calcul à disposition de terminaux mobiles connectés à cet équipement d'accès radio. On entend par « associé » le fait que l'équipement serveur soit intégré dans le même équipement physique, ou bien installé sur un même site et connecté à l'équipement d'accès via une connexion point à point haut débit de type fibre optique, ou encore installé plus en amont dans le réseau de télécommunications, mais distant d'au plus un saut de l'équipement d'accès et 3060930 2 bénéficiant d'une connexion haut débit avec l'équipement d'accès, de telle sorte que la latence de communication entre eux, ou latence du réseau de collecte (pour « backhaul latency », en anglais) puisse être considérée comme négligeable. Cette architecture présente l'avantage d'offrir à un terminal mobile une solution de 5 proximité pour délester des tâches d'exécution de code, sans l'inconvénient d'introduire de délai de transmission prohibitif. On connait en outre du document de You et al. intitulé « Multiuser Resource Allocation for Mobile-Edge Computation Offloading », publié sur le « Computing Research Repository (CoRR), vol. abs/1604.02519, en 2016, un système de délestage de code qui alloue à des utilisateurs de 10 terminaux mobiles présents dans la cellule radio d'un équipement d'accès équipé d'un serveur MEC, des créneaux temporels (pour « slots », en anglais), pour délester une portion de leur code informatique à l'équipement serveur MEC, avec pour contrainte d'optimiser globalement la consommation énergétique des terminaux mobiles. Plus précisément, le système évalue pour un terminal mobile une priorité de délestage en fonction d'un gain du canal de transmission entre le 15 terminal et l'équipement d'accès et d'une consommation d'énergie du terminal. Il compare cette priorité à un seuil et décide ensuite si l'utilisateur peut délester une partie ou l'intégralité de son code informatique selon que cette priorité est inférieure ou supérieure à ce seuil. 3. Inconvénients de l'art antérieur 20 Un inconvénient de cette solution est qu'elle ne prend pas en compte un délai de transmission ou latence sur le lien radio entre le terminal mobile et l'équipement d'accès. Or, pour certaines applications ou services dits « temps réel », une latence trop importante dégrade fortement l'expérience utilisateur et remet en cause l'intérêt même de recourir à du délestage de code. 25 4. Objectifs de l'invention L'invention vient améliorer la situation. L'invention a notamment pour objectif de pallier ces inconvénients de l'art antérieur. Plus précisément, un objectif de l'invention est de proposer une solution qui permette 30 notamment de garantir qu'un équipement terminal n'ait recours au délestage de code que lorsque le lien radio n'introduit pas un délai de transmission incompatible avec l'application visée. 3060930 3 5. Exposé de l'invention Ces objectifs, ainsi que d'autres qui apparaîtront par la suite, sont atteints à l'aide d'un procédé de traitement d'une requête d'autorisation de délestage de code de programme, en provenance d'un 5 équipement terminal et reçue par un équipement serveur, intégré à ou connecté par un lien haut débit à un équipement d'accès à un réseau de télécommunications, ledit équipement terminal étant connecté audit équipement d'accès au réseau par un lien radio, ledit équipement serveur comprenant au moins un module de traitement dédié à l'exécution de code délesté. Selon l'invention, ledit procédé comprend les étapes suivantes : 10 - estimation d'au moins une une mesure de latence sur le lien radio au moins à partir de paramètres radio fournis par l'équipement d'accès ; - prise de décision relative à une autorisation de délestage de code en provenance dudit équipement terminal par le serveur en fonction de la au moins une mesure de latence estimée ; 15 - en cas de décision positive, transmission à l'équipement client d'une réponse comprenant au moins la mesure de latence estimée et une adresse IP du module de traitement. Avec l'invention, le serveur exploite les paramètres radio caractérisant le lien radio, disponibles au niveau de l'équipement d'accès, pour estimer une mesure de latence réaliste, à partir de laquelle il 20 décide si le délestage de code est adapté pour ce terminal mobile. Lorsqu'il délivre une autorisation de délestage, le serveur transmet au terminal la mesure de latence qu'il a estimée, afin que celui-ci puisse l'exploiter de son côté. Avantageusement, les paramètres radio comprennent des paramètres représentatifs de conditions de transmission radio et des paramètres représentatifs d'une qualité de service souscrite par 25 l'utilisateur du terminal. L'équipement d'accès connait en effet non seulement les conditions du canal de transmission radio, mais aussi l'abonnement souscrit par l'utilisateur du terminal mobile, donc le niveau de qualité de service auquel son abonnement lui donne droit. Il peut les exploiter avantageusement pour estimer 3060930 4 une mesure de latence plus réaliste que celle obtenue par l'équipement terminal à l'aide de méthodes classiques. Selon un aspect de l'invention, suite à une décision positive, l'étape d'estimation d'une mesure de 5 latence est répétée à intervalles réguliers de sorte à obtenir une mesure de latence mise à jour, en ce que la mesure de latence mise à jour est comparée à la mesure de latence précédente et, lorsqu'une différence entre les deux mesures successives est supérieure à un seuil prédéterminé, elle est transmise à l'équipement terminal. Un avantage est que l'équipement terminal est informé régulièrement des évolutions notables du 10 délai de transmission sur le lien radio et qu'il peut ainsi adapter la mise en oeuvre de délestage de code en conséquence. Selon un autre aspect de l'invention, la requête comprend une information relative à une quantité de ressources requise et le procédé comprend en outre une étape d'obtention d'une information relative à une quantité de ressources disponible dans l'équipement serveur, la prise de décision est 15 en outre fonction de la quantité de ressources requise et de la quantité de ressources disponible et la réponse comprend une information relative à une quantité de ressources allouée à l'équipement terminal. Un avantage est que le serveur n'autorise le délestage de code que s'il dispose des ressources requises par le terminal mobile. 20 Selon un autre aspect de l'invention, des informations d'accès de l'équipement terminal au lien radio montant ayant été obtenues, lesdites informations comprenant un nombre d'intervalles d'émission alloué par l'équipement d'accès à l'équipement terminal pendant une période temporelle prédéterminée, l'étape d'estimation d'une mesure de latence comprend une sous- étape de calcul d'un temps d'aller-retour entre l'équipement d'accès et l'équipement terminal en fonction d'un 25 rapport entre un nombre total d'intervalles d'émission dans la période et le nombre alloué à l'équipement terminal. L'équipement serveur profite de sa proximité avec l'équipement d'accès pour accéder à des informations que ce dernier obtient et stocke en mémoire. Le rapport calculé lui fournit un délai 3060930 5 moyen d'accès au canal par le terminal. Une estimation d'un temps d'aller-retour peut être simplement obtenue en multipliant ce délai par 2. Avantageusement, l'étape de calcul d'un temps d'aller-retour comprend un moyennage pondéré du temps d'aller-retour courant et d'un temps d'aller-retour calculé pour une période temporelle 5 précédente. De cette manière, on lisse les artéfacts en vue d'obtenir une valeur plus stable. Selon un autre aspect de l'invention, le procédé de traitement d'une requête d'autorisation de délestage de code comprend une étape préalable d'établissement d'une session de communication applicative entre l'équipement terminal et l'équipement serveur, selon un protocole de communication comprenant au moins un message appartenant au groupe comprenant : 10 - un message de requête d'autorisation de délestage de code - un message de réponse à une requête d'autorisation de délestage de code ; - un message de requête de délestage d'un groupe de classes d'un code ; - un message de réponse à une requête de délestage d'un groupe de classes ; - un message de requête d'enregistrement de données de réponse à une requête de 15 délestage d'un groupe de classes dans une mémoire partagée ; et - un message de notification de mise à jour des données enregistrées dans une mémoire partagée. Un avantage de ce protocole est qu'il est peu contraignant. Contrairement aux solutions de l'art antérieur basées sur des interfaces de programmation du type RPC (pour « Remote Procedure 20 Calls », en anglais) ou RMI (pour « Remote Method invocation », en anglais), il ne nécessite pas de configuration préalable du terminal ni du code de programme, et d'autre part il n'impose pas de blocage du processus d'exécution du code côté terminal tant que le résultat de la classe délesté n'a pas été reçue du serveur. Les différents modes ou caractéristiques de réalisation mentionnés ci-après peuvent être ajoutés 25 indépendamment ou en combinaison les uns avec les autres, aux caractéristiques du procédé de traitement d'une requête d'autorisation de délestage défini ci-dessus. L'invention concerne également un dispositif de traitement d'une requête d'autorisation de délestage adapté pour mettre en oeuvre le procédé selon l'un quelconque des modes particuliers de réalisation définis ci-dessus. Ce dispositif pourra bien sûr comporter les différentes caractéristiques 30 relatives au procédé de traitement d'une requête d'autorisation de délestage selon l'invention. 3060930 6 Ainsi, les caractéristiques et avantages de ce dispositif sont les mêmes que ceux du procédé de traitement d'une requête d'autorisation de délestage, et ne sont pas détaillés plus amplement. Corrélativement l'invention concerne aussi un procédé de délestage de code par un équipement terminal connecté à un équipement d'accès à un réseau de télécommunications par un 5 lien radio, vers un équipement serveur intégré à ou connecté par un lien haut débit audit équipement d'accès, caractérisé en ce qu'il comprend les étapes suivantes : - émission d'une requête d'autorisation de délestage de code à destination de l'équipement serveur ; - sur réception d'une réponse comprenant au moins une mesure de latence estimée sur 10 le lien radio et une adresse d'un module de calcul dudit équipement serveur apte à exécuter au moins une portion de code pour ledit équipement terminal, prise de décision relative au délestage d'une portion de code par le module de calcul au moins à partir de la mesure de latence reçue. Un avantage est que le terminal bénéficie d'une supervision du réseau pour gérer le délestage 15 d'une portion de son code. Selon un aspect de l'invention, la prise de décision prend en compte une information de capacité allouée par le serveur. Un avantage est qu'on autorise un délestage de code que si les ressources nécessaires sont disponibles au niveau de l'équipement serveur. 20 Selon un autre aspect de l'invention, le code étant divisé en une pluralité de portions de code, dites classes, le procédé comprend une étape de partitionnement de la pluralité de classes en au moins deux groupes, l'étape de prise de décision décide, pour un groupe de classes, s'il doit être délesté, au moins en fonction de la mesure de latence estimée, et suite à une décision de délestage d'un groupe de classes, le procédé comprend l'émission d'un message de requête d'exécution de 25 code à destination de l'équipement serveur, ladite requête comprenant au moins une information relative à un nombre de classes à exécuter et une information relative à un délai de réponse attendu. 3060930 7 Un avantage est que le terminal profite d'informations de latence fournies par le réseau pour optimiser sa gestion du délestage d'un code de programme. Selon un autre aspect de l'invention, le procédé de délestage de code comprend une étape préalable d'établissement d'une session de communication applicative entre l'équipement terminal 5 et l'équipement serveur, selon un protocole de communication comprenant au moins un message appartenant au groupe comprenant : - un message de requête d'autorisation de délestage de code - un message de réponse à une requête d'autorisation de délestage de code ; - un message de requête de délestage d'un groupe de classes d'un code ; 10 - un message de réponse à une requête de délestage d'un groupe de classes ; - un message de requête d'enregistrement de données de réponse à une requête de délestage d'un groupe de classes dans une mémoire partagée ; et - un message de notification de mise à jour des données enregistrées dans une mémoire partagée. 15 Les différents modes ou caractéristiques de réalisation mentionnés ci-après peuvent être ajoutés indépendamment ou en combinaison les uns avec les autres, aux caractéristiques du procédé de délestage de code défini ci-dessus. - L'invention concerne également un dispositif de délestage adapté pour mettre en oeuvre le 20 procédé selon l'un quelconque des modes particuliers de réalisation définis ci-dessus. Ce dispositif pourra bien sûr comporter les différentes caractéristiques relatives au procédé de délestage de code selon l'invention. Ainsi, les caractéristiques et avantages de ce dispositif sont les mêmes que ceux du procédé de délestage de code, et ne sont pas détaillés plus amplement. Corrélativement, l'invention concerne aussi un équipement serveur intégré ou connecté par 25 un lien haut débit à un équipement d'accès à un réseau de communications mobiles, comprenant au moins un module de traitement apte à exécuter au moins une portion de code délestée par un équipement terminal connecté à l'équipement d'accès et un dispositif de traitement d'une requête d'autorisation de délestage de code selon l'invention. 3060930 8 L'invention concerne en outre un équipement terminal apte à se connecter à un équipement d'accès à un réseau de communications mobiles, comprenant un dispositif de délestage de code selon l'invention. L'invention concerne encore un programme d'ordinateur comportant des instructions pour la 5 mise en oeuvre des étapes d'un procédé de traitement d'une requête d'autorisation de délestage de code tel que décrit précédemment, lorsque ce programme est exécuté par un processeur. L'invention concerne aussi un programme d'ordinateur comportant des instructions pour la mise en oeuvre des étapes d'un procédé de délestage de code tel que décrit précédemment, lorsque ce programme est exécuté par un processeur. 10 Ces programmes peuvent utiliser n'importe quel langage de programmation. Ils peuvent être téléchargés depuis un réseau de communication et/ou enregistrés sur un support lisible par ordinateur. L'invention se rapporte enfin à des supports d'enregistrement, lisibles par un processeur, intégrés ou non au dispositif de traitement d'une requête d'autorisation de délestage de code et au 15 dispositif de délestage de code selon l'invention, éventuellement amovible, mémorisant respectivement un programme d'ordinateur mettant en oeuvre un procédé de traitement d'une requête d'autorisation de délestage de code et un programme d'ordinateur mettant en oeuvre un procédé de délestage de code, tels que décrits précédemment. 20 6. Liste des figures D'autres avantages et caractéristiques de l'invention apparaîtront 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 : - la figure 1 illustre de façon schématique un équipement terminal connecté à un équipement 25 d'accès à un réseau mobile, équipé d'un équipement serveur, comprenant des capacités de délestage de code de programme ; - la figure 2 décrit les étapes d'un procédé de traitement d'une requête d'autorisation de délestage de code selon un mode de réalisation de l'invention ; - la figure 3 présente l'architecture logique d'un équipement serveur ES selon l'invention, 30 lorsque le procédé de traitement est mis en oeuvre par une application MEC , 3060930 9 - la figure 4 décrit les étapes d'un procédé de délestage de code selon un mode de réalisation de l'invention ; - les figures 5A, 5B, 5C et 5D décrivent la structure de messages échangés entre l'équipement terminal et l'équipement serveur selon un mode de réalisation de l'invention ; 5 la figure 6 illustre sous la forme d'un diagramme de flux une séquence de messages échangés entre l'équipement terminal et l'équipement serveur selon un mode de réalisation de l'invention ; - la figure 7A présente de façon schématique un exemple de structure matérielle d'un dispositif de traitement d'une requête d'autorisation de délestage de code selon 10 l'invention ; et - la figure 7B présente de façon schématique un exemple de structure matérielle d'un dispositif de délestage de code selon l'invention. 7. Description d'un mode de réalisation particulier de l'invention 15 Le principe général de l'invention repose sur le traitement d'une requête d'autorisation de délestage de code, en provenance d'un équipement terminal connecté à un équipement d'accès à un réseau mobile, par un équipement serveur hébergé par ou situé à proximité de cet équipement d'accès et possédant des ressources dédiées au délestage de code. Selon l'invention, l'équipement serveur décide d'autoriser ou non l'équipement terminal à lui délester l'exécution d'une portion de 20 code au moins en fonction d'une mesure de latence estimée sur le lien radio entre l'équipement terminal et l'équipement d'accès. Dans la suite de la description on considère un équipement serveur intégré à un réseau de télécommunications organisé selon une architecture de type MEC. Dans un tel réseau sont déployés des équipements physiques qu'on désigne par hôtes ME et qui sont agencés pour mettre à 25 disposition d'autres équipements des ressources et des services. L'équipement serveur ES en fait partie. Un hôte ME est une entité logique qui contient une plateforme ME et une infrastructure de virtualisation sur laquelle des applications sont exécutées. La plateforme ME contient un ensemble de fonctionnalités de base qui permettent aux applications de s'exécuter sur l'hôte, de découvrir et 30 de consommer des services ME, ou de les mettre à disposition d'autres équipements ou applications via un service d'enregistrement. La plateforme ME est aussi responsable de la mise en 3060930 10 application des règles de trafic pour le routage de paquets de données vers ou en provenance des applications ME, ainsi que de maintenir un sous-système DNS nécessaire pour la découverte des applications ME. Les applications ME s'exécutent sur un hôte ME en tant que machines virtuelles et sont conçues pour consommer et/ou fournir des services ME. Un de ces services fournit une 5 interface de programmation applicative ou API (pour « Application Programming Interface », en anglais) qui délivre une information de statut de l'équipement terminal UE exploitable par une application ME qu'il héberge. Une de ces interfaces est un service d'information de réseau radio, qui délivre de l'information relative au lien radio entre l'équipement terminal EU et l'équipement d'accès ("EnodeB") auquel il 10 est rattaché. Il s'agit de paramètres dits RNIS (pour « Radio Network Information Service », en anglais) et/ou EPS (pour « Evolved Packet System », en anglais) qui concernent une configuration de l'UE, la bande passante descendante/montante dont il dispose (DL/UL bandwidth, en anglais), la qualité de service à laquelle il a souscrit (GBR ou non-GBR pour « Guaranteed Bit Rate », en anglais), une configuration de l'équipement d'accès, comprenant par exemple le nombre 15 d'équipements terminaux présents dans la cellule de l'équipement d'accès. L'invention propose donc de s'appuyer sur cette architecture MEC et sur l'information qu'elle met à disposition sur l'équipement terminal et la connexion radio qui le relie à l'équipement d'accès, pour mettre en oeuvre une application de gestion de délestage de code dans l'équipement serveur. 20 En relation avec la Figure 1, on considère à titre d'exemple un équipement serveur ES hébergé dans un système MEC organisé selon l'architecture qui vient d'être décrite. Il constitue donc un hôte ME du système MEC. Cet équipement serveur est situé à proximité d'un équipement d'accès EA à un réseau mobile RM, c'est-à-dire qu'il est relié à cet équipement d'accès par une connexion comprenant au plus un saut. On considère enfin un équipement terminal UE rattaché au 25 réseau mobile RM par l'intermédiaire de l'équipement d'accès EA. Cet équipement mobile UE souhaite délester l'exécution d'une portion de code informatique auprès de l'équipement serveur ES. En relation avec la Figure 2, on décrit maintenant les étapes d'un procédé de traitement d'une requête d'autorisation de délestage de code selon un mode de réalisation de l'invention. Ce 30 procédé est mis en oeuvre par l'équipement serveur ES. Selon ce mode de réalisation, il est plus précisément exécuté par une application GDC du système MEC dédiée à la gestion du délestage de code. 3060930 11 En relation avec la Figure 4 et selon ce mode de réalisation particulier de l'invention, cette application s'exécute en tant que machine virtuelle et consomme différents services ME qui vont être détaillés ci-après. Au cours d'une étape El, une requête REQ d'autorisation de délestage de code est reçue en 5 provenance de l'équipement terminal UE. Avantageusement cette requête comprend les informations suivantes : - une quantité de ressources de calcul ou stockage requis QR pour l'exécution de ce code de programme. Cette information peut inclure par exemple le nombre d'unités de calculs requis ou CPUs (pour « Central Processing Unit », en anglais) ; 10 - une latence maximale tolérée LMT par l'application visée, par exemple 80 ms pour une application de jeu vidéo. En variante, la requête comprend une information relative à un type de code de programme et d'application visée, auquel l'équipement serveur ES sait associer une latence maximale tolérée. Par exemple, elle indique s'il s'agit d'un jeu vidéo, l'équipement serveur 15 ES en déduit que la latence maximal autorisée est de 80 ms. En réponse à cette requête, l'équipement serveur estime en E2 une mesure de latence LAT sur le lien radio entre l'équipement terminal UE et l'équipement d'accès EA. Selon un mode de réalisation de l'invention, il obtient en E2 des informations relatives au lien radio. Notamment, il accède aux paramètres RNIS et EPS précédemment évoqués. Ces 20 informations comprennent par exemple : - un nombre d'équipements terminaux actifs dans la cellule de l'équipement d'accès EA ; - un type de connexion utilisé pour l'UE ou support (pour « bearer », en anglais) en fonction de l'abonnement auquel il a souscrit et notamment un niveau de qualité de service correspondant à cet abonnement, et pour les autres équipements terminaux actifs dans la 25 cellule ; - un paramètre de qualité du canal CQI (pour « Channel Quality Information », en anglais) remonté par l'UE. - un rapport d'ordonnancement sur le lien montant (« UL Scheduling Report » en anglais), comprenant les intervalles de temps réservés par l'équipement d'accès EA à l'équipement 30 terminal UE pour émettre des données vers le réseau. 3060930 12 Avantageusement, l'application GDC en charge de la gestion du délestage de code selon l'invention s'est préalablement inscrite auprès d'un service (« common service » sur la figure 3) pour recevoir les paramètres RNIS et EPS de l'équipement terminal UE et des autres équipements terminaux actifs dans la cellule de l'équipement d'accès EA. 5 En E3, on analyse les paramètres obtenus de l'équipement d'accès EA et on estime une mesure de latence LAT sur le lien radio entre l'UE et l'équipement d'accès EA à partir de ces informations. Selon le mode de réalisation illustré par la figure 2, on en estime potentiellement trois, de manière successive, à partir de paramètres radio distincts : 1- En E31, on analyse un niveau de qualité de service dont bénéficie l'UE. L'abonnement de 10 l'UE est vérifié, à l'aide des paramètres EPS. En fonction de la classe de qualité de service QCI (pour « QoS Class Indicator », en anglais, sur la Figure 3), à laquelle son abonnement lui donne accès, l'équipement terminal bénéficie d'un canal de communication dont le niveau de qualité de service est garanti (GBR pour « Guaranteed Bit Rate », en anglais) ou non garanti (non GBR). Si l'UE ne dispose pas d'un niveau de qualité de service garanti sur 15 le canal de communication qui le relie à l'équipement, la latence qu'il va devoir supporter va varier en fonction d'un nombre d'équipements terminaux actifs dans la cellule. Si ce nombre est élevé, les paquets de données échangés entre l'UE et l'équipement serveur risquent d'être retardés. S'il bénéficie d'une qualité de service garantie, une latence maximale du lien radio est spécifiée par un paramètre relatif au délai d'un paquet (« Packet 20 Delay », en anglais, sur la Figure 3). 2- En E32, on détermine l'état du canal de transmission à l'aide notamment du paramètre CQI. On comprend que si le paramètre CQI de l'UE est très faible, les paquets de données transmis par l'UE vers l'équipement serveur vont être soumis à un délai important, ce qui va dégrader la qualité de l'application exécutée sur l'UE. En E33, on estime une mesure de 25 latence LAT sur le lien radio à partir du paramètre UL scheduling report précédemment évoqué. Par exemple, on calcule un temps d'aller-retour des données entre l'UE et l'équipement d'accès EA ou RTT (pour Round Trip Time, en anglais). Ce rapport comprend un nombre X d'intervalles temporels de transmission TTI (pour « Transmission Time Interval », en 30 anglais), égal pour la technologie LTE à 1 ms, réservés par l'équipement d'accès à l'UE pendant une période T prédéterminée. Si par exemple, on considère une période T égale à 1s, alors elle comprend T = 1000 intervalles TTI. On peut estimer le délai moyen d'accès de l'UE au réseau, pendant la période T, égal à T/X. 3060930 13 Comme on considère que la latence dans le sens descendant ne peut pas excéder la latence dans le sens montant, le temps d'aller-retour peut être alors estimé comme le double du délai moyen d'accès de l'UE au canal de transmission. On note que, du fait de la situation de l'équipement serveur à proximité de ou intégré à 5 l'équipement d'accès, on considère le délai de collecte entre l'EA et l'équipement serveur comme négligeable. Pour éviter les fluctuations soudaines, on applique avantageusement un moyennage pondéré entre le temps d'aller-retour obtenu sur une période précédente et celui obtenu pour la période courante, par exemple basée sur une technique de type EWMA (pour 10 « Exponential Weighting Moving Average », en anglais), et on aboutit à l'équation suivante : LAT = RTTmoy= a* RTTprec+ ( 1- a)* RTT - cur où ae[0,1] Un premier avantage de cette estimation est qu'elle propose une estimation de la latence 15 sur le lien radio basée sur des paramètres radio acquis sur une période temporelle suffisamment longue pour ne pas être sensibles à des fluctuations locales. Ce n'est pas le cas des techniques connues de l'homme du métier, comme par exemple celle décrite dans l'article de A. Baid et al, intitulé "Delay estimation and fast iterative scheduling policies for LTE uplink," publié dans les proceedings de la conférence 10th International Symposium on 20 Modeling and Optimization in Mobile, Ad Hoc and Wireless Networks (WiOpt), Paderborn, Germany, en 2012, pp. 89-96. Elle s'appuie sur une information de type RBS (pour Remaining Block Signal », en anglais), de nature instantanée, qui est envoyée périodiquement par l'UE à l'équipement d'accès et donc reçue avec un décalage par ce dernier. 25 Un deuxième avantage de la solution de l'invention est de ne pas surcharger le réseau, contrairement aux techniques de type « ping » classiquement mises en oeuvre côté UE. Au cours d'une étape E4, les ressources de calcul et de stockage disponibles au niveau de l'équipement serveur ES sont vérifiées. 30 Avantageusement, l'application GDC s'est inscrite auprès d'un service (« Infra services » sur la Figure 3) en charge de fournir des informations relatives aux ressources de calcul en nombre de CPU et de stockage en nombre de Go, disponibles au niveau de l'équipement serveur ES. Une 3060930 14 information relative à une quantité de ressources disponible QRD pour l'équipement UE est ainsi obtenue. En E5, un processus de décision en quatre sous-étapes peut être mis en oeuvre : 5 1- Au cours d'une première sous-étape E51, on exploite le niveau de qualité de service analysé et on décide s'il est suffisant pour qu'une autorisation de délestage soit accordée. Par exemple, si le niveau de qualité de service n'est pas garanti pour l'UE et si le nombre d'équipements terminaux actifs dans la cellule est supérieur à un seuil prédéterminé, la demande d'autorisation est rejetée et on passe à l'étape E6. Sinon, on continue le 10 processus de décision ; 2- Au cours d'une sous-étape E52, on exploite l'analyse du paramètre CQI. S'il est trop faible, on décide de rejeter la requête et on passe à l'étape E6; 3- Au cours d'une sous-étape E53, on exploite la mesure de latence estimée LAT à partir du paramètre UL scheduling report et on la compare à la latence maximale tolérée LMT 15 associée au code de programme à délester. Si la mesure LAT estimée est inférieure à la latence maximale tolérée, on continue le processus de décision, sinon on rejette la requête et on passe à l'étape E6 ; 4- Au cours d'une étape E54, on compare la quantité de ressources disponible QRD à la quantité de ressources QR demandée par l'UE. Si cette dernière est supérieure à la quantité 20 de ressources disponibles, la décision prise est négative. Bien sûr, d'autres paramètres peuvent être pris en considération dans cette prise de décision. Par exemple, elle peut intégrer un paramètre de consommation énergétique de l'UE et résulter d'une optimisation d'une contrainte énergétique, comme décrit dans le document You déjà cité. On notera que de façon alternative, l'analyse des paramètres radio peut être réalisée au fur et à 25 mesure du processus de décision, seulement si nécessaire. Ensuite, une réponse REP à la requête d'autorisation de délestage est transmise à l'UE. Elle comprend la décision prise. 30 En cas de décision négative, la réponse comprend en E5 au moins une information qui indique cette décision, par exemple un champ « NOK ». 3060930 15 En cas de décision positive, elle comprend en E6 au moins la mesure de latence LAT estimée, une adresse @MC d'un module de traitement de l'équipement serveur apte à exécuter le code délesté par l'UE et une quantité de ressources QRA allouée à la requête de l'utilisateur. On comprend que cette quantité de ressources allouée peut s'exprimer de différentes manières. 5 Elle peut comprendre une quantité de ressources de calcul exprimée par exemple en CPU ou GPU et une quantité de ressources de stockage exprimée en Ko ou Mo. Avantageusement, le message de réponse peut comprendre aussi une adresse @MS d'un module de stockage apte à stocker un résultat d'exécution d'une requête de délestage de code de programme. 10 En E7, le procédé se met en attente d'une requête de délestage de code par l'UE. En E8, une requête de délestage de code DREQ, comprenant au moins l'adresse du module de traitement @MT indiquée par l'équipement serveur dans sa réponse à la requête d'autorisation de délestage de code, une portion de code, ou classe, à exécuter, est reçue en provenance de l'UE. Elle peut aussi comprendre une information relative à un délai de réponse maximal DRM attendu. 15 En E9, la portion de code est exécutée et le résultat de l'exécution est renvoyé dans un message de réponse DREP à l'UE. Avantageusement, l'étape E3 d'estimation d'une mesure de latence est répétée régulièrement par l'équipement serveur ES, par exemple toutes les secondes. On note que plus la mesure est répétée souvent, plus la précision de la latence est grande, mais coûteuse en ressources de transmission et 20 de traitement. Une période de 1 seconde est un bon compromis. Cette mesure LAT estimée est ensuite comparée à la mesure précédente et, si une différence suffisante est détectée, la nouvelle mesure de latence obtenue est transmise à l'équipement terminal UE. De cette manière, l'UE n'a à traiter la réception et la prise en compte d'une nouvelle mesure de latence, que lorsque celle-ci est susceptible d'avoir un impact réel sur sa gestion du 25 délestage de code. En relation avec la Figure 4, on décrit maintenant les étapes d'un procédé de délestage de code mis en oeuvre par un équipement terminal UE connecté à l'équipement d'accès EA. En T1, l'équipement terminal UE émet un message comprenant une requête REQ d'autorisation de 30 délestage de code à destination de l'équipement serveur ES situé à proximité de l'équipement d'accès EA. En T2, il reçoit une réponse en fonction d'une décision prise par l'équipement serveur ES, sous la forme d'un message de réponse REP. Il analyse en T3 la réponse reçue. 3060930 16 En cas de réponse négative, l'UE renonce à délester l'exécution de code de programme auprès de cet équipement serveur. Bien sûr, il pourra réémettre une requête d'autorisation de délestage REQ ultérieurement. En cas de réponse positive, l'UE obtient dans le message REP au moins une mesure de latence LAT 5 estimée par l'équipement serveur ES, une adresse @MT d'un module de traitement apte à exécuter du code délesté par cet UE et une quantité QRA de ressources allouée à l'UE par l'équipement serveur. Il peut aussi obtenir une adresse @MS d'un module de stockage apte à stocker un résultat d'exécution de code délesté. Il déclenche alors la mise en oeuvre d'une étape T4 de partitionnement du code de programme qu'il 10 souhaite au moins en partie délester auprès de l'équipement serveur ES. Cette étape consiste à découper le code de programme à exécuter en une pluralité de portions ou classes, et à modéliser les interactions entre ces classes, par exemple sous la forme d'un graphe comprenant des sommets représentant les classes et des arêtes reliant les classes entre elles en fonction de leurs interactions. 15 On notera que le résultat de l'exécution d'une classe constitue souvent une entrée pour l'exécution d'une autre classe. Il existe plusieurs techniques connues de l'homme de métier pour réaliser une telle partition, telles que par exemple celle décrite par Han et al dans l'article intitulé «A resource aware software partitioning algorithm based on mobility constraints in pervasive grid environments », publié par 20 Elsevier dans la revue Future Generation Computer Systems, vol. 24, Issue 6, en juin 2008, pp. 512-529. Une technique de réduction de graphe est ensuite appliquée, par exemple en formant des groupes (pour « clusters », en anglais) de classes, de façon à optimiser la communication entre les groupes, le temps d'exécution des classes et la consommation de l'UE. 25 En T5, l'UE décide pour quels groupes de classes une opération de délestage doit être mise en oeuvre. Il prend une décision au moins en fonction de la mesure de latence LAT estimée et de la quantité de ressource QRA allouée par l'équipement serveur ES. Il peut bien sûr décider de ne délester aucun groupe. 30 Selon une variante, l'UE met en oeuvre l'étape T4 de partitionnement de code avant d'émettre une requête d'autorisation de délestage en T1. L'information de latence maximale tolérée est alors dérivée de ce partitionnement. 3060930 17 Dans la suite, on suppose que l'équipement terminal UE a décidé de délester l'exécution d'un groupe comprenant C classes Cli' avec C entier non nul et i entier compris entre 0 et C-1. En T6, il émet une requête DREQ de délestage de code à destination de l'équipement serveur ES comprenant au moins une information d'identification Cli, avec i entier compris entre 0 et C-1 des C 5 classes appartenant au groupe et l'adresse @MT du module de traitement chargé d'exécuter ces classes. Deux cas sont envisagés : 1- l'UE a préalablement transmis une copie des classes concernées au module de stockage MS dont il a obtenu @ l'adresse @MS. L'information d'identification permettra au module de 10 traitement MT d'obtenir les portions de code à exécuter ; 2- l'UE n'a pas transmis le code de programmes correspondant à ces classes. Le message DREQ comprend alors les portions de code à exécuter. En T7, il reçoit une réponse DREP comprenant le résultat de l'exécution. Selon un mode de réalisation de l'invention, les échanges de messages entre l'UE et 15 l'équipement serveur ES sont mis en oeuvre dans le cadre d'une session de communication applicative établie, à l'initiative de l'UE, lorsqu'il souhaite requérir une autorisation de délestage de code auprès de l'équipement serveur ES. Cette session de communication est établie lors d'une étape préalable EO, TO des procédés qui viennent d'être décrits en relation avec les Figures 2 et 4 et s'appuie par exemple sur des interfaces de connexion de type « sockets » mettant en oeuvre un 20 protocole de contrôle de communication en mode connecté, par exemple du type TCP (pour « Transmission Control Protocol », en anglais). Cette session met en oeuvre plusieurs messages qui constituent un protocole applicatif spécifiquement adapté à la gestion de délestage de code. On considère en particulier les messages suivants : - un message REQ de requête d'autorisation de délestage de code, émis par l'UE, déjà 25 décrit : - un message REP de réponse à une requête d'autorisation de délestage de code, émis par l'équipement serveur ES, déjà décrit ; - un message DREQ de requête de délestage d'un groupe de classes d'un code, déjà décrit et illustré par la Figure 5A et par la table 1. ; Champs Description Type Type = 1. indique le type de message « Data Request » M=1 signifie que des données résultats d'un message de réponse DREP sont incluses dans ce message. 3060930 18 Reserved mis à 0 à la transmission. Ignoré à la réception Key ID Clé d'identification - utilisée pour séparer les messages de même type Authentication identifie l'UE Record Count nombre de classes incluses dans le message CkassSignature identifie une classe Record TTL spécifie le délai maximal d'exécution de la classe Error flag 0 si aucune erreur, 1 si une erreur est survenue D-Version version des données PrmBlck Count La classe contient une ou plusieurs méthodes. Ce champ représente le nombre de méthodes dans la classe. Data Type format des données (integer, float, String, char, double, Struct, etc.) Datalength spécifie la longueur des données de certains types Data la portion de code constituant la classe Table 1 - un message DREP de réponse à une requête de délestage d'un groupe de classes d'un code, déjà décrit et illustré par la Figure 5B et par la table 2. Champs Description Type Type = 2. indique le type de message « DataReply » P P=1 signifie que la requête est transmise à un autre équipement serveur pour qu'il l'exécute, par exemple en cas de mobilité. S S=1 signifie que le message de réponse comprend un message de requête. Reserved mis à 0 à la transmission. Ignoré à la réception Key ID clé d'identification. Sert à séparer des requêtes de même type Authentication identifie l'UE Record Count nombre de classes incluses dans le message CkassSignature identifie la classe Record TTL spécifie le délai de traitement maximal de la requête Error flag 0 si aucune erreur, 1 si une erreur est survenue D-Version version des données PrmBlck Count Nombre de méthodes dans une classe Data Type format des données (integer, float, String, char, double, Struct, etc.) Datalength format des résultats Data données constituant le résultat de l'exécution Table 2 5 un message DREG de requête d'enregistrement de données de réponse à une requête de délestage d'un groupe de classes dans une mémoire partagée MS et illustré par la Figure 5C et par la table 3 ; Champs Description Type Type = 3. indique le type de message « DataRegister » P P=1 signifie que l'UE a changé d'équipement d'accès et donc d'équipement serveur. Il s'agit d'enregistrer les données du module de stockage MS dans un autre module de stockage MS' associé au nouvel équipement serveur. N Lorsqu'il est mis à 1, le module de stockage MS notifie le requérant après avoir enregistré de nouvelles données. Reserved mis à 0 à la transmission. Ignoré à la réception Key ID clé d'identification. Sert à séparer des requêtes de même type Authentication identifie l'UE Record Count nombre de classes ClassSignature identifie une classe 3060930 19 Record TTL spécifie le délai de traitement maximal d'exécution de la classe Error flag 0 si aucune erreur, 1 si une erreur est survenue D-Version version des données PrmBlck Count Nombre de méthodes dans une classe Data Type format des données (integer, float, String, char, double, Struct, etc.) Datalength format des résultats Data données constituant le résultat de l'exécution de la classe Table 3 - un message de notification de mise à jour des données enregistrées dans une mémoire partagée MS et illustré par la Figure 5D et par la table 4. Champs Description Type Type = 4. indique le type de message « Data Notify » Reserved mis à 0 à la transmission. Ignoré à la réception Key ID clé d'identification. Sert à séparer des requêtes de même type Authentication identifie l'UE Record Count nombre de classes ClassSignature identifie une classe Record TTL spécifie le délai de traitement maximal d'exécution de la classe Error flag 0 si aucune erreur, 1 si une erreur est survenue D-Version version des données PrmBlck Count Nombre de méthodes dans une classe Data Type format des données (integer, float, String, char, double, Struct, etc.) Datalenght format des résultats Data données constituant le résultat de l'exécution de la classe Table 4 5 En relation avec la Figure 6, on décrit à titre d'exemple une séquence de messages échangés sur la base de ce protocole entre l'équipement terminal UE, l'équipement serveur ES et un module de stockage MS, qui peut être intégré dans l'équipement serveur ou bien distant, mais situé à proximité et connecté à ce dernier par un lien haut débit. L'équipement terminal UE émet à destination de l'équipement serveur ES une requête 10 d'autorisation de délestage de code REQ. Il indique le type de code de programme concerné TC et la quantité de ressources dont il a besoin QR. Il obtient en retour une réponse REP comprenant la décision prise par l'équipement serveur ES. En cas de réponse positive, elle comprend au moins une mesure de latence LAT estimée par le serveur, une quantité de ressources allouée QRA par le serveur au délestage de code de cet UE, 15 l'adresse @MT d'un module de traitement MT de l'équipement serveur apte à exécuter du code pour cet UE et l'adresse @MS d'un module de stockage MS apte à stocker la portion de code à exécuter ou le résultat de l'exécution de ce code. 3060930 20 On suppose que l'UE a décidé, à partir des informations reçues de l'ES de délester au moins une classe Cl; d'un code de programme. Il émet une requête de délestage DREQ à destination du module de traitement MT de l'équipement serveur ES. Avantageusement, cette requête est en premier lieu destinée au module de stockage MS, qui, sur 5 réception de cette requête, est agencé pour vérifier que les résultats d'exécution requis n'ont pas déjà été enregistrés. On suppose que ce n'est pas le cas. La requête est donc transmise au module de traitement MT de l'équipement serveur, qui a été réservé pour l'UE. A réception de ce message, le module MT exécute la classe Cl; de code. Il émet une réponse DREP 10 à l'UE comprenant le résultat de l'exécution. Il émet en outre une requête DREG d'enregistrement des données résultat au module de stockage. Une fois les données résultat enregistrées, le module de stockage émet une requête de notification DNOTIF à destination de l'UE et du module de traitement pour les informer que de nouvelles données ont été enregistrées dans le module de stockage MS. 15 La figure 7A présente la structure simplifiée d'un dispositif 100 adapté pour mettre en oeuvre le procédé de traitement d'une requête d'autorisation de délestage de codage selon l'un quelconque des modes particuliers de réalisation de l'invention qui viennent d'être décrits. Le dispositif 100 est notamment configuré pour: - recevoir une requête d'autorisation de délestage de codage en provenance d'un 20 équipement terminal ; - estimer une mesure de latence sur le lien radio au moins à partir de paramètres radio fournis par l'équipement d'accès; - décider d'autoriser ou non le délestage de code en provenance dudit équipement terminal par le serveur au moins en fonction de la mesure de latence estimée ; 25 - en cas de décision positive, transmettre à l'équipement client une réponse comprenant au moins la mesure de latence estimée et une adresse IP d'un module de calcul dudit équipement serveur, apte à exécuter le code délesté par ledit équipement terminal. Selon un mode particulier de réalisation de l'invention, les étapes du procédé de traitement 30 d'une requête d'autorisation de délestage sont mises en oeuvre par des instructions de programme 3060930 21 d'ordinateur. Pour cela, le dispositif 100 a l'architecture classique d'un ordinateur et comprend notamment une mémoire MEM, une unité de traitement UT1, équipée par exemple d'un microprocesseur pl, et pilotée par le programme d'ordinateur Pgl stocké en mémoire MEM1. Le programme d'ordinateur Pgl comprend des instructions pour mettre en oeuvre les étapes du 5 procédé de traitement tel que décrit ci-dessus, lorsque le programme est exécuté par le microprocesseur pl. A l'initialisation, les instructions de code du programme d'ordinateur Pgl sont par exemple chargées dans une mémoire RAM avant d'être exécutées par le microprocesseur pl de l'unité de traitement UT1. 10 Selon un autre mode particulier de réalisation de l'invention, le procédé d'authentification est mis en oeuvre par des modules ou unités fonctionnel(le)s. Pour cela, le dispositif 100 comprend en outre les modules suivants: - réception REC. REQ d'une requête d'autorisation de délestage de code en provenance d'un équipement terminal ; 15 - estimation EST. LAT d'une mesure de latence sur le lien radio au moins à partir de paramètres radio fournis par l'équipement d'accès; - prise de décision DEC. relative à une autorisation de délestage de code en provenance dudit équipement terminal par le serveur au moins en fonction de la mesure de latence estimée ; 20 - en cas de décision positive, transmission ENV REP à l'équipement terminal d'une réponse comprenant au moins la mesure de latence estimée et une adresse IP d'un module de traitement dudit équipement serveur, apte à exécuter le code délesté par ledit équipement terminal. De façon avantageuse, un tel dispositif 100 stocke dans la première mémoire Ml, la décision 25 prise, la mesure de latence estimée et la quantité de ressources allouée à l'équipement terminal. Avantageusement, suite à une décision positive, le dispositif 100 est agencé pour recevoir et traiter une requête de délestage de code émise par l'équipement terminal et à lui envoyer une réponse comprenant un résultat d'exécution du code délesté. Avantageusement, le dispositif 100 peut être intégré à un équipement serveur ES. 30 Le dispositif 100 est alors agencé pour coopérer au moins avec les modules suivants du serveur ES : 3060930 22 - au moins un module de traitement MT apte à exécuter une portion de code de programme délestée par l'équipement terminal UE ; - au moins un module de stockage MS apte à stocker la portion de code et/ou le résultat de l'exécution de cette portion de code. ; et 5 - un module E/R d'émission/réception de données, permettant l'échange de données avec l'équipement terminal via le réseau de télécommunications mobiles RM et l'équipement d'accès UA. La figure 8B présente la structure simplifiée d'un dispositif 200 adapté pour mettre en oeuvre le 10 procédé de de délestage de code selon l'un quelconque des modes particuliers de réalisation de l'invention qui viennent d'être décrits. Le dispositif 200 est notamment configuré pour: - émettre une requête d'autorisation de délestage de code à destination de l'équipement serveur ; - sur réception d'une réponse comprenant au moins une mesure de latence estimée sur 15 le lien radio et une adresse IP d'un module de calcul dudit équipement serveur apte à exécuter au moins une portion de code pour ledit équipement terminal, prendre une décision relative au délestage d'une portion de code par le module de traitement MT au moins à partir de la mesure de latence reçue. 20 Selon un mode particulier de réalisation de l'invention, les étapes du procédé de délestage sont mises en oeuvre par des instructions de programme d'ordinateur. Pour cela, le dispositif 200 a l'architecture classique d'un ordinateur et comprend notamment une mémoire MEM2, une unité de traitement UT2, équipée par exemple d'un microprocesseur p2, et pilotée par le programme d'ordinateur Pg2 stocké en mémoire MEM2. Le programme d'ordinateur Pg2 comprend des 25 instructions pour mettre en oeuvre les étapes du procédé de délestage tel que décrit ci-dessus, lorsque le programme est exécuté par le microprocesseur p2. A l'initialisation, les instructions de code du programme d'ordinateur Pg2 sont par exemple chargées dans une mémoire RAM avant d'être exécutées par le microprocesseur p2 de l'unité de traitement UT2. 3060930 23 Selon un autre mode particulier de réalisation de l'invention, le procédé de délestage est mis en oeuvre par des modules ou unités fonctionnel(le)s. Pour cela, le dispositif 200 comprend en outre les modules suivants: - émission ENV. REQ d'une requête d'autorisation de délestage de code à destination de 5 l'équipement serveur ; - sur réception REC. REP d'une réponse comprenant au moins une mesure de latence estimée sur le lien radio et une adresse d'un module de traitement dudit équipement serveur apte à exécuter au moins une portion de code pour ledit équipement terminal, prise de décision DEC. relative au délestage de code par le module de calcul au moins à 10 partir de la mesure de latence reçue. De façon avantageuse, un tel dispositif 200 stocke dans la deuxième mémoire M2, la décision prise, la mesure de latence estimée et la portion de code à délester. Avantageusement, sur réception d'une décision positive, il envoie à l'aide d'un module ENV. DREQ une requête de délestage de code à destination du module de traitement et reçoit une 15 réponse à l'aide d'un module REC. DREP comprenant le résultat de l'exécution du code. Le dispositif 200 peut être intégré à un équipement terminal UE. Le dispositif 200 est alors agencé pour coopérer au moins avec les modules suivants de l'équipement terminal UE : - un module E/R d'émission/réception de données, permettant l'échange de données avec 20 l'équipement serveur ES via le réseau de télécommunications mobiles RM et l'équipement d'accès EA. Les différents modules fonctionnels décrits ci-dessus peuvent être sous forme matérielle et/ou logicielle. Sous une forme logicielle, un tel module fonctionnel peut comprendre un processeur, une 25 mémoire et des instructions de code de programme pour mettre en oeuvre la fonction correspondante au module lorsque les instructions de code sont exécutées par un le processeur. Sous une forme matérielle, un tel module fonctionnel peut mis en oeuvre par tout type de circuits d'encodage adaptés, tels que par exemple et de manière non limitative des microprocesseurs, des processeurs de traitement du signal (DSP pour Digital Signal Processor en anglais), des circuits 30 intégrés spécifiques à des applications (ASICs pour Application Specific Integrated Circuit en 3060930 24 anglais), des circuits FPGA pour Field Programmable Gate Arrays en anglais, un câblage d'unités logiques. Il va de soi que les modes de réalisation qui ont été décrits ci-dessus ont été donnés à titre purement indicatif et nullement limitatif, et que de nombreuses modifications peuvent être 5 facilement apportées par l'homme de l'art sans pour autant sortir du cadre de l'invention. REVENDICATIONS1. Procédé de traitement d'une requête (REQ) d'autorisation de délestage de code de programme, en provenance d'un équipement terminal (UE) et reçue par un équipement serveur (ES) , intégré à ou connecté par un lien haut débit à un équipement d'accès (EA) à un réseau de télécommunications (RM), ledit équipement terminal étant connecté audit équipement d'accès au réseau par un lien radio, ledit équipement serveur comprenant au moins un module de traitement (MT) dédié à l'exécution de code délesté, caractérisé en ce que ledit procédé comprend les étapes suivantes : obtention (E2) de paramètres radio fournis par l'équipement d'accès ; - estimation (E3) d'au moins une mesure de latence (LAT) sur le lien radio au moins à partir des paramètres obtenus; - prise de décision (E5) relative à une autorisation de délestage de code en provenance dudit équipement terminal par le serveur en fonction de la au moins une mesure de latence estimée ; - en cas de décision positive, transmission (E7) à l'équipement client d'une réponse comprenant au moins la mesure de latence estimée et une adresse IP du module de traitement. 2. Procédé de traitement selon la revendication 1, caractérisé en ce que, suite à une décision positive, l'étape (E3) d'estimation d'une mesure de latence est répétée à intervalles réguliers de sorte à obtenir une mesure de latence mise à jour, en ce que la mesure de latence mise à jour est comparée à la mesure de latence précédente et en ce que, lorsqu'une différence entre les deux mesures successives est supérieure à un seuil prédéterminé, elle est transmise à l'équipement terminal. 3. Procédé de traitement selon l'une des revendications 1 ou 2 caractérisé en ce que, la requête d'autorisation de délestage (REQ) comprenant une information (LMT) relative à une latence maximale tolérée par le code de programme à délester, l'étape de prise de décision (E5) compare l'information de latence estimée à la latence maximale tolérée et décide d'autoriser le délestage de code lorsque la latence estimée est inférieure à la latence maximale tolérée. 3060930 26 4. Procédé de traitement selon l'une des revendications 1 à 3 caractérisé en ce que, la requête comprenant une information relative à une quantité de ressources requise (QR), le procédé comprend en outre une étape (E4) d'obtention d'une information relative à une quantité de ressources disponible (QRD) dans l'équipement serveur, en ce que la prise de 5 décision est en outre fonction de la quantité de ressources requise et de la quantité de ressources disponible et en ce que, la réponse comprend une information relative à une quantité de ressources allouée (QRA) à l'équipement terminal. 5. Procédé de traitement selon l'une des revendications précédentes, caractérisé en ce que des informations d'accès de l'équipement terminal au lien radio montant ayant été 10 obtenues, lesdites informations comprenant un nombre d'intervalles d'émission alloué par l'équipement d'accès à l'équipement terminal pendant une période temporelle prédéterminée, l'étape (E3) d'estimation d'une mesure de latence comprend une sous-étape (E33) de calcul d'un temps d'aller-retour entre l'équipement d'accès et l'équipement terminal en fonction d'un rapport entre un nombre total d'intervalles d'émission dans la 15 période et le nombre alloué à l'équipement terminal. 6.. Procédé de délestage de code par un équipement terminal (UE) connecté à un équipement d'accès (EA) à un réseau de télécommunications (RM) par un lien radio, vers un équipement serveur (ES) intégré à ou connecté par un lien haut débit audit équipement d'accès, caractérisé en ce qu'il comprend les étapes suivantes : 20 - émission (Ti.) d'une requête d'autorisation de délestage de code à destination de l'équipement serveur ; - sur réception (T2) d'une réponse comprenant au moins une mesure de latence estimée sur le lien radio et une adresse (@MT) d'un module de calcul dudit équipement serveur apte à exécuter au moins une portion de code pour ledit équipement terminal, prise de 25 décision (T5) relative au délestage d'une portion de code par le module de calcul au moins à partir de la mesure de latence (LAT) reçue. 7. Procédé de délestage de code selon la revendication 6, caractérisé en ce que la prise de décision prend en compte une information relative à une quantité de ressources allouée (QRA) par le serveur. 3060930 27 8. Procédé de délestage de codage selon l'une des revendications 6 ou 7, caractérisé en ce que, le code étant divisé en une pluralité de portions de code, dites classes, le procédé comprend une étape de partitionnement (T4) de la pluralité de classes en au moins deux groupes et en ce que l'étape (T5) de prise de décision décide, pour un groupe de classes, 5 s'il doit être délesté, au moins en fonction de la mesure de latence (LAT) estimée, et en ce que, suite à une décision de délestage d'un groupe de classes, le procédé comprend l'émission (T6) d'un message de requête d'exécution de code à destination de l'équipement serveur, ladite requête comprenant au moins une information relative à un nombre de classes à exécuter et une information relative à un délai de réponse attendu. 10 9. Procédé selon l'une des revendications précédentes, caractérisé en ce qu'il comprend une étape (E0, T0) préalable d'établissement d'une session de communication applicative entre l'équipement terminal et l'équipement serveur, selon un protocole de communication comprenant au moins un message appartenant au groupe comprenant : - un message (REQ) de requête d'autorisation de délestage de code 15 - un message (REP) de réponse à une requête d'autorisation de délestage de code ; - un message (DREQ) de requête de délestage d'un groupe de classes d'un code ; - un message (DREP) de réponse à une requête de délestage d'un groupe de classes ; - un message (DREG) de requête d'enregistrement de données de réponse à une requête de délestage d'un groupe de classes dans une mémoire partagée ; et 20 - un message (DNOTIF) de notification de mise à jour des données enregistrées dans une mémoire partagée. 10. Dispositif (100) de traitement d'une requête d'autorisation de délestage de code en provenance d'un équipement terminal et reçue par un équipement serveur intégré ou connecté par un lien haut débit à un équipement d'accès à un réseau de 25 télécommunications mobile, ledit équipement terminal étant connecté audit équipement d'accès au réseau par un lien radio, ledit équipement serveur comprenant au moins un module de traitement dédié à l'exécution de code délesté, caractérisé en ce que ledit dispositif comprend une machine de calcul dédiée à ou configurée pour : - estimer une mesure de latence sur le lien radio au moins à partir de paramètres radio fournis par l'équipement d'accès; 3060930 28 - décider d'autoriser ou non un délestage d'au moins une portion de code en provenance dudit équipement terminal par le serveur au moins en fonction de la mesure de latence estimée ; - en cas de décision positive, transmettre à l'équipement client une réponse comprenant 5 au moins la mesure de latence estimée et une adresse IP du module de traitement. 11. Equipement serveur (ES) intégré ou connecté par un lien haut débit à un équipement d'accès à un réseau de communications mobiles, caractérisé en ce qu'il comprend au moins un module de traitement (MT) apte à exécuter au moins une portion de code délestée par un équipement terminal connecté à l'équipement d'accès et un dispositif (100) de 10 traitement selon la revendication 9. 12. Dispositif (200) de délestage de code par un équipement terminal (UE) connecté à un équipement d'accès (EA) à un réseau de télécommunications (RM) par un lien radio, vers un équipement serveur connecté audit équipement d'accès, caractérisé en ce qu'il comprend une machine de calcul dédiée à ou configurée pour : 15 - émettre une requête d'autorisation de délestage de code à destination de l'équipement serveur ; - sur réception d'une réponse comprenant au moins une mesure de latence estimée sur le lien radio et une adresse IP d'un module de traitement dudit équipement serveur apte à exécuter au moins une portion de code pour ledit équipement terminal, décider 20 de délester ou non l'exécution d'une portion de code par le module de traitement au moins à partir de la mesure de latence reçue. 13. Equipement terminal (UE) apte à se connecter à un équipement d'accès à un réseau de communications mobiles, caractérisé en ce qu'il comprend un dispositif (200) de délestage de code selon la revendication 11. 25 14. Programme d'ordinateur (Pg1, Pg2) comportant des instructions pour la mise en oeuvre du procédé selon l'une quelconque des revendications 1 à 9, lorsque ledit programme est exécuté par un processeur.