WO2022034273A1 - Procede de traitement d'un service de transport de donnees - Google Patents

Procede de traitement d'un service de transport de donnees Download PDF

Info

Publication number
WO2022034273A1
WO2022034273A1 PCT/FR2021/051292 FR2021051292W WO2022034273A1 WO 2022034273 A1 WO2022034273 A1 WO 2022034273A1 FR 2021051292 W FR2021051292 W FR 2021051292W WO 2022034273 A1 WO2022034273 A1 WO 2022034273A1
Authority
WO
WIPO (PCT)
Prior art keywords
data
connector
processing
transport service
path
Prior art date
Application number
PCT/FR2021/051292
Other languages
English (en)
Inventor
Benoît RADIER
Gaël FROMENTOUX
Arnaud BRAUD
Vincent MESSIÉ
Original Assignee
Orange
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Orange filed Critical Orange
Priority to US18/040,573 priority Critical patent/US20230283664A1/en
Priority to EP21749675.1A priority patent/EP4193569A1/fr
Publication of WO2022034273A1 publication Critical patent/WO2022034273A1/fr

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

Definitions

  • the invention is located in a communications infrastructure allowing a client device to obtain a service developed from data from several storage spaces.
  • the invention aims more specifically to make it possible to improve the quality of the service offered to the customer by allowing optimized routing of data between different entities.
  • IDSA forum International Data Spaces Association
  • IDS-Reference-Architecture-Model an architecture and mechanisms for data exchange between separate entities.
  • One of the stones The cornerstones of such an architecture are based on certified "connectors" used to interconnect the different spaces maintained by the different partners.
  • a connector is thus used to collect the data and deposit them in a storage space common to the members of the virtual data space, for example at the periphery of a communications network (edge).
  • the virtual data space provides that each entity has at least one connector able to communicate with the connectors of the other partners of the virtual data space. Since the exchange of data must be secure, each connector must be able to be identified and authenticated in a secure manner and the connector of an entity must be able to ensure that the data it makes available is used by the other entities and in particular the client device in accordance with the data security specifications established by the respective providers of the virtual data space.
  • a connector can be integrated into equipment of a fixed network or of a mobile network, indifferently. Once a connector has been identified, accepted and configured in the virtual data space and that it is known in particular to a data broker, the data exchange can operate .
  • a data consumer in English Data Consumer also equipped with a connector requests the agent or directly one or more data providers (in English Data Provider) if he already knows them to transfer, recover, transform or obtain data from data providers.
  • the data may itself include information relating to the policies for the use of this data and/or a general policy for the data exchanged between a consumer and a supplier for the data exchanged between these two entities.
  • the provision of data may be accompanied by the provision of applications used by the connectors to perform data processing from an application.
  • the provisioning of applications in the virtual data space is comparable to the provisioning of data except that the agent is identified as an application store (in English Applications Store).
  • a connector can therefore request an application from a store according to its needs.
  • identification and communication information exists, including IP addresses and communication ports used, but the data and/or application provider connectors communicate with the consumer(s). ) of data and/or applications in overlay mode, for example on the basis of tunnels, for example of the TLS type, established on the existing communications infrastructures or by using a protocol of the HTTPS type.
  • This which does not allow on the one hand to establish a dynamic path between the connectors of the partners and on the other hand, the inherent characteristics of the communication networks, in terms of routing, quality of service, flow are not taken taken into account for the transfer of data in the virtual data space.
  • the exchange of data in space is thus not optimized and the service based on the exchange of data does not benefit from a quality possibly adapted to the service consumed.
  • the present invention aims to provide improvements over the state of the art.
  • the invention improves the situation using a method of processing a data transport service in a virtual data space deployed on a communications infrastructure, the virtual data space comprising a plurality of sites comprising each a communication server, also called a connector, capable of hosting data or a data processing application, the method implemented by an optimization entity capable of communicating with the connector and comprising:
  • a client entity or data consumer requests a data agent to identify servers, also called connectors, in charge of hosting some of the data requested by the consumer and/or connectors comprising an application capable of applying processing to requested data. Then, the consuming entity requests each connector to retrieve the data and apply the required processing to it.
  • the processing method advantageously improves this solution by taking advantage of the transmission or connectivity characteristics of the communications infrastructure on which the virtual data space is deployed, but also by allowing data to be transported between the various connectors to allow recovery data and their processing in a short time.
  • the method makes it possible to select connectors having a connectivity characteristic adapted to the data transport service, but also to avoid duplicating data by taking advantage of a chaining of the connectors in the development of the transport path of the data.
  • updating the virtual data space by deploying new sites and/or new connectors as needed makes it possible to have a virtual data space adapted to the needs of consumers.
  • the virtual data space can also be better organized by allowing the most common data processing operations, expressed in the transport service deployment requests received, to be carried out close to the connectors comprising the data. This data made available during previous offers and requests is thus taken into account by the optimization entity for the selection of processing functions in connectors and for optimizing their placement if new functions are to be deployed for a deployment request of data transport.
  • the optimization entity implementing the processing method is thus new and inventive since it makes it possible to establish a routing path between different connectors making it possible to avoid the solicitation of a connector consuming data towards a plurality of data provider connectors and/or processing applications.
  • the method thus makes it possible to aggregate the different data from different connectors, to apply a processing of this data or of part of this data as close as possible to the connectors where they are located and to route them according to a path improving the quality. of service of their routing thanks to a routing of the data of near closely between the connectors up to the data consumer or the client who issued the transport service deployment request.
  • the processing method further comprises obtaining at least one identifier relating to the transport service of the deployment request received from among the following identifiers:
  • identifiers from the data agent or directly from data providers and data consumers with regard to these identifiers makes it possible to determine the ordered sequence of connectors in an unambiguous way, in particular by using public identifiers such as FQDN names or IP addresses.
  • public identifiers such as FQDN names or IP addresses.
  • the use of a "Separation of Concern" data graph enriched with the identifiers of the connectors routing the data on the path makes it possible to be sure that the data has passed through connectors actually authorized to receive and process this data, guaranteeing that the data is not disseminated to unauthorized entities.
  • the identifiers of the applications allow the consumer of the data to know which types of processing have in particular actually been carried out on the data received.
  • the deployment request further comprises a rule associated with the data management policy of the transport service.
  • a virtual data space makes it possible to be able to exchange data between entities and in particular for a "consumer” entity to be able to obtain data from different "suppliers", but the virtual data space must also make it possible to guarantee in particular to the data supplier that its data is not disseminated to unauthorized entities.
  • the presence of rules associated with the data in the deployment request allows the entities responding to this request to ensure that the rules are compatible with their data management policies.
  • the rules may correspond to retransmission rights, to rights only allowing dissemination of the data within the framework of the deployment request or even rules which authorize a wider dissemination of this data to other entities.
  • the processing method further comprises obtaining an identifier of a provider of connectivity to the communications infrastructure associated with the identifier of the provider or of the consumer of data from the transport service obtained.
  • an identifier of a connectivity provider in addition to an identifier of a data provider authorizes on the one hand to complete the identification graph of a data with not only the identifiers of suppliers and consumers but also with identifiers of connectivity providers of connectors to the infrastructure.
  • a connector benefiting from connectivity with a supplier ensuring a high level of security for its transport infrastructure can improve the confidentiality of the data routed in accordance with the rules associated with the management policy for this data.
  • the connectivity parameter comprises at least one transmission characteristic among the following characteristics:
  • Different connectivity parameters of a connector to a communication infrastructure can be taken into account to ensure routing that complies with the needs expressed for example in the deployment request.
  • the propagation time of a data packet in particular using ICMP type packets, or information on the bandwidth, total or available, that is to say that which can actually be used for the service data transport, are particularly relevant.
  • the type of technology (Fiber, xDSL, 4G, 5G, etc.) used to attach a connector to the infrastructure provides information on the level availability and quality of the connection, on latency as well as on the security mechanisms associated with data transport.
  • the processing method further comprises obtaining a software characteristic of an application required for the data transport service.
  • the data transport service includes data, a path for transporting data, and applications performing processing of that data.
  • the optimization entity can advantageously obtain, for example from a software agent (Software Broker), information concerning the licenses associated with the software used for the processing of the data, the processing times required for the data in accordance with the request of deployment received, as well as the characteristics of the entities required for the instantiation of software in the event that new applications must be instantiated for the transport service.
  • the characteristics of the application may contain information on the volume of data which must be transmitted to the application so that the application can carry out these processing operations as well as the volume of data which the application must transmit. This information associated with the characteristics of data subscriptions via the data management agent can be useful for determining the bandwidth between the connectors and defining the quality of service that the connectivity operators must apply.
  • the determination of the at least one path comprises the identification of a connector able to accommodate a data processing application in the virtual data space according to of the deployment request received.
  • the optimization entity in the determination step, identifies the connectors capable of providing data and/or the entities capable of carrying out processing, for example by using the information obtained from the suppliers themselves or else by using its own previously obtained data.
  • the path determined as the most suitable for guaranteeing a level of quality of service required for routing the data may require the deployment of new connectors, for example to deploy new processing applications.
  • the optimization entity selects a connector to instantiate the required application by using in particular the connectivity parameters of the available connector.
  • the determination of the at least one path comprises the selection of a new site capable of receiving a new connector whose connectivity characteristic is compatible with the virtual space of data.
  • the deployment of new connectors, connected to the communications infrastructure according to the connectivity parameters required for the provision of the data transport service data, can be considered.
  • the virtual data space is thus dynamically updated with new connectors that can host data and/or applications in charge of processing this data.
  • the determination of the at least one path comprises the calculation for the at least one path of a parameter of transport quality of the data on the path.
  • the determination step possibly makes it possible to identify several possible paths for the transport of the data, and in particular for the successive processing of these data on the paths.
  • the selection of a path can be operated by a consumer of the data.
  • the optimization entity can advantageously qualify each determined path with a transport quality parameter. For example, it may be a duration for routing and processing test data, this duration possibly resulting from a test carried out by the optimization entity on the various paths in order to calibrate them.
  • the processing method further comprises the transmission to a data provider and/or to a data consumer of the at least one path.
  • the selection of a path can be operated by a consumer of the data according to its own needs in terms of quality of transport of the data or else by another entity according to its objectives of confidentiality of the data transmitted for example.
  • the method can therefore comprise a step of sending to an entity in charge of selecting the different paths and possibly information on the quality of transport, connectivity of the connectors used for transport, identification of the sites where the connectors are deployed or even information on software applying data processing.
  • the processing method further comprises the configuration of the connectors of the path selected from among F at least one determined path.
  • the optimization entity sets up the path.
  • This instantiation can include the configuration of the circuit between the connectors, the deployment of new applications and/or new connectors. Knowing that the connectors are managed by the sites and more precisely by the operators of these sites, the instantiation can advantageously be carried out by requesting the various agents (brokers) of the storage sites (MEC) for the existing connectors or to be deployed, the agents software for the new applications required, as well as the entities in charge of the infrastructure to ensure the connectivity of the connectors to this infrastructure.
  • This instantiation may also include the updating of data graphs including information on the new circuit set up and possibly usable for other services if the needs for quality of service and data confidentiality are compatible.
  • the invention also relates to a device for processing a data transport service in a virtual data space deployed on a communications infrastructure, the virtual data space comprising a plurality of sites each comprising a communication server, also called connector, capable of hosting data or a data processing application, capable of communicating with the connector and comprising:
  • a receiver capable of receiving a request for deployment of the data transport service from a data management agent
  • an obtaining module able to obtain a connectivity parameter to the communication infrastructure of a connector of a site among the plurality, said connector contributing to the data transport service of the request received,
  • This device capable of determining at least one data routing path in the virtual data space, F at least one path comprising an ordered sequence of connectors selected as a function of the connectivity parameter obtained.
  • This device capable of implementing in all its embodiments the processing method which has just been described, is intended to be implemented in an entity for managing an application service or else in an entity for managing a telecommunications network, deployed based on virtualized functions or physical equipment.
  • the invention also relates to a system for processing a data transport service in a virtual data space deployed on a communications infrastructure, the virtual data space comprising a plurality of sites each comprising a communication server, also called connector, capable of hosting data or a data processing application, said system comprising:
  • an optimization entity comprising a processing device and a data management agent capable of issuing a request for deployment of the data transport service to the optimization entity.
  • the invention also relates to a computer program comprising instructions for the implementation of the steps of the sorting method which has just been described, when this program is executed by a processor and a recording medium readable by a determination on which computer programs are stored.
  • This program may use any programming language, and be in the form of source code, object code, or intermediate code between source code and object code, such as in partially compiled form, or in any other desirable form.
  • the invention also relates to an information medium readable by a computer, and comprising instructions of the computer program as mentioned above.
  • the information medium can be any entity or device capable of storing the programs.
  • the medium may comprise a storage means, such as a ROM, for example a CD ROM or a microelectronic circuit ROM, or even a magnetic recording means, for example on a hard disk.
  • the information medium can be a transmissible medium such as an electrical or optical signal, which can be conveyed via an electrical or optical cable, by radio or by other means.
  • the program according to the invention can in particular be downloaded from an Internet-type network.
  • the information carrier may be an integrated circuit in which the program is incorporated, the circuit being adapted to execute or to be used in the execution of the method in question.
  • FIG 1 presents a simplified view of a communications infrastructure comprising a virtual data space in which a method of processing a data transport service can be implemented
  • FIG 2 presents an overview of the method for processing a data transport service according to a first embodiment of the invention
  • FIG 3 presents a method for processing a data transport service according to a first embodiment of the invention
  • FIG 4 presents an example of the structure of a data transport service processing device according to another embodiment of the invention.
  • embodiments of the invention are presented in a communications infrastructure using routing means specific to a fixed network or to a mobile network.
  • This infrastructure can be implemented to route communications data intended for fixed or mobile terminals and the invention can be intended to install virtualized functions used for the routing and/or processing of residential customer data or companies.
  • FIG 1 presents a simplified view of a communications infrastructure comprising a virtual data space in which a method for processing a data transport service can be implemented.
  • the communications infrastructure 1000 includes a virtual data space comprising a plurality of data storage spaces. Among these data spaces, we can distinguish data spaces belonging to companies 60, 70, 80, 90. These companies 60, 70, 80, 90 share for example data for the implementation of a service to from a customer not shown in [Fig 1]. Data spaces can also be stored in cloud spaces such as space 50. The data can also come from market places, that is to say space where it is possible to store data from different entities, this data can then be made available with other entities. These marketplaces allow entities to negotiate the acquisition of data.
  • Entities can also deposit data in spaces at the periphery, such as space 10 of the communications infrastructure, for example in distributed data spaces of the MEC type (Multi Access Edge Computing as specified in https: //www.etsi.org/technologies/multi-access-edge-computing).
  • a data space 30 can be specific to a loT (Internet of Things) service, or even to a corporate cloud 40 .
  • the virtual data space which allows a third-party entity to access data from several data spaces via the virtual data space, is based on a security architecture so that a data provider retains control of its shared data and their processing and for the third-party entity to have a guarantee on the origin of the data collected.
  • each 10, 20, 30, 40, 50, 60, 70, 80, 90 data space includes a 100, 200, 300, 400, 500, 600, 700, 800, 900 communication server, also called a connector, allowing data to be exchanged or made available to third-party entities (customer, other company, institution, etc.).
  • the intervening virtual data space (EVD) must allow secure data exchange between the various actors involved in these exchanges.
  • These connectors are used to collect the data and pour them, for example, into a storage space common to the members of the virtual data space, for example at the edge of the network. This allows the members of the virtual data space to carry out their analyzes locally without exporting their data but also to exchange them according to rules established with acquirers.
  • the exchange rules make it possible to specify that a piece of data should not be exported but that the processing results on this data can be exported.
  • the policies for distributing the data exchanged between the connectors, as well as the security rules (confidentiality in particular) are thus associated with the data in a file comprising the constraints for using the data identified C1, C2, C3 on [Eig 1].
  • a data transport service may for example include the suite of connectors 100, 700, 800, 300 and this data transport may include processing applications included in some or all of the connectors of the following.
  • the data of the connectors of the suite can be qualified with constraints of use of the data associated with each connector.
  • FIG 2 a virtual EVD data space is shown.
  • an Optim optimization entity in charge of implementing the data processing process of a transport service is deployed.
  • This Optim entity can for example be implemented in an administration station of the virtual data EVD space.
  • This Optim entity has a completely new and inventive role compared to existing IDSA architectures.
  • the purpose of this entity is in particular to collect information from the operators of the communications infrastructure on which the virtual EVD data space is deployed. Indeed, the different data spaces are interconnected thanks to the resources of the communications infrastructure 1000, described for example in [Fig 1].
  • This information on the connectivity of the data spaces to the communications infrastructure is advantageously used for the routing of the data in the virtual EVD data space. This information is used to optimize the routing of the data but also to optimize their processing knowing that applications deployed in data spaces are used to apply processing to this data during their routing.
  • the virtual data space EVD also comprises entities specific to the management of MEC type data spaces.
  • MEC Connec entity is to search for MEC type data spaces (MEC 1, MEC2, MEC3) that can actually host connectors of the virtual data EVD space.
  • MEC servicing entity is managed by a connectivity service provider with connectors. The purpose of this entity is to control and retrieve the state of the connectivities used for the connectors. Information on the states of connections between connectors can be collected from entities such as a PCF (Policy and Charging Function), an NEF-type entity (Network Exposure Function), or an NWDAF-type entity. (in English Network Data Analytic Function) for a mobile network or a CLF type entity (in English Connectivity Location Function) or RACF (Resource Admission and Control Function) for a fixed network.
  • PCF Policy and Charging Function
  • NEF-type entity Network Exposure Function
  • NWDAF-type entity in English Network Data Analytic Function
  • CLF type entity in English Connectivity Location Function
  • RACF Resource
  • the virtual EVD data space also includes a Gest entity corresponding to a brokerage agent or a market place, ensuring the management of data offers and requests from various entities (client entities wishing to acquire data, suppliers of data).
  • a Consum entity representing a data acquirer or consumer is included in this virtual data EVD space.
  • the virtual data space also includes 3 storage spaces MEC1, MEC2, MEC3 whose identifiers and respective connectivity to the communications infrastructure are managed by the entities MEC connec and MEC served.
  • the MEC1 space hosts, for example, data from the Propl and Prop2 entities, owners of their own data.
  • These MEC storage spaces are interconnected using the links implemented by the operators of the communications infrastructure on which the virtual EVD data space is deployed. It should be noted that these MEC spaces can also host applications as is the case in [Fig 2] where the MEC1, MEC2 and MEC3 spaces respectively host the applications Appl, App2 and App3.
  • These data spaces also include connectors in charge of ensuring the exchange of data between the different MEC spaces.
  • Virtualized resources managed by pods can additionally be administered by an orchestrator.
  • a Logic entity is also included in the virtual data EVD space and makes it possible to collect the characteristics of the applications as well as the types of connectors which must be used for the transport of data according for example to the constraints of the request for data or of constraints specific to the data itself.
  • the Optim function can identify and locate the data as well as the location of the applications in charge of processing this data and required as part of a data transport offer.
  • Data space connectivity information such as MEC1, MEC2, and MEC3 space connectivity is appended to object-specific information describing the required data.
  • connectivity information such as endpoints of the object (connectivity identifier), information of the CLID type (in English Calling Id identifier RADIUS), a termination point of the MEC space, a location for example with GPS coordinates or even a postal code, or even the identity of the operator ensuring the supply of the connectivity of the connector to the communications infrastructure .
  • the entity Optim can also obtain the data relating to the connectivity of the connectors of the spaces MEC1, MEC2, MEC3 directly from the spaces MEC1, MEC2 and MEC3.
  • the Optim function can also obtain additional information from the operators providing the connectivity of MEC1, MEC2 and MEC3 to the communications infrastructure, including:
  • the type of access used to connect an MEC1, MEC2 and MEC3 space to the communications infrastructure may be xDSL access, fiber access or radio access (Wi-Fi, 4G, 5G).
  • the service profile of the MEC1, MEC2 and MEC3 space may be a maximum traffic volume, downlink/uplink transmission capacity, roaming capacities, identifiers and/or network slice characteristics (in English slice).
  • the optimization entity Optim also obtains information on the applications installed in the spaces MEC1, MEC2 and MEC3 from the managers of these respective MECs.
  • the Optim entity can supplement the information obtained on the applications (type of application, latency of the applications, software version of the applications, etc.) with information obtained from the Gest entity and/or from the Logic entity.
  • the Optim entity processes the obtained data to identify the best path between connectors to route the data and apply processing to it. In particular, it identifies where to instantiate an application required for a data transport service, in particular in the case where no existing application in a MEC can perform the required processing or is not sufficiently well placed for the service.
  • the entity can further identify where to place a new connector if no connector satisfies the required service.
  • an end-to-end path is identified with possibly the processing applications required, the end-to-end path can be optionally selected or accepted by the requester and the Optim entity orchestrates the request with the various suppliers (managers of MEC1, MEC2, MEC3, managers of the communication infrastructure in charge of the connectivity of MEC1, MEC2, MEC3 to the infrastructure and the application suppliers if such needs are actually expressed.
  • the owners Prop 1 and Prop 2 send a data offer to the Data Manager (or management agent) with context information associated with the data.
  • this context information is for example described in a SOC (Separation of Concerns) format.
  • the purpose of the Data Management Manager is to collect data offers and on the other hand to receive data transport service requests from the applicant who may be a professional client seeking to collect and possibly process data from from different data providers, for example for data correlation purposes or to conduct studies, typically of the Marketing type.
  • This context information can for example include information on the location of the connectors hosting this data and the associated security rules, in accordance with the SOC description.
  • the Data management manager transmits to the optimization Optim entity a request for deployment of a data transport service in a virtual data space instantiated on a communications infrastructure.
  • This request includes the identifiers of the Prop 1 and Prop 2 owners as well as the connectivity identifiers of the MEC1 space and possibly of a connector of the MEC1 space, in which the data of these owners are stored.
  • the request also includes the identifiers of the data consumers, for example of the Consom entity wishing to access the transported data, as well as the identifier of the MEC2 space and of a connector of the MEC2 space, where the data received for the Consum entity will be stored.
  • the request further comprises the identifiers of the applications in charge of applying a processing to the data transported for the service considered.
  • the request also possibly includes the context information associated with the data, for example in a SOC type graph, of the transport service.
  • This context information includes, for example, the IP addresses of the connectors offering the data, the identifiers of the data, the rules associated with the policy for managing this data of the transport service, etc.).
  • the Optim entity also obtains from the Gest entity identifiers of the connectivity providers associated with the connectivity identifiers of the MEC1 and MEC2 spaces. These identifiers are used in particular to join the connectors in the communications infrastructure.
  • the Optim entity also obtains from the Gest entity a volume of data from the transport service, a frequency of transmission/reception of data by the connectors and by the applications in charge of the processing.
  • the entity Optim obtains from the entity Logic data processing delays by applications applying processing to the data transported.
  • the Optim entity can obtain from the Gest entity a list of applications already instantiated on the connectors during previously instantiated transport service implementations.
  • the Optim entity obtains all the above information not from the Gest entity but directly from the Prop 1, Prop 2 and Consum entities.
  • the connectivity service of the operators of the communications infrastructure is interrogated by the entity Optim to obtain additional information and in particular connectivity parameters of the connectors contributing to the data transport service as defined in the request received.
  • These connectivity parameters can for example comprise a propagation time of a data packet between a connector and an access point of the communication infrastructure.
  • the parameter may further comprise a propagation time between two connectors participating in the data transport service.
  • the connectivity parameters can further comprise a type of technology (xDSL, Fibre, Wi-Fi, 4G, 5G%) used to connect a connector to the communications infrastructure.
  • the type of technology can be dissociated between the type of transport technology (Ethernet, IP, LTE%) and the transport infrastructure (fiber, copper, Coaxial, Wi-Fi).
  • a total bandwidth (connectivity subscription profile (guaranteed max uplink/downlink etc%)) associated with each connector or even a bandwidth available for transporting data from the transport service can also be obtained by the Optim entity .
  • the connectivity parameters may further comprise a technology and/or a security protocol used for communications between a connector and an access point of the communication infrastructure.
  • the Optim entity can also obtain from the Logic entity the software characteristics of the applications required for the data transport service. These software characteristics may include licenses associated with applications, storage space characteristics to be used to deploy applications, or application data processing times.
  • the Optim entity determines at least one suite of connectors, hosting data and applications, to implement the transport service of data requested. This determination requires selecting the connectors offering connectivity, data routing and data processing characteristics that are the most suitable for the request received. In particular, these connectors are selected to obtain the best QoS and/or the least cost, for example in accordance with a parameter present in the SOC.
  • This determination can also include the instantiation of an application in an existing connector to limit the traffic to be exchanged, for example by instantiating applications as close as possible to the connectors where transported data is stored. This instantiation requires identifying connectors to proximity of data sources, for example based on connector geolocation information transmitted by the Gest entity or the MEC Connec entity, or even the MECs themselves.
  • the determination may also include the implementation of a new connector in the event that the existing connectors do not achieve the required QoS or if other connectors can improve the QoS.
  • This implementation can be carried out by searching among the MEC connectivity providers, for example by requesting the MEC Connec entity, the MEC storage spaces compatible with the criteria in particular of security and confidentiality of the virtual data space.
  • the Optim entity determines for the different paths, each composed of a series of connectors, a data transport quality parameter.
  • the adaptation of the paths to the transport of the data as required is determined. This may involve, for example, calculating an end-to-end QoS and a cost associated with data transport by respecting the rules for using the data and taking into account the processing of applications on the path.
  • These paths may include new connectors and may also include new instantiated applications, which requires assessing the QoS for routing and processing service data in the virtual data space.
  • the determined paths and possibly the associated quality of service parameters are transmitted to the Consom entity and possibly to the Prop 1 and Prop 2 entities.
  • This sending allows these entities to be able to select or to be able to eliminate one or more paths from the list.
  • the Consom entity may choose a path with good QoS while an entity, such as Prop 1, may prohibit a path due to the presence of a connector or an application on the path that could compromise Datas.
  • the Consum, Prop 1 and Prop 2 entities transmit their choice to the Optim entity in response to the request from the Optim entity.
  • the Optim entity sets up the path(s) (s).
  • This implementation consists of setting up connections between connectors providing and consuming data, instantiating applications for data processing if necessary, or even instantiating new connectors.
  • the Optim entity can set up this path(s) independently or by requesting the Logic entities, MEC Connec as well as the operators in charge of the communications infrastructure.
  • FIG 4 presents an example of the structure of a data transport service processing device according to another embodiment of the invention.
  • the device 400 for processing a data transport service implements the method for processing a data transport service, various embodiments of which have just been described.
  • Such a device 400 can be implemented in an application service management entity or else in a telecommunications network management entity, deployed based on virtualized functions or physical equipment.
  • the device 400 comprises a processing unit 430, equipped for example with a microprocessor pP, and controlled by a computer program 410, stored in a memory 420 and implementing the determination method according to the invention.
  • a computer program 410 stored in a memory 420 and implementing the determination method according to the invention.
  • the code instructions of the computer program 410 are for example loaded into a RAM memory, before being executed by the processor of the processing unit 430.
  • Such a device 400 comprises:
  • a receiver 403 capable of receiving a Req request for deployment of the data transport service from a data management agent
  • module 401 for obtaining capable of obtaining a connectivity parameter to the communication infrastructure of a connector of a site among the plurality, said connector contributing to the data transport service of the request received,
  • a computer 402 capable of determining at least one data routing path in the virtual data space, the at least one path comprising an ordered sequence of connectors selected as a function of the connectivity parameter obtained.
  • a customer of a logistics service wishes to follow the movement of his cargo of products in storage spaces (ports/warehouses) and transport services (container door, delivery truck) and the status of his storage (rental connected container (refrigerated example)).
  • the customer thus needs to obtain information on the location of his goods from the various transport services, information on the condition of his products via the sensors in his container from the container rental services, and maintenance information in the storage spaces via the entities in charge of storage services.
  • the customer can use applications to track the location of its cargo in real time as well as the status of its cargo.
  • the processing may thus consist of identifying data, correlating data with each other, protecting data.
  • a pharmaceutical company wants to analyze patient data for a specific disease and therefore needs to collect data from different hospitals in different countries without knowing the identity of the patients.
  • Applications hosted in connectors near hospitals aggregate and analyze patient data, taking care, for example, to delete information relating to patient identities.
  • MECs localized by country aggregate the patient data of a country, and the laboratory can thus aggregate the data of the different countries while respecting the local constraints of each country, requiring a specific treatment for each MEC, and minimizing the transfer of data to its connector via the appropriate use of communications infrastructures ensuring the connectivity of the MECs sites and the processing as close as possible to the MEC sites of the various countries. Only the data relevant to the laboratory are processed and transmitted, taking advantage of the specificities of the communication infrastructures.
  • a geomarketing company wishes to analyze the behavior of a population of a so-called connected city (“smart city”). It can thus subscribe to access to data from transport services to find out how many transport lines are used, with catering services (to find out about residents' dining habits), to parking services (to find out about parking habits), to navigation assistance services (to know the habits and frequentation of the roads (road lights, navigation aid), to communication services (to know the communication information of the inhabitants), to entertainment services (to analyze the entertainment of the inhabitants) ...
  • Each of these data providers may have already provided, via a virtual data space, for data processing requested by their own customers. These providers deploy applications in MECs near their data sources (sensors).
  • processing implemented by an optimization entity, can identify the applications already in place to determine the data transport paths es that respond to different customers and optimize data transport.
  • an application for example to compress data, will be preferred, taking into account the connectivity of the MEC spaces and the space where the application is implemented.
  • the data from the different suppliers will thus be routed on a path taking into account the connectivity of the data storage spaces and the spaces where processing of this data can be carried out in an optimal way to meet the requirements in terms of quality of service and cost of the service.

Abstract

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 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 (Appl, App2, App3) de traitement des données, le procédé mis en oeuvre 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; et 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.

Description

DESCRIPTION
Titre de l'invention : Procédé de traitement d’un service de transport de données
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 IDS-Reference-Architecture-Model 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. 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.
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.
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 F 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, F 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, F 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.
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.
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 [Fig 1] 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 [Fig 2] 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 [Fig 3] 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 [Fig 4] 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 [Fig 1] 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 loT (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 Cl, C2, C3 sur la [Eig 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 [Fig 2], 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 [Fig 2], 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 [Fig 1]. 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 Servie 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 servie. L’espace MEC1 héberge par exemple des données des entités Propl 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 [Fig 2] où les espaces MEC1, MEC2 et MEC3 hébergent respectivement les applications Appl, 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 Servie, 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 .
H 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. 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 [Fig 3], 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 El, 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.
H 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 [Eig 3] 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 [Fig 4] 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 pP, 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.
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 connaître la fréquentation des lignes de transport, auprès de services de restaurations (pour connaître les habitudes de restaurations des habitants), à des services de parking (pour connaître les habitudes de parking), à des services d’aide à la navigation (pour connaître les habitudes et la fréquentation des routes (feux routiers, aide à la navigation), à des services de communications (pour connaître 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

23
REVENDICATIONS 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 (Appl, 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 F 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 F 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 F 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.
PCT/FR2021/051292 2020-08-10 2021-07-12 Procede de traitement d'un service de transport de donnees WO2022034273A1 (fr)

Priority Applications (2)

Application Number Priority Date Filing Date Title
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
FRFR2008388 2020-08-10
FR2008388A FR3113346A1 (fr) 2020-08-10 2020-08-10 Procédé de traitement d’un service de transport de données

Publications (1)

Publication Number Publication Date
WO2022034273A1 true WO2022034273A1 (fr) 2022-02-17

Family

ID=74095860

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/FR2021/051292 WO2022034273A1 (fr) 2020-08-10 2021-07-12 Procede de traitement d'un service de transport de donnees

Country Status (4)

Country Link
US (1) US20230283664A1 (fr)
EP (1) EP4193569A1 (fr)
FR (1) FR3113346A1 (fr)
WO (1) WO2022034273A1 (fr)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2023217639A1 (fr) * 2022-05-12 2023-11-16 Orange Procédé, dispositif et système d'élaboration dynamique d'une infrastructure de données

Citations (1)

* Cited by examiner, † Cited by third party
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

Patent Citations (1)

* Cited by examiner, † Cited by third party
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)

* Cited by examiner, † Cited by third party
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] *

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2023217639A1 (fr) * 2022-05-12 2023-11-16 Orange Procédé, dispositif et système d'élaboration dynamique d'une infrastructure de données
FR3135584A1 (fr) * 2022-05-12 2023-11-17 Orange Procédé, dispositif et système d’élaboration dynamique d’une infrastructure de données

Also Published As

Publication number Publication date
US20230283664A1 (en) 2023-09-07
FR3113346A1 (fr) 2022-02-11
EP4193569A1 (fr) 2023-06-14

Similar Documents

Publication Publication Date Title
Sabella et al. Developing software for multi-access edge computing
EP3931694A1 (fr) Procédé d&#39;évaluation des dispositifs d&#39;une infrastructure de réseau en vue du déploiement d&#39;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&#39;obtention d&#39;identifiants de pairs en vue d&#39;acceder en mode p2p a des contenus qu&#39;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&#39;un réseau mobile large bande
EP4193569A1 (fr) Procede de traitement d&#39;un service de transport de donnees
WO2020260025A1 (fr) Procede d&#39;allocation de ressources d&#39;une infrastructure de reseau
EP2446360B1 (fr) Technique de determination d&#39;une chaine de fonctions elementaires associee a un service
EP2591587B1 (fr) Accès confidentiel ou protégé à un réseau de noeuds répartis sur une architecture de communication à l&#39;aide d&#39;un serveur de topoloqie
EP2591588B1 (fr) Accès à un réseau de noeuds répartis sur une architecture de communication a l&#39;aide d&#39;un serveur de topologie avec sélection multicritères
EP2150090B1 (fr) Terminal multimode à connextions optimisées
WO2022208017A1 (fr) Procede, dispositif et systeme de mise a disposition d&#39;une ressource de communication
WO2023135043A1 (fr) Procédé, dispositif et système de modification d&#39;une infrastructure de communication
WO2023217638A1 (fr) Procédé, dispositif et système de certification d&#39;une ressource
WO2023217639A1 (fr) Procédé, dispositif et système d&#39;élaboration dynamique d&#39;une infrastructure de données
EP4145794A1 (fr) Procédé d&#39;intégration dynamique mis en uvre au cours de la fédération de réseaux de radiocommunication et produit programme d&#39;ordinateur
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
WO2023281181A1 (fr) Procede et dispositif de configuration d&#39;une unite d&#39;acces dans un environnement virtualise
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&#39;ordinateur associés
EP3839738A1 (fr) Procede de gestion des requetes d&#39;allocation d&#39;une ressource informatique
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.
EP4066520A1 (fr) Procede de gestion d&#39;une connexion ininterrompue d&#39;un dispositif en deplacement
WO2017109367A1 (fr) Procédé d&#39;allocation de ressources d&#39;exécution
WO2014091131A1 (fr) Sélection multicritères de systèmes de diffusion de contenu

Legal Events

Date Code Title Description
WWE Wipo information: entry into national phase

Ref document number: 2021749675

Country of ref document: EP

NENP Non-entry into the national phase

Ref country code: DE

ENP Entry into the national phase

Ref document number: 2021749675

Country of ref document: EP

Effective date: 20230310