FR3113346A1 - Procédé de traitement d’un service de transport de données - Google Patents
Procédé de traitement d’un service de transport de données Download PDFInfo
- Publication number
- FR3113346A1 FR3113346A1 FR2008388A FR2008388A FR3113346A1 FR 3113346 A1 FR3113346 A1 FR 3113346A1 FR 2008388 A FR2008388 A FR 2008388A FR 2008388 A FR2008388 A FR 2008388A FR 3113346 A1 FR3113346 A1 FR 3113346A1
- Authority
- FR
- France
- Prior art keywords
- data
- connector
- transport service
- processing
- path
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Withdrawn
Links
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/10—Protocols in which an application is distributed across nodes in the network
- H04L67/1097—Protocols in which an application is distributed across nodes in the network for distributed storage of data in networks, e.g. transport arrangements for network file system [NFS], storage area networks [SAN] or network attached storage [NAS]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/10—Protocols in which an application is distributed across nodes in the network
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/50—Network services
- H04L67/56—Provisioning of proxy services
- H04L67/567—Integrating service provisioning from a plurality of service providers
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/50—Network services
- H04L67/60—Scheduling or organising the servicing of application requests, e.g. requests for application data transmissions using the analysis and optimisation of the required network resources
- H04L67/63—Routing a service request depending on the request content or context
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/04—Network management architectures or arrangements
- H04L41/046—Network management architectures or arrangements comprising network management agents or mobile agents therefor
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L43/00—Arrangements for monitoring or testing data switching networks
- H04L43/08—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters
- H04L43/0805—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters by checking availability
- H04L43/0811—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters by checking availability by checking connectivity
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/12—Protocols specially adapted for proprietary or special-purpose networking environments, e.g. medical networks, sensor networks, networks in vehicles or remote metering networks
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
Abstract
Procédé de traitement d’un service de transport de données Les espaces virtuels de données établis à partir d’une pluralité d’espaces de stockage et permettant d’agréger des données provenant de ces différents espaces ne permettent pas selon les techniques connues de pouvoir acheminer les données de façon optimisée vers un client requérant ces données. L’invention vise à apporte une solution à ce problème et concerne un procédé de de traitement d’un service de transport de données dans un espace virtuel de données déployé sur une infrastructure de communications. L’espace virtuel de données comprend une pluralité de sites comprenant chacun un serveur de communication, aussi appelé connecteur, apte à héberger une donnée ou une application de traitement des données, le procédé mis en œuvre par une entité d’optimisation apte à communiquer avec le connecteur comprend la réception d’une requête de déploiement du service de transport de données en provenance d’un agent de gestion des données, l’obtention d’un paramètre de connectivité à l’infrastructure de communication d’un connecteur d’un site parmi la pluralité, ledit connecteur contribuant au service de transport des données de la requête reçue, ainsi que la détermination d’au moins un chemin d’acheminement des données dans l’espace virtuel de données, l’au moins un chemin comprenant une suite ordonnée de connecteurs sélectionnés en fonction du paramètre de connectivité obtenu. Figure pour l'abrégé : Fig. 3
Description
1. Domaine technique
L'invention se situe dans une infrastructure de communications permettant à un dispositif client d’obtenir un service élaboré à partir de données issues de plusieurs espaces de stockage. L’invention vise plus spécifiquement à permettre d’améliorer la qualité du service proposé au client en permettant un acheminement optimisé des données entre différentes entités.
2. Etat de la technique
La fourniture de services, relatifs à des applications industrielles, tertiaires, médicales ou relatives à l’internet des objets, repose de plus en plus sur la mise à disposition de données par des entités distinctes et diverses. Ainsi, des fournisseurs d’applications, des entités de sécurité, des opérateurs de réseaux de communications mettent à disposition leurs propres données pour élaborer le service requis par un client. Les données sont ainsi de plus en plus partagées dans des espaces de données (en anglais data-space) pouvant dépasser les frontières et se déployer au niveau international. Ce partage de données doit cependant être mis en œuvre dans un contexte où chaque entité veut contrôler ses données et ne pas laisser à disposition ses données pour un traitement, une exploitation ou une fourniture à une entité tierce à des entités n’en ayant pas l’autorisation. Deux objectifs antagonistes sont donc à considérer dans les architectures de communications actuellement étudiées : d’une part il existe un besoin de mettre à disposition des données à des entreprises tout en s’assurant que les données mises à disposition sont maintenues sous contrôle du propriétaire de ces données. Une donnée doit donc être acheminée en toute confiance dans un espace virtuel de données comprenant des serveurs de données de partenaires distincts. Un espace virtuel de données définit donc une infrastructure de collaboration sécurisée où les données sont échangées en toute confiance car chaque partenaire respecte les mêmes politiques d’échange et de contrôle des données.
Afin de spécifier un cadre d’échange de données, des partenaires ont ainsi initié un forum IDSA (en anglais International Data Spaces Association) qui définit notamment dans le document https://www.internationaldataspaces.org/wp-content/uploads/2019/03/IDS-Reference-Architecture-Model-3.0.pdf une architecture et des mécanismes d’échanges de données entre des entités distinctes. L’une des pierres angulaires d’une telle architecture repose sur des « connecteurs » certifiés utilisés pour interconnecter les différents espaces maintenus par les différents partenaires. Ainsi, il est possible de déployer un espace virtuel de données, correspondant en quelque sorte à un cloud distribué, où chaque partenaire intervenant dans le cloud distribué met à disposition des données qu’il possède pour élaborer un service pour un client. Un connecteur est ainsi utilisé pour collecter les données et les déposer dans un espace de stockage commun aux membres de l’espace virtuel de données, par exemple en périphérie d’un réseau de communications (en anglais edge). L’espace virtuel de données prévoit que chaque entité dispose d’au moins un connecteur pouvant communiquer avec les connecteurs des autres partenaires de l’espace virtuel de données. L’échange de données devant être sécurisé, chaque connecteur doit pouvoir être identifié et authentifié de façon sûre et le connecteur d’une entité doit pouvoir s’assurer que les données qu’il met à disposition sont utilisées par les autres entités et notamment le dispositif client de façon conforme aux caractéristiques de sécurité des données établies par les prestataires respectifs de l’espace virtuel de données. Un connecteur peut être intégré à un équipement d’un réseau fixe ou d’un réseau mobile, indifféremment. Une fois qu’un connecteur a été identifié, accepté et configuré dans l’espace virtuel de données et que celui-ci est notamment connu d’un agent de courtage des données (en anglais data broker), l’échange de données peut opérer. Un consommateur de données (en anglais Data Consumer) également muni d’un connecteur sollicite l’agent ou directement un ou plusieurs fournisseurs de données (en anglais Data Provider) s’il le(s) connaît déjà pour transférer, récupérer, transformer ou obtenir des données des fournisseurs de données. Les données peuvent elle-même comprendre des informations relatives aux politiques d’utilisation de ces données et/ou une politique générale des données échangées entre un consommateur et un fournisseur pour les données échangées entre ces deux entités. Il est à noter que la mise à disposition de données peut s’accompagner de mises à disposition d’applications utilisées par les connecteurs pour effectuer un traitement de données à partir d’une application. La mise à disposition d’applications dans l’espace virtuel de données est comparable à la mise à disposition de données si ce n’est que l’agent est identifié comme un magasin d’applications (en anglais Applications Store). Un connecteur peut donc requérir une application d’un magasin en fonction de ses besoins.
Dans les informations de configuration des connecteurs, des informations d’identification et de communication existent, notamment des adresses IP et des ports de communication utilisés mais les connecteurs des fournisseurs de données et/ou d’applications communiquent avec le(s) consommateur(s) de données et/ou d’applications en mode overlay, par exemple sur la base de tunnels, par exemple de type TLS, établis sur les infrastructures de communications existantes ou en utilisant un protocole de type HTTPS. Ceci qui ne permet pas d’une part d’établir un chemin dynamique entre les connecteurs des partenaires et d’autre part, les caractéristiques inhérentes des réseaux de communications, en termes de routage, de qualité de service, de débit ne sont pas pris en compte pour le transfert des données dans l’espace virtuel de données. L’échange de données dans l’espace n’est ainsi pas optimisé et le service basé sur l’échange des données ne bénéficie pas d’une qualité possiblement adaptée au service consommé.
La présente invention a pour objet d’apporter des améliorations par rapport à l’état de la technique.
3. Exposé de l'invention
L'invention vient améliorer la situation à l'aide d'un procédé de traitement d’un service de transport de données dans un espace virtuel de données déployé sur une infrastructure de communications, l’espace virtuel de données comprenant une pluralité de sites comprenant chacun un serveur de communication, aussi appelé connecteur, apte à héberger une donnée ou une application de traitement des données, le procédé mis en œuvre par une entité d’optimisation apte à communiquer avec le connecteur et comprenant :
- la réception d’une requête de déploiement du service de transport de données en provenance d’un agent de gestion des données,
- l’obtention d’un paramètre de connectivité à l’infrastructure de communication d’un connecteur d’un site parmi la pluralité, ledit connecteur contribuant au service de transport des données de la requête reçue,
- la détermination d’au moins un chemin d’acheminement des données dans l’espace virtuel de données, l’au moins un chemin comprenant une suite ordonnée de connecteurs sélectionnés en fonction du paramètre de connectivité obtenu.
- la réception d’une requête de déploiement du service de transport de données en provenance d’un agent de gestion des données,
- l’obtention d’un paramètre de connectivité à l’infrastructure de communication d’un connecteur d’un site parmi la pluralité, ledit connecteur contribuant au service de transport des données de la requête reçue,
- la détermination d’au moins un chemin d’acheminement des données dans l’espace virtuel de données, l’au moins un chemin comprenant une suite ordonnée de connecteurs sélectionnés en fonction du paramètre de connectivité obtenu.
Selon la technique antérieure, une entité cliente ou consommatrice de données sollicite un agent de données pour identifier des serveurs aussi appelés connecteurs en charge d’héberger certaines des données demandées par le consommateur et/ou des connecteurs comprenant une application apte à appliquer un traitement aux données sollicitées. Ensuite, l’entité consommatrice sollicite chaque connecteur pour récupérer les données et leur appliquer le traitement requis. Le procédé de traitement améliore avantageusement cette solution en tirant parti des caractéristiques de transmission ou de connectivité de l’infrastructure de communications sur laquelle est déployé l’espace virtuel de données mais aussi en permettant un transport des données entre les différents connecteurs pour permettre la récupération des données et leur traitement dans un temps réduit. En effet, le procédé permet de sélectionner des connecteurs ayant une caractéristique de connectivité adaptée au service de transport des données, mais aussi d’éviter de dupliquer des données en tirant parti d’un chainage des connecteurs dans l’élaboration du chemin de transport des données. D’autre part, la mise à jour de l’espace virtuel de données en déployant au besoin des nouveaux sites et/ou des nouveaux connecteurs permet de disposer d’un espace virtuel de données adapté aux besoins des consommateurs. L’espace virtuel de données peut en outre être mieux organisé en permettant que les traitements de données les plus courants, exprimés dans les requêtes de déploiement de services de transport reçus, soient effectués à proximité des connecteurs comprenant les données. Ces données rendues disponibles lors des offres et des demandes précédentes sont ainsi prises en compte par l’entité d’optimisation pour la sélection de fonctions de traitement dans des connecteurs et pour optimiser leur placement si de nouvelles fonctions sont à déployer pour une requête de déploiement d’un transport de données. L’entité d’optimisation mettant en œuvre le procédé de traitement est ainsi nouvelle et inventive puisqu’elle permet d’établir un chemin d’acheminement entre différents connecteurs permettant d’éviter la sollicitation d’un connecteur consommateur de données vers une pluralité de connecteurs fournisseurs de données et/ou d’applications de traitement. Le procédé permet ainsi d’agréger les différentes données issues de différents connecteurs, d’appliquer un traitement de ces données ou d’une partie de ces données au plus près des connecteurs où ils sont localisés et de les acheminer selon un chemin améliorant la qualité de service de leur acheminement grâce à un routage des données de proche en proche entre les connecteurs jusqu’au consommateur des données ou le client ayant émis la requête de déploiement du service de transport.
Selon un aspect de l'invention, le procédé de traitement comprend en outre l’obtention d’au moins un identifiant relatif au service de transport de la requête de déploiement reçue parmi les identifiants suivants:
- un identifiant d’un connecteur d’un site d’un fournisseur d’une donnée du service de transport,
-un identifiant d’un connecteur d’un site d’un consommateur des données du service de transport,
- un identifiant d’une application de traitement d’une donnée du service de transport,
- un identifiant selon un graphe de données « Separation of Concern » d’une donnée du service de transport.
- un identifiant d’un connecteur d’un site d’un fournisseur d’une donnée du service de transport,
-un identifiant d’un connecteur d’un site d’un consommateur des données du service de transport,
- un identifiant d’une application de traitement d’une donnée du service de transport,
- un identifiant selon un graphe de données « Separation of Concern » d’une donnée du service de transport.
L’obtention d’identifiants auprès de l’agent de données ou bien directement en provenance des fournisseurs de données et des consommateurs de données pour ce qui concerne ces identifiants permet de pouvoir déterminer la suite ordonnée de connecteurs de façon non ambiguë, notamment en utilisant des identifiants publiques tels que des noms FQDN ou des adresses IP. L’utilisation d’un graphe de données « Separation of Concern » enrichi avec les identifiants des connecteurs acheminant les données sur le chemin permet de pouvoir s’assurer que les données ont transité par des connecteurs effectivement habilités à recevoir et traiter ces données, garantissant que les données ne sont pas diffusées à des entités non autorisées. Les identifiants des applications permettent au consommateur des données de savoir quels types de traitement ont notamment effectivement été effectués sur les données reçues.
Selon un autre aspect de l’invention, dans le procédé de traitement, la requête de déploiement comprend en outre une règle associée à la politique de gestion des données du service de transport.
Un espace virtuel de données permet de pouvoir échanger des données entre entités et notamment à une entité « consommateur » de pouvoir obtenir des données de différents « fournisseurs » mais l’espace virtuel de données doit également permettre de garantir notamment au fournisseur de données que ses données ne sont pas diffusées à des entités non autorisées. La présence de règles associées aux données dans la requête de déploiement permet aux entités répondant à cette requête de s’assurer que les règles sont compatibles avec leurs politiques de gestion de leurs données. Les règles peuvent correspondre à des droits de retransmission, à des droits ne permettant une diffusion des données que dans le cadre de la requête de déploiement ou bien encore des règles qui autorisent une diffusion plus large de ces données à d’autres entités.
Selon un autre aspect de l’invention, le procédé de traitement comprend en outre l’obtention d’un identifiant d’un fournisseur de connectivité à l’infrastructure de communications associé à l’identifiant du fournisseur ou du consommateur d’une donnée du service de transport obtenu.
La fourniture d’un identifiant d’un fournisseur de connectivité en plus d’un identifiant d’un fournisseur de donnée autorise d’une part à compléter le graphe d’identification d’une donnée avec non seulement les identifiants des fournisseurs et des consommateurs mais aussi avec des identifiants de fournisseurs de connectivité des connecteurs à l’infrastructure. Ainsi, un connecteur bénéficiant d’une connectivité auprès d’un fournisseur assurant un haut niveau de sécurité de son infrastructure de transport pourra améliorer la confidentialité des données acheminées conformément aux règles associées à la politique de gestion de ces données.
Selon un autre aspect de l’invention, dans le procédé de traitement, le paramètre de connectivité comprend au moins une caractéristique de transmission parmi les caractéristiques suivantes :
- un temps de propagation d’un paquet de données entre un connecteur et un point d’accès de l’infrastructure de communication,
- un type de technologie utilisée pour l’acheminement de données entre un connecteur et un point d’accès de l’architecture de communication,
- une bande passante associée à un connecteur,
- une bande passante disponible pour l’acheminement d’une donnée du service de transport.
- un temps de propagation d’un paquet de données entre un connecteur et un point d’accès de l’infrastructure de communication,
- un type de technologie utilisée pour l’acheminement de données entre un connecteur et un point d’accès de l’architecture de communication,
- une bande passante associée à un connecteur,
- une bande passante disponible pour l’acheminement d’une donnée du service de transport.
Différents paramètres de connectivité d’un connecteur à une infrastructure de communication peuvent être pris en compte pour s’assurer d’un acheminement conforme aux besoins exprimés par exemple dans la requête de déploiement. Ainsi, le temps de propagation d’un paquet de données, notamment en utilisant des paquets de type ICMP, ou des informations sur la bande passante, totale ou disponible c’est-à-dire à celle qui peut effectivement être utilisée pour le service de transport de données, sont particulièrement pertinents. Le type de technologie (Fibre, xDSL, 4G, 5G..) utilisée pour l’attachement d’un connecteur à l’infrastructure renseigne sur le niveau de disponibilité et de qualité de la connexion, sur la latence ainsi que sur les mécanismes de sécurité associés au transport des données.
Selon un autre aspect de l’invention, le procédé de traitement comprend en outre l’obtention d’une caractéristique logicielle d’une application requise pour le service de transport de données.
Le service de transport de données comprend des données, un chemin pour acheminer des données et des applications effectuant un traitement de ces données. L’entité d’optimisation peut avantageusement obtenir, par exemple auprès d’un agent du logiciel (Software Broker) des informations concernant les licences associées aux logiciels utilisés pour le traitement des données, les délais de traitement requis pour la données conformément à la requête de déploiement reçue, ainsi que des caractéristiques des entités requises pour l’instanciation de logiciels dans le cas où de nouvelles applications doivent être instanciées pour le service de transport. Les caractéristiques de l’application peuvent contenir les informations sur le volume de données qui doivent être transmis à l’application pour que l’application puisse réaliser ces traitements ainsi que le volume de données que l’application doit transmettre. Ces informations associées avec les caractéristiques de souscriptions aux données via l’agent de gestion de données peuvent être utiles pour déterminer la bande passante entre les connecteurs et définir la qualité de service que les opérateurs de connectivités doivent appliquer.
Selon un autre aspect de l’invention, dans le procédé de traitement, la détermination de l’au moins un chemin comprend l’identification d’un connecteur apte à accueillir une application de traitement des données dans l’espace virtuel de données en fonction de la requête de déploiement reçue.
L’entité d’optimisation, dans l’étape de détermination, identifie les connecteurs aptes à fournir des données et/ou les entités aptes à effectuer un traitement par exemple en utilisant les informations obtenues des fournisseurs eux-mêmes ou bien en utilisant ses propres données obtenues précédemment. Le chemin déterminé comme le plus adapté pour garantir un niveau de qualité de service requis pour l’acheminement des données peut requérir le déploiement de nouveaux connecteurs, par exemple pour déployer de nouvelles applications de traitement. Dans ce cas, l’entité d’optimisation sélectionne un connecteur pour instancier l’application requise en utilisant notamment les paramètres de connectivité du connecteur disponibles.
Selon un autre aspect de l’invention, dans le procédé de traitement, la détermination de l’au moins un chemin comprend la sélection d’un nouveau site apte à accueillir un nouveau connecteur dont une caractéristique de connectivité est compatible avec l’espace virtuel de données.
Dans le cas où aucun connecteur ne peut être sélectionné pour fournir le service de transport des données avec la qualité requise, le déploiement de nouveaux connecteurs, connectés à l’infrastructure de communications selon des paramètres de connectivité requis pour la fourniture du service de transport de données, peut être envisagé. L’espace virtuel de données est ainsi dynamiquement mis à jour avec de nouveaux connecteurs pouvant héberger des données et/ou des applications en charge d’un traitement de ces données.
Selon un autre aspect de l’invention, dans le procédé de traitement, la détermination de l’au moins un chemin comprend le calcul pour l’au moins un chemin d’un paramètre de qualité de transport des données sur le chemin.
L’étape de détermination permet possiblement d’identifier plusieurs chemins possibles pour le transport des données, et notamment pour les traitements successifs de ces données sur les chemins. La sélection d’un chemine peut être opérée par un consommateur des données. Afin de permettre cette sélection, l’entité d’optimisation peut avantageusement qualifier chaque chemin déterminé avec un paramètre de qualité de transport. Par exemple, il pourra s’agir d’une durée d’acheminement et de traitement de données de test, cette durée pouvant résulter d’un test effectué par l’entité d’optimisation sur les différents chemins afin de les calibrer.
Selon un autre aspect de l’invention, le procédé de traitement comprend en outre l’émission à destination d’un fournisseur d’une donnée et/ou d’un consommateur des données de l’au moins un chemin.
La sélection d’un chemin peut être opérée par un consommateur des données en fonction de ses propres besoins en termes de qualité de transport des données ou bien par une autre entité en fonction de ses objectifs de confidentialité des données transmises par exemple. Le procédé peut donc comprendre une étape d’envoi à une entité en charge de la sélection des différents chemins et possiblement des informations de qualité de transport, de connectivité des connecteurs utilisés pour le transport, d’identification des sites où sont déployés les connecteurs voire d’informations sur les logiciels appliquant un traitement des données.
Selon un autre aspect de l’invention, le procédé de traitement comprend en outre la configuration des connecteurs du chemin sélectionné parmi l’au moins un chemin déterminé.
Une fois le chemin sélectionné, par exemple suite à une information reçue de l’entité en charge de la sélection si tel est le cas, l’entité d’optimisation met en place le chemin. Cette instanciation peut comprendre la configuration du circuit entre les connecteurs, le déploiement de nouvelles applications et/ou de nouveaux connecteurs. Sachant que les connecteurs sont gérés par les sites et plus précisément par les opérateurs de ces sites, l’instanciation pourra avantageusement être opérée en sollicitant les différents agents (brokers) des sites de stockage (MEC) pour les connecteurs existants ou à déployer, les agents logiciels pour les nouvelles applications requises, ainsi que les entités en charge de l’infrastructure pour assurer la connectivité des connecteurs à cette infrastructure. Cette instanciation pourra en outre comprendre la mise à jour des graphes de données comprenant les informations sur le nouveau circuit mis en place et possiblement utilisable pour d’autres services si les besoins de qualité de service et de confidentialité des données sont compatibles.
Les différents aspects du procédé de traitement qui viennent d'être décrits peuvent être mis en œuvre indépendamment les uns des autres ou en combinaison les uns avec les autres.
L’invention concerne également un dispositif de traitement d’un service de transport de données dans un espace virtuel de données déployé sur une infrastructure de communications, l’espace virtuel de données comprenant une pluralité de sites comprenant chacun un serveur de communication, aussi appelé connecteur, apte à héberger une donnée ou une application de traitement des données, apte à communiquer avec le connecteur et comprenant :
- un récepteur, apte à recevoir une requête de déploiement du service de transport de données en provenance d’un agent de gestion des données,
- un module d’obtention, apte à obtenir un paramètre de connectivité à l’infrastructure de communication d’un connecteur d’un site parmi la pluralité, ledit connecteur contribuant au service de transport des données de la requête reçue,
- un calculateur, apte à déterminer au moins un chemin d’acheminement des données dans l’espace virtuel de données, l’au moins un chemin comprenant une suite ordonnée de connecteurs sélectionnés en fonction du paramètre de connectivité obtenu.
- un récepteur, apte à recevoir une requête de déploiement du service de transport de données en provenance d’un agent de gestion des données,
- un module d’obtention, apte à obtenir un paramètre de connectivité à l’infrastructure de communication d’un connecteur d’un site parmi la pluralité, ledit connecteur contribuant au service de transport des données de la requête reçue,
- un calculateur, apte à déterminer au moins un chemin d’acheminement des données dans l’espace virtuel de données, l’au moins un chemin comprenant une suite ordonnée de connecteurs sélectionnés en fonction du paramètre de connectivité obtenu.
Ce dispositif, apte à mettre en œuvre dans tous ses modes de réalisation le procédé de traitement qui vient d'être décrit, est destiné à être mis en œuvre dans une entité de gestion d’un service applicatif ou bien dans une entité de gestion d’un réseau de télécommunications, déployé à base de fonctions virtualisées ou d’équipements physiques.
L’invention concerne aussi un système de traitement d’un service de transport de données dans un espace virtuel de données déployé sur une infrastructure de communications, l’espace virtuel de données comprenant une pluralité de sites comprenant chacun un serveur de communication, aussi appelé connecteur, apte à héberger une donnée ou une application de traitement des données, ledit système comprenant :
- une entité d’optimisation comprenant un dispositif de traitement et un agent de gestion des données apte à émettre une requête de déploiement du service de transport de données à destination de l’entité d’optimisation.
- une entité d’optimisation comprenant un dispositif de traitement et un agent de gestion des données apte à émettre une requête de déploiement du service de transport de données à destination de l’entité d’optimisation.
L'invention concerne aussi un programme d'ordinateur comprenant des instructions pour la mise en œuvre des étapes du procédé de triatment qui vient d'être décrit, lorsque ce programme est exécuté par un processeur et un support d’enregistrement lisible par un dispositif de détermination sur lequel est enregistré le programmes d’ordinateur.
Ce 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 aussi un support d'informations lisible par un ordinateur, et comportant des instructions du programme d'ordinateur tel que mentionné ci-dessus.
Le support d'informations peut être n'importe quelle entité ou dispositif capable de stocker les programmes. Par exemple, le support peut comporter un moyen de stockage, tel qu'une ROM, par exemple un CD ROM ou une ROM de circuit microélectronique, ou encore un moyen d'enregistrement magnétique, par exemple sur un disque dur.
Le support d'informations peut être n'importe quelle entité ou dispositif capable de stocker les programmes. Par exemple, le support peut comporter un moyen de stockage, tel qu'une ROM, par exemple un CD ROM ou une ROM de circuit microélectronique, ou encore un moyen d'enregistrement magnétique, par exemple sur un disque dur.
D'autre part, le support d'informations peut être un support transmissible tel qu'un signal électrique ou optique, qui peut être acheminé via un câble électrique ou optique, par radio ou par d'autres moyens. Le programme selon l'invention peut être en particulier téléchargé sur un réseau de type Internet.
Alternativement, le support d'informations peut être un circuit intégré dans lequel le programme est incorporé, le circuit étant adapté pour exécuter ou pour être utilisé dans l'exécution du procédé en question.
4. Brève description des dessins
D’autres caractéristiques et avantages de l’invention apparaîtront plus clairement à la lecture de la description suivante de modes de réalisation particuliers, donnés à titre de simples exemples illustratifs et non limitatifs, et des dessins annexés, parmi lesquels :
La présente une vue simplifiée d’une infrastructure de communications comprenant un espace virtuel de données dans lequel un procédé de traitement d’un service de transport de données peut être mis en œuvre,
La présente un aperçu du procédé de traitement d’un service de transport de données selon un premier mode de réalisation de l’invention,
La présente un procédé de traitement d’un service de transport de données selon un premier mode de réalisation de l’invention,
La présente un exemple de structure d’un dispositif de traitement d’un service de transport de données selon un autre mode de réalisation de l’invention.
5. Description des modes de réalisation
Dans la suite de la description, on présente des modes de réalisation de l'invention dans une infrastructure de communications utilisant des moyens d’acheminement propres à un réseau fixe ou à un réseau mobile. Cette infrastructure peut être mise en œuvre pour acheminer des données de communications à destination de terminaux fixes ou mobiles et l’invention peut être destinée à installer des fonctions virtualisées utilisées pour l’acheminement et/ou le traitement de données de clientèle résidentielle ou d’entreprises.
On se réfère tout d’abord à la qui présente une vue simplifiée d’une infrastructure de communications comprenant un espace virtuel de données dans lequel un procédé de traitement d’un service de transport de données peut être mis en œuvre. L’infrastructure 1000 de communications comprend un espace virtuel de données comprenant une pluralité d’espace de stockage de données. Parmi ces espaces de données, on peut distinguer des espaces de données appartenant à des entreprises 60, 70, 80, 90. Ces entreprises 60, 70, 80, 90 partagent par exemple des données pour la mise en œuvre d’un service à destination d’un client non représenté sur la [Fig 1]. Les espaces de données peuvent également stockées dans des espaces cloud tel que l’espace 50. Les données peuvent également provenir de places de marché, c’est-à-dire d’espace où il est possible de stocker des données issues de différentes entités, ces données pouvant être ensuite donner lieu à une mise à disposition auprès d’autres entités. Ces places de marché permettent à des entités de négocier l’acquisition de données. Des entités peuvent en outre déposer des données dans des espaces à la périphérie, tel que l’espace 10 de l’infrastructure de communications, par exemple dans des espaces de données distribués de type MEC (Multi Access Edge Computing tel que spécifié dans https://www.etsi.org/technologies/multi-access-edge-computing). Selon d’autres mises en œuvre, un espace de données 30 peut être propre à un service IoT (en anglais Internet of Things), ou bien encore à un cloud 40 d’entreprise. L’espace virtuel de données, qui permet qu’une entité tierce puisse accéder à des données issus de plusieurs espaces de données via l’espace virtuel de données repose sur une architecture de sécurité pour qu’un fournisseur de données garde la maîtrise de ses données partagées et de leurs traitements et pour l’entité tierce d’avoir une garantie sur l’origine des données collectées. Ainsi, chaque espace 10, 20, 30, 40, 50, 60, 70, 80, 90 de données comprend un serveur 100, 200, 300, 400, 500, 600, 700, 800, 900 de communication, aussi appelé connecteur, permettant d’échanger des données ou de mettre à disposition d’entités tierces (client, autre entreprise, institution…). L’espace virtuel de données (EVD) intervenant doit permettre un échange de données sécurisé entre les différents acteurs intervenant dans ces échanges. Ces connecteurs sont utilisés pour collecter les données et les verser par exemple dans un espace de stockage commun aux membres de l’espace virtuel de données, par exemple en périphérie de réseau. Ceci permet aux membres de l’espace virtuel de données de dérouler leurs analyses localement sans exporter leurs données mais aussi de les échanger en fonction de règles établies avec des acquéreurs. Par exemple, les règles d’échanges permettent de spécifier qu’une donnée ne doit pas être exportée mais que les résultats de traitements sur ces données peuvent être exportés. Les politiques de diffusion des données échangées entre les connecteurs, ainsi que les règles de sécurité (confidentialité notamment) sont ainsi associées aux données dans un fichier comprenant les contraintes d’utilisation des données identifiées C1, C2, C3 sur la [Fig 1]. Un service de transport de données pourra par exemple comprendre la suite de connecteurs 100, 700, 800, 300 et ce transport de données pourra comprendre des applications de traitement comprises dans une partie ou l’ensemble des connecteurs de la suite. Les données des connecteurs de la suite pourront être qualifiées avec des contraintes d’utilisation des données associées à chaque connecteur.
En relation avec la , on présente un aperçu du procédé de traitement d’un service de transport de données selon un premier mode de réalisation de l’invention.
Sur la , un espace EVD virtuel de données est représenté. Dans cet espace EVD, une entité d’optimisation Optim en charge de mettre en œuvre le procédé de traitement de données d’un service de transport est déployée. Cette entité Optim peut par exemple être mise en œuvre dans une station d’administration de l’espace EVD virtuel de données.
Cette entité Optim a un rôle tout à fait nouveau et inventif par rapport aux architectures existantes IDSA. En effet, cette entité a notamment pour objet de collecter les informations des opérateurs de l’infrastructure de communications sur laquelle est déployé l’espace EVD virtuel de données. En effet, les différents espaces de données sont interconnectés grâce aux ressources de l’infrastructure 1000 de communications, décrite par exemple dans la . Ces informations sur la connectivité des espaces de données à l’infrastructure de communications sont avantageusement mises à profit pour l’acheminement des données dans l’espace EVD virtuel de données. Ces informations sont utilisées pour optimiser l’acheminement des données mais aussi pour optimiser leur traitement sachant que des applications déployées dans des espaces de données sont utilisées pour appliquer un traitement à ces données lors de leur acheminement.
L’espace EVD virtuel de données comprend en outre des entités propres à la gestion des espaces de données de type MEC. Ainsi, l’entité MEC Connec a pour objet de rechercher les espaces de données de type MEC (MEC 1, MEC2, MEC3) pouvant effectivement héberger des connecteurs de l’espace EVD virtuel de données. L’entité MEC Servic est gérée par un fournisseur de services de connectivité ayant des connecteurs. Cette entité a pour objet de contrôler et de récupérer l’état des connectivités utilisées pour les connecteurs. Les informations sur les états des connexions entre connecteurs peuvent être collectées auprès d’entités telles qu’un PCF (en anglais Policy and Charging Function), une entité de type NEF (en anglais Network Exposure Function), ou bien une entité de type NWDAF (en anglais Network Data Analytic Function) pour un réseau mobile ou bien une entité de type CLF (en anglais Connectivity Location Function) ou RACF (en anglais Resource Admission and Control Function) pour un réseau fixe.
L’espace EVD virtuel de données comprend en outre une entité Gest correspondant à un agent de courtage ou une place de marché, assurant la gestion des offres et des demandes de données en provenance d’entités diverses (entités clientes souhaitant acquérir des données, fournisseurs de données). Ainsi une entité Consom représentant un acquéreur ou consommateur de données est comprise dans cet espace EVD virtuel de données.
L’espace virtuel de données comprend en outre 3 espaces de stockage MEC1, MEC2, MEC3 dont les identifiants et les connectivités respectives à l’infrastructure de communications sont gérées par les entités MEC connec et MEC servic. L’espace MEC1 héberge par exemple des données des entités Prop1 et Prop2, propriétaires de leurs propres données. Ces espaces de stockage MEC sont interconnectés en utilisant les liens mises en œuvre par les opérateurs de l’infrastructure de communications sur laquelle est déployée l’espace EVD virtuel de données. Il est à noter que ces espaces MEC peuvent également héberger des applications comme c’est le cas sur la où les espaces MEC1, MEC2 et MEC3 hébergent respectivement les applications App1, App2 et App3. Ces espaces de données comprennent en outre des connecteurs en charge d’assurer l’échange des données entre les différents espaces MEC. Les ressources virtualisées gérées par les espaces peuvent en outre être administrées par un orchestrateur.
Une entité Logic est également comprise dans l’espace EVD virtuel de données et permet de recueillir les caractéristiques des applications ainsi que les types de connecteurs qui doivent être utilisés pour le transport de données en fonction par exemple des contraintes de la demande de données ou de contraintes propres aux données elles-mêmes.
Grâce aux informations collectées auprès des entités MEC Connec et MEC Servic, voire avec l’aide des informations fournies par la fonction Logic, la fonction Optim peut identifier et localiser les données ainsi que la localisation des applications en charge du traitement de ces données et requises dans le cadre d’une offre de transport de données. Les informations relatives à la connectivité des espaces de données, tels que les connectivités des espaces MEC1, MEC2 et MEC3 sont ajoutées à des informations propres à l’objet décrivant les données requises. Celles-ci sont par exemple décrites en utilisant le graphe de contextes des données SOC, décrit à la figure 3.30 du document https://www.internationaldataspaces.org/wp-content/uploads/2019/03/IDS-Reference-Architecture-Model-3.0.pdf. Ainsi, aux informations définies dans un graphe SOC selon l’état de la technique, s’ajoute des informations de connectivité, telles que des points de terminaison de l’objet (identifiant de connectivité), une information de type CLID (en anglais Calling Id identifier RADIUS), un point de terminaison de l’espace MEC, une localisation par exemple avec des coordonnées GPS voire un code postal, voire l’identité de l’opérateur assurant la fourniture de la connectivité du connecteur à l’infrastructure de communications.
Il est à noter que selon un autre exemple, l’entité Optim peut aussi obtenir les données relatives à la connectivité des connecteurs des espaces MEC1, MEC2, MEC3 directement auprès des espaces MEC1, MEC2 et MEC3. Ainsi la fonction Optim peut en outre obtenir auprès des opérateurs fournissant la connectivité des MEC1, MEC2 et MEC3 à l’infrastructure de communications des informations complémentaires comprenant :
- le type d’accès utilisé pour connecter un espace MEC1, MEC2 et MEC3 à l’infrastructure de communications. Par exemple, il peut s’agir d’un accès xDSL, un accès fibre ou un accès radio (Wi-Fi, 4G, 5G).
- le profil de service de l’espace MEC1, MEC2 et MEC3. Par exemple, il peut s’agir d’un volume de trafic maximum, de capacité de transmission downlink/uplink, des capacités en termes d’itinérances (en anglais roaming), des identifiants et/ou des caractéristiques de tranche de réseau (en anglais slice).
- Des informations concernant des délais de transmission entre connecteurs ainsi que des caractéristiques de bande passante utilisée.
- Des caractéristiques sur le volume de trafic qui devra être échangé (nombre de paquets par seconde, volume de trafic..).
L’entité d’optimisation Optim obtient en outre des informations sur les applications installées dans les espaces MEC1, MEC2 et MEC3 auprès des gestionnaires de ces MEC respectifs. L’entité Optim peut compléter les informations obtenues sur les applications (type d’application, latence des applications, version logicielle des applications…) avec des informations obtenues auprès de l’entité Gest et/ou de l’entité Logic.
- le type d’accès utilisé pour connecter un espace MEC1, MEC2 et MEC3 à l’infrastructure de communications. Par exemple, il peut s’agir d’un accès xDSL, un accès fibre ou un accès radio (Wi-Fi, 4G, 5G).
- le profil de service de l’espace MEC1, MEC2 et MEC3. Par exemple, il peut s’agir d’un volume de trafic maximum, de capacité de transmission downlink/uplink, des capacités en termes d’itinérances (en anglais roaming), des identifiants et/ou des caractéristiques de tranche de réseau (en anglais slice).
- Des informations concernant des délais de transmission entre connecteurs ainsi que des caractéristiques de bande passante utilisée.
- Des caractéristiques sur le volume de trafic qui devra être échangé (nombre de paquets par seconde, volume de trafic..).
L’entité d’optimisation Optim obtient en outre des informations sur les applications installées dans les espaces MEC1, MEC2 et MEC3 auprès des gestionnaires de ces MEC respectifs. L’entité Optim peut compléter les informations obtenues sur les applications (type d’application, latence des applications, version logicielle des applications…) avec des informations obtenues auprès de l’entité Gest et/ou de l’entité Logic.
L’entité Optim traite les données obtenues pour identifier le meilleur chemin entre connecteurs pour acheminer les données et leur appliquer un traitement. Elle identifie notamment où instancier une application requise pour un service de transport de données, notamment dans le cas où aucune application existante dans un MEC ne peut accomplir le traitement requis ou n’est pas suffisamment bien placée pour le service. L’entité peut en outre identifier où placer un nouveau connecteur si aucun connecteur ne satisfait le service requis. Elle identifie en outre les caractéristiques des communications à mettre en œuvre entre les connecteurs des MEC participant au service et elle identifie le coût et la qualité de service de bout en bout de chaque chemin entre connecteurs identifié. Une fois ces caractéristiques identifiées, qu’un chemin de bout en bout est identifié avec possiblement les applications de traitement requises, le chemin de bout en bout peut être optionnellement sélectionné ou accepté par le demandeur et l’entité Optim orchestre la demande avec les différents fournisseurs (gestionnaires des MEC1, MEC2, MEC3, gestionnaires de l’infrastructure de communication en charge de la connectivité des MEC1, MEC2, MEC3 à l’infrastructure et les fournisseurs d’applications si de tels besoins sont effectivement exprimés.
En lien avec la , on présente un procédé de traitement d’un service de transport de données selon un premier mode de réalisation de l’invention.
Lors d’une étape E0, les propriétaires Prop 1 et Prop 2 envoient une offre de données au Gestionnaire Gest (ou agent de gestion) de données avec des informations de contexte associées aux données. Selon un exemple, ces informations de contexte sont par exemple décrites dans un format SOC (en anglais Separation of Concerns). Le gestionnaire Gest de données a pour objet de recueillir les offres de données et d’autre part de recevoir des demandes de service de transport de données de la part de demandeur qui peut être un client professionnel cherchant à collecter et possiblement à traiter des données provenant de différents fournisseurs de données par exemple pour des besoins de corrélation des données ou pour mener des études, typiquement de type Marketing. Ces informations de contexte peuvent par exemple comprendre des informations de localisation des connecteurs hébergeant ces données et des règles de sécurité associées, conformément à la description SOC.
Lors d’une étape E1, le gestionnaire Gest de données transmet à l’entité Optim d’optimisation une requête de déploiement d’un service de transport de données dans un espace virtuel de données instancié sur une infrastructure de communications. Cette requête comprend les identifiants des propriétaires Prop 1 et Prop 2 ainsi que les identifiants de connectivité de l’espace MEC1 et possiblement d’un connecteur de l’espace MEC1, dans lequel sont stockées les données de ces propriétaires. Selon un exemple, la requête comprend en outre les identifiants des consommateurs de données, par exemple de l’entité Consom souhaitant accéder aux données transportées, ainsi que l’identifiant de l’espace MEC2 et d’un connecteur de l’espace MEC2, où seront stockées les données reçues pour l’entité Consom. Selon un autre exemple, la requête comprend en outre les identifiants des applications en charge d’appliquer un traitement aux données transportées pour le service considéré. La requête comprend en outre possiblement les informations de contexte associées aux données, par exemple dans un graphe de type SOC, du service de transport. Ces informations de contexte comprennent par exemple les adresses IP des connecteurs offrant les données, les identifiants des données, les règles associées à la politique de gestion de ces données du service de transport…).
Selon une alternative, l’entité Optim obtient en outre de l’entité Gest des identifiants des fournisseurs de connectivité associés aux identifiants de connectivité des espaces MEC1 et MEC2. Ces identifiants sont notamment utilisés pour joindre les connecteurs dans l’infrastructure de communications.
Selon une autre alternative, l’entité Optim obtient en outre en provenance de l’entité Gest un volume de données du service de transport, une fréquence d’émission/réception des données par les connecteurs et par les applications en charge du traitement. Selon un exemple, l’entité Optim obtient de l’entité Logic des délais de traitement des données par les applications appliquant un traitement aux données transportées. Par ailleurs, l’entité Optim peut obtenir de l’entité Gest une liste d’applications déjà instanciées sur les connecteurs lors des mises en œuvre de services de transport précédemment instanciées.
Il est à noter que selon une alternative, l’entité Optim obtient toutes les informations ci-dessus non pas de l’entité Gest mais directement des entités Prop 1, Prop 2 et Consom.
Lors d’une étape E2, le service de connectivité des opérateurs de l’infrastructure de communications, représenté dans la par l’entité MEC Connec, est interrogé par l’entité Optim pour obtenir des informations complémentaires et notamment des paramètres de connectivité des connecteurs contribuant au service de transport des données tel que défini dans la requête reçue. Ces paramètres de connectivité peuvent par exemple comprendre un temps de propagation d’un paquet de données entre un connecteur et un point d’accès de l’infrastructure de communication. Le paramètre peut en outre comprendre un temps de propagation entre deux connecteurs participant au service de transport de données. Les paramètres de connectivité peuvent en outre comprendre un type de technologie (xDSL, Fibre, Wi-Fi, 4G, 5G…) utilisé pour connecter un connecteur à l’infrastructure de communications. Le type de technologie peut être dissocié entre le type de technologie de transport (Ethernet, IP, LTE…) et l’infrastructure de transport (fibre, cuivre, Coaxial, Wi-Fi…). Une bande passante totale (profil de souscription de connectivité (uplink/downlink max garanti etc…)) associée à chaque connecteur voire une bande passante disponible pour l’acheminement des données du service de transport peuvent également être obtenues par l’entité Optim. Les paramètres de connectivité peuvent en outre comprendre une technologie et/ou un protocole de sécurité utilisé pour les communications entre un connecteur et un point d’accès de l’infrastructure de communication.
Lors de l’étape E2, l’entité Optim peut en outre obtenir auprès de l’entité Logic les caractéristiques logicielles des applications requises pour le service de transport des données. Ces caractéristiques logicielles peuvent comprendre des licences associées aux applications, des caractéristiques d’espace de stockage à utiliser pour déployer des applications, ou des délais de traitement des données d’applications.
Lors d’une étape E3, à partir des données collectées et en fonction du service de transport des données requis, l’entité Optim détermine au moins une suite de connecteurs, hébergeant des données et des applications, pour mettre en œuvre le service de transport de données demandé. Cette détermination requiert de sélectionner les connecteurs offrant des caractéristiques de connectivité, d’acheminement des données et de traitement de ces données, les plus adaptées à la requête reçue. Notamment, ces connecteurs sont sélectionnés pour obtenir la meilleure QoS et/ou le moindre coût, par exemple conformément à un paramètre présent dans le SOC. Cette détermination, selon une alternative, peut également comprendre l’instanciation d’une application dans un connecteur existant pour limiter le trafic à échanger, par exemple en instanciant des applications au plus près des connecteurs où sont stockées des données transportées. Cette instanciation requiert d’identifier des connecteurs à proximité des sources de données par exemple en se basant sur des informations de géolocalisation des connecteurs transmises par l’entité Gest ou l’entité MEC Connec, voire les MEC eux-mêmes.
Selon un exemple, la détermination peut également comprendre la mise en œuvre d’un nouveau connecteur dans le cas où les connecteurs existants ne permettent pas d’obtenir la QoS requise ou bien si d’autres connecteurs peuvent améliorer la QoS. Cette mise en œuvre peut être effectuée en recherchant parmi les fournisseurs de connectivité MEC, par exemple en sollicitant l’entité MEC Connec, les espaces de stockage MEC compatibles avec les critères notamment de sécurité et de confidentialité de l’espace virtuel de données.
Lors d’une étape E4, selon un exemple, l’entité Optim détermine pour les différents chemins, composés chacun d’une suite de connecteurs, un paramètre de qualité de transport des données. Ainsi, lors de cette phase E4, l’adaptation des chemins au transport des données tel que requis est déterminée. Il peut s’agir par exemple de calculer une QoS de bout en bout et un coût associé au transport des données en respectant les règles d’utilisation des données et en prenant en compte les traitement des applications sur le chemin. Ces chemins peuvent comprendre des nouveaux connecteurs et peuvent également comprendre de nouvelles applications instanciées, ce qui requiert d’évaluer la QoS pour l’acheminement et le traitement des données du service dans l’espace virtuel de données.
Les chemins déterminés et possiblement les paramètres de qualité de service associés sont transmis à destination de l’entité Consom et possiblement aux entités Prop 1 et Prop 2. Cet envoi permet à ces entités de pouvoir sélectionner ou bien de pouvoir éliminer un ou plusieurs chemins de la liste. Par exemple, l’entité Consom pourra choisir un chemin ayant une bonne QoS alors qu’une entité, telle que Prop 1, pourra interdire un chemin en raison de la présence d’un connecteur ou d’une application sur le chemin qui pourrait compromettre des données. Les entités Consom, Prop 1 et Prop 2 transmettent leur choix à l’entité Optim en réponse à la sollicitation de l’entité Optim.
Lors d’une étape E5, une fois le(s) chemin(s) sélectionnés par l’entité Optim, possiblement avec l’aide des entités Consom, Prop 1 et Prop2, l’entité Optim met en place le(s) chemin(s). Cette mise en place consiste à mettre en place les connexions entre connecteurs fournissant et consommant des données, à instancier si besoin des applications pour le traitement de données, voire à instancier de nouveaux connecteurs. L’entité Optim peut mettre en place ce(s) chemin(s) de façon autonome ou bien en sollicitant les entités Logic, MEC Connec ainsi que les opérateurs en charge de l’infrastructure de communications.
On se réfère maintenant à la qui présente un exemple de structure d’un dispositif de traitement d’un service de transport de données selon un autre mode de réalisation de l’invention
Le dispositif 400 de traitement d’un service de transport de données met en œuvre le procédé de traitement d’un service de transport de données, dont différents modes de réalisation viennent d'être décrits.
Un tel dispositif 400 peut être mis en œuvre dans une entité de gestion d’un service applicatif ou bien dans une entité de gestion d’un réseau de télécommunications, déployé à base de fonctions virtualisées ou d’équipements physiques.
Par exemple, le dispositif 400 comprend une unité de traitement 430, équipée par exemple d'un microprocesseur µP, et pilotée par un programme d'ordinateur 410, stocké dans une mémoire 420 et mettant en œuvre le procédé de détermination selon l'invention. A l’initialisation, les instructions de code du programme d’ordinateur 410 sont par exemple chargées dans une mémoire RAM, avant d’être exécutées par le processeur de l’unité de traitement 430.
Un tel dispositif 400 comprend :
- un récepteur 403, apte à recevoir une requête Req de déploiement du service de transport de données en provenance d’un agent de gestion des données,
- un module 401 d’obtention, apte à obtenir un paramètre de connectivité à l’infrastructure de communication d’un connecteur d’un site parmi la pluralité, ledit connecteur contribuant au service de transport des données de la requête reçue,
- un calculateur 402, apte à déterminer au moins un chemin d’acheminement des données dans l’espace virtuel de données, l’au moins un chemin comprenant une suite ordonnée de connecteurs sélectionnés en fonction du paramètre de connectivité obtenu.
- un module 401 d’obtention, apte à obtenir un paramètre de connectivité à l’infrastructure de communication d’un connecteur d’un site parmi la pluralité, ledit connecteur contribuant au service de transport des données de la requête reçue,
- un calculateur 402, apte à déterminer au moins un chemin d’acheminement des données dans l’espace virtuel de données, l’au moins un chemin comprenant une suite ordonnée de connecteurs sélectionnés en fonction du paramètre de connectivité obtenu.
A titre d’exemples, des mises en œuvre d’un tel procédé de traitement sont présentées ci-dessous.
Un client d’un service de logistique souhaite suivre le déplacement de sa cargaison de produits dans les espaces de stockages (ports/entrepôts) et des services de transports (porte conteneur, camion de livraison) et de l’état de son stockage (location de conteneur connecté (exemple frigorifique)). Le client a ainsi besoin d’obtenir les informations de localisation de sa marchandise aux différents services de transports, les informations de l’état de ses produits via les capteurs de son conteneur aux services de location de conteneur, et les informations de maintenance dans les espaces de stockages via les entités en charge des services de stockages. En corrélant les données à disposition des différentes entités en charge de ses produits, le client peut utiliser des applications pour suivre en temps réel la localisation de sa cargaison ainsi que l’état de sa cargaison. Comme les différentes entités (transport, stockage, refroidissement) de services peuvent rendre ses services à plusieurs clients, un traitement local des données est souhaitable pour l’ensemble des clients permettant ainsi que seules les données agrégées dans les MEC par les différentes entités soient transférées aux clients. Le traitement peut consister ainsi à identifier des données, à corréler des données entre elles, à protéger des données.
Selon un autre exemple de mise en œuvre, un laboratoire pharmaceutique souhaite analyser les données des patients pour une maladie spécifique et il a donc besoin de collecter les données de différents hôpitaux de différents pays sans connaitre l’identité des patients. Les applications hébergés dans des connecteurs à proximité des hôpitaux agrègent et analysent les données des patients en prenant soin par exemple de supprimer les informations relatives aux identités des patients. Des MECs localisés par pays agrègent les données des patients d’un pays, et le laboratoire peut ainsi agréger les données des différents pays tout en respectant les contraintes locales de chaque pays, requérant un traitement spécifique pour chaque MEC, et en minimisant le transfert de données vers son connecteur via l’utilisation adaptée des infrastructures de communications assurant la connectivité des sites MECs et le traitement au plus près des sites MEC des différents pays. Seules les données pertinentes pour le laboratoire sont traitées et transmises en tirant parti en outre des spécificités des infrastructures de communication.
Selon encore un autre exemple, une société de géomarketing souhaite faire une analyse des comportements d’une population d’une ville dite connectée (en anglais « smart city »). Elle peut ainsi souscrire un accès à des données auprès de services de transport pour connaitre la fréquentation des lignes de transport, auprès de services de restaurations (pour connaitre les habitudes de restaurations des habitants), à des services de parking (pour connaitre les habitudes de parking), à des services d’aide à la navigation (pour connaitre les habitudes et la fréquentation des routes (feux routiers, aide à la navigation), à des services de communications (pour connaitre les informations de communications des habitants), à des services de divertissements (pour analyser les divertissements des habitants) … Chacun de ces fournisseurs de données peuvent avoir déjà fourni, via un espace virtuel de données, pour des traitements de données demandés par leurs propres clients. Ces fournisseurs déploient des applications dans des MECs à proximités des leurs sources de données (capteurs). Le procédé de traitement, mis en œuvre par une entité d’optimisation, peut identifier les applications déjà mis en place pour déterminer les chemins de transport de données qui répondent aux différents clients et qui optimisent le transport de données. Ainsi, pour des données issues de deux fournisseurs distincts, le recours à une application par exemple pour compresser des données, sera privilégié en prenant en compte les connectivités des espaces MEC et de l’espace où l’application est mise en œuvre. Les données des différents fournisseurs seront ainsi acheminées sur un chemin prenant en compte les connectivités des espaces de stockage des données et les espaces où des traitements de ces données peut être effectué de façon optimale pour satisfaire els exigences en terme de qualité de service et coût du service.
Claims (15)
- Procédé de traitement d’un service de transport de données dans un espace (EVD) virtuel de données déployé sur une infrastructure (1000) de communications, l’espace (EVD) virtuel de données comprenant une pluralité de sites 10, 20, 30, 40, 50, 60, 70, 80, 90) comprenant chacun un serveur (100, 200, 300, 400, 500, 600, 700, 800, 900) de communication, aussi appelé connecteur, apte à héberger une donnée ou une application (App1, App2, App3) de traitement des données, le procédé mis en œuvre par une entité (Optim) d’optimisation apte à communiquer avec le connecteur et comprenant :
- la réception (1) d’une requête (Req) de déploiement du service de transport de données en provenance d’un agent (Gest) de gestion des données,
- l’obtention d’un paramètre de connectivité à l’infrastructure (100) de communication d’un connecteur d’un site parmi la pluralité (100, 200, 300, 400, 500, 600, 700, 800, 900), ledit connecteur contribuant au service de transport des données de la requête (Req) reçue,
- la détermination d’au moins un chemin d’acheminement des données dans l’espace (EVD) virtuel de données, l’au moins un chemin comprenant une suite (100, 700, 800, 300) ordonnée de connecteurs sélectionnés en fonction du paramètre de connectivité obtenu. - Procédé de traitement, selon la revendication 1, comprenant en outre l’obtention d’au moins un identifiant relatif au service de transport de la requête de déploiement reçue parmi les identifiants suivants:
- un identifiant d’un connecteur d’un site d’un fournisseur d’une donnée du service de transport,
-un identifiant d’un connecteur d’un site d’un consommateur des données du service de transport,
- un identifiant d’une application de traitement d’une donnée du service de transport,
- un identifiant selon un graphe de données « Separation of Concern » d’une donnée du service de transport. - Procédé de traitement, selon la revendication 1 ou la revendication 2, où la requête de déploiement comprend en outre une règle associée à la politique de gestion des données du service de transport.
- Procédé de traitement, selon la revendication 2, comprenant en outre l’obtention d’un identifiant d’un fournisseur de connectivité à l’infrastructure (1000) de communications associé à l’identifiant du fournisseur (Prop 1, Prop 2) ou du consommateur (Consom) d’une donnée du service de transport obtenu.
- Procédé de traitement, selon l’une des revendications 1 à 4, où le paramètre de connectivité comprend au moins une caractéristique de transmission parmi les caractéristiques suivantes :
- un temps de propagation d’un paquet de données entre un connecteur et un point d’accès de l’infrastructure de communication,
- un type de technologie utilisée pour l’acheminement de données entre un connecteur et un point d’accès de l’architecture de communication,
- une bande passante associée à un connecteur,
- une bande passante disponible pour l’acheminement d’une donnée du service de transport. - Procédé de traitement, selon l’une des revendications 1 à 5, comprenant en outre l’obtention d’une caractéristique logicielle d’une application requise pour le service de transport de données.
- Procédé de traitement, selon l’une des revendications 1 à 6, où la détermination de l’au moins un chemin comprend l’identification d’un connecteur apte à accueillir une application de traitement des données dans l’espace virtuel de données en fonction de la requête de déploiement reçue.
- Procédé de traitement, selon l’une des revendications 1 à 7, où la détermination de l’au moins un chemin comprend la sélection d’un nouveau site apte à accueillir un nouveau connecteur dont une caractéristique de connectivité est compatible avec l’espace virtuel de données.
- Procédé de traitement, selon l’une des revendications 1 à 8, où la détermination de l’au moins un chemin comprend le calcul pour l’au moins un chemin d’un paramètre de qualité de transport des données sur le chemin.
- Procédé de traitement, selon l’une des revendications 1 à 9, comprenant en outre l’émission (4) à destination d’un fournisseur (Prop 1, Prop 2) d’une donnée et/ou d’un consommateur (Consom) des données de l’au moins un chemin.
- Procédé de traitement, selon l’une des revendications 1 à 10, comprenant en outre la configuration des connecteurs du chemin sélectionné parmi l’au moins un chemin déterminé.
- Dispositif (400) de traitement d’un service de transport de données dans un espace (EVD) virtuel de données déployé sur une infrastructure (1000) de communications, l’espace (EVD) virtuel de données comprenant une pluralité de sites comprenant chacun un serveur de communication, aussi appelé connecteur, apte à héberger une donnée ou une application de traitement des données, apte à communiquer avec le connecteur et comprenant :
- un récepteur (403), apte à recevoir une requête de déploiement du service de transport de données en provenance d’un agent de gestion des données,
- un module (401) d’obtention, apte à obtenir un paramètre de connectivité à l’infrastructure de communication d’un connecteur d’un site parmi la pluralité, ledit connecteur contribuant au service de transport des données de la requête reçue,
- un calculateur (402), apte à déterminer au moins un chemin d’acheminement des données dans l’espace virtuel de données, l’au moins un chemin comprenant une suite ordonnée de connecteurs sélectionnés en fonction du paramètre de connectivité obtenu. - Système de traitement d’un service de transport de données dans un espace virtuel de données déployé sur une infrastructure de communications, l’espace virtuel de données comprenant une pluralité de sites comprenant chacun un serveur de communication, aussi appelé connecteur, apte à héberger une donnée ou une application de traitement des données, ledit système comprenant :
- une entité d’optimisation comprenant un dispositif de traitement selon la revendication 13
- un agent de gestion des données apte à émettre une requête de déploiement du service de transport de données à destination de l’entité d’optimisation. - Programme d'ordinateur comportant des instructions pour la mise en œuvre du procédé de traitement selon l'une quelconque des revendications 1 à 11, lorsque le programme est exécuté par un processeur.
- Support d’enregistrement lisible par un dispositif de traitement conforme à la revendication 12, sur lequel est enregistré le programme selon la revendication 14.
Priority Applications (4)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| FR2008388A FR3113346A1 (fr) | 2020-08-10 | 2020-08-10 | Procédé de traitement d’un service de transport de données |
| PCT/FR2021/051292 WO2022034273A1 (fr) | 2020-08-10 | 2021-07-12 | Procede de traitement d'un service de transport de donnees |
| US18/040,573 US20230283664A1 (en) | 2020-08-10 | 2021-07-12 | Method for processing a data transport service |
| EP21749675.1A EP4193569A1 (fr) | 2020-08-10 | 2021-07-12 | Procede de traitement d'un service de transport de donnees |
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| FR2008388A FR3113346A1 (fr) | 2020-08-10 | 2020-08-10 | Procédé de traitement d’un service de transport de données |
| FR2008388 | 2020-08-10 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| FR3113346A1 true FR3113346A1 (fr) | 2022-02-11 |
Family
ID=74095860
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| FR2008388A Withdrawn FR3113346A1 (fr) | 2020-08-10 | 2020-08-10 | Procédé de traitement d’un service de transport de données |
Country Status (4)
| Country | Link |
|---|---|
| US (1) | US20230283664A1 (fr) |
| EP (1) | EP4193569A1 (fr) |
| FR (1) | FR3113346A1 (fr) |
| WO (1) | WO2022034273A1 (fr) |
Families Citing this family (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| FR3135584A1 (fr) * | 2022-05-12 | 2023-11-17 | Orange | Procédé, dispositif et système d’élaboration dynamique d’une infrastructure de données |
Citations (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20050005116A1 (en) * | 2002-09-18 | 2005-01-06 | Commerce One Operations, Inc. | Dynamic interoperability contract for web services |
-
2020
- 2020-08-10 FR FR2008388A patent/FR3113346A1/fr not_active Withdrawn
-
2021
- 2021-07-12 US US18/040,573 patent/US20230283664A1/en active Pending
- 2021-07-12 WO PCT/FR2021/051292 patent/WO2022034273A1/fr active Application Filing
- 2021-07-12 EP EP21749675.1A patent/EP4193569A1/fr active Pending
Patent Citations (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20050005116A1 (en) * | 2002-09-18 | 2005-01-06 | Commerce One Operations, Inc. | Dynamic interoperability contract for web services |
Non-Patent Citations (1)
| Title |
|---|
| INTERATIONAL DATA SPACES ASSOCIATION: "REFERENCE ARCHITECTURE MODEL Version 3.0", 30 April 2019 (2019-04-30), XP055773816, Retrieved from the Internet <URL:-> [retrieved on 20210209] * |
Also Published As
| Publication number | Publication date |
|---|---|
| US20230283664A1 (en) | 2023-09-07 |
| WO2022034273A1 (fr) | 2022-02-17 |
| EP4193569A1 (fr) | 2023-06-14 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| Sabella et al. | Developing software for multi-access edge computing | |
| WO2020174156A1 (fr) | Procédé d'évaluation des dispositifs d'une infrastructure de réseau en vue du déploiement d'une fonction virtualisée | |
| Sabella et al. | Edge computing: from standard to actual infrastructure deployment and software development | |
| FR2928800A1 (fr) | Procede de gestion de requetes d'obtention d'identifiants de pairs en vue d'acceder en mode p2p a des contenus qu'ils stockent, et dispositif de gestion et equipement de reseau associes. | |
| Lee et al. | Trends in blockchain and federated learning for data sharing in distributed platforms | |
| EP1672846A1 (fr) | Gestion des ressources d'un réseau mobile large bande | |
| WO2022034273A1 (fr) | Procede de traitement d'un service de transport de donnees | |
| EP3729846B1 (fr) | Procédé de configuration dynamique d'entités d'un réseau de communications pour l'acheminement de données d'un terminal visiteur | |
| US20190297010A1 (en) | System and Method for IOT Systems of Logic Across a Continuum of Computers | |
| EP2446360B1 (fr) | Technique de determination d'une chaine de fonctions elementaires associee a un service | |
| FR3096531A1 (fr) | Procédé d’allocation de ressources d’une infrastructure de réseau | |
| EP2150090B1 (fr) | Terminal multimode à connextions optimisées | |
| WO2022208017A1 (fr) | Procede, dispositif et systeme de mise a disposition d'une ressource de communication | |
| WO2023217638A1 (fr) | Procédé, dispositif et système de certification d'une ressource | |
| WO2023135043A1 (fr) | Procédé, dispositif et système de modification d'une infrastructure de communication | |
| WO2023217639A1 (fr) | Procédé, dispositif et système d'élaboration dynamique d'une infrastructure de données | |
| FR3137238A1 (fr) | Procédé de suspension d’un jeton de certification permettant d’authentifier l’établissement d’une connexion entre deux équipements de communication, dispositifs et programmes d’ordinateur correspondants | |
| EP4145794A1 (fr) | Procédé d'intégration dynamique mis en uvre au cours de la fédération de réseaux de radiocommunication et produit programme d'ordinateur | |
| WO2023281181A1 (fr) | Procede et dispositif de configuration d'une unite d'acces dans un environnement virtualise | |
| EP3839738A1 (fr) | Procede de gestion des requetes d'allocation d'une ressource informatique | |
| FR3131674A1 (fr) | Système de dissémination de contenus dans une fédération de réseaux ; Procédé de dissémination et produit programme d'ordinateur associés | |
| FR3125191A1 (fr) | Procédé d’établissement authentifié d’une connexion entre un équipement raccordé à au moins un réseau de communication et un serveur d’un fournisseur de services et dispositifs correspondants. | |
| WO2017109367A1 (fr) | Procédé d'allocation de ressources d'exécution | |
| EP2446608A1 (fr) | Technique de contrôle d'accès par une entité cliente à un service | |
| FR3029729A1 (fr) | Procede de gestion de contenus dans un reseau de distribution de contenus |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PLSC | Publication of the preliminary search report |
Effective date: 20220211 |
|
| ST | Notification of lapse |
Effective date: 20220405 |