FR3139687A1 - METHOD FOR ORCHESTRATING SOFTWARE APPLICATIONS IN A TELECOMMUNICATION SYSTEM, COMPUTER PROGRAM AND ASSOCIATED ORCHESTRATION DEVICE - Google Patents

Abstract

The invention relates to a method for orchestrating software applications, distributed telecommunications platforms (20), connected to links (40, 41) of a wireless telecommunications network comprising processing resources (6), said method comprising selecting at least one platform for execution of said software application via a processing resource of the selected platform, said selection being made based on the collected availability states of the processing resources, memory characteristics and calculation required for the execution of said application, current transport conditions on said wireless telecommunications network and a transport template relating to said software application indicating minimum transport conditions required for the implementation of telecommunications with said software application during its execution, said transport conditions indicating at least one piece of information associated with the links among available bandwidths, jitters, latencies, error rates, nominal bandwidths and occupancy rates. Figure for abstract: Fig. 1

Description

METHOD FOR ORCHESTRATING SOFTWARE APPLICATIONS IN A TELECOMMUNICATION SYSTEM, COMPUTER PROGRAM AND ASSOCIATED ORCHESTRATION DEVICE

The invention lies in the field of software application orchestration, in which hardware resources, including CPUs and memories, in delocalized and distributed servers are selected to host the execution of a software application.

Currently, civil cloud orchestration solutions evaluate the suitability of a server for hosting software based on the available CPU resource or the amount of memory available on that server versus the software's CPU and memory requirements.

If these solutions are entirely effective on gigabit telecommunications networks based on optical fibers, they prove insufficient on constrained telecommunications networks and can even contribute to congestion in these networks.

The term “constrained telecommunications network” means a telecommunications network in which the telecommunications capacity is limited (compared to gigabit networks) and not very stable, such as, for example, tactical telecommunications networks deployed locally and occasionally in an area of intervention. health or military (a disaster zone, geological or other, a conflict zone, etc.). Transmission links are frequently broken without notice (for example by intentional or unintentional jamming), some are very limited in terms of bandwidth or experience occurrences, much more frequent than in traditional consumer networks, of variations in bandwidth. or latency. However, it is necessary in these interventions to be able to run software applications reliably, particularly in servers embedded in carrier vehicles moving in, on or near the intervention zone.

There is therefore a need to have a software application orchestration solution that can be implemented satisfactorily on any type of telecommunications network, including constrained ones.

• collecte d’états des ressources de traitement, lesdits états indiquant la disponibilité courante desdites ressources ;
• réception de requêtes indiquant des applications logicielles à exécuter et, pour chaque application logicielle indiquée dans une requête reçue, obtention des caractéristiques de mémoire et de calcul requises pour l’exécution de ladite application ;
• pour chaque application logicielle : sélection, parmi les plateformes, d’au moins une plateforme pour l’exécution de ladite application logicielle via une ressource de traitement de la plateforme sélectionnée, ladite sélection étant effectuée en fonction d’au moins:

les états de disponibilité collectés des ressources de traitement ; et
les caractéristiques obtenues de mémoire et de calcul requises pour l’exécution de ladite application; et

• affectation d’au moins ladite plateforme sélectionnée pour l’exécution de ladite application logicielle ;

ledit procédé étant caractérisé en ce qu’il comprend en outre les étapes suivantes mises en œuvre par le dispositif d’orchestration :

• collecte de conditions courantes de transport sur ledit réseau de télécommunication sans fil, lesdites conditions de transport indiquant au moins une information associée aux liaisons parmi leur bande passante disponible, leur gigue, leur latence, leur taux d’erreur, leur bande passante nominale et leur taux d’occupation ;
• pour chaque application logicielle indiquée dans une requête reçue, obtention en outre de gabarit(s) de transport indiquant des conditions de transport minimales requises pour la mise en œuvre de télécommunications avec ladite application logicielle pendant son exécution ;
• ladite sélection de la plateforme est effectuée en outre en fonction des conditions de transport collectées et desdits gabarit(s) de transport obtenus.

To this end, according to a first aspect, the present invention describes a method for orchestrating software applications in a telecommunications system comprising an electronic orchestration device, distributed telecommunications platforms (20), connected to communication links. a wireless telecommunications network and each comprising processing resources among memory resources and calculation resources, said method comprising the following steps implemented by the orchestration device:

• collection of states of processing resources, said states indicating the current availability of said resources;
• receiving requests indicating software applications to be executed and, for each software application indicated in a received request, obtaining the memory and computing characteristics required for execution of said application;
• for each software application: selection, among the platforms, of at least one platform for the execution of said software application via a processing resource of the selected platform, said selection being made according to at least:

collected availability states of processing resources; And
the obtained memory and calculation characteristics required for the execution of said application; And

• allocation of at least said selected platform for the execution of said software application;

said method being characterized in that it further comprises the following steps implemented by the orchestration device:

• collection of current transport conditions on said wireless telecommunications network, said transport conditions indicating at least one piece of information associated with the links among their available bandwidth, their jitter, their latency, their error rate, their nominal bandwidth and their occupancy rate ;
• for each software application indicated in a received request, further obtaining transport template(s) indicating minimum transport conditions required for implementing telecommunications with said software application during its execution;
• said selection of the platform is further carried out based on the transport conditions collected and said transport template(s) obtained.

