FR3130049A1

FR3130049A1 - Procédé d’émission d’un flux de données dans un réseau de communications, procédé de traitement d’un flux de données, procédé de contrôle du traitement d’un flux de données, dispositifs, équipement terminal, entité d’exécution, entité de contrôle, système et programmes d’ordinateur correspondants.

Info

Publication number: FR3130049A1
Application number: FR2113160A
Authority: FR
Inventors: Nicolas Bihannic; Pierre-Alexandre MASSON
Original assignee: Orange SA
Current assignee: Orange SA
Priority date: 2021-12-08
Filing date: 2021-12-08
Publication date: 2023-06-09
Also published as: CN118369901A; WO2023104724A1

Abstract

Procédé d’émission d’un flux de données dans un réseau de communications, procédé de traitement, procédé de contrôle, dispositifs, système et programmes d’ordinateur correspondants L’invention concerne un procédé d’émission d’un flux de données reçu d’un équipement terminal, dans un réseau de communications auquel est connecté ledit équipement terminal, ledit réseau étant découpé en une pluralité de tranches de réseau, ledit procédé comprenant : - la sélection (33) d’une tranche de réseau de ladite pluralité au moins en fonction d’une information comprise dans un en-tête du flux de données, - l’obtention (34) d’un type dudit flux, ledit type appartenant à un groupe comprenant au moins un premier type et un deuxième type de flux, - l’insertion (37) d’un indicateur de priorité (IP) associé au type de flux (STR_ID) dans ledit flux de données, et-l’émission (38) du flux de données comprenant l’indicateur de priorité dans la tranche de réseau sélectionnée. FIGURE 3

Description

Procédé d’émission d’un flux de données dans un réseau de communications, procédé de traitement, procédé de contrôle, dispositifs, système et programmes d’ordinateur correspondants.

1. Domaine de l'invention

L'invention se situe dans le domaine des télécommunications, et notamment dans celui des réseaux de communications structurés en tranches de réseau.

En particulier, l’invention concerne l’émission, le traitement et le contrôle des flux de données acheminés dans une telle tranche de réseau.

Elle s’applique notamment mais non exclusivement à un réseau de télécommunications mobiles dont l’architecture est conforme à la norme 3GPP (pour « Third Generation Partnership Project », en anglais), dans sa version 5G ou dans une version future.

2. Art antérieur et ses inconvénients

La digitalisation des processus industriels contribue à diversifier la nature des données qui transitent sur les réseaux d’un opérateur. Par exemple, l’internet des objets (Internet of ThingsouIoTen anglais) permet la mise en œuvre de nouveaux services comme la maintenance prédictive dans un objectif de recherche d’efficacité opérationnelle. Ces nouveaux services ne sont pas forcément temps-réel mais deviennent de plus en plus importants pour un client.

On connaît par exemple une application métier dite « technicien augmenté » qui permet à un technicien de visualiser des données diverses lui permettant d’enrichir le contexte d’une scène d’intervention. Il s’agit par exemple d’un historique des interventions faites sur une pièce industrielle sélectionnée, ou encore un processus de manipulation de la pièce industrielle sélectionnée. Ce technicien dispose aussi de la possibilité de bénéficier d’une assistance vocale avec un expert distant. On connaît aussi une application métier dite « jumeau numérique » qui permet la remontée d’informations de fonctionnement mesurées par des capteurs connectés vers un système d’informations du client afin de construire une représentation dite virtuelle de l’environnement d’exécution de ces capteurs. Cette application métier permet aussi à un utilisateur situé à proximité de ces capteurs de disposer d’une assistance vocale avec un expert distant en cas de dysfonctionnement ou de besoin de reconfiguration d’un ou plusieurs de ces capteurs. Chacune de ces applications décrites à titre d’exemple met généralement en œuvre des flux de données de natures différentes qui ne sont pas forcément temps-réel mais deviennent de plus en plus importants pour le client et pour les fournisseurs de services.

En dehors de l’IoT, on voit émerger d’autres exemples de services non temps-réel tels que par exemple les mises à jour d’applications professionnelles, les applications de divertissement et de jeu pour le marché grand-public, ou de cartographie pour le secteur de la voiture connectée.

La technologie en tranches de réseau (ounetwork slicingen anglais), notamment introduite dans les spécifications 5G, est prometteuse pour la mise en œuvre de réseaux spécialisés et l’acheminement différencié de données applicatives, notamment pour le support des services IoT qui ont des exigences variées en termes de débit, de disponibilité, ou encore de consommation énergétique. Une tranche de réseau est un sous-réseau défini de manière logicielle (de l’anglais, « Software-Defined Network ») dont le fonctionnement est spécialement configuré pour répondre aux besoins d’un client et/ou d’un terminal et/ou d’une application, et notamment pour mettre en œuvre de nouveaux services. Cette technologie permet donc notamment de répondre aux besoins spécifiques des différents clients de l’opérateur en réservant à chacun d’eux une ou plusieurs tranches de son réseau de communications. Selon la norme 5G du 3GPP, une tranche de réseau se compose de fonctions de réseau physiques et/ou virtuelles PNF/VNF (pour « Physical Network Functions/Virtual Network Functions », en anglais) qui sont interconnectées et peuvent appartenir à la partie accès et/ou à la partie cœur du réseau de communications. La synthèse d'une tranche de réseau sert donc un objectif fonctionnel particulier et, une fois instanciée, elle est utilisée pour soutenir certains services de communication pour un client dit « vertical » dédié (ex. une entreprise, une offre de service, etc.) en lui assurant une garantie de qualité de service donnée. Chaque tranche de réseau peut avoir sa propre architecture, sa propre gestion des opérations FCAPS (pour « Fault-management, Configuration, Accounting, Performance, and Security », en anglais)et sa propre sécurité correspondant à un cas d’usage particulier.

L’état de l’art dans la spécification des tranches de réseau permet de sélectionner une tranche de réseau pour une application client donnée, selon un mécanisme mis en œuvre via les règles URSP pour «User Equipment Route Selection Policies” définies dans les spécifications [3GPP TS 24.526] et [3GPP TS 23.503]. Plusieurs attributs peuvent être utilisés pour aiguiller les flux de données (ou «data flow» en anglais) issus d’une application client donnée vers la tranche de réseau correspondante :
- l’identifiant de l’application «Application ID», le FQDN (Fully Qualified Domain Name), le triplet «IP address, port number, protocol ID», le DNN (Data Network Name).

Par exemple, comme illustré par la , une application de technicien augmenté API_TA met en œuvre trois flux de données de natures différentes, comprenant :
- un type de flux STR_1 de données voix sur IP ou VoIP (de l’anglais, « Voice over IP ») ;
- un type de flux STR_2 de données de streaming vidéo ;
- un type de flux STR_3 de données enrichies.

A titre d’autre exemple, une application de jumeau numérique API_JN met en œuvre deux flux de natures différentes, comprenant :
- un type de flux STR_1’ de données voix sur IP ou VoIP ;
- un type de flux STR_2’ de données de capteurs.

Cependant, le mécanisme d’aiguillage via les règles URSP est essentiellement statique. Il ne permet pas de configurer dynamiquement, ni de contrôler une priorité d’acheminement d’un flux de données par rapport à un autre flux de données d’une même application client dont les flux de données sont acheminés dans une tranche de réseau spécifique. Pourtant, on comprend que le client aimerait pouvoir associer dynamiquement des priorités différentes à ces différents flux de sorte que les flux de type STR_1 soient traités de façon très prioritaire et acheminés en temps réel, les flux de type STR_2 soient acheminés avec une priorité standard et les flux de données de type STR_3 soient acheminés avec une priorité basse.

On connaît aussi une politique de gestion de la qualité de service basée sur une spécification 5QI définie par le 3GPP dans la spécification [3GPP TS 23.501 – section 5.7.3.1] et qui s’applique au niveau des paquets de données traités par un réseau de communication conforme à la norme 3GPP. Selon cette spécification, l’acheminement de paquets de données dans une tranche de réseau doit respecter plusieurs critères parmi lesquels :
-un critère de ressources (de l’anglais, « resource type ») qui précise si le débit doit être garanti,
- un critère de niveau de priorité (de l’anglais, « priority level ») qui précise le niveau de priorité du paquet,
- un critère de délai de transfert (de l’anglais, « Packet Delay Budget ») qui précise le délai de transfert de bout-en-bout autorisé (incluant les segments radio et cœur de réseau),
- un critère de taux d’erreur (de l’anglais, « Packet Error Rate ») qui précise le taux d’erreur dans la transmission du paquet,
-un critère de fenêtre moyenne (de l’anglais, « Averaging window ») qui précise la durée de maintien en mémoire du paquet au niveau d’un équipement du plan de transfert du réseau,
- un critère de volume maximal de volume de données en rafale (de l’anglais), « Maximum Data Burst Volume ») qui caractérise la nature du volume de données.

Le critère de priorité du paquet de données de l’indicateur 5QI est configuré pour prendre une vingtaine de valeurs figées associées à des types de paquets standardisés, par exemple, un paquet de type voix conversationnelle (de l’anglais, « conversational voice ») ou un paquet de type vidéo conversationnelle (de l’anglais, « conversational video »).

Un inconvénient de ce mécanisme de priorisation des paquets de données dans une tranche de réseau est qu’il ne permet pas de s’adapter aux besoins spécifiques d’un client qui voudrait définir de façon dynamique ses propres niveaux de priorité pour ses propres types de flux de données en fonction de l’application visée et éventuellement faire évoluer leurs niveaux de priorités respectifs selon la situation réelle (nominale ou alarme par exemple).

L’invention vient améliorer la situation.

3. Présentation de l’invention

L’invention répond à ce besoin en proposant un procédé d’émission d’un flux de données reçu d’une application logicielle s’exécutant sur un équipement terminal, dans un réseau de communications auquel est connecté ledit équipement terminal, ledit réseau étant découpé en une pluralité de tranches de réseau, caractérisé en ce que ledit procédé est mis en œuvre au niveau dudit équipement terminal et comprend
- la sélection d’une tranche de réseau de ladite pluralité au moins en fonction d’une information comprise dans un en-tête du flux de données,
- l’obtention d’un type dudit flux, ledit type appartenant à un groupe comprenant au moins un premier type et un deuxième type de flux, et
- l’insertion d’un indicateur de priorité associé au type de flux dans le flux de données, l’indicateur de priorité appartenant à un groupe comprenant au moins un premier indicateur associé au premier type de flux et un deuxième indicateur associé au deuxième type de flux, le premier indicateur et le deuxième indicateur de priorité ayant des valeurs distinctes ;
-l’émission du flux de données comprenant l’indicateur de priorité dans la tranche de réseau sélectionnée.

L’invention repose sur une approche tout-à-fait nouvelle et inventive qui consiste à insérer un indicateur de priorité dans un flux de données émis par une application d’un client éligible pour être acheminée via une tranche de réseau donnée. Cet indicateur de priorité est par exemple inséré dans un en-tête ou dans la partie utile du flux de données. Il est destiné à être détecté par une ou plusieurs entités du réseau en charge de traiter l’acheminement du flux de données dans la tranche de réseau et à être utilisé pour décider comment traiter le flux de données en fonction des ressources réseau disponibles et en particulier s’il peut être acheminé ou non par la tranche de réseau sélectionnée. Avec l’invention, il est ainsi possible de prioriser les flux de données émis par une application logicielle s’exécutant sur l’équipement terminal dans une tranche de réseau particulière. Cette tranche de réseau peut être dédiée ou non à l’application logicielle. S’il s’agit d’une application logicielle d’un client, la tranche de réseau peut être dédiée à cette application ou à plusieurs applications de ce client ou encore à l’ensemble des flux émis par ce client en général. L’invention permet alors au client d’affecter le niveau de priorité souhaité à chacun des types de flux applicatifs mis en œuvre dans sa ou ses applications logicielles. Par application logicielle, on entend ici une application métier associée par exemple à un client, cette application métier comprenant différents flux (voix, données, streaming, gestion…) requérant des priorités différentes selon leurs besoins.

Si l’application logicielle est configurée pour mettre en œuvre un service spécifique d’un opérateur, comme par exemple le service « Voix sur IP », la tranche de réseau en question peut être réservée à l’acheminement des flux de l’application Voix sur IP émis par cette application logicielle, quel que soit l’équipement terminal ou le client utilisant cet équipement terminal. Dans ce cas, l’opérateur configure avantageusement différents types de flux de Voix sur IP par exemple en fonction d’un niveau de qualité de service auquel chaque client accède en lien avec l’abonnement auquel il a souscrit. Dans ce cas-là, l’application logicielle est une application, par exemple de type VoIP, et les priorités sont associées par exemple à des clients ayant par exemple des contrats distincts et donc des priorités différentes pour l’application logicielle de Voix sur IP. Ainsi différents paramètres de l’en-tête du flux de données peuvent être utilisées distinctement ou en combinaison parmi lesquels un identifiant de l’application logicielle, tel que l’identifiant du protocole utilisé (par exemple le protocole RTP – Real Time Protocol), l’adresse IP de l’émetteur voire l’adresse IP du destinataire.

La tranche de réseau peut enfin être configurée par l’opérateur pour regrouper les flux de données émis par les applications logicielles de plusieurs clients distincts, qui ont par exemple des exigences communes en termes de disponibilité ou d’isolation des flux de données, etc. Dans ce cas, l’opérateur peut définir plusieurs types de flux de données et des valeurs d’indicateurs de priorité associés de façon commune à tous les clients qui partagent la tranche de réseau.

