WO2021151998A1 - Architecture d'échanges de flux de données dans une formation d'engins mobiles - Google Patents

Architecture d'échanges de flux de données dans une formation d'engins mobiles Download PDF

Info

Publication number
WO2021151998A1
WO2021151998A1 PCT/EP2021/051959 EP2021051959W WO2021151998A1 WO 2021151998 A1 WO2021151998 A1 WO 2021151998A1 EP 2021051959 W EP2021051959 W EP 2021051959W WO 2021151998 A1 WO2021151998 A1 WO 2021151998A1
Authority
WO
WIPO (PCT)
Prior art keywords
communication
flow
privileged
platform
module
Prior art date
Application number
PCT/EP2021/051959
Other languages
English (en)
Inventor
David Hairion
Pierre Simon
Original Assignee
Naval Group
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Naval Group filed Critical Naval Group
Publication of WO2021151998A1 publication Critical patent/WO2021151998A1/fr

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W28/00—Network traffic management; Network resource management
    • H04W28/02—Traffic management, e.g. flow control or congestion control
    • H04W28/0268—Traffic management, e.g. flow control or congestion control using specific QoS parameters for wireless networks, e.g. QoS class identifier [QCI] or guaranteed bit rate [GBR]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W8/00—Network data management
    • H04W8/02—Processing of mobility data, e.g. registration information at HLR [Home Location Register] or VLR [Visitor Location Register]; Transfer of mobility data, e.g. between HLR, VLR or external networks
    • H04W8/04—Registration at HLR or HSS [Home Subscriber Server]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W72/00—Local resource management
    • H04W72/50—Allocation or scheduling criteria for wireless resources
    • H04W72/56—Allocation or scheduling criteria for wireless resources based on priority criteria

