FR 3157769 A1 20250627 FR 2314763 A 20231221 L’invention se rapporte à un procédé de gestion d’un service par un serveur d’application (AS), ledit procédé comprenant une étape de transmission à un dispositif de communication (UE) d’un jeton (amigos_token) généré pour ledit dispositif de communication et un accès donné à un service via au moins un réseau (Network), ledit jeton (amigos_token) étant associé à un niveau de service (service_level) sélectionné pour cet accès audit service, ledit jeton (amigos_token) étant apte à déclencher, lorsqu’il est contenu dans un paquet de données (Data) relatif audit service échangé via ledit au moins un réseau (Network), un traitement de ce paquet de données (Data) correspondant audit niveau de service (service_level) par au moins une entité (AN, BR) dite de traitement dudit au moins un réseau (Network). Figure pour l’abrégé : Fig.4 Procédé d’accès à un service par un dispositif de communication via au moins un réseau de communication La présente invention se rapporte au domaine des télécommunications, et plus particulièrement de celui de services IP à valeur ajoutée. Art Antérieur La FIG. 1 illustre une architecture simplifiée de l’ensemble des entités impliquées lors de la fourniture d’un service IP. Ces entités comprennent un dispositif de communication, tel qu’un terminal ou un équipement utilisateur (ou UE pour « User Equipment » en anglais), au moins un serveur applicatif, également appelé serveur d’application (ou encore AS pour « Application Server » en anglais) et au moins un réseau de communication « Network » disposé entre le dispositif de communication et le au moins un serveur applicatif. Le dispositif de communication embarque différents applicatifs APP#1, APP#2, …, APP#n (ou applications) associés à différents services et un système d’exploitation OS (« Operating System », en anglais) disposé entre ces différents applicatifs et le réseau. Par « le dispositif de communication embarque un applicatif », on entend que le dispositif de communication comprend généralement le côté client d’une application, c’est-à-dire un logiciel adapté pour afficher, par exemple, une interface graphique associée à l’application dans l’environnement du dispositif de communication. Cependant, l’applicatif peut aussi comprendre une fonction « serveur ». Un ou plusieurs serveurs d’applicatifs sont sollicités par les applicatifs APP#1, APP#2, …, APP#n embarqués dans le dispositif de communication pour délivrer différents services Service#1, Service#2, …, Service#n, tels qu’un service de jeux (ou « gaming » en anglais), un service de diffusion de contenus (ou « streaming » en anglais), ou un service de conférence. Les applicatifs APP présents dans ce dispositif de communication permettent d’accéder aux services (ou applications) offerts par un serveur applicatif depuis ledit dispositif de communication. Ces applicatifs APP peuvent solliciter des traitements ou fonctions spécifiques via une API (pour « Application Programming Interface » en anglais) exposée par le système d’exploitation OS du dispositif de communication. L’accès à certaines fonctions du dispositif de communication peut toutefois être limité par l’API de l’OS. Par exemple, un applicatif de socket réseau peut être limité à la recherche de points d’accès WLAN (« Wireless Local Area Network », en anglais) pour une connexion d’un dispositif de communication au réseau ou interdire les communications IPv6. En plus de l’API de l’OS, le réseau expose également des API pour que des services « externes » qui reposent sur les ressources du réseau puissent invoquer une procédure de traitement de trafic différenciée pour des paquets de données associés à ces services. L’acheminement des trafics spécifiques à un service (fourni par un ou plusieurs serveurs applicatifs) peut donc faire l’objet de politiques d’acheminement de trafic différenciées (dites « differenciated traffic forwarding policies » en anglais). Le déploiement des infrastructures mobiles a remis au goût du jour le concept de « slice » (c’est-à-dire « tranche » en français). Une tranche réseau peut être définie comme une partition réseau telle qu’un réseau privé virtuel (RPV ou VPN pour « Virtual Private Network » en anglais) déployé sur une infrastructure fixe ou mobile. Les caractéristiques d’une tranche réseau sont typiquement exprimées en termes de capacité (bande passante) et de qualité de service (par ex. latence, temps de transit unidirectionnel, etc.) voire de sécurité (par exemple la préservation de la confidentialité des informations transmises au sein du RPV moyennant l’utilisation des techniques de chiffrement). Le document de A. Farrel et al. intitulé « A framework for Network Slices in Networks Built from IETF Technologies », septembre 2023, apporte des détails complémentaires sur les caractéristiques d’une tranche réseau. L’architecture de référence de la FIG. 2 illustre principalement des services dits « externes », (c’est-à-dire les services proposés par un fournisseur distinct de celui qui gère le réseau « Network# »). Comme l’illustre cette FIG. 2 , un dispositif de communication peut souscrire à des services différenciés qui peuvent être proposés par un serveur applicatif ou AS, un fournisseur de service, etc. Un AS exploite une collection d’instances de service impliquées dans la fourniture du service exposé par l’AS. L’invocation de l’une ou de l’autre des instances peut être conditionnée par différents paramètres, tels que la localisation du dispositif de communication, la charge de chacune des instances, etc. La logique décisionnelle de chaque AS lui est spécifique. Ainsi, aucune hypothèse n’est faite quant au nombre et au chaînage de ces différentes instances, leur exposition aux terminaux, le périmètre fonctionnel de chaque instance, etc. Le trafic susceptible d’être acheminé via une tranche réseau doit faire l’objet d’une habilitation. Une telle habilitation repose typiquement sur des règles de classification de trafic qui sont en général appliquées à « l’entrée » d’un réseau qui offre des tranches réseau. Dans le cas d’une tranche réseau, ce point d’entrée peut être situé à l’interface de raccordement de la « packet gateway » (ou passerelle paquets) au réseau Internet. Dans ce cas, la fonction de classification peut être localisée à cette interface. Le point d’entrée peut également se situer à l’interface de raccordement d’un dispositif de communication au réseau d’accès radio (ou RAN, pour « Radio Access Network ») de façon notamment à optimiser l’usage des ressources radio en fonction du type de la tranche réseau et du profil du trafic qu’elle est susceptible d’acheminer. Les règles de classification et de contrôle d’admission sont appliquées à la périphérie du réseau. Cependant, aucune hypothèse limitative n’est faite quant aux nœuds du réseau configurés avec les règles de classification. L’organisme 3GPP a défini plusieurs types de tranches réseau, par exemple eMBB « enhanced Mobile BroadBand (pour service mobile large bande amélioré en français), mIoT (pour « massive Internet of Things » en anglais ou déploiement massif de l’Internet des Objets en français) et URLLC pour « Ultra Reliable Low Latency Communications » en anglais ou communication ultra fiable et à faible latence en français. Chacun de ces types est associé à un ensemble de caractéristiques documentées par le 3GPP. Le choix de concevoir et de déployer l’un ou l’autre de ces types de tranche est conditionné par la nature du trafic caractéristique des applications ou services utilisé(e)s ou souscrit(e)s par l’utilisateur. Par exemple, un service dit « immersif » qui exploite des techniques de réalité augmentée ou virtuelle est généralement très exigeant en termes de latence et de fiabilité des échanges de données. Le service immersif est donc un client « naturel » d’une tranche de type URLLC. En outre, les règles de classification de trafic peuvent être extrêmement complexes car l’une des revendications majeures du 3GPP est le niveau de granularité associé à l’ingénierie et au déploiement d’une tranche. Ce niveau peut être macroscopique (par exemple, une tranche déployée pour acheminer le trafic à destination de l’Internet) mais également microscopique (par exemple le trafic applicatif échangé entre deux terminaux mobiles et pour lequel une tranche dédiée a été déployée). Cette granularité génère donc une complexité globale de l’ingénierie des tranches supportée par l’infrastructure mobile (difficulté à optimiser l’usage des ressources mises en œuvre par une tranche, par un ensemble de tranches, par toutes les tranches, difficulté à garantir strictement l’isolation du trafic acheminé au sein d’une tranche, difficulté à garantir strictement le niveau de qualité ou de sécurité associés à une tranche, voire les niveaux de disponibilité et de résilience d’une tranche donnée, etc.). En particulier, la complexité de l’édiction et de l’application de règles de classification de trafic associées à la mise en place d’une tranche donnée évolue avec la diversité des trafics, la richesse de l’organisation de la structure qui exploite la tranche (par exemple : un service de comptabilité, un service de R&D ou un service de production) ou encore le mode d’usage de la tranche (par exemple une gestion des surcharges de trafic lors des heures chargées avec des principes de répartition de la charge de trafic). Cette complexité est notamment aggravée par l’évolution des règles de classification de trafic au cours du temps, parfois à une fréquence élevée (par exemple dans le contexte du déploiement d’une tranche pour la retransmission d’un évènement sportif ou culturel, les règles de classification de trafic peuvent évoluer avec le nombre et le profil des utilisateurs de la tranche). La configuration de telles règles est donc elle aussi complexe et le risque d’erreur lors du processus de configuration de ces règles n’est pas nul. Il existe donc un besoin d’améliorer la mise en œuvre des politiques d’acheminement de trafic différenciées dans un réseau de communication en vue d’optimiser la fourniture et l’accès à des applications pour un dispositif de communication connecté audit réseau. Un objet de l’invention concerne un procédé de gestion d’un service par un serveur d’application, ledit procédé comprenant une étape de transmission à un dispositif de communication d’un jeton généré pour ledit dispositif de communication et un accès donné à un service via au moins un réseau, ledit jeton étant associé à un niveau de service sélectionné pour cet accès audit service, ledit jeton étant apte à déclencher, lorsqu’il est contenu dans un paquet de données relatif audit service échangé via ledit au moins un réseau, un traitement de ce paquet de données correspondant audit niveau de service par au moins une entité dite de traitement dudit au moins un réseau. L’invention propose un mécanisme collaboratif entre un dispositif de communication, un serveur d’application et un réseau permettant d’optimiser la fourniture de l’accès au service par le dispositif de communication via ce réseau., Ce mécanisme permet de gérer à la demande le traitement différencié par le réseau de paquets de données envoyés vers ou par un serveur d’application. On optimise ainsi la gestion des connexions d’un dispositif de communication au réseau de communication et on s’affranchit de certaines limitations imposées par le système d’exploitation (OS) du dispositif de communication. Le jeton utilisé pour déclencher un tel traitement est un jeton dynamique sélectionné par communication, c’est-à-dire pour un accès donné à un service par le dispositif de communication, et spécifique à ce dispositif de communication. Ce jeton n’est pas utilisé pour des agrégats. Il se distingue ainsi d’un marquage d’usage reposant sur un codage DSCP (pour « DiffServ Code Point » en anglais décrit par la norme RFC4594), ou l’utilisation du champ Flow Label d’un entête de paquet IPv6 (RFC6437), etc. Il offre ainsi une plus grande granularité concernant les politiques de traitement différenciées pouvant être mises en œuvre, et permet notamment la mise en œuvre de traitements différenciés personnalisés. Le serveur d’application peut comprendre plusieurs instances de service. Les étapes du procédé de gestion peuvent être mises en œuvre par une même instance de service ou par des instances de service différentes. Dans une variante de réalisation, le procédé de gestion comprend en outre une étape de fourniture d’au moins une information de vérification à une entité dite relais dudit au moins un réseau permettant à ladite entité relais de vérifier que ledit dispositif de communication est autorisé à accéder audit service en utilisant ledit jeton. On améliore ainsi la sécurité globale du procédé de gestion. Dans une variante de réalisation, la au moins une information de vérification comprend : - ledit jeton et un identifiant dudit dispositif de communication alloué par le serveur d’application ; ou - une confirmation que ledit dispositif de communication est autorisé à accéder audit service en utilisant ledit jeton. Ceci permet à l’entité relais ou au serveur d’application de procéder à la vérification. Dans le cas d’une vérification par le serveur d’application, l’entité relais lui fournit un identifiant du dispositif de communication et le jeton. Ce jeton a été fourni par le dispositif de communication à l’entité relais dans un message d’annonce. L’allocation par le serveur d’application d’un identifiant au dispositif de communication et l’utilisation de cet identifiant dans les procédures mises en œuvre avec le réseau permettent de masquer l’identité du dispositif de communication lorsqu’il accède au service via le réseau. On évite ainsi de stocker des informations pouvant porter atteinte à la vie privée de l’utilisateur du dispositif de communication. Dans une variante de réalisation, l’étape de transmission comprend en outre la transmission d’une indication représentative d’un canal véhiculé par le paquet de données dans lequel ledit jeton doit être contenu pour déclencher ledit traitement. Un tel canal permet d’insérer des métadonnées utiles pour mettre en œuvre l’invention, et notamment le jeton déclenchant le traitement des paquets de données par les entités de traitement du réseau en fonction du niveau de service associé au jeton. Ce canal peut être négocié préalablement avec le réseau. En variante, le jeton peut être inclus dans un champ dédié normalisé. L’une ou l’autre de ces variantes permet de s’assurer que les entités de traitement du réseau interceptant les paquets de données relatifs au service sont bien en mesure de détecter le jeton inclus le cas échéant dans ces paquets de données et d’appliquer le traitement correspondant au niveau de service associé à ce jeton. Dans une variante de réalisation, l’étape de transmission comprend en outre la transmission d’au moins un élément parmi : - un identifiant de service connu dudit au moins un réseau ; - un identifiant sélectionné par ledit serveur d’application pour ledit dispositif de communication ; et - une information représentative dudit niveau de service. On améliore ainsi le traitement par le réseau des paquets de données échangés entre le dispositif de communication et le serveur d’application. Dans une variante de réalisation, le procédé de gestion comprend une étape d’envoi d’au moins un paquet de données relatif audit service audit dispositif de communication contenant ledit au moins un jeton. Le jeton déclenchant un traitement par le réseau en fonction du niveau de service déterminé pour l’accès au service peut être ainsi inséré dans les paquets de données soit par le dispositif de communication soit par le serveur d’application. On s’assure ainsi qu’un traitement différencié correspondant au niveau de service souhaité est appliqué aux paquets de données émis et/ou reçu par le dispositif de communication. Dans une variante de réalisation, le procédé de gestion comprend : - une étape de désactivation dudit jeton ; et - une étape de notification à au moins une entité dudit réseau de ladite désactivation. L’entité du réseau notifiée peut être une entité de traitement impliquée dans le traitement des paquets de données selon le niveau de service associé au jeton ou un contrôleur réseau apte à configurer une telle entité de traitement. Cette variante de réalisation permet de mettre fin au traitement différencié appliqué par les entités de traitement du réseau en fonction du niveau de service associé au jeton. Un autre objet de l’invention concerne un procédé d’accès, par un dispositif de communication, à un service via au moins un réseau, ledit procédé comprenant : - une étape de réception en provenance d’un serveur d’application associé audit service d’un jeton généré pour ledit dispositif de communication et un accès donné audit service, ledit jeton étant associé à un niveau de service sélectionné pour cet accès audit service, ledit jeton étant apte à déclencher, lorsqu’il est contenu dans un paquet de données relatif audit service échangé via ledit au moins un réseau, un traitement de ce paquet de données correspondant audit niveau de service par au moins une entité dite de traitement dudit au moins un réseau ; et - une étape d’envoi à une entité dite relais dudit au moins un réseau, d’un message d’annonce d’une utilisation dudit jeton par le dispositif de communication lors dudit accès au service, ledit message d’annonce contenant ledit jeton. Ainsi, il est possible de gérer à la demande le traitement différencié de certains paquets de données envoyés vers ou par un serveur applicatif. On optimise ainsi la gestion des connexions d’un dispositif de communication via un réseau de communication et on s’affranchit de certaines limitations imposées par le système d’exploitation du dispositif de communication. Le message d’annonce vise le déclenchement de la configuration par l’entité relais des entités du réseau impliquées dans le traitement différencié des paquets de données, pour que le jeton inséré dans les paquets de données puisse être dûment interprété et déclencher le traitement escompté. Dans une variante de réalisation, suite à une réception d’une confirmation de l’entité relais de ladite utilisation, une étape d’insertion du jeton dans au moins un paquet de données relatif audit service émis par le dispositif de communication lors dudit accès donné au service. Ce jeton permet un traitement différencié du paquet de données dans le réseau car il permet d’identifier les paquets concernés et de déclencher ainsi le traitement associé. La classification des paquets d’une même communication peut se baser exclusivement sur le jeton ou sur un « condensé » (hash, en anglais) d’un paquet contenant ledit jeton. Ledit condensé est calculé par un routeur qui le garde dans une mémoire. Le routeur appliquera le traitement différencié sur tous les paquets dont le condensé est égal à un condensé présent dans la mémoire. Un autre objet de l’invention concerne un procédé de configuration par une entité dite relais d’un réseau, ledit procédé comprenant : - une étape de réception, en provenance d’un dispositif de communication, d’un message d’annonce d’une utilisation par le dispositif de communication lors d’un accès donné au service via ledit réseau d’un jeton contenu dans ledit message d’annonce, ledit jeton ayant été généré pour ledit dispositif de communication et ledit accès au service, et étant associé à un niveau de service sélectionné pour ledit accès au service ; et - si le dispositif de communication est autorisé à accéder au service, une étape de configuration d’au moins une entité dite de traitement du réseau pour que ladite entité de traitement mette en œuvre un traitement correspondant audit niveau de service associé audit jeton lorsque cette entité de traitement intercepte un paquet de données relatif au service contenant ledit jeton. La configuration de l’entité de traitement du réseau peut être effectuée selon les instructions d’un contrôleur ou localement à l’entité par un ensemble de commandes déclaratives, notamment si le relais se trouve dans ladite entité de traitement. L’entité de traitement est typiquement placée à la périphérie du réseau et se charge d’appliquer des règles de classification de trafic. En variante, cette entité de traitement est une entité intermédiaire du réseau d’accès gérant l’accès aux ressources filaires ou radio, par exemple. Une ou plusieurs entités de traitement peuvent être sollicitées lors de l’acheminement d’un même paquet de données. Les informations nécessaires au déclenchement du traitement différencié sont préservées dans le paquet de données. Dans une variante de réalisation, le message d’annonce comprend en outre un identifiant de service connu dudit au moins un réseau, ledit identifiant de service étant utilisé par l’entité relais pour solliciter ledit serveur d’application pour déterminer si le dispositif de communication est autorisé à accéder au service. Cet identifiant de service peut être généré par le réseau pendant une phase de négociation initiale avec la plateforme de service/serveur d’application. L’affectation d’un tel identifiant par le réseau permet de garantir son unicité à l’échelle du réseau. En variante, l’identifiant de service est généré par le serveur d’application. Dans une variante de réalisation, l’étape de configuration comprend la transmission à ladite au moins une entité de traitement d’au moins une politique de gestion de trafic correspondant audit niveau de service associé au jeton à appliquer à des paquets de données relatifs audit service émis par ou destinés audit dispositif de communication. Cette politique de gestion de trafic comprend au moins un élément parmi : - une règle de classification de trafic ; - une indication de priorité ; - une préférence pour préempter des ressources ; - un accès à des ressources (pré)réservées ; - un marquage reposant sur l’utilisation des champs Traffic Class ou Flow Label des entêtes de paquets IP. La politique de gestion de trafic peut avoir une durée limitée. Dans une variante de réalisation, le procédé de configuration comprend : - une étape de réception, en provenance dudit serveur d’application, d’une notification de désactivation dudit jeton ; et - une étape de mise à jour de la configuration de ladite au moins une entité de traitement pour désactiver ledit traitement correspondant au niveau de service associé au jeton. Le procédé de configuration est ainsi adapté pour gérer le cas d’une désactivation du jeton et éviter ainsi que le réseau maintienne des données de classification obsolètes (« stale », en anglais) qui permettrait à des entités frauduleuses d’utiliser les ressources réseaux. Aussi, cela permet de ne pas exposer les entités réseau à des attaques de déni de service (de type dépassement de tampon ou « memory overflow », typiquement). Un autre objet de l’invention concerne un procédé de traitement, par une entité dite de traitement d’un réseau, d’au moins un paquet de données associé à un service émis par ou destiné à un dispositif de communication, ledit procédé comprenant : - une étape de réception d’un élément d’une configuration activée par une entité dite relais du réseau pour que l’entité du traitement applique un traitement à au moins un paquet de données relatif audit service intercepté par l’entité de traitement et comprenant un jeton généré pour ledit dispositif de communication et un accès donné audit service via ledit réseau, ledit jeton étant associé à un niveau de service sélectionné pour cet accès au service, ledit traitement appliqué correspondant audit niveau de service; et - suite à une interception d’un paquet de données relatif audit service comprenant ledit jeton, une étape d’application sur ledit paquet de données dudit traitement correspondant audit niveau de service associé au jeton. L’entité de traitement est par exemple un nœud situé à la périphérie du réseau, tel qu’un routeur d’accès ou un ASBR (« Autonomous System Border Router »). Le fonctionnement d’un tel nœud de bordure permet de gérer le cas où le jeton inséré dans les paquets de données ne correspond pas aux règles de classification URSP (pour « UE Route Selection Policy » en anglais). Le nœud de bordure applique alors le traitement associé au niveau de service désigné par le jeton. On notera que l’élément d’une configuration est par exemple une règle de classification de trafic. On notera également que le procédé de configuration peut être local au nœud de bordure ou reposer sur des instructions communiquées par un contrôleur. On notera également que par « intercepter » on entend que l'entité de traitement est sur le chemin utilisé pour acheminer (« forwarding » en anglais) des paquets. Dans une variante de réalisation, le paquet de données intercepté comprend une indication de marquage correspondant à un niveau de service différent du niveau de service associé au jeton. Ainsi, dans le cas où le niveau de service correspondant à l’indication de marquage est différent du niveau de service associé au jeton, les paquets de données sont traités selon les consignes indiquées par le jeton. Dans une variante de réalisation, suite à l’étape d’application du traitement sur ledit paquet de données, le procédé de traitement comprend une étape de retrait dudit jeton contenu dans le paquet de données. La possibilité de retirer le jeton du paquet de données introduit une certaine flexibilité et permet d’appliquer des politiques spécifiques à un dispositif et qui ne refléteraient pas nécessairement les informations consignées dans un champ Traffic Class ou Flow Label d’un entête de paquet IP. De telles politiques peuvent ainsi être appliquées à un ensemble de flux. Un autre objet de l’invention concerne un serveur d’application comprenant au moins un module configuré pour mettre en œuvre une transmission à un dispositif de communication d’un jeton généré pour ledit dispositif de communication et un accès donné à un service via au moins un réseau, ledit jeton étant associé à un niveau de service sélectionné pour cet accès audit service, ledit jeton étant apte à déclencher, lorsqu’il est contenu dans un paquet de données relatif audit service échangé via ledit au moins un réseau, un traitement de ce paquet de données correspondant audit niveau de service par au moins une entité dite de traitement dudit au moins un réseau. Ainsi, il est possible de gérer à la demande le traitement différencié de certains paquets de données envoyés vers ou par un serveur applicatif. On optimise ainsi la gestion des connexions d’un dispositif de communication au réseau de communication et on s’affranchit de certaines limitations imposées par le système d’exploitation (OS) du dispositif de communication. Un autre objet de l’invention concerne un dispositif de communication configuré pour accéder à un service via au moins un réseau, ledit dispositif de communication comprenant au moins un module configuré pour : - recevoir en provenance d’un serveur d’application associé audit service un jeton généré pour ledit dispositif de communication et un accès donné audit service, ledit jeton étant associé à un niveau de service sélectionné pour cet accès audit service, ledit jeton étant apte à déclencher, lorsqu’il est contenu dans un paquet de données relatif audit service échangé via ledit au moins un réseau, un traitement de ce paquet de données correspondant audit niveau de service par au moins une entité dite de traitement dudit au moins un réseau ; et - envoyer à une entité dite relais dudit au moins un réseau, d’un message d’annonce d’une utilisation dudit jeton par le dispositif de communication lors dudit accès au service, ledit message d’annonce contenant ledit jeton. Ainsi, il est possible de gérer à la demande le traitement différencié de certains paquets de données envoyés vers ou par un serveur applicatif. On optimise ainsi la gestion des connexions d’un dispositif de communication au réseau de communication et on s’affranchit de certaines limitations imposées par le système d’exploitation du dispositif de communication. Un autre objet de l’invention concerne une entité relais comprenant au moins un module configuré pour : - recevoir, en provenance d’un dispositif de communication, un message d’annonce d’une utilisation par le dispositif de communication lors d’un accès donné à un service via ledit réseau d’un jeton contenu dans ledit message d’annonce, ledit jeton ayant été généré pour ledit dispositif de communication et ledit accès au service, et étant associé à un niveau de service sélectionné pour ledit accès au service ; et - si le dispositif de communication est autorisé à accéder au service, configurer au moins une entité du réseau dite entité de traitement du réseau pour que ladite entité de traitement mette en œuvre un traitement correspondant audit niveau de service associé audit jeton lorsque cette entité de traitement intercepte un paquet de données relatif au service contenant ledit jeton. La configuration de l’entité de traitement du réseau est réalisée localement à l’entité ou selon les instructions communiquées par un contrôleur, notamment si le relais est hébergé dans ladite entité de traitement. L’entité de traitement est typiquement un nœud situé en périphérie du réseau de communication, dit « nœud de bordure » et elle applique des règles de classification de trafic. En variante, cette entité de traitement est une entité intermédiaire du réseau, par exemple une entité du réseau d’accès gérant l’accès aux ressources radio ou une entité du réseau coeur. Un autre objet de l’invention concerne une entité de traitement comprenant au moins un module configuré pour : - recevoir une instruction de configuration activée par une entité dite « relais » du réseau pour que l’entité de traitement applique un traitement à au moins un paquet de données relatif à un service intercepté par l’entité de traitement et comprenant un jeton généré pour un dispositif de communication et un accès donné audit service via ledit réseau, ledit jeton étant associé à un niveau de service sélectionné pour cet accès au service, ledit traitement appliqué correspondant audit niveau de service; et - suite à une interception d’un paquet de données relatif audit service comprenant ledit jeton, appliquer sur ledit paquet de données ledit traitement correspondant audit niveau de service associé au jeton. L’entité de traitement est par exemple un nœud de bordure tel qu’un routeur d’accès ou un routeur de bordure. Un nœud de bordure est configuré pour gérer le cas où le jeton inséré dans les paquets de données ne correspond pas aux règles de classification URSP. Le nœud de bordure applique alors le traitement associé au niveau de service tel que désigné par le jeton. On notera que ladite configuration du nœud de bordure consiste par exemple à appliquer une règle de classification de trafic. On notera également que ladite configuration peut être effectuée localement au nœud de bordure selon des commandes déclaratives ou refléter les instructions de configuration communiquées par un contrôleur. Un autre objet de l’invention concerne un programme d’ordinateur comportant des instructions de code de programme pour l’exécution des étapes d’un procédé d’accès à un service via au moins un réseau. Un autre objet de l’invention concerne un support d’enregistrement lisible par un ordinateur sur lequel est enregistré un programme d’ordinateur comprenant des instructions de code de programme pour l’exécution des étapes d’un procédé d’accès à un service via au moins un réseau, lorsque ledit programme est exécuté par un processeur. Description des figures D’autres caractéristiques et avantages de l’invention apparaitront au cours de la lecture de la description détaillée qui va suivre pour la compréhension de laquelle on se reportera aux dessins annexés dans lesquels : La FIG. 1 illustre un exemple simplifié d’interactions entre différents blocs impliqués dans la fourniture d’un service selon l’art antérieur ; La FIG. 2 illustre un exemple d’architecture de référence selon l’art antérieur, dans laquelle un dispositif de communication accède à des services via un réseau de communication qui lui fournit la connectivité ; La FIG. 3 illustre une activation d’un procédé d’accès différencié à un service selon l’invention ; La FIG. 4 illustre un système pour la mise en place d’un procédé d’accès différencié selon l’invention ; La FIG. 5 illustre un message utilisé dans le procédé de FIG. 4 , ledit message comportant une nouvelle option PCP (pour « Port Control Protocol » en anglais) pour la mise en œuvre dudit procédé ; La FIG. 6 illustre des messages utilisés dans le procédé de la FIG. 4 , lesdits message comportant de nouvelles options PCP pour la mise en œuvre dudit procédé ; La FIG. 7 illustre un mécanisme de modification d’un contexte à l’initiative d’un serveur applicatif dans le cas du mode de réalisation de l’invention de la FIG. 4 ; La FIG. 8 illustre un serveur d’application utilisé dans le système de la FIG. 4 ; La FIG. 9 illustre un dispositif de communication utilisé dans le système de la FIG. 4 ; La FIG. 10 illustre une entité relais utilisée dans le système de la FIG. 4 ; La FIG. 11 illustre une entité participant au traitement différencié utilisée dans le système de la FIG. 4 . Description de modes de réalisation La FIG. 3 illustre une activation d’un procédé d’accès à un service, appelé par la suite procédé AMIGOS (pour « Advanced Management of Innovation, Global, and truly Operational Services » en anglais), entre un réseau de communication Network et un serveur d’application AS. Dans un premier temps, le réseau de communication Network (par exemple par l’intermédiaire d’un contrôleur réseau) et le serveur d’application AS négocient dynamiquement la mise en œuvre du procédé d’accès via une API réseau dédiée appelée API AMIGOS. Un protocole de négociation dynamique CPNP (pour « Connectivity Provisionning Negotiation Protocol » selon la norme RFC8921) est activé par exemple en vue d’exposer l’API AMIGOS. Le réseau de communication expose alors un serveur CPNP et l’AS se comporte comme un client CPNP. D’autres protocoles peuvent être utilisés pour exposer cette API AMIGOS tel que le protocole RESTCONF selon la norme RFC8040. A la FIG. 3 , l’AS envoie un message de souscription Subscribe () au réseau de communication en vue de souscrire au service AMIGOS qui permet de gérer à la demande le traitement différencié de paquets de données Data envoyés vers ou par le serveur d’application AS. Le message de souscription contient au moins une adresse IP pour contacter l’AS. Cette adresse IP est codée dans un champ « Contact_Locator » du message. En variante, le message de souscription contient également un numéro de port. Alternativement, le champ « Contact_Locator » peut contenir un nom de domaine destiné à être présenté à une libraire de résolution de noms (par ex. DNS) pour récupérer une adresse IP et/ou un numéro de port. De plus, le message de souscription contient une information descriptive du niveau de service (champ « service_level ») désiré par l’AS pour l’accès au service (plus particulièrement, pour la fourniture du service via ce réseau). Le niveau de service indique une classe de service. Le niveau de service peut comprendre également des paramètres de performance (par exemple la latence ne doit pas excéder 20 ms), un niveau de sécurité, résilience, etc. Le niveau de service peut comprendre également un type de tranches, par exemple une tranche de type URLLC. Dans un mode de réalisation, le niveau de service fait l’objet d’une description détaillée, par exemple, sous la forme d’une liste d’attributs qui résulte de la combinatoire de différents paramètres tels que ceux évoqués ci-dessus. En variante, le niveau de service est décrit selon une seule référence. Dans ce cas, l’association de cette référence à une liste détaillée de paramètres est supposée être connue de l’AS et du réseau. Cette association est par exemple consignée dans un catalogue de services, tel que décrit dans le document TS28.541 dans sa version 16.6.0 notamment, publiée par le 3GPP, et qui décrit les différents types de tranches et les paramètres de qualité de service associés. A l’issue de l’acceptation de la demande de souscription, l’API réseau AMIGOS retourne un identifiant de service « as_id » pour identifier d’une manière non-ambigüe l’AS. Elle fournit également à l’AS au moins une plage d’adresses IP (« IP address range » en anglais) ou de préfixes IP dudit réseau de communication. Dans un mode de réalisation particulier, des plages par familles d’adresses (IPv4/IPv6) sont consignées dans une réponse à une demande de souscription dans le cadre de la négociation reposant sur l’exemple de la négociation CPNP. Cet identifiant de service « as_id » est alloué par le réseau. En variante, c’est l’AS qui génère lui-même l’identifiant de service « as_id ». Dans ce cas, une procédure pour s’assurer que l’identifiant de service « as_id » est globalement unique est supportée par l’AS. Ceci n’est pas nécessaire si l’identifiant de service « as_id » est généré par le réseau car l’unicité doit être seulement locale à ce réseau. Dans une autre variante, l’identifiant de service « as_id » est alloué par une entité tierce (par exemple l’IANA (pour « Internet Assigned Numbers Authority » en anglais)). On suppose, ici, que l’AS expose un serveur PCP (pour « Port Control Protocol » en anglais conformément à la norme RFC6887). Ainsi, le champ « Contact_Locator » contient les informations pour joindre le serveur PCP de l’AS telles qu’une adresse IP, un nom de domaine, un numéro de port, etc. L’API AMIGOS peut également être utilisée pour négocier le canal d’insertion des métadonnées AMIGOS considérées lors de la mise en œuvre de l’invention dans les paquets échangés dans le contexte de ce service. De telles métadonnées comprenant notamment, comme décrit plus en détail ultérieurement, un jeton amigos_token. D’une manière optionnelle, l’API indique également si l’insertion doit être effectuée pour tous les paquets éligibles au service ou seulement pour une partie des paquets. Les autres paquets peuvent être identifiés sur la base d’un calcul de condensé de tout ou partie des métadonnées (par exemple du jeton amigos_token) à comparer avec le condensé calculé pour des paquets qui présentent des métadonnées valides (dans l’exemple envisagé, un jeton amigos_token valide). Typiquement, ce canal est utilisé dans le contexte de l’invention pour insérer des informations de marquage AMIGOS (et notamment le jeton amigos_token précité) dans les paquets qui transportent les données envoyées depuis une instance de service du serveur d’application vers un dispositif de communication joignable via ce réseau mais aussi depuis un dispositif de communication connecté à ce réseau qui envoie des paquets vers une instance de service du serveur d’application. On notera dès à présent qu’un tel jeton amigos_token est utilisé dans le contexte de l’invention pour identifier un traitement différencié à appliquer pour satisfaire les besoins du service, typiquement pour satisfaire un niveau de service. Le jeton amigos_token est ainsi plus particulièrement associé à un niveau de service service_level sélectionné pour un accès au service par le dispositif de communication. On note que le niveau de service négocié entre un AS et un réseau peut être défini pour indiquer une classe de traitement et non le traitement précis à appliquer sur les paquets reçus ou à destination d’un AS. Par exemple, une classe de traitement peut indiquer un niveau de granularité du traitement différencié à mettre en place (par ex. invocation d’une fonction d’inspection de malware ou de canaux couverts pour tout ou partie des paquets qui présentent un jeton valide). L’API AMIGOS peut également être utilisée pour indiquer le mode de population des tables de classification à base de jetons amigos_token. A titre illustratif, si un mode « non-sollicité » est indiqué, alors l’AS informe le réseau quand un nouveau jeton amigos_token est fourni à un dispositif de communication. Si un mode « sollicité » est indiqué, le réseau doit contacter l’AS pour vérifier l’authenticité du jeton présenté par le dispositif de communication. Les informations échangées lors de la procédure de négociation/souscription sont enregistrées par le réseau dans une table « AS_AMIGOS_SUBSCRIBERS » et par l’AS dans une table « NTW_AMIGOS_SUBSCRIPTIONS ». La FIG. 4 illustre un système SYS pour la mise en place d’un procédé d’accès différencié à un service selon un premier mode de réalisation de l’invention. Ce système SYS comprend ici : – un dispositif de communication UE ; – une entité relais amigos_relay, une entité de traitement AN, BR et un contrôleur réseau Controller situés dans le réseau de communication Network ; – le serveur d’application AS. Le dispositif de communication est ici un « User Equipment » UE. Il peut être un terminal mobile ou un terminal fixe. En variante, le dispositif de communication peut être une instance de service, un CPE (pour « Customer Premises Equipment »), etc. Aucune hypothèse n’est faite quant à la nature du dispositif de communication. Le dispositif de communication UE embarque, dans le mode de réalisation décrit ici, un client PCP tel que décrit dans le document IETF RFC 6887 édité par D. Wing et al. intitulé « Port Control Protocol (PCP) », avril 2013. Un client PCP est une structure logicielle qui a la possibilité de générer des requêtes PCP vers un serveur PCP. D’autres protocoles que PCP peuvent être utilisés (par ex., HTTP) ; ainsi l’invention n’est pas limitée au seul mode de réalisation décrit ici. En outre, le dispositif de communication UE est adapté pour être connecté à au moins un réseau de communication Network. Ce réseau de communication Network peut être un réseau mobile 5G, un réseau sans fil WLAN (pour « Wireless Local Area Network ») ou un réseau fixe. Le dispositif de communication UE comprend au moins un module configuré pour recevoir un jeton amigos_token en provenance du serveur d’application AS et accéder au service. Le dispositif de communication UE est également adapté pour envoyer à l’entité relais amigos_relay un message d’annonce M AD de l’utilisation du jeton amigos_token par ce dispositif lors de l’accès au service. Ce message d’annonce M AD comprend le jeton amigos_token. Le réseau de communication Network peut supporter plusieurs tranches réseaux (« slice » en anglais). Un réseau peut être organisé en plusieurs réseaux distincts qui composent autant de domaines (par exemple, un réseau de communication peut être composé d’un réseau d’accès, d’un réseau de collecte, d’un réseau cœur et d’un réseau de transit). Chacun de ces domaines supporte des tranches réseau dont l’ingénierie et l’exploitation sont caractéristiques du domaine (par exemple, une tranche déployée sur un réseau cœur mobile 5G fera appel à des fonctions de traitement de trafic et d’exploitation caractéristiques d’un réseau cœur mobile 5G). Ainsi, chaque domaine exploite des technologies qui peuvent être spécifiques à ce réseau pour la réalisation des tranches réseau (par ex. en fonction des choix d’ingénierie locale à un opérateur réseau). Des tranches dans un réseau mobile (5G) pourraient reposer sur la mise en place de tranches dans les différents segments suivants : Radio Access Network (RAN), Core Network (CN) et Transport Network (TN). La réalisation d’une tranche réseau qui s’étend sur plusieurs domaines n’est pas conditionnée par la disponibilité ou l’activation des mêmes technologies utilisées pour la réalisation des tranches « locales » à chaque domaine. Par exemple, un premier domaine peut mettre en place des tunnels IPsec qui sont exploités pour acheminer le trafic dans les tranches déployées dans ce domaine, alors qu’un autre domaine utilise une ingénierie de réseau privé virtuel de niveau réseau (Layer 3 VPN ou L3VPN en anglais) combiné avec des mécanismes d’ingénierie de trafic (TE, Traffic Engineering), tandis qu’un troisième domaine utilise les ressources du routage par segments reposant sur le protocole IPv6 (Segment Routing IPv6 ou SRv6 en anglais) pour acheminer le trafic dans les tranches déployées dans ce domaine. Une tranche réseau peut impliquer une ou plusieurs fonctions service selon la terminologie utilisée par le RFC7665, ou « Network Functions » comme gNB (« gNodeB ») ou des fonctions UPF (« User Plane Function ») selon la terminologie utilisée par le 3GPP). Une même fonction service peut être fournie par une ou plusieurs instances de service. Une instance de service peut être hébergée par le SSP (Slice Service Provider, ou fournisseur de services reposant sur des tranches réseau) ou au sein d’une autre infrastructure. Des chaînes de service (ou Service Function Chain (SFC) en anglais) peuvent être mises en place afin de faciliter l’acheminement de trafics de différente nature et présentant des profils différents pour les besoins de la réalisation d’une tranche ou au sein d’une tranche. La FIG. 4 illustre également la mise en œuvre du procédé d’accès différencié à un service dans la situation d’un réseau de communication Network supportant trois tranches réseau T1, T2, T3 représentées schématiquement par des tubes. Dans ce cadre, le traitement différencié consiste à associer certains messages à ces tranches T1, T2, T3. On notera que le dispositif de communication est ici adapté pour négocier avec chaque SSP auquel il est connecté une liste de tranches qu’il est susceptible d’utiliser pour envoyer ou recevoir du trafic. Pour chaque tranche, son type est aussi négocié entre le dispositif de communication et le réseau. En variante, des identifiants de tranche réseau ou marqueurs idoines (« tags », qui ne sont pas des identifiants utilisés effectivement pour le marquage des données d’une tranche mais pour des besoins de classification) sont aussi communiqués par le réseau au dispositif de communication. Dans le réseau de communication Network de la FIG. 4 : - l’entité relais comprend au moins un relais PCP également appelé Proxy PCP ou AMIGOS_relay ; - l’entité de traitement comprend un routeur d’accès AN (pour « Access Network » en anglais) et au moins un routeur de bordure BR (pour « Border Router » en anglais ). Le relais PCP est adapté pour recevoir des requêtes PCP provenant d’un ou plusieurs client(s) PCP du dispositif de communication UE. Ce relais est compatible avec la norme RFC 7648 publiée en septembre 2015. Il a la fonction de relais de requêtes PCP. Ce relais peut être localisé avec une fonction CGN (pour « Carrier Grade NAT », par exemple un CGN NAT64 (Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers, RFC6146 publiée en avril 2011), un pare-feu, une fonction de translation de préfixes IPv6 NPTv6 (IPv6-toIPv6 Network Prefix Translation, RFC6296 publiée en juin 2011). Le relais procède au traitement de l’adresse externe indiquée dans les messages PCP relayés selon le mécanisme décrit dans la Section 3.3 du RFC 7648 (Port Control Protocol Proxy Function) publiée en septembre 2015. Le relais est configuré avec des règles qui permettent de contrôler le périmètre de traitement d’une requête émise par le dispositif de communication UE, si une telle requête peut être traitée localement par le premier relais sollicité par le dispositif de communication UE ou si elle doit être transmise à un autre serveur PCP. De telles règles peuvent, par exemple, refléter l’organisation mise en place au titre de l’ingénierie du service AMIGOS. Elles peuvent reposer sur un principe de régionalisation qui impose de solliciter un serveur PCP « national » seul habilité à servir certaines requêtes qui permettraient de bénéficier d’un service AMIGOS dans le cas d’un AS situé dans certaines régions frontalières du réseau. Le relais PCP a une fonction de gestionnaire de tranches réseau pour l’acheminement des paquets de données Data via la tranche réseau, qui est choisie en fonction du niveau de service requis. Dans un premier mode, le dispositif de communication est configuré par le réseau de communication Network avec les informations du relais. A cet effet, au moins une adresse IP, un numéro de port et un identifiant d’authentification (ADN pour « Authentification Domain Name » en anglais) pour joindre le relais sont configurés. La configuration réseau peut utiliser les ressources d’un protocole dédié tel que DHCP (pour « Dynamic Host Configuration Protocol » en anglais) ou un message RA (message Router Advertisement en environnement IPv6). Dans un deuxième mode, le dispositif de communication utilise une adresse anycast ou multicast pour envoyer un message de découverte (DISCOVER()). Si un relais AMIGOS est disponible, celui-ci répond avec un message ACK(IP Address(es), port number, ADN). Dans un troisième mode, le dispositif de communication utilise un nom de domaine SUDN (Special-Use Domain Names RFC6761 publiée en février 2013) puis procède à des résolutions SVCB (« Service binding and parameter specification via the DNS », RFC 9460 publiée en novembre 2023) associées à ce nom spécifique. Un nouveau SvcParam, appelé « amigos » peut être défini pour indiquer le support de la procédure AMIGOS. Le routeur d’accès AN est déployé à la périphérie du réseau de communication Network. Il comprend des règles de classification de trafic et de contrôle d’admission pour gérer des échanges de paquets de données Data entre le dispositif de communication UE et le réseau de communication Network. Le routeur AN est adapté pour sélectionner, dans un exemple de réalisation non limitatif, une tranche réseau adaptée pour transmettre les paquets de données émis par le dispositif de communication UE à destination d’un serveur AS. Le routeur de bordure BR est déployé à la périphérie du réseau de communication Network. Il applique des règles de classification de trafic et de contrôle d’admission pour gérer des échanges de paquets de données Data entre le réseau de communication Network et une instance SFI du serveur applicatif AS (directement ou indirectement via un autre réseau d’interconnexion). Le routeur d’accès AN et le routeur de bordure BR sont des entités du réseau qui sont impliquées dans le traitement différencié du trafic. Chaque routeur AN et BR comprend au moins un module configuré pour recevoir des instructions de configuration activée par l’entité amigos_relay. Chaque routeur est adapté pour appliquer un traitement à au moins un paquet de données Data comprenant un jeton amigos_token. Ce traitement correspond au niveau de service service_level associé au jeton amigos_token. Le contrôleur Controller est disposé dans le réseau de communication NETWORK entre le routeur AN et le routeur BR. Il est adapté pour transmettre (incluant pour mettre à jour) les règles de classification de trafic dans ledit routeur AN et ledit routeur BR. Ce contrôleur est, par exemple, un contrôleur SDN (pour « Software-Defined Networking » en anglais). On notera que les règles de classification de trafic sont instanciées pendant la durée de validité indiquée par le relais PCP ou par un serveur PCP appartenant au serveur applicatif AS. La durée de vie peut aussi être contrôlée par une valeur par défaut sélectionnée par l’opérateur du réseau. Le serveur d’application AS est un serveur adapté pour permettre l’installation, l’exploitation et l’hébergement de services. Ce serveur d’application AS comprend : - le serveur PCP ; - au moins une instance SFI. Le serveur PCP est adapté pour échanger des requêtes PCP avec le PCP Proxy du réseau de communication. L’instance SFI (pour « Service Function Instance » en anglais) est impliquée dans la fourniture du service exposé par l’AS. Elle est adaptée pour communiquer avec le Client PCP du dispositif de communication UE selon le protocole PCP. Elle est également adaptée pour échanger des paquets de données Data avec le dispositif de communication UE. Le serveur PCP et la au moins une instance SFI permettent de mettre en œuvre une transmission du jeton amigos_token au dispositif de communication UE pour un accès donné au service via le réseau Network. On notera ici que le serveur d’application AS est le même serveur que le serveur d’application AS de la FIG. 3 gérant la souscription au service AMIGOS. En variante, le serveur d’application AS de la FIG. 4 est différent du serveur d’application de la FIG. 3 . Ces serveurs d’application peuvent alors former deux entités distinctes. En variante, ces serveurs d’application sont colocalisés, ou on peut envisager d’avoir deux instances de service d’un même serveur d’application. La FIG. 4 illustre également la mise en place d’un procédé d’accès différencié à un service. Dans une première étape, le dispositif de communication UE établit une communication avec le serveur applicatif AS. Plus précisément, c’est un client applicatif embarqué dans le dispositif de communication UE qui établit cette connexion avec l’instance instance SFI de l’AS. Pour établir cette communication, le dispositif de communication UE envoie un message Req pour accéder à un service. Ce message comprend une adresse source associée au dispositif de communication UE. Dans une seconde étape, sur réception de ce message Req, le serveur d’application AS extrait l’adresse source du paquet puis consulte la table « NTW_AMIGOS_SUBSCRIPTIONS » pour vérifier si le dispositif de communication UE est bien éligible à un accès différencié pour un service. A cet effet, l’instance SFI vérifie que l’adresse source extraite du message Req correspond à une plage IP de ladite table. Si c’est le cas, ladite instance SFI envoie un message au dispositif de communication en réponse à sa requête initiale avec, dans le mode de réalisation décrit ici, les éléments d’informations suivants : - un identifiant de service as_id connu du réseau. Cet identifiant est associé à l’AS tel que renseigné dans la table « NTW_AMIGOS_SUBSCRIPTIONS » et il correspond à l’identifiant connu du réseau auquel le dispositif de communication est connecté ; - un identifiant ue_id sélectionné par le serveur d’application AS pour le dispositif de communication UE. En variante, cet identifiant peut être généré par une autre entité que l’AS, par exemple une entité responsable de la gestion des connexions de l’ensemble des terminaux à l’AS, toutes instances de service confondues. Dans une autre variante, l’identifiant est généré par connexion/session de service. Dans ce cas, un nouvel identifiant est alloué à chaque connexion au service même si la même adresse IP externe est utilisée pour joindre le service par un même dispositif de communication. Cette variante est, par exemple, motivée par la nature du service, tel qu’un service transactionnel. - l’information service_level qui indique le niveau du service sélectionné pour le dispositif de communication. Cette information est maintenue dans la table « NTW_AMIGOS_SUBSCRIPTIONS » ; - un jeton amigos_token, tel que décrit précédemment, et destiné à être inséré dans les paquets émis par ou à destination de l’UE. Comme il a déjà été précisé, ce jeton est utilisé pour identifier les paquets éligibles à un niveau de service correspondant à l’information « service_level » dans le réseau de communication auquel le dispositif de communication est connecté. Il est généré pour le dispositif de communication et pour un accès donné au service via le réseau (dans le mode de réalisation décrit ici, suite à la réception du message Req d’accès au service envoyé par le dispositif de communication). Ce jeton est associé à un niveau de service sélectionné pour cet accès. Ainsi, le jeton peut introduire une certaine granularité par rapport à l’information « service_level » permettant de sélectionner un niveau de service pour l’accès spécifique au service par le dispositif de communication. D’autres informations, telles que le canal négocié avec le réseau de communication pour l’insertion des métadonnées AMIGOS, et en particulier du jeton amigos_token, peuvent être communiquées au dispositif de communication dans le message de réponse ainsi que des indications précisant si l’insertion doit s’effectuer dans tout ou partie des paquets de données. Par ailleurs, on note qu’afin d’optimiser l’accès au service, dans un mode particulier de réalisation, l’AS (et plus particulièrement son instance SFI) peut communiquer au dispositif de communication UE, lors d’un premier accès au service, une liste de jetons à utiliser pour des accès futurs au service. Ce mode de réalisation permet d’appliquer un traitement différencié même sur la demande d’accès au service envoyée par le dispositif de communication UE. L’instance SFI enregistre les informations descriptives de la connexion (par exemple : 4-uplet pour TCP, identifiant de connexion QUIC) ainsi que les informations envoyées à l’UE. Ces informations sont enregistrées dans une table appelée ici ASAAC pour AS_ACTIVE_AMIGOS_CONTEXTS. Si le mode « non-sollicité » est activé pour ce réseau, l’AS informe le relais PCP dudit réseau de l’activation du jeton amigos_token pour cette communication. Sur réception des éléments d’informations (« amigos_token », « as_id », « ue_id », « service_level », …) par le dispositif de communication, l’applicatif APP#i vérifie si une API exposée par l’OS permet de communiquer ces informations à l’OS pour les besoins de classification des trafics associés à un niveau de service. Si l’API exposée par l’OS permet effectivement la transmission de ces informations, cette API est utilisée pour négocier la classification du trafic en exploitant les informations retournées par l’instance de service. L’API se charge alors d’effectuer les vérifications et d’exécuter les opérations décrites ci-après pour l’applicatif APP#i. Si l’API exposée par l’OS ne permet pas le transfert de ces informations, l’applicatif APP#i envoie, via le client PCP, le message d’annonce M ad de l’utilisation du jeton amigos_token, à destination du relais AMIGOS associé au réseau de communication (ce relais est déjà configuré par le réseau ou découvert par le dispositif come décrit précédemment). Ce message d’annonce correspond à une requête PCP. Le message d’annonce M ad peut être un message MAP ou PEER. En plus d’une option FILTER, telle que décrite dans la Section 13.3 de la RFC6887, le message d’annonce M ad contient, dans un mode de réalisation particulier, une option appelée ici SLICE_CLASS, telle que décrite sur la FIG. 5 . L’option FILTER a pour objectif de ne permettre que l’envoi de messages à destination de l’instance de service pour bénéficier du service AMIGOS. L’option SLICE_CLASS contient les éléments d’information retournés par l’instance du service SFi (« amigos_token », « as_id », « ue_id », « service_level », …). En variante, plusieurs options PCP peuvent être définies comme cela est illustré à la FIG. 6 . Chacune de ces options inclut un élément d’information de la liste (« amigos_token », « as_id », « ue_id », et « service_level »). D’autres formes d’encodage peuvent être considérés. Le client PCP du dispositif de communication UE et le Proxy PCP du relais AMIGOS s’authentifient mutuellement. En particulier, le client PCP utilise le paramètre ADN pour authentifier ledit Proxy PCP et éviter que les données soient interceptées par une entité malveillante. Le Proxy PCP authentifie le client PCP sur la base des informations enrichies par le réseau de communication (par exemple le numéro MSISDN (pour « Mobile Station International Subscriber Directory Number » en anglais), l’adresse IP interne auquel le dispositif de communication se connecte, un certificat présenté par un dispositif de communication. Le relais AMIGOS consulte la table « AS_AMIGOS_SUBSCRIBERS » pour vérifier si l’AS identifié par l’identifiant de service « as_id », tel que communiqué par le dispositif de communication, a souscrit au service AMIGOS. Si une entrée est trouvée et que le mode « non-sollicité » est activé par cet AS identifié par « as_id », le relais AMIGOS vérifie si une entrée de classification correspond à un jeton « amigos_token » communiqué par l’AS. Si une entrée est trouvée, le relais AMIGOS envoie un message « SUCCESS » au dispositif de communication pour confirmer l’établissement d’un contexte (c.-à-d.- un état qui permet de procéder à la classification et déclencher ainsi le traitement différencié sur les paquets qui correspondent aux règles de classification (« match», en anglais)). Le dispositif de communication UE peut alors marquer le trafic éligible au service AMIGOS en utilisant le jeton « amigos_token ». Si aucune entrée n’est trouvée, alors un message d’erreur (« NOT_AUTHORIZED ») est envoyé au dispositif de communication. Les demandes provenant de ce dispositif de communication peuvent être limitées (via un paramètre « rate-limit ») et de façon optionnelle, le relais AMIGOS envoie un message d’alerte à destination d’une plateforme dédiée. Dans la suite, on suppose que le mode « sollicité » est activé. Si le mode « sollicité » est activé, le relais AMIGOS récupère les informations permettant d’accéder au serveur PCP associé à cet AS (c’est-à-dire, celles consignées dans l’attribut « Contact_Locator » échangé lors de la négociation CPNP). La requête initiale du dispositif de communication UE est ensuite envoyée par le relais AMIGOS vers ce serveur. Les informations contenues dans la requête sont ajustées par le relais (par ex. l’adresse interne du client PCP, retrait des options FILTER, ou retrait de l’information « as_id »). Sur réception de la requête par le serveur PCP associé à l’AS, le serveur PCP vérifie si un contexte qui correspond aux informations contenues dans la requête PCP est maintenu dans la table ASAAC. Si une entrée est trouvée, alors une réponse positive (« SUCCESS ») est envoyée au relais pour confirmer cette entrée. Le message indique une durée de validité pour cette entrée. Si aucune entrée n’est trouvée, alors un message d’erreur (« NOT_AUTHORIZED ») est envoyé au relais AMIGOS. Sur réception de ce message, le relais AMIGOS rejette la demande du dispositif de communication UE. Les demandes provenant de ce dispositif de communication peuvent être limitées (via un paramètre « rate-limit ») et de façon optionnelle, le relais envoie un message d’alerte à destination d’une plateforme dédiée. Sur réception du message « SUCCESS » par le relais AMIGOS, celui-ci procède comme suit. Il envoie le message « SUCCESS » au dispositif de communication UE pour confirmer l’établissement du contexte. Le dispositif de communication UE peut alors marquer le trafic éligible au service AMIGOS en utilisant le jeton « amigos_token ». Le relais AMIGOS installe en outre au moins une règle pour que le trafic reçu du ou destiné au dispositif de communication UE contenant le jeton amigos_token soit traité selon le niveau de service défini par le paramètre « service_level » et sélectionné pour l’accès au service par le dispositif de communication UE. Une ou plusieurs règles peuvent être installées dans le réseau. Ces règles peuvent être des règles IP, radio, etc. Le niveau de service appliqué au trafic du dispositif de communication UE est ainsi défini par les indications véhiculées par le jeton, et incidemment par les indications fournies par le relais AMIGOS dans les règles installées dans le réseau destinées à être appliquées par les éléments du réseau impliqués dans le traitement du trafic du dispositif de communication UE véhiculant le jeton amigos_token. L’échange de paquets de données Data peut alors avoir lieu entre le dispositif de communication UE et le serveur d’application AS via le routeur AN et le routeur BN. La FIG. 7 illustre un mécanisme de modification d’un contexte à l’initiative du serveur d’application dans le cas du premier mode de l’invention de la FIG. 4 . Le serveur PCP peut modifier le contexte pour le dispositif de communication. Pour cela, il envoie un message « ANNOUNCE » au Proxy PCP associé à un contexte stocké dans la table ASAAC, pour mettre à jour l’entrée correspondante. Le Proxy PCP transmet cette information au contrôleur Controller. Le contrôleur fait alors modifier les différentes règles de classification de trafic les entités réseau concernées, typiquement les routeurs AN et BR. En référence à la FIG. 7 , la modification est une suppression du contexte pour le dispositif de communication UE. Le trafic émis par ce dispositif de communication avec un marquage « amigos_token » ne sera plus alors traité au titre du service AMIGOS tel que négocié entre le réseau de communication Network et le serveur applicatif AS. Concrètement, le trafic présenté avec un jeton AMIGOS expiré est traité selon un mode de base (« par default ») et ne bénéficie donc pas de traitement différencié. Le dispositif de communication UE peut également participer au maintien de l’entrée PCP dans le Proxy PCP en conformité avec la durée de validité édictée par l’instance de service SFI. En l’absence de messages de rafraîchissement avant l’échéance de cette durée de validité de l’entrée PCP correspondante, les règles de classification du trafic échangé entre le dispositif de communication UE et l’instance de service SFI considérée seront supprimées. Le dispositif de communication peut supprimer le contexte lorsque la session de service est clôturée. Dans une variante de réalisation, l’entrée PCP est maintenue même si la session a été clôturée. L’avantage de ce mode est d’optimiser le temps d’établissement de session lorsque le dispositif de communication se reconnecte au service pendant un intervalle de temps choisi par le service. En cas de modification de l’adresse externe du dispositif de communication (par l’UE ou par un élément du réseau), cette modification est notifiée au serveur PCP par le Proxy PCP pour mettre à jour les règles de classification de trafic qui tiendront le cas échéant compte de la nouvelle adresse externe : Si le protocole de transport utilisé par le service permet de maintenir la session même en cas de modification de l’adresse IP ou du numéro de port (comme dans le cas du protocole QUIC spécifié dans le standard RFC 9000 dans sa publication de mai 2021), alors le dispositif de communication n’a pas besoin de clôturer la connexion en cours ni d’établir une nouvelle connexion (contexte de continuité de service). Sinon, une nouvelle connexion est établie avec l’instance de service. Le serveur applicatif AS peut alors maintenir le même identifiant de dispositif de communication (« ue_id ») même en cas de changement d’adresse IP externe ou pas. Cette décision est locale à chaque serveur AS. Dans une variante de réalisation, la procédure PCP est effectuée lors d’une première connexion du dispositif de communication à une instance de service, et non par session de service. Dans une autre variante de réalisation, si le dispositif de communication est localisé derrière un équipement tel qu’un CPE, alors le terminal utilisateur contacte le nœud de périphérie pour mettre en place des règles PCP gérées par le Proxy PCP embarqué dans le CPE. La FIG. 8 illustre un serveur d’application AS pour une gestion de service, tel qu’utilisé dans le système SYS de FIG. 4 . Ce serveur d’application AS comprend : - au moins une interface entrée/sortie E/S AS ; - une mémoire de stockage Mem AS ; - un processeur Proc AS . La au moins une interface entrée/sortie E/S AS est adaptée pour transmettre au dispositif de communication UE le jeton amigos_token généré pour le dispositif de communication et un accès donné à un service via au moins le réseau Network. Comme il a déjà été précisé, le jeton amigos_token est associé au niveau de service (« service_level » en anglais) sélectionné pour cet accès au service. Le jeton amigos_token est apte à déclencher, lorsqu’il est contenu dans un paquet de données relatif audit service échangé via le réseau Network. Le traitement de ce paquet de données par au moins une entité de traitement AN, BR correspond au niveau de service ad hoc. La mémoire de stockage Mem AS est adaptée pour stocker des informations telles que le jeton amigos-token, le niveau de service service_level associé à ce jeton, l’identifiant « ue_id » du dispositif de communication UE, l’identifiant de service as_id. Le processeur Proc AS est adapté pour mettre en œuvre les étapes d’un procédé de gestion d’un service par le serveur d’application AS. Ce procédé de gestion comprenant l’étape de transmission au dispositif de communication UE du jeton amigos_token généré par le dispositif de communication UE pour un accès donné au service via le réseau Network. Ce procédé de gestion comprend en outre une étape de fourniture de l’information de vérification que le dispositif de communication UE est autorisé à accéder au service en utilisant le jeton. Cette information de vérification comprend le jeton amigos_token et l’identifiant ue_id du dispositif de communication UE. En variante, l’information de vérification comprend une confirmation SUCCESS que le dispositif de communication UE est autorisé à accéder au service en utilisant le jeton amigos_token. L’étape de transmission du procédé de gestion comprend en outre la transmission d’une indication représentative du canal véhiculé par le paquet de données Data dans lequel le jeton amigos_token doit être contenu pour déclencher le traitement de ce paquet. L’étape de transmission comprend en outre la transmission d’au moins un élément tel que l’identifiant de service connu du réseau, l’identifiant ue_id sélectionné par le serveur d’application AS pour le dispositif de communication UE ou l’information représentative du niveau de service service_level. Le procédé de gestion comprend en outre l’étape d’envoi d’au moins un paquet de données Data relatif au service au dispositif de communication UE contenant le jeton amigos_token. Le procédé de gestion comprend également une étape de désactivation du jeton amigos_token et une étape de notification à au moins une entité du réseau (amigos_relay ou contrôleur) de cette désactivation. La FIG. 9 illustre un dispositif de communication UE tel qu’utilisé dans le système SYS de FIG. 4 . Ce dispositif de communication UE comprend : - au moins une interface entrée/sortie E/S UE ; - une mémoire de stockage Mem UE ; - un processeur Proc UE . La au moins une interface entrée/sortie E/S UE est adaptée pour recevoir en provenance du serveur d’application AS associé au service le jeton amigos_token généré pour le dispositif de communication UE. Cette interface E/S UE est également adaptée pour envoyer à l’entité amigos_relay le message d’annonce M ad d’une utilisation du jeton amigos_token par le dispositif de communication UE lors de l’accès au service. La mémoire de stockage Mem UE est adaptée pour stocker des informations telles que le jeton amigos-token, le niveau de service service_level associé à ce jeton, l’identifiant ue_id du dispositif de communication UE, l’identifiant de service as_id. Le processeur Proc UE est adapté pour mettre en œuvre les étapes d’un procédé d’accès au service via le réseau. Ce procédé d’accès comprend l’étape de réception du jeton amigos_token et l’envoi du message d’annonce M ad à l’entité relais amigos_relay. Le procédé d’accès comprend en outre une étape d’insertion du jeton amigos_token dans un paquet de données relatif au service. La FIG. 10 illustre une entité relais amigos_relay telle qu’utilisée dans le système SYS de FIG. 4 . Cette entité relais comprend : - au moins une interface entrée/sortie E/S relay ; - une mémoire de stockage Mem relay ; - un processeur Proc relay . La au moins une interface entrée/sortie E/S relay est adaptée pour recevoir le message d’annonce M ad et pour configurer au moins une entité de traitement du réseau AN, BR. La mémoire de stockage Mem relay est adaptée pour stocker le message d’annonce M ad . Le processeur Proc relay est adapté pour mettre en œuvre un procédé de configuration d’au moins une entité de traitement du réseau AN, BR par l’entité relais amigos_relay. Ce procédé comprend une étape de réception du message d’annonce M ad et une étape de configuration à partir des informations contenues dans ce message d’annonce M ad . Le message d’annonce M ad comprend en outre l’identifiant de service utilisé par l’entité relais pour solliciter le serveur d’application en vue de déterminer si le dispositif de communication est autorisé à accéder au service. L’étape de configuration comprend en outre la transmission d’une politique de gestion de trafic correspondant au niveau de service associé au jeton. Le procédé de configuration comprend en outre une étape de réception d’une notification de désactivation du jeton en provenance du serveur d’application AS et une étape de mise à jour de la configuration pour désactiver le traitement correspondant au niveau de service associé au jeton. La FIG. 11 illustre une entité de réseau participant au traitement différencié. Dans l’exemple de la FIG. 11 , cette entité réseau est le routeur d’accès AN tel qu’utilisé dans le système SYS de FIG. 4 . Ce routeur d’accès AN comprend : - au moins une interface entrée/sortie E/S AN ; - une mémoire de stockage Mem AN ; - un processeur Proc AN . La au moins une interface entrée/sortie E/S AN est adaptée pour recevoir les instructions de configuration mises en œuvre par l’entité relais amigos_relay pour que le routeur d’accès AN applique un traitement à au moins un paquet de données Data relatif au service intercepté par ce routeur. La mémoire de stockage Mem AN est adaptée pour stocker l’élément de configuration. Cet élément de configuration est, par exemple, une règle de classification de trafic. Le processeur Proc AN est adapté pour mettre en œuvre un procédé de traitement d’au moins un paquet de données Data associé au service émis par ou destiné au dispositif de communication UE. Ce procédé de traitement comprend une étape de réception des instructions de configuration mises en œuvre par l’entité relais amigos_relay et une étape de traitement du paquet de données Data selon le niveau de service associé au jeton. Le paquet de données intercepté peut comprendre une indication de marquage correspondant à un niveau de service différent du niveau de service associé au jeton. Dans ce cas, on applique le traitement associé au jeton Suite à l’étape d’application du traitement du paquet de données, le procédé de traitement comprend une étape de retrait du jeton contenu dans le paquet de données Data. En variante, le jeton est conservé dans le paquet de données. La possibilité de conserver ou de retirer le jeton du paquet de données introduit une certaine flexibilité et permet de déclencher l’application des politiques spécifiques à un dispositif qui ne seraient pas déclenchées selon les informations consignées dans un champ Traffic Class ou Flow Label d’un entête de paquet IP par exemple. De telles politiques spécifiques à un dispositif peuvent avantageusement être appliquées à un ensemble de flux de données (aussi appelé agrégats) et non par flux émis ou reçus par le dispositif de communication. On notera que le traitement différencié n’est pas seulement celui activé localement dans une entité de traitement mais peut couvrir tout le chemin utilisé pour l’acheminement (« forwarding » en anglais) du trafic au sein d’un réseau. La description de la FIG. 11 s’applique également au routeur de bordure BR de la FIG. 4 . Procédé de gestion d’un service par un serveur d’application (AS), ledit procédé comprenant une étape de transmission à un dispositif de communication (UE) d’un jeton (amigos_token) généré pour ledit dispositif de communication et un accès donné à un service via au moins un réseau (Network), ledit jeton (amigos_token) étant associé à un niveau de service (service_level) sélectionné pour cet accès audit service, ledit jeton (amigos_token) étant apte à déclencher, lorsqu’il est contenu dans un paquet de données (Data) relatif audit service échangé via ledit au moins un réseau (Network), un traitement de ce paquet de données (Data) correspondant audit niveau de service (service_level) par au moins une entité (AN, BR) dite de traitement dudit au moins un réseau (Network). Procédé de gestion selon la revendication 1, comprenant en outre une étape de fourniture d’au moins une information de vérification à une entité dite relais (amigos_relay) dudit au moins un réseau permettant à ladite entité relais (Relais amigos_relay) de vérifier que ledit dispositif de communication (UE) est autorisé à accéder audit service en utilisant ledit jeton (amigos_token). Procédé de gestion selon la revendication 2, dans laquelle ladite au moins une information de vérification comprend : - ledit jeton (amigos_token) et un identifiant (ue_id) dudit dispositif de communication (UE) alloué par le serveur d’application ; ou - une confirmation (SUCCESS) que ledit dispositif de communication (UE) est autorisé à accéder audit service en utilisant ledit jeton (amigos_token). Procédé de gestion selon l’une quelconque des revendications 1 à 3, dans lequel l’étape de transmission comprend en outre la transmission d’une indication représentative d’un canal véhiculé par le paquet de données (Data) dans lequel ledit jeton (amigos_token) doit être contenu pour déclencher ledit traitement. Procédé de gestion selon l’une quelconque des revendications 1 à 4, dans lequel l’étape de transmission comprend en outre la transmission d’au moins un élément parmi : - un identifiant de service (as_id) connu dudit au moins un réseau ; - un identifiant (ue_id) sélectionné par ledit serveur d’application (AS) pour ledit dispositif de communication (UE) ; et - une information représentative dudit niveau de service (service_level). Procédé de gestion selon l’une quelconque des revendications 1 à 5, comprenant en outre une étape d’envoi d’au moins un paquet de données (Data) relatif audit service audit dispositif de communication (UE) contenant ledit au moins un jeton (amigos_token). Procédé de gestion selon l’une quelconque des revendications 1 à 6 comprenant : - une étape de désactivation dudit jeton (amigos_token) ; et - une étape de notification à au moins une entité (amigos_relay ; Controller) dudit réseau de ladite désactivation. Procédé d’accès, par un dispositif de communication (UE), à un service via au moins un réseau (Network), ledit procédé comprenant : - une étape de réception en provenance d’un serveur d’application (AS) associé audit service d’un jeton (amigos_token) généré pour ledit dispositif de communication (UE) et un accès donné audit service, ledit jeton (amigos_token) étant associé à un niveau de service (service_level) sélectionné pour cet accès audit service, ledit jeton (amigos_token) étant apte à déclencher, lorsqu’il est contenu dans un paquet de données (Data) relatif audit service échangé via ledit au moins un réseau (Network), un traitement de ce paquet de données (Data) correspondant audit niveau de service par au moins une entité (AN, BR) dite de traitement dudit au moins un réseau (Network) ; et - une étape d’envoi à une entité (amigos_relay) dite relais dudit au moins un réseau (Network), d’un message d’annonce (M ad ) d’une utilisation dudit jeton (amigos_token) par le dispositif de communication (UE) lors dudit accès au service, ledit message d’annonce contenant ledit jeton (amigos_token). Procédé d’accès selon la revendication 8 comprenant en outre, suite à une réception d’une confirmation de l’entité relais (Relais amigos) de ladite utilisation, une étape d’insertion du jeton (amigos_token) dans au moins un paquet de données (Data) relatif audit service émis par le dispositif de communication (UE) lors dudit accès donné au service. Procédé de configuration par une entité (amigos_relay) dite relais d’un réseau, ledit procédé comprenant : - une étape de réception, en provenance d’un dispositif de communication (UE), d’un message d’annonce d’une utilisation par le dispositif de communication (UE) lors d’un accès donné au service via ledit réseau d’un jeton (AN, BR) contenu dans ledit message d’annonce (M ad ), ledit jeton (amigos_token) ayant été généré pour ledit dispositif de communication et ledit accès au service, et étant associé à un niveau de service (service_level) sélectionné pour ledit accès au service ; et - si le dispositif de communication (UE) est autorisé à accéder au service, une étape de configuration d’au moins une entité (AN, BR) dite de traitement du réseau pour que ladite entité de traitement (AN, BR) mette en œuvre un traitement correspondant audit niveau de service (service_level) associé audit jeton (amigos_token) lorsque cette entité de traitement (AN, BR) intercepte un paquet de données (Data) relatif au service contenant ledit jeton (amigos_token). Procédé de configuration selon la revendication 10, dans lequel ledit message d’annonce comprenant en outre un identifiant de service (as_id) connu dudit au moins un réseau (Network), ledit identifiant de service étant utilisé par l’entité relais (amigos_relay) pour solliciter ledit serveur d’application (AS) pour déterminer si le dispositif de communication (UE) est autorisé à accéder au service. Procédé de configuration selon la revendication 10 ou 11, dans lequel l’étape de configuration comprend la transmission à ladite au moins une entité de traitement (AN, BR) d’au moins une politique de gestion de trafic correspondant audit niveau de service (service_level) associé au jeton (amigos_token) à appliquer à des paquets de données (Data) relatifs audit service émis par ou destinés audit dispositif de communication (UE). Procédé de configuration selon l’une quelconque des revendications 10 à 12 comprenant : - une étape de réception, en provenance dudit serveur d’application (AS), d’une notification de désactivation dudit jeton (amigos_token) ; et - une étape de mise à jour de la configuration de ladite au moins une entité de traitement (AN, BR) pour désactiver ledit traitement correspondant au niveau de service (service_level) associé au jeton (amigos_token). Procédé de traitement, par une entité (AN, BR) dite de traitement d’un réseau, d’au moins un paquet de données (Data) associé à un service émis par ou destiné à un dispositif de communication (UE), ledit procédé comprenant : - une étape de réception d’un élément d’une configuration activée par une entité (amigos_relay) dite relais du réseau (Network) pour que l’entité du traitement (AN, BR) applique un traitement à au moins un paquet de données (Data) relatif audit service intercepté par l’entité de traitement (AN, BR) et comprenant un jeton (amigos_token) généré pour ledit dispositif de communication (UE) et un accès donné audit service via ledit réseau, ledit jeton (amigos_token) étant associé à un niveau de service (service_level) sélectionné pour cet accès au service, ledit traitement appliqué correspondant audit niveau de service (service_level) ; et - suite à une interception d’un paquet de données (Data) relatif audit service comprenant ledit jeton (amigos_token), une étape d’application sur ledit paquet de données (Data) dudit traitement correspondant audit niveau de service (service_level) associé au jeton (amigos_token). Procédé de traitement selon la revendication 14, dans lequel ledit paquet de données intercepté comprend une indication de marquage correspondant à un niveau de service différent du niveau de service associé (service_level) au jeton (amigos_token). Procédé de traitement selon la revendication 14 ou 15, comprenant, suite à l’étape d’application du traitement sur ledit paquet de données, une étape de retrait dudit jeton (amigos_token) contenu dans le paquet de données . Serveur d’application (AS) comprenant au moins un module configuré pour mettre en œuvre une transmission à un dispositif de communication (UE) d’un jeton (amigos_token) généré pour ledit dispositif de communication et un accès donné à un service via au moins un réseau (Network), ledit jeton (amigos_token) étant associé à un niveau de service (service_level) sélectionné pour cet accès audit service, ledit jeton (amigos_token) étant apte à déclencher, lorsqu’il est contenu dans un paquet de données (Data) relatif audit service échangé via ledit au moins un réseau (Network), un traitement de ce paquet de données (Data) correspondant audit niveau de service (service_level) par au moins une entité (AN, BR) dite de traitement dudit au moins un réseau (Network). Dispositif de communication configuré pour accéder à un service via au moins un réseau (Network), ledit dispositif de communication (UE) comprenant au moins un module configuré pour : - recevoir en provenance d’un serveur d’application (AS) associé audit service un jeton (amigos_token) généré pour ledit dispositif de communication (UE) et un accès donné audit service, ledit jeton (amigos_token) étant associé à un niveau de service (service_level) sélectionné pour cet accès audit service, ledit jeton (amigos_token) étant apte à déclencher, lorsqu’il est contenu dans un paquet de données relatif audit service échangé via ledit au moins un réseau (Network), un traitement de ce paquet de données ) correspondant audit niveau de service par au moins une entité (AN, BR) dite de traitement dudit au moins un réseau (Network) ; et - envoyer à une entité (amigos_relay) dite relais dudit au moins un réseau (Network), d’un message d’annonce d’une utilisation dudit jeton (amigos_token) par le dispositif de communication (UE) lors dudit accès au service, ledit message d’annonce contenant ledit jeton (amigos_token). Entité relais d’un réseau (amigos_relay) comprenant au moins un module configuré pour : - recevoir, en provenance d’un dispositif de communication (UE), un message d’annonce d’une utilisation par le dispositif de communication (UE) lors d’un accès donné à un service via ledit réseau d’un jeton (AN, BR) contenu dans ledit message d’annonce, ledit jeton (amigos_token) ayant été généré pour ledit dispositif de communication et ledit accès au service, et étant associé à un niveau de service (service_level) sélectionné pour ledit accès au service ; et - suite à une autorisation reçue pour le dispositif de communication (UE) en provenance d’un serveur d’application (AS) associé audit service, configurer au moins une entité (AN, BR) dite de traitement du réseau pour que ladite entité de traitement (AN, BR) mette en œuvre un traitement correspondant audit niveau de service (service_level) associé audit jeton (amigos_token) lorsque cette entité de traitement (AN, BR) intercepte un paquet de données (Data) relatif au service contenant ledit jeton (AN, BR). Entité de traitement d’un réseau comprenant au moins un module configuré pour : - réceptionner un élément d’une configuration activée par une entité (amigos_relay) dite relais du réseau (Network) pour que l’entité du traitement (AN, BR) applique un traitement à au moins un paquet de données (Data) relatif à un service intercepté par l’entité de traitement (AN, BR) et comprenant un jeton (amigos_token) généré pour un dispositif de communication (UE) et un accès donné audit service via ledit réseau, ledit jeton (amigos_token) étant associé à un niveau de service (service_level) sélectionné pour cet accès au service, ledit traitement appliqué correspondant audit niveau de service (service_level) ; et - suite à une interception d’un paquet de données (Data) relatif audit service comprenant ledit jeton (amigos_token), appliquer sur ledit paquet de données (Data) ledit traitement correspondant audit niveau de service (service_level) associé au jeton (amigos_token).