Un autre avantage de l’invention est qu’elle permet de sélectionner la tranche de réseau à utiliser pour un flux de données au niveau de l’équipement terminal, plutôt qu’au niveau d’un équipement du réseau de communications proprement dit. La charge est ainsi déplacée du réseau vers le terminal. En outre, du fait que l’équipement terminal n’a que ses propres flux de données à gérer, cette sélection est plus simple à mettre en œuvre et répond mieux aux contraintes de passage à l’échelle (de l’anglais, « scalability »). En effet, grâce à la mise en œuvre de tranches de réseau sur les terminaux, il est possible d’associer des flux de données du terminal à des tranches distinctes, ce qui est plus difficile à mettre en œuvre lorsque la tranche de réseau est instanciée sur un équipement du réseau d’opérateur où les flux sont plus nombreux et en outre potentiellement chiffrés, rendant impossible l’exploitation de données d’en-tête. En outre, le client possédant le terminal peut lui-même gérer les tranches alors qu’il n’aura pas la possibilité lors d’une instanciation sur un équipement du réseau, comme cela peut être le cas lors de mise en œuvre du réseau privé virtuel (en anglais VPN – Virtual Private Network), l’architecture en tranche de réseau proposant en outre des capacités d’isolation des flux plus importante que les réseaux privés virtuels notamment.

Selon un aspect de l’invention, le procédé comprend en outre :
- la réception préalable d’au moins une règle d’acheminement d’un flux de données émis par ladite application logicielle, ladite règle comprenant au moins un identifiant de ladite application logicielle, ledit type de flux, ledit indicateur de priorité associé audit type de flux et un identifiant d’une dite tranche de réseau;
- le stockage en mémoire de ladite au moins une règle d’acheminement et
- l’application de ladite au moins une règle d’acheminement lors de la mise en œuvre de ladite sélection et de ladite insertion .

Avantageusement, cette priorisation des flux de données émis par l’application logicielle est mise en œuvre par l’installation préalable de règles définissant la valeur de l’indicateur de priorité à insérer dans le flux de données en plus de la tranche de réseau à utiliser.

Par exemple, dans une architecture 5G, la tranche de réseau est identifiée par un paramètre S-NSSAI. On note que le réseau d’accès mobile 5G garde un contexte des tranches de réseau pour lesquelles le terminal s’est préalablement enregistré et qu’il n’est pas nécessaire d’insérer ce champ d’informations dans un en-tête du flux de données.

Si l’application logicielle est une application d’un client, c’est le client qui peut définir ses propres types de flux et les valeurs d’indicateur de priorité qu’il associe à chacun d’eux. Si l’application logicielle met en œuvre un service de l’opérateur, comme par exemple un service de voix sur IP, alors c’est l’opérateur qui définit les types de flux de données, par exemple par type de client ou de niveau d’abonnement et leur associe une valeur d’indicateur de priorité.

Selon un autre aspect de l’invention, le procédé comprend en outre l’obtention d’un mode opératoire de ladite application logicielle, ledit mode opératoire appartenant à un groupe comprenant au moins un premier mode opératoire et un deuxième mode opératoire, et ladite au moins une règle d’acheminement est associée audit mode opératoire.

Un avantage est que les règles de priorisation des flux de données les uns par rapport aux autres peuvent être modifiés en fonction d’un mode opératoire courant de l’application.

Par exemple, lorsque l’application logicielle est celle d’un client, ces modes opératoires sont préalablement définis par le client et comprennent au moins un premier mode dit « nominal » et un deuxième mode dit « alarme » et des règles de traitement spécifiques des flux de données sont associées à chacun de ces modes. Ils peuvent comprendre en outre un troisième mode de type « Reporting Priorisé » qui, contrairement au mode alarme, peut être planifié, voir récurrent sur une plage horaire donnée. Un tel mode opératoire peut être avantageusement mis en œuvre dans tous les secteurs d’activité pour le suivi de performance opérationnelle.

Par exemple, pour une application de « jumeau numérique », un flux de données de type « données de capteur » est associé à une valeur minimale à moyenne de l’indicateur de priorité en mode opératoire « nominal », mais à une valeur maximale de l’indicateur de priorité en mode opératoire « alarme ». En effet, ces données de capteur sont utiles pour gérer une crise et doivent être reçues en temps réel avec une priorité maximale dans le mode « alarme ».

On comprend donc qu’un mode opératoire courant, par exemple correspondant à une situation nominale peut être défini de façon préalable au niveau du terminal de l’utilisateur qui va appliquer les règles d’acheminement associées à ce mode opératoire, mais qu’il peut être modifié au cours du temps par notification d’une entité du client connectée au réseau. Sur réception d’une notification de changement du mode opératoire, par exemple de passage à un mode opératoire de type alarme, le terminal de l’utilisateur va mettre en application les règles d’acheminement associées à ce nouveau mode opératoire pour les futurs flux de données émis par l’application logicielle dans la tranche de réseau.

L’invention concerne également un dispositif d’émission d’un flux de données par une application logicielle s’exécutant sur un équipement terminal, dans un réseau de communications auquel est connecté ledit terminal, ledit réseau étant découpé en une pluralité de tranches de réseau. Ledit dispositif est configuré pour mettre en œuvre au niveau de l’équipement terminal :
- la sélection d’une tranche de réseau de ladite pluralité au moins en fonction d’une information comprise dans un en-tête du flux de données ;
- l’obtention d’un type dudit flux, ledit type appartenant à un groupe comprenant au moins un premier type et un deuxième type de flux), et
- l’insertion d’un indicateur de priorité associé au type de flux dans le flux de données, l’indicateur de priorité appartenant à un groupe comprenant au moins un premier indicateur associé au premier type de flux et un deuxième indicateur associé au deuxième type de flux, le premier indicateur et le deuxième indicateur de priorité ayant des valeurs distinctes ; et
-l’émission du flux de données comprenant ledit indicateur de priorité, dans la tranche de réseau sélectionnée.

Avantageusement, ledit dispositif configuré pour mettre en œuvre les étapes du procédé d’émission tel que décrit précédemment.

Avantageusement, ledit dispositif est intégré dans un équipement terminal connecté au réseau de communications, tel qu’un terminal utilisateur ou un objet connecté.

Avantageusement, ledit équipement terminal est compris dans un système de contrôle de flux de données acheminés dans un réseau de communications.

Le système, l’équipement terminal et le dispositif d’émission présentent au moins les mêmes avantages que ceux conférés par le procédé d’émission précité.

Corrélativement, l’invention concerne aussi un procédé de traitement d’un flux de données dans un réseau de communications, ledit réseau étant découpé en une pluralité de tranches de réseau, ledit flux de données ayant été reçu dans unedite tranche de réseau de ladite pluralité en provenance d’une application logicielle s’exécutant sur un équipement terminal connecté à audit réseau. Ledit procédé est mis en œuvre par une entité d’exécution du réseau et comprend :
- la détection d’un indicateur de priorité dudit flux dans un ledit flux de données ;
- l’évaluation d’un niveau de ressources disponibles dans la tranche de réseau ;
- l’exécution d’au moins une action de traitement dudit flux de données au moins en fonction dudit indicateur de priorité et du niveau de ressources réseau disponibles dans ladite tranche de réseau, ladite action de traitement appartenant à un groupe comprenant au moins une première action de laisser-passer du flux de données dans ladite tranche de réseau, lorsque le niveau de ressources disponibles est suffisant pour acheminer le flux de données selon l’indicateur de priorité, et une deuxième action de blocage du flux de données dans ladite tranche de réseau, destinée à être mise en œuvre lorsque le niveau de ressources réseau disponibles est insuffisant.

L’invention repose sur une approche tout-à-fait nouvelle et inventive du traitement d’un flux de données reçu d’une application client par une entité d’exécution du réseau de communications, qui consiste à détecter un indicateur de priorité du flux dans un en-tête de ce flux et à l’utiliser pour décider, en fonction d’un niveau de ressources disponibles par rapport à un niveau de ressources requis pour acheminer le flux de données avec le niveau de priorité qui lui est associé, si ce flux peut être acheminé dans la tranche de réseau vers sa destination ou s’il doit être rejeté.

Bien sûr, l’invention ne se limite pas aux deux actions de laisser -passer et de blocage qui viennent d’être énoncées. D’autres actions peuvent être décidées notamment lorsque le niveau de ressources évalué est insuffisant pour acheminer le flux de données dans les conditions associées au niveau de priorité. Par exemple, d’autres actions possibles seraient de différer l’acheminement du flux de données pour laisser-passer d’autres flux de données plus prioritaires, d’écrêter le flux avant de le transmettre pour qu’il nécessite moins de ressources, de ralentir ou d’accélérer l’acheminement du flux de données en lui affectant moins ou plus de ressources selon son niveau de priorité, etc.

Selon un aspect de l’invention, le procédé comprend l’obtention préalable d’au moins une règle de traitement d’un flux de données reçu de ladite application logicielle, ladite règle comprenant ledit indicateur de priorité d’un flux de données, ledit identifiant de tranche de réseau et ladite au moins une action de traitement dudit flux, et l’extraction de l’action de traitement de ladite règle.

Pour décider de l’action à exécuter, l’équipement nœud met en application des règles de traitement qu’il a préalablement reçues et stockées. Un avantage est qu’il est capable de traiter le flux de données entrant sans délai. Ce mode de réalisation est adapté à la mise en œuvre de règles simples.

Selon un autre aspect de l’invention, lorsqu’aucune règle de traitement n’a été préalablement obtenue pour traiter ledit flux de données, ledit procédé comprend en outre la notification dudit indicateur de priorité à une entité de contrôle dudit réseau et la réception, en provenance de ladite entité de contrôle, de ladite au moins une action de traitement à exécuter.

Selon au moins un autre mode de réalisation de l’invention, l’entité d’exécution ne dispose pas à son niveau de règles de traitement des flux de données qu’il reçoit en provenance de l’application client. La règle de base qu’il applique est celle de notifier une entité de contrôle qui lui répond par la ou les actions de traitement à exécuter au cas par cas. Ce mode de réalisation est adapté à la mise en œuvre de règles plus complexes. L’intelligence du réseau est concentrée au niveau de la ou des entités de contrôle.

Selon encore un autre aspect de l’invention, l’entité d’exécution étant configurée pour gérer la tranche de réseau et au moins une autre tranche de réseau dudit réseau de communications, lorsque l’action de traitement est la deuxième action de blocage du flux de données dans la tranche de réseau, le procédé comprend, préalablement à l’exécution de la deuxième action de traitement :
- l’évaluation d’un niveau de ressources dans l’autre tranche de réseau ;
- la décision d’au moins une troisième action de traitement, dite action de transfert du flux de données dans l’autre tranche de réseau, en fonction dudit niveau de ressources et de l’indicateur de priorité.

Un avantage est de donner à certains flux de données, par exemple les plus prioritaires une chance supplémentaire d’être acheminés dans le réseau de communications, lorsque la tranche de réseau dans laquelle ils sont est à court de ressources et lorsqu’il existe une autre tranche de réseau avec un niveau de ressources disponibles suffisant pour acheminer le flux de données dans les conditions correspondant à son niveau de priorité associé.

L’invention concerne également un dispositif de traitement d’un flux de données dans un réseau de communications, ledit réseau étant découpé en une pluralité de tranches de réseau, ledit flux de données ayant été reçu dans unedite tranche de réseau de ladite pluralité, en provenance d’une application logicielle s’exécutant sur un équipement terminal (UE, IoT) connecté à audit réseau. Ledit dispositif est configuré pour mettre en œuvre au niveau d’une entité d’exécution du réseau :
- la détection d’un indicateur de priorité dudit flux dans ledit flux de données ;
- l’évaluation d’un niveau de ressources disponibles dans la tranche de réseau ;
- l’exécution d’au moins une action de traitement dudit flux de données au moins en fonction dudit indicateur de priorité et du niveau de ressources réseau disponibles dans ladite tranche de réseau, ladite action de traitement appartenant à un groupe comprenant au moins une première action de laisser-passer du flux de données dans ladite tranche de réseau, lorsque le niveau de ressources disponibles est suffisant et une deuxième action de blocage du flux de données dans ladite tranche de réseau, destinée à être mise en œuvre lorsque le niveau de ressources réseau disponibles est insuffisant.

Avantageusement, ledit dispositif configuré pour mettre en œuvre les étapes du procédé de traitement tel que décrit précédemment.

Avantageusement, ledit dispositif est intégré dans une entité d’exécution du réseau de communications, comprise par exemple dans le plan de transfert de ce réseau.

Avantageusement, ladite entité d’exécution est comprise dans le système de contrôle de flux de données acheminés dans un réseau de communications.

Le système, l’entité d’exécution et le dispositif de traitement présentent au moins les mêmes avantages que ceux conférés par le procédé de traitement précité.

Corrélativement, l’invention concerne aussi un procédé de contrôle du traitement d’un flux de données dans un réseau de communications, ledit réseau de communications étant découpé en une pluralité de tranches de réseau, ledit flux de données ayant été émis par un équipement terminal et reçu par une entité d’exécution dudit réseau dans une tranche de réseau de ladite pluralité. Ledit procédé est mis en œuvre par une entité de contrôle dudit réseau, ladite entité de contrôle étant configurée pour contrôler la mise en œuvre d’une politique de traitement des flux de données acheminés dans ledit réseau et ledit procédé comprend :
- la réception en provenance de l’entité d’exécution d’une notification d’un indicateur de priorité associé audit flux de données reçu ;
- l’obtention d’un niveau de ressources disponibles dans la tranche de réseau ;
- la décision d’au moins une action de traitement dudit flux au moins en fonction de l’indicateur de priorité reçu et du niveau de ressources disponibles, ladite action de traitement appartenant à un groupe comprenant au moins une première action de laisser-passer du flux de données dans ladite tranche de réseau destinée à être mise en œuvre lorsque le niveau de ressources réseau disponibles est suffisant et une deuxième action de blocage du flux de données dans ladite tranche de réseau destinée à être mise en œuvre lorsque le niveau de ressources réseau disponibles est insuffisant ; et
- l’envoi d’une réponse à ladite entité d’exécution, ladite réponse comprenant ladite action de traitement.

