Method for constructing exchange rules in an architecture for exchanging data streams in a formation of mobile machines and associated central module

DE602021029968T2Active Publication Date: 2025-04-30NAVAL GRP
View PDF 0 Cites 0 Cited by

Patent Information

Application Number
DE602021029968
Authority / Receiving Office
DE · DE
Patent Type
Patents
Current Assignee / Owner
Priority Date
2020-01-28
Filing Date
2021-01-28
Publication Date
2025-04-30
Estimated Expiration
2041-01-28

AI Technical Summary

Technical Problem

Existing methods for managing data transmission in a training of mobile devices face challenges in ensuring reliable, effective, and evolving data exchanges amidst changing operational conditions and device compositions.

Method used

A central module implements a process for building exchange rules within a data flow exchange architecture, which includes negotiation with other communication platforms to ensure reserved flow rates and quality of service for privileged data flows, and dynamically manages transmission conduits to accommodate evolving data exchange needs.

Benefits of technology

This solution enables reliable and effective data exchanges that can adapt quickly to changes in the training composition and operational conditions, ensuring guaranteed quality of service for critical data flows.

✦ Generated by Eureka AI based on patent content.
Patent Text Reader
Need to check novelty before this filing date? Find Prior Art

Description

[0001] The present invention relates to a method for constructing exchange rules in a data flow exchange architecture in a formation of mobile vehicles.

[0002] The present invention also relates to a central module implementing such a construction method.

[0003] The mobile craft formation is composed in particular of ships, for example warships.

[0004] As is known per se, such devices are capable of exchanging digital data between themselves and possibly with a command center via communication links established between them.

[0005] Different methods of data exchange are described for example in FR 2 961 367 A1 (which discloses the routing of sensitive and non-sensitive -security- flows having constraints on QoS with the use of encryption and established communication rules, whose flows are classified on the basis of a QoS allocated on the basis of their priority, their bandwidth and bit rate requirements and other constraints -e.g., delay- and, depending on the sensitivity of the content, some packets are subject to priority routing over others according to a resource reservation by associating the priority level of a flow with a minimum bandwidth requirement), WO 03 / 107607 A1 (which, in order to provide a "guaranteed service" with a QoS such that the end-to-end delay for a data flow does not exceed an upper limit,the data flow is controlled by collecting its raw traffic patterns and passing the collected information to a traffic specification engine based on MBTS measurements which converts the pattern data into flow specifications reported to a QoS service provider for traffic control of data packets from a previous point A to the next point B in the network), EP 2 640 004 A1 (concerning data transfer along a path involving several nodes -control modules- which apply their forwarding rules -based on parameters to be applied- to the data flow to be transmitted, whose forwarding rules are adapted by a first control module to the complete network route based on information from a second -next- control module) or US 2018 / 213434 A1 (which is concerned with the admissibility of data flows according to the end-to-end availability of guaranteed throughput).,

[0006] Digital data can be of different natures.

[0007] For example, this data may include data streams relating to telephone exchanges between at least some of the devices. These data streams, although generally small in volume, must be transmitted as a priority in order to ensure quality of service.

[0008] The data exchanged may also include strategic data, for example, related to the ongoing battle. It is clear that this data must be transmitted not only with high priority but also with guaranteed bandwidth.

[0009] This makes it possible, in particular, to determine maximum latencies in the transmission of this data and to configure the corresponding combat systems appropriately.

[0010] The data exchanged may also include data of different confidentiality which must be encrypted to avoid their interception by a third party.

[0011] Finally, the data exchanged may also include entertainment data, for example, from people on board mobile vehicles. This data, although low priority, can have significant throughput, particularly when it comes to multimedia data.

[0012] The links that can be used to transmit these different types of data are notably radio links and have limited bandwidths.

[0013] In addition, the formation of mobile vehicles and the conditions of their operation can change rapidly.

[0014] Thus, a mobile device serving as a data transmission relay can leave the formation and another device can join it.

[0015] Furthermore, each mobile device is generally capable of changing its operational conditions quickly, for example, by switching from surveillance mode to action mode. This also changes the nature of the data exchanged by such a device.

[0016] It is therefore clear that the management of data transmission within a formation of mobile vehicles presents numerous difficulties which have not been resolved to date by existing methods and systems.

[0017] The present invention aims to resolve these difficulties and in particular, to propose data management in a formation of mobile machines allowing not only reliable and efficient exchanges within this formation but also exchanges which can evolve rapidly depending on the composition of the formation and the operational conditions of each of the mobile machines.

[0018] For this purpose, the invention relates to a construction method according to claim 1.

[0019] According to other advantageous aspects of the invention, the method for constructing exchange rules according to the invention comprises one or more characteristics of claims 2 to 11.

