Method for orchestrating software applications in a telecommunications system, computer program and associated orchestration device

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 the selection 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 the collected availability states of the processing resources, the memory and computing characteristics 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 the available bandwidths, jitter, latency, error rates, nominal bandwidths and occupancy rates. Figure for the abstract: Fig. 1,

Description

Title of the invention: ORCHESTRATION METHOD SOFTWARE APPLICATIONS IN A TELECOMMUNICATION SYSTEM, COMPUTER PROGRAM AND ASSOCIATED ORCHESTRATION DEVICE technical field

[0001] The invention lies in the field of software application orchestration, in which hardware resources, including CPUs and memories, in remote and distributed servers are selected to host the execution of a software application. Previous technique

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

[0003] While these solutions are quite effective on gigabit telecommunication networks based on optical fibers, they prove insufficient on constrained telecommunication networks and may even contribute to congestion of these networks.

[0004] A "constrained telecommunications network" is defined as a telecommunications network in which telecommunications capacity is limited (compared to gigabit networks) and unstable, such as tactical telecommunications networks deployed locally and temporarily in a medical or military intervention area (a disaster zone, geological or other area, a conflict zone, etc.). Transmission links are frequently interrupted without warning (for example, by intentional or unintentional jamming), some are very limited in terms of bandwidth, or experience bandwidth or latency variations much more frequently than in conventional consumer networks. However, in these interventions, it is essential to be able to run software applications reliably, particularly on servers mounted on vehicles moving in, on, or near the intervention zone.

[0005] There is therefore a need for a software application orchestration solution that can be satisfactorily implemented on any type of telecommunications network, including constrained ones. Summary of the invention

[0006] 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 links of a wireless telecommunications network and each comprising processing resources among memory resources and computing resources, said method comprising the following steps implemented by the orchestration device: - collection of status reports of processing resources, said status reports 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 the execution of said application; - for each software application: selection, from 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 based on at least: the collected availability statuses of processing resources; and the memory and computing characteristics required for the execution of said application; and - allocation of at least the said selected platform for the execution of said software application; said process 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, jitter, latency, error rate, nominal bandwidth and occupancy rate; - for each software application indicated in a received request, obtaining in addition transport template(s) indicating minimum transport conditions required for the implementation of telecommunications with said software application during its execution; - said platform selection is also carried out according to the transport conditions collected and the said transport template(s) obtained.

[0007] In embodiments, such a method will further comprise at least one of the following features:

[0008] - said request received relating to said software application further indicates deployment requirements for the installation of said software application; and said processing resource selection is further performed according to said deployment requirements for the installation of said software application;

[0009] - in a tree structure, two software applications are linked by a branches of said structure if they have been defined to implement telecommunications between them during their execution, and to each branch are associated transport templates specifically required 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 includes at least the selection of at least one platform for the execution of another application of said tree structure, said platforms being a single platform, according to a rule relating to transport templates on the branches connecting them, if this reduces the need for exchanges of the selected platform with the other platforms;

[0010] - following said selection, a transport resource reservation 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;

[0011] - said transport templates for the implementation of telecommunications with said software application during its execution include 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, corresponding to a degraded operating mode of the software application; said processing resource selection being performed according to said first and second transport templates as obtained.

[0012] 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 process according to the first aspect of the invention.

[0013] 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 computing 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 ap software applications to be executed and, for each software application specified in a received request, to obtain the memory and computing characteristics required for the execution of said application; For each software application, said orchestration device is adapted to: - 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 based on at least: the collected availability states of the processing resources; and the memory and computing characteristics required for the execution of said application; and - to allocate at least the 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, jitter, latency, error rate, nominal bandwidth and occupancy rate; - for each software application indicated in a received request, also obtain transport template(s) indicating minimum transport conditions required for the implementation of telecommunications with said software application during its execution; said platform selection being carried out further according to the transport conditions collected and the said transport template(s) obtained.

[0014] In embodiments, such a device will further comprise at least one of the following features:

[0015] - said request received relating to said software application further indicates deployment requirements for the installation of said software application; and said processing resource selection is further performed according to said deployment requirements for the installation of said software application;

[0016] - in a tree structure, two software applications are linked by a branches of said structure if they have been defined to implement telecommunications between them during their execution, and to each branch are associated transport templates specifically required for said telecommunications, and according to which: The selection of at least one platform for running a software application, when it is part of said tree structure, also includes at least one platform for running another application of said tree structure, said platforms being one and the same platform, in depending on a rule relating to transport dimensions on the branches connecting them, if this reduces the need for exchanges between the selected platform and other platforms;

[0017] - 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 current transport conditions, for the implementation of telecommunications with said software application during its execution. Brief description of the drawings

[0018] The invention will be better understood and other features, details and advantages will become clearer from the following description, given by way of non-limiting reason, and from the accompanying figures, given by way of example.

[0019] [Fig-1] Fig. 1 is an illustration of a telecommunications system 1 in a method of implementing the invention;

[0020] [Fig.2] The [Fig.2] represents steps of a resource allocation process in one embodiment of the invention;

[0021] [Fig.3] The [Fig.3] represents steps of a resource allocation process in another embodiment of the invention.

[0022] Identical references may be used in different figures when they refer to identical or comparable elements. Description of the implementation methods

[0023] Fig. 1 represents a telecommunications system 1 in one embodiment of the invention.

[0024] The system 1 includes an orchestration device 10, a plurality of processing platforms 20. In one embodiment represented here, the system 1 further includes a database 50.

[0025] Each processing platform 20 is a hardware platform which includes 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.

[0026] In the case represented in [Fig.1], the system 1 comprises three processing platforms 20: the platforms 20_1, 20_2 and 20_3, for example each mounted in a respective mobile vehicle (airplane, drone, rolling vehicle)...: the platform 20_1 is here in an airplane, the platform 20_2 in another airplane and the platform 20_3 in a land vehicle, which circulate at the level of a geographical intervention area.

[0027] In the embodiment considered: - the 20_l platform has two servers 6: the SERVI 1 and SERV12 servers; - the 20_2 platform has three servers 6: the SERV21, SERV22 and SERV23 servers; - and the 20_3 platform includes a server 6: the SER31 server.

[0028] 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 metadata relating to the software application.

[0029] Database 50 is for example in a building remote from the intervention area.

[0030] The orchestration device 10, hereinafter referred to as orchestrator 10, is connected by a wireless telecommunication link 61, respectively 62, respectively 63, to the processing platform 20_1, respectively 20_2, respectively 20_3.

[0031] 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 [Fig. 1], each platform 20_i, i = 1 to 3, is connected by a satellite link 5i to the database 50; platform 20_1 is connected to platform 20_2 by a link 40, for example VHF or UHF, and platform 20_2 is connected to platform 20_3 by a link 41, for example VHF and UHF.

[0032] These links 40, 41, 51, 52, 53 constitute transmission resources of the constrained telecommunication network of system 1.

[0033] 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.

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

[0035] Regarding the value of Tt: if we want to be responsive, we need a low value, for example, the value of Tt 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 responsiveness.

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

[0037] 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 telecommunication links, then transmitted to the orchestration device 10 by the platform 20_l on the link 6i, i = 1 to 3.

[0038] 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; satellite links 51, 52 and 53 have a bandwidth frequently - or even always - less than a few Mbits / s (for example less than 10) or even a few hundred kbits / s (less than 10).

[0039] The latency for geostationary satellites is approximately 600 ms (in the case of double hopping when it is necessary to pass through a ground hub); the latency for UHF networks is more on the order of a hundred ms, perhaps a few tens (less than 10) of ms. For satellites in low Earth orbit, the latency lies between the two.

[0040] Jitter is most commonly found on TDMA radio networks because the access time to the transmit 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.