Definitions

  • TITLE Data flow exchange architecture in a mobile machine training
  • the present invention relates to a data flow exchange architecture in a formation of mobile vehicles.
  • the formation of mobile devices consists in particular of ships, for example warships.
  • such devices are suitable for exchanging digital data with each other and possibly with a command center via communication links established between them.
  • this data can comprise data flows relating to telephone exchanges between at least some of the devices. These data flows, although generally small, must be transmitted as a priority in order to ensure quality of service.
  • the data exchanged can also include strategic data, for example relating to the combat in progress. It is clear that this data must be transmitted not only with high priority but also with guaranteed bandwidth.
  • the exchanged data may also include different confidentiality data which must be encrypted in order to avoid their interception by a third party.
  • the data exchanged can also include entertainment data, for example of people on board mobile vehicles.
  • This data although low priority, can present significant data rates when it comes to multimedia data.
  • the links that can be used for transmitting these different types of data are in particular radio links and have limited bandwidths.
  • a mobile machine serving as a relay for data transmission can leave the formation and another machine can join it.
  • each mobile machine is generally able to change its operational conditions quickly, for example by switching from a surveillance mode to an action mode. It also changes the nature of the data exchanged by such a device.
  • the object of the present invention is to resolve these difficulties and in particular to provide data management in a training of mobile vehicles making it possible not only to ensure reliable and efficient exchanges within this training but also exchanges which can evolve. rapidly depending on the composition of the formation and the operational conditions of each of the mobile devices.
  • the subject of the invention is an architecture for exchanging data flows in a formation of mobile vehicles in a formation of mobile vehicles, comprising a plurality of communication platforms and links connecting these communication platforms between they, each communication platform being associated with one of the mobile vehicles or with a command center, and comprising at least one security domain capable of transmitting and receiving data streams and a switch connecting the or each security domain to connections.
  • each communication platform further comprises a central module capable of establishing a communication plan for this communication platform comprising a list of privileged flows and for each of these privileged flows, a speed of transmission reserved for this flow in a reserved bandwidth in one of the links associated with this communication platform; and in that each communication platform further comprises a global management module connected between the or each security domain and the switch of this communication platform and capable of recognizing among the set of data flows to be sent by this communication platform.
  • the exchange architecture according to the invention comprises one or more of the following characteristics, taken in isolation or according to all the technically possible combinations: the central module of each communication platform is able to establish the corresponding communication plan following a negotiation with the central modules of the other communication platforms.
  • the central module of each communication platform is connected directly to the switch of this communication platform to communicate via the corresponding links with the central modules of the other communication platforms;
  • each communication platform is able to control the issuance of data flows other than the privileged flows in accordance with a best effort technique
  • each communication platform is able to control the transmission of each privileged flow in a predetermined transmission path for this flow, each transmission path being composed of a plurality of path segments, each segment of conduit being formed by a capacity reserved in one of the links connecting a pair of communication platforms;
  • the or each security domain of each communication platform further comprises an encryption module capable of encrypting all of the data flows leaving this security domain and of decrypting all of the data flows entering this domain.
  • the global management module is able to recognize each privileged stream among encrypted data streams using an unencrypted identifier of this stream;
  • the or each security domain further comprises a local management module arranged upstream of the encryption module during the transmission of the data streams, capable of distinguishing among the data streams a privileged stream in accordance with the corresponding communication plan, and able to mark it so that it is designated as a privileged flow by the global management module after the encryption of this flow;
  • the local management module of the or each security domain of each communication platform is linked via a unidirectional link to the corresponding central module, said central module being able to transmit the corresponding communication plan to said local management module via this unidirectional link ;
  • each communication platform further comprises a measurement module for each link associated with this communication platform, said measurement module being able to measure a real throughput of this link;
  • the overall management module of each communication platform is able to readjust the bit rate for each of the privileged streams as a function of the real bit rates of the associated ducts; and the overall management module of each communication platform is able to readjust the bit rate for each of the data streams as a function of the actual use of each bandwidth reserved by the corresponding data stream.
  • Figure 1 is a schematic view of a data flow exchange architecture in a formation of mobile vehicles comprising a plurality of communication platforms, each communication platform being associated with a mobile machine or with a command center;
  • Figure 2 is a schematic view of one of the communication platforms of Figure 1 with links associated with this platform, the platform comprising a central module and a plurality of exchange management modules;
  • Figure 3 is a detailed schematic view of one of the exchange management modules of Figure 2;
  • FIG. 4 Figures 4 and 5 are different views illustrating the operation of the exchange management module of Figure 4;
  • FIG. 6 is a flowchart of a method for constructing exchange rules implemented by the central module of FIG. 2;
  • Figure 7 is a simplified view illustrating the implementation of the method of Figure 6;
  • Figure 8 is a flowchart of a process for building and maintaining conduits implemented by the central module of Figure 2.
  • FIG. 1 illustrates an architecture of exchanges 10 of data flows in a formation of mobile vehicles.
  • This exchange architecture 10 comprises a plurality of communication platforms 12A to 12N and links 14 connecting at least some pairs of these platforms.
  • the links 14 are formed by transmission means known per se.
  • each link 14 is formed between a pair of platforms 12A to 12N using one or more transmission means known per se.
  • These transmission means are optionally wireless of the same type or of different types and are for example chosen according to the nature of the mobile devices. These transmission means can also be, at least in part, wired when for example the corresponding platform or platforms are at least temporarily immobilized.
  • each transmission means is a radio or optical transmission means, possibly passing through a system of satellites and / or a system of aircraft or balloons or other types of mobile devices not forming part of said system. training of mobile devices.
  • Each link 14 has a data transmission rate, also called the transmission capacity of this link. This flow is measurable.
  • Each communication platform 12A to 12N is associated with one of the mobile training vehicles or with a command center.
  • each mobile device has a vessel, for example a surface vessel or a submersible vessel.
  • the communication platform associated with such a device is therefore on board the latter.
  • a mobile device can have any other device, for example a land vehicle or an aircraft or even a spacecraft.
  • command center is understood to mean for example a land command center then comprising the communication platform associated with it.
  • the command center can also be on board a mobile machine, for example of the same type as the other machines or else of a different nature.
  • the communication platforms 12A to 12N are for example substantially similar to each other. Thus, hereinafter, only for example the communication platform 12A will be described in detail with reference to FIG. 2.
  • the communication platform 12A comprises a plurality of security domains 21 A to 21 M, a switch 22, a central module 23 and an overall management module 24. All the domains security 21 A to 21 M of the same communication platform form a communication system of this platform.
  • Each security domain 21 A to 21 M is able to produce data flows with a confidentiality level specific to this domain and to receive data flows with the corresponding confidentiality level.
  • 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 security. confidentiality and to decrypt the incoming data in this field, according to techniques known per se.
  • the computer network 32 is for example a wired LAN type network known per se.
  • Each client 31 has, for example, an access terminal that can be used by a user or an on-board system.
  • 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.
  • Each data flow includes an identifier that uniquely identifies the corresponding flow.
  • This identifier is for example determined by the field known under the English name of “Differentiated Services Field”. In this case, the value of this field has a value of DSCP type, also known per se.
  • each security domain 21 A to 21 M 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 streams as will be explained in more detail. afterwards.
  • the local management module 34 of each security domain 21 A to 21 M 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 23 in a unidirectional manner.
  • the encryptor 33 of each security domain 21 A to 21 M is connected to the switch 22 via the global management module 24.
  • the global management module 24 makes it possible to manage incoming or outgoing data flows in a manner analogous to that of the local management modules 34.
  • the global management module 24 manages encrypted streams which originate from or are intended for different security domains.
  • the overall management module 24 will also be explained in more detail below.
  • the switch 22 makes it possible to connect the global management module 24 to the links 14 associated with the communication platform 12A.
  • this switch 22 makes it possible to transmit to the global management module 24 data flows received from each of the links 14. It also makes it possible to transmit each data flow leaving the platform 12A to one of the links 14 in accordance with the requirements. setpoints determined by the global management module 24.
  • the switch 22 is also connected directly to the central module 23, thus allowing this central module 23 to exchange data with the modules.
  • central 23 of the other communication platforms 12B to 12N without going through the corresponding global management module.
  • 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.
  • These measuring means 40 are able to communicate the actual measured flow rates to the central module 23 via links provided for this purpose.
  • the central module 23 makes it possible to establish management rules for 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 plan communication for this platform.
  • 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 to be treated as privileged.
  • Each privileged flow is associated with its specification including:
  • the quality of service includes conditions under which this flow must be processed.
  • This transmission rate can be fixed or elastic.
  • this can be defined by a minimum admissible flow, that is to say by a minimum flow with which this flow must be transmitted, and an ideal flow, i.e. say a rate to be granted if corresponding resources are available.
  • each communication plan includes a list of flow specifications thus making it possible to define privileged flows for which the quality of service is guaranteed.
  • the central module 23 is able to implement a method of constructing new exchange rules 100 which will be explained in detail below.
  • the central module 23 implements a negotiation with the central modules of the other communication platforms 12B to 12N in order to ensure the speeds reserved for each of the privileged flows and more generally, their quality. on duty.
  • the central module 23 is able to also implement a method for constructing and maintaining transmission conduits 200 making it possible to reserve a communication conduit. transmission for each family of privileged flows.
  • family of privileged flows is meant all of the privileged flows having the same source and the same destination.
  • transmission path for a family of flows is understood to mean an end-to-end path determined for each privileged flow of this family on which it is possible to reserve the rate requested by the specification of this flow.
  • 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.
  • Each transmission conduit is formed from a plurality of conduit segments.
  • Each channel segment corresponds to a flow rate reserved on the link 14 connecting the source to the destination of the associated family of flows, or the source or the destination to one of the relay platforms or two relay platforms between them.
  • the throughput of each path segment is less than or equal to the total throughput of the link 14 corresponding to this segment.
  • the sum of the bit rates of the path segments passing over a link is strictly less than the total bit rate of the corresponding link 14.
  • the remaining bit rate then has a minimum bit rate reserved for all of the non-privileged streams to be transmitted via this link.
  • each transmission path has an identical reserved rate for the same family of flows.
  • each transmission path has a guaranteed throughput for the corresponding privileged stream family.
  • 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 to this communication plan.
  • the local management modules 34 and the global management module 24 are also able to ensure the transmission of non-privileged flows according to a best effort technique known under the English name of “Best Effort”.
  • management modules 24, 34 are defined substantially by the same structure which will now be explained with reference to FIG. 3.
  • each of the management modules 24, 34 comprises a transmission queue manager 51, a dump mechanism 52 and a dump manager 53.
  • the transmission queue manager 51 is able to associate a queue with each data stream to be transmitted.
  • the transmission queue manager 51 is further adapted to place in each queue the corresponding data stream in the form of a plurality of datagrams.
  • the dump mechanism 52 defines a plurality of outputs and able to empty each queue by sending corresponding datagrams to the associated links 14 via one or more send outputs associated with that queue.
  • the operation of the emptying mechanism 52 can be illustrated as a gear having P teeth. Each tooth corresponds to an outlet defined by this mechanism 52.
  • a quantity Q of bytes to be transmitted is defined.
  • This quantity Q is defined as a function of the total bit rate of the links 14 associated with the platform 12A and therefore has an instantaneous bit rate sent by the platform 12A to the links 14.
  • the emptying manager 53 is able to control the operation of the emptying mechanism 52.
  • the dump manager 53 is able to define for each FIFO # 1 to FIFO # N queue a dump frequency and a capacity for emptying this 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.
  • the emptying manager 53 is able to associate with each output a credit q t therefore corresponding 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 endowment for the next round.
  • the emptying manager 53 is able to dynamically manage the emptying frequency and the emptying capacity in order to respect the quality of service of each privileged stream and in order to send each non-privileged stream according to the best technique. effort.
  • 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.
  • each data stream not recognized by the dump manager 53 in accordance with the communication plan is treated as a non-privileged stream, that is to say according to the best effort technique.
  • the ability to designate or recognize privileged streams varies depending on the location of the dump manager 53.
  • the dump manager 53 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, that is to say from the DSCP value, but also from their unencrypted content.
  • the dump manager 53 is able to distinguish among the 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 user. global management module 24 after the encryption of this stream.
  • This marking can comprise the modification of the DSCP value for a predetermined value making it possible to recognize in a sure manner a privileged flow after the encryption of the latter.
  • the dump manager 53 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 to from their identifier only which remains unencrypted after the flow has passed through the encryptor 33.
  • the dump manager 53 is able to recognize this modified DSCP value and therefore to treat this flow as a privileged flow.
  • the dump manager 53 is able to dynamically modify the dump frequency and the dump capacity of each queue in order to respect the quality of service of each privileged stream at each transmission.
  • the emptying manager 53 is able to allocate the credits dynamically depending on the loading of each queue so that the sum of all the allocated emission credits is less than or equal to Q. This allows in particular to ensure a better service for non-privileged flows .
  • the emission credits are allocated by the emptying manager 53 of so that at least some of the unprivileged flows use this unused transmission capacity.
  • a flow rate Di is reserved for the privileged flows originating from the security domain Ni
  • a flow rate D 2 is reserved for the privileged flows originating from the security domain N 2
  • a flow rate D 3 is reserved for the privileged flows coming from the security domain N 3
  • a flow D4 then has a remaining flow to transmit all the non-privileged flows F.
  • the dump manager 53 determines that at least one of the reserved flows D1 to D 3 is not used entirely by the corresponding privileged flows, it can use this remaining capacity to allocate it to the non-privileged flows F.
  • the reserved rate D 3 for the privileged streams originating from the security domain N 3 is not used entirely, and the rate D4 for non-streams. privileged F is therefore temporarily increased to use all the capacity of the corresponding link 14.
  • This increase in flow D is carried out by the emptying manager 53 by appropriately increasing the credits q t granted to non-privileged flows F.
  • FIG. 5 illustrates an example of such an implementation by the dump manager 53 integrated into the global management module 24.
  • a flow rate Di is reserved for the privileged flows originating from the security domain Ni
  • a flow rate D 2 is reserved for the privileged flows originating from the security domain N 2
  • a flow rate D 3 is reserved for the privileged flows originating from the security domain N 3
  • a rate D 4 then presents a remaining rate for transmitting all of the non-privileged flows F.
  • a slice of 30% of the rate D1 is reserved for the stream Nu and a slice of 70% of the rate D1 is reserved for the stream N I2 .
  • the emptying manager 53 is then able to readjust these distributions between the streams Nu and N I2 over time as a function of the actual use of the corresponding slot by each of the streams.
  • this readjustment is carried out by appropriately allocating the credits q t to these flows Nu or N I2 .
  • the emptying manager 53 is also able to receive information on the actual flow rate of each associated link 14 and to determine the emptying frequency and the emptying capacity of each queue as a further function. of each of these actual rates.
  • This actual bit rate information is provided by the means 40 explained previously.
  • the receiving part has, for example, a similar structure. However, on reception, it is not necessary to treat the privileged flows in any particular way since their quality of service has already been ensured during the transmission by the corresponding platform.
  • the method of constructing new exchange rules 100 will henceforth be explained with reference to FIG. 6 presenting a flowchart of its steps. As indicated above, 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 below and this central module will be called the current module.
  • each communication platform operates in accordance with a communication plan in force.
  • the purpose of method 100 is therefore to generate a new communication plan for all of the platforms when at least one new plan specification is received.
  • the central module 23 acquires at least one new flow specification defining a new data flow to be sent by the current platform.
  • this new specification is acquired from a new plan specification submitted to the 12A platform.
  • a plan specification includes a list of flow specifications, each flow specification defining a data flow to be produced or received by the current platform as a privileged flow.
  • the operator has, for example, a suitable interface.
  • This interface can for example comprise 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 can also be associated with each flow.
  • the operator has the possibility of modifying each of these indicators by, for example, moving a cursor on a scale associated with this indicator.
  • the plan specification is submitted by an on-board system, an external system or else an external authority.
  • 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.
  • the central module 23 of the platform 12A receives from the initiating 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.
  • the export message is sent by the initiating module following the implementation of a step 125 for transmitting this export message.
  • This step 125 can also be implemented by the module 23 of the current platform in relation to the flows for which it is the destination.
  • 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.
  • the central module 23 of the platform 12A receives a request for relaying a data flow from the central module, called the requesting module, from one of the communication platforms connected directly to the current platform.
  • This relaying request comprising the specification of each flow to be relayed by the current platform 12A.
  • the central module 23 is called the relay module.
  • the central module 23 determines an emission specification. This emission specification is formed by each flow specification resulting from the communication plan in force for the platform 12A and from the or each new specification acquired.
  • this central module 23 When the central module 23 is an initiator module, this central module 23 therefore includes in its transmission specification each flow specification resulting from the communication plan in force and each flow specification from the plan specification submitted during step 110 .
  • the central module 23 removes from its transmission specification each flow specification resulting from the communication plan in force and defining a data flow of which the current platform is the source.
  • this central module 23 When the central module 23 is an importer 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 export message acquired during the step 110. In addition, in this case, the central module 23 removes from its transmission specification each flow specification resulting from the communication plan in force and transmitted previously via an export message originating from the initiating module.
  • this central module 23 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 relaying request received during the transmission. 'step 110.
  • the central module 23 removes from its transmission specification each flow specification resulting from the communication plan in force and transmitted previously via a relay request from the requesting module.
  • the central module 23 implements the method for constructing and maintaining transmission paths 200 making it possible to construct, for each family of flows of the transmission specification, a transmission path between the source and the source. destination of each of the flows of this family.
  • 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.
  • 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.
  • 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 connected directly to the current platform.
  • This platform corresponding to the relay module is determined in accordance with the transmission duct constructed in the previous step.
  • the relaying request includes the specification of the flow for which the relaying is requested.
  • the central module 23 receives a relaying report relating to the admissibility of this flow from the relay platform.
  • the relaying 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.
  • 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.
  • this step 145 is for example implemented after step 150 explained in detail below.
  • step 150 the central module 23 of the current platform 12A verifies the admissibility of each data stream defined by its emission specification.
  • a data flow resulting from the transmission specification is admissible when it can be transmitted in the corresponding path in accordance with the quality of service defined in its specification.
  • the quality of service of the corresponding flow is respected when this flow can be transmitted with at least the associated minimum rate.
  • 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 stream. whose specification was received with the export message. This report is then sent to the destination platform of the corresponding flow.
  • the central module 23 of the current platform 12 constructs a new communication plan for the current platform 12 by including therein the specifications of all the data flows defined by the transmission specification, including the admissibility is confirmed.
  • the module 23 of the current platform 12A is an initiator module which receives a plan specification S A.
  • This specification S A is for example submitted to this module 23 by the user, as has been explained previously.
  • the other central modules of the other communication platforms 12B to 12N can therefore also receive new plan specifications S B to S N and generate relaying requests R and corresponding export requests E.
  • this module 23 generates a communication plan P by including therein each admissible flow from its emission specification SE.
  • the method of constructing and maintaining transmission conduits 200 will henceforth be explained with reference to FIG. 8 presenting a flowchart of its steps. 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 path for each family of flows.
  • step A) the module 23 constructs a segment of the path 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.
  • the central module 23 first establishes a list of legal links from the current platform 12A in an order of preference of these legal links.
  • a link is considered lawful when it forms part of at least one path connecting the current platform 12A and the destination platform for the flows of the family by crossing relay platforms, the number of which is less than or equal to a number of hops. predetermined maximum.
  • two paths can for example be considered.
  • 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.
  • the maximum number of hops is equal to 2
  • the two links 14 associated with platform 12A will be considered as lawful. If, on the other hand, this maximum number of hops is equal to 1, only the link 14 connecting the platform 12A to the platform 12B will be considered as lawful.
  • the order of preference of the legal links is for example determined according to the number of relay platforms that can be used in the paths comprising these links.
  • the link 14 connecting the platforms 12A and 12B will be considered as preferred over the link 14 connecting the platforms 12A and 12C.
  • the central module 23 classifies all of the data flows intended to be sent by the current platform 12A according to an order of priority determined by a priority associated with each of the data flows. 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 licit links according to the order of preference.
  • 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 are not intended for the next platform.
  • the central module 23 sends to the central module of the following platform a request for the extension of the transmission path of this family of flows by a path segment constructed in the link between the following platform and a communication platform other than the current platform.
  • This next platform therefore builds a next segment of the conduit in a manner analogous to that explained with reference to step A) above.
  • the central module 23 determines during step C) a route and an end-to-end rate of the corresponding transmission path .
  • step D) the central module 23 associates the transmission path whose route and bit rate have been analyzed with the transmission of the corresponding family of flows when each path segment makes it possible to transmit each data flow of this family of flows with a quality of service determined by the specification of this flow.
  • 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.
  • the method 200 further comprises step E) corresponding to a maintenance step of the existing conduits.
  • 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.
  • the current module 23 sends a path synthesis for each transmission path to each central module of all the relay platforms corresponding to this transmission path at the extension of a predetermined time period. This synthesis then allows the central modules of the corresponding communication platforms to conclude that the corresponding transmission path is still in use.
  • the present invention has a certain number of advantages. First of all, it is clear that the architecture as described below makes it possible to define rules for exchanges among a plurality of communication platforms.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Databases & Information Systems (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

La présente invention concerne une architecture d'échanges (10) de flux de données dans une formation d'engins mobiles, comprenant une pluralité de plateformes de communication (12A,...,12N) et des liaisons (14) raccordant ces plateformes de communication (12A,...,12N) entre elles. Chaque plateforme de communication (12A,...,12N) comprend en outre un module central apte à établir un plan de communication comprenant une liste de flux privilégiés et pour chacun de ces flux privilégiés, un débit de transmission réservé pour ce flux. Chaque plateforme de communication (12A,...,12N) comprend en outre un module de gestion global apte à reconnaître parmi l'ensemble des flux de données à émettre des flux privilégiés conformément au plan de communication correspondant.

Description

DESCRIPTION
TITRE : Architecture d’échanges de flux de données dans une formation d’engins mobiles
La présente invention concerne une architecture d’échanges de flux de données dans une formation d’engins mobiles.
La formation d’engins mobiles est notamment composée de navires, par exemple de navires de guerre.
De manière connue en soi, de tels engins sont propres à échanger des données numériques entre eux et éventuellement avec un centre de commandement via des liaisons de communication établies entre eux.
Ces données numériques peuvent être de différentes natures.
Ainsi, par exemple, ces données peuvent comprendre des flux de données relatives aux échanges téléphoniques entre au moins certains des engins. Ces flux de données, bien que généralement peu volumineux, doivent être transmis en priorité afin d’assurer la qualité de service.
Les données échangées peuvent comprendre également des données stratégiques par exemple relatives au combat en cours. Il est clair que ces données doivent être transmises non-seulement avec une grande priorité mais également avec une bande passante garantie.
Cela permet notamment de déterminer des latences maximales dans les transmissions de ces données et de configurer de manière adaptée les systèmes de combat correspondants.
Les données échangées peuvent comprendre également des données de confidentialités différentes qui doivent être chiffrées afin d’éviter leur interception par une partie tierce.
Enfin, les données échangées peuvent comprendre également des données de divertissement par exemple des personnes se trouvant à bord des engins mobiles. Ces données, bien que peu prioritaires, peuvent présenter des débits importants lorsqu’il s’agit notamment des données multimédia.
Les liaisons utilisables pour transmettre ces différents types de données sont notamment des liaisons radio et présentent des bandes passantes limitées.
En outre, la formation elle-même d’engins mobiles et les conditions de leur opération peuvent évoluer rapidement. Ainsi, un engin mobile servant de relai de transmission des données peut quitter la formation et un autre engin peut la rejoindre.
En outre, chaque engin mobile est généralement capable de modifier ses conditions opérationnelles rapidement en passant par exemple d’un mode de surveillance à un mode d’action. Cela change également la nature des données échangées par un tel engin.
On conçoit alors que la gestion de transmission des données au sein d’une formation d’engins mobiles présente de nombreuses difficultés qui n’ont pas été résolues à ce jour par les méthodes et systèmes existants.
La présente invention a pour objet de résoudre ces difficultés et en particulier, de proposer une gestion de données dans une formation d’engins mobiles permettant non- seulement d’assurer des échanges fiables et efficaces au sein de cette formation mais également des échanges pouvant évoluer rapidement en fonction de la composition de la formation et des conditions opérationnelles de chacun des engins mobiles.
À cet effet, l’invention a pour objet une architecture d’échanges de flux de données dans une formation d’engins mobiles dans une formation d’engins mobiles, comprenant une pluralité de plateformes de communication et des liaisons raccordant ces plateformes de communication entre elles, chaque plateforme de communication étant associée à l’un des engins mobiles ou à un centre de commandement, et comprenant au moins un domaine de sécurité apte à émettre et à recevoir des flux de données et un commutateur raccordant le ou chaque domaine de sécurité aux liaisons.
L’architecture d’échanges est caractérisée en ce que chaque plateforme de communication comprend en outre un module central apte à établir un plan de communication pour cette plateforme de communication comprenant une liste de flux privilégiés et pour chacun de ces flux privilégiés, un débit de transmission réservé pour ce flux dans une bande passante réservée dans l’une des liaisons associée à cette plateforme de communication; et en ce que chaque plateforme de communication comprend en outre un module de gestion global raccordé entre le ou chaque domaine de sécurité et le commutateur de cette plateforme de communication et apte à reconnaître parmi l’ensemble des flux de données à émettre par cette plateforme de communication, des flux privilégiés conformément au plan de communication correspondant et à contrôler l’émission de chaque flux privilégié selon le débit réservé pour ce flux conformément au plan de communication.
Suivant d’autres aspects avantageux de l’invention, l’architecture d’échanges selon l’invention comprend une ou plusieurs des caractéristiques suivantes, prises isolément ou suivant toutes les combinaisons techniquement possibles : le module central de chaque plateforme de communication est apte à établir le plan de communication correspondant à la suite d’une négociation avec les modules centraux des autres plateformes de communication .
- le module central de chaque plateforme de communication est raccordé directement au commutateur de cette plateforme de communication pour communiquer via les liaisons correspondantes avec les modules centraux des autres plateformes de communication ;
- le module de gestion global de chaque plateforme de communication est apte à contrôler l’émission des flux de données autres que les flux privilégiés conformément à une technique de meilleur effort ;
- le module de gestion global de chaque plateforme de communication est apte à contrôler l’émission de chaque flux privilégié dans un conduit de transmission prédéterminé pour ce flux, chaque conduit de transmission étant composé d’une pluralité de segments de conduit, chaque segment de conduit étant formé par une capacité réservée dans l’une des liaisons raccordant un couple de plateformes de communication ;
- le ou chaque domaine de sécurité de chaque plateforme de communication comprend en outre un module de chiffrage apte à chiffrer l’ensemble des flux de données sortant de ce domaine de sécurité et à déchiffrer l’ensemble des flux de données entrant dans ce domaine de sécurité ;
- le module de gestion global est apte à reconnaître chaque flux privilégié parmi des flux de données chiffrés en utilisant un identifiant non-chiffré de ce flux ;
- le ou chaque domaine de sécurité comprend en outre un module de gestion local disposé en amont du module de chiffrage lors de l’émission des flux de données, apte à distinguer parmi des flux de données un flux privilégié conformément au plan de communication correspondant, et apte à le marquer afin qu’il soit désigné en tant qu’un flux privilégié par le module de gestion global après le chiffrement de ce flux ;
- le module de gestion local du ou de chaque domaine de sécurité de chaque plateforme de communication est relié via un lien unidirectionnel au module central correspondant, ledit module central étant apte à transmettre le plan de communication correspondant audit module de gestion local via ce lien unidirectionnel ;
- chaque plateforme de communication comprend en outre un module de mesure pour chaque liaison associée à cette plateforme de communication, ledit module de mesure étant apte à mesurer un débit réel de cette liaison ;
- le module de gestion global de chaque plateforme de communication est apte à réajuster le débit pour chacun des flux privilégiés en fonction des débits réels des conduits associés ; et - le module de gestion global de chaque plateforme de communication est apte à réajuster le débit pour chacun des flux de données en fonction de l’utilisation réelle de chaque bande passante réservée par le flux de données correspondant.
Ces caractéristiques et avantages de l’invention apparaîtront à la lecture de la description qui va suivre, donnée uniquement à titre d’exemple limitatif, et faite en référence aux dessins annexés sur lesquels :
- [Fig 1] la figure 1 est une vue schématique d’une architecture d’échanges de flux de données dans une formation d’engins mobiles comprenant une pluralité de plateformes de communication, chaque plateforme de communication étant associée à un engin mobile ou à un centre de commandement ;
- [Fig 2] la figure 2 est une vue schématique de l’une des plateformes de communication de la figure 1 avec des liaisons associées à cette plateforme, la plateforme comprenant un module central et une pluralité de modules de gestion d’échanges ;
- [Fig 3] la figure 3 est une vue schématique en détail de l’un des modules de gestion d’échanges de la figure 2 ;
- [Fig 4] [Fig 5] les figures 4 et 5 sont différentes vues illustrant le fonctionnement du module de gestion d’échanges de la figure 4 ;
- [Fig 6] la figure 6 est un organigramme d’un procédé de construction de règles d’échanges mis en œuvre par le module central de la figure 2 ;
- [Fig 7] la figure 7 est une vue simplifiée illustrant la mise en œuvre du procédé de la figure 6 ; et
- [Fig 8] la figure 8 est un organigramme d’un procédé de construction et de maintien de conduits mis en œuvre par le module central de la figure 2.
On a en effet illustré sur la figure 1 une architecture d’échanges 10 de flux de données dans une formation d’engins mobiles.
Cette architecture d’échanges 10 comprend une pluralité de plateformes de communication 12A à 12N et des liaisons 14 raccordant au moins certains couples de ces plateformes.
Les liaisons 14 sont formées par des moyens de transmission connus en soi.
Ainsi, chaque liaison 14 est formée entre un couple de plateformes 12A à 12N en utilisant un ou plusieurs moyens de transmission connus en soi.
Ces moyens de transmission sont éventuellement sans fil de même nature ou de natures différentes et sont par exemple choisis en fonction de la nature des engins mobiles. Ces moyens de transmission peuvent aussi être, au moins en partie, filaires lorsque par exemple la ou les plateformes correspondantes sont immobilisées au moins temporairement.
De préférence, chaque moyen de transmission est un moyen de transmission radio ou optique, passant éventuellement par un système de satellites et/ou un système d’aéronefs ou d’aérostats ou d’autres types d’engins mobiles ne faisant pas partie de ladite formation d’engins mobiles.
Chaque liaison 14 présente un débit de transmission de données, appelé également capacité de transmission de cette liaison. Ce débit est mesurable.
Chaque plateforme de communication 12A à 12N est associée à l’un des engins mobiles de la formation ou à un centre de commandement.
Dans l’exemple décrit, chaque engin mobile présente un navire, par exemple un navire de surface ou un navire submersible. La plateforme de communication associée à un tel engin est donc embarquée à bord de celui-ci.
De manière générale, un engin mobile peut présenter tout autre engin, par exemple un engin terrestre ou un aéronef ou encore un engin spatial.
Par « centre de commandement », on entend par exemple un centre de commandement terrestre comportant alors la plateforme de communication qui lui est associée.
Selon d’autres exemples de réalisation, le centre de commandement peut être embarqué également à bord d’un engin mobile, par exemple de même nature que les autres engins ou alors d’une nature différente.
Les plateformes de communication 12A à 12N sont par exemple sensiblement analogues entre elles. Ainsi, par la suite, seule par exemple la plateforme de communication 12A sera décrite en détail en référence à la figure 2.
Ainsi, comme cela est visible sur cette figure 2, la plateforme de communication 12A comprend une pluralité de domaines de sécurité 21 A à 21 M, un commutateur 22, un module central 23 et un module de gestion global 24. L’ensemble des domaines de sécurité 21 A à 21 M d’une même plateforme de communication forment un système de communication de cette plateforme.
Chaque domaine de sécurité 21 A à 21 M est apte à produire des flux de données d’un niveau de confidentialité propre à ce domaine et à recevoir des flux de données du niveau de confidentialité correspondant.
Pour ce faire, chaque domaine de sécurité comprend une pluralité de clients 31 , un réseau informatique 32 raccordant ces clients 31 entre eux et un chiffreur 33 permettant de chiffrer des données sortantes de ce domaine selon leur niveau de confidentialité et de déchiffrer les données entrantes dans ce domaine, selon des techniques connues en soi.
Le réseau informatique 32 est par exemple un réseau filaire de type LAN connu en soi.
Chaque client 31 présente par exemple un terminal d’accès utilisable par un utilisateur ou un système embarqué.
Ainsi, chaque client 31 est apte à produire des données numériques sous la forme de flux de données et à recevoir des données numériques également sous la forme de flux numériques.
Chaque flux de données comprend un identifiant permettant d’identifier de manière unique le flux correspondant. Cet identifiant est par exemple déterminé par le champ connu sous la nom anglais de « Differentiated Services Field ». Dans ce cas, la valeur de ce champ présente une valeur de type DSCP, également connue en soi.
Selon l’invention, chaque domaine de sécurité 21 A à 21 M comprend en outre un module de gestion local 34 raccordant le réseau informatique 32 au chiffreur 33 et permettant de gérer localement des flux de données non-chiffrés comme cela sera expliqué plus en détail par la suite.
Le module de gestion local 34 de chaque domaine de sécurité 21 A à 21 M est par ailleurs raccordé au module central 23 via un lien unidirectionnel permettant à ce module central 23 de transmettre des données vers ce module de gestion local 23 de manière unidirectionnelle.
Le chiffreur 33 de chaque domaine de sécurité 21 A à 21 M est raccordé au commutateur 22 via le module de gestion global 24.
Le module de gestion global 24 permet de gérer des flux de données entrants ou sortants de manière analogue à celle des modules de gestion locaux 34.
Toutefois, contrairement à ceux-ci, le module de gestion global 24 gère des flux chiffrés qui sont issus ou destinés à des différents domaines de sécurité.
Le module de gestion global 24 sera également expliqué plus en détail par la suite.
Le commutateur 22 permet de raccorder le module de gestion global 24 aux liaisons 14 associées à la plateforme de communication 12A.
En particulier, ce commutateur 22 permet de transmettre au module de gestion global 24 des flux de données reçus de chacune des liaisons 14. Il permet en outre de transmettre chaque flux de données sortant de la plateforme 12A à l’une des liaisons 14 conformément aux consignes déterminées par le module de gestion global 24.
Le commutateur 22 est raccordé en outre directement au module central 23 en permettant ainsi à ce module central 23 d’échanger des données avec les modules centraux 23 des autres plateformes de communication 12B à 12N sans passer par le module de gestion global correspondant.
Finalement, avantageusement selon l’invention, le commutateur 22 est raccordé à chaque liaison 14 via un moyen de mesure 40 permettant de mesurer un débit réel de la liaison 14 correspondante.
Ces moyens de mesure 40 sont aptes à communiquer les débits réels mesurés au module central 23 via des liens prévus à cet effet.
Selon l’invention, le module central 23 permet d’établir des règles de gestion de l’ensemble des flux de données dans la plateforme de communication 12A par les modules de gestion locaux 34 et par le module de gestion global 24 en établissant un plan de communication pour cette plateforme.
En particulier, le plan de communication établi par le module central 23 permet de désigner parmi l’ensemble des flux de données gérés par la plateforme 12A, des flux de données devant être traités comme privilégiés.
Chaque flux privilégié est associé à sa spécification comprenant :
- un identifiant de ce flux ;
- une source de ce flux correspondant à la plateforme de communication destinée à produire ce flux, appelée également plateforme d’origine ;
- une destination de ce flux correspondant à la plateforme de communication destinées à recevoir ce flux, appelée également plateforme de destination ; et
- une qualité de service de ce flux.
En particulier, de manière connue en soi, la qualité de service comprend des conditions dans lesquelles ce flux doit être traité.
Ces conditions comprennent notamment des priorités relatives à ce flux, des latences ainsi que son débit de transmission.
Ce débit de transmission peut être fixe ou élastique.
En cas d’un débit élastique, celle-ci peut être défini par un débit minimal admissible, c’est-à-dire par un débit minimal avec lequel ce flux doit être transmis, et un débit idéal, c’est-à-dire un débit devant être accordé si des ressources correspondantes sont disponibles.
Ainsi, chaque plan de communication comprend une liste de spécifications de flux permettant ainsi de définir des flux privilégiés dont la qualité de service est garantie.
Pour définir un tel plan de communication, le module central 23 est apte à mettre en œuvre un procédé de construction de nouvelles règles d’échanges 100 qui sera expliqué en détail par la suite. En particulier, en mettant en œuvre ce procédé 100, le module central 23 met en œuvre une négociation avec les modules centraux des autres plateformes de communication 12B à 12N afin d’assurer les débits réservés pour chacun des flux privilégiés et plus globalement, leur qualité de service.
En outre, lors de la mise en œuvre du procédé de construction de nouvelles règles d’échanges 100, le module central 23 est apte à mettre en œuvre également un procédé de construction et de maintien de conduits de transmission 200 permettant de réserver un conduit de transmission pour chaque famille de flux privilégiés.
Par « famille de flux privilégiés », on entend l’ensemble des flux privilégiés ayant une même source et une même destination.
En outre, par « conduit de transmission » pour une famille de flux, on entend un chemin de bout en bout déterminé pour chaque flux privilégié de cette famille sur lequel il est possible de réserver le débit demandé par la spécification de ce flux.
Un tel chemin passe donc par la source du flux privilégié correspondant, sa destination et lorsque la source et la destination ne sont pas raccordées par l’une des liaisons 14, par une ou plusieurs autres plateformes de communication, appelées alors plateformes de relai.
Chaque conduit de transmission est formé d’une pluralité de segments de conduit. Chaque segment de conduit correspond à un débit réservé sur la liaison 14 raccordant la source à la destination de la famille de flux associée, ou la source ou la destination à l’une des plateformes de relai ou deux plateformes de relai entre elles.
Ainsi, le débit de chaque segment de conduit est inférieur ou égal au débit total de la liaison 14 correspondant à ce segment.
De préférence, la somme des débits des segments de conduit passant sur une liaison est strictement inférieure au débit total de la liaison 14 correspondante. Dans ce cas, le débit restant présente alors un débit minimal réservé pour l’ensemble des flux non- privilégiés devant être transmis via cette liaison.
Enfin, comme cela sera démontré par la suite, les segments d’un même conduit présentent un débit réservé identique pour une même famille de flux. Ainsi, chaque conduit de transmission présente un débit garanti pour la famille de flux privilégiés correspondante.
Les modules de gestion locaux 34 et le module de gestion global 24 sont aptes à recevoir chaque plan de communication établi par le module central 23 et en utilisant ce plan de communication, à désigner ou à reconnaître chaque flux privilégié afin d’assurer son émission conformément à ce plan de communication. Les modules de gestion locaux 34 et le module de gestion global 24 sont aptes en outre à assurer l’émission des flux non-privilégiés selon une technique de meilleur effort connue sous la nom anglais de « Best Effort ».
Ces modules de gestion 24, 34 sont définies sensiblement par une même structure que sera désormais expliquée en référence à la figure 3.
Ainsi, comme cela est visible sur cette figure 3, chacun des modules de gestion 24, 34 comprend un gestionnaire de files d’émission 51, un mécanisme de vidage 52 et un gestionnaire de vidage 53.
Le gestionnaire de files d’émission 51 est apte à associer à chaque flux de données à émettre une file d’attente.
Sur la figure 3, ces files d’attente sont désignées par les références FIFO#1 à FIFO#N, leur nombre est donc égal à N.
Le gestionnaire de files d’émission 51 est apte en outre à placer dans chaque file d’attente le flux de données correspondant sous une forme d’une pluralité de datagrammes.
Le mécanisme de vidage 52 définit une pluralité de sorties et apte à vider chaque file d’attente en émettant des datagrammes correspondants vers les liaisons 14 associées via une ou plusieurs sorties d’émission associées à cette file d’attente.
Comme illustré sur la figure 3, le fonctionnement du mécanisme de vidage 52 peut s’illustrer sous la forme d’un engrenage ayant P dents. Chaque dent correspond à une sortie définie par ce mécanisme 52.
Il est par ailleurs supposé qu’à chaque rotation complète de l’engrenage, une quantité Q d’octets à transmettre est définie. Cette quantité Q est définie en fonction du débit total des liaisons 14 associées à la plateforme 12A et présente donc un débit instantané envoyé par la plateforme 12A vers les liaisons 14.
Le gestionnaire de vidage 53 est apte à contrôler le fonctionnement du mécanisme de vidage 52.
En particulier, le gestionnaire de vidage 53 est apte à définir pour chaque file d’attente FIFO#1 à FIFO#N une fréquence de vidage et une capacité de vidage de cette file d’attente.
Pour définir la fréquence de vidage à une file d’attente, le gestionnaire de vidage 53 est apte à déterminer un nombre de sorties à associer à cette file d’attente. Plus ce nombre est élevé, plus souvent la file d’attente correspondante est « visitée » par l’engrenage lors d’une même rotation. Cela permet alors de vider plus rapidement cette file d’attente ce qui permet de traiter les priorités de différents flux. Pour définir la capacité de vidage, le gestionnaire de vidage 53 est apte à associer à chaque sortie un crédit qt correspondant donc au nombre d’octets pris lors d’une « visite » par l’engrenage de la file d’attente correspondante sachant qu’un datagramme ne peut pas être scindé. Si le crédit n’est pas suffisant pour sortir le datagramme, il sera traité au prochain tour, le crédit restant étant additionné à la dotation du prochain tour.
Il est donc clair que le nombre total des crédits qt accordés par le gestionnaire 53 est inférieur ou égal à Q. Cela permet alors de régler le débit d’émission de chaque flux de données.
Selon l’invention, le gestionnaire de vidage 53 est apte à gérer dynamiquement la fréquence de vidage et la capacité de vidage afin de respecter la qualité de service de chaque flux privilégié et afin d’émettre chaque flux non-privilégié selon la technique de meilleur effort.
Pour cela, le gestionnaire de vidage 53 est à apte à recevoir le plan de communication en cours de la part du module central 23 et à désigner ou à reconnaître chaque flux privilégié conformément à ce plan de communication.
Ainsi, chaque flux de données non-reconnu par le gestionnaire de vidage 53 conformément au plan de communication est traité comme un flux non-privilégié, c’est-à- dire selon la technique de meilleur effort.
La capacité de désigner ou de reconnaître les flux privilégiés varie en fonction de l’emplacement du gestionnaire de vidage 53.
Ainsi, lorsque le gestionnaire de vidage 53 est situé dans l’un des modules de gestion locaux 34, il permet de désigner les flux privilégiés conformément au plan de communication non-seulement à partir de leur identifiant, c’est-à-dire de la valeur DSCP, mais également à partir de leur contenu non-chiffré.
Dans ce cas, le gestionnaire de vidage 53 est apte à distinguer parmi des flux de données un flux privilégié en utilisant le contenu non-chiffré de ce flux et à le marquer afin qu’il soit reconnu en tant qu’un flux privilégié par le module de gestion global 24 après le chiffrement de ce flux.
Ce marquage peut comprendre la modification de la valeur DSCP pour une valeur prédéterminée permettant de reconnaître de manière sûre un flux privilégié après le chiffrage de celui-ci.
Cela est par exemple le cas lorsque seulement certain flux parmi un ensemble de flux ayant la même valeur DSCP doivent être traités comme des flux privilégiés.
Lorsque le gestionnaire de vidage 53 est situé dans le module de gestion global 24, il permet de reconnaître les flux privilégiés conformément au plan de communication à partir de leur identifiant uniquement qui reste non-chiffré après le passage du flux par le chiffreur 33.
Lorsqu’il s’agit d’une valeur modifiée DSCP par l’un des modules de gestion locaux 34, le gestionnaire de vidage 53 est apte à reconnaître cette valeur DSCP modifiée et à traiter donc ce flux comme un flux privilégié.
Comme indiqué précédemment, indépendamment de son emplacement, le gestionnaire de vidage 53 est apte à modifier dynamiquement la fréquence de vidage et la capacité de vidage de chaque file d’attente afin de respecter à chaque émission la qualité de service de chaque flux privilégié.
Avantageusement selon l’invention, le gestionnaire de vidage 53 est apte à attribuer les crédits
Figure imgf000013_0001
de manière dynamique en fonction du chargement de chaque fil d’attente de sorte que la somme de l’ensemble des crédits d’émission attribués soit inférieure ou égale à Q. Cela permet notamment d’assurer un meilleur service pour les flux non-privilégié.
Ainsi, par exemple, lorsqu’un segment de conduit correspondant à l’une des liaisons 14 de la plateforme 12A présente une capacité de transmission non-utilisée par les flux privilégiés, les crédits d’émission sont attribués par le gestionnaire de vidage 53 de sorte qu’au moins certains des flux non-privilégiés utilisent cette capacité de transmission non-utilisée.
Cela peut être fait localement, c’est-à-dire lorsque le gestionnaire de vidage 53 est intégré dans l’un des modules de gestion locaux 34, en relation avec les flux privilégiés issus d’un même domaine de sécurité ou globalement, c’est-à-dire lorsque le gestionnaire de vidage 53 est intégré dans le module de gestion global 24, en relation avec les flux privilégiés issus de domaines de sécurité différents.
Un exemple d’implémentation de ce deuxième cas est illustré sur la figure 4.
Ainsi, en référence à cette figure, un débit Di est réservé pour les flux privilégiés issus du domaine de sécurité Ni, un débit D2 est réservé pour les flux privilégiés issus du domaine de sécurité N2, un débit D3 est réservé pour les flux privilégiés issus du domaine de sécurité N3 et un débit D4 présente alors un débit restant pour transmettre l’ensemble des flux non-privilégiés F.
Lorsque le gestionnaire de vidage 53 détermine qu’au moins l’un des débits réservés D1 à D3 n’est pas utilisé entièrement par les flux privilégiés correspondants, il peut utiliser cette capacité restante pour l’attribuer aux flux non-privilégiés F.
Ainsi, dans l’exemple de la figure 4, le débit réservé D3 pour les flux privilégiés issus du domaine de sécurité N3 n’est pas utilisé entièrement, et le débit D4 des flux non- privilégiés F est donc augmenté temporairement pour utiliser toute la capacité de la liaison 14 correspondante.
Cette augmentation du débit D est effectuée par le gestionnaire de vidage 53 en augmentant de manière adaptée les crédits qt accordés aux flux non-privilégiés F.
Il est possible également de réajuster entre eux les débits réservés par des flux privilégiés au sein d’un même domaine de sécurité.
Cela peut être fait localement ou globalement.
La figure 5 illustre un exemple d’une telle implémentation par le gestionnaire de vidage 53 intégré dans le module de gestion global 24.
Ainsi, comme dans le cas précédent, un débit Di est réservé pour les flux privilégiés issus du domaine de sécurité Ni, un débit D2 est réservé pour les flux privilégiés issus du domaine de sécurité N2, un débit D3 est réservé pour les flux privilégiés issus du domaine de sécurité N3 et un débit D4 présente alors un débit restant pour transmettre l’ensemble des flux non-privilégiés F.
En qui concerne le domaine de sécurité Ni, initialement, par exemple une tranche de 30% du débit D1 est réservée pour le flux Nu et une tranche de 70% du débit D1 est réservée pour le flux NI2.
Le gestionnaire de vidage 53 est apte alors à réajuster ces répartitions entre les flux Nu et NI2 au cours du temps en fonction de l’utilisation réele de la tranche correspondante par chacun des flux.
Comme dans le cas précédant, ce réajustement est effectué en affectant de manière adaptée les crédits qt à ces flux Nu ou NI2.
Avantageusement, selon l’invention, le gestionnaire de vidage 53 est apte en outre à recevoir une information de débit réel de chaque liaison 14 associée et à déterminer la fréquence de vidage et la capacité de vidage de chaque file d’attente en fonction en outre de chacun de ces débits réels. Cette information de débit réel est fournie par les moyens 40 expliqués précédemment.
Enfin, il est à noter que seule la partie d’émission des flux de données des modules de gestion 24, 34 a été expliquée en détail.
La partie de réception présente par exemple une structure similaire. Toutefois, à la réception, il n’est pas nécessaire de traiter les flux privilégiés d’une manière particulière étant donné que leur qualité de service a déjà été assurée lors de l’émission par la plateforme correspondante.
Le procédé de construction de nouvelles règles d’échanges 100 sera désormais expliqué en référence à la figure 6 présentant un organigramme de ses étapes. Comme indiqué précédemment, ce procédé est mis en œuvre par le module central 23 de l’une des plateformes de communication 12A à 12N. Par la suite, il sera considéré que ce procédé 100 est mis en œuvre par le module central 23 de la plateforme de communication 12A. Cette plateforme 12A sera alors appelée par la suite plateforme courante et ce module central sera appelé module courant.
Il est par ailleurs considéré qu’avant la mise en œuvre du procédé 100, chaque plateforme de communication fonctionne conformément à un plan de communication en vigueur. Le but du procédé 100 est donc de générer un nouveau plan de communication pour l’ensemble des plateformes lors qu’au moins une nouvelle spécification de plan est reçue.
Lors d’une étape initiale 110, le module central 23 acquiert au moins une nouvelle spécification de flux définissant un nouveau flux de données à émettre par la plateforme courante.
Différentes possibilités de réalisation de cette étapes 110 sont possibles en fonction du rôle de la plateforme courante 12A.
Selon une première possibilité, cette nouvelle spécification est acquise à partir d’une nouvelle spécification de plan soumise à la plateforme 12A.
La soumission de cette nouvelle spécification déclenche la mise en œuvre du procédé 100 et dans ce cas, le module central 23 de cette plateforme est alors appelé module initiateur.
En particulier, une spécification de plan comprend une liste de spécifications de flux, chaque spécification de flux définissant un flux de données à produire ou à recevoir par la plateforme courante en tant qu’un flux privilégié.
Cette spécification est notamment soumise par un opérateur via par exemple une interface homme-machine associée au module central 23.
Pour construire cette spécification, l’opérateur dispose par exemple d’une interface adaptée.
Cette interface peut par exemple comprendre une liste de flux de données utilisables par la plateforme 12A et pour chaque flux, un indicateur de réservation correspondant à la part souhaitée dans la masse des données traitées par la plateforme. Un indicateur de priorité indiquant la priorité des flux peut être également associé à chaque flux.
Ainsi, l’opérateur a une possibilité de modifier chacun de ces indicateurs en déplaçant par exemple un curseur sur une échelle associée à cet indicateur.
Selon d’autres exemples de réalisation, la spécification de plan est soumise par un système embarqué, un système extérieur ou alors une autorité extérieure. Selon une deuxième et une troisième possibilités de réalisation de l’étape 110, la mise en œuvre du procédé 100 est déjà déclenchée par le module central d’une autre plateforme de communication 12B à 12N. Le module central de cette autre plateforme est alors appelé module initiateur.
Dans ce cas, selon la deuxième possibilité, le module central 23 de la plateforme 12A reçoit de la part du module initiateur un message d’export comprenant au moins une spécification de flux définissant un flux de données à produire par la plateforme courante. Le module central 23 est alors appelé module importateur.
Le message d’export est envoyé par le module initiateur à la suite de la mise en œuvre d’une étape 125 de transmission de ce message d’export. Cette étape 125 peut être également mise en œuvre par le module 23 de la plateforme courante en relation avec les flux dont elle est la destination. Dans ce cas, le module courant est également un module initiateur en relation avec ces flux. Une telle étape 125 peut être mise en œuvre par la module courant par exemple en parallèle avec l’étape 110 ou 120.
Selon la troisième possibilité, le module central 23 de la plateforme 12A reçoit une demande de relayage d’un flux de données de la part du module central, dit module demandeur, de l’une des plateformes de communication raccordée directement à la plateforme courante. Cette demande de relayage comprenant la spécification de chaque flux devant être relayé par la plateforme courante 12A. Dans ce cas, le module central 23 est appelé module de relai.
Lors de l’étape 120 suivante, le module central 23 détermine une spécification d’émission. Cette spécification d’émission est formée par chaque spécification de flux issue du plan de communication en vigueur de la plateforme 12A et de le ou de chaque nouvelle spécification acquise.
Lorsque le module central 23 est un module initiateur, ce module central 23 inclut donc dans sa spécification d’émission chaque spécification de flux issue du plan de communication en vigueur et chaque spécification de flux de la spécification de plan soumise lors de l’étape 110.
En outre, dans ce cas, le module central 23 supprime de sa spécification d’émission chaque spécification de flux issue du plan de communication en vigueur et définissant un flux de données dont la plateforme courante est la source.
Lorsque le module central 23 est un module importateur, ce module central 23 inclut donc dans sa spécification d’émission chaque spécification de flux issue du plan de communication en vigueur et chacune des spécifications de flux issues du message d’export acquis lors de l’étape 110. En outre, dans ce cas, le module central 23 supprime de sa spécification d’émission chaque spécification de flux issue du plan de communication en vigueur et transmise précédemment via un message d’export issu du module initiateur.
Lorsque le module central 23 est un module de relai, ce module central 23 inclut donc dans sa spécification d’émission chaque spécification de flux issue du plan de communication en vigueur et chacune des spécifications de flux issues de la demande de relayage reçue lors de l’étape 110.
En outre, dans ce cas, le module central 23 supprime de sa spécification d’émission chaque spécification de flux issue du plan de communication en vigueur et transmise précédemment via une demande de relayage issue du module demandeur.
Lors de l’étape 130 suivante, le module central 23 met en œuvre le procédé de construction et de maintien de conduits de transmission 200 permettant de construire pour chaque famille de flux de la spécification d’émission un conduit de transmission entre la source et la destination de chacun des flux de cette famille.
Ce procédé de construction et de maintien de conduits de transmission 200 sera expliqué en détail par la suite.
L’étape 140 suivante est mise en œuvre par le module central 23 pour chaque flux de données défini par la spécification d’émission dont la destination n’est pas raccordée par l’une des liaisons 14 associées à la plateforme courante.
Autrement dit, dans ce cas, la destination du flux correspondant n’est pas raccordée directement à la plateforme courante et il est nécessaire de passer par au moins une plateforme de relai pour transmettre ce flux.
En particulier, lors de cette étape, le module central 23 transmet une demande de relayage de ce flux au module central, dit module de relai, de l’une des plateformes de communication raccordée directement à la plateforme courante. Cette plateforme correspondant au module de relai est déterminée conformément au conduit de transmission construit lors de l’étape précédente.
La demande de relayage comprend la spécification du flux pour lequel le relayage est demandé.
Ensuite, le module central 23 reçoit un rapport de relayage relatif à l’admissibilité de ce flux de la part de la plateforme de relai.
En particulier, un tel flux est admissible lorsque la plateforme de relai a la capacité de l’émettre en tant qu’un flux privilégié.
Le rapport de relayage est alors généré par le module central de la plateforme de relai à la suite de la mise en œuvre d’une étape 145 correspondante par le module central 23 de la plateforme de relai. Une telle étape 145 peut être également mise en œuvre par le module central 23 de la plateforme courante pour des flux pour lesquels cette plateforme présente une plateforme de relai. Dans ce cas, cette étape 145 est par exemple mise en œuvre après l’étape 150 expliquée en détail ci-dessous.
Lors de l’étape 150, le module central 23 de la plateforme courante 12A vérifie l’admissibilité de chaque flux de données défini par sa spécification d’émission.
En particulier, un flux de données issu de la spécification d’émission est admissible lorsqu’il peut être émis dans le conduit correspondant conformément à la qualité de service définie dans sa spécification.
Lorsqu’une spécification de flux définit un débit élastique, la qualité de service du flux correspondant est respectée lorsque ce flux peut être transmis avec au moins le débit minimal associé.
Outre l’étape 145, après l’étape 150, le module central 23 peut mettre également en œuvre une étape 155 lors de laquelle il génère et envoie un rapport d’admission à la suite d’une vérification de l’admissibilité de chaque flux dont la spécification a été reçue avec le message d’export. Ce rapport est alors envoyé à la plateforme de destination du flux correspondant.
Lors de l’étape finale 160, le module central 23 de la plateforme courante 12 construit un nouveau plan de communication de la plateforme courante 12 en y incluant les spécifications de tous les flux de données définis par la spécification d’émission dont l’admissibilité est confirmée.
La mise en œuvre du procédé 100 peut être comprise plus facilement en référence à la figure 7.
Dans l’exemple de cette figure, il est considéré que le module 23 de la plateforme courante 12A est un module initiateur qui reçoit une spécification de plan SA. Cette spécification SA est par exemple soumise à ce module 23 par l’utilisateur, comme cela a été expliqué précédemment.
Les autres modules centraux des autres plateformes de communication 12B à 12N peuvent donc également recevoir des nouvelles spécifications de plan SBà SN et génèrent des demandes de relayage R et des demandes d’export E correspondantes.
Ces demandes R et E sont ensuite transmises au module central 23 de la plateforme courante 12A qui les combine avec sa spécification de plan SA pout obtenir une spécification d’émission SE.
Enfin, ce module 23 génère un plan de communication P en y incluant chaque flux admissible à partir de sa spécification d’émission SE.
Le procédé de construction et de maintien de conduits de transmission 200 sera désormais expliqué en référence à la figure 8 présentant un organigramme de ses étapes. Comme expliqué précédemment, ce procédé 200 est mis en œuvre lors de l’étape 130 du procédé de construction 100 par le module central 23 de la plateforme courante 12A et permet d’établir un conduit de transmission pour chaque famille de flux.
Lors de l’étape A), le module 23 construit un segment de conduit dans la liaison 14 entre la plateforme courante 12A et une plateforme de communication, dite plateforme suivante, pour chaque famille de flux dont les flux sont destinés à être produits par la plateforme courante 12A.
En particulier, pour ce faire, le module central 23 établit d’abord une liste de liaisons licites à partir de la plateforme courante 12A selon un ordre de préférence de ces liaisons licites.
Une liaison est considérée licite lorsqu’elle fait partie d’au moins un chemin raccordant la plateforme courante 12A et la plateforme de destination des flux de là famille en traversant des plateformes de relai, dont le nombre est inférieur ou égal à un nombre de bonds maximal prédéterminé. Ainsi, dans l’exemple de la figure 1, lorsqu’il est nécessaire de construire un conduit de transmission entre la plateforme 12A et la plateforme 12N, deux chemins peuvent par exemple être considérés.
Un premier chemin par une seule plateforme de relai 12B et un deuxième chemin passe d’abord par la plateforme de relai 12C et puis, par la plateforme de relai 12B. Dans ce cas, si le nombre de bonds maximal est égal à 2, les deux liaisons 14 associées à plateforme 12A seront considérées comme licites. Si, en revanche, ce nombre de bonds maximal est égal à 1 , seule la liaison 14 raccordant la plateforme 12A à la plateforme 12B sera considérée comme licite.
L’ordre de préférence des liaisons licites est par exemple déterminé suivant le nombre de plateformes de relai utilisables dans les chemins comprenant ces liaisons.
Ainsi, dans le précédent exemple avec le nombre de bonds maximal égal à 2, la liaison 14 raccordant les plateformes 12A et 12B sera considérée comme préférée par rapport à la liaison 14 raccordant les plateformes 12A et 12C.
Enfin, lorsque deux liaisons licites font partie de deux chemins différents pour une même famille de flux, la liaison ayant un plus grand débit est prioritaire dans l’ordre de préférence défini pour ces deux liaison licites.
Puis, le module central 23 classe l’ensemble des flux de données destinés à être émis par la plateforme courante 12A selon un ordre de priorité déterminé par une priorité associée à chacun des flux de données. Enfin, le module central 23 affecte les flux de données en choisissant pour chaque flux de données suivant l’ordre de priorité, une capacité dans une liaison parmi la liste de liaisons licites suivant l’ordre de préférence.
L’étape B) est mise en œuvre par le module central 23 lorsque les flux de données d’une famille de flux destinés à être émis par la plateforme courante 12A n’ont pas pour destination la plateforme suivante.
Dans ce cas, le module central 23 envoie au module central de la plateforme suivante une requête de prolongation du conduit de transmission de cette famille de flux par un segment de conduit construit dans la liaison entre la plateforme suivante et une plateforme de communication autre que la plateforme courante.
Cette plateforme suivante construit donc un segment suivant du conduit de manière analogue à celle expliquée en référence à l’étape A) ci-dessus.
Lorsqu’un dernier segment de conduit relatif à une famille de données atteint la plateforme de destination des flux de cette famille, le module central 23 détermine lors de l’étape C) un tracé et un débit de bout en bout du conduit de transmission correspondant.
Enfin lors de l’étape D), le module central 23 associe le conduit de transmission dont le tracé et le débit ont été analysés à la transmission de la famille de flux correspondante lorsque chaque segment de conduit permet de transmettre chaque flux de données de cette famille de flux avec une qualité de service déterminée par la spécification de ce flux.
Pour ce faire, le module courant 23 détermine d’abord une liste de caractéristiques de qualité de service sur chaque segment du conduit de transmission et en déduit un indicateur global de qualité de service pour le conduit de transmission correspondant.
Puis, il détermine une liste de flux de données susceptibles d’utiliser ce conduit de transmission conformément à son indicateur global.
Avantageusement, le procédé 200 comprend en outre l’étape E) correspondant à une étape de maintenance des conduits existants.
Cette étape E) est par exemple mise en œuvre indépendamment des autres étapes A) à D) lorsqu’elles ont été mises en œuvre au moins une fois. Ainsi, elle peut être mise en œuvre lors du fonctionnement de l’architecture 10.
Lors de cette étape E), le module courant 23 envoie une synthèse de conduit pour chaque conduit de transmission à chaque module central de l’ensemble des plateformes de relai correspondant à ce conduit de transmission à l’extension d’une période temporelle prédéterminée. Cette synthèse permettent alors aux modules centraux des plateformes de communication correspondantes de conclure que le conduit de transmission correspondant est toujours utilisé.
Ainsi, lorsqu’une plateforme de relai ne reçoit pas une synthèse de conduit relative à un conduit de transmission au bout de la période temporelle prédéterminée, le module central correspondant en conclut que le conduit n’est plus utilisé et le détruit.
On conçoit alors que la présente invention présente un certain nombre d’avantages. Tout d’abord, il est clair que l’architecture telle que décrite ci-dessous permet de définir des règles d’échanges parmi une pluralité de plateformes de communication.
Ces règles sont négociées entre l’ensemble de ces plateformes ce qui permet d’identifier de manière sûre l’ensemble des flux devant être traités comme privilégiés et d’assurer leur qualité de service. En outre, ces règles peuvent être modifiées de manière dynamique et de manière automatique par les plateformes elles-mêmes.
Cela est particulièrement avantageux lorsque la formation d’engins mobiles évolue ou lorsque les conditions de leur opération changent.
Enfin, ces règles peuvent être changées à l’initiative d’un utilisateur qui peut exprimer de manière particulièrement simple les besoins de la plateforme de communication correspondante.