[0020] The present invention also relates to a central module for an architecture for exchanging data flows in a formation of mobile vehicles, the exchange architecture comprising a plurality of communication platforms and links connecting these communication platforms to each other, each communication platform being associated with one of the mobile vehicles or with a command center.

[0021] The central module includes technical means configured to implement the construction method as previously described.

[0022] These characteristics and advantages of the invention will appear on reading the description which follows, given solely as a limiting example, and made with reference to the appended drawings in which: [ Fig 1 ] there figure 1 is a schematic view of an architecture for exchanging data flows in a formation of mobile vehicles comprising a plurality of communication platforms, each communication platform being associated with a mobile vehicle or a command center; [ Fig 2 ] there figure 2 is a schematic view of one of the communication platforms of the figure 1 with links associated with this platform, the platform comprising a central module and a plurality of exchange management modules; [ Fig 3 ] there figure 3 is a detailed schematic view of one of the exchange management modules of the figure 2 ; [ Fig 4 ] [ Fig 5 ] THE figures 4 And 5are different views illustrating the operation of the exchange management module of the figure 4 ; [ Fig 6 ] there figure 6 is a flowchart of a process for constructing exchange rules implemented by the central module of the figure 2 ; [ Fig 7 ] there figure 7 is a simplified view illustrating the implementation of the method of the figure 6 ; And [ Fig 8 ] there figure 8 is a flowchart of a conduit construction and maintenance process implemented by the central module of the figure 2 .

[0023] It has in fact been illustrated on the figure 1 an architecture for exchanging 10 data flows in a formation of mobile machines.

[0024] This exchange architecture 10 comprises a plurality of communication platforms 12A to 12N and links 14 connecting at least certain pairs of these platforms.

[0025] The links 14 are formed by transmission means known per se.

[0026] Thus, each link 14 is formed between a pair of platforms 12A to 12N using one or more transmission means known per se.

[0027] These transmission means may be wireless of the same or different natures and are, for example, chosen according to the nature of the mobile machines. These transmission means may also be, at least in part, wired when, for example, the corresponding platform(s) are immobilized at least temporarily.

[0028] Preferably, each transmission means is a radio or optical transmission means, possibly passing through a satellite system and / or an aircraft or aerostat system or other types of mobile machines not forming part of said formation of mobile machines.

[0029] Each link 14 has a data transmission rate, also called the transmission capacity of this link. This rate is measurable.

[0030] Each 12A to 12N communication platform is associated with one of the formation's mobile vehicles or a command center.

[0031] In the example described, each mobile device is a vessel, for example a surface ship or a submersible vessel. The communication platform associated with such a device is therefore carried on board it.

[0032] Generally speaking, a mobile device can be any other device, for example a land device or an aircraft or even a space device.

[0033] By "command center" we mean, for example, a land-based command center including the associated communications platform.

[0034] According to other embodiments, the command center can also be mounted on board a mobile vehicle, for example of the same type as the other vehicles or of a different type.

[0035] The communication platforms 12A to 12N are, for example, substantially similar to each other. Thus, subsequently, only the communication platform 12A, for example, will be described in detail with reference to the figure 2 .

[0036] So, as it is visible on this figure 2 , the communication platform 12A comprises a plurality of security domains 21A to 21M, a switch 22, a central module 23 and a global management module 24. All of the security domains 21A to 21M of the same communication platform form a communication system of this platform.

[0037] Each security domain 21A to 21M is capable of producing data streams of a confidentiality level specific to this domain and of receiving data streams of the corresponding confidentiality level.

[0038] To do this, each security domain comprises a plurality of clients 31, a computer network 32 connecting these clients 31 to each other and an encryptor 33 making it possible to encrypt outgoing data from this domain according to their level of confidentiality and to decrypt incoming data in this domain, according to techniques known per se.

[0039] The computer network 32 is, for example, a wired LAN type network known per se.

[0040] Each client 31 presents, for example, an access terminal usable by a user or an on-board system.

[0041] Thus, each client 31 is able to produce digital data in the form of data streams and to receive digital data also in the form of digital streams.

[0042] Each data stream includes an identifier that uniquely identifies the corresponding stream. This identifier is, for example, determined by the field known as " Differentiated Services Field ". In this case, the value of this field has a DSCP type value, also known as DSCP.

[0043] According to the invention, each security domain 21A to 21M further comprises a local management module 34 connecting the computer network 32 to the encryptor 33 and making it possible to locally manage unencrypted data flows as will be explained in more detail below.

[0044] The local management module 34 of each security domain 21A to 21M is also connected to the central module 23 via a unidirectional link allowing this central module 23 to transmit data to this local management module 34 in a unidirectional manner.

[0045] The encryptor 33 of each security domain 21A to 21M is connected to the switch 22 via the global management module 24.