In embodiments, such a method will also include at least one of the following characteristics:

- said received request relating to said software application further indicates deployment requirements for the installation of said software application; and said processing resource selection is further performed based on said deployment requirements for the installation of said software application;

- in a tree structure, two software applications are connected by a branch of said structure if they have been defined to implement telecommunications between them during their execution and each branch is associated with transport templates required specifically for said telecommunications and according to which:
the selection of at least one platform for the execution of a software application, when it is part of said tree structure further comprises at least the selection of a platform for the execution of another application of said tree structure , said platforms having to be a single platform, according to a rule relating to the transport templates on the branches connecting them, if this reduces the need for exchanges of the selected platform with the other platforms;

- following said selection, a reservation of transport resources is triggered on at least one link of the wireless telecommunications network according to said transport template(s) and current transport conditions, for the implementation of telecommunications with said software application during its execution;

- said transport templates for implementing telecommunications with said software application during its execution comprise a first transport template corresponding to a nominal operating mode of the software application and a second transport template, less demanding than the first template transport, corresponding to a degraded operating mode of the software application; said selection of processing resource being carried out according to said first and second transport templates as obtained.

According to another aspect, the invention describes a computer program intended to be stored in the memory of an electronic orchestration device further comprising a microcomputer, said computer program comprising instructions which, when executed on the microcomputer, implement the steps of a method according to the first aspect of the invention.

According to another aspect, the invention describes an electronic device for orchestrating software applications for a telecommunications system comprising distributed telecommunications platforms, connected to links of a wireless telecommunications network and each comprising processing resources among memory resources and calculation resources, said orchestration device being adapted to collect states of the processing resources, said states indicating the current availability of said resources, to receive requests indicating software applications to be executed and, for each software application indicated in a received request, to obtain memory and calculation characteristics required for the execution of said application;
for each software application, said orchestration device being adapted for:
- select from among the platforms, at least one platform for the execution of said software application via a processing resource of the selected platform, said selection being made according to at least:
collected availability states of processing resources; And
the obtained memory and calculation characteristics required for the execution of said application; And
- to affect at least said selected platform for the execution of said software application;
said orchestration device being characterized in that it is adapted for:
- collect current transport conditions on said wireless telecommunications network, said transport conditions indicating at least one piece of information associated with the links among their available bandwidth, their jitter, their latency, their error rate, their nominal bandwidth and their occupancy rate;
- for each software application indicated in a received request, further obtain transport template(s) indicating minimum transport conditions required for the implementation of telecommunications with said software application during its execution;
said selection of the platform being further carried out according to the transport conditions collected and said transport template(s) obtained.

In embodiments, such a device will also include at least one of the following characteristics:

- said received request relating to said software application further indicates deployment requirements for the installation of said software application; and said processing resource selection is further performed based on said deployment requirements for the installation of said software application;

- in a tree structure, two software applications are connected by a branch of said structure if they have been defined to implement telecommunications between them during their execution and each branch is associated with transport templates required specifically for said telecommunications and according to which:
the selection of at least one platform for the execution of a software application, when it is part of said tree structure further comprises at least the selection of a platform for the execution of another application of said tree structure , said platforms having to be a single platform, according to a rule relating to the transport templates on the branches connecting them, if this reduces the need for exchanges of the selected platform with the other platforms;

- the device is adapted to, following said selection, trigger a reservation of transport resources on at least one link of the wireless telecommunications network according to said transport template(s) and the current transport conditions, for the implementation telecommunications work with said software application during its execution.

The invention will be better understood and other characteristics, details and advantages will appear better on reading the description which follows, given on a non-limiting basis, and thanks to the appended figures, given by way of example.

There is an illustration of a telecommunications system 1 in one embodiment of the invention;

There represents steps of a resource allocation method in one embodiment of the invention;

There represents steps of a resource allocation method in another embodiment of the invention.

Identical references may be used in different figures when they designate identical or comparable elements.

There represents a telecommunications system 1 in one embodiment of the invention.

System 1 comprises an orchestration device 10, a plurality of processing platforms 20. In one embodiment shown here, system 1 further comprises a database 50.

Each processing platform 20 is a hardware platform which comprises one or more servers 6, a local telecommunications network 7, a local electronic controller 8 and a data storage base 9. The local telecommunications network, for example a wired network, interconnects the servers 6 and the local controller, within their platform 20.

In the case shown on the , system 1 includes three processing platforms 20: platforms 20_1, 20_2 and 20_3, for example each embedded in a respective mobile vehicle (airplane, drone, rolling machine)…: platform 20_1 is located here in an airplane, the platform 20_2 in another aircraft and the platform 20_3 in a land vehicle, which circulate in a geographical area of intervention.

In the embodiment considered:
- platform 20_1 includes two servers 6: servers SERV11 and SERV12;
- platform 20_2 includes three servers 6: servers SERV21, SERV22 and SERV23;
- and platform 20_3 includes a server 6: server SER31.

The storage database 9 stores, in association with the identifier of each software application to be hosted considered in the present invention, the (binary) code of the application and a set of meta-data relating to the software application.

