EP4058892A1 - Procédés de commande d'un réseau informatique de périphérie a accès multiple - Google Patents

Procédés de commande d'un réseau informatique de périphérie a accès multiple

Info

Publication number
EP4058892A1
EP4058892A1 EP20817450.8A EP20817450A EP4058892A1 EP 4058892 A1 EP4058892 A1 EP 4058892A1 EP 20817450 A EP20817450 A EP 20817450A EP 4058892 A1 EP4058892 A1 EP 4058892A1
Authority
EP
European Patent Office
Prior art keywords
entity
module
mec2
mec1
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
EP20817450.8A
Other languages
German (de)
English (en)
Inventor
Frédéric FIEAU
Gaël FROMENTOUX
Emile Stephan
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 EP4058892A1 publication Critical patent/EP4058892A1/fr
Pending legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/54—Interprogram communication
    • G06F9/547—Remote procedure calls [RPC]; Web services
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/56—Provisioning of proxy services
    • H04L67/563—Data redirection of data network streams
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/08—Configuration management of networks or network elements
    • H04L41/0893—Assignment of logical groups to network elements

Definitions

  • This description relates to the field of multiple access peripheral computer networks and, more specifically, to methods of controlling operations in such networks.
  • 5G standards will considerably improve speeds, connectivity, latency as well as the reliability of communications in the field of industrial production known as "4.0", for example in the context of the control of connected devices, the control of robots, coordination between several machine tools, or the transmission and sharing of data or services between different operators.
  • the 5G standards will also make it possible to perfect many technologies in the field of the Internet of Things, in the field of augmented reality and even virtual reality.
  • a difficulty commonly encountered is to be able to have network architectures that meet the constraints demanded by the players in a given industrial sector when they exchange information or applications with each other, for example applications of service. Such constraints are necessary to guarantee high speeds and low latencies during data communication between several industrial sites, to meet specific traffic needs or even to share the use of common systems between different principals. .
  • MEC networks for "Multi-Access Edge Computing", in English.
  • ETSI group European Telecommunications Standards Institute
  • the ETSI group has defined precise technical specifications relating to network architectures compatible with the standards of multi-access edge computing.
  • an MEC network provides a multiple access periphery computer system which hosts service applications at a level positioned as close as possible to the “end user” level. This makes it possible to store and process data with a faster response time than traditional infrastructures and networks.
  • an MEC network is designed to be compatible with different types of mobile or fixed access, which allows it to be installed physically and directly at any level of a network provided by an operator, and for example in base stations or in infrastructures belonging to specific users or industries.
  • the data collected or used can then be communicated via a higher level network and possibly dematerialized, for example a cloud network.
  • MEC networks make it possible to meet the aforementioned requirements; For example, MEC networks can improve data sharing at an industrial site using wireless communications.
  • the corresponding architecture defines a space for exchanging and controlling data in accordance with the aforementioned conditions.
  • the specifications of networks and MEC architectures do not allow applications to be deployed from one domain to another domain.
  • an operator of a network associated with an MEC architecture of a first domain does not have the possibility of interacting with an operator associated with an architecture of a second domain, in particular for executing applications from the first domain in this second domain or again for implementing the control of an operation in other connected domains.
  • a platform module that comprises a first entity of said plurality, an execution of a service application installed in a second entity of the plurality by means of a proxy function included in said second entity, the second entity being distinct from the first entity.
  • a module designates a hardware or software computer component integrated into the network.
  • multiple access peripheral computing and “MEC” are used in a general manner. interchangeable.
  • entity and “architecture” are used interchangeably.
  • an entity of a multiple access edge computer network is an MEC architecture.
  • an edge computer network comprises a plurality of entities, that is to say at least two MEC architectures.
  • a service executed by an application is an application service, and preferably, a network service such as a DNS service or an application proxy deployed in an entity that comprises the network.
  • application services include, but are not limited to, industrial robot control services, environmental condition management services, communication services between connected terminals, physical measurement collection services, data sharing services. 'information between industrial sites, etc.
  • the method further comprises:
  • a proxy function designates a software implementation capable of allowing interaction between a host entity and a guest entity.
  • a proxy function installed in a module makes it possible to implement a command or an action from an element of a “host” network which hosts it on behalf of a “guest” element which is external to it, and thus allow access to services provided by the host element.
  • the proxy function can also refer to a network service such as a DNS service or any other type of proxy service that can be deployed to one of the entities.
  • the network comprises a plurality of entities, that is to say a plurality of multiple access periphery computer architectures, called MEC architectures.
  • MEC architectures multiple access periphery computer architectures
  • proxy module This also allows the localized module, referred to herein as "proxy module”, to fulfill an intermediary role between several entities of a multiple access periphery computer network or between entities of separate networks.
  • the location of the module is preceded by a location of a current entity from among the plurality of entities connected to each other, the module to be located being included in said current entity.
  • the method further comprises:
  • the identification of the presence of at least one such module allows it to serve as a proxy module, that is to say to define an instance located within a hardware element of an architecture GUY. This instance can be configured to act as an intermediary with another MEC architecture.
  • a proxy module can be a physical server or even a virtual server instantiated therein.
  • the location of a module among the modules that connects the network is done according to a network topology.
  • this location is made according to the presence of this module in at least one element of an entity of the periphery network of the network, among which an periphery platform, an periphery platform manager, a network virtual network virtualization infrastructure or a network data plan.
  • this allows an entity to remotely execute this application service in another entity, and more generally to control it.
  • This also allows an operator or a principal of an MEC architecture to execute application services within another MEC architecture of which he is not an operator or a principal. , and reciprocally.
  • the installed proxy function is configured to delegate control of the execution of the service application to the second entity.
  • This also allows an operator or a principal of an entity of a given edge computer network to remotely control service applications through another entity.
  • the location of the module is implemented on receipt, by the first entity, of a location response to a corresponding location request.
  • the location request and a response thereto are exchanged between managers of periphery platforms of the first and of the second entity.
  • the installation of the proxy function is implemented on receipt, by the localized module, of a download request for said proxy function.
  • the download request and a response thereto are exchanged between the located module and a periphery platform manager of the first entity.
  • the proxy function is installed via a multiple access periphery application of the second entity upon receipt, by said application, of an installation request.
  • the installation request and a response thereto are exchanged between the located module and at least one periphery application.
  • control of the execution of the service application is implemented upon receipt, by the second entity, of a control request.
  • the delegation of the control of the execution of the service application is implemented upon receipt of a request for representation of the second entity by the first entity.
  • the representation request is received by the localized module.
  • control of the execution of the service application further comprises a transmission, by the localized module and to the first entity, of a control response to the control request.
  • At least one request or a response to at least one request is transmitted via an intermediate reference point connecting the first entity and the second entity.
  • a computer program is also provided comprising instructions for implementing the method according to one of the preceding embodiments, when said instructions are executed by a processor of a computer processing circuit.
  • Figure 1 shows a schematic view of an entity that comprises a peripheral computer network according to one embodiment
  • FIG. 2 shows a schematic view of a network comprising several entities according to one embodiment
  • FIG. 3 represents a schematic view of different embodiments of connections between several entities;
  • FIG. 4 shows, in the form of a flowchart, the steps of a method for controlling an edge computer network according to one embodiment;
  • FIG. 5 shows in the form of a flow diagram of the steps of a method of controlling an edge computer network according to another embodiment
  • FIG. 6 shows a schematic block diagram of a computer processing circuit according to one embodiment.
  • FIG. 1 represents an example of an entity, that is to say an MEC architecture, which includes a computer network multiple access periphery according to one embodiment.
  • This network comprises in particular two entities MEC1 and MEC2.
  • the host level HL comprises at least one host module of the periphery network, called the MECH host module (or "Mobile Edge Computing Host", in English).
  • This MECH host module makes it possible, in particular, to provide a means of storing and processing information.
  • a MECH host module comprises at least one edge platform, called MEP platform module (or “Mobile Edge Platform”, in English), a virtual network virtualization infrastructure, called infrastructure VI (or “Virtual Network Function Infrastructure” , in English), as well as at least one periphery application, called MEA application (or “Mobile Edge Applications”, in English).
  • an MEA application is executable as a virtual machine on the VI infrastructure.
  • the MEA application interacts with the MEP platform module via at least one Mp1 reference point, which can also be used for the implementation of additional support procedures.
  • point Mp1 provides an interface connecting one or more MEA applications to an MEP platform module, which makes it possible to monitor the state of such applications. This control is implemented internally with respect to a server which hosts this or these applications.
  • An example of a MEA application is an application configured to indicate the resource or service requirements of the MECH host module, or to inform or update constraints relating to the MECH host module.
  • the infrastructure VI provides computing, storage and network resources for one or more MEA applications.
  • the VI infrastructure also includes a switching plane, called data layer, also known as DP data plane (or “Data Plane”, in English), configured to execute the transmission rules received by the MEP platform module.
  • DP data plane or “Data Plane”, in English
  • the DP data plane is generally included in the infrastructure VI of the MECH host module and makes it possible, in particular, to route data between the various services, applications and services associated with the architecture.
  • the MEP platform module that the MECH module comprises provides a set of basic functionalities for running applications on a host entity and for enabling these applications to use the associated services.
  • These functionalities are used, for example, to organize the routing of data between different applications, or between services and / or networks interacting with an MEC architecture.
  • the HL host level further comprises other entities external to the MECH host module, such as a host level multiple access periphery platform manager, called MEPM manager (or "Mobile Edge Platform Manager” in English ), or a virtualization infrastructure manager, called VIM manager (or “Virtual Infrastructure Manager”).
  • MEPM manager or "Mobile Edge Platform Manager” in English
  • VIM manager or “Virtual Infrastructure Manager”.
  • the VIM virtualization infrastructure manager is connected to the VI interface by the Mm7 reference point, which makes it possible to manage the virtualized resources of the MECH host module and / or to manage any instantiations. It is also used to keep information about available resources.
  • the MEPM manager receives the traffic transfer rules and notably manages the life cycles of the mobile edge applications and of the management functions.
  • the MEPM manager can be either a local or centralized function in an MEC architecture.
  • the MEPM manager makes it possible to provide detailed information on one or more MECH host modules deployed in different locations, for example to make it possible to enter, for example, the IP addresses of the servers which host them.
  • the MEPM manager is connected to the MEP platform module via the reference point Mm5 which allows it to transmit instructions. These instructions can be transmitted from the MEP platform module to the VI interface via the Mp2 reference point.
  • the reference point Mp2 provides an interface connecting the MEP platform to the data plane DP to allow it to communicate and transmit data.
  • the reference points Mp1 and Mp2 make it possible to exchange and manage data flows between different entities of the MECH host module, for example signals passing through the DP data plane.
  • the MEP platform module also supports the configuration of a possible local server, for example a DNS server, which can be used to direct user traffic to desired edge applications.
  • a DNS server for example a DNS server
  • the MECH host module of the MEC1 entity and, in particular, the MEP platform module of the MECH host module, are configured to exchange data with another architecture, here represented by the MEC2 entity.
  • an interface can be made between the MEC1 and MEC2 entities by means of an Mp3 reference point.
  • this Mp3 reference point can connect the MECH host module of the MEC1 entity to a second MECH2 host module that includes the MEC2 entity.
  • this connection can be established between the platform module MEP of the host module MECH of the first entity MEC1 and another platform module MEP2 of the host module MECH2 which the second entity MEC2 comprises.
  • At least one platform module among MEP and MEP2 is a local platform, that is to say a platform integrated into the topology of the corresponding entity MEC1 or that of MEC2.
  • the Mp3 reference point makes it possible to exchange and manage data flows between several entities, and in particular, between the MEC architectures that comprise the RMEC network.
  • the upper layer of the entity MEC1 which corresponds to the system level SL, comprises an operations support system, called an OSS system (or “Operations Support System”), an LCM proxy (or “Life Cycle Manager ”, in English) and a multi-access orchestrator, known as MEO orchestrator (or “Mobile Edge Orchestrator”, which is configured to run mobile edge applications.
  • OSS system or “Operations Support System”
  • LCM proxy or “Life Cycle Manager ”, in English
  • MEO orchestrator or “Mobile Edge Orchestrator”
  • the OSS system comprises at least one OSS system, a BSS system (or “Business Support System”) and / or an OSS / BSS system.
  • the MEO orchestrator is designed to communicate with applications installed on user equipment, called UEA applications (or “User Equipment Applications”, in English), or with a CFS (or "Customer-Facing Service” portal, in English) which serves as an entry point for a third-party application.
  • UEA applications or "User Equipment Applications”, in English
  • CFS or "Customer-Facing Service” portal, in English
  • a UEA application is a web application, that is to say an application that can be handled directly online using a web browser.
  • a UEA application does not require installation on a client machine.
  • a UEA application makes it possible to move applications between external networks, for example cloud networks, and the edge network.
  • a UEA application can be an edge application which is instantiated in an element of the host level FIL in response to a request from a device.
  • the LCM proxy is a proxy for managing the life cycle of user applications, and further allows applications to request the integration, instantiation, termination of user applications or even the relocation of user applications. user applications inside and outside the mobile edge network.
  • an execution of a mobile edge application can be initiated by third party equipment through a reference point located between a UEA application and the LCM proxy.
  • the execution of such an application can also be initiated through another reference point located between the CFS portal and the OSS system.
  • the various elements of the SL level make it possible to implement one or more instantiations of specific applications in the MECH host module, and in particular, instantiations performed at the request of one or more UEA applications of a user equipment.
  • the MEO orchestrator is configured to have knowledge of the topology of the MEC architecture, all of the host modules deployed in the architecture, as well as the services and resources available in each host module.
  • the OSS system is for its part linked to the host level NL via a reference point Mm2 connecting it to the manager MEPM and designed to trigger the instantiation and the closing of mobile peripheral applications of the host module, for example.
  • the Mm2 reference point can also be used for the management of failures, configuration and performance of the MEP platform module.
  • the MEO orchestrator is connected to the MEPM manager via an Mm3 reference point, and is further connected to the VIM manager via an Mm4 reference point.
  • FIG. 2 represents a schematic view of a network comprising several entities or MEC architectures according to one embodiment.
  • an RMEC network comprises two entities MEC and MEC2.
  • the entity MEC1 corresponds to an MEC architecture of a first domain, that is to say connected to a first network R, and which is interfaced with an architecture of a second domain, that is to say ie connected to a second network R2, this second domain being distinct and possibly remote from the first domain.
  • the entity MEC1 comprises elements identical to those described in the previous figure.
  • the corresponding MEC architecture further comprises an MECS service module connected to the MEPM manager as well as to a first industrial data space IDS-A.
  • the data plane DP that this MEC architecture comprises is connected to the first network R, which is for example a cloud network of a first factory of the first domain.
  • the other entity MEC2 comprises elements similar to those of the entity MEC1, and in particular, a host module MECH2 comprising a platform module MEP2, at least one application MEA2 and a data plane DP2 connected to the second network R2, for example a cloud network of a second factory which is remote from the first factory.
  • the MEC2 entity further comprises an MEPM2 manager connected to another MECS2 service module, itself connected to the MEPM2 manager as well as to a second industrial data space IDS-B.
  • the data plane DP is used to control a robot via the network R of the first factory, while the data plane DP2 is used to control another robot via the network R2 of the second plant.
  • robots of the same type or from the same manufacturer are configured so that the same cyber-physical system can be used to control these robots in order to perform a task.
  • two robots connected to two separate R and R2 networks can be controlled remotely by different ordering parties, here by the two industrial data spaces IDS-A and IDS-B having the same cyber-physical system.
  • the control of a robot via a given network may require resources absent from the MEC architecture connected to this network.
  • an ordering party corresponding to the IDS-A industrial space will not be able to control a robot connected to the R2 network if this control requires an application present in MEA, but absent from MEA2.
  • the industrial site of the first domain does not necessarily have the applications necessary to control a robot on the industrial site of the second domain, even if the first domain includes a similar or identical robot.
  • the entities MEC1 and MEC2 have inter-domain interfaces. How to improve their corresponding architectures and associated methods to enable the transmission and execution of these applications.
  • An interface between the two entities MEC1 and MEC2 is for example possible by means of the reference point Mp3 to allow the platform module MEP to communicate with other platforms, and in particular with the platform module MEP2 of the host module MECH2 that includes the second architecture MEC2.
  • this interface and this communication takes place via the Mp3 reference point, which connects the platform modules MEP and MEP2.
  • the Mp3 reference point is shown as belonging to the MEC1 entity, but this is equivalent to the corresponding Mp3 ’reference point in the other MEC2 entity.
  • the interface produced by means of the intermediate point Mp3 between the entities MEC1 and MEC2 does not on its own make it possible to share or transmit an executable application from one MEC architecture to another.
  • Mp3 does not by itself allow a remote execution of a control command for this robot.
  • a solution provided by the present embodiments provides for the creation of a new interface.
  • FIG. 3 represents a schematic view of connections between two entities, and more precisely between two entities MEC1 and MEC2.
  • a MEPROXY module is present in the MEC2 entity. This module is either located outside the MEP2 platform module and connected to it and / or to the MEPM2 manager, for example by means of a connection in the MEC2 entity, or installed directly in the MEP2 platform module.
  • At least one interface between the two entities MEC1 and MEC2 is implemented by means of of so-called intermediate reference points, to allow inter-domain application exchange.
  • an interface is defined by an intermediate reference point Mpld connects the managers MEPM and MEPM2 of the two architectures.
  • the intermediate reference point Mpld thus allows direct or indirect communication between the two entities MEC1 and MEC2.
  • the point Mpid can for example be located in a host level HL of the first architecture MEC or of the second architecture MEC which correspond to the entities.
  • an interface is defined by another intermediate reference point Mpl ld which connects the MEP platform module of the MEC1 entity to the MEPROXY module of the other MEC2 entity.
  • an interface is defined by yet another intermediate reference point Mpld ’connects the MEPM manager of the MEC1 entity to the MEPROXY module of the other MEC2 entity.
  • a direct or indirect interface can be implemented between at least three MEC architectures by means of reference points similar to those previously described.
  • FIG. 4 represents in flowchart form the steps of a method for controlling a multiple access peripheral computer network according to one embodiment.
  • a first step S1 concerns the location of the MEPROXY module within the MEC2 entity.
  • this location is implemented at least by the exchange of a location request-response pair exchanged between two entities MEC1 and MEC2 with the result of providing the position of the module within MEC2, for example by informing its IP addresses.
  • a second step S2, which follows step S1, concerns the installation of an FPROXY proxy function in at least one module whose location is known.
  • this installation includes an exchange of an installation request-response pair of the FPROXY function.
  • said installation request-response pair is exchanged between the MPEROXY module located during step S1 and at least one application MEA2.
  • a third step S3, which follows step S2, relates to the control of an operation of the network, in particular of an execution of a service application.
  • this command comprises an exchange of a command request-response pair, said command request-response pair being exchanged between the first architecture MEC and the MEPROXY module which includes the FPROXY function installed during step S2.
  • FIG. 5 shows in the form of a flow diagram of steps S10, S20, S30, S40, S50, S60, S70, S80, S90 and S100 of a control method of a peripheral computer network according to another embodiment.
  • the MEPROXY module and the FPROXY proxy function are represented as being distinct and separate from the platform module MEP2. However, this does not exclude the MEPROXY module and the FPROXY proxy function from being installed in the MEP2 platform module.
  • the location step S1 comprises the steps S10 and S20
  • the installation step S2 comprises the steps S30, S40, S50 and S60
  • the step S3 for controlling a network operation, in particular an execution of a service application comprises the steps S70, S80, S90 and S100.
  • the MEPM manager of the MEC1 entity transmits a location request RQ-LOC to the MEPM2 manager of the MEC2 entity. This makes it possible to request the address of the MEPROXY module.
  • the RQ-LOC location request is preferably transmitted via the intermediate reference point Mpld.
  • step S20 on receipt of the RQ-LOC request, an ACK-LOC location acknowledgment message is sent from the manager MEPM2 to the manager MEPM.
  • This acknowledgment message is used to inform the location of the MEPROXY module to the MEC1 entity.
  • the message ACK-LOC acknowledgment is preferably also transmitted via the intermediate reference point Mpld.
  • the ACK-LOC acknowledgment includes an IP address of the localized MEPROXY module, for example the IP address of the server hosting it. According to another example, and entered by the manager MEPM2.
  • the MEPM manager initiates the installation of one or more applications in the MEC2 entity, via the reference point Mp1, the point Mp3 reference point or even the intermediate reference point Mpld. This installation is implemented during steps S30 to S60, in order to prepare the installation of the FPROXY proxy function in the MEPROXY module.
  • Step S30 comprises the transmission of an RQ-UP download request from the MEPM manager to MEC2, in particular to the MEPROXY module of MEC2.
  • the download request RQ-UP can be transmitted from a central point integrated into the architecture MEC corresponding to MEC1 or from another point such as a server or any other type of device connected to MEC1 .
  • step S30 is implemented on receipt of the ACK-LOC location acknowledgment message, on receipt of location information from the MEPROXY module or else of an instruction to install a device. application or a function in the MEPROXY module if its location is entered in the installation instruction.
  • the installation of the FPROXY proxy function is implemented by a principal associated with the entity MEC1, for example by a principal having access to the industrial space. IDS-A data.
  • An installation or an update of this function can be implemented by means of an MEO orchestrator or an OSS system of one or the other of the entities MEC1 and MEC2.
  • the MEPROXY module transmits an installation request RQ-INST to at least one application MEA2 that includes the entity MEC2. This request is preferably transmitted via the point Mp1 '.
  • the MEPROXY module and / or the FPROXY function are instantiated.
  • the OSS system (s) that comprise the entities MEC1 and MEC2 are connected to the platform MEPM, and further configured to trigger the instantiation or the closing of the FPROXY function.
  • the proxy function FPROXY is installed in the second entity MEC2 during step S40.
  • This installation is implemented by at least one MEA2 periphery application.
  • the FPROXY function is installed directly in the MEPROXY module.
  • an installation acknowledgment message ACK-INST is sent during step S50 by the second MEC2 entity to the first MEC1 entity.
  • the ACK-INST installation acknowledgment message is transmitted by the MEPROXY module to the MEPM manager of the MEC architecture.
  • the ACK-INST installation acknowledgment message is transmitted via the MpT reference point.
  • an ACK-UP download acknowledgment message is transmitted by the MEPROXY module to the MEPM manager.
  • the ACK-INST installation acknowledgment message is transmitted via the intermediate reference point Mpld ’.
  • the ACK-UP download acknowledgment message can be transmitted during step S50 and more generally on receipt of the download request RQ-UP, when the latter makes it possible to proceed. directly to the installation of the FPROXY function in the MEPROXY module.
  • the ACK-INST installation acknowledgment message makes it possible to indicate to the manager MEPM, and therefore to the entity MEC1, that the installation of the proxy function FPROXY has been completed.
  • the MEP platform module initiates the command of an execution of a service application by means of the installed proxy function.
  • this order comprises several steps S70 to S100 making it possible to guarantee that the order is initiated by a principal external to the entity MEC2, for example a principal having access to the industrial space of IDS-A data rather than the industrial IDS-B data space.
  • a step S70 is implemented and comprises the transmission of an RQ-CTRL command request from the platform module MEP to the entity MEC2, and in particular to the module MEPROXY that includes MEC2.
  • this request can correspond to a request coming from a principal associated with the industrial data space IDS-A connected to the entity MEC1, in order to be able to run an application in the entity MEC2. .
  • step S70 is implemented on receipt of the ACK-UP location acknowledgment message, or more generally on receipt of a confirmation that the FPROXY function has been downloaded and / or installed in the device.
  • MEPROXY module is implemented on receipt of the ACK-UP location acknowledgment message, or more generally on receipt of a confirmation that the FPROXY function has been downloaded and / or installed in the device.
  • a caching of an application present in MEA2 is performed.
  • caching is meant here that the execution of this application, initially allowed to a first ordering party, for example an ordering party associated with the industrial data space IDS-A, is delegated to a second ordering party, for example another principal who is associated with the industrial data space IDS-B rather than with IDS-A.
  • step S80 implements this caching on receipt, by MEA2, of a caching request RQ-PROXY, this caching request being transmitted by the MEPROXY module, preferably via point Mp1 '.
  • an ACK-PROXY caching acknowledgment message is sent. transmitted by MEA2 to the MEPROXY module, in order to confirm that the delegation of the execution of the application concerned is indeed effective.
  • an ACK-CTRL command acknowledgment message is sent during step S100 by the entity MEC2 to the entity MEC1.
  • the ACK-CTRL command acknowledgment message is sent by the MEPROXY module from the MEC2 entity to the MEP platform module of the MEC1 entity.
  • This ACK-CTRL command acknowledgment message is used to indicate to the MEC1 entity that an execution of a service application can be commanded by means of the installed proxy function.
  • a command of an execution of one or more service applications by means of the proxy function installed in MEPROXY comprises, for example, the execution of an application allowing the control of a connected device, the piloting of a robot, the coordination of a movement between several machine tools, or the transmission of information or data. signals to an operator.
  • an industrial data space IDS-A is initially a customer of the services provided by an MEC architecture belonging to a first domain, this customer wishing to be allowed the use of a robot connected in a second associated domain. to another MEC architecture.
  • the robot performs tasks for an industrial data space IDS-B customer of the services provided by the entity MEC2.
  • steps S1 to S3 makes it possible to make available, via the first domain, from the industrial data space IDS-A, one or more resources that can be used by the latter.
  • the first domain is thus responsible for carrying out a task that it could not initially carry out.
  • the MEC1 entity is thus able to seek resources or services on behalf of IDS-A in another domain.
  • each of the domains can also expose or share its resources independently, so as to make them available to several other domains.
  • FIG. 6 represents a schematic block diagram of a computer processing circuit according to an exemplary implementation of the embodiments described.
  • said computer processing circuit is a processor.
  • a computer processing circuit is a system on a chip 1000 arranged to implement a method for controlling a peripheral computer network.
  • this computer processing circuit can correspond to a hardware element defining the MEPROXY module, an MEP platform module or even an MEPM manager.
  • the system on a chip 1000 comprises a communication bus connected, for example, to a central processing unit 1010, such as a processor or a microprocessor, and denoted CPU.
  • a central processing unit 1010 such as a processor or a microprocessor, and denoted CPU.
  • the system on a chip 1000 further comprises a random access memory 1020, denoted RAM, capable of storing the executable code of the control method as well as the registers suitable for recording the variables and parameters necessary for the implementation of the control process.
  • a random access memory 1020 denoted RAM
  • the memory capacity thereof can be supplemented by an optional RAM memory connected to an expansion port, for example.
  • system on a chip 1000 comprises a read only memory 1030, denoted ROM, for storing computer programs for the implementation. embodiments described above, as well as a network interface 1040 which is normally connected to a communication network on which digital data to be processed are transmitted or received.
  • ROM read only memory
  • network interface 1040 which is normally connected to a communication network on which digital data to be processed are transmitted or received.
  • the network interface 1040 can be a single network interface, or composed of a set of different network interfaces (for example wired and wireless, interfaces or different types of wired or wireless interfaces).
  • Data packets are sent over the network interface for transmission or are read from the network interface for reception under the control of the software application running in the processor or microprocessor 1010.
  • the system on a chip 1000 comprises a user interface 1050 for receiving inputs from a user or for displaying information to a user, an optional storage medium 1060 denoted HD, and an input-output module 1070, denoted IO, for receiving, sending data from or to external devices such as hard disk, removable storage medium or others.
  • the executable code can be stored in a read only memory 1030, on the storage medium 1060 or on a digital removable medium such as for example a disk.
  • the executable code of the programs can be received by means of a communication network, via the network interface 1040, in order to be stored in the storage medium 1060, before being executed.
  • the central processing unit 1010 is suitable for controlling and directing the execution of the instructions or portions of software code of the program or of the programs according to one of the embodiments, instructions which are stored in one of the storage means mentioned above. After power-up, the CPU 1010 is able to execute instructions stored in the main RAM memory 1020, relating to a software application, after these instructions have been loaded from the ROM for example.
  • system on a chip 1000 is a programmable device which uses software.
  • this description can be implemented in any type of hardware (eg, in the form of a specific integrated circuit or ASIC).

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Computer And Data Communications (AREA)
  • Information Transfer Between Computers (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

La présente divulgation concerne la commande d'opérations dans un réseau comprenant plusieurs architectures informatiques de périphérie à accès multiple. Spécifiquement, la présente divulgation se rapporte à un procédé de commande d'une application de service dans un réseau informatique de périphérie à accès multiple (RMEC), le réseau comprenant une pluralité d'entités (MEC1, MEC2) connectées entre elles, le procédé comportant: - commander (S3; S70, S80, S90, S100), par un module plateforme (MEP) que comprend une première entité (MEC1) de ladite pluralité, une exécution d'une application de service installée dans une deuxième entité (MEC2) de la pluralité par l'intermédiaire d'une fonction mandataire (FPROXY) comprise dans ladite deuxième entité, la deuxième entité étant distincte de la première entité.

Description

Description
Titre : Procédés de commande d’un réseau informatique de périphérie à accès multiple
Arrière-plan de l’invention
[0001] La présente description se rapporte au domaine des réseaux informatiques de périphérie à accès multiple et, plus précisément, à des procédés de commande d’opérations dans de tels réseaux.
[0002] Les domaines de la santé, des transports, de l’énergie, de l’industrie du transport deviendront prochainement des domaines majeurs d’utilisation des standards 5G en télécommunications. En particulier, les standards 5G vont considérablement améliorer les débits, la connectivité, la latence ainsi que la fiabilité des communications dans le domaine de la production industrielle dite « 4.0 », par exemple dans le cadre de la commande de dispositifs connectés, du pilotage de robots, de la coordination entre plusieurs machines-outils, ou encore de la transmission et du partage de données ou de services entre différents opérateurs. Les standards 5G vont également permettre de perfectionner de nombreuses technologies dans le domaine de l’Internet des objets, dans le domaine de la réalité augmentée ou encore de la réalité virtuelle.
[0003] Dans ce contexte, une difficulté couramment rencontrée est de pouvoir disposer d’architectures réseaux répondant aux contraintes exigées par les acteurs d’un secteur industriel donné lorsque ceux-ci échangent entre eux des informations ou des applications, par exemple des applications de service. De telles contraintes sont nécessaires pour garantir des débits élevés et des latences faibles lors de la communication de données entre plusieurs sites industriels, pour faire face à des besoins de trafic spécifiques ou encore pour partager l’utilisation de systèmes communs entre différents donneurs d’ordre.
[0004] Pour ce faire, il est connu des réseaux informatiques de périphérie à accès multiples, dits réseaux MEC (pour « Multi-Access Edge Computing », en anglais). Le groupe ETSI (« European Télécommunications Standards Institute », en anglais) a défini des spécifications techniques précises et relatives à des architectures réseau compatibles avec les standards de l’informatique de périphérie multi-accès.
[0005] Selon ces normes, un réseau MEC fournit un système informatique de périphérie à accès multiple qui héberge des applications de services à un niveau positionné au plus proche du niveau « utilisateur » (« end user », en anglais). Ceci permet de stocker et de traiter des données avec un temps de réponse plus rapide que les infrastructures et les réseaux traditionnels.
[0006] En outre, un réseau MEC est conçu pour être compatible avec différents types d’accès mobiles ou fixes, ce qui lui permet d’être installé physiquement et directement à tout niveau d’un réseau fourni par un opérateur, et par exemple dans des stations de base ou dans des infrastructures appartenant à des utilisateurs ou à des industries spécifiques. Les données collectées ou utilisées peuvent ensuite être communiquées via un réseau de niveau supérieur et éventuellement dématérialisé, par exemple un réseau en nuage.
[0007] L’utilisation de réseaux MEC permet de répondre aux exigences précitées ; à titre d’exemple, des réseaux MEC permettent d’améliorer le partage de données sur un site industriel au moyen de communications sans fil. L’architecture correspondante définit un espace d’échange et de contrôle de données conformes aux conditions précitées.
[0008] Toutefois, les procédés de communication et de commande de réseaux MEC connus présentent plusieurs inconvénients majeurs.
[0009] Tout d’abord, les spécifications techniques des réseaux et des architectures MEC, qui seront déployés dans un avenir proche, ne sont actuellement prévues que pour commander des opérations dans un seul domaine, par exemple sur un seul site industriel donné. Il n’est donc pas possible de commander une opération d’un domaine à partir d’un autre domaine.
[0010] En outre, les spécifications des réseaux et des architectures MEC ne permettent pas de déployer des applications depuis un domaine vers un autre domaine. Par exemple, un opérateur d’un réseau associé à une architecture MEC d’un premier domaine n’a pas la possibilité d’interagir avec un opérateur associé à une architecture d’un deuxième domaine, en particulier pour exécuter des applications du premier domaine dans ce deuxième domaine ou encore pour mettre en œuvre la commande d’une opération dans d’autres domaines connectés.
[0011] De plus, il n’est pas possible de partager ou d’échanger des ressources utiles à l’exécution d’applications par des systèmes informatiques de périphérie à accès multiple localisés dans des domaines différents. Actuellement, les architectures MEC ne permettent donc pas de commander des opérations en mode « inter-domaine ».
[0012] Par ailleurs, les architectures et les réseaux MEC actuels ne permettent pas non plus à différentes entités d’exécuter une tâche dans un domaine donné si cette tâche nécessite une ressource qui est absente du système informatique de périphérie à accès multiple déployé dans ce domaine.
Objet et résumé de l’invention [0013] Afin d’améliorer la situation et de répondre à ce ou à ces inconvénients, il est proposé, de façon générale, un procédé de commande d’une application de service dans un réseau informatique de périphérie à accès multiple, le réseau comprenant une pluralité d’entités connectées entre elles, le procédé comportant:
- commander, par un module plateforme que comprend un première entité de ladite pluralité, une exécution d’une application de service installée dans une deuxième entité de la pluralité par l’intermédiaire d’une fonction mandataire comprise dans ladite deuxième entité, la deuxième entité étant distincte de la première entité.
[0014] Ceci permet la mise en œuvre d’échanges applicatifs inter-domaines. Ceci permet aussi d’effectuer une transmission d’applications et/ou d’utiliser des services au sein d’une ou de plusieurs entités au sein d’un réseau informatique de périphérie à accès multiple.
[0015] Dans les présentes, et de manière générale, un module désigne un composant informatique matériel ou logiciel intégré au réseau.
[0016] Dans les présentes, et de manière générale, les appellations « informatique de périphérie à accès multiple » et « MEC » sont utilisées de manière interchangeable. En outre, les appellations « entité » et « architecture » sont utilisées de manière interchangeable. Ainsi, une entité d’un réseau informatique de périphérie à accès multiple est une architecture MEC.
[0017] Dans les présentes, et conformément à ces appellations, il est ainsi défini qu’un réseau informatique de périphérie comprend une pluralité d’entités, c’est-à- dire au moins deux architectures MEC.
[0018] Dans les présentes, un service exécuté par une application est un service d’application, et de préférence, un service réseau tel qu’un service DNS ou un proxy d’application déployé dans une entité que comprend le réseau. Des exemples de services d’application comprennent, entre autres, des services de contrôle de robots industriels, des services de gestion de conditions environnementales, des services de communication entre des terminaux connectés, des services de collecte de mesures physiques, des services de partage d’informations entre des sites industriels, etc.
[0019] Dans une réalisation, le procédé comporte en outre :
- localiser un module parmi une pluralité de modules que comprend la deuxième entité ; et
- installer la fonction mandataire dans le module localisé.
[0020] Dans les présentes, et de manière générale, une fonction mandataire désigne une implémentation logicielle apte à permettre une interaction entre une entité hôte et une entité invitée. Par exemple, une fonction mandataire installée dans un module permet de mettre en œuvre une commande ou une action depuis un élément d’un réseau « hôte » qui l’abrite pour le compte d'un élément « invité » qui lui est externe, et ainsi permettre un accès à des services fournis par l’élément hôte.
[0021] Dans les présentes, la fonction mandataire peut aussi désigner un service réseau tel qu’un service DNS ou tout autre type de service mandataire pouvant être déployé l’une des entités.
[0022] Dans les présentes, le réseau comporte une pluralité d’entités, c’est-à-dire une pluralité d’architectures informatiques de périphérie à accès multiple, dites architectures MEC. La localisation du module dans une entité permet de provoquer la commande de l’exécution du service par une application installée dans une autre entité.
[0023] Ceci permet aussi au module localisé, appelé dans les présentes « module mandataire », de remplir un rôle d'intermédiaire entre plusieurs entités d’un réseau informatique de périphérie à accès multiple ou entre des entités de réseaux distincts.
[0024] Dans une réalisation particulière, la localisation du module est précédée par une localisation d’une entité courante parmi la pluralité d’entités connectées entre elles, le module à localisé étant compris dans ladite entité courante.
[0025] Dans une réalisation, le procédé comporte en outre :
- analyser une topologie du réseau pour identifier une présence d’un module courant dans une plateforme de périphérie à accès multiple du réseau, en vue de la localisation du module ;
- sélectionner ledit module courant en tant que module localisé, en vue de l’installation de la fonction mandataire.
[0026] L’identification de la présence d’au moins un tel module permet à celui-ci de servir de module mandataire, c’est-à-dire de définir une instance localisée au sein d’un élément matériel d’une architecture MEC. Cette instance peut être configurée pour servir d'intermédiaire avec une autre architecture MEC. Un tel module « mandataire » peut être un serveur physique ou encore un serveur virtuel instancié dans celui-ci.
[0027] Dans les présentes, la localisation d’un module parmi les modules que relie le réseau se fait en fonction d’une topologie du réseau.
[0028] Selon différents exemples, cette localisation se fait en fonction de la présence de ce module dans au moins un élément d’une entité du réseau de périphérie du réseau, parmi lesquels une plateforme de périphérie, un gestionnaire de plateforme de périphérie, une infrastructure de virtualisation de réseau virtuel du réseau ou encore un plan de données du réseau. Ces éléments seront décrits dans la suite des présentes en relation avec les figures.
[0029] En particulier, ceci permet à une entité d’exécuter à distance ce service d’application dans une autre entité, et plus généralement de la piloter. [0030] Ceci permet aussi à un opérateur ou un donneur d’ordre d’une architecture MEC d’exécuter des services d’applications au sein d’une autre architecture MEC dont il n’est pas un opérateur ou un donneur d’ordre, et réciproquement.
[0031] Dans une réalisation, la fonction mandataire installée est configurée pour déléguer la commande de l’exécution de l’application de service à la deuxième entité.
[0032] Ceci permet de réaliser une interface entre des composants matériels ou logiciels appartenant à des entités distinctes.
[0033] Ceci permet aussi à un opérateur ou à un donneur d’ordre d’une entité d’un réseau informatique de périphérie donné de commander à distance des applications de service par l’intermédiaire d’une autre entité.
[0034] En outre, ceci permet l’utilisation et la combinaison de ressources des domaines auxquels chacune de ces entités appartient pour l’exécution de services d’applications.
[0035] Dans une réalisation, la localisation du module est mise en œuvre sur réception, par la première entité, d’une réponse de localisation à une requête de localisation correspondante.
[0036] Ceci permet de tester la présence et/ou la position du module localisé dans le réseau informatique de périphérie.
[0037] Dans une réalisation particulière, la requête de localisation et une réponse à celle-ci sont échangées entre des gestionnaires de plateformes de périphérie de la première et de la deuxième entité.
[0038] Dans une réalisation, l’installation de la fonction mandataire est mise en œuvre sur réception, par le module localisé, d’une requête de téléchargement de ladite fonction mandataire.
[0039] Ceci permet d’installer une fonction mandataire qui n’est pas initialement présente dans le module localisé.
[0040] Dans une réalisation particulière, la requête de téléchargement et une réponse à celle-ci sont échangées entre le module localisé et un gestionnaire de plateforme de périphérie de la première entité. [0041] Dans une réalisation, la fonction mandataire est installée via une application de périphérie à accès multiple de la deuxième entité sur réception, par ladite application, d’une requête d’installation.
[0042] Ceci permet de provisionner, au module localisé, une fonction mandataire qui n’est pas initialement présente dans celui-ci.
[0043] Dans une réalisation particulière, la requête d’installation et une réponse à celle-ci sont échangées entre le module localisé et au moins une application de périphérie.
[0044] Dans une réalisation, la commande de l’exécution de l’application de service est mise en œuvre sur réception, par la deuxième entité, d’une requête de commande.
[0045] Dans une réalisation, la délégation de la commande de l’exécution de l’application de service est mise en œuvre sur réception d’une requête de représentation de la deuxième entité par la première entité.
[0046] De préférence, la requête de représentation est reçue par le module localisé.
[0047] Dans une réalisation, la commande de l’exécution de l’application de service comporte en outre une émission, par le module localisé et à destination de la première entité, d’une réponse de commande à la requête de commande.
[0048] Dans une réalisation, au moins une requête ou une réponse à au moins une requête est transmise via un point intermédiaire de référence connectant la première entité et la deuxième entité.
[0049] Il est aussi proposé un programme informatique comportant des instructions pour la mise en œuvre du procédé selon l’une des réalisations précédentes, lorsque lesdites instructions sont exécutées par un processeur d’un circuit de traitement informatique.
[0050] Il est aussi proposé un support de stockage d'informations, amovible ou non, partiellement ou totalement lisible par un ordinateur ou un processeur comportant des instructions de code d'un programme d'ordinateur pour l'exécution de chacune des étapes du procédé selon l’une quelconque des réalisations précédentes. Brève description des dessins
[0051] D’autres caractéristiques, détails et avantages apparaîtront à la lecture de la description détaillée ci-après, et à l’analyse des dessins annexés, sur lesquels :
[0052] [Fig. 1], la figure 1 représente une vue schématique d’une entité que comprend un réseau informatique de périphérie selon une réalisation ;
[0053] [Fig. 2], la figure 2, représente une vue schématique d’un réseau comprenant plusieurs entités selon une réalisation;
[0054] [Fig. 3], la figure 3, représente une vue schématique de différentes réalisations de connexions entre plusieurs entités ; [0055] [Fig. 4], la figure 4, représente sous forme d’organigramme, des étapes d’un procédé de commande d’un réseau informatique de périphérie selon une réalisation;
[0056] [Fig. 5], la figure 5, représente sous forme de diagramme de flux des étapes d’un procédé de commande d’un réseau informatique de périphérie selon une autre réalisation ;
[0057] [Fig. 6], la figure 6, représente un bloc-diagramme schématique d'un circuit de traitement informatique selon une réalisation.
[0058] Sauf indications contraires, les éléments communs ou analogues à plusieurs figures portent les mêmes signes de référence et présentent des caractéristiques identiques ou analogues, de sorte que ces éléments communs ne sont généralement pas à nouveau décrits par souci de simplicité.
Description des modes de réalisation
[0059] Les dessins et la description ci-après contiennent, pour l’essentiel, des éléments de caractère certain. Ils pourront donc servir à mieux faire comprendre la présente divulgation et à contribuer à sa définition, le cas échéant.
[0060] Il est maintenant fait référence à la figure 1, qui représente un exemple d’entité, c’est-à-dire une architecture MEC, que comprend un réseau informatique de périphérie à accès multiple selon une réalisation. Ce réseau comprend en particulier deux entités MEC1 et MEC2.
[0061] Différents éléments fonctionnels que comprend l’entité MEC1 sont illustrés de manière plus détaillée. Ces éléments fonctionnels sont regroupés en plusieurs niveaux, ou couches, parmi lesquelles un niveau système SL correspondant à une couche supérieure et un niveau hôte HL correspondant à une couche intermédiaire.
[0062] Concernant la couche intermédiaire, le niveau hôte HL comprend au moins un module hôte du réseau de périphérie, dit module hôte MECH (ou « Mobile Edge Computing Host », en anglais). Ce module hôte MECH permet, notamment, de fournir un moyen de stockage et de traitement d’informations.
[0063] Une module hôte MECH comprend au moins une plateforme de périphérie, dite module plateforme MEP (ou « Mobile Edge Platform », en anglais), une infrastructure de virtualisation de réseau virtuel, dite infrastructure VI (ou « Virtual Network Function Infrastructure », en anglais), ainsi qu’au moins une application de périphérie, dites application MEA (ou « Mobile Edge Applications », en anglais).
[0064] Typiquement, une application MEA est exécutable en tant que machine virtuelle sur l'infrastructure VI. Lorsqu’elle est exécutée, l’application MEA interagit avec le module plateforme MEP via au moins un point de référence Mp1 , qui peut également être utilisé pour la mise en œuvre de procédures de support supplémentaires.
[0065] En outre, le point Mp1 fournit une interface reliant une ou plusieurs applications MEA à un module plateforme MEP, ce qui permet de contrôler l’état de telles applications. Ce contrôle est mis en œuvre de manière internalisée par rapport à un serveur qui héberge cette ou ces applications.
[0066] Un exemple d’application MEA est une application configurée pour indiquer les besoins en ressources ou en services du module hôte MECH, ou encore pour renseigner ou mettre à jour des contraintes relatives au module hôte MECH.
[0067] L’infrastructure VI fournit des ressources de calcul, de stockage et de réseau pour une ou plusieurs applications MEA. L'infrastructure VI comprend en outre un plan de commutation, dit couche de données, aussi dit plan de données DP (ou « Data Plane », en anglais), configuré pour exécuter les règles de transmission reçues par le module plateforme MEP.
[0068] Le plan de données DP est généralement compris dans l’infrastructure VI du module hôte MECH et permet, notamment, d’acheminer des données entre les différents services, applications et services associés à l’architecture.
[0069] Le module plateforme MEP que comprend le module MECH fournit un ensemble de fonctionnalités de base pour exécuter des applications sur une entité hôte et pour permettre à ces applications d’utiliser les services associés.
[0070] Ces fonctionnalités sont utilisées, par exemple, pour organiser le routage de données entre différentes applications, ou entre des services et/ou des réseaux interagissant avec une architecture MEC.
[0071] Le niveau hôte HL comprend en outre d’autres entités externes au module hôte MECH, telles qu’un gestionnaire de plateforme de périphérie à accès multiple de niveau hôte, dit gestionnaire MEPM (ou « Mobile Edge Platform Manager », en anglais), ou encore un gestionnaire d’infrastructure de virtualisation, dit gestionnaire VIM (ou « Virtual Infrastructure Manager », en anglais).
[0072] Le gestionnaire d’infrastructure de virtualisation VIM est relié à l’interface VI par le point de référence Mm7, ce qui permet de gérer les ressources virtualisées du module hôte MECH et/ou pour gérer d’éventuelles instanciations. Il est également utilisé pour conserver des informations sur les ressources disponibles.
[0073] Le gestionnaire MEPM reçoit les règles de transfert de trafic et gère notamment les cycles de vie des applications de périphérie mobile et des fonctions de gestion.
[0074] Le gestionnaire MEPM peut être une fonction soit locale soit centralisée dans une architecture MEC. Le gestionnaire MEPM permet de fournir des informations détaillées sur un ou plusieurs modules hôtes MECH déployés en différentes localisations, par exemple pour permettre de renseigner par exemple les adresses IP des serveurs qui les abritent.
[0075] Le gestionnaire MEPM est connecté au module plateforme MEP via le point de référence Mm5 qui lui permet de transmettre des instructions. Ces instructions peuvent être transmises du module plateforme MEP à l’interface VI via le point de référence Mp2.
[0076] Le point de référence Mp2 fournit une interface reliant la plateforme MEP au plan de données DP pour lui permettre de communiquer et transmettre des données.
[0077] Les points de référence Mp1 et Mp2 permettent d’échanger et de gérer des flux de données entre différentes entités du module hôte MECH, par exemple des signaux passant par le plan de données DP.
[0078] Le module plateforme MEP prend aussi en charge la configuration d’un éventuel serveur local, par exemple un serveur DNS, qui peut être utilisé pour diriger le trafic utilisateur vers des applications de périphérie souhaitées.
[0079] Le module hôte MECH de l’entité MEC1 , et, en particulier, le module plateforme MEP du module hôte MECH, sont configurés pour échanger des données avec une autre architecture, ici représentée par l’entité MEC2.
[0080] Spécifiquement, une interface peut être réalisée entre les entités MEC1 et MEC2 au moyen d’un point de référence Mp3.
[0081] Comme illustré, ce point de référence Mp3 peut connecter le module hôte MECH de l’entité MEC1 à un deuxième module hôte MECH2 que comprend l’entité MEC2. En particulier, cette connexion peut être établie entre le module plateforme MEP du module hôte MECH de la première entité MEC1 et un autre module plateforme MEP2 du module hôte MECH2 que comprend la deuxième entité MEC2.
[0082] Au moins un module plateforme parmi MEP et MEP2 est une plateforme locale, c’est-à-dire une plateforme intégrée dans la topologie de l’entité correspondante MEC1 ou de celle de MEC2.
[0083] Le point de référence Mp3 permet d’échanger et de gérer des flux de données entre plusieurs entités, et en particulier, entre les architectures MEC que comprend le réseau RMEC.
[0084] La couche supérieure de l’entité MEC1 , qui correspond au niveau système SL, comprend un système de support d’opérations, dit système OSS (ou « Operations Support System », en anglais), un proxy LCM (ou « Life Cycle Manager », en anglais) et un orchestrateur multi-accès, dit orchestrateur MEO (ou « Mobile Edge Orchestrator », en anglais), qui est configuré pour exécuter des applications de périphérie mobile.
[0085] De manière générale, le système OSS comprend au moins un système OSS, un système BSS (ou « Business Support System », en anglais) et/ou un système OSS/BSS.
[0086] L’orchestrateur MEO est agencé pour communiquer avec des applications installées sur un équipement utilisateur, dites applications UEA (ou « User Equipment Applications », en anglais), ou avec un portail CFS (ou « Customer- Facing Service », en anglais) qui sert de point d’entrée pour une application tiers.
[0087] Dans les présentes, une application UEA est une application web, c’est-à- dire une application manipulable directement en ligne grâce à un navigateur web. Typiquement, une telle application UEA ne nécessite pas d'installation sur une machine cliente.
[0088] Une application UEA permet de déplacer des applications entre des réseaux externes, par exemple des réseaux en nuage, et le réseau de périphérie. En particulier, une application UEA peut être une application de périphérie qui est instanciée dans un élément du niveau hôte FIL en réponse à une demande d'un équipement.
[0089] Dans les présentes, le proxy LCM est un proxy de gestion du cycle de vie des applications utilisateur, et permet en outre aux applications de requérir l’intégration, l’instanciation, la résiliation d’applications utilisateur ou encore la relocalisation d’applications utilisateur à l’intérieur et à l’extérieur du réseau de périphérie mobile.
[0090] Au niveau système SL, une exécution d’une application de périphérie mobile peut être initiée par un équipement tiers par l’intermédiaire d’un point de référence situé entre une application UEA et le proxy LCM. L’exécution d’une telle application peut aussi être initiée par l’intermédiaire d’un autre point de référence situé entre le portail CFS et le système OSS.
[0091] Selon différents exemples, les différents éléments du niveau SL permettent de mettre en œuvre une ou plusieurs instanciations d’applications spécifiques dans le module hôte MECH, et en particulier, des instanciations effectuées sur demande d’une ou de plusieurs applications UEA d’un équipement utilisateur.
[0092] L’orchestrateur MEO est configuré pour avoir connaissance de la topologie de l’architecture MEC, de tous les modules hôte déployés dans l’architecture, ainsi que des services et des ressources disponibles dans chaque module hôte.
[0093] Le système OSS est quant à lui relié au niveau hôte NL via un point de référence Mm2 le connectant au gestionnaire MEPM et conçu pour déclencher l'instanciation et la fermeture d’applications de périphérie mobile du module hôte, par exemple.
[0094] Le point de référence Mm2 peut aussi être utilisé pour la gestion des pannes, de la configuration et des performances du module plateforme MEP.
[0095] L’orchestrateur MEO est connecté au gestionnaire MEPM via un point de référence Mm3, et est en outre connecté au gestionnaire VIM via un point de référence Mm4.
[0096] Il est maintenant fait référence à la figure 2, qui représente une vue schématique d’un réseau comprenant plusieurs entités ou architectures MEC selon une réalisation.
[0097] En particulier, un réseau RMEC comprend deux entités MEC et MEC2. Par exemple, l’entité MEC1 correspond à une architecture MEC d’un premier domaine, c’est-à-dire connectée à un premier réseau R, et qui est interfacée avec une architecture d’un deuxième domaine, c’est-à-dire connectée à un deuxième réseau R2, ce deuxième domaine étant distinct et éventuellement éloigné du premier domaine.
[0098] L’entité MEC1 comprend des éléments identiques à ceux décrits dans la figure précédente. L’architecture MEC correspondante comprend en outre un module de services MECS connecté au gestionnaire MEPM ainsi qu’à un premier espace industriel de données IDS-A. Le plan de données DP que comprend cette architecture MEC est connecté au premier réseau R, qui est par exemple un réseau en nuage d’une première usine du premier domaine. [0099] L’autre entité MEC2 comprend des éléments analogues à ceux de l’entité MEC1 , et notamment, un module hôte MECH2 comportant un module plateforme MEP2, au moins une application MEA2 et un plan de données DP2 connecté au deuxième réseau R2, par exemple un réseau en nuage d’une deuxième usine qui est éloignée de la première usine.
[0100] Ces entités sont connectées entre elles via des points Mp1 ’, Mp2’ et Mp3’ semblables aux points Mp1 , Mp2 et Mp3 précédemment décrits.
[0101] L’entité MEC2 comprend en outre un gestionnaire MEPM2 connecté à un autre module de services MECS2, lui-même connecté au gestionnaire MEPM2 ainsi qu’à un deuxième espace industriel de données IDS-B.
[0102] Dans l’exemple représenté ici, le plan de données DP est utilisé pour commander un robot via le réseau R de la première usine, tandis que le plan de données DP2 est utilisé pour commander un autre robot via le réseau R2 de la deuxième usine.
[0103] En général, des robots de même type ou d’un même constructeur sont configurés de sorte qu’un même système cyber-physique peut être utilisé pour piloter ces robots en vue d’effectuer une tâche. En particulier, deux robots connectés à deux réseaux R et R2 distincts sont pilotables à distance par des donneurs d’ordre différents, ici par les deux espaces industriels de données IDS-A et IDS-B disposant du même système cyber-physique.
[0104] Le pilotage d’un robot via un réseau donné peut nécessiter des ressources absentes de l’architecture MEC connectée à ce réseau. Par exemple, un donneur d’ordre correspondant à l’espace industriel IDS-A ne pourra pas piloter un robot connecté au réseau R2 si ce pilotage nécessite une application présente dans MEA, mais absente de MEA2.
[0105] Par exemple, le site industriel du premier domaine ne dispose pas nécessairement des applications nécessaires pour effectuer un pilotage d’un robot sur le site industriel du deuxième domaine, même si le premier domaine comprend un robot similaire ou identique.
[0106] Pour échanger des informations, les entités MEC1 et MEC2 disposent d’interfaces inter-domaines. Il est décrit dans la suite comment améliorer leurs architectures correspondantes et les procédés associés pour permettre la transmission et l’exécution de ces applications.
[0107] Une interface entre les deux entités MEC1 et MEC2 est par exemple possible au moyen du point de référence Mp3 pour permettre à le module plateforme MEP de communiquer avec d’autres plates-formes, et notamment avec le module plateforme MEP2 du module hôte MECH2 que comprend la deuxième architecture MEC2.
[0108] Comme illustré, cette interface et cette communication se fait via le point de référence Mp3, qui connecte les modules plateforme MEP et MEP2. Le point de référence Mp3 est représenté comme appartenant à l’entité MEC1 , mais celui-ci est équivalent au point de référence Mp3’ correspondant dans l’autre entité MEC2.
[0109] Comme décrit précédemment, l’interface réalisée au moyen du point intermédiaire Mp3 entre les entités MEC1 et MEC2 ne permet pas à elle seule de partager ou de transmettre une application exécutable d’une architecture MEC à une autre.
[0110] Par exemple, bien que le point de référence Mp3 permettant une interface entre deux architectures MEC rende possible un provisionnement d’une application de pilotage d’un robot d’une architecture à une autre, Mp3 ne permet pas à lui seul une exécution à distance d’une commande de pilotage de ce robot.
[0111] Une solution fournie par les présentes réalisations prévoit de créer une nouvelle interface.
[0112] Il est maintenant fait référence à la figure 3, qui représente une vue schématique de connexions entre deux entités, et plus précisément entre deux entités MEC1 et MEC2.
[0113] Un module MEPROXY est présent dans l’entité MEC2. Ce module est soit situé à l’extérieur du module plateforme MEP2 et relié à celle-ci et/ou au gestionnaire MEPM2, par exemple au moyen d’une connexion dans l’entité MEC2, soit installé directement dans le module plateforme MEP2.
[0114] Selon différentes variantes pouvant être combinées entre elles, au moins une interface entre les deux entités MEC1 et MEC2 est mise en œuvre au moyen de points de référence dits points de référence intermédiaires, pour permettre un échange applicatif inter-domaine.
[0115] Dans une première de ces variantes, une interface est définie par un point de référence intermédiaire Mpld relie les gestionnaires MEPM et MEPM2 des deux architectures. Le point de référence intermédiaire Mpld permet ainsi une communication directe ou indirecte entre les deux entités MEC1 et MEC2. Le point Mpid peut par exemple être situé dans un niveau hôte HL de la première architecture MEC ou de la deuxième architecture MEC qui correspondent aux entités.
[0116] Dans une deuxième de ces variantes, une interface est définie par un autre point de référence intermédiaire Mpl ld qui relie le module plateforme MEP de l’entité MEC1 au module MEPROXY de l’autre entité MEC2.
[0117] Dans une troisième de ces variantes, une interface est définie par encore un autre point de référence intermédiaire Mpld’ relie le gestionnaire MEPM de l’entité MEC1 au module MEPROXY de l’autre entité MEC2.
[0118] De manière générale, une interface directe ou indirecte peut être mise en œuvre entre au moins trois architectures MEC au moyen de points de référence semblables à ceux précédemment décrits.
[0119] Il est maintenant fait référence à la figure 4, qui représente sous forme d’organigramme des étapes d’un procédé de commande d’un réseau informatique de périphérie à accès multiple selon une réalisation.
[0120] Une première étape S1 concerne la localisation du module MEPROXY au sein de l’entité MEC2. Par exemple, cette localisation est mise en œuvre au moins par l’échange d’une paire requête-réponse de localisation échangée entre deux entités MEC1 et MEC2 avec pour résultat de fournir la position du module au sein de MEC2, par exemple en renseignant son adresse IP.
[0121] Une deuxième étape S2, qui suit l’étape S1 , concerne l’installation d’une fonction mandataire FPROXY dans au moins un module dont la localisation est connue. Par exemple, cette installation comprend un échange d’une paire requête- réponse d’installation de la fonction FPROXY. Par exemple, ladite paire requête- réponse d’installation est échangée entre le module MPEROXY localisé lors de l’étape S1 et au moins une application MEA2. [0122] Une troisième étape S3, qui suit l’étape S2, concerne la commande d’une opération du réseau, en particulier d’une exécution d’une application de service. Par exemple, cette commande comprend un échange d’une paire requête-réponse de commande, ladite paire requête-réponse de commande étant échangée entre la première architecture MEC et le module MEPROXY qui comprend la fonction FPROXY installée au cours de l’étape S2.
[0123] Il est maintenant fait référence à la figure 5, qui représente sous forme de diagramme de flux d’étapes S10, S20, S30, S40, S50, S60, S70, S80, S90 et S100 d’un procédé de commande d’un réseau informatique de périphérie selon une autre réalisation.
[0124] Ces flux peuvent être des flux de données et/ou des flux de contrôle, aussi dits flux de commande. La transmission ou l’échange de flux de commande est rendue possible grâce aux réalisations décrites dans les présentes.
[0125] Comme illustré, le module MEPROXY et la fonction mandataire FPROXY sont représentés comme étant distincts et séparés du module plateforme MEP2. Cependant, ceci n’exclut pas que le module MEPROXY et la fonction mandataire FPROXY soient installés dans le module plateforme MEP2.
[0126] En lien avec les étapes décrites précédemment, l’étape S1 de localisation comprend les étapes S10 et S20, l’étape S2 d’installation comprend les étapes S30, S40, S50 et S60 et l’étape S3 de commande d’une opération du réseau, en particulier d’une exécution d’une application de service, comprend les étapes S70, S80, S90 et S100.
[0127] Comme illustré, lors de l’étape S10, le gestionnaire MEPM de l’entité MEC1 transmet une requête de localisation RQ-LOC vers le gestionnaire MEPM2 de l’entité MEC2. Ceci permet de requérir l’adresse du module MEPROXY. La requête de localisation RQ-LOC est transmise de préférence via le point de référence intermédiaire Mpld.
[0128] Lors de l’étape S20, sur réception de la requête RQ-LOC, un message d’acquittement de localisation ACK-LOC est renvoyé depuis le gestionnaire MEPM2 à destination du gestionnaire MEPM. Ce message d’acquittement permet de renseigner la localisation du module MEPROXY à l’entité MEC1. Le message d’acquittement ACK-LOC est, de préférence, lui aussi transmis via le point de référence intermédiaire Mpld.
[0129] L’accusé de réception ACK-LOC comprend une adresse IP du module MEPROXY localisé, par exemple l’adresse IP du serveur hébergeant celui-ci. Selon un autre exemple, et renseignée par le gestionnaire MEPM2.
[0130] Une fois l’adresse du module MEPROXY renseignée au gestionnaire MEPM de l’entité MEC1 , le gestionnaire MEPM initie l’installation d’une ou de plusieurs applications dans l’entité MEC2, via la point de référence Mp1 , le point de référence Mp3 ou encore le point de référence intermédiaire Mpld. Cette installation est mise en œuvre au cours des étapes S30 à S60, afin de préparer l’installation de la fonction mandataire FPROXY dans le module MEPROXY.
[0131] L’étape S30 comprend la transmission d’une requête de téléchargement RQ-UP depuis le gestionnaire MEPM vers MEC2, en particulier vers le module MEPROXY de MEC2.
[0132] Selon différents exemples, la requête de téléchargement RQ-UP peut être transmise depuis un point central intégré à l’architecture MEC correspondant à MEC1 ou depuis un autre point tel qu’un serveur ou de tout autre type de dispositif relié à MEC1 .
[0133] De préférence, l’étape S30 est mise en œuvre sur réception du message d’acquittement de localisation ACK-LOC, sur réception d’une information de localisation du module MEPROXY ou encore d’une instruction d’installation d’une application ou d’une fonction dans le module MEPROXY si la localisation de celui- ci est renseignée dans l’instruction d’installation.
[0134] En pratique, et par exemple, l’installation de la fonction mandataire FPROXY est mise en œuvre par un donneur d’ordre associé à l’entité MEC1 , par exemple par un donneur d’ordre ayant accès à l’espace industriel de données IDS-A. Une installation ou une mise à jour de cette fonction peut être mise en œuvre au moyen d’un orchestrateur MEO ou d’un système OSS de l’une ou l’autre des entités MEC1 et MEC2. [0135] Lors de l’étape S40, le module MEPROXY transmet une requête d’installation RQ-INST vers au moins une application MEA2 que comprend l’entité MEC2. Cette requête est de préférence transmise via le point Mp1 ’.
[0136] Selon différents exemples, le module MEPROXY et/ou la fonction FPROXY sont instanciés. Par exemple, le ou les systèmes OSS que comprennent les entités MEC1 et MEC2 sont connectés à la plateforme MEPM, et en outre configurés pour déclencher l'instanciation ou la fermeture de la fonction FPROXY.
[0137] Sur réception de la requête d’installation RQ-INST, la fonction mandataire FPROXY est installée dans la deuxième entité MEC2 lors de l’étape S40. Cette installation est mise en œuvre par au moins une application de périphérie MEA2. De préférence, la fonction FPROXY est installée directement dans le module MEPROXY.
[0138] Toujours sur réception de la requête d’installation RQ-INST, et faisant suite à l’installation de la fonction FPROXY, un message d’acquittement d’installation ACK-INST est envoyé lors de l’étape S50 par la deuxième entité MEC2 vers la première entité MEC1 . En particulier, le message d’acquittement d’installation ACK- INST est transmis par le module MEPROXY vers le gestionnaire MEPM de l’architecture MEC.
[0139] De préférence, le message d’acquittement d’installation ACK-INST est transmis via le point de référence MpT.
[0140] Sur réception du message d’acquittement d’installation ACK-INST, et lors de l’étape S50, un message d’acquittement de téléchargement ACK-UP est transmis par le module MEPROXY vers le gestionnaire MEPM.
[0141] De préférence, le message d’acquittement d’installation ACK-INST est transmis via le point de référence intermédiaire Mpld’.
[0142] Selon un autre exemple non représenté, le message d’acquittement de téléchargement ACK-UP peut être transmis lors de l’étape S50 et plus généralement sur réception de la requête de téléchargement RQ-UP, lorsque celle- ci permet de procéder directement à l’installation de la fonction FPROXY dans le module MEPROXY. [0143] Le message d’acquittement d’installation ACK-INST permet d’indiquer au gestionnaire MEPM, et donc à l’entité MEC1 , que l’installation de la fonction mandataire FPROXY est bien complétée.
[0144] Une fois l’installation de la fonction mandataire FPROXY terminée, le module plateforme MEP initie la commande d’une exécution d’une application de service au moyen de la fonction mandataire installée.
[0145] En particulier, cette commande comprend plusieurs étapes S70 à S100 permettant de garantir que la commande est initiée par un donneur d’ordre externe à l’entité MEC2, par exemple un donneur d’ordre ayant accès à l’espace industriel de données IDS-A plutôt qu’à l’espace industriel de données IDS-B.
[0146] Pour ce faire, une étape S70 est mise en œuvre et comprend la transmission d’une requête de commande RQ-CTRL depuis le module plateforme MEP vers l’entité MEC2, et en particulier vers le module MEPROXY que comprend MEC2.
[0147] Par exemple, cette requête peut correspondre à une demande provenant d’un donneur d’ordre associé à l’espace industriel de données IDS-A connecté à l’entité MEC1 , afin de pouvoir exécuter une application dans l’entité MEC2.
[0148] Ainsi, si le gestionnaire MEPM2 est initialement configuré pour n’exécuter une application que sur la base de commandes provenant d’un donneur d’ordre associé à l’espace industriel de données IDS-B, l’installation de la fonction FPROXY dans le module MEPROXY permet de déléguer cette exécution au donneur d’ordre associé à l’espace industriel de données IDS-A.
[0149] De préférence, l’étape S70 est mise en œuvre sur réception du message d’acquittement de localisation ACK-UP, ou plus généralement sur réception d’une confirmation selon laquelle la fonction FPROXY est bien téléchargée et/ou installée dans le module MEPROXY.
[0150] Sur réception de la requête de commande RQ-CTRL, une mise en cache d’une application présente dans MEA2 est effectuée. Par « mise en cache » on entend ici que l’exécution de cette application, initialement permise à un premier donneur d’ordre, par exemple un donneur d’ordre associé à l’espace industriel de données IDS-A, est déléguée à un deuxième donneur d’ordre, par exemple un autre donneur d’ordre qui, lui, est associé à l’espace industriel de données IDS-B plutôt qu’à IDS-A.
[0151] En particulier, l’étape S80 met en œuvre cette mise en cache sur réception, par MEA2, d’une requête de mise en cache RQ-PROXY, cette requête de mise en cache étant transmise par le module MEPROXY, de préférence par l’intermédiaire du point Mp1 ’.
[0152] Lorsque la délégation de l’application est appliquée de sorte que son exécution soit désormais permise par le deuxième donneur d’ordre au lieu du premier donneur d’ordre uniquement, un message d’acquittement de mise en cache ACK-PROXY est transmis par MEA2 vers le module MEPROXY, afin de confirmer que la délégation de l’exécution de l’application concernée est bien effective.
[0153] Sur réception du message d’acquittement de mise en cache ACK-PROXY, et faisant suite à la délégation de l’exécution de l’application, un message d’acquittement de commande ACK-CTRL est envoyé lors de l’étape S100 par l’entité MEC2 vers l’entité MEC1. En particulier, le message d’acquittement de commande ACK-CTRL est émis par le module MEPROXY depuis l’entité MEC2 vers le module plateforme MEP de l’entité MEC1 .
[0154] Ce message d’acquittement de commande ACK-CTRL permet d’indiquer à l’entité MEC1 qu’une exécution d’une application de service peut être commandée au moyen de la fonction mandataire installée.
[0155] Lors de l’étape S100 ou lors d’une ou plusieurs étapes ultérieures à l’étape S100, une commande d’une exécution d’une ou de plusieurs applications de service au moyen de la fonction mandataire installée dans MEPROXY. Une telle commande comprend par exemple l’exécution d’une application permettant le contrôle d’un dispositif connecté, le pilotage d’un robot, la coordination d’un mouvement entre plusieurs machines-outils, ou encore la transmission d’informations ou de signaux vers un opérateur.
[0156] A titre illustratif, un espace industriel de données IDS-A est initialement client des services fournis par une architecture MEC appartenant à un premier domaine, ce client souhaitant se voir permettre l’utilisation d’un robot connecté dans un deuxième domaine associé à une autre architecture MEC. [0157] Pratiquement, en un premier instant t1 , le robot effectue des tâches pour un espace industriel de données IDS-B client des services fournis par l’entité MEC2. En un deuxième instant t2, la mise en œuvre des étapes S1 à S3 permet de mettre à disposition, via le premier domaine, depuis l’espace industriel de données IDS-A, une ou plusieurs ressources utilisables par celui-ci. Le premier domaine se charge ainsi d’exécuter une tâche qu’il ne pouvait pas exécuter initialement.
[0158] L’entité MEC1 est ainsi capable d’aller chercher des ressources ou des services pour le compte d’IDS-A dans un autre domaine.
[0159] En outre, chacun des domaines peut également exposer ou partager ses ressources de manière indépendante, de manière à les rendre disponibles à plusieurs autres domaines.
[0160] La figure 6 représente un bloc-diagramme schématique d'un circuit de traitement informatique selon un exemple de mise en œuvre des réalisations décrites.
[0161] Selon un exemple, ledit circuit de traitement informatique est un processeur. De préférence, un tel circuit de traitement informatique est un système sur puce 1000 agencé pour mettre en œuvre un procédé de commande d’un réseau informatique de périphérie. En particulier, ce circuit de traitement informatique peut correspondre à un élément matériel définissant le module MEPROXY, un module plateforme MEP ou encore un gestionnaire MEPM.
[0162] De manière non limitative, le système sur puce 1000 comporte un bus de communication connecté, par exemple, à une unité centrale de traitement 1010, tel qu'un processeur ou un microprocesseur, et notée CPU.
[0163] Le système sur puce 1000 comporte en outre une mémoire à accès aléatoire 1020, notée RAM, apte à mémoriser le code exécutable du procédé de commande ainsi que les registres adaptés à enregistrer des variables et des paramètres nécessaires pour la mise en œuvre du procédé selon des modes de réalisation, la capacité de mémoire de celui-ci peut être complétée par une mémoire RAM optionnelle connectée à un port d'extension, par exemple.
[0164] En outre, le système sur puce 1000 comporte une mémoire morte 1030, notée ROM, pour stocker des programmes informatiques pour la mise en œuvre des réalisations décrites précédemment, ainsi qu’une interface réseau 1040 qui est normalement connectée à un réseau de communication sur lequel des données numériques à traiter sont transmises ou reçues.
[0165] L'interface réseau 1040 peut être une seule interface réseau, ou composée d'un ensemble d'interfaces réseau différentes (par exemple filaire et sans fil, interfaces ou différents types d'interfaces filaires ou sans fil).
[0166] Des paquets de données sont envoyés sur l'interface réseau pour la transmission ou sont lues à partir de l'interface de réseau pour la réception sous le contrôle de l'application logiciel exécuté dans le processeur ou le microprocesseur 1010.
[0167] Par ailleurs, le système sur puce 1000 comporte une interface utilisateur 1050 pour recevoir des entrées d'un utilisateur ou pour afficher des informations à un utilisateur, un support de stockage optionnel 1060 noté HD, et un module d’entrée-sortie 1070, noté IO, pour la réception, l'envoi de données depuis ou vers des périphériques externes tels que disque dur, support de stockage amovible ou autres.
[0168] Dans un exemple présenté ici, le code exécutable peut être stocké dans une mémoire morte 1030, sur le support de stockage 1060 ou sur un support amovible numérique tel que par exemple un disque.
[0169] Selon une variante, le code exécutable des programmes peuvent être reçu au moyen d'un réseau de communication, via l'interface réseau 1040, afin d'être stocké dans le support de stockage 1060, avant d'être exécuté.
[0170] L'unité centrale de traitement 1010 est adaptée pour commander et diriger l'exécution des instructions ou des portions de code logiciel du programme ou des programmes selon l'un des modes de réalisation, instructions qui sont stockées dans l'un des moyens de stockage précités. Après la mise sous tension, le CPU 1010 est capable d'exécuter des instructions stockées dans la mémoire RAM principale 1020, relatives à une application logicielle, après que ces instructions aient été chargées de la ROM par exemple.
[0171] Dans l’exemple présenté ici, le système sur puce 1000 est un appareil programmable qui utilise un logiciel. Toutefois, à titre subsidiaire, la présente description peut être mise en œuvre dans n’importe quel type de matériel (par exemple, sous la forme d'un circuit intégré spécifique ou ASIC).

Claims

Revendications
[Revendication 1] Procédé de commande d’une application de service dans un réseau informatique de périphérie à accès multiple (RMEC), le réseau comprenant une pluralité d’entités (MEC1 , MEC2) connectées entre elles, le procédé comportant:
- commander (S3 ; S70, S80, S90, S100), par un module plateforme (MEP) que comprend une première entité (MEC1 ) de ladite pluralité, une exécution d’une application de service installée dans une deuxième entité (MEC2) de la pluralité par l’intermédiaire d’une fonction mandataire (FPROXY) comprise dans ladite deuxième entité, la deuxième entité étant distincte de la première entité, la première entité (MEC1 ) et la deuxième entité (MEC2) étant des architectures MEC.
[Revendication 2] Procédé selon la revendication 1 , comportant en outre:
- localiser (S1 ; S10, S20) un module (MEPROXY) parmi une pluralité de modules que comprend la deuxième entité (MEC2) ; et
- installer (S2 ; S30, S40, S50, S60) la fonction mandataire (FPROXY) dans le module localisé.
[Revendication 2] Procédé selon la revendication 2, comportant en outre :
- analyser une topologie du réseau pour identifier une présence d’un module courant dans une plateforme de périphérie à accès multiple du réseau, en vue de la localisation du module ; et
- sélectionner ledit module courant en tant que module localisé, en vue de l’installation de la fonction mandataire.
[Revendication 3] Procédé selon l’une quelconque des revendications 2 à 3, dans lequel la fonction mandataire (FPROXY) installée est configurée pour déléguer la commande de l’exécution de l’application de service à la deuxième entité (MEC2).
[Revendication 4] Procédé selon l’une quelconque des revendications 2 à 4, dans lequel la localisation du module est mise en œuvre sur réception (S20), par la première entité (MEC1 ), d’une réponse de localisation (ACK-LOC) à une requête de localisation correspondante (RQ-LOC).
[Revendication 5] Procédé selon l’une quelconque des revendications 2 à 5, dans lequel l’installation de la fonction mandataire est mise en œuvre sur réception (S30), par le module localisé, d’une requête de téléchargement (RQ-UP) de ladite fonction mandataire.
[Revendication 6] Procédé selon l’une quelconque des revendications 2 à 6, dans lequel la fonction mandataire (FPROXY) est installée via une application de périphérie à accès multiple (MEA2) de la deuxième entité (MEC2) sur réception (S40), par ladite application, d’une requête d’installation (RQ-INST).
[Revendication 7] Procédé selon l’une quelconque des revendications 2 à 7, dans lequel la commande de l’exécution de l’application de service est mise en œuvre sur réception (S70), par la deuxième entité (MEC2), d’une requête de commande (RQ-CTRL).
[Revendication 8] Procédé selon l’une quelconque des revendications 2 à 8, dans lequel une délégation de la commande de l’exécution de l’application de service est mise en œuvre sur réception (S90) d’une requête de représentation (RQ-PROXY) de la deuxième entité (MEC2) par la première entité (MEC1 ).
[Revendication 9] Procédé selon l’une quelconque des revendications 8 à 9, dans lequel la commande de l’exécution de l’application de service comporte en outre une émission (S100), par le module localisé et à destination de la première entité (MEC1 ), d’une réponse de commande (ACK-CTRL) à la requête de commande (RQ-CTRL).
[Revendication 10] Procédé selon l’une quelconque des revendications 5 à 10, dans lequel au moins une requête ou au moins une réponse à une requête est transmise via un point intermédiaire de référence (Mpid, Mplid) connectant la première entité (MEC1) et la deuxième entité (MEC2).
[Revendication 11] Programme informatique comportant des instructions pour la mise en œuvre du procédé selon l’une des revendications 1 à 11, lorsque lesdites instructions sont exécutées par un processeur d’un circuit de traitement informatique.
[Revendication 12] Support de stockage d'informations, amovible ou non, partiellement ou totalement lisible par un ordinateur ou un processeur comportant des instructions de code d'un programme d'ordinateur pour l'exécution de chacune des étapes du procédé selon l'une quelconque des revendications 1 à 11.
EP20817450.8A 2019-11-12 2020-11-03 Procédés de commande d'un réseau informatique de périphérie a accès multiple Pending EP4058892A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR1912611A FR3103042A1 (fr) 2019-11-12 2019-11-12 Procédés de commande d’un réseau informatique de périphérie à accès multiple
PCT/FR2020/051979 WO2021094668A1 (fr) 2019-11-12 2020-11-03 Procédés de commande d'un réseau informatique de périphérie a accès multiple

Publications (1)

Publication Number Publication Date
EP4058892A1 true EP4058892A1 (fr) 2022-09-21

Family

ID=69700050

Family Applications (1)

Application Number Title Priority Date Filing Date
EP20817450.8A Pending EP4058892A1 (fr) 2019-11-12 2020-11-03 Procédés de commande d'un réseau informatique de périphérie a accès multiple

Country Status (4)

Country Link
US (1) US11924300B2 (fr)
EP (1) EP4058892A1 (fr)
FR (1) FR3103042A1 (fr)
WO (1) WO2021094668A1 (fr)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FR3103042A1 (fr) * 2019-11-12 2021-05-14 Orange Procédés de commande d’un réseau informatique de périphérie à accès multiple

Family Cites Families (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2015001784A (ja) * 2013-06-13 2015-01-05 富士通株式会社 情報処理システム、情報処理装置、及び情報処理プログラム
US10411964B2 (en) * 2016-09-09 2019-09-10 Huawei Technologies Co., Ltd. Method and apparatus for network slicing
US10536515B2 (en) * 2016-12-23 2020-01-14 Kausik Majumdar Method and program product for robot communications
US10440096B2 (en) * 2016-12-28 2019-10-08 Intel IP Corporation Application computation offloading for mobile edge computing
US10333985B2 (en) * 2017-01-09 2019-06-25 Microsoft Technology Licensing, Llc Distribution and management of services in virtual environments
US10848974B2 (en) * 2018-12-28 2020-11-24 Intel Corporation Multi-domain trust establishment in edge cloud architectures
US11469954B2 (en) * 2019-05-16 2022-10-11 Verizon Patent And Licensing Inc. System and methods for service policy optimization for multi-access edge computing services
FR3103042A1 (fr) * 2019-11-12 2021-05-14 Orange Procédés de commande d’un réseau informatique de périphérie à accès multiple
FR3108754B1 (fr) * 2020-03-24 2022-12-30 Orange Procédé de délégation entre réseaux informatiques de périphérie à accès multiple
US12113853B2 (en) * 2020-09-25 2024-10-08 Intel Corporation Methods and apparatus to manage quality of service with respect to service level agreements in a computing device
US20220116445A1 (en) * 2021-04-12 2022-04-14 Miltiadis Filippou Disintermediated attestation in a mec service mesh framework
US11889593B2 (en) * 2021-07-16 2024-01-30 T-Mobile Innovations Llc Wireless communication service over an edge data network (EDN) between a user equipment (UE) and an application server (AS)

Also Published As

Publication number Publication date
US20220407938A1 (en) 2022-12-22
FR3103042A1 (fr) 2021-05-14
WO2021094668A1 (fr) 2021-05-20
US11924300B2 (en) 2024-03-05

Similar Documents

Publication Publication Date Title
US11184438B2 (en) Omnichannel approach to application sharing across different devices
US20250156915A1 (en) Partitioned private interconnects to provider networks
US9954763B1 (en) Pre-configured virtual gateways for isolated virtual networks
US20170083354A1 (en) Connection-based resource management for virtual desktop instances
US12354357B2 (en) Telecommunication network monitoring
JP2023523523A (ja) 複数のキャリアの近隣のｍｅｃホスト間での地理的に集中したワークロードの共有
US12074918B2 (en) Network-based Media Processing (NBMP) workflow management through 5G Framework for Live Uplink Streaming (FLUS) control
US11689636B2 (en) Delegating network data exchange
US20230300069A1 (en) System and Method for IOT Systems of Logic Across a Continuum of Computers
US20110238582A1 (en) Service Method For Customer Self-Service And Rapid On-Boarding For Remote Information Technology Infrastructure Monitoring And Management
EP4058892A1 (fr) Procédés de commande d'un réseau informatique de périphérie a accès multiple
WO2021191535A1 (fr) Procede de delegation entre reseaux informatiques de peripherie a acces multiples
US12598454B2 (en) Dynamic configuration of an electronic subscriber identification module in a virtual reality environment
JP7658693B2 (ja) モバイルｋｕｂｅ－ｅｄｇｅ自動構成
JP7321368B2 (ja) 第３世代パートナーシッププロジェクト（３ｇｐｐ）ライブアップリンクストリーミングのためのフレームワーク（ｆｌｕｓ）シンク機能を決定するための方法、コンピュータシステムおよびコンピュータプログラム
WO2023281181A1 (fr) Procede et dispositif de configuration d'une unite d'acces dans un environnement virtualise
CN110870275A (zh) 共享存储器文件传输
JP2023502375A (ja) 統合システム内のアプリケーション・フローとの通信
JP7807144B2 (ja) 拡張された第３世代パートナーシッププロジェクト（３ｇｐｐ（登録商標））のライブアップリンクストリーミング伝送のためのフレームワーク（ｆｌｕｓ）のシンク機能説明
Davoli 5G Management and Orchestration–From Cloud-Native to 5G-Ready Applications
HK40072098A (en) Network-based media processing (nbmp) workflow management through 5g framework for live uplink streaming (flus) control

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: 20220609

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

DAV Request for validation of the european patent (deleted)
DAX Request for extension of the european patent (deleted)
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: 20250814