[0046] The global management module 24 makes it possible to manage incoming or outgoing data flows in a manner similar to that of the local management modules 34.

[0047] However, unlike these, the global management module 24 manages encrypted flows which come from or are intended for different security domains.

[0048] The global management module 24 will also be explained in more detail later.

[0049] The switch 22 makes it possible to connect the global management module 24 to the links 14 associated with the communication platform 12A.

[0050] In particular, this switch 22 makes it possible to transmit to the global management module 24 data streams received from each of the links 14. It also makes it possible to transmit each data stream leaving the platform 12A to one of the links 14 in accordance with the instructions determined by the global management module 24.

[0051] The switch 22 is further connected directly to the central module 23, thus allowing this central module 23 to exchange data with the central modules 23 of the other communication platforms 12B to 12N without going through the corresponding global management module.

[0052] Finally, advantageously according to the invention, the switch 22 is connected to each link 14 via a measuring means 40 making it possible to measure an actual flow rate of the corresponding link 14.

[0053] These measuring means 40 are capable of communicating the actual measured flow rates to the central module 23 via links provided for this purpose.

[0054] According to the invention, the central module 23 makes it possible to establish rules for managing all the data flows in the communication platform 12A by the local management modules 34 and by the global management module 24 by establishing a communication plan for this platform.

[0055] In particular, the communication plan established by the central module 23 makes it possible to designate, from among all the data flows managed by the platform 12A, data flows which must be treated as privileged.

[0056] Each privileged flow is associated with its specification including: an identifier of this flow; a source of this flow corresponding to the communication platform intended to produce this flow, also called the originating platform; a destination of this flow corresponding to the communication platform intended to receive this flow, also called the destination platform; and a quality of service of this flow.

[0057] In particular, as is known per se, the quality of service includes conditions under which this flow must be processed.

[0058] These conditions include priorities relating to this flow, latencies as well as its transmission rate.

[0059] This transmission rate can be fixed or elastic.

[0060] In case of elastic flow, this can be defined by a minimum admissible flow, i.e. by a minimum flow with which this flow must be transmitted, and an ideal flow, i.e. a flow to be granted if corresponding resources are available.

[0061] Thus, each communication plan includes a list of flow specifications allowing the definition of preferred flows with guaranteed quality of service.

[0062] To define such a communication plan, the central module 23 is able to implement a method for constructing new exchange rules 100 which will be explained in detail later.

[0063] In particular, by implementing this method 100, the central module 23 implements a negotiation with the central modules of the other communication platforms 12B to 12N in order to ensure the reserved rates for each of the privileged flows and more generally, their quality of service.

[0064] Furthermore, when implementing the method for constructing new exchange rules 100, the central module 23 is also able to implement a method for constructing and maintaining transmission conduits 200 making it possible to reserve a transmission conduit for each family of privileged flows.

[0065] By "privileged flow family" we mean all privileged flows having the same source and the same destination.

[0066] Furthermore, by "transmission conduit" for a family of flows, we mean an end-to-end path determined for each privileged flow of this family on which it is possible to reserve the flow rate requested by the specification of this flow.

[0067] Such a path therefore passes through the source of the corresponding privileged flow, its destination and when the source and the destination are not connected by one of the links 14, by one or more other communication platforms, then called relay platforms.

[0068] Each transmission conduit is formed of a plurality of conduit segments. Each conduit segment corresponds to a reserved flow rate on the link 14 connecting the source to the destination of the associated flow family, or the source or the destination to one of the relay platforms or two relay platforms between them.

[0069] Thus, the flow rate of each conduit segment is less than or equal to the total flow rate of the link 14 corresponding to this segment.

[0070] Preferably, the sum of the flow rates of the conduit segments passing over a link is strictly less than the total flow rate of the corresponding link 14. In this case, the remaining flow rate then has a minimum flow rate reserved for all non-privileged flows to be transmitted via this link.

[0071] Finally, as will be demonstrated later, the segments of the same conduit have an identical reserved flow rate for the same family of flows. Thus, each transmission conduit has a guaranteed flow rate for the corresponding family of privileged flows.

[0072] The local management modules 34 and the global management module 24 are able to receive each communication plan established by the central module 23 and, using this communication plan, to designate or recognize each privileged flow in order to ensure its transmission in accordance with this communication plan.

[0073] The local management modules 34 and the global management module 24 are also capable of ensuring the transmission of non-privileged flows according to a best effort technique known by the English name of " Best Effort ».

[0074] These management modules 24, 34 are defined substantially by the same structure which will now be explained with reference to the figure 3 .

[0075] So, as it is visible on this figure 3 , each of the management modules 24, 34 comprises a transmission queue manager 51, a dump mechanism 52 and a dump manager 53.