The database 50 is for example in a building distant from the intervention zone.

The orchestration device 10, hereinafter called orchestrator 10, is connected by a wireless telecommunications link 61, respectively 62, respectively 63, to the processing platform 20_1, respectively 20_2, respectively 20_3.

Furthermore, the processing platforms 20, or at least some of them, are for example interconnected with each other and/or with other wireless telecommunications entities (for example in the present case the database 50) by a constrained wireless telecommunications network. For example, in the case shown in , each platform 20_i, i = 1 to 3, is connected by a satellite link 5i to the database 50; the platform 20_1 is connected to the platform 20_2 by a link 40, for example VHF or UHF and the platform 20_2 is connected to the platform 20_3 by a link 41, for example VHF and UHF.

These links 40, 41, 51, 52, 53 constitute transmission resources of the constrained telecommunications network of system 1.

In one embodiment, some or all of the links among the links 40, 41, 61, 62 and 63 are logical links carried by a single physical link.

The orchestrator 10 is adapted to regularly receive, for example at least once every T _t seconds, data indicating the current transport conditions on the links 40, 41, 51, 52 and 53, in particular the available bandwidth and/or or link occupancy rate and/or latency and/or jitter.

Concerning the value of T _t : if we want to be reactive, we need a low value, for example, the value of T _t will be set equal to a maximum of 1 second, but this will require a large bandwidth; the more we increase this value (up to, for example, 60 seconds), the less bandwidth we will consume, but the less responsive we will be; there is therefore a compromise to be made between consumption and reactivity.

In another embodiment, at least some of this data is not communicated periodically but on the occurrence of an event (for example passage of the bandwidth below (or above) defined thresholds etc., which makes it possible to minimize the footprint of these reports on the overall bandwidth of the network.

These data indicating the current transport conditions are for example determined by the local controllers 8 of the platforms 20 according to the exchanges implemented on the telecommunications links, then transmitted to the orchestration device 10 by the platform 20_1 on the link 6i, i = 1 to 3.

Typically, UHF, VHF links 40, 41 have fluctuating and limited bandwidths, for example, frequently - or even always - less than a hundred kbits/s or even a few tens of kbits/s. ; the satellite links 51, 52 and 53 have a bandwidth frequently - or even always - lower than a few Mbits/s (for example less than 10) or even a few hundred kbit/s (less than 10).

The latency for geostationary satellites is around 600ms (case of double hop when you have to go back through a hub on the ground); the latency for UHF networks is more of the order of a hundred ms, perhaps a few tens (less than 10) ms. For low-orbit satellites, the latency is somewhere between the two.

Jitter will especially be found on TDMA radio networks because the access time to the transmission slot is variable. It depends on the length of the slot, but it can be several tens (less than 10 tens) of ms, or even more.

Each server 6 includes processing resources, which include calculation resources (CPU) and memory resources, for example RAM type, or NAS (Network-Attached Storage). Each server 6 is adapted to host, for a determined time, one or more software applications following the allocation of processing resources of the server 6 to each of these software applications, the hosted applications then executing using the memory resources and calculation assigned to it.

Within each platform 20_i, i = 1 to 3, the local controller 8 is adapted to determine in real time for each server 6 of this platform 20_i, the current state of availability of the processing resources of the server: quantity of resources of available memory, for example expressed in bytes, and quantity of available computing resources, for example expressed in virtual CPU (vCPU) or in threads or in Mips (Million instructions per second), the other resources being used for execution of software applications assigned to the server. By “amount of available resource” we mean the quantity that could be allocated to the execution of an additional software application. The local controller 8 is adapted to determine in real time for each server 6 of this platform 20_i, the state of the applications running on the server 6 (for example progress of execution OK or NOK, progress status, performance …).

The local controller 8 is adapted to transmit regularly, for example at least once every T_rseconds, with T_rfor example chosen equal to T_t, the state of the processing resources at the orchestrator 10 as well as the state of the applications.

In another embodiment, the transmission of this state is not periodic but takes place on the occurrence of an event, for example linked to an exceeding of threshold(s) characterizing the state of the resources and/or the state of the applications.

The orchestrator 10 is an electronic device comprising an electronic scheduling block 11, an electronic selection block 12 and a database 13. It is adapted to receive requests, called REQs, from telecommunications devices connected to the orchestrator 10 via telecommunications links. Some of these communication devices are for example embedded in the mobile vehicles transporting the platforms 20 or embedded in the same vehicle, mobile or fixed, in which the orchestrator 10 is located.

The selection block 12 of the orchestrator 10 is adapted to, following receipt of a request, named REQ, indicating a software application to be executed, select from all the processing resources of the servers of the platforms 20_1, 20_2, 20_3, that of the processing resource(s) which will be allocated to the execution of a software application indicated in the REQ request, in the manner described in more detail with reference to Figures 2 and 3.

Each REQ request received by the orchestrator 10 and concerning a software application to be hosted, named APP, conforms to a predefined syntax and includes at least, in addition to the identifier of the telecommunications device at the origin of the request, the identifier of the APP software application and optionally time indication of when the execution of the APP application is desired (for example at the latest).

• a/ code (binaire) de l’application logicielle APP les valeurs de paramètres etc. (ou dans un mode de réalisation, l’adresse URL à partir de laquelle l’application logicielle peut être téléchargée) ;
• b/ les caractéristiques de mémoire et de calcul requises, nécessaires à la bonne exécution de l’application logicielle APP obtenues par l’évaluation des quantités de ressources de calcul et de mémoire par exemple au moment de la conception de l’application APP)
• c/ indication des conditions de transport minimales requises pour la mise en œuvre de télécommunications avec ladite application logicielle APP pendant son exécution ; cette indication est fournie dans un mode de réalisation pour un mode nominal de fonctionnement de l’application et optionnellement en outre pour un ou plusieurs modes dégradés de fonctionnement de l’application logicielle ; ces conditions sont exprimées par exemple sous forme de bande passante minimale requise, de latence maximale requise, de gigue maximale requise, de taux d’erreur maximal requis, de coût d’usage maximal permis, de paramètres qualitatifs (type de liaison par exemple), etc.