Claims

REVENDICATIONS
1. Architecture d’échanges (10) de flux de données dans une formation d’engins mobiles, comprenant une pluralité de plateformes de communication (12A,...,12N) et des liaisons (14) raccordant ces plateformes de communication (12A,...,12N) entre elles, chaque plateforme de communication (12A,... ,12N) étant associée à l’un des engins mobiles ou à un centre de commandement, et comprenant au moins un domaine de sécurité (21 A,..., 21 M) apte à émettre et à recevoir des flux de données et un commutateur (22) raccordant le ou chaque domaine de sécurité aux liaisons (14) ; l’architecture d’échanges (10) étant caractérisée en ce que chaque plateforme de communication (12A,... ,12N) comprend en outre un module central (23) apte à établir un plan de communication pour cette plateforme de communication (12A,... ,12N) comprenant une liste de flux privilégiés et pour chacun de ces flux privilégiés, un débit de transmission réservé pour ce flux dans une bande passante réservée dans l’une des liaisons (14) associée à cette plateforme de communication (12A,...,12N) ; et en ce que chaque plateforme de communication (12A,... ,12N) comprend en outre un module de gestion global (24) raccordé entre le ou chaque domaine de sécurité (21 A,... , 21 M) et le commutateur (22) de cette plateforme de communication (12A,... ,12N) et apte à reconnaître parmi l’ensemble des flux de données à émettre par cette plateforme de communication (12A,... ,12N), des flux privilégiés conformément au plan de communication correspondant et à contrôler l’émission de chaque flux privilégié selon le débit réservé pour ce flux conformément au plan de communication.
2. Architecture d’échanges (10) selon la revendication 1 , dans laquelle le module central (23) de chaque plateforme de communication (12A,... ,12N) est apte à établir le plan de communication correspondant à la suite d’une négociation avec les modules centraux (23) des autres plateformes de communication (12A,... ,12N).
3. Architecture d’échanges (10) selon la revendication 1 ou 2, dans laquelle le module central (23) de chaque plateforme de communication (12A,...,12N) est raccordé directement au commutateur (22) de cette plateforme de communication (12A,... ,12N) pour communiquer via les liaisons (14) correspondantes avec les modules centraux (23) des autres plateformes de communication (12A,...,12N).
4. Architecture d’échanges (10) selon l’une quelconque des revendications précédentes, dans laquelle le module de gestion global (24) de chaque plateforme de communication (12A,... ,12N) est apte à contrôler l’émission des flux de données autres que les flux privilégiés conformément à une technique de meilleur effort.
5. Architecture d’échanges (10) selon l’une quelconque des revendications précédentes, dans laquelle le module de gestion global (24) de chaque plateforme de communication (12A,... ,12N) est apte à contrôler l’émission de chaque flux privilégié dans un conduit de transmission prédéterminé pour ce flux, chaque conduit de transmission étant composé d’une pluralité de segments de conduit, chaque segment de conduit étant formé par une capacité réservée dans l’une des liaisons (14) raccordant un couple de plateformes de communication (12A,... ,12N).
6. Architecture d’échanges (10) selon l’une quelconque des revendications précédentes, dans laquelle le ou chaque domaine de sécurité (21A,... ,21M) de chaque plateforme de communication (12A,... ,12N) comprend en outre un module de chiffrage (33) apte à chiffrer l’ensemble des flux de données sortant de ce domaine de sécurité (21 A,... , 21 M) et à déchiffrer l’ensemble des flux de données entrant dans ce domaine de sécurité (21 A,... , 21 M).
7. Architecture d’échanges (10) selon la revendication 6, dans laquelle le module de gestion global (24) est apte à reconnaître chaque flux privilégié parmi des flux de données chiffrés en utilisant un identifiant non-chiffré de ce flux.
8. Architecture d’échanges (10) selon la revendication 7, dans laquelle le ou chaque domaine de sécurité (21 A,... , 21 M) comprend en outre un module de gestion local (34) disposé en amont du module de chiffrage (33) lors de l’émission des flux de données, apte à distinguer parmi des flux de données un flux privilégié conformément au plan de communication correspondant, et apte à le marquer afin qu’il soit désigné en tant qu’un flux privilégié par le module de gestion global (24) après le chiffrement de ce flux.
9. Architecture d’échanges (10) selon la revendication 8, dans laquelle le module de gestion local (34) du ou de chaque domaine de sécurité (21A,... ,21M) de chaque plateforme de communication (12A,... ,12N) est relié via un lien unidirectionnel au module central (23) correspondant, ledit module central (23) étant apte à transmettre le plan de communication correspondant audit module de gestion local (34) via ce lien unidirectionnel.
10. Architecture d’échanges (10) selon l’une quelconque des revendications précédentes, dans laquelle chaque plateforme de communication (12A,... ,12N) comprend en outre un module de mesure (40) pour chaque liaison (14) associée à cette plateforme de communication, ledit module de mesure (40) étant apte à mesurer un débit réel de cette liaison (14).
11. Architecture d’échanges (10) selon la revendication 10 prise en combinaison avec la revendication 5, dans laquelle le module de gestion global (24) de chaque plateforme de communication (12A,... ,12N) est apte à réajuster le débit pour chacun des flux privilégiés en fonction des débits réels des conduits associés.
12. Architecture d’échanges (10) selon l’une quelconque des revendications précédentes, dans laquelle le module de gestion global (24) de chaque plateforme de communication (12A,... ,12N) est apte à réajuster le débit pour chacun des flux de données en fonction de l’utilisation réelle de chaque bande passante réservée par le flux de données correspondant.
PCT/EP2021/051959 2020-01-28 2021-01-28 Architecture d'échanges de flux de données dans une formation d'engins mobiles WO2021151998A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FRFR2000814 2020-01-28
FR2000814A FR3106712B1 (fr) 2020-01-28 2020-01-28 Architecture d'echanges de flux de donnees dans une formation d'engins mobiles

