WO2021151994A1 - Module de gestion d'échanges de flux de données dans une architecture d'échanges pour une formation d'engins mobiles - Google Patents

Module de gestion d'échanges de flux de données dans une architecture d'échanges pour une formation d'engins mobiles Download PDF

Info

Publication number
WO2021151994A1
WO2021151994A1 PCT/EP2021/051955 EP2021051955W WO2021151994A1 WO 2021151994 A1 WO2021151994 A1 WO 2021151994A1 EP 2021051955 W EP2021051955 W EP 2021051955W WO 2021151994 A1 WO2021151994 A1 WO 2021151994A1
Authority
WO
WIPO (PCT)
Prior art keywords
queue
privileged
flow
transmission
management module
Prior art date
Application number
PCT/EP2021/051955
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 WO2021151994A1 publication Critical patent/WO2021151994A1/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
    • 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 management module in an exchange architecture for training mobile devices
  • the present invention relates to a data flow exchange management module in an exchange architecture for training mobile devices.
  • 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 invention relates to a data flow exchange management module in an exchange architecture for the formation of mobile vehicles, the exchange architecture further comprising a plurality of communication systems. and links connecting these communication systems to one another, the exchange management module connecting one of the communication systems to links associated with this communication system and comprising:
  • a transmission queue manager capable of associating a queue with each data stream to be transmitted by the communication system and of placing the corresponding data stream in this queue in the form of a plurality of datagrams
  • an emptying mechanism defining a plurality of transmission outputs and capable of emptying each queue by sending corresponding datagrams to the associated links via one or more transmission outputs associated with this queue.
  • the exchange management module further comprises an emptying manager capable of designating or recognizing among the set of data flows to be transmitted privileged flows in accordance with a predetermined communication plan and of defining an emptying frequency and a capacity. emptying each queue so as to control the transmission of each privileged stream according to a rate reserved for this stream in accordance with this communication plan.
  • the exchange management module comprises one or more of the following characteristics, taken in isolation or according to all the technically possible combinations: - the dump manager is able to associate with each queue one or more transmission outputs according to a priority determined for the data flow corresponding to this queue, the number of transmission outputs associated with each queue wait setting defining the emptying frequency of this queue;
  • the emptying manager is also able to associate with each emission output an emission credit defining the capacity for emptying the queue associated with this emission output;
  • emission credits are allocated dynamically according to the loading of each queue so that the sum of all emission credits allocated is less than or equal to a total transmission capacity of the associated links;
  • emission credits are allocated so that at least some of the non-privileged flows use this unused transmission capacity
  • the emission credits are allocated so that at least one other privileged flow originating from the same security domain as said privileged flow uses a transmission capacity not used by said privileged flow;
  • the transmission queue manager is able to receive unencrypted data streams to be transmitted from an internal computer network of the corresponding communication system
  • the dump manager is able to distinguish among data flows a privileged flow in accordance with the communication plan, and able to mark it so that it is designated as a privileged flow after the encryption of this flow;
  • the transmission queue manager is able to receive encrypted data streams to be transmitted from several security domains of the corresponding communication system
  • the dump manager is able to designate from among all the data streams to be sent a privileged stream using an unencrypted identifier of this data stream;
  • a path segment guaranteeing a reserved rate for each privileged flow of each security domain is formed in each link; - when a path segment has a transmission capacity not used by the privileged flows of at least one security domain, the emission credits are allocated so that at least some of the non-privileged flows of at least one security domain at least one other security domain uses this unused transmission capacity;
  • the emptying manager is able to receive real bit rate information from each associated link and to determine the emptying frequency and the emptying capacity of each queue as a function of each of these real bit rates, each information of real flow being provided by a measurement module associated with the corresponding link.
  • 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. Thus, 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, subsequently, only for example the communication platform 12A will be described in detail with reference to FIG. 2. Thus, as can be seen in this FIG. 2, the communication platform
  • Each security domain 21 A to 21 M is able to produce data streams with a confidentiality level specific to this domain and to receive data streams 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 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 therefore to the links 14, and making it possible to locally manage unencrypted data streams such as this will be explained in more detail later.
  • the local management module 34 of each security domain 21 A to 21 M is moreover connected to the central module 23 via a unidirectional link allowing this central module 23 to transmit data to this local management module 34 in a unidirectional manner.
  • 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 central modules 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.
  • 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 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. More this The number is high, 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 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 according to the loading of each queue so that the sum of all the allocated emission credits is less than or equal to Q. This makes it possible 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 is reserved for the privileged flows originating from the security domain N 2
  • a flow rate D is reserved for the privileged flows from the security domain N
  • a bit rate D then has a remaining bit rate for transmitting all the non-privileged streams F.
  • the dump manager 53 determines that at least one of the reserved flows D to D 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 rate D3 reserved for the privileged flows coming from the security domain N3 is not used entirely, and the rate D4 of the non-privileged flows F is therefore temporarily increased to use all the data. 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 rate D1 is reserved for the privileged flows originating from the security domain Ni
  • a rate D 2 is reserved for the privileged flows originating from the security domain N 2
  • a 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 a particular way given that their quality of service has already been ensured during 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.
  • 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 importing module, this central module 23 therefore includes in its transmission specification each flow specification resulting from the transmission plan. communication in force and each of the flow specifications resulting from the export message acquired during 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 an export message 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.
  • Such a flow is admissible when the relay platform has the capacity to send it as a privileged flow.
  • 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.
  • Such a step 145 can also be implemented by the central module 23 of the current platform for flows for which this platform has a relay platform. In this case, this step 145 is for example implemented after step 150 explained in detail below.
  • 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 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.
  • 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 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 link having a higher bit rate takes priority in the order of preference defined for these two lawful links. Then, 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.
  • 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 lawful 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 platforms relay corresponding to this transmission path to the extension of a predetermined period of time.
  • This synthesis then allows the central modules of the corresponding communication platforms to conclude that the corresponding transmission path is still in use.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