[0076] The transmission queue manager 51 is able to associate a queue with each data stream to be transmitted.

[0077] On the figure 3 , these queues are designated by the references FIFO#1 to FIFO#N, their number is therefore equal to N.

[0078] The transmission queue manager 51 is further capable of placing in each queue the corresponding data stream in the form of a plurality of datagrams.

[0079] The flushing mechanism 52 defines a plurality of outputs and is capable of flushing each queue by transmitting corresponding datagrams to the associated links 14 via one or more transmit outputs associated with that queue.

[0080] As illustrated in the figure 3 , the operation of the emptying mechanism 52 can be illustrated in the form of a gear having P teeth. Each tooth corresponds to an output defined by this mechanism 52.

[0081] It is further assumed that at each complete rotation of the gear, a quantity Q of bytes to be transmitted is defined. This quantity Q is defined as a function of the total throughput of the links 14 associated with the platform 12A and therefore presents an instantaneous throughput sent by the platform 12A to the links 14.

[0082] The dump manager 53 is capable of controlling the operation of the dump mechanism 52.

[0083] In particular, the emptying manager 53 is able to define for each queue FIFO#1 to FIFO#N a emptying frequency and an emptying capacity of this queue.

[0084] To define the emptying frequency for a queue, the emptying manager 53 is able to determine a number of outputs to be associated with this queue. The higher this number, the more often the corresponding queue is “visited” by the gear during the same rotation. This then makes it possible to empty this queue more quickly, which makes it possible to process the priorities of different flows.

[0085] To define the emptying capacity, the emptying manager 53 is able to associate a credit with each output q i corresponding therefore to the number of bytes taken during a "visit" by the gear of the corresponding queue knowing that a datagram cannot be split. If the credit is not sufficient to output the datagram, it will be processed in the next round, the remaining credit being added to the allocation of the next round.

[0086] It is therefore clear that the total number of credits q i granted by the manager 52 is less than or equal to Q. This then makes it possible to adjust the transmission rate of each data stream.

[0087] According to the invention, the flushing manager 53 is capable of dynamically managing the flushing frequency and the flushing capacity in order to respect the quality of service of each privileged flow and in order to transmit each non-privileged flow according to the best effort technique.

[0088] For this, the dump manager 53 is able to receive the current communication plan from the central module 23 and to designate or recognize each privileged flow in accordance with this communication plan.

[0089] Thus, each data stream not recognized by the flush manager 53 in accordance with the communication plan is treated as an unprivileged stream, i.e. according to the best effort technique.

[0090] The ability to designate or recognize privileged streams varies depending on the location of the dump manager 53.

[0091] Thus, when the dump manager 53 is located in one of the local management modules 34, it makes it possible to designate the privileged flows in accordance with the communication plan not only from their identifier, i.e. the DSCP value, but also from their unencrypted content.

[0092] In this case, the dump manager 53 is able to distinguish among data streams a privileged stream by using the unencrypted content of this stream and to mark it so that it is recognized as a privileged stream by the global management module 24 after the encryption of this stream.

[0093] This marking may include modifying the DSCP value to a predetermined value allowing a privileged flow to be securely recognized after it has been encrypted.

[0094] This is for example the case when only certain flows among a set of flows having the same DSCP value should be treated as privileged flows.

[0095] When the dump manager 53 is located in the global management module 24, it makes it possible to recognize the privileged flows in accordance with the communication plan from their identifier only which remains unencrypted after the flow has passed through the encryptor 33.

[0096] When it is a DSCP value modified by one of the local management modules 34, the dump manager 53 is able to recognize this modified DSCP value and therefore to treat this flow as a privileged flow.

[0097] As indicated previously, regardless of its location, the flush manager 53 is able to dynamically modify the flush frequency and the flush capacity of each queue in order to respect the quality of service of each privileged flow at each transmission.

[0098] Advantageously according to the invention, the emptying manager 53 is able to allocate the credits q i dynamically depending on the loading of each queue so that the sum of all the emission credits allocated is less than or equal to Q. This makes it possible in particular to ensure better service for non-privileged flows.

[0099] Thus, for example, when a conduit segment corresponding to one of the links 14 of the platform 12A has a transmission capacity not used by the privileged flows, the transmission credits are allocated by the flushing manager 53 so that at least some of the non-privileged flows use this unused transmission capacity.

[0100] This can be done locally, i.e. when the dump manager 53 is integrated into one of the local management modules 34, in relation to the privileged flows originating from the same security domain or globally, i.e. when the dump manager 53 is integrated into the global management module 24, in relation to the privileged flows originating from different security domains.

[0101] An example of implementation of this second case is illustrated in the figure 4 .