From this APP software application identifier, the orchestrator 10 is adapted to obtain the following information (or at least some of the following information), stored previously, in its database 14, in correspondence with the identifier of the APP software application (for example this information is part of the metadata of the APP application):

• a/ code (binary) of the software application APP parameter values etc. (or in one embodiment, the URL from which the software application can be downloaded);
• b/ the required memory and calculation characteristics, necessary for the proper execution of the APP software application obtained by evaluating the quantities of calculation and memory resources, for example at the time of designing the APP application)
• c/ indication of the minimum transport conditions required for the implementation of telecommunications with said APP software application during its execution; this indication is provided in one embodiment for a nominal mode of operation of the application and optionally further for one or more degraded modes of operation of the software application; these conditions are expressed for example in the form of minimum required bandwidth, maximum required latency, maximum required jitter, maximum required error rate, maximum allowed usage cost, qualitative parameters (type of link for example) , etc.

In another embodiment, the information indicated above as extracted from a database 13 is alternatively indicated in the REQ request and the orchestrator obtains it directly in the REQ request.

Thus, for each software application intended to be processed by the orchestrator 10, a step of characterizing the exchanges implemented by the software application must first be carried out, for example during the design of each software application APP, in particular in broadcast. This step is for example implemented by a characterization software block implementing the steps below.

In this characterization of exchanges, the types of information exchanged are first identified. For each type of information, the lifespan of the information produced is then characterized. This gives a latency constraint that must not be exceeded on the transport of this information. Then, the volume of information produced by these exchanges is calculated or evaluated or measured. Associated with the maximum latency constraint, this leads to a minimum bandwidth constraint necessary to convey the information produced. The periodicity of exchanges is another property of information which allows resources to be maintained over time. For non-periodic information, once the information has been sent, the transmission resources can be freed. For periodic information, resources must be maintained as long as the application is active. Furthermore, the volume associated with the period makes it possible to define an average information rate, which leads to a minimum bandwidth constraint on the transmission resources.

• contrainte de gigue, c’est-à-dire une contrainte sur la variation maximum de latence ;
• contrainte sur le taux de perte maximum d’information, ce qui se traduit en un taux d’erreur maximum du réseau de transmission ;
• éléments qualitatifs du transport : liaison sécurisée nécessaire ou pas, liaison patrimoniale nécessaire ou pas, ….

During this characterization, in one embodiment, the data below, or at least some of them, are additionally determined:

• jitter constraint, that is to say a constraint on the maximum latency variation;
• constraint on the maximum information loss rate, which translates into a maximum error rate of the transmission network;
• qualitative elements of transport: secure connection necessary or not, heritage connection necessary or not, etc.

From this characterization of the exchanges associated with the software application, a definition of the threshold transport conditions required for the proper execution of the software application, in terms of at least a minimum bandwidth value and/or maximum value of latency and/or jitter and/or error rate.

As specified above, this characterization of the exchanges (and the required threshold transport conditions) is carried out at least for a nominal mode of operation of the application and in addition, optionally, for one or more degraded modes of operation of the application. software that can be implemented in the event of shortage or degradation of network transmission resources.

For example, a video capture application will be associated with a nominal operating mode, in which it provides images with maximum resolution, corresponding to a bit rate of 2 Mbit/s, a first degraded operating mode in which it provides images with an intermediate resolution, corresponding to a bit rate of 1 Mbit/s and a second degraded operating mode in which it provides images with a low resolution, corresponding to a bit rate of 500 kbit/s. This allows the application to switch to a suitable operating mode if a transmission resource allowing the nominal operating mode cannot be found.