La présente invention concerne un module de gestion d'échanges (24, 34) de flux de données comprenant un gestionnaire de files d'émission (51) apte à associer à chaque flux de données à émettre par le système de communication une file d'attente et à placer dans cette file d'attente le flux de données correspondant, et un mécanisme de vidage (52) définissant une pluralité de sorties d'émission et apte à vider chaque file d'attente. Le module de gestion d'échanges (24, 34) est caractérisé en ce qu'il comprend en outre un gestionnaire de vidage (53) apte à désigner ou à reconnaître parmi l'ensemble des flux de données à émettre des flux privilégiés conformément à un plan de communication prédéterminé et à définir une fréquence de vidage et une capacité de vidage de chaque file d'attente.

Description

DESCRIPTION
TITRE : Module de gestion d’échanges de flux de données dans une architecture d’échanges pour une formation d’engins mobiles
La présente invention concerne un module de gestion d’échanges de flux de données dans une architecture d’échanges pour 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 un module de gestion d’échanges de flux de données dans une architecture d’échanges pour une formation d’engins mobiles, l’architecture d’échanges comprenant en outre une pluralité de systèmes de communication et des liaisons raccordant ces systèmes de communication entre eux, le module de gestion d’échanges raccordant l’un des systèmes de communication à des liaisons associées à ce système de communication et comprenant :
- un gestionnaire de files d’émission apte à associer à chaque flux de données à émettre par le système de communication une file d’attente et à placer dans cette file d’attente le flux de données correspondant sous une forme d’une pluralité de datagrammes ;
- un mécanisme de vidage définissant une pluralité de sorties d’émission et apte à vider chaque file d’attente en émettant des datagrammes correspondants vers les liaisons associées via une ou plusieurs sorties d’émission associées à cette file d’attente.
Le module de gestion d’échanges comprend en outre un gestionnaire de vidage apte à désigner ou à reconnaître parmi l’ensemble des flux de données à émettre des flux privilégiés conformément à un plan de communication prédéterminé et à définir une fréquence de vidage et une capacité de vidage de chaque file d’attente de sorte à contrôler l’émission de chaque flux privilégié selon un débit réservé pour ce flux conformément à ce plan de communication.
Suivant d’autres aspects avantageux de l’invention, le module de gestion d’échanges selon l’invention comprend une ou plusieurs des caractéristiques suivantes, prises isolément ou suivant toutes les combinaisons techniquement possibles : - le gestionnaire de vidage est apte à associer à chaque file d’attente une ou plusieurs sorties d’émission en fonction d’une priorité déterminée pour le flux de données correspondant à cette file, le nombre des sorties d’émission associées à chaque file d’attente définissant la fréquence de vidage de cette file ;
- le gestionnaire de vidage est apte en outre à associer à chaque sortie d’émission un crédit d’émission définissant la capacité de vidage de la file d’attente associée à cette sortie d’émission ;
- les crédits d’émission sont attribués de manière dynamique en fonction du chargement de chaque file d’attente de sorte que la somme de l’ensemble des crédits d’émission attribués soit inférieure ou égale à une capacité totale de transmission des liaisons associés ;
- un segment de conduit garantissant un débit réservé pour chaque flux privilégié est formé dans chaque liaison;
- lorsqu’un segment de conduit présente une capacité de transmission non-utilisée par les flux privilégiés, les crédits d’émission sont attribués de sorte qu’au moins certains des flux non-privilégiés utilisent cette capacité de transmission non-utilisée ;
- un segment de conduit garantissant un débit réservé pour chaque flux privilégié est formé dans chaque liaison ;
- lorsqu’un flux privilégié présente un débit réel inférieur au débit réservé dans le segment de conduit correspondant, les crédits d’émission sont attribués de sorte qu’au moins un autre flux privilégié issu d’un même domaine de sécurité que ledit flux privilégié utilise une capacité de transmission non-utilisée par ledit flux privilégié ;
- le gestionnaire de files d’émission est apte à recevoir des flux de données non- chiffrés à émettre de la part d’un réseau informatique interne du système de communication correspondant ;
- le gestionnaire de vidage est apte à distinguer parmi des flux de données un flux privilégié conformément au plan de communication, et apte à le marquer afin qu’il soit désigné en tant qu’un flux privilégié après le chiffrement de ce flux ;
- le gestionnaire de files d’émission est apte à recevoir des flux de données chiffrés à émettre de la part de plusieurs domaines de sécurités du système de communication correspondant ;
- le gestionnaire de vidage est apte à désigner parmi l’ensemble des flux de données à émettre un flux privilégié en utilisant un identifiant non-chiffré de ce flux de données ;
- un segment de conduit garantissant un débit réservé pour chaque flux privilégié de chaque domaine de sécurité est formé dans chaque liaison ; - lorsqu’un segment de conduit présente une capacité de transmission non-utilisée par les flux privilégiés d’au moins un domaine de sécurité, les crédits d’émission sont attribués de sorte qu’au moins certains des flux non-privilégiés d’au moins un autre domaine de sécurité utilisent cette capacité de transmission non-utilisée ;
- le gestionnaire de vidage est apte à recevoir une information de débit réel de chaque liaison 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, chaque information de débit réel étant fournie par un module de mesure associé à la liaison correspondante.
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 donc aux liaisons 14, 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 34 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 file 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 D est réservé pour les flux privilégiés issus du domaine de sécurité N2, un débit D est réservé pour les flux privilégiés issus du domaine de sécurité N et un débit D 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 D à D 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 D1 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éelle 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. Module de gestion d’échanges (24, 34) de flux de données dans une architecture d’échanges (10) pour une formation d’engins mobiles, l’architecture d’échanges (10) comprenant en outre une pluralité de systèmes de communication et des liaisons (14) raccordant ces systèmes de communication entre eux, le module de gestion d’échanges (24, 34) raccordant l’un des systèmes de communication à des liaisons (14) associées à ce système de communication et comprenant :
- un gestionnaire de files d’émission (51) apte à associer à chaque flux de données à émettre par le système de communication une file d’attente et à placer dans cette file d’attente le flux de données correspondant sous une forme d’une pluralité de datagrammes ;
- un mécanisme de vidage (52) définissant une pluralité de sorties d’émission 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 ; le module de gestion d’échanges (24, 34) étant caractérisé en ce qu’il comprend en outre un gestionnaire de vidage (53) apte à désigner ou à reconnaître parmi l’ensemble des flux de données à émettre des flux privilégiés conformément à un plan de communication prédéterminé et à définir une fréquence de vidage et une capacité de vidage de chaque file d’attente de sorte à contrôler l’émission de chaque flux privilégié selon un débit réservé pour ce flux conformément à ce plan de communication.
2. Module de gestion d’échanges (24, 34) selon la revendication 1 , dans lequel le gestionnaire de vidage (53) est apte à associer à chaque file d’attente une ou plusieurs sorties d’émission en fonction d’une priorité déterminée pour le flux de données correspondant à cette file, le nombre des sorties d’émission associées à chaque file d’attente définissant la fréquence de vidage de cette file.
3. Module de gestion d’échanges (24, 34) selon la revendication 2, dans lequel le gestionnaire de vidage (53) est apte en outre à associer à chaque sortie d’émission un crédit d’émission définissant la capacité de vidage de la file d’attente associée à cette sortie d’émission.
4. Module de gestion d’échanges (24, 34) selon la revendication 3, dans lequel les crédits d’émission sont attribués de manière dynamique en fonction du chargement de chaque file d’attente de sorte que la somme de l’ensemble des crédits d’émission attribués soit inférieure ou égale à une capacité totale de transmission des liaisons (14) associés.
5. Module de gestion d’échanges (24, 34) selon la revendication 4, dans lequel un segment de conduit garantissant un débit réservé pour chaque flux privilégié est formé dans chaque liaison (14) ; et dans lequel lorsqu’un segment de conduit présente une capacité de transmission non-utilisée par les flux privilégiés, les crédits d’émission sont attribués de sorte qu’au moins certains des flux non-privilégiés utilisent cette capacité de transmission non-utilisée.
6. Module de gestion d’échanges (24, 34) selon la revendication 4 ou 5, dans lequel un segment de conduit garantissant un débit réservé pour chaque flux privilégié est formé dans chaque liaison ; et dans lequel lorsqu’un flux privilégié présente un débit réel inférieur au débit réservé dans le segment de conduit correspondant, les crédits d’émission sont attribués de sorte qu’au moins un autre flux privilégié issu d’un même domaine de sécurité que ledit flux privilégié utilise une capacité de transmission non-utilisée par ledit flux privilégié.
7. Module de gestion d’échanges (34) selon l’une quelconque des revendications précédentes, dans lequel le gestionnaire de files d’émission (51) est apte à recevoir des flux de données non-chiffrés à émettre de la part d’un réseau informatique (32) interne du système de communication correspondant.
8. Module de gestion d’échanges (34) selon la revendication 7, dans lequel le gestionnaire de vidage (53) est apte à distinguer parmi des flux de données un flux privilégié conformément au plan de communication, et apte à le marquer afin qu’il soit désigné en tant qu’un flux privilégié après le chiffrement de ce flux.
9. Module de gestion d’échanges (24) selon l’une quelconque des revendications 1 à 6, dans lequel le gestionnaire de files d’émission (51) est apte à recevoir des flux de données chiffrés à émettre de la part de plusieurs domaines de sécurités (21 A,... ,21 M) du système de communication correspondant.
10. Module de gestion d’échanges (24) selon la revendication 9, dans lequel le gestionnaire de vidage (53) est apte à désigner parmi l’ensemble des flux de données à émettre un flux privilégié en utilisant un identifiant non-chiffré de ce flux de données.
11. Module de gestion d’échanges (24) selon la revendication 9 ou 10 prise en combinaison avec la revendication 4, dans lequel un segment de conduit garantissant un débit réservé pour chaque flux privilégié de chaque domaine de sécurité (21 A,... ,21 M) est formé dans chaque liaison (14) ; et dans lequel lorsqu’un segment de conduit présente une capacité de transmission non-utilisée par les flux privilégiés d’au moins un domaine de sécurité (21 A,..., 21 M), les crédits d’émission sont attribués de sorte qu’au moins certains des flux non-privilégiés d’au moins un autre domaine de sécurité (21 A,... ,21 M) utilisent cette capacité de transmission non-utilisée.
12. Module de gestion d’échanges (24, 34) selon l’une quelconque des revendications précédentes, dans lequel le gestionnaire de vidage (53) est apte à recevoir une information de débit réel de chaque liaison 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, chaque information de débit réel étant fournie par un module de mesure (40) associé à la liaison correspondante.
PCT/EP2021/051955 2020-01-28 2021-01-28 Module de gestion d'échanges de flux de données dans une architecture d'échanges pour une formation d'engins mobiles WO2021151994A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FRFR2000809 2020-01-28
FR2000809A FR3106710B1 (fr) 2020-01-28 2020-01-28 Module de gestion d'echanges de flux de donnees dans une architecture d'echanges pour une formation d'engins mobiles