[0102] Thus, with reference to this figure, a flow rate D 1 is reserved for the privileged flows originating from security domain N 1 , a flow rate D 2 is reserved for the privileged flows originating from security domain N 2 , a flow rate D 3 is reserved for the privileged flows originating from security domain N 3 and a flow rate D 4 then presents a remaining flow rate to transmit all of the non-privileged flows F.

[0103] When the flush manager 53 determines that at least one of the reserved throughputs D 1 to D 3 is not fully used by the corresponding privileged flows, it can use this remaining capacity to allocate it to the non-privileged flows F.

[0104] So, in the example of the figure 4 , the reserved flow rate D 3 for privileged flows from security domain N 3 is not fully used, and the flow rate D 4 of non-privileged flows F is therefore temporarily increased to use the full capacity of the corresponding link 14.

[0105] This increase in the D 4 flow rate is carried out by the dump manager 53 by appropriately increasing the credits q i granted to non-privileged flows F.

[0106] It is also possible to readjust the flow rates reserved by privileged flows within the same security domain.

[0107] This can be done locally or globally.

[0108] There figure 5 illustrates an example of such an implementation by the dump manager 53 integrated into the global management module 24.

[0109] Thus, as in the previous case, a flow rate D 1 is reserved for the privileged flows from security domain N 1 , a flow rate D 2 is reserved for the privileged flows from security domain N 2 , a flow rate D 3 is reserved for the privileged flows from security domain N 3 and a flow rate D 4 then presents a remaining flow rate to transmit all the non-privileged flows F.

[0110] As regards the security domain N 1 , initially, for example, a slice of 30% of the flow D1 is reserved for the flow N 11 and a slice of 70% of the flow D1 is reserved for the flow N 12 .

[0111] The emptying manager 53 is then able to readjust these distributions between the flows N 11 and N 12 over time depending on the actual use of the corresponding slice by each of the flows.

[0112] As in the previous case, this readjustment is carried out by appropriately allocating the credits q i to these flows N 11 or N 12.

[0113] Advantageously, according to the invention, the emptying manager 53 is further capable of receiving actual flow rate information from each associated link 14 and of determining the emptying frequency and the emptying capacity of each queue as a function of each of these actual flow rates. This actual flow rate information is provided by the means 40 explained previously.

[0114] Finally, it should be noted that only the part of transmitting the data streams from the management modules 24, 34 has been explained in detail.

[0115] The receiving part, for example, has a similar structure. However, at the receiving end, there is no need to process privileged streams in any special way, since their quality of service has already been ensured upon transmission by the corresponding platform.

[0116] The process of constructing new exchange rules 100 will now be explained with reference to the figure 6 presenting a flowchart of its stages.

[0117] As indicated previously, this method is implemented by the central module 23 of one of the communication platforms 12A to 12N. Subsequently, it will be considered that this method 100 is implemented by the central module 23 of the communication platform 12A. This platform 12A will then be called the current platform and this central module will be called the current module.

[0118] It is further considered that before the implementation of the method 100, each communication platform operates in accordance with a current communication plan. The purpose of the method 100 is therefore to generate a new communication plan for all the platforms when at least one new plan specification is received.

[0119] During an initial step 110, the central module 23 acquires at least one new flow specification defining a new data flow to be transmitted by the current platform.

[0120] Different possibilities for carrying out this step 110 are possible depending on the role of the current platform 12A.

[0121] According to a first possibility, this new specification is acquired from a new plan specification submitted to platform 12A.

[0122] The submission of this new specification triggers the implementation of the method 100 and in this case, the central module 23 of this platform is then called the initiator module.

[0123] In particular, a plan specification comprises a list of stream specifications, each stream specification defining a data stream to be produced or received by the current platform as a preferred stream.

[0124] This specification is notably submitted by an operator via, for example, a human-machine interface associated with the central module 23.

[0125] To build this specification, the operator has, for example, a suitable interface.

[0126] This interface may, for example, include a list of data flows that can be used by the platform 12A and, for each flow, a reservation indicator corresponding to the desired share in the mass of data processed by the platform. A priority indicator indicating the priority of the flows may also be associated with each flow.

[0127] Thus, the operator has the possibility of modifying each of these indicators by moving, for example, a cursor on a scale associated with this indicator.

[0128] In other embodiments, the plan specification is submitted by an embedded system, an external system, or an external authority.

[0129] According to a second and a third possibility of carrying out step 110, the implementation of the method 100 is already triggered by the central module of another communication platform 12B to 12N. The central module of this other platform is then called the initiator module.

[0130] In this case, according to the second possibility, the central module 23 of the platform 12A receives from the initiator module an export message comprising at least one flow specification defining a data flow to be produced by the current platform. The central module 23 is then called the importer module.