Selon un mode de réalisation de l’invention, l’entité de contrôle applique elle-même les règles de traitement des flux de données reçus de l’application logicielle du client par l’entité d’exécution, sur notification de l’entité d’exécution et envoie l’action de traitement à exécuter à cette entité d’exécution. De la sorte, elle contrôle le traitement de tous les flux de données émis par l’application client dans la tranche de réseau et l’intelligence de décision est concentrée au niveau du plan de contrôle.

Selon un aspect de l’invention, lorsque l’action de traitement décidée est l’action de blocage dudit flux de données dans la tranche de réseau et lorsque l’entité d’exécution est configurée pour gérer une autre tranche de réseau de ladite pluralité, ledit procédé comprend, préalablement à la transmission de la deuxième action de traitement à l’entité d’exécution:
- l’obtention d’un niveau de ressources disponibles dans l’autre tranche de réseau;
- la décision d’au moins une troisième action de traitement, dite action de transfert du flux de données dans l’autre tranche de réseau, en fonction dudit niveau de ressources et de l’indicateur de priorité.

Avantageusement, un mode repli est mis en œuvre pour les flux de données les plus prioritaires qui n’ont pas pu être acheminés dans la tranche de réseau initialement prévue. Si une autre tranche de réseau à laquelle le client est éligible dispose de ressources réseau suffisantes pour acheminer le flux de données dans les conditions de son niveau de priorité, alors l’entité de contrôle peut décider, de transférer le flux de données vers une autre tranche du réseau à laquelle l’application client est éligible.

L’invention concerne également un dispositif de contrôle du traitement d’un flux de données dans un réseau de communications, ledit réseau de communications étant découpé en une pluralité de tranches de réseau, ledit flux de données ayant été émis par un équipement terminal et reçu par une entité d’exécution dudit réseau dans une tranche de réseau de ladite pluralité. Ledit dispositif est configuré pour mettre en œuvre au niveau d’une entité de contrôle dudit réseau, ladite entité de contrôle étant configurée pour contrôler la mise en œuvre d’une politique de traitement des flux de données acheminés dans ledit réseau:
- la réception en provenance de l’entité d’exécution d’une notification d’un indicateur de priorité associé audit flux de données reçu ;
- l’obtention d’un niveau de ressources disponibles dans la tranche de réseau ;
- la décision d’au moins une action de traitement dudit flux au moins en fonction de l’indicateur de priorité reçu et du niveau de ressources disponibles, ladite action de traitement appartenant à un groupe comprenant au moins une première action de laisser-passer du flux de données dans ladite tranche de réseau destinée à être mise en œuvre lorsque le niveau de ressources réseau disponibles est suffisant pour acheminer ledit flux de données selon l’indicateur de priorité et une deuxième action de blocage du flux de données dans ladite tranche de réseau destinée à être mise en œuvre lorsque le niveau de ressources réseau disponibles est insuffisant ; et
- l’envoi d’une réponse à ladite entité d’exécution, ladite réponse comprenant ladite action de traitement.

Avantageusement, ledit dispositif configuré pour mettre en œuvre les étapes du procédé de contrôle tel que décrit précédemment.

Avantageusement, ledit dispositif est intégré dans une entité de contrôle du réseau de communications, comprise par exemple dans le plan de contrôle de ce réseau.

Avantageusement, ladite entité de contrôle est comprise dans le système de contrôle de flux de données acheminés dans un réseau de communications.

Le système, l’entité de contrôle et le dispositif de contrôle présentent au moins les mêmes avantages que ceux conférés par le procédé de contrôle précité.

Alternativement, l’invention concerne enfin un système de contrôle de flux de données acheminés dans un réseau de communications comprenant le dispositif d’émission précité, le dispositif de traitement précité et le dispositif de contrôle précité.

Avantageusement, le système de contrôle selon l’invention comprend aussi une entité de gestion de règles, configurée pour définir des règles d’acheminement, de traitement et de contrôle des flux de données émis par une application logicielle dans une tranche du réseau, et pour les transmettre aux dispositifs d’émission, de traitement et de contrôle selon l’invention.

L’invention concerne également des produits programmes d'ordinateur comprenant des instructions de code de programme pour la mise en œuvre respective des procédés d’émission, de traitement et de contrôle tels que décrit précédemment, lorsqu’il est exécuté par un processeur.

Un programme peut utiliser n’importe quel langage de programmation, et être sous la forme de code source, code objet, ou de code intermédiaire entre code source et code objet, tel que dans une forme partiellement compilée, ou dans n’importe quelle autre forme souhaitable.

L’invention vise également au moins 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 des procédés selon l’invention tel que décrits ci-dessus.

Un tel support d'enregistrement peut être n'importe quelle entité ou dispositif capable de stocker le programme. Par exemple, le support peut comporter un moyen de stockage, tel qu'une ROM, par exemple un CD ROM ou une ROM de circuit microélectronique, ou encore un moyen d'enregistrement magnétique, par exemple un support mobile (carte mémoire) ou un disque dur ou un SSD.

D'autre part, un tel support d'enregistrement peut être un support transmissible tel qu'un signal électrique ou optique, qui peut être acheminé via un câble électrique ou optique, par radio ou par d'autres moyens, de sorte que le programme d’ordinateur qu’il contient est exécutable à distance. Les programmes selon l'invention peuvent être en particulier téléchargés sur un réseau par exemple le réseau Internet.

Alternativement, le ou les supports d'enregistrement peuvent être un ou des circuits intégrés dans lesquels chaque programme est incorporé, le ou les circuits étant adaptés pour exécuter ou pour être utilisé dans l'exécution du ou des procédés précités.

Selon un exemple de réalisation, la présente technique est mise en œuvre au moyen de composants logiciels et/ou matériels. Dans cette optique, le terme "module" peut correspondre dans ce document aussi bien à un composant logiciel, qu'à un composant matériel ou à un ensemble de composants matériels et logiciels.

Un composant logiciel correspond à un ou plusieurs programmes d'ordinateur, un ou plusieurs sous-programmes d'un programme, ou de manière plus générale à tout élément d'un programme ou d'un logiciel apte à mettre en œuvre une fonction ou un ensemble de fonctions, selon ce qui est décrit ci-dessous pour le module concerné. Un tel composant logiciel est exécuté par un processeur de données d'une entité physique (terminal, serveur, passerelle, set-top-box, routeur, etc.) et est susceptible d'accéder aux ressources matérielles de cette entité physique (mémoires, supports d'enregistrement, bus de communication, cartes électroniques d'entrées/sorties, interfaces utilisateur, etc.). Par la suite, on entend par ressources tous ensembles d’éléments matériels et/ou logiciels support d’une fonction ou d’un service, qu’ils soient unitaires ou combinés.

De la même manière, un composant matériel correspond à tout élément d'un ensemble matériel (ou hardware) apte à mettre en œuvre une fonction ou un ensemble de fonctions, selon ce qui est décrit ci-dessous pour le module concerné. Il peut s'agir d'un composant matériel programmable ou avec processeur intégré pour l'exécution de logiciel, par exemple un circuit intégré, une carte à puce, une carte à mémoire, une carte électronique pour l'exécution d'un micrologiciel (« firmware » en anglais), etc.

Chaque composante du système précédemment décrit met bien entendu en œuvre ses propres modules logiciels.

Les différents modes de réalisation mentionnés ci-dessus sont combinables entre eux pour la mise en œuvre de la présente technique.

4. Brève description des figures

D'autres buts, caractéristiques et avantages de l'invention apparaîtront plus clairement à la lecture de la description suivante, donnée à titre de simple exemple illustratif, et non limitatif, en relation avec les figures, parmi lesquelles :

: la illustre de façon schématique des exemples de types de flux de données mis en œuvre dans des applications clients et destinés à être acheminés dans une tranche d’un réseau de communications ;

: la illustre de façon schématique un exemple d’architecture d’un système de contrôle de flux de données émis dans un réseau de communications selon un mode de réalisation de l’invention ;

:la décrit sous forme d’un logigramme les étapes d’un procédé d’émission d’un flux de données dans une tranche d’un réseau de communications, selon un exemple de réalisation de l’invention ;

: la décrit sous forme d’un logigramme les étapes d’un procédé de traitement d’un flux de données émis dans une tranche d’un réseau de communications, selon un exemple de réalisation de l’invention ;

: la détaille l’obtention d’une action de traitement du flux de données selon un premier mode de réalisation de l’invention ;

: la détaille l’obtention d’une action de traitement du flux de données selon un deuxième mode de réalisation de l’invention ;

:la décrit sous forme d’un logigramme les étapes d’un procédé de contrôle du traitement d’un flux de données émis dans une tranche d’un réseau de communications, selon un exemple de réalisation de l’invention ;

:la illustre de façon schématique le traitement d’un flux de données émis dans une tranche de réseau par une entité d’exécution du plan de transfert d’un réseau de communications selon un mode de réalisation de l’invention ;

: la illustre de façon schématique un exemple d’architecture d’un réseau de communications, comprenant une pluralité d’entités d’exécution configurées pour traiter l’acheminement d’un flux de données émis par un équipement terminal dans au moins une tranche du réseau de communication, une pluralité d’entités de contrôle configurées pour contrôler le traitement de ce flux par les entités d’exécution et une pluralité d’entités de gestion configurées pour envoyer des règles de traitement et de contrôle à ces pluralités d’entités selon un mode de réalisation de l’invention ;

: la décrit un exemple de structure matérielle d’un dispositif d’émission d’un flux de données dans une tranche d’un réseau de communications selon l’invention ;

: la décrit un exemple de structure matérielle d’un dispositif de traitement d’un flux de données émis dans une tranche d’un réseau de communications selon l’invention ;

: la décrit un exemple de structure matérielle d’un dispositif de contrôle du traitement d’un flux de données dans une tranche d’un réseau de communications selon l’invention.

5. Description détaillée de l'invention

L’invention concerne un réseau de communications structuré en une pluralité de tranches de réseau. Le principe général de l’invention repose sur l’insertion d’un indicateur de priorité dans un flux de données émis par une application logicielle s’exécutant sur un équipement terminal connecté au réseau de communications, avant son émission dans le réseau de communications de cet opérateur, et sur l’utilisation de cet indicateur pour traiter l’acheminement de ce flux de données dans une tranche de réseau particulière du réseau de communications. Cette tranche de réseau peut être dédiée à ce client afin de lui permettre d’acheminer les flux de données générés par une ou plusieurs de ses propres applications logicielles, ou applications métier, ou au contraire partagée entre plusieurs clients de l’opérateur pour acheminer les flux de données issus de différentes applications logicielles de ces clients, ou encore être dédié à la mise en œuvre d’un service particulier de l’opérateur, comme par exemple un service de voix sur IP.

Dans le réseau de communications, l’indicateur de priorité est détecté par une entité d’exécution d’un plan de transfert du réseau de l’opérateur et exploité pour décider, en fonction d’un niveau de ressources disponibles dans la tranche de réseau au niveau de cette entité d’exécution et des besoins en ressources correspondant à ce niveau de priorité, si le flux de données va pouvoir ou non être acheminé dans cette tranche de réseau.

Avantageusement, la valeur de l’indicateur de priorité associée à chaque type de flux de données émis par l’application logicielle est préalablement définie en fonction des besoins de l’application logicielle. En particulier, dans le cas d’une application métier d’un client, le client définit ses propres types de flux et leur niveau de priorité associé. La valeur de l’indicateur de priorité peut évoluer au cours du temps, notamment suite à un changement de mode opératoire de l’application logicielle.

L’invention permet ainsi d’adapter plus finalement la technologie de tranches de réseau aux besoins accrus des clients et à la diversité des flux de données relatifs à un ou plusieurs de ces clients.

Dans le cas où l’application logicielle considérée met en œuvre un service de l’opérateur, l’invention permet à l’opérateur de mettre en application sa politique de qualité de service différenciée au sein d’une tranche de réseau.

L’invention permet aussi à l’opérateur de regrouper au sein d’une même tranche de réseau les applications de différents clients qui partagent des exigences communes et de leur appliquer une même stratégie d’affectation des ressources de la tranche de réseau. Il s’agit notamment d’exigences en termes de disponibilité des flux de données que les applications émettent (temps réel, non temps réel) ou en termes d’isolation, c’est-à-dire de niveau de protection contre des perturbations type congestion ou attaques potentielles du réseau de communications).

L’invention trouve une application toute particulière dans un réseau de communications mobiles dont l’architecture est conforme à la norme 5G du 3GPP et permet une structuration de ce réseau en tranches. Bien sûr, l’invention n’est pas limitée à cet exemple et s’étend à toute autre architecture de réseau de communications mettant en œuvre une technologie permettant, comme les règles URSP pour les équipements terminaux 3GPP, de discriminer les flux de données issus d’une application logicielle.

Dans la suite, on désigne par cette notion d’indicateur de priorité une valeur, par exemple entière, comprise dans un intervalle de valeurs possibles. Avantageusement, cet intervalle comprend un faible nombre de valeurs, par exemple égal au nombre de types de flux de données distincts pour la ou les applications logicielles associées à la tranche de réseau considérée.

Dans la suite on désigne par ressource réseau d’une tranche de réseau aussi bien des ressources matérielles que des ressources logicielles au niveau du réseau cœur que d’un réseau d’accès, par exemple d’un réseau d’accès radio mobile RAN (de l’anglais, « Radio Access Network ») du réseau de communication.