Publications (1)

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

Family

ID=71994556

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2021/051955 WO2021151994A1 (fr) 2020-01-28 2021-01-28 Module de gestion d'échanges de flux de données dans une architecture d'échanges pour une formation d'engins mobiles

Country Status (2)

Country Link
FR (1) FR3106710B1 (fr)
WO (1) WO2021151994A1 (fr)

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2001063855A1 (fr) * 2000-02-25 2001-08-30 Telefonaktiebolaget Lm Ericsson (Publ) Ordonnancement de paquets dans un systeme de communication umts au moyen de plusieurs vitesses de transfert calculees
US6570883B1 (en) * 1999-08-28 2003-05-27 Hsiao-Tung Wong Packet scheduling using dual weight single priority queue
EP1679923A1 (fr) * 2003-10-16 2006-07-12 NEC Corporation Procede et systeme d'ordonnancement de capacite
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 (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6570883B1 (en) * 1999-08-28 2003-05-27 Hsiao-Tung Wong Packet scheduling using dual weight single priority queue
WO2001063855A1 (fr) * 2000-02-25 2001-08-30 Telefonaktiebolaget Lm Ericsson (Publ) Ordonnancement de paquets dans un systeme de communication umts au moyen de plusieurs vitesses de transfert calculees
EP1679923A1 (fr) * 2003-10-16 2006-07-12 NEC Corporation Procede et systeme d'ordonnancement de capacite
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
FR3106710A1 (fr) 2021-07-30
FR3106710B1 (fr) 2022-02-11

Similar Documents

Publication Publication Date Title
EP1835411B1 (fr) Systeme sur puce a controle semi-distribue
EP2137836A2 (fr) Procede et dispositif de gestion de canaux de communication pour des echanges de donnees a partir d'un aeronef
EP2095570B1 (fr) Systeme de reservation de bande passante pour differentes classes de trafic
WO2008125437A1 (fr) Procede et systeme de routage multitopologie
EP2830360A1 (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 ; noeud associé
EP2460322B1 (fr) Procede et systeme pour la selection automatique de media de transmission
FR3070564A1 (fr) Procede de taxation de donnees d'une application acheminees sur une tranche d'un reseau de communication
FR3045256A1 (fr) Reseau de communication embarque d'un vehicule et abonne d'un tel reseau de communication
WO2021151994A1 (fr) Module de gestion d'échanges de flux de données dans une architecture d'échanges pour 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é
WO2021151998A1 (fr) Architecture d'échanges de flux de données dans 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
EP1217865B1 (fr) Dispositif et procédé de contrôle de flux dans un réseau commuté
EP2446360A1 (fr) Technique de determination d'une chaine de fonctions elementaires associee a un service
WO2022122823A1 (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
WO2018122258A1 (fr) Procede et dispositif de reallocation 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
FR3003109A1 (fr) Procede de controle de congestion pour reseaux de telecommunications
EP2946373B1 (fr) Systeme de capteurs integres en suite
EP2272220A1 (fr) Gestion de service dans un reseau multicanaux et multi sauts

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

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

Country of ref document: EP

Kind code of ref document: A1