[0131] The export message is sent by the initiator module following the implementation of a step 125 of transmitting this export message. This step 125 can also be implemented by the module 23 of the current platform in relation to the flows of which it is the destination. In this case, the current module is also an initiator module in relation to these flows. Such a step 125 can be implemented by the current module for example in parallel with step 110 or 120.

[0132] According to the third possibility, the central module 23 of the platform 12A receives a request for relaying a data flow from the central module, called the requesting module, of one of the communication platforms directly connected to the current platform. This relay request includes the specification of each flow to be relayed by the current platform 12A. In this case, the central module 23 is called the relay module.

[0133] In the following step 120, the central module 23 determines a transmission specification. This transmission specification is formed by each flow specification from the current communication plan of the platform 12A and the or each new specification acquired.

[0134] When the central module 23 is an initiator module, this central module 23 therefore includes in its transmission specification each flow specification from the current communication plan and each flow specification from the plan specification submitted during step 110.

[0135] Furthermore, in this case, the central module 23 removes from its transmission specification each flow specification originating from the current communication plan and defining a data flow of which the current platform is the source.

[0136] When the central module 23 is an importer module, this central module 23 therefore includes in its transmission specification each flow specification from the communication plan in force and each of the flow specifications from the export message acquired during step 110.

[0137] Furthermore, in this case, the central module 23 removes from its transmission specification each flow specification originating from the current communication plan and previously transmitted via an export message originating from the initiator module.

[0138] When the central module 23 is a relay module, this central module 23 therefore includes in its transmission specification each flow specification resulting from the communication plan in force and each of the flow specifications resulting from the relay request received during step 110.

[0139] Furthermore, in this case, the central module 23 removes from its transmission specification each flow specification originating from the current communication plan and previously transmitted via a relay request originating from the requesting module.

[0140] During the following step 130, the central module 23 implements the method for constructing and maintaining transmission conduits 200 making it possible to construct for each family of flows of the transmission specification a transmission conduit between the source and the destination of each of the flows of this family.

[0141] This method of constructing and maintaining transmission conduits 200 will be explained in detail later.

[0142] The following step 140 is implemented by the central module 23 for each data flow defined by the transmission specification whose destination is not connected by one of the links 14 associated with the current platform.

[0143] In other words, in this case, the destination of the corresponding flow is not directly connected to the current platform and it is necessary to go through at least one relay platform to transmit this flow.

[0144] In particular, during this step, the central module 23 transmits a request for relaying this flow to the central module, called the relay module, of one of the communication platforms directly connected to the current platform. This platform corresponding to the relay module is determined in accordance with the transmission conduit constructed during the previous step.

[0145] The relay request includes the specification of the flow for which relaying is requested.

[0146] Then, the central module 23 receives a relay report relating to the admissibility of this flow from the relay platform.

[0147] In particular, such a flow is admissible when the relay platform has the capacity to emit it as a privileged flow.

[0148] The relay report is then generated by the central module of the relay platform following the implementation of a corresponding step 145 by the central module 23 of the relay platform. Such a step 145 can also be implemented by the central module 23 of the current platform for flows for which this platform has a relay platform. In this case, this step 145 is for example implemented after step 150 explained in detail below.

[0149] During step 150, the central module 23 of the current platform 12A checks the admissibility of each data stream defined by its transmission specification.

[0150] In particular, a data stream from the transmission specification is admissible when it can be transmitted in the corresponding channel in accordance with the quality of service defined in its specification.

[0151] When a flow specification defines an elastic throughput, the quality of service of the corresponding flow is respected when this flow can be transmitted with at least the associated minimum throughput.

[0152] In addition to step 145, after step 150, the central module 23 can also implement a step 155 during which it generates and sends an admission report following a verification of the admissibility of each flow whose specification was received with the export message. This report is then sent to the destination platform of the corresponding flow.

[0153] During the final step 160, the central module 23 of the current platform 12 constructs a new communication plan of the current platform 12 by including the specifications of all the data flows defined by the transmission specification whose admissibility is confirmed.

[0154] The implementation of the method 100 can be understood more easily with reference to the figure 7 .

[0155] In the example of this figure, it is considered that the module 23 of the current platform 12A is an initiator module which receives an SA plan specification. This SA specification is for example submitted to this module 23 by the user, as explained previously.

[0156] The other central modules of the other communication platforms 12B to 12N can therefore also receive new plan specifications SB to SN and generate corresponding relay requests R and export requests E.

[0157] These R and E requests are then transmitted to the central module 23 of the current platform 12A which combines them with its SA plan specification to obtain an SE emission specification.

[0158] Finally, this module 23 generates a communication plan P by including each admissible flow from its transmission specification SE.

[0159] The method of constructing and maintaining transmission conduits 200 will now be explained with reference to the figure 8 presenting a flowchart of its stages.