Cette notion de ressource englobe l’équipement d’accès ou l’équipement nœud lui-même, d’autres ressources de cet équipement, comme un module de modulation de données, un module d’allocation d’intervalles de temps pour la transmission de données, un module de gestion de la qualité de service associée aux différents types de données transmises (voix, IoT (de l’anglais, « Internet of Things »), vidéo, etc). Pour une station de base d’un réseau d’accès cellulaire par exemple, il s’agit par exemple de composants particuliers de cette antenne radio, tels que des unités de ressources PRB (de l’anglais, « Physical Ressource Block »), des modules de modulation, d’allocation d’intervalles de temps pour la transmission de données, de gestion de la qualité de service QoS (de l’anglais, « Quality of Service ») pour les différents types de données transmises, etc. La disponibilité de ces ressources est évaluée à partir d’informations de trafic de données relatives à une bande-passante, à un débit de données, à un volume de données, à un nombre d’unités de ressources fréquentielles ou PRB (de l’anglais, « Physical Resource Blocks »), etc, déjà alloués ou au contraire disponibles, au niveau d’un équipement d’accès mobile tel qu’une station de base ou d’un équipement nœud d’un plan de transfert (ou « user plane », en anglais) du cœur de réseau.

La illustre de façon schématique un exemple d’architecture d’un système S pour le contrôle d’un flux de données émis par une application logicielle s’exécutant sur un équipement terminal dans un réseau de communications RC d’un opérateur, découpé en une pluralité de tranches de réseau, selon un mode de réalisation de l’invention.

On désigne ici par équipement terminal aussi bien un terminal utilisateur, tel qu’un téléphone mobile, de type téléphone intelligent (de l’anglais, « smartphone »), un ordinateur portable, une tablette, une montre connectée, etc qu’un objet connecté de type IoT, comme par exemple un capteur de mesures de données de température, de vibration, etc ou encore un robot autonome comme un AGV (de l’anglais, « Automated Guided Vehicle »), par exemple installé dans un environnement industriel.

On suppose que l’équipement terminal UE, ou IoT est connecté au réseau RC par un réseau d’accès, tel que par exemple un réseau d’accès radio mobile par l’intermédiaire d’un équipement d’accès radio. Bien sûr, et comme déjà évoqué, l’invention s’applique à d’autres technologies d’accès, sans fil ou filaires. En conséquence, l’équipement terminal peut de façon non restrictive être connecté au réseau RC via une station de base, une femto cellule associée à cette station de base, un équipement multiplexeur d'accès à la ligne d'abonné numérique DSLAM (de l’anglais, « Digital Subscriber Line Access Multiplexeur ») pour un réseau d’accès de type ADSL, une borne d’accès Wifi (ou « hotspot », en anglais) ou un répéteur Wifi associé à cette borne, un équipement de terminaison de liaison optique ONT (de l’anglais, « Optical Network Termination ») pour un réseau d’accès fibre, de type PON (de l’anglais, « Passive Optical Network »), etc.

Selon ce mode de réalisation de l’invention, le système S comprend cet équipement terminal, lequel comprend un dispositif 100 d’émission d’un flux de données dans le réseau RC, configuré pour sélectionner une tranche de réseau de ladite pluralité de tranches, au moins en fonction d’une information comprise dans un en-tête du flux de données, obtenir une information relative à un type dudit flux, ledit type appartenant à un groupe comprenant au moins un premier type et un deuxième type de flux, insérer un indicateur de priorité associé au type de flux dans le flux de données, l’indicateur de priorité appartenant à un groupe comprenant au moins un premier indicateur associé au premier type de flux et un deuxième indicateur associé au deuxième type de flux, le premier indicateur et le deuxième indicateur de priorité ayant des valeurs distinctes et émettre le flux de données dans la tranche de réseau sélectionnée. A cet égard, on note que dans le cas d’une architecture 5G, le cœur de réseau configure l’équipement terminal UE avec l’ensemble des tranches de réseaux auxquelles il est autorisé à se connecter. Chacune de ces tranches est identifiée par un identifiant S-NSSAI (de l’anglais, « Single – Network Slice Selection Assistance Information »).

Avantageusement le dispositif 100 est configuré pour recevoir au moins une règle d’acheminement d’un flux de données pour ladite application logicielle, ladite règle comprenant au moins un identifiant de ladite application logicielle, ledit type de flux, ledit indicateur de priorité associé audit type et un identifiant d’une dite tranche de réseau, stocker en mémoire de ladite au moins une règle d’acheminement et l’appliquer lors de la mise en œuvre de ladite sélection de ladite insertion. Par exemple, cette règle R_UE est stockée dans une mémoire du dispositif 100 ou de l’équipement terminal UE, IoT.

Le dispositif 100 met ainsi en œuvre le procédé d’émission d’un flux de données selon l’invention qui sera détaillé ci-après en relation avec la .

Selon ce mode de réalisation de l’invention, le système S comprend aussi une entité d’exécution EXE du réseau de communications, configurée pour gérer l’acheminement ou routage de flux de données émis par des équipements terminaux dans au moins une tranche du réseau de communications RC. Une telle entité d’exécution appartient à un plan de transfert (ou « User Plane », en anglais) du réseau de communications RC, selon la terminologie définie dans la norme ETSI TS 123 501, publiée en septembre 2018. Il s’agit d’un équipement d’accès ou bien d’un équipement nœud du réseau cœur. L’entité d’exécution EXE peut être instanciée sous la forme d’un équipement physique dédié ou non aux fonctions respectives de l’entité d’exécution EXE, ou bien sous forme d’entités virtualisées, comme par exemple des fonctions virtuelles.

Selon l’invention, cette entité d’exécution comprend un dispositif 200 de traitement d’un flux de données émis par une application logicielle d’un équipement terminal UE, IoT dans une dite tranche de réseau. Ce dispositif 200 est configuré pour obtenir un niveau de ressources disponibles pour acheminer le flux de données dans la tranche de réseau, détecter un indicateur de priorité dudit flux dans ledit flux de données, et exécuter au moins une action de traitement dudit flux de données au moins en fonction dudit indicateur de priorité et d’un niveau des ressources réseau disponibles dans ladite tranche de réseau, ladite action de traitement appartenant à un groupe comprenant au moins une première action de blocage du flux de données dans ladite tranche de réseau, destinée à être mise en œuvre lorsque le niveau de ressources réseau disponibles est insuffisant et une deuxième action de laisser-passer du flux de données dans ladite tranche de réseau, lorsque le niveau de ressources disponibles est suffisant.

Avantageusement le dispositif 200 est configuré pour obtenir au moins une règle de traitement R_UP d’un flux de données reçu de ladite application logicielle, ladite règle comprenant ledit indicateur de priorité d’un flux de données, ledit identifiant de tranche de réseau et ladite au moins une action de traitement dudit flux, la stocker en mémoire et l’appliquer au traitement du flux de données. Cette règle R_UP est avantageusement stockée dans une mémoire du dispositif 200 ou de l’entité d’exécution EXE.

Le dispositif 200 met ainsi en œuvre le procédé de traitement d’un flux de données selon l’invention qui sera détaillé ci-après en relation avec la .

Le système S comprend également une entité de contrôle CTR du réseau de communications RC, configurée pour contrôler la mise en œuvre d’une politique de traitement de flux de données acheminés dans ledit réseau par une ou plusieurs entités d’exécution. Une telle entité fait partie d’un plan dit de contrôle (ou « control plane », en anglais). Elle peut faire partie du réseau d’accès ou du réseau cœur. Par exemple, dans un réseau d’accès radio, il s’agit d’un élément de gestion de réseau ENM (de l’anglais, « Element Network Manager ») faisant partie d’un système de gestion de réseau NMS (de l’anglais, ‘Network Management System’, associé aux stations de base de 5G/4G, aussi appelées respectivement « gNodeB » ou « eNodeB ». Par exemple, dans un réseau cœur, cette entité de contrôle peut être la fonction SMF (de l’anglais, « Session Management Function ») qui contrôle la fonction UPF (en anglais, « User Plane Function ») à travers l’interface N4 selon la spécification 3GPP TS 23.501. L’entité de contrôle CTR peut être instanciée sous la forme d’un équipement physique dédié ou non aux fonctions respectives du contrôleur CTR, ou bien sous forme d’entités virtualisées.

Selon l’invention, elle comprend un dispositif 300 de contrôle du traitement par l’entité d’exécution EXE d’un flux de données émis par une application logicielle de l’équipement terminal UE, IoT dans une tranche du réseau de communications. Ledit dispositif est configuré pour recevoir, en provenance de l’entité d’exécution une notification d’un indicateur de priorité associé audit flux de données reçu, obtenir un niveau de ressources disponibles pour acheminer le flux de données dans la tranche de réseau, décider d’au moins une action de traitement dudit flux à exécuter, au moins en fonction de l’indicateur de priorité reçu et d’une politique de traitement des flux de données émis par l’application logicielle, ladite action de traitement appartenant à un groupe comprenant au moins une première action de blocage du flux de données dans ladite tranche de réseau destinée à être mise en œuvre lorsque le niveau de ressources réseau disponibles est insuffisant et une deuxième action de laisser-passer du flux de données dans ladite tranche de réseau destinée à être mise en œuvre lorsque le niveau de ressources réseau disponibles est suffisant, et envoyer une réponse à ladite entité d’exécution, comprenant ladite au moins une action de traitement.

Avantageusement le dispositif 300 est configuré pour obtenir au moins une règle de contrôle R_CP du traitement d’un flux de données reçu de ladite application logicielle, ladite règle comprenant ledit indicateur de priorité d’un flux de données, ledit identifiant de tranche de réseau et ladite au moins une action de traitement dudit flux, la stocker en mémoire et l’appliquer au contrôle du traitement du flux de données. Cette règle R_CP est avantageusement stockée dans une mémoire du dispositif 300 ou de l’entité de contrôle CTR.

Le dispositif 300 met ainsi en œuvre le procédé de contrôle du traitement d’un flux de données selon l’invention qui sera détaillé ci-après en relation avec la .

Avantageusement, le système S comprend enfin une entité de gestion EMG de la pluralité de tranches du réseau de communication RC. Elle fait partie d’un plan de gestion du réseau de communication RC. Dans le contexte d’une architecture en tranches de réseaux, une telle entité met en œuvre les fonctions de gestion des tranches de réseaux (de l’anglais, « Network Slice Management Functions) telle que décrites dans le document ETSI GR NFV-EVE 012 relatif au support des tranches de réseau en environnement virtualisé, publié en décembre 2017.). L’entité de gestion EMG peut elle aussi être instanciée sous la forme d’un équipement physique dédié ou non aux fonctions respectives de l’entité de gestion, ou bien sous forme d’entités virtualisées.

Selon l’invention, cette entité de gestion comprend un dispositif 400 de gestion de règles, configuré pour obtenir des informations métier d’un client d’une application logicielle destinée à être exécutée par un équipement terminal, lesdites informations comprenant au moins des types de flux de données destinés à être émis par l’application logicielle et des indicateurs de priorité associées à chacun des types de flux, transmettre les règles respectivement à l’équipement terminal, à l’entité d’exécution EXE et à l’entité de contrôle CTR.

Dans la suite, on décrit de façon plus détaillée des modes de réalisation de l’invention dans un réseau de télécommunications mobiles, dont l’architecture est conforme à la version 5G ou une version future de la norme 3GPP et met en œuvre le découpage du réseau en tranches de réseau. Bien sûr, et comme déjà évoqué, l’invention n’est pas limitée aux exemples décrits et s’applique aussi bien à d’autres types de réseaux de télécommunications fixes ou mobiles et à d’autres technologies d’accès, sans fil ou filaires.

On présente désormais, en relation avec la , sous une forme de logigramme, un exemple de mise en œuvre d’un procédé d’émission d’un flux de données reçu d’une application logicielle API_TA, API_JM s’exécutant sur l’équipement terminal UE, IoT, dans le réseau de communications RC, selon un mode de réalisation de l’invention. Avantageusement, le procédé est mis en œuvre par le dispositif 100 intégré dans l’équipement terminal UE, IoT.

Dans la suite, on suppose que le réseau de communications RC est découpé en plusieurs tranches SL_1 à SL_N, avec N supérieur à 2. On s’attache plus particulièrement à décrire le cas où les tranches SL_1 et SL_2 sont dédiées aux usages d’un client donné, lequel met notamment en œuvre les applications logicielles API_TM et API_JM. Ces applications logicielles sont des applications métier spécifiques du client, lequel a défini les différents types de flux de données mis en œuvre et leurs niveaux de priorité associés.

Bien sûr, comme précédemment évoqué, l’invention ne se limite pas à ce cas d’usage, mais s’applique à toute autre stratégie d’affectation des tranches du réseau de communications d’un opérateur à des clients, terminaux, applications logicielles, services, etc. En particulier, selon au moins un autre mode de réalisation de l’invention, l’opérateur définit une tranche de réseau dédiée à l’acheminement des flux de données émis dans le cadre d’un des services qu’il propose à ses clients, comme par exemple le service de Voix sur IP. Dans ce cas, il définit différents types de flux de données de Voix sur IP associés à des niveaux de qualité de service distincts, en lien avec différents niveaux d’abonnements souscrits par les clients (par exemple, or, argent ou bronze) et il leur associe des valeurs d’indicateurs de priorité distinctes, le type de flux de données Voix sur IP « or » étant le plus prioritaire et le type de flux de données Voix sur IP « bronze » étant le moins prioritaire.

Dans une phase préalable, des règles R_UE d’acheminement de flux de données en provenance de cette application logicielle API_TA, API_JM sont reçues en 30, par exemple en provenance de l’entité de gestion EMG. Ces règles permettent d’associer un indicateur de priorité à chaque flux de donnée émis par l’application logicielle API_TA, API_JM.