The information corresponding to item c above can thus take several forms: either it is provided in the form of the evaluation of the exchanges (and in this case, it is the orchestrator who carries out the translation, deducing the threshold transport conditions required (= transport templates to be respected), or in the form of these transport templates to be respected (different operating modes corresponding to different transport templates).

Software applications are software units of autonomous executable (thus including the code), for example containers, such as Kuberbetes® pods. Each is adapted to be deployed on a server chosen by the orchestrator 10, and to be executed there.

In a system 1 according to the invention, the current transport conditions are therefore supervised and provided to the orchestrator 10 in the same way as the calculation and memory resources, and the selection of the hardware resource for hosting the applications takes into account takes into account not only the calculation capacity and the memory necessary for the execution of the applications, but also the capacity of the underlying constrained network to ensure the exchanges carried out by the applications due to their relocation.

There represents the steps of a method for orchestrating software applications in one embodiment of the invention.

In the embodiment considered, the orchestrator 10, and in particular the scheduling block 11 and the selection block 12, are produced in the form of software blocks, comprising software instructions stored in a memory of the orchestrator 10 and which, when executed on a processor of the orchestrator 10, implement the steps incumbent upon them.

In reference to the , the controller 8 in each platform 20 determines in a step 101a, based on control data transmitted by the hardware processing resources (memory and calculation) of each server 6 of the platform, the updated state of resource availability processing of the platform, for example at a frequency T _r (some of the resources are for example not available, used for the execution of the applications APP_A, APP_B, etc. previously allocated to the resources of this platform 20).

In parallel for example, the controller 8 in each platform 20, determines, in a step 101b, the updated state of the software applications running locally, based on control data transmitted to it by these software applications including The execution has been assigned to the servers 6 of the platform by the orchestrator 10 (at this stage the APP_N application is not yet hosted on the platform, the state therefore does not concern it; it has been framed in dotted lines on there to signal its subsequent insertion during the process).

In a step 102a, the controller 8 transmits the updated availability state, also at the frequency T _r (on the link 6i from the platform 20_i, i=1 to 3) to the orchestrator 10, which receives it. In one embodiment, it also transmits to the orchestrator the status of the software applications (optionally this status is transmitted only when the status indicates a malfunction).

In parallel for example, in a step 102b, the orchestrator 10 receives, for example (see above) at the frequency T _t , the current transport conditions on the links 40, 41, 51, 52 and 53.

In a step 103, the orchestrator 10 receives a REQ request, relating to a software application, here named APP_N, for the deployment of the latter on a server to be identified by the orchestrator 10. The scheduling block 11 of the orchestrator 10, in a step 104, extracts from the database 13 the information indicated (or some of it) in items a, b, c above (when they do not appear in the REQ request) , then it provides, as well as the REQ request to the selection block 12 of the orchestrator 10.

• les états de disponibilité des ressources de traitement reçues à l’étape 102a ;
• les caractéristiques de mémoire et de calcul requises pour l’exécution de l’application APP_N, telles que fournies à l’étape 104 au bloc de sélection 12 ;
• les conditions de transport reçues à l’étape 102b ;
• les conditions de transport seuil telles que fournies à l’étape 104 au bloc de sélection 12.

The selection block 12, in a step 105, selects that of the platforms 20_1, 20_2, 20_3 among all the platforms 20_1, 20_2, 20_3 whose processing resource(s) can be allocated to the execution of the application software APP_N, this selection being made according to at least:

• the availability states of the processing resources received in step 102a;
• the memory and calculation characteristics required for the execution of the APP_N application, as provided in step 104 to selection block 12;
• the transport conditions received in step 102b;
• the threshold transport conditions as provided in step 104 in selection block 12.

Once the platform is selected, if it includes several servers with the required resources, a server among these servers is in turn selected, whose processing resources will be allocated to the execution of the software application APP_N. This last selection is made depending on the embodiments, either by the selection block 12 also, or by the local controller 8 of the selected platform.

Typically, the selection rules are such that: the processing resources (calculation, memory in the RAM sense) selected for the APP_N application will be chosen within the same server 6; the selected resources are resources, in a then “available” state, and are selected in quantity equal to or greater than said memory and calculation characteristics required for APP_N; furthermore, the selected platform is such that the output link(s) of this platform (allowing the transmission of data from this platform) present transport conditions (according to those received in step 102b) verifying the transport conditions threshold associated with the APP_N application and provided in step 104

• identifier les plateformes en capacité d’héberger l’application APP_N selon remontée des états 102a ; sélectionner parmi elles la plateforme offrant les meilleures conditions de transport selon remontée 102b ; ou
• identifier les plateformes en capacité d’assurer les échanges de l’application APP_N selon remontée 102b ; sélectionner parmi elles la plateforme capable d’héberger l’application APP_N selon remontée des états 102a et qui conserve un maximum de ressources disponibles.

Selection rules are for example:

• identify the platforms capable of hosting the APP_N application according to reporting of states 102a; select among them the platform offering the best transport conditions according to lift 102b; Or
• identify the platforms capable of ensuring exchanges of the APP_N application according to feedback 102b; select among them the platform capable of hosting the APP_N application according to reporting of states 102a and which retains a maximum of available resources.

As an example, consider a video application with a nominal operating mode (MdF0) at 2Mbit/s, a degraded operating mode MdF1 at 1Mbit/s and a degraded operating mode MdF2 at 500kbit/s. The transport conditions (step 102b) are: link 51 = 2.4 Mbit/s; link 52 = 750 kbit/s; link 53 = 1.3 Mbit/s. Suppose that platform 20_1 does not have sufficient computing or memory resources to host APP_N and that both platforms 20_2 and 20_3 can do so, then the selection will be made on platform 20_3 which offers the best transport conditions and the The APP_N application will then be deployed in MdF1 mode. If, on the other hand, application 20_1 had been able to host application APP_N, then it would have been selected and application APP_N would have been deployed in MdF0 mode.

An additional measure making it possible to limit the use of transmission resources consists of modifying the scheduling algorithm of the orchestrator to associate with the deployment all or part of the support services necessary for the proper functioning of the deployed services and thus maintain the maximum number of interactions. co-located: thus if the APP_N application must exchange on the one hand with the database 50 and on the other hand with an application which is then hosted on the platform 20_3, the volumes exchanged with the latter being high and with a duration of low life, selection block 12 will prioritize resources for APP_N on platform 20_3

Then selection block 12 indicates the selected platform (or even the selected calculation and memory resources) to scheduling block 11.

In a step 106, the scheduling block 11 transmits a request for hosting the APP_N application to the local controller 8 of the selected platform 20 and provides the context information (or the information allowing the download of the context).

In a step 107, the controller 8 receives the request for hosting the application APP_N; it extracts from the storage database 9 in particular the code of the APP_N application which is stored there in association with the identifier of APP_N indicated in the hosting request. If applicable, the controller 8 selects the local calculation and memory resources (if they have not been selected by the selection block 12 and indicated in the hosting request) based on the metadata of the APP_N application in the base 9. Controller 8 installs the application in the selected memory resource (DRAM), starts this application on the selected calculation resource and verifies the execution (using the selected memory and calculation resources). It adds the APP_N application to the list of applications whose operating status is reported to the orchestrator (see above). The APP_N application (boxed in dotted lines on the to signal its insertion during the process) is then hosted on the platform.

The APP_N application during its execution implements exchanges on one or more links, among the links 40, 41, 51, 52, 53, between the platform 20 hosting APP_N and the interlocutor or interlocutors involved in these exchanges.

In one embodiment, the scheduling block 11 of the orchestration device triggers, beforehand (for example, during a step 108), an action to guarantee the availability of transport resources (estimated according to said transport conditions threshold required for APP_N) necessary for these exchanges on this or these links and making it possible to satisfy the selected operating mode: for example a reservation of these resources or any other mechanism making it possible to manage the quality of service in a wireless network. Subsequently, if transport conditions change, this may cause the APP_N application to switch to another operating mode. It may also be that no operating mode can be satisfied, in which case the APP_N application can no longer run correctly. An execution error is then reported to the scheduler to find alternative accommodation

The selection of the hardware processing resource is a function, in one embodiment, of the deployment time of the software application on the hardware resource (including in particular the instantiation of the application, its startup, and the transmission of the context of operation in the event of redeployment), which depend on current transport conditions. The deployment time may in fact prove to be incompatible with the temporal need, expressed in the request, to benefit from the service and must therefore be considered in the algorithm for selecting the available processing resources.

For example, in one embodiment, said REQ request received relating to the software application to be hosted further indicates deployment requirements for the installation of the software application (for example, it must be launched in 2 s). And the orchestrator selects server 6 further based on these deployment requirements for installing the software application.

There represents the steps of an application orchestration method in one embodiment of the invention, in the case of redeployment following the loss of a processing resource then used for the execution of a software application or following the inability to ensure one of the operating modes authorized for the execution of an application.

The controller 8 in each platform 20 (in particular in the platforms 20_1, 20_2 represented in ) determines in a step 201a, based on control data transmitted by the hardware processing resources of each server 6 of the platform, the updated state of availability of the processing resources of the platform, at a frequency T _r (some of the resources are not available, used for the execution of applications APP_A, … APP_B, previously allocated to the resources of this platform 20).

In parallel for example, in a step 201b, the controller 8 in each platform 20 determines, based on control data transmitted by the software applications whose execution has been assigned to the servers 6 of the platform, the updated state of the software applications running locally.

In the present case, depending for example on the state of the software applications determined in step 201b and/or the state of the resources determined in step 201a, the controller 8 of the platform 20_1 determines that the execution of the The hosted application APP_B presents a malfunction. Typically, this follows the detection of a software crash, the disappearance of a resource or the temporary removal of the platform on which an application was running with which the APP_B application exchanged data during its execution etc.

In a step 202a, the controller 8 of each platform transmits the updated state of resource availability, also at the frequency Tr (on the link 6i from the platform 20_i, i=1 to 3) to the orchestrator 10, which receives.

In parallel, in a step 202b, the orchestrator 10 receives, for example at the frequency Tt, the current transport conditions on the links 40, 41, 51, 52 and 53.

In parallel, in a step 202c, the controller 8 of the platform 20_1 transmits to the scheduling block 11 of the orchestrator 10 a state indicating that the hosting of the application APP_B is to be reassigned.

The scheduling block 11 of the orchestrator 10 extracts from the database 13 the information associated with the APP_B application and indicated (or some of them) in items a, b, c above, then it performs a request for re-selection of resources to host the application APP_B in the selection block 12 of the orchestrator 10, in a step 203.

The selection block 12, in a step 204, selects that of the platforms 20_1, 20_2, 20_3, whose processing resource(s) will be allocated to the execution of the software application APP_N, this selection being made according to at least the criteria indicated in relation to step 105 of the ; then the selection block 12 indicates the selected platform (or even in one embodiment the selected resources of this selected platform, when it is not the local controller 8 of the selected platform which selects the allocated resources) to the scheduling block 11, in this case platform 20_2.

In a step 205, the scheduling block 11 transmits a request for hosting the application APP_B to the local controller 8 of the platform 20_2 and provides the context information (or the information allowing the download of the context). In the present case, the information is downloaded from the platform 20_1 of previous hosting of the APP_B application or from a NAS, for example base 50.

In a step 206, in response to receipt of this redeployment request, the controller 8 of the platform 20_2 carries out the deployment of the application, and then sends a status of successful execution of the application APP_B after its deployment, confirming that it was carried out correctly, if necessary (state with content similar to that sent in step 102c or 202c).

The APP_B application in its execution implements exchanges on one or more of the links, among the links 40, 41, 52 connecting the platform 20_2 hosting APP_B to its immediate environment.

As mentioned previously, in one embodiment, transport resources are reserved for these exchanges.

In one embodiment, the selection block 11 in the context of the software redeployment to be hosted selects the platform in which to re-deploy the APP_B application by further evaluating whether context data and/or the instantiation time are indeed compatible with a maximum duration allocated to the deployment of the software application (this duration being indicated in the initial REQ request associated with APP_B) and/or are compatible with the deployment requirements as described with reference to the .

Note that the malfunction of an application in one embodiment is identified directly by the orchestrator 10 (and not following a message from the local controller), which then implements steps 203 et seq.

In the embodiment considered, the codes of the applications to be hosted are already resident (in a non-active manner, i.e. without execution) on each platform. If this was not the case for some of the applications, an additional platform selection criterion could be considered: the presence of the application code on the platforms.

An additional measure which makes it possible to limit the use of wireless transmission resources consists of modifying the selection algorithm of the orchestrator 10 to associate with the deployment of a software application all or part of the "support" applications which are necessary for the proper functioning of the application to be deployed and thus maintain the maximum number of co-located interactions, thus reducing the need for exchanges of the platform with other platforms. To do this, a tree of application interdependencies is maintained in the form of, for example, a choreography definition with the applications to be deployed as a starting point. The selection algorithm can then traverse the choreography tree and consolidate the need for computing and memory and transmission resources for each application encountered in the tree. Note that unlike calculation resources and memory resources which are additive (deploying a support service increases the need for calculation and memory), transmission resources can vary upwards or downwards (co-located exchanges reduce the need in transmission resources). So there is a compromise to be made. The selection of the hardware resource to host the applications then becomes a classic search for an optimal solution in a field of constraints given on the one hand by the available resources and on the other hand by the resource requirements.

For example, in one embodiment, the applications are represented by a tree structure, in which two software applications are connected by a branch of the structure (representing their exchanges) if they implement telecommunications between them during their execution. The nodes of the tree represent the software applications and carry the metadata of said software applications (calculation, memory, transport templates). The branches of the tree carry the specific transport templates for inter-node exchanges. As we go through the tree, we add the calculation, memory and exchange requirements given by the nodes and subtract the exchange requirements given by the branches.

The two applications linked by a branch are for example an application for capturing images by a Radar responsible for tracking a target and an application for calculating the trajectory of the aircraft transporting the Radar (and therefore having to track the target).

Note that at least the following two situations can occur:

- the software application is launched from a market place or equivalent; the initiator of the REQ request will then be the interlocutor of the application to be hosted and is therefore defined by the source address of the REQ request; this is a push mode: the application knows who to send its data to;

– the software application is launched automatically for the benefit of a group of participants, not necessarily all connected to the network at that time; in this case, the choice of the hosting platform can be made by comparing the transmission resources of the platforms with the operating modes expressed for the application in the transport templates; it is then a pull mode: the application waits for a contact to come forward to send it their data and it is only at that moment that the end-to-end path is taken into account and the actual operating mode is chosen.

Thus the invention proposes a cloud orchestrator which evaluates the suitability of a server to host an application according to the available CPU resource and/or the quantity of available memory versus the application's needs in CPU and/or or memory, and which further evaluates this adequacy according to the characteristics of the end-to-end network versus the previously evaluated exchange needs of the software applications (so that the characteristics of the transmission links implemented to ensure exchanges during execution of the software application on the selected server fulfills these exchange needs). An orchestrator implementing the invention can be used in constrained networks with a satisfactory level of performance. The heterogeneity of transmission capacities and the state of discretion contribute to transport conditions. This information is taken into account by selecting a transport template compatible with the transport conditions observed.

The invention also makes it possible, in one embodiment, to take into account the deployment time of software or components in the selection of hosting resources, to guarantee availability within the expected deadlines.

Thus the invention can be implemented in existing orchestrators by completing their scoring mechanism calculated for each available processing resource or vice versa by only calculating this scoring for compatible resources (in terms of links involved) with minimum transport conditions. .

The method may be implemented by executing software instructions on a processor, as described above. Alternatively, it can be implemented by dedicated hardware, typically a digital integrated circuit, either specific (ASIC) or based on programmable logic (for example FPGA/Field Programmable Gate Array).

Claims (10)

Method for orchestrating software applications in a telecommunications system (1) comprising an electronic orchestration device (10), distributed telecommunications platforms (20), connected to links (40, 41) of a network of wireless telecommunications and comprising each of the processing resources (6) among memory resources and calculation resources, said method comprising the following steps implemented by the orchestration device (10):

• collection of states of processing resources, said states indicating the current availability of said resources (6);
• receiving requests (REQ) indicating software applications (APP_N) to be executed and, for each software application indicated in a received request (REQ), obtaining the memory and calculation characteristics required for the execution of said application;
• for each software application: selection, among the platforms, of at least one platform for the execution of said software application via a processing resource of the selected platform, said selection being made according to at least:

collected availability states of processing resources; And
the obtained memory and calculation characteristics required for the execution of said application; And

• allocation of at least said selected platform for the execution of said software application;

said method being characterized in that it further comprises the following steps implemented by the orchestration device (10):

• collection of current transport conditions on said wireless telecommunications network, said transport conditions indicating at least one piece of information associated with the links among their available bandwidth, their jitter, their latency, their error rate, their nominal bandwidth and their occupancy rate ;
• for each software application (APP_N) indicated in a request (REQ) received, further obtaining transport template(s) indicating minimum transport conditions required for the implementation of telecommunications with said software application during its execution;
• said selection of the platform is further carried out based on the transport conditions collected and said transport template(s) obtained.

Orchestration method according to claim 1, according to which:
- said request (REQ) received relating to said software application (APP_N) further indicates deployment requirements for the installation of said software application; And
- said selection of processing resource (6) is further carried out according to said deployment requirements for the installation of said software application. Orchestration method according to claim 1 or 2, according to which in a tree structure, two software applications are connected by a branch of said structure if they have been defined to implement telecommunications between them during their execution and at each branch are associated with transport templates required specifically for said telecommunications and according to which:
the selection of at least one platform for the execution of a software application, when it is part of said tree structure further comprises at least the selection of a platform for the execution of another application of said tree structure , said platforms having to be a single platform, according to a rule relating to the transport templates on the branches connecting them, if this reduces the need for exchanges of the selected platform with the other platforms. Orchestration method according to any one of the preceding claims, according to which following said selection, a reservation of transport resources is triggered on at least one link of the wireless telecommunications network according to said transport templates and current conditions transport, for the implementation of telecommunications with said software application during its execution. Orchestration method according to any one of the preceding claims, according to which:

• said transport templates for implementing telecommunications with said software application during its execution comprise a first transport template corresponding to a nominal operating mode of the software application and a second transport template, less demanding than the first transport template transport, corresponding to a degraded operating mode of the software application;
• said processing resource selection being carried out according to said first and second transport templates as obtained.

Computer program, intended to be stored in the memory of an electronic orchestration device (10) further comprising a microcomputer, said computer program comprising instructions which, when executed on the microcomputer, implement implements the steps of a method according to one of the preceding claims. Electronic device (10) for orchestrating software applications for a telecommunications system (1) comprising distributed telecommunications platforms (20), connected to links (40, 41) of a wireless telecommunications network and each comprising processing resources (6) among memory resources and calculation resources, said orchestration device (10) being adapted to collect states of the processing resources, said states indicating the current availability of said resources (6), for receive requests (REQ) indicating software applications (APP_N) to be executed and, for each software application indicated in a received request (REQ), to obtain memory and calculation characteristics required for the execution of said application;
for each software application, said orchestration device (10) being adapted for:
- select from among the platforms, at least one platform for the execution of said software application via a processing resource of the selected platform, said selection being made according to at least:
collected availability states of processing resources; And
the obtained memory and calculation characteristics required for the execution of said application; And
- to affect at least said selected platform for the execution of said software application;
said orchestration device (10) being characterized in that it is adapted for:
- collect current transport conditions on said wireless telecommunications network, said transport conditions indicating at least one piece of information associated with the links among their available bandwidth, their jitter, their latency, their error rate, their nominal bandwidth and their occupancy rate;
- for each software application (APP_N) indicated in a request (REQ) received, further obtain transport template(s) indicating minimum transport conditions required for the implementation of telecommunications with said software application during its execution;
said selection of the platform being further carried out according to the transport conditions collected and said transport template(s) obtained. Orchestration device (10) according to claim 7, in which:
- said request (REQ) received relating to said software application (APP_N) further indicates deployment requirements for the installation of said software application; And
- said selection of processing resource (6) is further carried out according to said deployment requirements for the installation of said software application. Orchestration device according to claim 7 or 8, in which in a tree structure, two software applications are connected by a branch of said structure if they have been defined to implement telecommunications between them during their execution and at each branch are associated with transport templates required specifically for said telecommunications and according to which:
the selection of at least one platform for the execution of a software application, when it is part of said tree structure further comprises at least the selection of a platform for the execution of another application of said tree structure , said platforms having to be a single platform, according to a rule relating to the transport templates on the branches connecting them, if this reduces the need for exchanges of the selected platform with the other platforms. Orchestration device (10) according to any one of the preceding claims, adapted to, following said selection, trigger a reservation of transport resources on at least one link of the wireless telecommunications network according to said template(s) transport and current transport conditions, for the implementation of telecommunications with said software application during its execution.