[0041] Each server 6 includes processing resources, which comprise computing resources (CPU) and memory resources, for example, RAM or NAS (Network-Attached Storage). Each server 6 is adapted to host, for a specified period, one or more software applications following the allocation of processing resources from server 6 to each of these software applications, the hosted applications then running using the memory and computing resources allocated to them.

[0042] 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 server's processing resources: the amount of available memory resources, for example expressed in bytes, and the amount of available computing resources, for example expressed in virtual CPUs (vCPUs) or in threads or in MIPS (Millions of Instructions Per Second), the other resources being used for the execution of software applications assigned to the server. "Amount of available resources" is understood to mean the amount 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, execution status OK or NOK, progress, performance, etc.).

[0043] The local controller 8 is adapted to transmit regularly, for example at least once every Tr seconds, with Tr for example chosen equal to Tt, the state of the processing resources to orchestrator 10 as well as the status of applications.

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

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

[0046] The selection block 12 of the orchestrator 10 is adapted to, following the receipt of a request, named REQ, indicating a software application to be executed, select from among all the processing resources of the servers of the platforms 20_1, 20_2, 20_3, 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.

[0047] 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 originating the request, the identifier of the software application APP and optionally a time indication of when the execution of the application APP is desired (for example at the latest).

[0048] From this software application identifier APP, the orchestrator 10 is adapted to obtain the following information (or at least some of the following information), previously stored in its database 14, corresponding to the software application identifier APP (for example, this information is part of the metadata of the application APP): - a / (binary) code of the APP software application, parameter values ​​etc. (or in one embodiment, the URL address from which the software application can be downloaded); - b / the required memory and computing characteristics necessary for the proper execution of the APP software application, obtained by evaluating the quantities of computing and memory resources, for example, at the time of the APP application design) - c / indication of the minimum transport conditions required for the implementation of telecommunications with said software application APP during its execution; this indication is provided in an embodiment for a nominal operating mode of the application and optionally also for one or more degraded operating modes of the software application; these conditions are expressed for example in terms of minimum bandwidth required, maximum latency required, maximum jitter required, maximum error rate required, maximum permissible usage cost, qualitative parameters (link type for example), etc.

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

[0050] Thus, for each software application intended to be processed by the orchestrator 10, a characterization step of the exchanges implemented by the software application, particularly in transmission, must be carried out beforehand, for example during the design of each software application APP. This step is implemented, for example, by a characterization software block implementing the steps below.

[0051] In this characterization of the exchanges, the types of information exchanged are first identified. For each type of information, the lifetime of the information produced is then characterized. This establishes a latency constraint that must not be exceeded for the transport of this information. Next, the volume of information produced by these exchanges is calculated, evaluated, or measured. Combined with the maximum latency constraint, this leads to a minimum bandwidth constraint required to carry the information produced. The periodicity of the exchanges is another property of the information that allows resources to be maintained over time. For non-periodic information, once the information is sent, the transmission resources can be released. For periodic information, the resources must be maintained as long as the application is active.Furthermore, the volume associated with the period allows us to define an average information rate, which leads to a minimum bandwidth constraint on transmission resources.

[0052] During this characterization, in one embodiment, the following data, or at least some of them, are further determined: - jitter constraint, that is to say a constraint on the maximum variation of latency; - 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, ....

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

[0054] As specified above, this characterization of the exchanges (and the required threshold transport conditions) is carried out at least for a nominal operating mode of the application and, in addition, optionally, for one or more degraded operating modes of the software application which may be implemented in the event of scarcity or degradation of the network transmission resources.

[0055] 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 intermediate resolution, corresponding to a bit rate of 1 Mbit / s; and a second degraded operating mode in which it provides images with 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 enabling the nominal operating mode cannot be found.

[0056] 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 modes of operation corresponding to different transport templates).

[0057] Software applications are self-contained executable software units (including the code), for example container-type units such as Kuberbetes® pods. Each is adapted to be deployed on a server chosen by the orchestrator 10, and to be executed there.