Typiquement, une telle règle comprend un identifiant de l’application logicielle API_TA, API_JM, un identifiant du type de flux de données STR_ID, un identifiant de la tranche de réseau à utiliser pour émettre le flux de données dans le réseau de communication RC et la valeur de l’indicateur de priorité IP associée. Par exemple, pour l’application métier « Technicien Augmenté », un flux de données de type STR_1, la tranche de réseau SL_1, la structure d’une telle règle est la suivante : « Indicateur de priorité IP - Application logicielle Métier API_TA – Tranche de réseau SL_1 – Type de flux de données STR_1 ». Elles sont stockées dans une mémoire, par exemple une mémoire M1 du dispositif 100 ou une mémoire de l’équipement terminal UE, IoT.

Optionnellement, les règles UE_R reçues en 30 sont associées à un mode opératoire de l’application logicielle API_TA, AP_JM. Par exemple, on compte trois modes opératoires distincts :
- un mode opératoire nominal MO_1, qui correspond à une situation de fonctionnement normale ;
- un mode opératoire d’alarme MO_2, qui correspond à une situation d’alarme ; et
- un mode opératoire post-alarme MO_3, qui correspond à une situation de retour à la normale ou de redémarrage suite à l’alarme.

Le fait de distinguer différents modes opératoires permet de modifier les niveaux de priorité respectifs de chacun des types de flux de données utilisés par une application logicielle à la situation de chacun de ces modes.

Par exemple, l’indicateur peut prendre au moins les valeurs suivantes :
- IP_1, par exemple égal à 1 pour un flux temps-réel de priorité haute ;
- IP_2, par exemple égal à 2, pour un flux non temps-réel ou différé, de priorité haute ;
- IP_3, par exemple égal à 3, pour un flux non temps-réel ou différé, de priorité faible.

On présente ci-après, dans la table 1, un exemple d’affectation de niveaux de priorité aux flux des applications métiers « technicien augmenté » et « jumeau numérique » pour les trois modes opératoires précédemment définis.

Application métier	Valeurs de l’indicateur de priorité par type de flux et par mode opératoire
Application métier	Type de flux	Mode opératoire « nominal »	Mode opératoire « alarme »	Mode opératoire « Post-alarme »
« Technicien Augmenté »	Voix sur IP (STR_1)	IP_1	IP_1	IP_1
	Streaming vidéo (STR_2)	IP_2	IP_1	IP_2
	Données enrichies (STR_3)	IP_3	IP_1	IP_3
« Jumeau Numérique »	Voix sur IP (STR_1’)	IP_1	IP_1	IP_1
« Jumeau Numérique »	Données de capteurs (STR_2’)	IP_3	IP_1	IP_3

[Table 1]

Dans ce cas, les règles UE_R peuvent par exemple comprendre un attribut supplémentaire correspondant au mode opératoire qui leur est associé.

En 31, une information relative à un mode opératoire courant de l’application logicielle API_TA, API_JM est reçue. On suppose ici qu’il s’agit du mode opératoire nominal MO_1.

Dans une phase de fonctionnement, un flux de données STR est reçu en 32 de l’application logicielle API_TA, API_JM. En 33, la tranche de réseau est sélectionnée, à partir d’au moins une information comprise dans un en-tête du flux de données. Par exemple, il s’agit de l’adresse IP dite de destination qui identifie l’équipement qui recevra ce flux de données et/ou d’un identifiant de l’application API_TA, API_JM. Par exemple, cette information est extraite d’un en-tête d’un protocole de signalisation, tel que le protocole NAS (de l’anglais, « Non Access Stratum ») mis en œuvre dans les échanges entre l’équipement terminal et le réseau cœur 5G, et défini par la procédure « 4.16.12.2 UE Policy Association Modification initiated by the PCF » du 3GPP TS 23.502.

En 34, le type de flux de données STR_ID (par exemple voix, streaming vidéo ou échange de données) est obtenu, par exemple à partir du 2-uplet « adresse IP (de destination) ; protocole ID » extrait d’un en-tête du flux ou du triplet d’attributs « adresse IP (de destination), numéro de port, protocole ID ». L’utilisation du triplet d’attributs sert par exemple à différencier plus finement deux flux distincts d’une même application sur la base de leurs numéros de ports distincts.

C’est notamment le cas lorsque cette application est configurée pour transmettre ces flux à un même serveur applicatif, situé en première ligne, mais que ce dernier retransmet chacun d’eux à des serveurs spécialisés distincts, situés en deuxième ligne. Par exemple, pour l’application API_TA « technicien augmenté », un serveur spécialisé dans la reconnaissance de formes reçoit les flux de streaming vidéo, un autre serveur spécialisé dans l’indexation de documentation technique reçoit les flux de données enrichies et encore un autre serveur spécialisé dans les services interpersonnels de mise en relation reçoit les flux de voix sur IP.

En 35, la valeur du mode opératoire courant MO_1 est obtenue, le cas échéant. En 36, la règle UE_R stockée en mémoire correspondant à l’application logicielle API_TA, API_JM qui a émis le flux STR, au type de flux de données STR_ID et éventuellement au mode opératoire courant MO_1 est récupérée, ce qui permet d’obtenir la valeur de l’indicateur de priorité IP associée à ce flux de données STR. En 37, l’indicateur de priorité IP est inséré dans le flux de données STR. Par exemple, il est inséré dans un en-tête du flux de données STR, tel qu’un en-tête du protocole applicatif utilisé par l’application logicielle API_TA, API_JM. Par exemple, l’indicateur de priorité IP est inséré dans une variable d’un en-tête d’une requête HTTP GET. Il peut aussi être inséré dans un en-tête d’un paquet IP, d’une trame Ethernet, ou d’un contexte de réseau 3GPP (PDP context, EPB bearer, PDU session). En variante, il peut également être inséré dans la partie utile d’un tel paquet, trame ou contexte du flux de données STR.

En 38, le flux de données STR ainsi modifié est transmis dans la tranche de donnée SL_1 du réseau de communication RC.

On comprend que, suite à un changement du mode opératoire, la valeur de l’indicateur de priorité à insérer dans le prochain flux de données émis par l’application logicielle API_TA, API_JM est mise à jour et devient celle associée au nouveau mode opératoire courant.

On présente désormais, en relation avec la , sous une forme de logigramme, un exemple de mise en œuvre d’un procédé de traitement d’un flux de données reçu d’une application logicielle API_TA, API_JM s’exécutant sur l’équipement terminal UE, IoT, dans une tranche SL_1 de réseau de communications RC, selon un mode de réalisation de l’invention. Avantageusement, ce flux de données STR est reçu par une entité d’exécution EXE du plan de transfert UP du réseau de communications RC et le procédé est mis en œuvre par le dispositif 200 intégré dans cette entité d’exécution EXE configurée pour gérer au moins la tranche de réseau SL_1 du réseau RC. Si le réseau RC est un réseau de communications mobiles conforme à la 5G, il s’agit par exemple d’un équipement du réseau d’accès radio RAN, par exemple, dans une architecture O-RAN, cet équipement peut être celui implémentant la fonction O-CU-UP («O-RAN Central Unit – User Plane» en anglais [O-RAN]), ou un équipement du cœur de réseau.

Avantageusement, on suppose ici que l’entité d’exécution EXE est configurée pour gérer les tranches SL_1 et SL_2 du réseau RC.

En 40, le flux de données STR est reçu. En 41, un indicateur de priorité IP est détecté le flux de données, par exemple dans un en-tête ou dans une partie utile de ce flux de données.

En 42, une évaluation d’un niveau de ressources NRS_1 disponibles pour acheminer le flux de données STR dans la tranche de réseau SL_1 est obtenue. Cette évaluation peut être mise en œuvre localement ou obtenue d’un équipement distant, par exemple un autre équipement du plan de transfert. L’entité d’exécution EXE a connaissance des ressources dont elle dispose et qu’elle peut utiliser pour chaque tranche de réseau SL dont elle a la charge. En effet, dans une architecture 5G, lors de la mise en œuvre des tranches de réseau, le plan de gestion configure chacun des équipements réseaux d’accès et de cœur en fonction des caractéristiques de chaque tranche. Ces caractéristiques incluent notamment la bande passante allouée à chaque tranche.

Ensuite, chaque règle de traitement R_UP précise la bande passante nécessaire pour le fonctionnement correct de chaque type de flux de données susceptible d’être émis par l’application métier API_TA, API_JM considérée.

Enfin, l’entité d’exécution EXE évalue si les ressources disponibles pour une tranche SL donnée sont suffisantes pour assurer l’acheminement du flux de données reçu compte tenu de la valeur de l’indicateur de priorité IP qui lui est associé. Pour ce faire, elle compare la quantité de ressources nécessaire pour acheminer le flux reçu à la quantité de ressources disponible. Il s’agit par exemple d’un nombre de PRB au niveau d’un réseau d’accès radio, d’un débit en kbits/s ou Mbits/s pour le cœur de réseau.

On note que si plusieurs flux de données sont reçus en même temps, leur traitement peut avantageusement être hiérarchisé en fonction de leur niveau de priorité associé. Par exemple, les flux temps réel sont priorisés par rapport aux flux non temps réel.

Si besoin, un deuxième niveau de priorisation peut être appliqué, dans le cas où plusieurs flux temps-réel utilisent la même tranche de réseau et sont reçus en même temps par l’entité d’exécution EXE, par exemple en traitant d’abord les flux temps-réel haute priorité par rapport aux flux temps-réel basse priorité. C’est le cas notamment pour une application « Voix sur IP » de l’opérateur qui distingue des flux de données VoIP prioritaires et des flux de données VoIP non prioritaires. On note qu’il est possible de faire de même pour des flux non temps-réel, en distinguant des flux non temps réel à haute priorité par rapport à des flux non temps-réel à plus faible priorité. Dans ce cas, on note que les flux temps-réel basse priorité resteront prioritaires sur les flux non-temps réel et notamment sur les flux non temps-réel à haute priorité.

En 43, une action de traitement AC à exécuter pour traiter l’acheminement de ce flux de données est obtenue. En 44, l’action de traitement AC est exécutée.

Selon l’invention, l’action de traitement AC peut être obtenue par l’entité d’exécution EXE de différentes façons, qui vont maintenant être détaillées.

Selon un premier mode de réalisation de l’invention, illustré par la , au moins une règle de traitement R_UP du flux de données STR reçu en provenance de l’application logicielle API_TA, API_JM est obtenue en 430. On suppose par exemple qu’un ensemble de règles a été reçu de l’entité de gestion EGM dans une phase de configuration préalable non représentée. De telles règles indiquent l’action de traitement AC à exécuter pour le flux de données STR. Avantageusement, une telle règle de traitement R_UP comprend un identifiant de l’application logicielle API_TA, API_JN, un identifiant du type de flux de données STR_1, un identifiant de la tranche de réseau SL_1 à utiliser pour émettre le flux de données dans le réseau de communication RC, la valeur de l’indicateur de priorité IP_1 associée et un identifiant de l’action AC à exécuter.

Par exemple, la mémoire en question est organisée comme une base de données et la règle de traitement à appliquer au flux de données STR reçu est obtenue en interrogeant la base de données à l’aide de l’identifiant de l’application logicielle et/ou de l’identifiant du flux de données et de l’indicateur de priorité détecté dans le flux.

Avantageusement, l’action de traitement AC peut prendre au moins l’une des deux valeurs suivantes :
- laisser passer (AC1, par exemple égal à 1) le flux de données et le transférer dans la tranche de réseau SL_1 ;
- bloquer (AC2, par exemple égal à 2) le flux de données STR et le supprimer de la tranche de réseau SL_1.

On comprend que les actions AC_1, AC_2 sont les deux actions de base à exécuter en 44. Elles présentent l’avantage d’être simples à mettre en œuvre, sur la base de règles simples, du fait qu’elles reposent sur une prise de décision binaire. Bien sûr, d’autres actions peuvent être prises en considération pour mettre en œuvre une stratégie enrichie, lorsque les ressources sont évaluées comme insuffisantes. Par exemple, une autre action possible serait d’accélérer ou retarder le transfert du flux de données STR ou lui affectant moins ou plus de ressources, ou encore de limiter ou écrêter le flux de données avant de le transmettre pour s’adapter aux ressources disponibles. Dans le cas où deux flux de même priorité sont reçus simultanément, on pourrait ainsi les transférer tous les deux en affectant moins de ressources à chacun.

En 431, l’action de traitement AC est extraite de la règle R_UP obtenue, puis mise en application en 44.

Selon ce premier mode de réalisation, l’entité d’exécution EXE a donc été préalablement configurée pour décider localement de l’action de traitement à exécuter.

Avantageusement, elle peut avoir reçu préalablement une première règle de traitement R_UP0 lui indiquant si elle devait décider localement de l’action de traitement à exécuter ou si elle devait notifier une autre entité du réseau de communication RC.
En variante, elle peut simplement rechercher en mémoire si elle dispose d’une règle R_UP pour l’application logicielle d’où provient le flux de données reçu et pour l’indicateur de priorité IP détecté. Si aucune règle R_UP correspondante n’est trouvée, alors elle notifie une autre entité ou bien elle applique une règle par défaut R_UP_D qui définit l’action de traitement à exécuter pour un flux de données issu de l’application logicielle considérée ou de toutes les applications logicielles du client de la tranche de réseau SL_1, associé au niveau de priorité IP_3 le plus faible.

Selon un deuxième mode de réalisation de l’invention illustré par la , on considère que l’entité d’exécution EXE est configurée pour notifier une autre entité du réseau de communications RC. Avantageusement, il s’agit d’une entité de contrôle CTR du plan de contrôle du réseau RC, configurée pour contrôler la mise en œuvre d’une politique de traitement des flux de données acheminés dans ledit réseau RC. Par exemple, la première règle R_UP0 identifie cette entité de contrôle CTR à notifier et les informations à lui transmettre.

