EP4042641A1 - Procede de controle d'un flux de donnees associe a un processus au sein d'un reseau mutualise - Google Patents

Procede de controle d'un flux de donnees associe a un processus au sein d'un reseau mutualise

Info

Publication number
EP4042641A1
EP4042641A1 EP20790370.9A EP20790370A EP4042641A1 EP 4042641 A1 EP4042641 A1 EP 4042641A1 EP 20790370 A EP20790370 A EP 20790370A EP 4042641 A1 EP4042641 A1 EP 4042641A1
Authority
EP
European Patent Office
Prior art keywords
data
control
flow
parameter
network
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
EP20790370.9A
Other languages
German (de)
English (en)
Inventor
Nicolas Bihannic
Jean-Michel CORNILY
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Orange SA
Original Assignee
Orange SA
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 SA filed Critical Orange SA
Publication of EP4042641A1 publication Critical patent/EP4042641A1/fr
Pending legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/40—Support for services or applications
    • H04L65/403—Arrangements for multi-party communication, e.g. for conferences
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/38—Flow based routing
    • 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/0876—Network utilisation, e.g. volume of load or congestion level
    • H04L43/0882—Utilisation of link capacity
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/24—Multipath
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/10—Architectures or entities
    • H04L65/1045—Proxies, e.g. for session initiation protocol [SIP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/1066—Session management
    • H04L65/1073—Registration or de-registration
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/75—Media network packet handling
    • H04L65/765—Media network packet handling intermediate
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/10—Architectures or entities
    • H04L65/102—Gateways
    • H04L65/1023—Media gateways
    • H04L65/103—Media gateways in the network

Definitions

  • the invention relates to the identification and routing of process data in a communication network, in particular structured into data paths having, for example, quality of service, security and common routing characteristics. This involves, for example, managing flows associated with specific services in a network comprising network slices, also called "network slices" in English.
  • the product or service delivered is more and more personalized, specific to a customer or to a set of customers, requiring appropriate monitoring of the process of implementing the product or service.
  • a process may require the intervention of several actors.
  • one (or more) supplier (s) of industrial equipment, one (or more) supplier (s) of connectivity services, one (or more) supplier (s) of business applications, one (or more) cloud infrastructure provider (s) or even a process integrator involving the various actors mentioned above, can thus intervene in the implementation of the process.
  • a process can further include a variety of services which can be performed simultaneously or sequentially.
  • the process may require group calls between workers within production lines, IoT (Internet of Things) type communications to collect machine operating information, or transmission of application data to devices. customers who are the recipients of the product or service resulting from the process.
  • IoT Internet of Things
  • customers who are the recipients of the product or service resulting from the process.
  • Each of these services, associated with the process has different connectivity needs in terms of volume, tolerance to packet loss, responsiveness for example to piloting commands, as well as very different supervision requirements depending on their level of criticality.
  • 5G (Fifth Generation) technology must be a facilitator in the implementation of these requirements, in particular through the support of data routing services that are specific to each of the services mentioned above.
  • the slices of networks implemented in 5G technology are deployed in particular to convey data having common characteristics in terms of quality of service, security and management. Thus, separate processes requiring the same connectivity characteristics will have their data routed within a single network slice. Also, the data streams of a process that correspond to distinct services will likely be routed over different network slices. Indeed, the operator of the communication service organizes his communication network by routing all the data having common characteristics from the point of view of the network but possibly relating to separate customers, in the same network slice. For example, the operator deploys a network slice for IoT data, a network slice for very critical data, a network slice for Best-Effort data.
  • the network operator administers its network according to its own needs and deploys mechanisms for managing and monitoring the traffic of a network slice according to its own constraints.
  • the company in charge of the process does not have dynamically configured supervision information specific to its process and therefore cannot supervise and adapt the process control, for example to modify the process in question according to this control.
  • Network architectures and monitoring solutions also do not make it possible to quickly detect a problem that may arise on one of the services making up the process, complicating and delaying the decisions taken to resolve the problem.
  • the object of the present invention is to provide improvements over the state of the art.
  • the invention improves the situation using a method for controlling a flow of data associated with a process and routed in a shared data path, comprising a plurality of flows, of a communication network, said method being implemented in a device of said path and comprising receiving, from a supervision entity, information identifying the flow to be controlled, the configuration of at least one flow control parameter, said parameter being relating to the process corresponding to the information received and the execution of an operation to control the flow of data as a function of at least one configured parameter.
  • the method makes it possible to differentiate the options for monitoring a flow within a shared data path.
  • the data path is supervised in a uniform manner for all the data of the path, that is to say that the data of the different flows within the path are controlled with the same characteristics or control parameters.
  • the flows of the same data path can have the same routing parameters, i.e. the data of the flows are routed according to quality of service and quality criteria. comparable security.
  • control of one flow must be able to be differentiated from the control of another flow, associated with another process, and also require the implementation. of the control process.
  • the method makes it possible to be able to dynamically configure control parameters for a specific flow of data in a shared (or pooled) data path, thus making it possible to improve the supervision of the process.
  • the shared data path corresponds to a network slice.
  • the data flows are routed in slices of network, also called "network slices".
  • the data of a network slice are routed according to common routing characteristics and the method makes it possible to customize the type of supervision of a particular flow within a network slice comprising a plurality of data flows, corresponding to possibly separate processes.
  • the flow identification information comprises a process identifier, and optionally at least one identifier from an identifier of the shared data path, an identifier of the device, a identifier of the supervision entity.
  • a flow can advantageously be identified by a process identifier with which it is associated to facilitate the use and association of the control data received.
  • the process identifier can be supplemented by a data path identifier, for example a network slice identifier, knowing that data from the same process can be routed on different data paths depending, for example, on their requirement. in terms of quality of service.
  • a device identifier can be used in addition to the process identifier and optionally to the identifier of a path of data.
  • An identifier of the supervision entity can also be used as an identifier in addition to the process identifier, in particular to verify that the supervision entity actually corresponds to the process to be controlled.
  • At least one flow control parameter is obtained from the supervision entity prior to the configuration of said parameter by the device.
  • the supervision entity can advantageously transmit the flow control parameter (s) in addition to the identifier of the flow to be supervised. These two pieces of information can be transmitted simultaneously or separately.
  • a specific sending of the control parameter (s) can be sent to modify the parameter while the data of the flow is conveyed. in the shared path.
  • At least one flow control parameter comprises at least one parameter from: a field of flow data, a period during which flow control is executed, a frequency corresponding to the number of iterations of the control operation per unit of time, a method of calculating the control data, the type of interface used to perform the control operation, data for synchronization of control operations control.
  • the control parameter can make it possible to evaluate a specific field of data in the stream, for example a field relating to the quality of service. It may be advantageous to indicate a control period in the case where the control is carried out for a limited period, meeting a specific need or the detection of an incident in the implementation of the process. It is possible to collect monitoring data at specific intervals depending on the type of process to be monitored, among other things. A process requiring high availability requires, for example, a higher frequency.
  • the calculation method corresponds for example to a calculation of average value of a controlled datum or to a calculation of instantaneous value.
  • the type of interface may depend on the type and frequency of control.
  • a streaming interface on the device is preferred for frequent uploading of data while a file transfer interface is more suitable for less frequent uploading of control data.
  • a synchronization datum such as a clock
  • control method further comprises sending to the supervisory entity a result of the control operation performed.
  • the device sends the supervision entity a result of the control carried out allowing the supervision entity to make a decision based on the result.
  • the decision may, for example, be to request that the process data flow be routed on another data path or that the data flow be supervised in accordance with another control parameter.
  • control method further comprises receiving from another device the data path of a message comprising information taken into account by the device to configure the control parameter.
  • a process usually involves a plurality of devices that can exercise control over the flow of data.
  • a second device or even several other devices, can influence the control exerted by a first device, for example by transmitting a result of a control and thus modify a control parameter of the first device.
  • This allows distributed and coordinated control of the process to be achieved across multiple devices, each of which can exercise control over some or some process data. These devices can act on the same data path or on several data paths.
  • the control operation comprises an operation of correlating a result of a control carried out on a second data flow, with a result resulting from the control on the flow of data.
  • a process can be associated with several data flows, each of the flows being for example established to transport data having the same routing characteristics.
  • a process may for example comprise a real-time data stream and a “best effort” type data stream, or “audio” and “video” data streams, the two streams being routed on the same shared data path or two separate data paths.
  • the control operation may consist of obtaining data from the control of each flow as well as a correlation operation of the various data received and then transmitting a result of the control of the process to the supervision entity or to another entity.
  • the second data stream of the correlation operation is routed in a control plane of the communication network and the data flow is routed in the transfer plane of the communication network.
  • the data stream is transmitted in a network slice established in the shared data path.
  • a network slice allows processing specific to flows having common routing characteristics.
  • a data flow of a process can be transmitted in a network slice, or slice, which network slice can itself be included in a network slice in the case where the shared data path is a network slice.
  • the data flow control operation can correspond to a specific processing associated with the network slice associated with the process.
  • a network sub-slice may have specific, process-specific control parameters within a network slice having generic control parameters independent of the process data conveyed in that slice. This configuration is directly applicable to the framework of a wholesale offer where the operator, subscribing to this wholesale offer, implements network sub-slices.
  • control method further comprises a reconfiguration of at least one parameter following the execution of the data flow control operation.
  • the method makes it possible to be able to reconfigure a control parameter following the execution of the control and thus to be able to adapt the control according in particular to the first results obtained once the control operation has been initiated. Thus, depending on the results obtained, it may be useful to control other parameters of the flow or to modify the initially controlled parameter, and thus improve, deepen or diversify the control operation carried out.
  • control method which have just been described can be implemented independently of one another or in combination with one another.
  • the invention also relates to a device for controlling a flow of data associated with a process and routed in a shared data path, comprising a plurality of flows of a communication network, implemented in a device of said path and comprising a receiver, able to receive from a supervision entity information identifying the flow to be controlled, a configuration module able to configure a flow control parameter, said parameter relating to the process corresponding to the information received , a controller, capable of performing an operation for controlling the data flow as a function of the configured parameter.
  • This device capable of implementing the control method which has just been described in all its embodiments, is intended to be implemented in an entity of a communications infrastructure, in a virtualized infrastructure or in a infrastructure based on physical equipment.
  • the device can be implemented in an entity of the network equipment type such as a router or an application server.
  • the invention also relates to a system for controlling a flow of data associated with a process and routed in a shared data path comprising a plurality of flows, of a communication network, the system comprising:
  • the invention also relates to a computer program comprising instructions for implementing the steps of the control method which has just been described, when this program is executed by a processor and a recording medium readable by a recording device. control over which the computer program is recorded.
  • This program can 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 a 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 else 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 medium can 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 shows a simplified view of an environment in which the invention is implemented according to one aspect of the invention.
  • FIG 2 shows a logical architecture of an environment in which the invention is implemented according to another aspect of the invention.
  • FIG 3 shows an architecture of a communication network in which the invention is implemented according to a first embodiment of the invention.
  • FIG 4 shows an architecture of a communication network in which the invention is implemented according to yet a second embodiment of the invention
  • FIG 5 shows an architecture of a communication network in which the invention is implemented according to yet a third embodiment of the invention.
  • FIG 6 presents an overview of the control method according to a fourth embodiment of the invention.
  • FIG 7 presents an overview of the control method according to a fifth embodiment of the invention.
  • FIG 8 shows an example of the structure of a control device according to one aspect of the invention.
  • embodiments of the invention are presented in a communication network.
  • This network can be implemented in a fixed or mobile infrastructure and the invention can be intended to ensure control of industrial processes, service delivery processes or any other process related to the provision of a service intended for a client or for the own needs of the company deploying it.
  • FIG. 1 presents a simplified view of an environment in which the invention according to one aspect of the invention is implemented.
  • an Indus company produces an industrial good from a process requiring the contribution of a plurality of actors.
  • the process also called business process, is defined as a set of tasks performed by the different actors, the control of the realization of the process leading to the production of the industrial good based on the supervision of each task of the process.
  • the various players do not necessarily have knowledge of the industrial good and, according to the prior art, transmit supervision data specific to their environment and not specific to monitoring the process of producing the industrial good produced by Indus.
  • the Indus company interacts with an Integ integrator responsible for monitoring, coordinating the various tasks of the process and advancing the tasks allowing the achievement of the good.
  • the Indus company also plays the role of the integrator.
  • Carrying out the process also requires the contribution of at least one supplier of industrial equipment Equipt in charge of the implementation of equipment allowing the manufacture of the industrial good.
  • At least one app business application provider is also involved in the process. These applications can correspond, for example, to servers in charge of analyzing the operating data of industrial equipment.
  • At least one Infra infrastructure provider for example of the Cloud type, is also likely to intervene in particular to store applications and data relating to the process.
  • the progress of the process also requires at least one connectivity provider Connect ensuring the transmission of the various data relating to the stages of the process between the various actors intervening in the process.
  • the connectivity provider ensures supervision of the connectivity service independently of the process for which it transmits data.
  • the connectivity provider Connect ensures, for example, that the data it transmits does not suffer from packet loss, that the quality of service classes are respected for the different data flows carried, that the data for a given client are well counted and invoiced if necessary, that the commitments in terms of security for a customer are well respected but the connectivity provider Connect, according to the prior art, does not carry out checks data specific to the product's manufacturing process.
  • the connectivity provider Connect does not carry out checks data specific to the product's manufacturing process.
  • the connectivity provider Connect controls the data flows specific to the manufacturing process as a function of a request issued by a monitoring device of the Indus actor or even of the actor Integ depending on the case.
  • a device for the supervision of the Equipt, App, Infra actors can also transmit a control request to a device of the Connect actor, for example to correlate the control information of the Connect entity with their own control of manufacturing process data.
  • the Equipt, App, Infra or even Integ entities also have communications networks and can implement the control method according to the invention as the Connect actor.
  • the different actors intervening in the process as described in [Fig 1] also intervene in the process of [Fig 2].
  • the players Indus, Integ, Equipt, Infra, Connect and App are thus represented.
  • the same structure can play the role of one or more actors.
  • the same structure or company can intervene as Integ and Connect for example.
  • Each actor has at least one supervision entity.
  • the Integ actor administers an Integ Super supervision entity
  • the Equipt actor manages the Eq Sup supervision entity
  • the Infra, Connect and App actors administer respectively the Infra Sup, Connect Sup and App Sup entities.
  • the supervisory entities of the various actors control the functioning of the mechanisms specific to the actor.
  • the entity Eq sup controls the operation of an industrial equipment EL
  • the supervision entities are each able to control more than one device, [Fig 2] representing only one for each supervision entity.
  • the Infra Sup, Connect Sup and App Sup entities respectively control the operation of the Eqt Infra devices (Eq Res 1 and Eq Res 2), and the EA application equipment.
  • the Connect Sup entity controls the operation of the Eq Res 1 and Eq Res 2 equipment, the Eq Res 1 device intervening in the control plan Contrl and the Eq Res 2 device intervening in the transfer plan Transf of the network communication managed by the Connect actor.
  • Each supervision entity is also connected to a database (BdD1, BdD2, BdD3 and BdD4) to store the data resulting from the control carried out on the respective equipment items by the supervision entities.
  • the Integ actor has a BdDi database integrating the various data resulting from the checks carried out by the Equipt, Infra, Connect, App actors.
  • a supervision entity is likely to call on the devices of the communication network involved in the implementation of the process and transmits information identifying a process to be controlled.
  • the requested devices configure one or more control parameters relating to the identified process and perform the control operations according to the configured parameters.
  • the network equipments Eq Res 1 and Eq Res 2 receive identifiers of the flow to be controlled, configure control parameters to control the data flows of a process, and perform the control.
  • the Eq Resl device thus performs a control of data specific to a process in the Control control plane and the Eq Res 2 device performs a control of the data routed in the Transfer plane Transf of the Connect network for the process identified by the information. previously transmitted by the Connect Sup entity. It should be noted that an entity of supervision of an actor can transmit the identification information of the process to devices of other actors involved in the process.
  • the Integ Sup entity can thus directly or indirectly transmit a process identifier to the devices Eq Res 1 and Eq Res 2 so that the latter carry out a control of the process identified by the transmitted identifier.
  • this data path can be a network slice, a virtual private network, a leased link or any other technique making it possible to aggregate or multiplex data relating to customers or different processes
  • the process identifier makes it possible to control only the data specific to the process. This makes it possible to be able to use them directly or to be able to aggregate them more easily in order to transmit them for example to the Indus actor, each actor intervening in the process possibly implementing the same control process.
  • FIG. 3 an architecture of a communication network in which the invention is implemented according to a first embodiment of the invention is presented.
  • three industry business processes PMI, PM2, PM3 are controlled.
  • the three processes are respectively a PMI process for ordering a product, a process PM2 for manufacturing a product and a process PM3 for transporting the product manufactured within a factory.
  • These three processes PMI, PM2, PM3 require data exchanges between different equipment, different teams and different business applications.
  • the PMI process requires data exchanges between an industrial order-taking equipment Eli and an order management business application AMI, this Eli equipment and this AMI business application exchanging a Flux 21 data flow on a network segment S2 of the transfer plan Transf of a communication network.
  • the data streams Stream 31 and Stream 32 transmitted by the equipment Eli and E12 on a slice S3 of the transfer plan Transf of the communication network to the business application AM3 relate to the business process PM3. Data flows can equally well be exchanged between business applications or physical or virtualized equipment.
  • the transfer plan Transf comprises 2 network slices S2 and S3 established between the network devices ET1 and ET2 while the control plane Contrl includes a network slice S 1 implemented from the devices EC1 and EC2.
  • the data flows transmitted in these network slices are specific to distinct processes and it is therefore necessary to set up the control method to ensure control of the data flows associated with the respective processes.
  • the configuration of a control parameter of a data flow such as a quality of service field of the flow, a number of packets transmitted for a flow or a duration of the control carried out is implemented from information identifying the flow to be controlled. This information, transmitted by a supervision entity not shown in [Fig.
  • the Flux 11 data stream can be identified by Flux 11, Ell-Sll or even by these identifiers to which is added a slice identifier (Flux 11, SI), (Flux 11, Ell-Sll, SI) depending on whether the data flow is rising (by a terminal to a server) or downstream (from a server to a terminal) within the Connect connectivity infrastructure.
  • An identifier of a device conveying the data of the flow (EC1, EC2 ...) and the type of plan (Control, Transfer) can also be used to identify the flow or be added to the parameters defined previously.
  • the identifier of Stream 11 may for example include a data item among the following data in addition to the identifier Stream 11 (Eli, E12, SI, Contrl, EC1, EC2).
  • An identifier of the supervision entity (such as For example Integ Sup or Connect Sup according to [Fig. 2]) transmitting the information on the identifier of the flow to be controlled can also be added to the Flow identifier (Flow 11) for identification purposes.
  • the shared data path is a network slice.
  • FIG 4 we present an architecture of a communication network in which the invention is implemented according to a second embodiment of the invention.
  • This embodiment relates to a process of a banking service requiring high availability.
  • the communication network is composed of a mobile communication network RM and an optical type communication network RO, the two networks being intended to ensure high availability of the banking service.
  • Each RM and RO network has a control plan, named Contrl RM and Contrl RO, respectively, and a transfer plan, Transf RM and Transf RO.
  • the data flows specific to the banking service, transported from the EB1 banking equipment to the AMI business application, take different data paths, each path being a shared path.
  • the Flux 11 control flow is routed in the shared path between the devices EC1 and EC2 and corresponding to an SI network slice of the Contrl RM control network of the RM mobile network, the Flux 21 transfer data stream is routed in a slice of network S2, between the devices ET1 and ET2, of the transfer network Transf RM of the mobile network RM.
  • the flow 31 and Flow 41 of control and transfer data of the optical network RO are respectively routed in the VPN3 (in English Virtual Private Network) built between the network devices EC3 and EC4, and VPN4 built between the devices ET3 and ET4 of the RO optical network.
  • the flows of the same process can be routed in separate or common shared paths.
  • FIG 4 different data streams Stream 11, Stream 21, Stream 31, Stream 41 are routed in separate shared paths of different types since they are network slices for Stream 11 and Stream 21 whereas they are VPNs for Stream 31 and Stream 41.
  • the different streams can be identified in accordance with the possibilities specified in the description of [Fig 3].
  • a single process is shown but the shared data paths (S1, S2, VPN3 and VPN4) can each include a plurality of flows of the same process and / or of separate processes.
  • a control parameter is configured for each stream (Stream 11, Stream 21, Stream 31, Stream 41) in the process. This may be a piece of data from a flow to be controlled, for example making it possible to count the packets of the flow, a period during which the flow control is executed. The control can thus be carried out for a limited period to resolve a specific problem.
  • the control parameter can include a frequency of the control operation when it is a question, for example, of taking an indicator several times in a period of time. It may also be a method of calculating control data, for example collecting instantaneous values or average values.
  • the parameter of control can also include synchronization data, such as a clock, making it possible for example to synchronize the control information received from separate streams of a process as is the case for Streams Stream 11, Stream 21, Stream 31 and Stream 41 and to be able to interpret the various control data obtained at a given instant during the execution of the control on the various flows of the process.
  • This embodiment is part of a wholesale offer, for example of the Wholesale type, from a communication network operator to a service provider deploying processes for his needs and / or himself offering services to customers, likely to be generated by processes, on the basis of the wholesale offer contracted with the operator.
  • the network operator routes the provider's transfer data in a WHS2 slot, comprising the ET1 and ET2 devices, of the Transf.
  • the provider's control data is routed in a slot WHS 1 of the control plane Contrl of the communication network, comprising the devices EC1 and EC2.
  • the ET1, ET2, EC1 and EC2 devices contribute to the implementation of at least one network slice and more than two devices can be considered for a given network slice.
  • a second service provider contracting a wholesale offer from the same operator would see its data routed in two sections, not shown on [Lig 5], distinct from the WHS1 and WHS2 sections.
  • the service provider implements 3 processes from the same Eli industrial equipment, each of the processes generating data flows to the respective business applications AMI, AM2, AM3.
  • Each data flow is routed in the transfer plane Transf in a network slice of the WHS2 slice.
  • the Llux 21 of PMI process data exchanged between the equipment Eli and the business application AMI is routed on a network slice S21 of the network slice WHS2.
  • the Stream 22 and the Stream 23 of data are routed on the slots S22 and S23 of the slot WHS2.
  • the flow 11 of the control plane Contrl of the process PM2 is routed to the slot WHS1.
  • the data flows are associated with network slices, themselves included in a network slice, forming a hierarchy of network slices.
  • the data flows of a process are in fact associated with network slices established within a network slice forming a shared data path.
  • This hierarchy can be implemented using other sharing techniques, such as VPNs or leased lines and it is also possible to envisage a mixed architecture comprising a hierarchy of shared data paths based on different technologies (slice network in a VPN for example).
  • a customer 100 requests from a process management device 101 the control of a business process involving different equipment, or even different actors and generating data exchange between industrial equipment and / or computer applications.
  • This request of the management device 101 is optional and the client 100 can directly request the supervision device 102 if he knows the device 102 in charge of controlling the process.
  • the management device 101 identifies the supervision device to be contacted for process control to be carried out. This identification is for example carried out on the basis of a process identifier, and / or a description of the process, and / or an association table of processes and supervision devices.
  • the management entity 101 sends to the supervision entity 102 identified during step 301, a request to check the data relating to the flow of the process to be controlled. In the event that several actors are involved in the process, entity 101 can identify and request several supervision entities.
  • the exchanges between the entity 101 and the entity 102 can be carried out by an HTTP (HyperText Transfer Protocol) or SNMP (Simple Network Management Protocol) type protocol or even by a specific protocol.
  • the entity 101 can also indicate to the entity 102 the frequency of collection of control data data, the rate of availability of the devices of the connectivity infrastructure or of the applications specific to the process, as well as other information suitable for determining the type of control and the parameters of this control.
  • the supervision entity 102 determines the devices to be called upon to carry out a control of the process data in accordance with the request received from the management entity 101 or from the client 100.
  • the supervision entity 102 can use a table associating the processes with the data flows. For example, entity 102 maintains a table associating processes with network slice identifiers and possibly with shared path identifiers, such as a network slice identifier, of VPNs.
  • the entity 102 can also hold a table associating the processes and the devices conveying the data of the processes and it can also associate a type of process (IoT (in English "Internet Of Things"), Streaming, Best Effort ”) with identifiers of devices involved in transporting data from these types of processes.
  • IoT in English "Internet Of Things”
  • Streaming Best Effort
  • identifiers of devices involved in transporting data from these types of processes For example, when a new process is implemented by a client, the latter indicates to the operator in charge of the supervision device 102, the types of flows generated by the process and their characteristics (quality of service, throughput, criticality, location of the equipment and applications generating the flow data, etc.) and the operator in charge of routing the data assigns one or more data paths in which (or which) the data of the process flows will be routed in depending on the characteristics of these flows.
  • the identification information of the data flow to be controlled comprises a process identifier generating the data of the flow, and optionally at least one identifier among:
  • an identifier of the shared data path such as the network slice or VPN identifier
  • an identifier of the device carrying out the check such as the identifier 105 or 106
  • the supervision entity 102 transmits to the devices 105 and 106 identified during step 303 information identifying a flow to be controlled.
  • the identification information includes the identifiers described above.
  • the supervision entity 102 also transmits flow control parameters to the devices 105 and 106.
  • the purpose of these parameters is to qualify the check and to define the parameters of the flow to be configured by the devices 105 and 106 in order to carry out the check.
  • the flow control parameters transmitted to devices 105 and 106 may be different depending on the role played by the device in the routing of data. For example, if device 105 is involved in routing control flows and device 106 is involved in routing transfer data, the control parameters may be different.
  • the control parameters as described in [Fig 3] can thus be transmitted, according to one example, by the supervision entity 102 to the devices 105 and 106 during step 304.
  • the devices 105 and 106 configure one or more parameters for controlling the flow of data generated by the process to be controlled.
  • the control parameter to be configured may have been transmitted by the supervision entity 102 during step 304 or else it may be configuration parameters determined by the devices 105 and 106 as a function in particular of the data of the process to be controlled. .
  • the devices 105 and 106 can determine the control parameters to be configured. For example, if these are critical process flows, devices can configure a packet loss rate calculation. If this is a real-time data stream, the devices will be able to configure regular monitoring of packet QoS parameters.
  • devices will be able to configure a check of the packet integrity parameters of the data stream.
  • an application-type device will be able to access the data while a communications network router will not necessarily have the keys to decrypt the encrypted data flow.
  • the devices 105 and 106 can therefore configure separate control parameters, but however, it may be necessary to synchronize these controls by configuring for example a common clock identifying the moment when the controls must be carried out by the two devices 105 and 106.
  • step 306 devices 105 and 106 perform data flow control according to the control parameter configured in step 305.
  • each flow can be controlled with control parameters specific to the process flow.
  • the control parameters are therefore specific to the data flow and / or to the device in charge of the flow control in addition to being specific to the process.
  • the control operation executed during step 306 comprises an operation of correlation of a control carried out on a second flow with a result resulting from the control on the flow to be controlled.
  • the device 105 can route data originating from a plurality of flows of the same process or of distinct processes.
  • the transmission of data from one stream may influence the transmission of data from another stream or a problem detected on two separate streams may make it possible to identify a problem on the device 105 for example.
  • all the data streams carried by the device 105 experience a degradation of quality of service or a loss of packets, then this may indicate a problem with the device. 105.
  • the possibility of correlating, comparing or aggregating control results makes it easier to identify a problem.
  • the device 106 of the data path transmits to the device 105 a message comprising information taken into account by the device 106 to configure a control parameter.
  • This condition may correspond to a result of a check that the device 106 performed on the data flow during a previous check or during the check performed. For example, if device 106 detects packet loss, it can indicate this information for device 105 to configure the packet loss control parameter as well. It can also be synchronization data so that the checks by the devices 105 and 106 are carried out at the same times. According to one example, this information is transmitted by the entity 106 via the supervision entity 102 to respond to the situation where the devices of the data path do not know each other or cannot exchange data directly.
  • the device 105 reconfigures one or more data flow control parameters.
  • This reconfiguration is consecutive to the information received during step 307 and / or it results from the control operation carried out autonomously by the device 105.
  • the device 105 detects an abnormal variation of a quality of service parameter, it can reconfigure control parameters, for example to control other fields of the protocol used to transmit the data of the process flow.
  • the devices 105 and 106 transmit, during a step 309, a result of the check carried out on the data flow in accordance with the configured control parameters.
  • This result can allow the supervision entity 102 to determine a new control to be operated on the same data flow or on a separate flow of the process and also to inform the management entity 101 and possibly the client 100 of the control results. obtained.
  • the supervision entity 102 can save the results obtained in order to assess the progress of the routing of the data of the flow of a process in a shared path of the communication network.
  • FIG. 7 an outline of the control method according to a fifth embodiment of the invention in a communication network 10 is presented.
  • the architecture of the communication network in which this embodiment is implemented is that presented in [Fig 3].
  • Two industrial equipment El 1 and El 2 are connected to the control plane and to the transfer plane of a mobile communication network.
  • the control plan is made up of 2 network devices EC1 and EC2; the transfer plan is made up of 2 network devices ET1 and ET2.
  • the Tranf transfer planes and Contrl control plans are interfaced to allow in particular the configuration of the transfer plan by the control plan.
  • This “Interface_CT” interface typically corresponds to the 3GPP N4 interface for the “Service-based Architecture” of the 5GC core network (in English “5G Core”).
  • Data flow is created according to the nature of a business process (associated with the business application). There are therefore flows relating to the control plane and flows relating to the transfer plan. Typically, for the supervision of events relating to the attachment of industrial equipment to the network or to its mobility, at least one flow will be created at the level of the control plane.
  • the flows (of the transfer plan and of the control plan) are determined from the nature of the business process (associated with the business application) and by considering industrial equipment involved in this business process. For each flow (of the transfer plane and of the control plane), there is then a unique input attribute and a unique output attribute.
  • control plan for each industrial equipment that initiates communication with the control plane, at least one flow is created to which are associated a single input attribute and a single output attribute at the level of the supervision entity of the connectivity provider.
  • control plan i) is common for the industrial equipment (Eli and EI2) of the customer's industrial tool ii) is implemented via a single IS unit.
  • SI tranche there is a creation
  • the Fluxl 1 and Fluxl2 flows participate in the business process PM2 relating to loT data exchanges. Flows 11 and 12 then make it possible to provide information on the state of attachment to the network for industrial equipment Eli and EI2 during the supervision of the business process PM2.
  • Eli industrial equipment participates in 3 business processes PMI, PM2 and PM3.
  • Connectivity to the transfer plane is via 2 slices of the communications network (or “slices” in English) S2 and S3 to differentiate the nature of the data transferred via the mobile communications network.
  • the S2 slot is used for loT data exchanges between industrial equipment and business applications AMI, AM2, AM3.
  • the S3 slice is used to manage software updates for each industrial equipment.
  • the S3 slice will require more bandwidth than the S2 slice, the S2 slice will have more continuous traffic than the S3 network slice.
  • the flows of the transfer plan are determined from the nature of the business process (associated with the business application) and by considering the industrial equipment involved in this business process. For each flow in the transfer plan, then there is a unique input attribute and a unique output attribute.
  • business processes PMI and PM2 may have similar requirements vis-à-vis the properties of the transfer plan (traffic volume, level of connectivity speed or latency, level of connectivity availability %), their differentiation, via the implementation of different flows, allows a different configuration of the control parameters which will have to be reported by the network device for each business process.
  • the business process loT PMI of the business application AMI is more critical than the business process loT PM2 of the business application AM2.
  • the ET1 and ET2 network devices will be configured so that:
  • the configured control parameter is the frequency of performance metrics feedback and will be determined according to the needs of the business process to be supervised.
  • control parameters associated with the various business process flows including the nature of the interfaces used for the execution of control operations are presented in connection with the steps in [Fig 7]. Only the steps requesting the supervision entity or a device of the communication network in charge of carrying out the control are detailed with the exception of the initial step 300.
  • Step 300 The client entity 100 transmits to a management entity 101 the list of business processes to be supervised and the overall performance expected for each business process. The following data is thus transmitted:
  • ⁇ Business Process PMI; volume of packets to be transferred: 2 Mbits / hour; frequency of reporting performance metrics to the monitoring tool: 10 minutes ⁇ ⁇ Business Process: PM2; volume of packets to be transferred: 2 Mbits / hour; performance monitoring frequency: 30 minutes ⁇
  • Step 302 sending, to the supervision entity 102, the identifiers of the devices in charge of control, the list of industrial equipment and the expected performance by business process. Sending of the following data:
  • Step 304 sending to the devices 105 representing ET1 and 106 representing ET2 identification information of the flows to be controlled and control parameters relating to the performance metrics that must be executed then transmitted by the device for each flow.
  • the manager sends the control parameters for the expected performance metrics to each device of the communication network involved in the data transmission of the flow to be controlled for which it is supervised.
  • the Flux 11 and Flux 12 flow identifiers and of control parameters are transmitted to the EC1 and EC2 equipment for the management of the Fluxl 1 and Fluxl2 flows.
  • the devices EC1 and EC2 are not shown in [Fig 7].
  • the flow identifiers and control parameters are transmitted to the 105 ET1 and 106 ET2 devices for the management of the Flux21, Flux22, Flux23, Flux31 and Flux32 flows.
  • the following 3 examples relate to the flows Flux21, Flux22 and Flux23 for device 105 ET1 of the transfer network Transf. Identical data is transmitted to device 106. It should be noted that it is proposed to use: i) the streaming interface to supervise the flows requiring frequent feedback of performance metrics by the network device concerned and ii) l 'file transfer interface in the opposite case, namely to supervise flows that do not require frequent reporting.
  • step 304 The following information is thus transmitted during step 304 to the device 105 ET1: ⁇ Network Equipment: ET1; Flux: Flux21, Input attribute: E21; Output attribute: S21; Industrial equipment: Eli; volume of packets to be transferred: 2 Mbits / hour; performance monitoring frequency: 10 minutes; value: instantaneous values; interface: streaming interface ⁇
  • the supervision entity informs, in particular in the database of its technical area, the attributes of input and output of the stream with respectively: the IP address allocated to the industrial equipment and the IP address used by the business application to communicate with this industrial equipment.
  • Steps 305 to 309 are analogous to the identical steps of [Fig 6].
  • Step 310 the supervision entity 102 detects a problem with the data flow of the PMlet business process; performance monitoring must now be configured at 10 seconds (and no longer 10 minutes).
  • Step 311 notification by the supervision entity 102 to the 105 ET1 and 106 ET2 devices concerned, of the identified business process and requiring coordinated supervision.
  • the implementation of the PMI business process indeed involves the 105 ET1 and 106 ET2 devices at the network level.
  • the supervision entity 102 then sends the 2 control parameter reconfiguration commands for the Flux21 flow of the PMl process to the 105 ET1 and 106 ET2 devices, respectively:
  • Steps 312 to 314 correspond to steps 305, 306, 309 described above with the control parameters modified in step 310.
  • the control device 105 implements the control method, various embodiments of which have just been described.
  • Such a device 105 can be implemented in an entity of a communications infrastructure, in a virtualized infrastructure or in an infrastructure based on physical equipment.
  • the device can be implemented in an entity of the network equipment type such as a router or an application server.
  • the device 105 comprises a processing unit 430, equipped for example with an mR microprocessor, and controlled by 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, able to receive from a supervision entity identification information Ident of the flow to be controlled, - a configuration module 401 able to configure a flow control parameter, said parameter relating to the process corresponding to the information received, a controller 402, able to execute an operation for controlling the data flow as a function of the configured parameter.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Multimedia (AREA)
  • Environmental & Geological Engineering (AREA)
  • Business, Economics & Management (AREA)
  • General Business, Economics & Management (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

Selon la technique antérieure, les opérateurs acheminent des données de processus distincts sur des chemins partagés et il est alors difficile de contrôler le bon acheminement des données propres à un processus en particulier, le contrôle portant de façon statique sur les données totales du chemin et non spécifiquement et dynamiquement sur des données d'un processus en particulier. L'invention concerne un procédé de contrôle d'un flux de données associées à un processus et acheminées dans un chemin partagé de données, comprenant une pluralité de flux, d'un réseau de communication, ledit procédé étant mis en œuvre dans un dispositif dudit chemin et comprenant la réception en provenance d'une entité de supervision d'une information d'identification du flux à contrôler, la configuration d'au moins un paramètre de contrôle du flux, ledit paramètre étant relatif au processus correspondant à l'information reçue et l'exécution d'une opération de contrôle du flux de données en fonction d'au moins un paramètre configuré.

Description

DESCRIPTION
Titre de l'invention : Procédé de contrôle d’un flux de données associé à un processus au sein d’un réseau mutualisé
1. Domaine technique
L'invention est relative à l’identification et à l’acheminement de données de processus dans un réseau de communication, notamment structurés en chemins de données ayant par exemple des caractéristiques de qualité de service, de sécurité et d’acheminement communes. Il s’agit par exemple de gérer des flux associés à des services spécifiques dans un réseau comprenant des tranches de réseaux, aussi appelées « network slices » en anglais.
2. Etat de la technique
Les entreprises, notamment du secteur industriel, souhaitent, dans le contexte de la digitalisation de leurs processus métiers, une forte intégration des mécanismes de contrôle des performances de leurs services de connectivité avec les mécanismes propres aux processus de leur activité. Le processus se définit comme un ensemble de tâches qui permettent le suivi de la réalisation et de la qualité du service fourni ou du produit délivré.
Le produit ou service délivré est de plus en plus personnalisé, propre à un client ou à un ensemble de clients, requérant un suivi adapté du processus de mise en œuvre du produit ou service.
Un processus peut requérir l’intervention de plusieurs acteurs. Par exemple, un (ou plusieurs) fournisseur(s) d'équipements industriels, un (ou plusieurs) fournisseur(s) de services de connectivité, un (ou plusieurs) fournisseur(s) d'applicatifs métier, un (ou plusieurs) fournisseur(s) d'infrastructure cloud voire un intégrateur du processus faisant intervenir les différents acteurs cités ci-dessus, peuvent ainsi intervenir dans la mise en œuvre du processus.
Un processus peut en outre comprendre une diversité de services qui peuvent être exécutés simultanément ou à la suite. Le processus peut par exemple requérir des appels de groupe entre travailleurs au sein des lignes de production, des communications de type loT (en anglais « Internet of Things ») pour collecter les informations de fonctionnement des machines ou encore des transmissions de données applicatives vers des clients destinataires du produit ou du service issu du processus. Chacun de ces services, associé au processus, a des besoins de connectivité différents en termes de volumétrie, de tolérance à des pertes de paquets, de réactivité par exemple à des commandes de pilotage, ainsi que des exigences de supervision très différentes suivant leur niveau de criticité. La technologie 5G (Cinquième Génération) doit être un facilitateur dans la mise en œuvre de ces exigences à travers notamment le support de services d’acheminement de données qui soient spécifiques à chacun des services cités précédemment. Les tranches de réseaux mises en œuvre dans la technologie 5G sont notamment déployées pour acheminer des données ayant des caractéristiques communes en termes de qualité de service, de sécurité, de gestion. Ainsi, des processus distincts requérant les mêmes caractéristiques de connectivité auront leurs données acheminées au sein d’une même tranche de réseau. Aussi, les flux de données d’un processus qui correspondent à des services distincts seront probablement acheminés sur des tranches de réseaux différentes. En effet, l’opérateur du service de communication organise son réseau de communication en acheminant toutes les données ayant des caractéristiques communes du point de vue du réseau mais possiblement relatives à des clients distincts, dans une même tranche de réseau. L’opérateur déploie par exemple une tranche de réseau pour les données IoT, une tranche de réseau pour les données très critiques, une tranche de réseau pour les données Best-Effort. En outre, l’opérateur de réseau administre son réseau suivant ses propres besoins et déploie des mécanismes de gestion et de suivi de trafic d’une tranche de réseau en fonction de ses propres contraintes. L’entreprise en charge du processus ne dispose pas d’informations de supervision dynamiquement configurées et propres à son processus et ne peut donc pas superviser et adapter le contrôle du processus par exemple pour modifier le processus en question en fonction de ce contrôle. Les architectures des réseaux et les solutions de supervision ne permettent pas en outre de détecter rapidement un problème pouvant survenir sur l’un des services composant le processus, compliquant et retardant les décisions prises pour résoudre le problème.
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 contrôle d’un flux de données associées à un processus et acheminées dans un chemin partagé de données, comprenant une pluralité de flux, d’un réseau de communication, ledit procédé étant mis en œuvre dans un dispositif dudit chemin et comprenant la réception en provenance d’une entité de supervision d’une information d’identification du flux à contrôler, la configuration d’au moins un paramètre de contrôle du flux, ledit paramètre étant relatif au processus correspondant à l’information reçue et l’exécution d’une opération de contrôle du flux de données en fonction d’au moins un paramètre configuré.
Le procédé permet de pouvoir différencier les options de supervision d’un flux au sein d’un chemin partagé de données. Selon la technique antérieure, le chemin de données est supervisé de façon uniforme pour l’ensemble des données du chemin, c’est-à-dire que les données des différents flux au sein du chemin sont contrôlées avec les mêmes caractéristiques ou paramètres de contrôle. Dans les architectures de réseaux mises en œuvre, les flux d’un même chemin de données peuvent avoir les mêmes paramètres d’acheminement, c’est-à-dire que les données des flux sont routées selon des critères de qualité de service et de sécurité comparables.
Cependant, en fonction de la nature de ces flux et notamment des processus associés aux différents flux, le contrôle d’un flux doit pouvoir se différencier du contrôle d’un autre flux, associé à un autre processus, et aussi requérir la mise en œuvre du procédé de contrôle. Le procédé permet en effet de pouvoir configurer de façon dynamique des paramètres de contrôle pour un flux spécifique de données dans un chemin partagé (ou mutualisé) de données, permettant ainsi d’améliorer la supervision du processus. Il est en effet ainsi possible de modifier dynamiquement les paramètres de contrôle d’un flux, de prévoir une remontée d’information de supervision adaptée au flux et d’analyser des caractéristiques spécifiques des données en fonction du type, de la criticité en termes de disponibilité, des exigences en termes de qualité de service d’un processus dont les données sont transmises dans un chemin de données, par exemple en utilisant des méthodes de multiplexage et/ou de structuration en tranches de réseau.
Selon un aspect de l'invention, dans le procédé de contrôle, le chemin partagé de données correspond à une tranche de réseau.
Dans les architectures de réseau en cours de spécification, par exemple de type 5G (Cinquième Génération), les flux de données sont acheminés dans des tranches de réseau, aussi appelées « network slices » (en anglais). Les données d’une tranche de réseau sont acheminées selon des caractéristiques d’acheminement communes et le procédé permet de personnaliser le type de supervision d’un flux en particulier au sein d’une tranche de réseau comprenant une pluralité de flux de données, correspondant possiblement à des processus distincts.
Selon un autre aspect de l’invention, dans le procédé de contrôle, l’information d’identification du flux comprend un identifiant de processus, et optionnellement au moins un identifiant parmi un identifiant du chemin de données partagé, un identifiant du dispositif, un identifiant de l’entité de supervision.
Un flux peut avantageusement être identifié par un identifiant de processus auquel il est associé pour faciliter l’exploitation et l’association des données de contrôle reçues. L’identifiant de processus peut être complété par un identifiant de chemin de données, par exemple un identifiant de tranche de réseau, sachant que des données d’un même processus peuvent être acheminées sur des chemins de données différents en fonction par exemple de leur exigence en termes de qualité de service. Dans le cas où certaines données d’un processus doivent transiter par un dispositif spécifique, par exemple pour des raisons de sécurité, un identifiant du dispositif peut être utilisé en complément de l’identifiant de processus et optionnellement de l’identifiant d’un chemin de données. Un identifiant de l’entité de supervision peut en outre être utilisé comme identifiant en complément de l’identifiant de processus, notamment pour vérifier que l’entité de supervision correspond effectivement au processus à contrôler.
Selon un autre aspect de l’invention, dans le procédé de contrôle, l’au moins un paramètre de contrôle du flux est obtenu en provenance de l’entité de supervision préalablement à la configuration dudit paramètre par le dispositif.
L’entité de supervision peut avantageusement transmettre le (ou les) paramètre(s) de contrôle du flux en plus de l’identifiant du flux à superviser. Ces deux informations peuvent être transmises simultanément ou de façon distinctes. Notamment, si l’entité de supervision souhaite modifier le paramètre de contrôle de façon dynamique pour améliorer le suivi du processus, un envoi spécifique du (ou des) paramètres de contrôle peut être émis pour modifier le paramètre alors que des données du flux sont acheminées dans le chemin partagé.
Selon un autre aspect de l’invention, dans le procédé de contrôle, au moins un paramètre de contrôle du flux comprend au moins un paramètre parmi : un champ d’une donnée du flux, une période pendant laquelle le contrôle du flux est exécuté, une fréquence correspondant au nombre d’itérations de l’opération de contrôle par unité de temps, un mode de calcul des données de contrôle, le type d’interface utilisé pour effectuer l’opération de contrôle, une donnée de synchronisation d’opérations de contrôle.
Le paramètre de contrôle peut permettre d’évaluer un champ spécifique d’une donnée du flux, par exemple un champ relatif à la qualité de service. Il peut être avantageux d’indiquer une durée de contrôle dans le cas où le contrôle est effectué pendant une durée limitée, répondant à un besoin spécifique ou à une détection d’un incident dans la mise en œuvre du processus. Il est possible de collecter des données de contrôle à des intervalles spécifiques en fonction notamment du type de processus à contrôler. Un processus requérant une forte disponibilité requiert par exemple une fréquence plus élevée. Le mode de calcul correspond par exemple à un calcul de valeur moyenne d’une donnée contrôlée ou bien à un calcul de valeur instantanée. Le type d’interface peut dépendre du type et de la fréquence de contrôle. Ainsi, une interface de streaming sur le dispositif est privilégiée pour une remontée fréquente de données alors qu’une interface de transfert de fichiers est plus adaptée à une remontée moins fréquente de données de contrôle. Notamment dans le cas où plusieurs flux de données relatifs à un processus sont contrôlés, l’ajout d’une donnée de synchronisation, telle qu’une horloge, permet de corréler les différentes opérations et de pouvoir interpréter les résultats d’opérations de contrôle effectués sur les différents flux. La donnée de synchronisation permet en outre de suivre l’évolution des résultats des opérations de contrôle dans le temps.
Selon un autre aspect de l’invention, le procédé de contrôle comprend en outre l’émission à destination de l’entité de supervision d’un résultat de l’opération de contrôle exécutée.
Une fois le contrôle effectué sur le flux identifié et conformément au paramètre de contrôle configuré, le dispositif émet à destination de l’entité de supervision un résultat du contrôle opéré permettant à l’entité de supervision de prendre une décision en fonction du résultat. La décision peut par exemple consister à requérir que le flux de données du processus soit acheminé sur un autre chemin de données ou que le flux de données soit supervisé conformément à un autre paramètre de contrôle.
Selon un autre aspect de l’invention, le procédé de contrôle comprend en outre la réception en provenance d’un autre dispositif du chemin de données d’un message comprenant une information prise en compte par le dispositif pour configurer le paramètre de contrôle.
Un processus fait le plus souvent intervenir une pluralité de dispositifs pouvant exercer un contrôle sur le flux de données. Un deuxième dispositif, voire plusieurs autres dispositifs, peut influer sur le contrôle exercé par un premier dispositif par exemple en transmettant un résultat d’un contrôle et ainsi modifier un paramètre de contrôle du premier dispositif. Cela permet d’effectuer un contrôle réparti et coordonné du processus sur plusieurs dispositifs, chacun de ces dispositifs pouvant exercer un contrôle d’une partie ou de certaines données du processus. Ces dispositifs peuvent agir sur un même chemin de données ou sur plusieurs chemins de données.
Selon un autre aspect de l’invention, dans le procédé de contrôle, l’opération de contrôle comprend une opération de corrélation d’un résultat d’un contrôle effectué sur un deuxième flux de données, avec un résultat issu du contrôle sur le flux de données.
Un processus peut être associé à plusieurs flux de données, chacun des flux étant par exemple établi pour transporter des données ayant les mêmes caractéristiques d’acheminement. Un processus peut comprendre par exemple un flux de données temps réel et un flux de données de type « best effort », ou des flux de données « audio » et « vidéo », les deux flux étant acheminés sur un même chemin partagé de données ou deux chemins de données distincts. L’opération de contrôle peut consister à obtenir des données issues du contrôle de chaque flux ainsi qu’une opération de corrélation des différentes données reçues pour ensuite transmettre un résultat du contrôle du processus à l’entité de supervision ou à une autre entité.
Selon un autre aspect de l’invention, dans le procédé de contrôle, le deuxième flux de données de l’opération de corrélation est acheminé dans un plan de contrôle du réseau de communication et le flux de données est acheminé dans le plan de transfert du réseau de communication.
Il est avantageux de pouvoir aussi bien contrôler les données d’un processus émises dans le plan de contrôle en plus du contrôle effectué sur les données émises dans le plan de transfert pour identifier les problèmes survenant sur un processus. Les contrôles d’établissement d’une connexion ou de résolution d’un nom de domaine DNS (en anglais « Domain Name System »), effectués dans le plan de contrôle, peuvent en effet être avantageusement utilisés en complément du contrôle des flux dans le plan de transfert pour détecter des anomalies ou des problèmes sur un processus, ces anomalies pouvant indifféremment survenir lors de l’établissement ou lors de la gestion d’un flux comme dans la transmission des données du flux dans le plan de transfert.
Selon un autre aspect de l’invention, dans le procédé de contrôle, le flux de données est transmis dans une tranche de réseau établie dans le chemin partagé de données. Une tranche de réseau permet d’effectuer des traitements spécifiques à des flux ayant des caractéristiques d’acheminement communes. Un flux de données d’un processus peut être transmis dans une tranche de réseau, ou slice, cette tranche de réseau pouvant elle-même être comprise dans une tranche de réseau dans le cas où le chemin partagé de données est une tranche de réseau. L’opération de contrôle du flux de données peut correspondre à un traitement spécifique associé à la tranche de réseau associée au processus. Ainsi, une sous-tranche de réseau peut présenter des paramètres de contrôle spécifiques, propres à un processus, au sein d’une tranche de réseau ayant des paramètres de contrôle génériques indépendants des données des processus acheminées dans cette tranche. Cette configuration est directement applicable au cadre d’une offre de gros où l’opérateur, souscrivant à cette offre de gros, met en œuvre des sous-tranches de réseau.
Selon un autre aspect de l’invention, le procédé de contrôle comprend en outre une reconfiguration d’au moins un paramètre suite à l’exécution de l’opération de contrôle du flux de données.
Le procédé permet de pouvoir reconfigurer un paramètre de contrôle suite à l’exécution du contrôle et ainsi de pouvoir adapter le contrôle en fonction notamment de premiers résultats obtenus une fois l’opération de contrôle initialisée. Ainsi, en fonction des résultats obtenus, il pourra être utile de contrôler d’autres paramètres du flux ou de modifier le paramètre contrôlé initialement, et ainsi améliorer, approfondir ou diversifier l’opération de contrôle effectuée.
Les différents aspects du procédé de contrôle 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 contrôle d’un flux de données associées à un processus et acheminées dans un chemin partagé de données, comprenant une pluralité de flux d’un réseau de communication, mis en œuvre dans un dispositif dudit chemin et comprenant un récepteur, apte à recevoir en provenance d’une entité de supervision une information d’identification du flux à contrôler, un module de configuration apte à configurer un paramètre de contrôle du flux, ledit paramètre étant relatif au processus correspondant à l’information reçue, un contrôleur, apte à exécuter une opération de contrôle du flux de données en fonction du paramètre configuré. Ce dispositif, apte à mettre en œuvre dans tous ses modes de réalisation le procédé de contrôle qui vient d'être décrit, est destiné à être mis en œuvre dans une entité de d’une infrastructure de communications, dans une infrastructure virtualisée ou dans une infrastructure basée sur des équipements physiques. Par exemple, le dispositif peut être mis en œuvre dans une entité de type équipement réseau tel que routeur ou serveur applicatif.
L’invention concerne aussi un système de de contrôle d’un flux de données associées à un processus et acheminées dans un chemin partagé de données comprenant une pluralité de flux, d’un réseau de communication, le système comprenant :
- un dispositif de contrôle,
- une entité de supervision apte à émettre à destination du dispositif de contrôle une information d’identification du flux à contrôler.
L'invention concerne aussi un programme d'ordinateur comprenant des instructions pour la mise en œuvre des étapes du procédé de contrôle 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 contrôle sur lequel est enregistré le programme 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 :
[Fig 1] présente une vue simplifiée d’un environnement dans lequel est mise en œuvre l’invention selon un aspect de l’invention.
[Fig 2] présente une architecture logique d’un environnement dans lequel est mise en œuvre l’invention selon un autre aspect de l’invention.
[Fig 3] présente une architecture d’un réseau de communication dans lequel est mise en œuvre l’invention selon un premier mode de réalisation de l’invention.
[Fig 4] présente une architecture d’un réseau de communication dans lequel est mise en œuvre l’invention selon encore un deuxième mode de réalisation de l’invention, [Fig 5] présente une architecture d’un réseau de communication dans lequel est mise en œuvre l’invention selon encore un troisième mode de réalisation de l’invention. [Fig 6] présente un aperçu du procédé de contrôle selon un quatrième mode de réalisation de l’invention.
[Fig 7] présente un aperçu du procédé de contrôle selon un cinquième mode de réalisation de l'invention.
[Fig 8] présente un exemple de structure d’un dispositif de contrôle selon un aspect 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 un réseau de communication. Ce réseau peut être mis en œuvre dans une infrastructure fixe ou mobile et l’invention peut être destinée à assurer un contrôle de processus industriel, de processus de livraison de service ou tout autre processus lié à la fourniture d’une prestation à destination d’un client ou pour les propres besoins de l’entreprise le déployant.
On se réfère tout d’abord à la [Fig 1] qui présente une vue simplifiée d’un environnement dans lequel est mise en œuvre l’invention selon un aspect de l’invention. Dans cet environnement une entreprise Indus produit un bien industriel à partir d’un processus requérant la contribution d’une pluralité d’acteurs. Le processus, aussi appelé processus métier, se définit comme un ensemble de tâches effectuées par les différents acteurs, le contrôle de la réalisation du processus conduisant à la production du bien industriel s’appuyant sur la supervision de chacune des tâches du processus. Les différents acteurs n’ont cependant pas forcément connaissance du bien industriel et, selon la technique antérieure, transmettent des données de supervision propres à leur environnement et non pas propres au suivi du processus de réalisation du bien industriel produit par Indus. Selon un aspect de l’invention, l’entreprise Indus interagit avec un intégrateur Integ chargé du suivi, de l’articulation des différentes tâches du processus et de l’avancement des tâches permettant la réalisation du bien. Dans certains cas, l’entreprise Indus joue également le rôle de l’intégrateur. La réalisation du processus requiert en outre la contribution d’au moins un fournisseur d’équipement industriel Equipt en charge de la mise en œuvre d’équipements permettant la fabrication du bien industriel. Au moins un fournisseur d’applications métiers App intervient également dans le processus. Ces applications peuvent correspondre par exemple à des serveurs en charge de l’analyse des données de fonctionnement des équipements industriels. Au moins un fournisseur d’infrastructure Infra, par exemple de type Cloud, est également susceptible d’intervenir notamment pour stocker des applications et des données relatives au processus. Le déroulement du processus requiert en outre au moins un fournisseur de connectivité Connect assurant la transmission des différentes données relatives aux étapes du processus entre les différents acteurs intervenant dans le processus. Comme les autres acteurs, selon la technique antérieure, le fournisseur de connectivité assure une supervision du service de connectivité indépendamment du processus pour lequel il transmet des données. Le fournisseur de connectivité Connect s’assure par exemple que les données qu’il achemine ne subissent pas de pertes de paquets, que les classes de qualité de service sont bien respectées pour les différents flux de données acheminés, que les données pour un client donné sont bien comptées et facturées le cas échéant, que les engagements en termes de sécurité pour un client sont bien respectés mais le fournisseur de connectivité Connect, selon l’art antérieur, ne conduit pas de contrôle des données propres au processus de fabrication du produit. Dans l’environnement de la figure 1, selon un aspect de l’invention, le fournisseur de connectivité Connect contrôle les flux de données propres au processus de fabrication en fonction d’une demande émise par un dispositif de supervision de l’acteur Indus voire de l’acteur Integ selon les cas. Selon d’autres exemples, un dispositif de supervision des acteurs Equipt, App, Infra peut également transmettre une demande de contrôle à un équipement de l’acteur Connect par exemple pour corréler les informations de contrôle de l’entité Connect avec leur propre contrôle de données du processus de fabrication. Il est à noter que les entités Equipt, App, Infra voire Integ disposent également de réseaux de communications et peuvent mettre en œuvre le procédé de contrôle selon l’invention comme l’acteur Connect.
En relation avec la [Fig 2], on présente une architecture logique d’un environnement dans lequel est mise en œuvre l’invention selon un autre aspect de l’invention.
Les différents acteurs intervenant dans le processus tels que décrits dans la [Fig 1] interviennent également dans le processus de la [Fig 2]. Les acteurs Indus, Integ, Equipt, Infra, Connect et App sont ainsi représentés. Il est à noter qu’une même structure peut tenir le rôle d’un ou plusieurs acteurs. Par exemple, une même structure ou entreprise peut intervenir en tant qu’ Integ et Connect par exemple. Chaque acteur dispose d’au moins une entité de supervision. Ainsi, l’acteur Integ administre une entité de supervision Integ Super, l’acteur Equipt gère l’entité de supervision Eq Sup, et de façon correspondante les acteurs Infra, Connect et App administrent respectivement les entités Infra Sup, Connect Sup et App Sup. Les entités de supervision des différents acteurs contrôlent le fonctionnement des dispositifs propres à l’acteur. Ainsi l’entité Eq sup contrôle le fonctionnement d’un équipement industriel EL Bien entendu, les entités de supervision sont aptes à contrôler chacun plus d’un dispositif, la [Fig 2] n’en représentant qu’un pour chaque entité de supervision. Les entités Infra Sup, Connect Sup et App Sup contrôlent respectivement le fonctionnement des dispositifs Eqt Infra, (Eq Res 1 et Eq Res 2), et l’équipement applicatif EA. Il est à noter que l’entité Connect Sup contrôle le fonctionnement des équipements Eq Res 1 et Eq Res 2, le dispositif Eq Res 1 intervenant dans le plan de contrôle Contrl et le dispositif Eq Res 2 intervenant dans le plan de transfert Transf du réseau de communication géré par l’acteur Connect. Chaque entité de supervision est en outre connectée à une base de données (BdDl, BdD2, BdD3 et BdD4) pour stocker les données issues du contrôle opéré sur les équipements respectifs par les entités de supervision. L’acteur Integ dispose d’une base de données BdDi intégrant les différentes données issues des contrôles opérés par les acteurs Equipt, Infra, Connect, App. Dans cette architecture logique, une entité de supervision est susceptible de solliciter les dispositifs du réseau de communication intervenant dans la mise en œuvre du processus et transmet une information d’identification d’un processus à contrôler. Les dispositifs sollicités configurent un ou plusieurs paramètres de contrôle relatif au processus identifié et exécutent les opérations de contrôle en fonction des paramètres configurés. Ainsi, par exemple, les équipements réseau Eq Res 1 et Eq Res 2 reçoivent des identifiants de flux à contrôler, configurent des paramètres de contrôle pour contrôler les flux de données d’un processus, et exécutent le contrôle. Le dispositif Eq Resl effectue ainsi un contrôle de données propres à un processus dans le plan de contrôle Control et le dispositif Eq Res 2 effectue un contrôle des données acheminées dans le plan de transfert Transf du réseau de Connect pour le processus identifié par l’information transmise précédemment par l’entité Connect Sup. Il est à noter qu’une entité de supervision d’un acteur peut transmettre l’information d’identification du processus à des dispositifs d’autres acteurs intervenant dans le processus. L’entité Integ Sup peut ainsi transmettre directement ou indirectement un identifiant de processus aux dispositifs Eq Res 1 et Eq Res 2 pour que ceux-ci effectuent un contrôle du processus identifié par l’identifiant transmis. Sachant que les flux de données transitent dans un même chemin de données, que ce chemin de données peut être une tranche de réseau, un réseau privé virtuel, une liaison louée ou tout autre technique permettant d’agréger ou de multiplexer des données relatives à des clients ou des processus différents, l’identifiant de processus permet de pouvoir assurer un contrôle des seules données propres au processus. Cela permet de pouvoir les exploiter directement ou de pouvoir les agréger plus facilement pour les transmettre par exemple à l’acteur Indus, chaque acteur intervenant dans le processus mettant en œuvre possiblement le même procédé de contrôle.
En relation avec la [Fig 3], on présente une architecture d’un réseau de communication dans lequel est mise en œuvre l’invention selon un premier mode de réalisation de l’invention. Dans ce mode de réalisation, trois processus métiers PMI, PM2, PM3 de l’industrie sont contrôlés. A titre d’exemple, les trois processus sont respectivement un processus PMI de commande d’un produit, un processus PM2 de fabrication d’un produit et un processus PM3 de transport du produit fabriqué au sein d’une usine. Ces trois processus PMI, PM2, PM3 requièrent des échanges de données entre différents équipements, différentes équipes et différentes applications métier. Ainsi le processus PMI requiert des échanges de données entre un équipement industriel Eli de prise de commande et une application métier AMI de gestion des commandes, cet équipement Eli et cette application métier AMI échangeant un flux de données Flux 21 sur une tranche de réseau S2 du plan de transfert Transf d’un réseau de communication. Les flux de données Flux 22 et Flux 23 respectivement échangés entre les équipements Eli et EI2 et l’application métier AM2 sur la tranche de réseau S2 du plan de transfert Transf du réseau de communication, et les flux de données Flux 11 et Flux 12 transmis par les équipements Eli et EI2 sur une tranche de réseau SI du plan de contrôle Contrl du réseau de communication sont propres au processus métier PM2. Les flux de données Flux 31 et Flux 32 transmis par les équipements Eli et E12 sur une tranche S3 du plan de transfert Transf du réseau de communication à destination de l’applicatif métier AM3 sont relatifs au processus métier PM3. Des flux de données peuvent indifféremment être échangés entre des applicatifs métiers ou des équipements physiques ou virtualisés. Dans ce mode de réalisation, le plan de transfert Transf comprend 2 tranches de réseau S2 et S3 établies entre les dispositifs réseau ET1 et ET2 alors que le plan de contrôle Contrl comprend une tranche de réseau S 1 mise en œuvre à partir des dispositifs EC1 et EC2. Les flux de données transmis dans ces tranches de réseau sont propres à des processus distincts et il convient donc de mettre en place le procédé de contrôle pour assurer le contrôle des flux de données associés aux processus respectifs. Par exemple, la configuration d’un paramètre de contrôle d’un flux de données, tel qu’un champ de qualité de service du flux, un nombre de paquets transmis pour un flux ou une durée du contrôle effectué est mise en œuvre à partir d’une information d’identification du flux à contrôler. Cette information, transmise par une entité de supervision non représentée sur la [Fig. 3], correspond au numéro du flux, par exemple Flux 11, Flux 12..., ou bien encore à des attributs d’entrée (Eli, E12, E21, E22, E23, E31, E32) et/ou de sortie (Sll, S12, S21, S22, S23, S31, S32) des flux de données. Ainsi, le flux de données Flux 11 peut être identifié par Flux 11, Ell-Sll ou bien encore par ces identifiants auxquels est ajouté un identifiant de tranche (Flux 11, SI), (Flux 11, Ell-Sll, SI) suivant que le flux de données soit montant (d’un terminal vers un serveur) ou descendant (d’un serveur vers un terminal) au sein de l’infrastructure de connectivité Connect. Un identifiant d’un équipement acheminant les données du flux (EC1, EC2...) et le type de plan (Contrôle, Transfert) peut en outre être utilisé pour identifier le flux ou être ajouté aux paramètres définis précédemment. L’identifiant du Flux 11 pourra par exemple comprendre une donnée parmi les données suivantes en plus de l’identifiant Flux 11 ( Eli, E12, SI, Contrl, EC1, EC2). Un identifiant de l’entité de supervision (comme par exemple Integ Sup ou Connect Sup suivant la [Fig.2]) transmettant l’information sur l’identifiant du flux à contrôler peut en outre être ajouté à l’identifiant de Flux (Flux 11) à des fins d’identification. Dans ce mode de réalisation, le chemin partagé de données est une tranche de réseau.
En relation avec la [Fig 4], on présente une architecture d’un réseau de communication dans lequel est mise en œuvre l’invention selon un deuxième mode de réalisation de l’invention. Ce mode de réalisation est relatif à un processus d’un service bancaire requérant une forte disponibilité. Le réseau de communication est composé d’un réseau de communication mobile RM et d’un réseau de communication de type optique RO, les deux réseaux étant destinés à assurer une haute disponibilité du service bancaire. Chaque réseau RM et RO dispose d’un plan de contrôle, nommé respectivement Contrl RM et Contrl RO, et d’un plan de transfert, Transf RM et Transf RO. Les flux de données propres au service bancaire, transportés depuis l’équipement bancaire EB1 jusqu’à l’application métier AMI, empruntent différents chemins de données, chaque chemin étant un chemin partagé. Le flux de contrôle Flux 11 est acheminé dans le chemin partagé entre les dispositifs EC1 et EC2 et correspondant à une tranche de réseau SI du réseau de contrôle Contrl RM du réseau mobile RM, le flux de données de transfert Flux 21 est acheminé dans une tranche de réseau S2, entre les dispositifs ET1 et ET2, du réseau de transfert Transf RM du réseau mobile RM. Les flux Flux 31 et Flux 41 de données de contrôle et de transfert du réseau optique RO sont respectivement acheminés dans le VPN3 (en anglais Virtual Private Network) construit entre les dispositifs réseau EC3 et EC4, et VPN4 construit entre les dispositifs ET3 et ET4 du réseau optique RO. Les flux d’un même processus peuvent être acheminés dans des chemins partagés distincts ou communs. Dans la [Fig 4] différents flux de données Flux 11, Flux 21, Flux 31, Flux 41 sont acheminés dans des chemins partagés distincts de types différents puisque ce sont des tranches de réseau pour le Flux 11 et le Flux 21 alors que ce sont des VPNs pour le Flux 31 et le Flux 41. Les différents flux peuvent être identifiés conformément aux possibilités précisées dans la description de la [Fig 3]. Sur la [Fig 4], un seul processus est représenté mais les chemins de données partagés (SI, S2, VPN3 et VPN4) peuvent chacun comprendre une pluralité de flux d’un même processus et/ou de processus distincts. Pour chaque flux (Flux 11, Flux 21, Flux 31, Flux 41) du processus, un paramètre de contrôle est configuré. Il peut s’agir d’une donnée d’un flux à contrôler, par exemple permettant de compter les paquets du flux, une période pendant laquelle le contrôle du flux est exécuté. Le contrôle peut ainsi être mené pendant une période limitée pour résoudre un problème spécifique.
Le paramètre de contrôle peut comprendre une fréquence de l’opération de contrôle lorsqu’il s’agit par exemple de prélever plusieurs fois un indicateur dans une période de temps. Il peut également s’agir d’un mode de calcul des données de contrôle, par exemple le recueil de valeurs instantanées ou des valeurs moyennes. Le paramètre de contrôle peut comprendre également une donnée de synchronisation, telle qu’une horloge, permettant par exemple de synchroniser les informations de contrôle reçues de flux distincts d’un procédé comme cela est le cas pour les Flux Flux 11, Flux 21, Flux 31 et Flux 41 et de pouvoir interpréter les différentes données de contrôle obtenues à un instant donné lors de l’exécution du contrôle sur les différents flux du processus.
En lien avec la [Fig 5], on présente une architecture d’un réseau de communication dans lequel est mise en œuvre l’invention selon un troisième mode de réalisation de l’invention.
Ce mode de réalisation s’inscrit dans le cadre d’une offre de gros, par exemple de type Wholesale, d’un opérateur de réseau de communication à un prestataire déployant des processus pour ses besoins et/ou offrant lui-même des services à des clients, susceptibles d’être générés par des processus, sur la base de l’offre de gros contractée auprès de l’opérateur.
L’opérateur de réseau achemine les données de transfert du prestataire dans une tranche WHS2, comprenant les dispositifs ET1 et ET2, du plan de transfert Transf. Les données de contrôle du prestataire sont acheminées dans une tranche WHS 1 du plan de contrôle Contrl du réseau de communication, comprenant les dispositifs EC1 et EC2. Les dispositifs ET1, ET2, EC1 et EC2 contribuent à la mise en œuvre d’au moins une tranche de réseau et un nombre supérieur à deux dispositifs peut être envisagé pour une tranche de réseau donnée. Un deuxième prestataire contractant une offre de gros auprès du même opérateur verrait ses données acheminées dans deux tranches, non représentées sur la [Lig 5], distinctes des tranches WHS1 et WHS2. Le prestataire met en œuvre 3 processus à partir d’un même équipement industriel Eli, chacun des processus générant des flux de données vers les applications métiers respectives AMI, AM2, AM3. Chaque flux de données est acheminé dans le plan de transfert Transf dans une tranche de réseau de la tranche WHS2. Ainsi, le Llux 21 de données du processus PMI échangées entre l’équipement Eli et l’application métier AMI est acheminé sur une tranche de réseau S21 de la tranche de réseau WHS2. De façon identique, le Flux 22 et le Flux 23 de données sont acheminés sur les tranches S22 et S23 de la tranche WHS2. Le Flux 11 du plan de contrôle Contrl du processus PM2 est acheminé sur la tranche WHS1. Dans ce mode de réalisation, les flux de données sont associés à des tranches de réseau, elles-mêmes comprises dans une tranche de réseau, formant une hiérarchie de tranches de réseau. Les flux de données d’un processus sont en effet associés à des tranches de réseau établies au sein de tranche de réseau formant un chemin de données partagé. Selon les processus et le nombre d’acteurs intervenant dans la mise en œuvre dans ces processus, un nombre supérieur à deux niveaux de tranches de réseau peut être envisagé. Cette hiérarchie peut être mise en œuvre à partir d’autres techniques de partage, telles que les VPNs ou des liaisons louées et il est également possible d’envisager une architecture mixte comprenant une hiérarchie de chemins de données partagés basés sur des technologies différentes (tranche de réseau dans un VPN par exemple).
En relation avec la [Fig 6], on présente un aperçu du procédé de contrôle selon un quatrième mode de réalisation de l’invention mis en œuvre dans un réseau 10 de communicaion.
Lors d’une étape 300, un client 100 par exemple de type industriel requiert auprès d’un dispositif 101 de gestion des processus le contrôle d’un processus métier faisant intervenir différents équipements, voire différents acteurs et générant des échanges de données entre des équipements industriels et/ou des applications informatiques. Cette sollicitation du dispositif 101 de gestion est facultative et le client 100 peut solliciter directement le dispositif 102 de supervision s’il connaît le dispositif 102 en charge du contrôle du processus.
Lors d’une étape 301, le dispositif 101 de gestion identifie le dispositif de supervision à contacter pour qu’un contrôle du processus soit effectué. Cette identification est par exemple effectuée à partir d’un identifiant du processus, et/ou d’une description du processus, et/ou d’une table d’association des processus et des dispositifs de supervision. Lors d’une étape 302, l’entité 101 de gestion émet à destination de l’entité 102 de supervision identifiée lors de l’étape 301, une requête pour effectuer un contrôle des données relatives au flux du processus à contrôler. Dans le cas où plusieurs acteurs interviennent dans le processus, l’entité 101 peut identifier et solliciter plusieurs entités de supervision. Les échanges entre l’entité 101 et l’entité 102 peuvent être réalisés par un protocole de type HTTP (en anglais HyperText Transfer Protocol) ou SNMP (en anglais Simple Network Management Protocol) ou bien encore par un protocole spécifique. Lors de l’étape 302, l’entité 101 peut également indiquer à l’entité 102 la fréquence de collecte de données de données de contrôle, le taux de disponibilité des dispositifs de l’infrastructure de connectivité ou des applications propres au processus, ainsi que d’autres informations propres à déterminer le type de contrôle et les paramètres de ce contrôle. Lors d’une étape 303, l’entité de supervision 102 détermine les dispositifs à solliciter pour exécuter un contrôle des données du processus conformément à la requête reçue de l’entité 101 de gestion ou du client 100. Pour déterminer les équipements, l’entité 102 de supervision peut utiliser une table associant les processus avec les flux de données. Par exemple, l’entité 102 maintient une table associant les processus avec les identifiants de tranche de réseau et possiblement avec des identifiants de chemins partagés, tel qu’un identifiant de tranche de réseau, de VPN. L’entité 102 peut également détenir une table associant les processus et les dispositifs acheminant les données des processus et elle peut également associer un type de processus (IoT (en anglais « Internet Of Things »), Streaming, Best Effort...) avec des identifiants de dispositifs impliqués dans le transport de données de ces types de processus. Par exemple, lorsqu’un nouveau processus est mis en œuvre par un client, celui-ci indique à l’opérateur en charge du dispositif 102 de supervision, les types de flux générés par le processus et leurs caractéristiques (qualité de service, débit, criticité, localisation des équipements et applications générant les données du flux...) et l’opérateur en charge de l’acheminement des données affecte un ou plusieurs chemins de données dans lequel (ou lesquels) seront acheminées les données des flux du processus en fonction des caractéristiques de ces flux. A partir de cette identification du (ou des) chemins, l’opérateur identifie les dispositifs du (ou des) chemins intervenant dans l’acheminement des données du (ou des) flux. L’information d’identification du flux de données à contrôler comprend un identifiant de processus générant les données du flux, et optionnellement au moins un identifiant parmi :
- un identifiant du chemin de données partagé, tel que l’identifiant de tranche de réseau ou de VPN,
- un identifiant du dispositif effectuant le contrôle, tel que l’identifiant 105 ou 106,
- un identifiant de l’entité de supervision tel que l’identifiant 102 de l’entité de supervision. Lors de l’étape 304, l’entité 102 de supervision transmet aux dispositifs 105 et 106 identifiés lors de l’étape 303 une information d’identification d’un flux à contrôler. L’information d’identification comprend les identifiants décrits précédemment.
Selon une alternative, l’entité 102 de supervision transmet en outre aux dispositifs 105 et 106 des paramètres de contrôle du flux. Ces paramètres ont pour objet de qualifier le contrôle et de définir quels sont les paramètres du flux à configurer par les équipements 105 et 106 pour effectuer le contrôle. Les paramètres de contrôle du flux transmis aux dispositifs 105 et 106 peuvent être différents selon le rôle tenu par le dispositif dans l’acheminement des données. Par exemple, si le dispositif 105 intervient dans l’acheminement des flux de contrôle et le dispositif 106 intervient dans l’acheminement des données de transfert, les paramètres de contrôle pourront être différents. Les paramètres de contrôle tels que décrits dans la [Fig 3] peuvent ainsi être transmis, selon un exemple, par l’entité 102 de supervision aux dispositifs 105 et 106 lors de l’étape 304.
Lors de l’étape 305, les dispositifs 105 et 106 configurent un ou plusieurs paramètres de contrôle du flux de données généré par le processus à contrôler. Le paramètre de contrôle à configurer peut avoir été transmis par l’entité 102 de supervision lors de l’étape 304 ou bien il peut s’agir de paramètres de configuration déterminés par les dispositifs 105 et 106 en fonction notamment des données du processus à contrôler. Par exemple, à partir des identifiants du flux à contrôler, les dispositifs 105 et 106 peuvent déterminer les paramètres de contrôle à configurer. S’il s’agit de flux critiques d’un processus, les dispositifs pourront par exemple configurer un calcul du taux de perte de paquets. S’il s’agit de flux de données temps réel, les dispositifs pourront configurer un suivi régulier des paramètres de qualité de service des paquets. S’il s’agit de processus confidentiels, les dispositifs pourront configurer un contrôle des paramètres d’intégrité des paquets du flux de données. Dans le cas de flux de données chiffrés, un dispositif de type applicatif pourra accéder aux données alors qu’un routeur du réseau de communications ne disposera pas nécessairement des clés pour déchiffrer le flux de données chiffré. Les dispositifs 105 et 106 peuvent donc configurer des paramètres de contrôle distincts mais toutefois, il peut être nécessaire de synchroniser ces contrôles en configurant par exemple une horloge commune identifiant le moment où les contrôles doivent être effectués par les deux dispositifs 105 et 106.
Lors de l’étape 306, les dispositifs 105 et 106 exécutent le contrôle du flux de données conformément au paramètre de contrôle configuré lors de l’étape 305. Dans le cas où un processus comprend plusieurs flux de données, chaque flux peut être contrôlé avec des paramètres de contrôle spécifiques au flux du processus. Les paramètres de contrôle, selon un exemple, sont donc spécifiques au flux de données et/ou au dispositif en charge du contrôle du flux en plus d’être spécifique au processus.
Selon un exemple, l’opération de contrôle exécutée lors de l’étape 306 comprend une opération de corrélation d’un contrôle effectué sur un deuxième flux avec un résultat issu du contrôle sur le flux à contrôler. Par exemple, le dispositif 105 peut acheminer des données issues d’une pluralité de flux d’un même processus ou de processus distincts. La transmission des données d’un flux peut influer sur la transmission des données d’un autre flux ou un problème détecté sur deux flux distincts peut permettre d’identifier un problème sur le dispositif 105 par exemple. Notamment, si tous les flux de données acheminés par le dispositif 105 subissent une dégradation de qualité de service ou une perte de paquets, alors cela peut indiquer un problème du dispositif 105. La possibilité de corréler, de comparer ou d’agréger des résultats de contrôle permet d’identifier plus facilement un problème.
Selon une alternative, lors de l’étape 307, le dispositif 106 du chemin de données transmet au dispositif 105 un message comprenant une information prise en compte par le dispositif 106 pour configurer un paramètre de contrôle. Cette condition peut correspondre à un résultat d’un contrôle que le dispositif 106 a effectué sur le flux de données lors d’un contrôle précédent ou au cours du contrôle effectué. Par exemple, si le dispositif 106 détecte une perte de paquets, il peut indiquer cette information pour que le dispositif 105 configure le paramètre de contrôle de perte de paquets également. Il peut également s’agir d’une donnée de synchronisation pour que les contrôles par les dispositifs 105 et 106 soient effectués aux mêmes moments. Selon un exemple, cette information est transmise par l’entité 106 via l’entité de supervision 102 pour répondre à la situation où les dispositifs du chemin de données ne se connaissent pas ou ne peuvent échanger des données directement.
Selon une autre alternative, lors de l’étape 308, le dispositif 105 reconfigure un ou plusieurs paramètres de contrôle du flux de donnés. Cette reconfiguration, selon un exemple, est consécutive à l’information reçue lors de l’étape 307 et/ou elle résulte de l’opération de contrôle effectuée de façon autonome par le dispositif 105. Ainsi, si le dispositif 105 détecte une variation anormale d’un paramètre de qualité de service, elle peut reconfigurer des paramètres de contrôle par exemple pour contrôler d’autres champs du protocole utilisé pour transmettre les données du flux du processus.
Selon une autre alternative, les dispositifs 105 et 106 transmettent lors d’une étape 309 un résultat du contrôle exécuté sur le flux de données conformément aux paramètres de contrôle configurés. Ce résultat peut permettre à l’entité 102 de supervision de déterminer un nouveau contrôle à opérer sur le même flux de données ou sur un flux distinct du processus et également à informer l’entité de gestion 101 et possiblement le client 100 des résultats de contrôle obtenus. Dans le cas d’un contrôle périodique, l’entité 102 de supervision peut sauvegarder les résultats obtenus pour évaluer l’évolution de l’acheminement des données du flux d’un processus dans un chemin partagé du réseau de communication.
En relation avec la [Fig 7], on présente un aperçu du procédé de contrôle selon un cinquième mode de réalisation de l'invention dans un réseau 10 de communication. L’architecture du réseau de communication dans laquelle est mis en œuvre ce mode de réalisation est celle présentée dans la [Fig 3].
Deux équipements industriels El 1 et El 2 sont connectés au plan de contrôle et au plan de transfert d'un réseau de communication mobile.
Le plan de contrôle est constitué de 2 équipements réseau EC1 et EC2 ; le plan de transfert est composé de 2 équipements de réseau ET1 et ET2.
Les plans de transfert Tranf et de contrôle Contrl sont interfacés pour permettre notamment la configuration du plan de transfert par le plan de contrôle. Cette interface « Interface_CT» correspond typiquement à l'interface N4 du 3GPP pour l'architecture « Service-based Architecture» du cœur de réseau 5GC (en anglais « 5G Core »). Il y a création de flux de données suivant la nature d’un processus métier (associé à l'applicatif métier). Il y a donc des flux qui sont relatifs au plan de contrôle et des flux relatifs au plan de transfert. Typiquement, pour la supervision des évènements relatifs à l'attachement d'un équipement industriel au réseau ou à sa mobilité, il y aura création d'au moins un flux au niveau du plan de contrôle. Ainsi, les flux (du plan de transfert et du plan de contrôle) sont déterminés à partir de la nature du processus métier (associé à l'applicatif métier) et en considérant l'équipement industriel impliqué dans ce processus métier. Pour chaque flux (du plan de transfert et du plan de contrôle), il y a alors un attribut d'entrée unique et un attribut de sortie unique.
Selon cet exemple, comme présenté dans la [Fig 3],
- pour le plan de contrôle : pour chaque équipement industriel qui initie une communication avec le plan de contrôle, il y a création d'au moins un flux auquel sont associés un attribut d'entrée unique et un attribut de sortie unique au niveau de l'entité de supervision du fournisseur de connectivité. Dans le cas présent, nous faisons les hypothèses que le plan de contrôle : i) est commun pour les équipements industriels (Eli et EI2) de l'outil industriel du client ii) est mis en œuvre via une tranche unique SI. Pour cette tranche SI, il y a création
- du flux Fluxl 1 et des 2 identifiants Eli et SI 1 comme attributs d'entrée et de sortie pour l'équipement industriel Eli,
- du flux Fluxl2 et des 2 identifiants E12 et S 12 comme attributs d'entrée et de sortie pour l'équipement industriel EI2.
Les flux Fluxl 1 et Fluxl2 participent au processus métier PM2 relatif à des échanges de données loT. Les Flux 11 et Flux 12 permettent alors de fournir des informations sur l'état d'attachement au réseau pour les équipements industriels Eli et EI2 durant la supervision du processus métier PM2. Pour le plan de transfert, l'équipement industriel Eli participe à 3 processus métiers PMI, PM2 et PM3. La connectivité au plan de transfert se fait via 2 tranches du réseau de communications (ou « slices » en anglais) S2 et S3 pour différencier la nature des données transférées via le réseau de communication mobile. La tranche S2 est utilisée pour les échanges de données loT entre les équipements industriels et les applications métiers AMI, AM2, AM3. La tranche S3 est utilisée pour la gestion des mises à jour des logiciels de chaque équipement industriel. Typiquement, la tranche S3 demandera plus de bande passante que la tranche S2, la tranche S2 aura un trafic plus continu que la tranche de réseau S3. Les flux du plan de transfert sont déterminés à partir de la nature du processus métier (associé à l'applicatif métier) et en considérant l'équipement industriel impliqué dans ce processus métier. Pour chaque flux du plan de transfert, il y a alors un attribut d'entrée unique et un attribut de sortie unique.
Bien que les processus métiers PMI et PM2 puissent avoir des exigences similaires vis-à-vis des propriétés du plan de transfert (volumétrie de trafic, niveau de rapidité de la connectivité ou latence, niveau de disponibilité de la connectivité...), leur différenciation, via la mise en œuvre de flux différents, permet une configuration différente des paramètres de contrôle qui devront être remontés par le dispositif réseau pour chaque processus métier.
Dans ce mode de réalisation il est considéré que le processus métier loT PMI de l'application métier AMI est plus critique que le processus métier loT PM2 de l'application métier AM2. Dans ce cas, les équipements réseaux ET1 et ET2 seront configurés de manière à ce que:
- les métriques de performance du Flux 21 (comme le nombre de paquets transférés via la tranche S2 soient transmises toutes les 10 minutes vers l'entité de supervision (non représentée sur la [Fig 3] et pouvant être l’entité Connect Sup décrite dans la [Fig 2]),
- les métriques de performance des flux 22 et 23 (comme le nombre de paquets transférés via la tranche S2 soient transmises toutes les 30 minutes vers l'entité de supervision. Ainsi, le paramètre de contrôle configuré est la fréquence des remontées des métriques de performance et sera déterminé en fonction des besoins du processus métier à superviser.
Les paramètres de contrôle associés aux différents flux des processus métiers dont la nature des interfaces utilisées pour l’exécution des opérations de contrôle sont présentés en lien avec les étapes de la [Fig 7]. Seules les étapes sollicitant l'entité de supervision ou un dispositif du réseau de communication en charge de l’exécution du contrôle sont détaillées à l'exception de l'étape initiale 300.
Etape 300 : L’entité cliente 100 transmet à une entité 101 de gestion la liste des processus métiers à superviser et la performance globale attendue pour chaque processus métier. Les données suivantes sont ainsi transmises :
{Processus Métier: PMI ; volume de paquets à transférer : 2 Mbits/heure ; fréquence de remontée des métriques de performances vers l'outil de supervision: 10 minutes} {Processus Métier: PM2 ; volume de paquets à transférer: 2 Mbits/heure ; fréquence de suivi des performances: 30 minutes}
{Processus Métier: PM3 ; taux de perte de paquets: 0% ; fréquence de suivi des performances: à la fin de chaque transfert complet}
Etape 302 : envoi, vers l’entité 102 de supervision, des identifiants des dispositifs en charge du contrôle, de la liste des équipements industriels et de la performance attendue par processus métier. Envoi des données suivantes :
{Processus Métier : PMI ; Equipement industriel : Eli ; volume de paquets à transférer : 2 Mbits/heure ; fréquence de suivi des performances: 10 minutes} {Processus Métier: PM2 ; Equipement industriel: Eli, EI2 ; volume de paquets à transférer: 2 Mbits/heure ; fréquence de suivi des performances: 30 minutes} {Processus Métier: PM3 ; Equipement industriel: Eli, EI2 ; taux de perte de paquets : 0% ; fréquence de suivi des performances: à la fin de chaque transfert complet} Etape 304 : envoi aux dispositifs 105 représentant ET1 et 106 représentant ET2 des informations d’identification des flux à contrôler et des paramètres de contrôle relatifs aux métriques de performances qui devront être exécutés puis transmis par le dispositif pour chaque flux.
A cette étape, le gestionnaire envoie les paramètres de contrôle pour les métriques de performances attendues à chaque dispositif du réseau de communication intervenant dans la transmission de données du flux à contrôler dont il a la supervision.
Pour le plan de contrôle, il y a transmission des identifiants de flux Flux 11 et Flux 12 et de paramètres de contrôle aux équipements EC1 et EC2 pour la gestion des flux Fluxl 1 et Fluxl2. Les dispositifs EC1 et EC2 ne sont pas représentés sur la [Fig 7]. Pour le plan de transfert, il y a transmission des identifiants de flux et de paramètres de contrôle aux équipements 105 ET1 et 106 ET2 pour la gestion des flux Flux21, Flux22, Flux23, Flux31 et Flux32.
Les 3 exemples suivants portent sur les flux Flux21, Flux22 et Flux23 pour le dispositif 105 ET1 du réseau de transfert Transf. Les données identiques sont transmises au dispositif 106. Il est à noter que l'on propose d'utiliser : i) l'interface de streaming pour superviser les flux demandant une remontée fréquente des métriques de performance par le dispositif réseau concerné et ii) l'interface de transfert de fichiers dans le cas contraire à savoir pour superviser les flux ne nécessitant pas une remontée fréquente.
Les informations suivantes sont ainsi transmises lors de l’étape 304 au dispositif 105 ET1 : {Equipement Réseau: ET1 ; Flux: Flux21, Attribut d'entrée: E21 ; Attribut de sortie: S21 ; Equipement industriel : Eli ; volume de paquets à transférer: 2 Mbits/heure; fréquence de suivi des performances: 10 minutes; valeur: valeurs instantanées; interface: interface de streaming}
{Equipement Réseau: ET1 ; Flux : Flux22, Attribut d'entrée : E22 ; Attribut de sortie : S22 ; Equipement industriel : Eli ; volume de paquets à transférer: 2 Mbits/heure ; fréquence de suivi des performances : 30 minutes; valeur: valeurs moyennées; interface: transfert de fichiers}
{Equipement Réseau: ET1 ; Flux: Flux23, Attribut d'entrée: E23 ; Attribut de sortie: S23 ; Equipement industriel : EI2 ; volume de paquets à transférer : 2 Mbits/heure ; fréquence de suivi des performances : 30 minutes; valeur: valeurs moyennées; interface: transfert de fichiers}
Dès qu’un équipement industriel El se connecte au réseau de communication et communique avec un des domaines des applicatifs métiers d’un processus métier, alors l’entité de supervision renseigne, notamment en base de données de son domaine technique, les attributs d'entrée et de sortie du flux avec respectivement: l'adresse IP allouée à l'équipement industriel et l'adresse IP utilisée par l'application métier pour communiquer avec cet équipement industriel.
Les étapes 305 à 309 sont analogues aux étapes identiques de la [Fig 6].
Etape 310 : l’entité 102 de supervision détecte un problème sur le flux de données du processus métier PMlet le suivi des performances doit désormais être configuré à 10 secondes (et non plus 10 minutes).
- Etape 311 : notification par l’entité 102 de supervision vers les dispositifs 105 ET1 et 106 ET2 concernés, du processus métier identifié et demandant une supervision coordonnée.
La mise en œuvre du processus métier PMI implique en effet les équipements 105 ET1 et 106 ET2 au niveau du réseau. L’entité 102 de supervision envoie alors les 2 commandes de reconfiguration de paramètres de contrôle pour le flux Flux21 du processus PMlvers respectivement les dispositifs 105 ET1 et 106 ET2 :
{Equipement Réseau: ET1 ; Flux: Flux21, Attribut d'entrée: E21 ; Equipement industriel: Eli ; volume de paquets à transférer: 2 Mbits/heure ; fréquence de suivi des performances: 10 secondes; valeur: valeurs instantanées; interface: interface de streaming}
{Equipement Réseau: ET2 ; Flux : Flux21; Attribut de sortie : S21 ; Equipement industriel: Eli ; volume de paquets à transférer: 2 Mbits/heure ; fréquence de suivi des performances: 10 secondes; valeur: valeurs instantanées; interface: interface de streaming}
Les étapes 312 à 314 correspondent aux étapes 305, 306, 309 décrites ci-dessus avec les paramètres de contrôle modifiés lors de l’étape 310.
En relation avec la [Fig 8], on présente un exemple de structure d’un dispositif de contrôle selon un aspect de l'invention.
Le dispositif 105 de contrôle met en œuvre le procédé de contrôle, dont différents modes de réalisation viennent d'être décrits.
Un tel dispositif 105 peut être mis en œuvre dans une entité de d’une infrastructure de communications, dans une infrastructure virtualisée ou dans une infrastructure basée sur des équipements physiques. Par exemple, le dispositif peut être mis en œuvre dans une entité de type équipement réseau tel que routeur ou serveur applicatif. Par exemple, le dispositif 105 comprend une unité de traitement 430, équipée par exemple d'un microprocesseur mR, 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 en provenance d’une entité de supervision une information d’identification Ident du flux à contrôler, - un module 401 de configuration apte à configurer un paramètre de contrôle du flux, ledit paramètre étant relatif au processus correspondant à l’information reçue, un contrôleur 402, apte à exécuter une opération de contrôle du flux de données en fonction du paramètre configuré.

Claims

REVENDICATIONS
1. Procédé de contrôle d’un flux de données associées à un processus et acheminées dans un chemin partagé de données, comprenant une pluralité de flux, d’un réseau de communication, ledit procédé étant mis en œuvre dans un dispositif dudit chemin et comprenant la réception en provenance d’une entité de supervision d’une information d’identification du flux à contrôler, la configuration d’au moins un paramètre de contrôle du flux, ledit paramètre étant relatif au processus correspondant à l’information reçue, l’exécution d’une opération de contrôle du flux de données en fonction d’au moins un paramètre configuré.
2. Procédé de contrôle, selon la revendication 1, où le chemin partagé de données correspond à une tranche de réseau.
3. Procédé de contrôle, selon la revendication 1, où l’information d’identification du flux comprend un identifiant de processus, et optionnellement au moins un identifiant parmi un identifiant du chemin de données partagé, un identifiant du dispositif, un identifiant de l’entité de supervision.
4. Procédé de contrôle, selon la revendication 1, où G au moins un paramètre de contrôle du flux est obtenu en provenance de l’entité de supervision préalablement à la configuration dudit paramètre par le dispositif.
5. Procédé de contrôle, selon la revendication 1, où G au moins un paramètre de contrôle du flux comprend au moins un paramètre parmi : un champ d’une donnée du flux, une période pendant laquelle le contrôle du flux est exécuté, une fréquence correspondant au nombre d’itérations de l’opération de contrôle par unité de temps, un mode de calcul des données de contrôle, le type d’interface utilisé pour effectuer l’opération de contrôle, une donnée de synchronisation d’opérations de contrôle
6. Procédé de contrôle, selon la revendication 1, comprenant en outre l’émission à destination de l’entité de supervision d’un résultat de l’opération de contrôle exécutée.
7. Procédé de contrôle, selon la revendication 1, comprenant en outre la réception en provenance d’un autre dispositif du chemin de données d’un message comprenant une information prise en compte par le dispositif pour configurer le paramètre de contrôle.
8. Procédé de contrôle, selon la revendication 1, où l’opération de contrôle comprend une opération de corrélation d’un résultat d’un contrôle effectué sur un deuxième flux de données avec un résultat issu du contrôle sur le flux de données.
9. Procédé de contrôle, selon la revendication 8, où le deuxième flux de données est acheminé dans un plan de contrôle du réseau de communication et le flux de données est acheminé dans le plan de transfert du réseau de communication.
10. Procédé de contrôle, selon la revendication 1, où le flux de données est transmis dans une tranche de réseau établie dans le chemin partagé de données.
11. Procédé de contrôle d’un flux de données comprenant en outre une reconfiguration d’au moins un paramètre suite à l’exécution de l’opération de contrôle du flux de données.
12. Dispositif de contrôle d’un flux de données associées à un processus et acheminées dans un chemin partagé de données, comprenant une pluralité de flux d’un réseau de communication, mis en œuvre dans un dispositif dudit chemin et comprenant un récepteur, apte à recevoir en provenance d’une entité de supervision une information d’identification du flux à contrôler, - un module de configuration apte à configurer un paramètre de contrôle du flux, ledit paramètre étant relatif au processus correspondant à l’information reçue, un contrôleur, apte à exécuter une opération de contrôle du flux de données en fonction du paramètre configuré.
13. Système de contrôle d’un flux de données associées à un processus et acheminées dans un chemin partagé de données comprenant une pluralité de flux, d’un réseau de communication, le système comprenant :
- un dispositif de contrôle selon la revendication 12,
- une entité de supervision apte à émettre à destination du dispositif de contrôle une information d’identification du flux à contrôler
14. Programme d'ordinateur comportant des instructions pour la mise en œuvre du procédé de contrôle selon l'une quelconque des revendications 1 à 11, lorsque le programme est exécuté par un processeur.
15. Support d’enregistrement lisible par un dispositif de contrôle conforme à la revendication 12, sur lequel est enregistré le programme selon la revendication 14.
EP20790370.9A 2019-09-30 2020-09-24 Procede de controle d'un flux de donnees associe a un processus au sein d'un reseau mutualise Pending EP4042641A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR1910780A FR3101498A1 (fr) 2019-09-30 2019-09-30 Procédé de contrôle d’un flux de données associé à un processus au sein d’un réseau mutualisé
PCT/FR2020/051663 WO2021064310A1 (fr) 2019-09-30 2020-09-24 Procede de controle d'un flux de donnees associe a un processus au sein d'un reseau mutualise

Publications (1)

Publication Number Publication Date
EP4042641A1 true EP4042641A1 (fr) 2022-08-17

Family

ID=69743304

Family Applications (1)

Application Number Title Priority Date Filing Date
EP20790370.9A Pending EP4042641A1 (fr) 2019-09-30 2020-09-24 Procede de controle d'un flux de donnees associe a un processus au sein d'un reseau mutualise

Country Status (4)

Country Link
US (1) US12101248B2 (fr)
EP (1) EP4042641A1 (fr)
FR (1) FR3101498A1 (fr)
WO (1) WO2021064310A1 (fr)

Family Cites Families (21)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20080298300A1 (en) 2004-10-26 2008-12-04 Alcatel Lucent Communication Control Method and System for Carrying Out Said Method
US9240945B2 (en) * 2008-03-19 2016-01-19 Citrix Systems, Inc. Access, priority and bandwidth management based on application identity
US8670310B2 (en) * 2010-12-21 2014-03-11 Hewlett-Packard Development Company, L.P. Dynamic balancing priority queue assignments for quality-of-service network flows
US8873392B1 (en) * 2011-06-09 2014-10-28 Marvell International Ltd. Method and apparatus for controlling the flow of packets in a data network
WO2016074738A1 (fr) * 2014-11-14 2016-05-19 Huawei Technologies Co., Ltd. Routage de données à l'aide d'un modèle de routage basé sur un apprentissage machine
US10536357B2 (en) * 2015-06-05 2020-01-14 Cisco Technology, Inc. Late data detection in data center
EP3433756A1 (fr) * 2016-02-23 2019-01-30 Level 3 Communications, LLC Contrôle de flux de réseau
US10129894B2 (en) * 2016-03-04 2018-11-13 Huawei Technologies Co., Ltd. Systems and methods for performing traffic engineering through network slices
WO2017204067A1 (fr) * 2016-05-26 2017-11-30 京セラ株式会社 Appareil de réseau
US10802857B2 (en) * 2016-12-22 2020-10-13 Nicira, Inc. Collecting and processing contextual attributes on a host
US10742672B2 (en) * 2017-04-03 2020-08-11 Level 3 Communication, Llc Comparing metrics from different data flows to detect flaws in network data collection for anomaly detection
CN108924884B (zh) * 2017-04-04 2021-02-23 华为技术有限公司 通信方法及通信设备
US10698714B2 (en) * 2017-04-07 2020-06-30 Nicira, Inc. Application/context-based management of virtual networks using customizable workflows
US20190036779A1 (en) * 2017-07-31 2019-01-31 Cisco Technology, Inc. Virtualized software-defined network
FR3074626A1 (fr) 2017-12-01 2019-06-07 Orange Procede d'acheminement de donnees d'une session initialisee entre un terminal et un serveur
EP3725036A1 (fr) * 2017-12-15 2020-10-21 Nokia Technologies Oy Procédé de commande de transmission de données à l'aide de tranches de réseau
US11283721B2 (en) * 2018-06-27 2022-03-22 Nokia Solutions And Networks Oy Application-based traffic control in multipath networks
WO2020124381A1 (fr) * 2018-12-18 2020-06-25 Lenovo (Beijing) Limited Procédé et appareil de surveillance et d'évaluation de qos
US11330648B2 (en) * 2019-02-15 2022-05-10 Ofinno, Llc Charging aggregation control for network slices
US10849025B1 (en) * 2019-05-02 2020-11-24 Verizon Patent And Licensing Inc. Systems and methods for allocating network resources utilizing bearer information
US11736623B2 (en) * 2021-04-14 2023-08-22 Verizon Patent And Licensing Inc. Systems and methods for granular charging in mobile wireless networks

Also Published As

Publication number Publication date
WO2021064310A1 (fr) 2021-04-08
FR3101498A1 (fr) 2021-04-02
US20220345399A1 (en) 2022-10-27
US12101248B2 (en) 2024-09-24

Similar Documents

Publication Publication Date Title
EP2052503B1 (fr) Procede d'optimisation du transfert d'informations dans un reseau de telecommunication
US9712634B2 (en) Orchestrating mobile data networks in a network environment
US11683421B2 (en) Resolving unsatisfactory QoE for an application for 5G networks or hybrid 5G networks
US20230082301A1 (en) MEASURING QoE SATISFACTION IN 5G NETWORKS OR HYBRID 5G NETWORKS
US12082051B2 (en) Determining QoE requirements for 5G networks or hybrid 5G networks
EP3105889B1 (fr) Notification d'une information de consommation de bande passante à un fournisseur de service dans un réseau de télécommunications
WO2021255382A1 (fr) Procédé de configuration d'un dispositif terminal
EP4373059A1 (fr) Infrastructure de communication munie d'un maillage de services étendu ; procédé et produit programme d ordinateur associés
EP2396086B1 (fr) Procédé de communication
EP4042641A1 (fr) Procede de controle d'un flux de donnees associe a un processus au sein d'un reseau mutualise
CN109714193B (zh) 一种基于zuul路由转发方式接管对象存储服务的方法
EP3044909B1 (fr) Procédé de transmission de flux de donnees a travers un reseau de telecommunication
WO2021191535A1 (fr) Procede de delegation entre reseaux informatiques de peripherie a acces multiples
EP1349319B1 (fr) Dispositif de gestion de service réseau utilisant le protocole cops pour la configuration d'un réseau privé virtuel
EP3430777A1 (fr) Procédé de gestion dynamique de chemins de communication entre routeurs en fonction de besoins applicatifs
EP2446360A1 (fr) Technique de determination d'une chaine de fonctions elementaires associee a un service
FR3003115A1 (fr) Procede d'allocation de ressources pour la mise en oeuvre de reseaux virtuels dans un reseau de telecommunication
EP2530877B1 (fr) Système et procédés d'instrumentation
WO2023047068A1 (fr) Procede de controle d'un acces a un service applicatif mis en œuvre dans un reseau de telecommunications, procede de traitement d'un message de controle d'un acces audit service applicatif, dispositifs, equipement de controle, equipement client, systeme et programmes d'ordinateur correspondants
WO2023217639A1 (fr) Procédé, dispositif et système d'élaboration dynamique d'une infrastructure de données
FR2979505A1 (fr) Procede d'insertion d'un equipement intermediaire permettant le controle a distance de la qualite d'une communication
FR3124668A1 (fr) Procédé de contrôle de la livraison partagée d’un contenu
FR3135543A1 (fr) Procédé, dispositif et système de certification d’une ressource
FR3042364A1 (fr) Systeme et procede de communication pour repartir la transmission de donnees sur plusieurs dispositifs

Legal Events

Date Code Title Description
STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: UNKNOWN

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE INTERNATIONAL PUBLICATION HAS BEEN MADE

PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: REQUEST FOR EXAMINATION WAS MADE

17P Request for examination filed

Effective date: 20220427

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO RS SE SI SK SM TR

RAP3 Party data changed (applicant data changed or rights of an application transferred)

Owner name: ORANGE

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: EXAMINATION IS IN PROGRESS

17Q First examination report despatched

Effective date: 20240326