[0058] 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 computing and memory resources, and the selection of the hardware resource for hosting the applications takes into account not only the computing capacity and memory required 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.

[0059] Fig. 2 represents the steps of a software application orchestration process in one embodiment of the invention.

[0060] In the embodiment considered, the orchestrator 10, and in particular the scheduling block 11 and the selection block 12, are implemented 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.

[0061] With reference to [Fig.2], the controller 8 in each platform 20 determines in a step 101a, based on control data transmitted by the processing hardware resources (memory and computing) of each server 6 of the platform, the updated state of availability of the processing resources of the platform, for example at a frequency Tr (some of the resources are for example not available, used for the execution of the applications APP_A, APP_B, ... previously allocated to the resources of this platform 20).

[0062] 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 whose execution has been assigned to the servers 6 of the platform by the orchestrator 10 (at this stage the application APP_N is not yet hosted on the platform, so the state does not concern it; it has been outlined in dotted lines on [Fig.2] to indicate its subsequent insertion during the process).

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

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

[0065] 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 it is not included in the REQ request), then it provides it, as well as the REQ request, to the selection block 12 of the orchestrator 10.

[0066] The selection block 12, in a step 105, selects the platform 20_1, 20_2, 20_3 from among all the platforms 20_1, 20_2, 20_3 whose processing resource(s) can be allocated to the execution of the software application APP_N, this selection being made based on at least: - the availability status of the processing resources received in step 102a; - the memory and computing characteristics required for the execution of the APP_N application, as provided in step 104 to selection block 12 - the transport conditions received at step 102b; - the threshold transport conditions as provided in step 104 of block selection 12.

[0067] Once the platform has been selected, if it has several servers with the required resources, one of 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 carried out according to the embodiments, either by the selection block 12 also, or by the local controller 8 of the selected platform.

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

[0069] Selection rules include, for example: - identify the platforms capable of hosting the APP_N application based on the status report 102a; select from among them the platform offering the best transport conditions based on the status report 102b; or - identify the platforms capable of ensuring the exchanges of the APP_N application according to report 102b; select among them the platform capable of hosting the APP_N application according to the report of the states 102a and which retains a maximum of available resources.

[0070] Consider, as an example, a video application with a nominal operating mode (MdFO) at 2 Mbit / s, a degraded operating mode (MdF1) at 1 Mbit / s, and a degraded operating mode (MdF2) at 500 kbit / 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, then platform 20_3, which offers the best transport conditions, will be selected, and the APP_N application will then be deployed in MdF1 mode. If, on the other hand, application 20_l had been able to host application APP_N, then it would have been selected and application APP_N would have been deployed in MdFO mode.

[0071] An additional measure to limit the use of resources Transmission involves modifying the orchestrator's scheduling algorithm to associate all or part of the support services necessary for the proper functioning of the deployed services with the deployment, thus maintaining maximum localized interactions: for example, if the APP_N application needs to exchange data on one hand with database 50 and on the other hand with an application hosted on platform 20_3, the volumes exchanged with the latter being high and with a short lifespan, the selection block 12 will prioritize resources for APP_N on platform 20_3.

[0072] Then the selection block 12 indicates the selected platform (or even the selected computing and memory resources) to the scheduling block 11.

[0073] In a step 106, the scheduling block 11 transmits a request to host the application APP_N to the local controller 8 of the selected platform 20 and provides the context information (or the information enabling the context to be downloaded).

[0074] In a step 107, the controller 8 receives the hosting request for the application APP_N; it extracts from the storage database 9, in particular, the code of the application APP_N stored there in association with the identifier of APP_N indicated in the hosting request. If necessary, the controller 8 selects the local compute and memory resources (if they have not been selected by the selection block 12 and indicated in the hosting request) according to the metadata of the application APP_N in the database 9. The controller 8 installs the application in the selected memory resource (DRAM), starts this application on the selected compute resource and verifies the execution (using the selected memory and compute resources). It adds the application APP_N to the list of applications whose operating state has been reported to the orchestrator (see above). The application APP_N (outlined in dashed lines in the [Fig.2] to signal its insertion during the process) is then hosted on the platform.