Publications (1)

Publication Number Publication Date
WO2021151998A1 true WO2021151998A1 (fr) 2021-08-05

Family

ID=71994559

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2021/051959 WO2021151998A1 (fr) 2020-01-28 2021-01-28 Architecture d'échanges de flux de données dans une formation d'engins mobiles

Country Status (2)

Country Link
FR (1) FR3106712B1 (fr)
WO (1) WO2021151998A1 (fr)

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP2037636A1 (fr) * 2007-09-14 2009-03-18 NTT DoCoMo, Inc. Procédé et appareil pour la configuration de la bande passante dans des réseaux à base de classes
FR2961367A1 (fr) * 2010-06-14 2011-12-16 Thales Sa Systeme et methode de gestion de flux securises entre plusieurs sites distants
FR3039729A1 (fr) * 2015-07-31 2017-02-03 Sagemcom Broadband Sas Procede de gestion de bande passante par un dispositif d'interconnexion de reseaux de communication
US20170359749A1 (en) * 2016-06-10 2017-12-14 Huawei Technologies Co., Ltd. Systems and method for quality of service monitoring, policy enforcement, and charging in a communications network

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP2037636A1 (fr) * 2007-09-14 2009-03-18 NTT DoCoMo, Inc. Procédé et appareil pour la configuration de la bande passante dans des réseaux à base de classes
FR2961367A1 (fr) * 2010-06-14 2011-12-16 Thales Sa Systeme et methode de gestion de flux securises entre plusieurs sites distants
FR3039729A1 (fr) * 2015-07-31 2017-02-03 Sagemcom Broadband Sas Procede de gestion de bande passante par un dispositif d'interconnexion de reseaux de communication
US20170359749A1 (en) * 2016-06-10 2017-12-14 Huawei Technologies Co., Ltd. Systems and method for quality of service monitoring, policy enforcement, and charging in a communications network