En 430’ (de la ), l’entité d’exécution obtient cette première règle R_UP0 et en extrait donc l’identité de l’entité de contrôle à notifier.
En 431’, elle notifie à l’entité de contrôle CTR qu’elle a reçu le flux de données STR, associé à l’indicateur de priorité IP dans la tranche de réseau SL_1. On note qu’elle peut déclencher cette notification suite à la détection de l’indicateur de priorité IP dans le flux de données STR, c’est-à-dire notifier systématiquement l’entité de contrôle CTR dans un message comprenant un seul indicateur de priorité associé à un seul flux de données reçu, ou, en variante, transmettre un seul message de notification NTF à l’expiration d’une période temporelle donnée regroupant les indicateurs de priorité détectés dans des flux de données reçus sur la tranche de réseau SL_1 pendant cette période.

En 432’, elle reçoit en retour l’action de traitement à exécuter. Par exemple, il s’agit d’une des deux actions AC_1, AC_2 précédemment évoquées ou bien selon la stratégie enrichie, d’une autre action, par exemple de retard ou d’accélération du transfert du flux de données STR ou encore de limitation ou d’écrêtage du flux de données avant transfert. En 44, elle exécute l’action de traitement reçue.

Selon ce deuxième mode de réalisation de l’invention, c’est donc le plan de contrôle qui applique les règles de traitement des flux de données en fonction des indicateurs de priorités associés à ces flux.

On présente désormais, en relation avec la , sous une forme de logigramme, un exemple de mise en œuvre d’un procédé de contrôle d’un flux de données reçu d’une application logicielle API_TA, API_JN dans une tranche de réseau SL1 du réseau de communications, selon ce deuxième mode de réalisation de l’invention. Avantageusement, le procédé est mis en œuvre par le dispositif 300 intégré dans l’entité de contrôle CTR du plan de contrôle du réseau de communication RC.

En 50, une notification NTF est reçue par l’entité de contrôle CTR en provenance de l’entité d’exécution EXE du plan de transfert du réseau de communications RC. Elle concerne un flux de données STR reçu par cette entité d’exécution EXE et comprend au moins un identifiant du type de flux de données STR_1, un indicateur de priorité IP_1 associé et l’identifiant de la tranche de réseau SL_1. Par exemple, cette notification est transmise à l’entité de contrôle dans un message conforme à un protocole de type radius, diameter ou http/2. Dans le cas d’une architecture basée service ou SBA (de l’anglais, « Service Based Architecture ») pour la 5G, c’est le protocole http/2 qui est utilisé.

En 51, l’entité de contrôle CTR obtient une évaluation d’un niveau de ressources disponibles dans la tranche de réseau SL_1 Par rapport au besoin de ressources pour transmettre le flux de données STR reçu dans les conditions prévues pour le niveau de priorité qui lui est associé, les mécanismes mis en œuvre sont similaires à ceux décrits pour l’étape 42 et ne seront pas détaillés plus avant.

Dans le réseau d’accès d’une architecture 5G mettant en œuvre une implémentation de type O-RAN, l’entité ou fonction de contrôle CTR récupère les informations de ressources disponibles pour chaque tranche de réseau à partir de la fonction O-CU-CP.

Dans le réseau cœur, l’entité ou fonction de contrôle CTR récupère ces informations de ressources disponibles auprès d’une fonction de gestion de session SMF (de l’anglais « Session Mangement Function ») qui contrôle la fonction de plan de transfert UPF (de l’anglais, « User Plane Function ») correspondant à l’entité ou fonction d’exécution EXE en question, via l’interface N4 telle que définie par le 3GPP dans la spécification TS23.501 (section 5.8.2.11 « Parameters for N4 session management »)

En 52, elle obtient une règle de contrôle R_CP des flux de données acheminés sur la tranche de réseau SL_1 et associés à l’indicateur de priorité IP reçu. Avantageusement, on suppose qu’un ensemble de règles R_CP a été reçu de l’entité de gestion EMG dans une phase de configuration préalable non représentée. De telles règles indiquent l’action de traitement AC à exécuter pour le flux de données STR en fonction de la valeur de son indicateur de priorité associé. Avantageusement, une telle règle de contrôle R_CP comprend un identifiant de la tranche de réseau SL_1, la valeur de l’indicateur de priorité IP_1 et un identifiant de l’action AC à exécuter.

On comprend que cette règle de contrôle R_CP est très proche dans sa structure et son contenu d’une règle de traitement R_UP. Une différence est que les règles de contrôle R_CP peuvent être plus complexes car l’entité ou fonction de contrôle CTR dispose généralement d’une vision plus large sur le domaine dont elle a la responsabilité que l’entité ou fonction d’exécution EXE qui n’a connaissance que de ses propres ressources et donc un périmètre d’action limité à sa fonction.

Par exemple, la mémoire en question est organisée comme une base de données et la règle de contrôle R_CP à appliquer à la notification NTF reçue est obtenue en interrogeant la base de données à l’aide de l’identifiant de la tranche de donnée SL_1 et de l’indicateur de priorité IP reçu dans la notification.

En 53, l’action de traitement AC est extraite de la règle reçue, puis en 54 une réponse est transmise à l’entité d’exécution dans un message comprenant au moins l’action de traitement AC. Par exemple, ce message est conforme au format JSON et il est envoyé selon le protocole http/2.

On présente désormais, en relation avec la , sous une forme de logigramme, un autre mode de réalisation de l’invention mis en œuvre lorsque l’action de traitement décidée pour le flux de données STR est de bloquer ce flux dans la tranche de réseau SL_1. En particulier, on décrit ci-après un mécanisme qui peut être mis en œuvre soit au niveau de l’entité d’exécution EXE dans le cadre du procédé de traitement d’un flux de données qui vient d’être décrit en relation avec la , soit au niveau de l’entité de contrôle CTR dans le cadre du procédé de contrôle du traitement d’un flux de données qui vient d’être décrit en relation avec la .

Le mécanisme en question est donc déclenché suite à l’obtention 43 de l’action AC au niveau de l’entité d’exécution EXE lorsque cette action est une action AC2 de blocage du flux de données dans la tranche de réseau SL_1 ou plus généralement, lorsque les ressources disponibles sont évaluées comme insuffisantes et qu’une action de limitation du flux ou de retard du transfert du flux a été prise, ou encore suite à la décision 53 d’exécuter cette action AC au niveau de l’entité de contrôle CTR.
En 60, il est vérifié s’il existe une autre règle de traitement R_UP_FK ou de contrôle R_CP_FK pour un flux de données de l’application logicielle API_TA, API_JM, associé à l’indicateur de priorité IP dans la tranche de réseau SL_1, qui prévoit une troisième action de traitement AC_3 consistant à transférer le flux de données bloqué dans une autre tranche de réseau SL_2 accessible au client de l’application logicielle considérée. Par exemple, cette règle supplémentaire, qu’on appelle règle de repli, est obtenue en interrogeant la base de données de la mémoire locale, comme précédemment décrit.

On suppose d’abord que cette règle de repli n’est pas disponible. Dans ce cas, l’action de traitement à exécuter reste l’action AC2 de blocage donc de suppression du flux de données de la tranche de réseau SL_1 ou de limitation du flux suivant les ressources disponibles pour l’acheminement.

Lorsqu’au contraire cette règle de repli est disponible pour le flux de données courant, alors on évalue en 61 la disponibilité des ressources dans une autre tranche de réseau accessible au client de l’application logicielle, ici la tranche SL_2. Une quantité de ressources disponibles est obtenue puis comparée à un seuil minimum TH donné ou aux besoins en ressources pour l’acheminement du flux de données STR en 62. Si cette autre tranche de réseau SL_2 dispose de ressources suffisantes et/ou de plus de ressources disponibles que la tranche de réseau SL_1 pour acheminer le flux de données STR, c’est-à-dire si la quantité de ressources évaluée est supérieure ou égale au seuil TH, alors le flux de données STR est transféré dans l’autre tranche de réseau SL_2.

Avantageusement, une telle règle de repli R_UP_FK, R_CP_FK est associée aux indicateurs de priorité correspondant à des niveaux de priorité élevée. Par exemple, pour l’application logicielle API_TA, AP_JN, seuls les flux de données associés à un indicateur de priorité IP_1 peuvent bénéficier de cette solution de repli vers une autre tranche de réseau SL_2. Lorsque des modes opératoires sont mis en œuvre, on note que ce sont les seuls flux de données de type STR_1 en mode nominal MO_1 qui peuvent bénéficier de la solution de repli, mais qu’en revanche tous les types de flux STR_1, STR_2 et STR_3 en mode alarme MO2 peuvent en bénéficier.

Ce mécanisme présente donc l’avantage d’offrir une chance supplémentaire à un flux de données prioritaire d’être acheminé lorsque les ressources du plan de transfert UP ne sont pas suffisantes dans la tranche de réseau SL_1 sélectionnée pour l’application qui l’a émis.

Il s’articule avec les deux modes de réalisation précédemment décrits de la façon suivante :
- dans le cas du premier mode de réalisation, selon lequel l’entité d’exécution EXE décide localement de l’action à exécuter en appliquant des règles de traitement obtenues au préalable de l’entité de gestion EMG, le mécanisme de repli qui vient d’être décrit peut soit être exécuté localement lui aussi sur la base d’une règle de repli R_UP_FK pourvu que l’entité d’exécution soit en charge de gérer au moins deux tranches de réseau SL_1, SL_2 accessibles à l’application logicielle concernée, soit la décision de bloquer le flux de données STR ou encore de limiter le flux de données STR, déclenche l’émission d’une notification à destination de l’entité de contrôle CTR pour qu’elle mette en œuvre le mécanisme de repli en question. Par exemple, la notification comprend l’indicateur de priorité, l’identifiant de l’application logicielle API_TA, API_JN, l’identifiant de la tranche de réseau sélectionnée SL_1. A réception, l’entité de contrôle CTR met en œuvre le mécanisme de repli et répond à la notification en transmettant soit une confirmation de l’action de blocage (ou limitation de l’acheminement) AC_2 soit l’action de transfert AC_3 en précisant la tranche de réseau SL_2 vers laquelle transférer le flux de données ;
- dans le cas du deuxième mode de réalisation, selon lequel l’entité d’exécution EXE notifie l’entité de contrôle CTR dont elle dépend de l’indicateur de priorité détecté dans le flux de données STR qu’elle a reçu, et de la tranche de réseau SL_1 dans laquelle elle l’a reçu, le mécanisme de repli est avantageusement mis en œuvre par l’entité de contrôle CTR suite à la décision 52 de faire exécuter à l’entité EXE la décision AC_2 de blocage du flux de données STR. De la sorte, l’entité de contrôle envoie uniquement l’action de transfert AC_3 dans sa réponse à la notification NTF de l’entité d’exécution EXE, associée à la tranche de réseau SL_2 vers laquelle ce transfert doit être réalisé.

On présente maintenant, en relation avec la , un exemple d’architecture d’un réseau de communications RC mettant en œuvre l’invention. Il comprend un plan de gestion MP, un plan de transfert UP et un plan de contrôle CP. Le plan de gestion MP comprend une pluralité d’entités de gestion EMG_1, EMG_2, EMG_3 configurées pour définir des règles d’acheminement, de traitement et de contrôle de flux de données dans les différentes tranches SL_1, SL_2 du réseau RC. En particulier, les entités de gestion sont configurées pour transmettre des règles d’acheminement de flux de données à des équipements terminaux UE, IoT connectés au réseau RC, des règles de traitement à une pluralité d’entités d’exécution EXE_1, EXE_2, EXE_3 du plan de transfert UP, et des règles de contrôle à une pluralité d’entités de contrôle CTR_1, CTR_2, CTR_3 du plan de contrôle CP du réseau RC.

Ces règles permettent de décider, en fonction d’un niveau de ressources disponibles dans une tranche de réseau et d’un niveau de priorité de ce flux, si un flux de données peut être acheminé ou s’il doit être bloqué.

Certaines de ces entités d’exécution peuvent être configurées pour gérer plusieurs tranches SL_1, SL_2 du réseau RC, d’autres une seule. Celles qui sont configurées pour gérer au moins deux tranches du réseau RC pourront mettre en œuvre le mécanisme de repli décrit en relation avec la et l’appliquer aux flux de données les plus prioritaires.

Comme précédemment décrit, ce mécanisme de repli peut, en variante, être mis en œuvre par des entités de contrôle CTR_1, CTR_2, CTR_3 lorsque les entités d’exécution qu’elles contrôlent gèrent au moins deux tranches de réseau. Par exemple, l’entité d’exécution EXE_1 détecte un mode opératoire « alarme » et en informe l’entité de contrôle CTR_1 qui gère l’entité EXE_1. Cette entité CTR_1 peut alors décider de dupliquer les flux vers une autre tranche de réseau SL_2 qui est contrôlée par une entité d’exécution EXE_1’ (non représentée) pour le plan de transfert et par cette même entité CTR_1 pour le plan de contrôle.

Les entités d’exécution du plan transfert sont placés le long du chemin ou de la route empruntée par un flux de données STR émis par l’équipement terminal UE, IoT vers sa destination. On comprend donc que chacune d’entre elles est configurée pour mettre en œuvre le procédé de traitement d’un flux de données qui vient d’être décrit sous le contrôle de l’entité de contrôle CTR_1, CTR_2, CTR_3 dont elle dépend.

On note que l’invention s’applique également dans un contexte multi-opérateurs et que de ce fait, certaines entités d’exécution ou de contrôle peuvent être configurées pour avoir une connaissance des ressources d’une tranche de réseau d’un autre opérateur et prendre une décision de transfert d’un flux de données vers cette tranche de réseau. Par exemple, l’entité de contrôle qui prend la décision relative à l’acheminement du flux de données peut recevoir des informations relatives à un niveau de ressources disponibles dans cette tranche de réseau d’un autre opérateur de la part d’une entité de contrôle gérée par cet autre opérateur.