[0075] 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.

[0076] In one embodiment, the scheduling block 11 of the orchestration device triggers, beforehand (for example, during step 108), an action to guarantee the availability of transport resources (estimated based on said threshold transport conditions required for APP_N) necessary for these exchanges on this or these links and enabling the chosen operating mode to be satisfied: for example, a reservation of these resources or any other mechanism enabling quality of service management in a wireless network. Subsequently, if the transport conditions change, this may cause the APP_N application to switch to another mode of operation. It is also possible that no operating mode can be satisfied, in which case the APP_N application can no longer run correctly. A runtime error is then reported to the scheduler to find an alternative hosting environment.

[0077] In one embodiment, the selection of the processing hardware resource depends on the deployment time of the software application on the hardware resource (including, in particular, application instantiation, startup, and transmission of the operating context in case of redeployment), which depends on the prevailing transport conditions. The deployment time may indeed be incompatible with the time requirement, expressed in the request, for accessing the service and must therefore be taken into account in the algorithm for selecting available processing resources.

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

[0079] Fig. 3 represents the steps of an application orchestration process in an embodiment of the invention, in the case of a redeployment following the loss of a processing resource then used for the execution of a software application or following the impossibility of ensuring one of the operating modes authorized for the execution of an application.

[0080] The controller 8 in each platform 20 (in particular in platforms 20_1, 20_2 represented in [Fig.3]) determines in a step 201a, based on control data transmitted by the processing hardware resources of each server 6 of the platform, the updated availability status of the platform's processing resources, at an uncertain frequency. Resources are not available, used for the execution of applications APP_A, ... APP_B, previously allocated to the resources of this platform 20).

[0081] 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.

[0082] 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_l determines that the execution of the hosted application APP_B is malfunctioning. 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 ran, with which the application APP_B exchanged data during its execution, etc.

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

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

[0085] In parallel, in a step 202c, the controller 8 of the platform 20_l 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.

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

[0087] The selection block 12, in a step 204, selects the platform 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 carried out according to at least the criteria indicated with respect to step 105 of [Fig.2]; then the selection block 12 indicates the selected platform (or in one embodiment the selected resources of this selected platform, when it is not the local controller 8 of the selected platform that selects the allocated resources) to the scheduling block 11, in this case the platform 20_2.

[0088] In step 205, the scheduling block 11 transmits a hosting request for the application APP_B to the local controller 8 of the platform 20_2 and provides the context information (or the information enabling the context to be downloaded). In this case, the information is to be downloaded from the previous hosting platform 20_1 of the application APP_B or from a NAS, for example, database 50.

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

[0090] 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.

[0091] As mentioned previously, in one embodiment, resources of transport is reserved for these exchanges.

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

[0093] It should be noted that the malfunction of an application in an embodiment is identified directly by the orchestrator 10 (and not following a message from the local controller), which then implements steps 203 and following.

[0094] In the embodiment considered, the application code to be hosted is already resident (inactively, i.e., without execution) on each platform. If this were 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.

[0095] A further measure to limit the use of wireless transmission resources consists of modifying the orchestrator's selection algorithm 10 to associate the deployment of a software application with all or part of the "support" applications necessary for the proper functioning of the application to be deployed, thereby maintaining maximum co-located interactions and reducing the need for exchanges between the platform and other platforms. To achieve this, an application dependency tree is maintained, for example, in the form of a choreography definition, starting with the applications to be deployed. The selection algorithm can then traverse the choreography tree and consolidate the computing, memory, and transmission resource requirements for each application encountered in the tree.It should be noted that, unlike computing and memory resources, which are additive (deploying a support service increases computing and memory requirements), transmission resources can fluctuate (co-located exchanges reduce transmission resource requirements). Therefore, a trade-off must be made. Selecting the hardware resource to host applications then becomes a classic search for the optimal solution within a set of constraints defined by both available resources and resource requirements.