Also Published As

Publication number Publication date
FR3106712B1 (fr) 2022-02-11
FR3106712A1 (fr) 2021-07-30

Similar Documents

Publication Publication Date Title
EP1672874B1 (fr) Procédé de transmission securisée, système, pare-feu et routeur le mettant en oeuvre
EP2204034B1 (fr) Passerelle bidirectionnelle à niveau de sécurité renforcé
EP2830360B1 (fr) Procédé pour l'échange en sécurité d'une donnée sur un réseau ad-hoc mettant en oeuvre un service de diffusion Xcast et noeud associé
EP2137836A2 (fr) Procede et dispositif de gestion de canaux de communication pour des echanges de donnees a partir d'un aeronef
EP2135403A1 (fr) Procede et systeme de routage multitopologie
EP2095570B1 (fr) Systeme de reservation de bande passante pour differentes classes de trafic
EP2460322B1 (fr) Procede et systeme pour la selection automatique de media de transmission
FR3045256A1 (fr) Reseau de communication embarque d'un vehicule et abonne d'un tel reseau de communication
WO2021151998A1 (fr) Architecture d'échanges de flux de données dans une formation d'engins mobiles
WO2021151975A1 (fr) Procédé de construction de règles d'échanges dans une architecture d'échanges de flux de données dans une formation d'engins mobiles et module central associé
WO2021152016A1 (fr) Procédé de construction et de maintien de conduits dans une architecture d'échanges de flux de données dans une formation d'engins mobiles et module central associé
EP3370363A1 (fr) Solution de transport de donnees hybride notamment pour liaisons par satellite
WO2021151994A1 (fr) Module de gestion d'échanges de flux de données dans une architecture d'échanges pour une formation d'engins mobiles
EP3675430A1 (fr) Système de communication avionique mixte de types arinc 664 p7 et ethernet à routage prédéterminé
WO2011157704A2 (fr) Système et méthode de gestion de flux sécurisés entre plusieurs sites distants
EP3675438B1 (fr) Procédé de configuration d'un réseau avionique, produit programme d'ordinateur et module de configuration associés
EP3989494A1 (fr) Procede d'agregation et de regulation de messages via un canal de communication bidirectionnel contraint
EP4260525A1 (fr) Architecture d'échanges de flux de données dans une formation d'engins mobiles et procédé d'échanges associé
WO2014135793A1 (fr) Procédé d'allocation de ressources pour la mise en œuvre de réseaux virtuels dans un réseau de télécommunication
EP1217865A1 (fr) Dispositif et procédé de contrôle de flux dans un réseau commuté
EP3563494A1 (fr) Procédé et dispositif de réallocation de ressources satellite
EP2476225B1 (fr) Procede et systeme pour le controle de l'acheminement d'un flux de donnees d'une classe de service a travers un reseau maille et chiffre
EP4340292A1 (fr) Adaptation dynamique du format de transmission d'un chiffrement de données basé sur les attributs
EP4064636A1 (fr) Procédé, dispositif et système de communication, avec rupture de protocole, entre des équipements de zones de sécurité différentes
EP1868349B1 (fr) Dispositif de mise en communication de réseaux locaux par un commutateur exclusif et systéme de mise en communication correspondant ainsi qu'un support d'informations et un programme d'ordinateur

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 21701343

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 21701343

Country of ref document: EP

Kind code of ref document: A1