[0160] As explained previously, this method 200 is implemented during step 130 of the construction method 100 by the central module 23 of the current platform 12A and makes it possible to establish a transmission conduit for each family of flows.

[0161] During step A), the module 23 constructs a conduit segment in the link 14 between the current platform 12A and a communication platform, called the next platform, for each family of flows whose flows are intended to be produced by the current platform 12A.

[0162] In particular, to do this, the central module 23 first establishes a list of legal connections from the current platform 12A according to an order of preference of these legal connections.

[0163] A link is considered legitimate when it is part of at least one path connecting the current platform 12A and the destination platform of the family flows by crossing relay platforms, the number of which is less than or equal to a predetermined maximum number of hops.

[0164] So, in the example of the figure 1, when it is necessary to construct a transmission conduit between platform 12A and platform 12N, two paths can for example be considered.

[0165] A first path through a single relay platform 12B and a second path passes first through relay platform 12C and then through relay platform 12B.

[0166] In this case, if the maximum number of hops is equal to 2, both links 14 associated with platform 12A will be considered legitimate. If, on the other hand, this maximum number of hops is equal to 1, only link 14 connecting platform 12A to platform 12B will be considered legitimate.

[0167] The order of preference of legal links is, for example, determined according to the number of relay platforms that can be used in the paths including these links.

[0168] Thus, in the previous example with the maximum number of hops equal to 2, link 14 connecting platforms 12A and 12B will be considered preferred over link 14 connecting platforms 12A and 12C.

[0169] Finally, when two legal links are part of two different paths for the same flow family, the link with a higher flow rate takes priority in the order of preference defined for these two legal links.

[0170] Then, the central module 23 classifies all of the data flows intended to be emitted by the current platform 12A according to an order of priority determined by a priority associated with each of the data flows.

[0171] Finally, the central module 23 assigns the data flows by choosing for each data flow according to the order of priority, a capacity in a link from the list of legal links according to the order of preference.

[0172] Step B) is implemented by the central module 23 when the data flows of a family of flows intended to be sent by the current platform 12A do not have the following platform as their destination.

[0173] In this case, the central module 23 sends to the central module of the following platform a request to extend the transmission conduit of this family of flows by a conduit segment constructed in the link between the following platform and a communication platform other than the current platform.

[0174] This next platform therefore constructs a next segment of the conduit in a manner analogous to that explained with reference to step A) above.

[0175] When a last segment of conduit relating to a data family reaches the destination platform of the flows of this family, the central module 23 determines during step C) a route and an end-to-end flow rate of the corresponding transmission conduit.

[0176] Finally, during step D), the central module 23 associates the transmission conduit whose route and flow rate have been analyzed with the transmission of the corresponding flow family when each conduit segment makes it possible to transmit each data flow of this flow family with a quality of service determined by the specification of this flow.

[0177] To do this, the current module 23 first determines a list of quality of service characteristics on each segment of the transmission path and deduces therefrom an overall quality of service indicator for the corresponding transmission path.

[0178] Then, it determines a list of data flows that are likely to use this transmission conduit according to its global indicator.

[0179] Advantageously, the method 200 further comprises step E) corresponding to a step of maintenance of the existing conduits.

[0180] This step E) is for example implemented independently of the other steps A) to D) when they have been implemented at least once. Thus, it can be implemented during the operation of the architecture 10.

[0181] During this step E), the current module 23 sends a conduit synthesis for each transmission conduit to each central module of the set of relay platforms corresponding to this transmission conduit at the extension of a predetermined time period.

[0182] This synthesis then allows the central modules of the corresponding communication platforms to conclude that the corresponding transmission channel is still in use.

[0183] Thus, when a relay platform does not receive a conduit synthesis relating to a transmission conduit after the predetermined time period, the corresponding central module concludes that the conduit is no longer used and destroys it.

[0184] It is therefore understood that the present invention presents a certain number of advantages.

[0185] First of all, it is clear that the architecture as described below makes it possible to define exchange rules among a plurality of communication platforms.

[0186] These rules are negotiated between all of these platforms, which makes it possible to securely identify all of the flows that must be treated as privileged and to ensure their quality of service.

[0187] Furthermore, these rules can be changed dynamically and automatically by the platforms themselves.

[0188] This is particularly advantageous when the formation of mobile machines evolves or when the conditions of their operation change.

[0189] Finally, these rules can be changed at the initiative of a user who can express in a particularly simple way the needs of the corresponding communication platform.

Claims