On présente désormais, en relation avec la , un exemple de structure matérielle d’un dispositif 100 d’émission d’un flux de données dans un réseau de télécommunications, auquel est connecté un équipement terminal, ledit réseau étant découpé en une pluralité de tranches de réseau, ledit dispositif comprenant un module de sélection d’une tranche de réseau de ladite pluralité au moins en fonction de l’identifiant de l’application logicielle, un module d’obtention d’un type dudit flux, ledit type appartenant à un groupe comprenant au moins un premier type et un deuxième type de flux, et un module d’insertion d’un indicateur de priorité associé au type de flux dans un en-tête du flux de données, l’indicateur de priorité appartenant à un groupe comprenant au moins un premier indicateur associé au premier type de flux et un deuxième indicateur associé au deuxième type de flux, le premier indicateur et le deuxième indicateur de priorité ayant des valeurs distinctes et un module d’émission du flux de données dans la tranche de réseau sélectionnée.

Avantageusement, le dispositif 100 comprend un module de réception d’au moins une règle d’acheminement d’un flux de données pour ladite application logicielle, ladite règle comprenant au moins un identifiant de ladite application logicielle, ledit type de flux, ledit indicateur de priorité associé audit type de flux et un identifiant d’une dite tranche de réseau; un module de stockage en mémoire de ladite au moins une règle de traitement , les modules de sélection et d’insertion étant configurés pour appliquer ladite au moins une règle. Avantageusement, le dispositif 100 comprend aussi un module d’obtention d’un mode opératoire de ladite application logicielle, ledit mode opératoire appartenant à un groupe comprenant au moins un premier mode opératoire et un deuxième mode opératoire, ladite au moins une règle d’acheminement étant associée audit mode opératoire.

Le terme « module » peut correspondre aussi bien à un composant logiciel qu’à un composant matériel ou un ensemble de composants matériels et logiciels, un composant logiciel correspondant lui-même à un ou plusieurs programmes ou sous-programmes d’ordinateur ou de manière plus générale à tout élément d’un programme apte à mettre en œuvre une fonction ou un ensemble de fonctions.

Plus généralement, un tel dispositif 100 comprend une mémoire vive 103 (par exemple une mémoire RAM), une unité de traitement 102 équipée par exemple d'un processeur, et pilotée par un programme d'ordinateur Pg1, représentatif des modules de sélection, d’obtention, d’insertion, de réception, de stockage, stocké dans une mémoire morte 101 (par exemple une mémoire ROM ou un disque dur). A l'initialisation, les instructions de code du programme d'ordinateur sont par exemple chargées dans la mémoire vive 103 avant d'être exécutées par le processeur de l'unité de traitement 102. La mémoire vive 103 peut aussi contenir par exemple l’identifiant de l’application logicielle, le type de flux de données et le mode opératoire obtenus.

La illustre seulement une manière particulière, parmi plusieurs possibles, de réaliser le dispositif 100 afin qu’il effectue les étapes du procédé d’émission d’un flux de données tel que détaillé ci-dessus, en relation avec la , dans ses différents modes de réalisation. En effet, ces étapes peuvent être réalisées indifféremment sur une machine de calcul reprogrammable (un ordinateur PC, un processeur DSP ou un microcontrôleur) exécutant un programme comprenant une séquence d’instructions, ou sur une machine de calcul dédiée (par exemple un ensemble de portes logiques comme un FPGA ou un ASIC, ou tout autre module matériel).