[0096] For example, in one embodiment, applications are represented by a tree structure, in which two software applications are linked 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 carry the metadata of said software applications (computing, memory, transport templates). The branches of the tree carry the specific transport templates for inter-node exchanges. As we traverse the tree, we add the computing, memory, and exchange requirements of the nodes and subtract the exchange requirements of the branches.

[0097] The two applications linked by a branch are, for example, an application for capturing images by a Radar tasked with tracking a target and an application for calculating the trajectory of the aircraft carrying the Radar (and therefore having to track the target).

[0098] It should be noted that at least the following two situations can occur:

[0099] - the software application is launched from a marketplace or equivalent; the initiator 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 to whom to send its data;

[0100] - the software application is launched automatically for the benefit of a group of par 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; this is then a pull mode: the application waits for an interlocutor to express itself to send its data and it is only at that moment that the end-to-end path is taken into account and the effective operating mode is chosen.

[0101] Thus, the invention proposes a cloud orchestrator that evaluates the suitability of a server for hosting an application based on the available CPU resources and / or the amount of available memory versus the application's CPU and / or memory requirements, and that further evaluates this suitability based on the characteristics of the end-to-end network versus the previously evaluated exchange requirements of the software applications (such that the characteristics of the transmission links implemented to ensure exchanges during the execution of the software application on the selected server meet these exchange requirements). 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 discreteness contribute to the transport conditions.This information is taken into account by selecting a transport template compatible with the observed transport conditions.

[0102] The invention also allows, in one embodiment, for taking into account the deployment time of software or components in the selection of hosting resources, to guarantee availability within the expected timeframe.

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

[0104] The method can 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 (e.g., FPGA / Field Programmable Gate Array).

Claims

1. Claims 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 wireless telecommunications network and each comprising processing resources (6) among memory resources and computing resources, said method comprising the following steps implemented by the orchestration device (10): - collecting 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 computing characteristics required for the execution of said application; - for each software application: selection, from 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 based on at least: the collected availability states of the processing resources; and the obtained characteristics of memory and computing 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): - collecting current transport conditions on said wireless telecommunications network, said transport conditions indicating at least one 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 received request (REQ), further obtaining transport template(s) indicating minimum transport conditions required for implementing telecommunications with said software application during its execution; - said platform selection is further performed based on the transport conditions collected and said transport template(s) obtained.

2. Orchestration method according to claim 1, according to which: - said received request (REQ) 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.

3. 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 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.

4. 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 transport conditions, for the implementation of telecommunications with said software application during its execution.

5. 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, 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.

6. A 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 the steps of a method according to one of the preceding claims.

7. 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 computing resources, said orchestration device (10) being adapted to collect states of the processing resources, said states indicating the current availability of said resources (6), to 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 computing characteristics required for the execution of said application;for each software application, said orchestration device (10) being adapted to: - 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 carried out; based on at least: the collected availability states of the processing resources; and the obtained memory and computing characteristics required for the execution of said application; and - to assign at least said selected platform for the execution of said software application; said orchestration device (10) being characterized in that it is adapted to: - 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 received request (REQ), further obtaining transport template(s) indicating minimum transport conditions required for implementing telecommunications with said software application during its execution; said platform selection being further carried out based on the transport conditions collected and said transport template(s) obtained.;

8. Orchestration device (10) according to claim 7, wherein: - said received request (REQ) relating to said software application (APP_N) further indicates deployment requirements for the installation of said software application; and - said processing resource selection (6) is further performed according to said deployment requirements for the installation of said software application.

9. Orchestration device according to claim 7 or 8, wherein 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 must be a single platform, based on a rule relating to the transport gauges on the branches connecting them, if this reduces the need for exchanges between the selected platform and the other platforms.

10. 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 transport template(s) and current transport conditions, for the implementation of telecommunications with said software application during its execution.

Images