1. A method (100) for constructing new exchange rules in an exchange architecture (10) for data streams in a formation of mobile machines, the exchange architecture (10) comprising a plurality of communication platforms (12A,...,12N) and links (14) connecting these communication platforms (12A,...,12N) to one another, each communication platform (12A,...,12N) being associated with one of the mobile machines or with a command centre and comprising a central module (23), each platform (12A,......,12N) transmitting and receiving data streams in accordance with a current communication plan, the current communication plan comprises a list of stream specifications, each stream specification defining a data stream to be transmitted by the corresponding communication platform as a privileged stream, each specification comprising a quality of service of the corresponding stream; the construction method (100) being implemented by the central module (23), referred to as the current module, of one of the communication platforms (12A, ..., 12N), referred to as the current platform, and comprising the following steps: - acquiring (110) of at least one new stream specification defining a new data stream to be transmitted by the current platform; - determining (120) a transmission specification comprising the inclusion, in the transmission specification, of each stream specification from the current communication plan and the or each new specification acquired; - for each data stream defined by the transmission specification whose destination communication platform (12A,...,12N) is not connected directly to the current platform: + transmitting (140) a relay request for this stream to the central module (23), known as the relay module, of one of the communication platforms (12A, ..., 12N) connected directly to the current platform, the relay request comprising the specification of that stream; + receiving (140) a relay report relating to the eligibility of that stream; - verifying (150) the eligibility of each data stream defined by the transmission specification; - constructing (160) of a new communication plan for the current platform, including the specifications of all the data streams defined by the emission specification whose eligibility is confirmed.

2. The construction method (100) according to claim 1, wherein the step (110) of acquiring at least one new stream specification comprises receiving a request to relay a data stream from the central module (23), referred to as the requesting module, from one of the communication platforms (12A,....,12N) connected directly to the current platform, the relay request comprising a specification of that stream; the step of determining (120) the transmission specification comprising including the specification of that stream in the transmission specification; the construction method (100) further comprising the step of generating (145) a relay report following a verification of the eligibility of that stream.

3. The construction method (100) according to claim 2, wherein the step of determining (120) the transmission specification comprises deleting from the transmission specification each stream specification originating from the current communication plan that was previously transmitted via a relay request originating from the requesting module.

4. The construction method (100) according to any one of the preceding claims, wherein the step of acquiring (110) at least one new stream specification comprises receiving an export message from the central module (23), referred to as the initiator module, of one of the communication platforms (12A,....,12N), the export message comprising at least one stream specification defining a data stream to be sent by the current platform; the step of determining (120) the transmission specification comprising the inclusion of the or each specification of that stream in the transmission specification; the construction method (100) further comprising the step of generating (155) an eligibility report following a verification of the eligibility of that or those streams.

5. The construction method (100) according to claim 4, wherein the step of determining (120) the transmission specification comprises deleting from the transmission specification each stream specification originating from the current communication plan that was previously transmitted via an export message originating from the initiator module.

6. The construction method (100) according to any one of the preceding claims, wherein the step of acquiring (110) at least one new stream specification comprises acquiring a plan specification, the plan specification comprising a list of stream specifications, each stream specification defining a data stream to be transmitted or received by the current platform as a privileged stream; the step of determining (120) the transmission specification comprising the inclusion of each stream specification in the transmission specification.

7. The construction method (100) according to claim 6, wherein the step of determining (120) the transmission specification comprises deleting from the transmission specification each stream specification originating from the current communication plan and defining a data stream of which the current platform is a source.

8. The construction method (100) according to claim 7, further comprising the step of transmitting (125) an export message to the central module (23), known as the importer module, of at least one of the communication platforms (12A, ...12N), the export message comprising a list of stream specifications, each stream specification defining a stream to be received by the current platform and for which the communication platform (12A, ..., 12N) of the importer module is a source.

9. The construction method (100) according to any one of claims 6 to 8, wherein the plan specification is entered by an operator via a human-machine interface connected to the current module.

10. The construction method (100) according to any of the preceding claims, wherein each stream specification defining a data stream comprises: - an identifier of that stream; - a source of that stream corresponding to the communication platform (12A,...,12N) intended to generate and transmit that stream; - a destination of that stream corresponding to the communication platform (12A,...,12N) intended to receive that stream; - a rate at which this stream is to be transmitted between the source and destination.

11. The construction method (100) according to claim 10, wherein the eligibility of a data stream is confirmed by the central module (23) of one of the communication platforms (12A,...,12N), when it is possible to reserve a transmission rate for this stream in accordance with its specification, on at least one end-to-end channel connecting that communication platform (12A,...,12N) to the destination of that stream.

12. The central module (23) for a data stream exchange architecture (10) in a formation of mobile machines, the exchange architecture (10) comprising a plurality of communication platforms (12A,...,12N) and links (14) connecting these communication platforms (12A,...,12N) together, each communication platform (12A,...,12N) being associated with the one of the mobile machines or with a command centre; the central module (23) being characterised in that it comprises technical means configured to implement the steps of the construction method (100) according to any one of the preceding claims.