Dans le cas où le dispositif 100 est réalisé avec une machine de calcul reprogrammable, le programme correspondant (c'est-à-dire la séquence d’instructions) pourra être stocké dans un médium de stockage amovible (tel que par exemple une carte SD, une clé USB, un CD-ROM ou un DVD-ROM) ou non, ce médium de stockage étant lisible partiellement ou totalement par un ordinateur ou un processeur.

Les différents modes de réalisation ont été décrits ci-avant en relation avec un dispositif 100 intégré dans un équipement terminal connecté à un réseau de communications RC, mais il peut aussi être intégré dans un équipement d’accès à ce réseau, par exemple une passerelle de connectivité qui intègre ce dispositif 100. Une telle passerelle de connectivité sert généralement d’interface entre des modules IoT dit légers (c’est-à-dire dotés d’une faible capacité de traitement embarqué) et le réseau de communications RC. Elle est par exemple mise en œuvre pour la gestion de l’énergie. Des capteurs IoT remontent des données de mesures de consommation d’énergie d’usagers à une passerelle de connectivité, qui est typiquement configurée pour agréger une dizaine de capteurs IoT.

On présente ensuite, en relation avec la , un exemple de structure matérielle d’un dispositif 200 de traitement d’un flux de données reçu dans un réseau de télécommunications, ledit réseau étant découpé en une pluralité de tranches de réseau, ledit flux de données ayant été reçu d’une application logicielle s’exécutant sur un équipement terminal connecté audit réseau dans une dite tranche de réseau de ladite pluralité, ledit dispositif comprenant un module d’obtention d’une évaluation d’un niveau de ressources disponibles dans la tranche de réseau , un module de détection d’un indicateur de priorité dans un en-tête dudit flux de données et un module d’exécution d’au moins une action de traitement dudit flux de données au moins en fonction dudit indicateur de priorité et du niveau de ressources réseau disponibles dans ladite tranche de réseau, ladite action de traitement appartenant à un groupe comprenant au moins une première action de laisser-passer du flux de données dans ladite tranche de réseau, lorsque le niveau de ressources disponibles est suffisant et une deuxième action de blocage du flux de données dans ladite tranche de réseau, destinée à être mise en œuvre lorsque le niveau de ressources réseau disponibles est insuffisant.

Avantageusement, le dispositif 200 comprend un module d’obtention préalable d’au moins une règle de traitement d’un flux de données reçu de ladite application logicielle, ladite règle comprenant ledit indicateur de priorité d’un flux de données, ledit identifiant de tranche de réseau et ladite au moins une action de traitement dudit flux, et un module d’extraction (de l’action de traitement de ladite règle). Avantageusement, ledit dispositif comprend aussi un module de notification dudit indicateur de priorité à une entité de contrôle dudit réseau, configuré pour être mis en œuvre lorsqu’aucune règle de traitement n’a été préalablement obtenue pour traiter ledit flux de données, et un module de réception, en provenance de ladite entité de contrôle, de ladite au moins une action de traitement à exécuter. Avantageusement, le dispositif 200 comprend enfin un module d’obtention d’une évaluation d’un niveau de ressources dans une autre tranche de réseau et un module de décision d’au moins une troisième action de traitement, dite action de transfert du flux de données, en fonction dudit niveau de ressources (et de l’indicateur de priorité, en remplacement de la deuxième action de traitement). Ces modules sont configurés pour être mis en œuvre lorsque l’entité d’exécution étant configurée pour gérer la tranche de réseau et ladite au moins une autre tranche de réseau dudit réseau de communication et lorsque l’action de traitement est la deuxième action de blocage du flux de données dans la tranche de réseau.

Plus généralement, un tel dispositif 200 comprend une mémoire vive 203 (par exemple une mémoire RAM), une unité de traitement 202 équipée par exemple d'un processeur, et pilotée par un programme d'ordinateur Pg2, représentatif des modules précités, stocké dans une mémoire morte 201 (par exemple une mémoire ROM ou un disque dur). A l'initialisation, les instructions de code du programme d'ordinateur sont par exemple chargées dans la mémoire vive 203 avant d'être exécutées par le processeur de l'unité de traitement 202. La mémoire vive 203 peut aussi contenir par exemple l’identifiant de l’application logicielle, l’indicateur de priorité, la tranche de réseau, le niveau de ressources évalué pour la tranche de réseau, le type de flux de données obtenus. Elle peut comprendre aussi les règles de traitement préalablement reçues, le ou les niveaux de ressources évalués pour la ou les tranches de réseau, le ou les seuils de décision mis en œuvre pour décider si le ou les niveaux de ressources évalués sont suffisants pour acheminer le flux de données.

La illustre seulement une manière particulière, parmi plusieurs possibles, de réaliser le dispositif 200 afin qu’il effectue les étapes du procédé de contrôle du traitement d’un flux de données tel que détaillé ci-dessus, en relation avec les figures 4, 4A, 4B et 6, dans ses différents modes de réalisation. En effet, ces étapes peuvent être réalisées indifféremment sur une machine de calcul reprogrammable (un ordinateur PC, un processeur DSP ou un microcontrôleur) exécutant un programme comprenant une séquence d’instructions, ou sur une machine de calcul dédiée (par exemple un ensemble de portes logiques comme un FPGA ou un ASIC, ou tout autre module matériel).

Dans le cas où le dispositif 200 est réalisé avec une machine de calcul reprogrammable, le programme correspondant (c'est-à-dire la séquence d’instructions) pourra être stocké dans un médium de stockage amovible (tel que par exemple une carte SD, une clé USB, un CD-ROM ou un DVD-ROM) ou non, ce médium de stockage étant lisible partiellement ou totalement par un ordinateur ou un processeur.

Les différents modes de réalisation ont été décrits ci-avant en relation avec un dispositif 200 intégré dans une entité d’exécution du réseau de communications RC, par exemple un équipement nœud du réseau d’accès, par exemple une station de base d’un réseau d’accès radio mobile ou un équipement routeur du réseau cœur.

On présente enfin, en relation avec la , un exemple de structure matérielle d’un dispositif 300 de contrôle du traitement d’un flux de données reçu dans un réseau de télécommunications, ledit réseau étant découpé en une pluralité de tranches de réseau, ledit flux de données ayant été émis par un équipement terminal et reçu par une entité d’exécution dudit réseau dans une tranche de réseau de ladite pluralité, ledit dispositif comprenant un module de réception en provenance de l’entité d’exécution d’une notification d’un indicateur de priorité (IP) associé audit flux de données reçu, un module d’obtention d’un niveau de ressources disponibles dans la tranche de réseau, un module de décision d’au moins une action de traitement dudit flux au moins en fonction de l’indicateur de priorité reçu et du niveau de ressources disponibles, et un module d’envoi d’une réponse à ladite entité d’exécution, ladite réponse comprenant ladite action de traitement.

Avantageusement, le dispositif 300 comprend un module d’obtention préalable d’au moins une règle de contrôle du traitement d’un flux de données reçu de ladite application logicielle, ladite règle comprenant ledit indicateur de priorité d’un flux de données, ledit identifiant de tranche de réseau et ladite au moins une action de traitement dudit flux, et un module de stockage de ladite au moins une règle en mémoire. Avantageusement, ledit dispositif 300 comprend aussi un module d’obtention d’un niveau de ressources disponibles dans une autre tranche de réseau, un module de décision d’au moins une troisième action de traitement, dite action de transfert du flux de données, en fonction dudit niveau de ressources et de l’indicateur de priorité, en remplacement de la deuxième action de traitement. Ces modules sont configurés pour être mis en œuvre préalablement à la transmission de la deuxième action de traitement à l’entité d’exécution, lorsque l’action de traitement décidée est l’action de blocage dudit flux de données dans la tranche de réseau et lorsque l’entité d’exécution est configurée pour gérer une autre tranche de réseau de ladite pluralité.
Le terme « module » peut correspondre aussi bien à un composant logiciel qu’à un composant matériel ou un ensemble de composants matériels et logiciels, un composant logiciel correspondant lui-même à un ou plusieurs programmes ou sous-programmes d’ordinateur ou de manière plus générale à tout élément d’un programme apte à mettre en œuvre une fonction ou un ensemble de fonctions.

Plus généralement, un tel dispositif 300 comprend une mémoire vive 303 (par exemple une mémoire RAM), une unité de traitement 302 équipée par exemple d'un processeur, et pilotée par un programme d'ordinateur Pg3, représentatif des modules précités, stocké dans une mémoire morte 301 (par exemple une mémoire ROM ou un disque dur). A l'initialisation, les instructions de code du programme d'ordinateur sont par exemple chargées dans la mémoire vive 303 avant d'être exécutées par le processeur de l'unité de traitement 302. La mémoire vive 303 peut aussi contenir par exemple les règles de contrôle préalablement reçues, l’identifiant de l’application logicielle, l’indicateur de priorité, la tranche de réseau, le niveau de ressources évalué pour la tranche de réseau, le type de flux de données obtenus. Elle peut comprendre aussi le niveau de ressources évalué pour l’autre tranche de réseau, le ou les seuils de décision mis en œuvre pour décider si le ou les niveaux de ressources évalués sont suffisants pour acheminer le flux de données.

La illustre seulement une manière particulière, parmi plusieurs possibles, de réaliser le dispositif 300 afin qu’il effectue les étapes du procédé de contrôle du traitement d’un flux de données tel que détaillé ci-dessus, en relation avec les figures 5 et 6, dans ses différents modes de réalisation. En effet, ces étapes peuvent être réalisées indifféremment sur une machine de calcul reprogrammable (un ordinateur PC, un processeur DSP ou un microcontrôleur) exécutant un programme comprenant une séquence d’instructions, ou sur une machine de calcul dédiée (par exemple un ensemble de portes logiques comme un FPGA ou un ASIC, ou tout autre module matériel).

Dans le cas où le dispositif 300 est réalisé avec une machine de calcul reprogrammable, le programme correspondant (c'est-à-dire la séquence d’instructions) pourra être stocké dans un médium de stockage amovible (tel que par exemple une carte SD, une clé USB, un CD-ROM ou un DVD-ROM) ou non, ce médium de stockage étant lisible partiellement ou totalement par un ordinateur ou un processeur.

Les différents modes de réalisation ont été décrits ci-avant en relation avec un dispositif 300 intégré dans une entité de contrôle du réseau de communications RC, par exemple un équipement de contrôle du réseau d’accès ou un équipement de contrôle du réseau cœur. Par exemple, ce dispositif 300 est implémenté dans une entité fonctionnelle O-CU-CP d’un réseau d’accès mobile suivant les spécifications O-RAN. S’agissant du réseau cœur mobile, ce dispositif 300 peut être implémenté dans une entité fonctionnelle SMF suivant les spécifications 3GPP de l’architecture 5G.

Claims

Procédé d’émission d’un flux de données reçu d’une application logicielle s’exécutant sur un équipement terminal (UE, IoT), dans un réseau de communications (RC) auquel est connecté ledit équipement terminal, ledit réseau étant découpé en une pluralité de tranches de réseau (SL_1, SL_2) , caractérisé en ce que ledit procédé est mis en œuvre au niveau dudit équipement terminal et comprend
- la sélection (33) d’une tranche de réseau (SL_1) de ladite pluralité au moins en fonction d’une information comprise dans un en-tête du flux de données,
- l’obtention (34) d’un type dudit flux, ledit type appartenant à un groupe comprenant au moins un premier type (STR_1) et un deuxième type de flux (STR_2),
- l’insertion (37) d’un indicateur de priorité (IP) associé au type de flux (STR_ID) dans le flux de données, l’indicateur de priorité appartenant à un groupe comprenant au moins un premier indicateur (IP_1) associé au premier type de flux (STR_1) et un deuxième indicateur (IP_2) associé au deuxième type de flux (STR_2), le premier indicateur et le deuxième indicateur de priorité ayant des valeurs distinctes ; et
-l’émission (38) du flux de données comprenant l’indicateur de priorité dans la tranche de réseau (SL_1) sélectionnée.
Procédé d’émission d’un flux de données selon la revendication 1, caractérisé en ce qu’il comprend :
- la réception préalable (30) d’au moins une règle d’acheminement (R_UE) d’un flux de données émis par ladite application logicielle, ladite règle comprenant au moins un identifiant de ladite application logicielle, ledit type de flux, ledit indicateur de priorité (IP) associé audit type de flux et un identifiant (SL_1) d’une dite tranche de réseau;
- le stockage en mémoire de ladite au moins une règle d’acheminement et
- l’application de ladite au moins une règle d’acheminement lors de la mise en œuvre de ladite sélection (33) et de ladite insertion (37).
Procédé d’émission d’un flux de données selon la revendication 2, caractérisé en ce qu’il comprend en outre l’obtention (35) d’un mode opératoire de ladite application logicielle, ledit mode opératoire appartenant à un groupe comprenant au moins un premier mode opératoire (MO_1) et un deuxième mode opératoire (MO_2), et en ce que ladite au moins une règle d’acheminement est associée audit mode opératoire.
Procédé de traitement d’un flux de données (STR) dans un réseau de communication (RC), ledit réseau étant découpé en une pluralité de tranches de réseau, caractérisé en ce que, ledit flux de données ayant été émis selon le procédé d’émission d’un flux de données conforme à l’une quelconque des revendications 1 à 3 et reçu dans unedite tranche de réseau de ladite pluralité en provenance d’une application logicielle s’exécutant sur un équipement terminal (UE, IoT) connecté à audit réseau, le procédé est mis en œuvre par une entité d’exécution (EXE) du réseau et comprend :
- la détection (41) d’un indicateur de priorité (IP) dudit flux dans un ledit flux de données ;
- l’évaluation (42) d’un niveau de ressources disponibles dans la tranche de réseau ;
- l’exécution (44) d’au moins une action de traitement (AC) dudit flux de données au moins en fonction dudit indicateur de priorité (IP) et du niveau (NRS_1)de ressources réseau disponibles dans ladite tranche de réseau (SL_1), ladite action de traitement (AC) appartenant à un groupe comprenant au moins une première action (AC_1) de laisser-passer du flux de données dans ladite tranche de réseau, lorsque le niveau de ressources disponibles est suffisant pour acheminer le flux de données selon l’indicateur de priorité (IP) et une deuxième action (AC_2) de blocage du flux de données dans ladite tranche de réseau, destinée à être mise en œuvre lorsque le niveau de ressources réseau disponibles est insuffisant.
Procédé de traitement d’un flux de données selon la revendication précédente, caractérisé en ce qu’il comprend l’obtention préalable (430) d’au moins une règle de traitement (R_UP) d’un flux de données reçu de ladite application logicielle, ladite règle comprenant ledit indicateur de priorité (IP) d’un flux de données, ledit identifiant de tranche de réseau (SL_1) et ladite au moins une action de traitement (AC) dudit flux, et l’extraction (431) de l’action de traitement de ladite règle.
Procédé de traitement d’un flux de données selon la revendication 4, caractérisé en ce que, lorsqu’aucune règle de traitement n’a été préalablement obtenue pour traiter ledit flux de données, ledit procédé comprend en outre la notification (431’) dudit indicateur de priorité à une entité de contrôle (CTR) dudit réseau et la réception (432’), en provenance de ladite entité de contrôle, de ladite au moins une action de traitement à exécuter.
Procédé de traitement d’un flux de données selon l’une quelconque des revendications 4 à 6, caractérisé en ce que, l’entité d’exécution étant configurée pour gérer la tranche de réseau (SL_1) et au moins une autre tranche de réseau (SL_2) dudit réseau de communication (RC), lorsque l’action de traitement est la deuxième action (AC_2) de blocage du flux de données dans la tranche de réseau (SL_1), le procédé comprend, préalablement à l’exécution de la deuxième action de traitement :
- l’évaluation (60) d’un niveau de ressources (NRS_2) dans l’autre tranche de réseau (SL_2) ;
- la décision (61) d’au moins une troisième action de traitement, dite action de transfert (AC_3) du flux de données dans l’autre tranche de réseau (SL_2), en fonction dudit niveau de ressources (NRS_2) et de l’indicateur de priorité (IP).
Procédé de contrôle du traitement d’un flux de données (STR) dans un réseau de communications, ledit réseau de communications étant découpé en une pluralité de tranches de réseau, ledit flux de données ayant été émis par un équipement terminal (UE, IoT) selon un procédé d’émission d’un flux de données conforme à l’une quelconque des revendications 1 à 3, et reçu par une entité d’exécution (EXE) dudit réseau dans une tranche de réseau (SL_1) de ladite pluralité , selon un procédé de traitement d’un flux de données conforme à l’une quelconque des revendications 4 à 7, caractérisé en ce que ledit procédé est mis en œuvre par une entité de contrôle (CTR) dudit réseau, ladite entité de contrôle étant configurée pour contrôler la mise en œuvre d’une politique de traitement des flux de données acheminés dans ledit réseau et en ce que ledit procédé comprend :
- la réception (50) en provenance de l’entité d’exécution d’une notification (NTF) d’un indicateur de priorité (IP) associé audit flux de données (STR) reçu ;
- l’obtention (51) d’un niveau de ressources (NRS_1) disponibles dans la tranche de réseau (SL_1) ;
- la décision (53) d’au moins une action de traitement dudit flux au moins en fonction de l’indicateur de priorité (IP) reçu et du niveau de ressources disponibles (NRS_1), ladite action de traitement appartenant à un groupe comprenant au moins une première action (AC_1) de laisser-passer du flux de données dans ladite tranche de réseau destinée à être mise en œuvre lorsque le niveau de ressources réseau disponibles est suffisant pour acheminer le flux de données selon l’indicateur de priorité (IP) et une deuxième action (AC_2) de blocage du flux de données dans ladite tranche de réseau destinée à être mise en œuvre lorsque le niveau de ressources réseau disponibles est insuffisant ; et
- l’envoi (54) d’une réponse à ladite entité d’exécution, ladite réponse comprenant ladite action de traitement.
Procédé de contrôle d’un flux de données selon la revendication précédente, caractérisé en ce que, lorsque l’action de traitement décidée est l’action (AC_2) de blocage dudit flux de données dans la tranche de réseau et lorsque l’entité d’exécution est configurée pour gérer une autre tranche de réseau (SL_2) de ladite pluralité, ledit procédé comprend, préalablement à la transmission de la deuxième action de traitement à l’entité d’exécution (EXE) :
- l’obtention d’un niveau de ressources (NRS_2) disponibles dans l’autre tranche de réseau (SL_2) ;
- la décision (61) d’au moins une troisième action de traitement, dite action de transfert (AC_3) du flux de données dans l’autre tranche de réseau (SL_2), en fonction dudit niveau de ressources (NRS_2) et de l’indicateur de priorité (IP).
Dispositif (100) d’émission d’un flux de données par une application logicielle s’exécutant sur un équipement terminal (UE, IoT), dans un réseau de communications auquel est connecté ledit terminal, ledit réseau étant découpé en une pluralité de tranches de réseau, caractérisé en ce que ledit dispositif est configuré pour mettre en œuvre au niveau de l’équipement terminal :
- la sélection d’une tranche de réseau (SL_1) de ladite pluralité au moins en fonction d’une information comprise dans un en-tête du flux de données ;
- l’obtention d’un type dudit flux, ledit type appartenant à un groupe comprenant au moins un premier type (STR_1) et un deuxième type de flux (STR_2), et
- l’insertion d’un indicateur de priorité (IP) associé au type de flux (STR_ID) dans le flux de données, l’indicateur de priorité appartenant à un groupe comprenant au moins un premier indicateur (IP_1) associé au premier type de flux (STR_1) et un deuxième indicateur (IP_2) associé au deuxième type de flux (STR_2), le premier indicateur et le deuxième indicateur de priorité ayant des valeurs distinctes ; et
-l’émission (38) du flux de données (STR) comprenant ledit indicateur de priorité, dans la tranche de réseau (SL_1) sélectionnée.
Dispositif (200) de traitement d’un flux de données (STR) dans un réseau de communication (RC), ledit réseau étant découpé en une pluralité de tranches de réseau, ledit flux de données ayant été reçu dans unedite tranche de réseau de ladite pluralité, en provenance d’une application logicielle s’exécutant sur un équipement terminal (UE, IoT) connecté à audit réseau, ledit flux de données ayant été émis par un dispositif d’émission d’un flux de données selon la revendication 10, caractérisé en ce que le dispositif de traitement est configuré pour mettre en œuvre au niveau d’une entité d’exécution (EXE) du réseau:
- la détection (41) d’un indicateur de priorité (IP) dudit flux dans ledit flux de données ;
l’évaluation (42) d’un niveau de ressources disponibles dans la tranche de réseau ;
- l’exécution (44) d’au moins une action de traitement (AC) dudit flux de données au moins en fonction dudit indicateur de priorité (IP) et du niveau (NRS) de ressources réseau disponibles dans ladite tranche de réseau (SL_1), ladite action de traitement (AC) appartenant à un groupe comprenant au moins une première action (AC_1) de laisser-passer du flux de données dans ladite tranche de réseau, lorsque le niveau de ressources disponibles est suffisant et une deuxième action (AC_2) de blocage du flux de données dans ladite tranche de réseau, destinée à être mise en œuvre lorsque le niveau de ressources réseau disponibles est insuffisant.
Dispositif (300) de contrôle du traitement d’un flux de données (STR) dans un réseau de communications, ledit réseau de communications étant découpé en une pluralité de tranches de réseau, ledit flux de données ayant été émis au niveau d’un équipement terminal (UE, IoT) par un dispositif d’émission d’un flux de données selon la revendication 10, reçu par une entité d’exécution (EXE) dudit réseau dans une tranche de réseau (SL_1) de ladite pluralité et traité au niveau de ladite entité d’exécution par un dispositif de traitement selon la revendication 11, caractérisé en ce que ledit dispositif de contrôle est configuré pour mettre en œuvre au niveau d’une entité de contrôle (CTR) dudit réseau, ladite entité de contrôle étant configurée pour contrôler la mise en œuvre d’une politique de traitement des flux de données acheminés dans ledit réseau:
- la réception en provenance de l’entité d’exécution d’une notification (NTF) d’un indicateur de priorité (IP) associé audit flux de données (STR) reçu ;
- l’obtention d’un niveau de ressources (NRS_1) disponibles dans la tranche de réseau (SL_1) ;
- la décision d’au moins une action de traitement dudit flux au moins en fonction de l’indicateur de priorité (IP) reçu et du niveau de ressources disponibles (NRS_1), ladite action de traitement appartenant à un groupe comprenant au moins une première action (AC_1) de laisser-passer du flux de données dans ladite tranche de réseau destinée à être mise en œuvre lorsque le niveau de ressources réseau disponibles est suffisant et une deuxième action (AC_2) de blocage du flux de données dans ladite tranche de réseau destinée à être mise en œuvre lorsque le niveau de ressources réseau disponibles est insuffisant ; et
- l’envoi d’une réponse à ladite entité d’exécution, ladite réponse comprenant ladite action de traitement.
Equipement terminal (UE, IoT) connecté à un réseau de communications (RC), ledit réseau étant découpé en une pluralité de tranches de réseau, caractérisé en ce qu’il comprend un dispositif (100) d’émission d’un flux de données dans une tranche de réseau de ladite pluralité selon la revendication 10.
Système (S) de contrôle de flux de données acheminés dans un réseau de communications (RC), caractérisé en ce qu’il comprend au moins un dispositif (100) d’émission d’un flux de données selon la revendication 10, un dispositif (200) de traitement d’un flux de données selon la revendication 11 et un dispositif (300) de contrôle du traitement d’un flux de données selon la revendication 12.
Programme d’ordinateur comprenant des instructions de code de programme pour la mise en œuvre d’un procédé selon l'une quelconque des revendications 1 à 9, lorsqu’il est exécuté par un processeur.