Method for managing data traffic between source entity and recipient entity, corresponding entity and computer program

Abstract

A method for managing data traffic between a source entity and a recipient entity, and corresponding entities and computer programs. The invention relates to a method for managing data traffic between a source entity (11) and a recipient entity (12), implementing the following steps: selecting (13) for the source entity and the recipient entity at least one policy for scheduling application data packets exchanged between the source entity and the recipient entity, establishing (14), between the source entity and the recipient entity, at least one connection over which the at least one selected packet scheduling policy is implemented, taking into account at least one characteristic of an application associated with the application data.

Description

Technical Field

[0001] The field of the invention is that of communications within networks, for example computer networks implementing the IP protocol, such as WAN (Wide Area Network) networks.

[0002] More specifically, the present invention proposes a solution for improving data exchange between a source entity and a recipient entity connected to said network.

[0003] The present invention has application particularly, but not exclusively, in networks based on SD-WAN (Software Defined Wide Area Network) architecture. Background Art

[0004] A WAN network may be particularly used to interconnect various sites of a company, each site hosting at least one LAN (Local Area Network) network.

[0005] Typically, such WAN networks are based on the use of the MPLS (Multi-Protocol Label Switching) protocol, which supports communications established between the various sites and provides access, for example from one or other of the remote sites, to local applications hosted on the company's servers.

[0006] Congestion can occur in WAN networks depending on usage, on user behavior, or even on the nature of the applications or content that users want to access, which can be hosted in a cloud infrastructure.

[0007] New technologies for automating the process of network resource generation and usage have been introduced recently. In particular, SDN (Software Defined Network) network architectures have been deployed, in which a typically centralized computing logic (e.g., an SDN controller) is responsible for dynamically allocating resources involved in routing traffic or providing (multiple) communication services supported by the network. In particular, these automation technologies significantly increase the flexibility of resource usage and its adaptability to user needs.

[0008] This flexibility therefore makes it easier to, for example, allocate network resources as needed, manage a company's application flows, or maintain continuity of communication services in the event of a transmission resource failure.

[0009] Communication services such as virtual private network (VPN) services can be deployed specifically on the SD-WAN infrastructure, which makes it easier to establish IPsec tunnels, for example, between sites of a company interconnected via VPN.

[0010] Similarly, SD-WAN architecture makes it easier to manage application flows across a company, some of whose resources may be hosted in private, public or hybrid cloud infrastructure.

[0011] However, managing traffic to or from corporate sites is typically limited by changes in network access conditions, the availability of one or more network access paths, changes in traffic volumes over time, pricing conditions for accessing (multiple) networks or establishing data transmission facilities, the confidentiality of information exchanged between sites, etc.

[0012] However, such parameters are not always known to the calculation logic used by the SD-WAN infrastructure operator, which may significantly lead to non-optimized engineering for routing data traffic.

[0013] Therefore, solutions for predictively managing quality of experience have been proposed. These solutions are based on the use of artificial intelligence (AI) techniques such as machine learning and usually involve entities external to the network, such as SDN controllers.

[0014] However, these solutions involve the exchange of large amounts of telemetry data that can be used for malicious purposes. In addition, the aggregation and centralization of data, especially due to its use by external entities, also presents security vulnerabilities that can be exploited for illegal intrusion or profiling purposes. Therefore, these types of projects raise security and confidentiality issues.

[0015] Therefore, there is a need for a new data traffic management technology that can be particularly applied to the management of traffic routed through an SD-WAN infrastructure and that makes it possible to overcome at least some of the shortcomings of the prior art. Summary of the invention

[0016] The present invention proposes a solution in the form of a method for managing data traffic between a source entity and a receiver entity, achieving:

[0017] - selecting, for said source entity and said recipient entity, at least one policy for scheduling packets of application data exchanged between said source entity and said recipient entity, taking into account at least one characteristic of an application associated with the application data, said at least one selected packet scheduling policy being supported by said source entity and said recipient entity,

[0018] - establishing at least one connection between said source entity and said receiver entity, implementing said at least one selected packet scheduling strategy on said at least one connection.

[0019] Thus, this method for managing data traffic according to at least one embodiment of the invention makes it possible to take into account the nature of the application or data stream exchanged between a source entity and a recipient entity to select a packet scheduling strategy to be executed for a given connection (called a reference connection) established between the source entity and the recipient entity. This method differs from the prior art in that the configuration of the packet scheduling strategy is local to the device and cannot be negotiated per connection or at the network level linking the source entity and the recipient entity.

[0020] Indeed, such applications may have specific characteristics, such as the type of application, constraints or needs in terms of quality of service or experience, or in terms of security (maximum transmission time between two local area networks, for example, packet loss rate, maintaining confidentiality of information exchanged between certain sites, etc.), each local area network being associated with a site of the company. They may also have constraints or needs in terms of pricing or consumption (pricing optimization per visit, consumption monitoring, etc.). Therefore, taking into account at least one characteristic related to an application makes it possible to select a packet scheduling strategy adapted to the characteristics of the traffic profile of said application and aimed at optimizing the routing of data characteristics of this application between source and recipient entities.

[0021] It should be noted that the proposed solution is also applicable to point-to-multipoint (e.g. in the case of a television program broadcasting service based on a multicast transmission mode) or multipoint-to-multipoint (e.g. in the case of a video conferencing service) connections. In this case, a reference connection may be established between at least one source entity and at least one recipient entity.

[0022] According to certain embodiments, packet scheduling policies local to each network are selected (rather than a common policy applied to all traffic routed through the WAN network), which makes it possible to retain some control over the routing of data and the routes selected to route them between the various sites.

[0023] Therefore, these local packet scheduling strategies can resonate the engineering choices related to the establishment of inter-site transmission resources.

[0024] For example, such a packet scheduling policy belongs to the group including:

[0025] -Path management strategy,

[0026] - Congestion management strategies,

[0027] - Group reorganization strategy,

[0028] - Group reordering strategy,

[0029] -etc.

[0030] It should be noted that such a method according to the invention can be implemented indifferently by a source entity and / or a recipient entity.

[0031] More generally, such a method is applicable to any communication network that demonstrates that the execution of a packet scheduling policy (aimed at optimizing packet routing) is able to take into account the previously mentioned application constraints or needs. In particular, this method can be applied by a wide area network based on an SD-WAN architecture.

[0032] For example, this traffic management method that can be used to improve the quality of user experience is referred to as SCHEMATICS ("Procedure for SCHEdule Management for Technically-advanced InfrastruCtureS") in the rest of the specification.

[0033] The data packet scheduling strategy is referred to as PSS (Packet Scheduling SCHEMATICS) hereinafter.

[0034] In a particular embodiment, a source entity may send to a recipient entity a list of at least one packet scheduling policy supported by the source entity.

[0035] In another embodiment (which may be combined with the above specific embodiment), the source entity receives from the receiver entity a list of at least one packet scheduling strategy supported by the receiver entity.

[0036] Thus, the source entity and / or the recipient entity may check whether they support at least one common packet scheduling strategy.The two entities may also indicate preferences that may be considered for the selection of a scheduling strategy for the current connection.

[0037] For example, according to a specific embodiment, the source entity may check whether the recipient entity supports the packet scheduling strategy preferred by the source entity. If this is not the case, the source entity may check whether the recipient entity supports at least one packet scheduling strategy supported by the source entity. If this is not the case, the management method according to the present invention cannot be implemented.

[0038] Therefore, the source entity (correspondingly, the receiver entity) can store a table in a memory, which records all the packet scheduling strategies supported by the receiver entity (correspondingly, the source entity). The table is maintained by the source entity (correspondingly, the receiver entity).

[0039] Such a list may be sent in particular using a transport layer protocol between the source entity and the recipient entity. For example, QUIC, TCP (with or without MPTCP options) protocols may be used. Protocols such as GRE, GTP, IKE, etc. may also be used to exchange these parameters.

[0040] If the QUIC protocol is used, a new QUIC frame is defined to include PSS information. This new QUIC frame, referred to as a PSS frame, can be transmitted by a source entity using a secure connection between the source entity and a receiver entity to trigger the receiver entity to transmit a (multiple) PSS list supported by the receiver entity.

[0041] In a specific embodiment, the source entity (respectively, the receiver entity) sends a parameter notifying the receiver entity (respectively, the source entity) that the source entity (respectively, the receiver entity) is capable of implementing the at least one selected packet scheduling strategy.

[0042] For example, such a parameter takes a first value to indicate that the entity sending the parameter (source entity or recipient entity) supports the process for selecting at least one packet scheduling strategy, and takes a second value to indicate that the entity sending the parameter (source entity or recipient entity) does not support the process for selecting at least one packet scheduling strategy.

[0043] As a variant, the absence of such a parameter means that the entity transmitting the message does not support a procedure for selecting at least one packet scheduling policy.

[0044] Such parameters may in particular be sent using a transport layer protocol between the source entity and the recipient entity.The same protocol mentioned previously by way of example and used for sending the list proposed above may be used.

[0045] If the QUIC protocol is used, such a parameter may be a QUIC transport parameter referred to herein as "Customized_PSS", set to, for example, "0x1" to indicate that an entity sending a QUIC PSS frame including such a parameter supports the method according to the present invention. The "Customized_PSS" parameter may be set to, for example, "0x0" to indicate that an entity sending a QUIC PSS frame does not support the method according to the present invention.

[0046] In a particular embodiment, the connection comprises at least two sub-connections, each sub-connection being associated with a separate path between the source entity and the recipient entity, and the source entity transmits the application data via at least one of the sub-connections taking into account the at least one packet scheduling strategy selected for the connection.

[0047] According to this particular embodiment, the establishment of a sub-connection corresponding to a reference connection (also called a multipath connection) established between a source entity and a recipient entity enables all or part of the traffic to be switched or redirected to one path or the other, for example depending on the quality of service or quality of experience targets set / observed for the application, or depending on changes in the application data routing conditions (deterioration of transmission time, etc.).

[0048] For example, depending on the selected packet scheduling policy, various processes for handling application data packets may be implemented when establishing a connection so that traffic can be transmitted via one and / or the other of the paths.

[0049] In a particular embodiment, a method for managing data traffic includes receiving, by a source entity and / or a recipient entity, at least one item of traffic classification information, such that at least one packet scheduling policy can be associated with an application type.

[0050] This classification information in particular makes it possible to associate an application (or more generally, a type of application) with at least one packet scheduling policy that meets the requirements and / or constraints (e.g., in terms of quality of service or experience) of this type of application. The step of selecting a packet scheduling policy may in particular take into account this classification information. The application may communicate via a dedicated transport API in order to select a PSS policy to be implemented for establishing an underlying transport connection.

[0051] The application mode of at least one selected packet scheduling strategy (i.e., the way of processing application data packets, such as configuration and queue management) is updated periodically and / or depending on changes in routing conditions of application data exchanged between the source entity and the recipient entity according to specific characteristics.

[0052] In this way, actions can be performed that are consistent with the selected packet scheduling policy, such as switching or redirecting traffic to one path or another, or marking certain application data packets, in particular depending on the quality of service or quality of experience targets set for the application under consideration.

[0053] According to a first embodiment, the source entity is a first device connected to the local area network and the recipient entity is a second device connected to the external network. As a variant, the source entity is a second device connected to the external network and the recipient entity is a first device connected to the local area network.

[0054] According to this first example, the proposed solution is directly implemented by a first device (eg a terminal) and a second device (eg a remote server).

[0055] According to a second embodiment, the source entity is an access device connected to a local area network and to at least one external network, routing application data from a first device connected to the local area network, and the recipient entity is a second device connected to the at least one external network. As a variant, the source entity is a second device connected to at least one external network, and the recipient entity is an access device connected to the local area network and to at least one external network, routing application data to a first device connected to the local area network. It should be noted that the source entity and the recipient entity may be connected to separate external networks.

[0056] According to this second example, the proposed solution is implemented by an access device (connected to the same network as the first device) and a second device, such as a remote server, another access device, another terminal, etc. This second example can be particularly implemented when the first device does not support a process for selecting at least one packet scheduling strategy.

[0057] According to a third embodiment, the source entity is an access device connected to a local area network and to at least one external network, routing application data from a first device connected to said local area network, and the recipient entity is a central device, routing application data to a second device connected to at least one external network. As a variant, the source entity is a central device, routing application data from a second device connected to at least one external network, and the recipient entity is an access device connected to a local area network and to at least one external network, routing application data to a first device connected to said local area network. Likewise, the source entity and the recipient entity may be connected to separate external networks.

[0058] According to this third example, the proposed solution is implemented by an access device (connected to the same network as the first device (e.g., a terminal)) and a central device communicating with a second device (e.g., a remote server, another terminal, etc.). Such a central device in particular makes it possible to aggregate sub-connections between the access device and the central device and terminate these sub-connections. This third example can be implemented in particular when both the first device and the second device do not support a process for selecting at least one packet scheduling strategy.

[0059] According to yet another example, the proposed solution is implemented by a central device and a remote server.

[0060] In particular, if the access device maintains a long-term connection with the recipient entity, the steps of sending and / or receiving a list of PSSs, and subsequently selecting at least one PSS, can be implemented when there are application changes, or periodically (for example, every 24 hours), or by taking into account changes in routing conditions of application data exchanged between the source entity and the recipient entity, etc.

[0061] According to a particular embodiment, the access device establishes at least two connections between said source entity and said recipient entity, each connection implementing a separate packet scheduling strategy selected taking into account at least one characteristic of an application.

[0062] According to this particular embodiment, the access device can thus establish a connection for an application using a single packet scheduling policy for the connection under consideration. As a variant, the access device can establish connections for several applications, taking into account various packet scheduling policies for the connections. In other words, several separate application flows can be routed on the same connection between the source entity and the recipient entity, while being subject to separate scheduling policies.

[0063] In a particular embodiment, the access device receives information related to at least one of the external networks from at least one other access device that is connected to the local area network and has established a connection with a remote server or a central device.

[0064] In this way, an access device according to an embodiment of the present invention can collect information characteristics of traffic passing through other access devices. According to an embodiment of the present invention, the access device can specifically use such information to influence the application process (or mode) of the packet scheduling policy selected for the access device and the server - if the server supports the process for selecting at least one packet scheduling policy, or the central device - if the server does not support the process for selecting at least one packet scheduling policy.

[0065] For example, consider that various access devices connected to the same local area network can use a "point-to-multipoint" channel established, for example, using a multicast transmission mode, to share information related to various external networks among themselves.

[0066] In another embodiment, the access device sends information related to at least one of the external networks to the controller, and the controller receives information related to at least one of the external networks from at least one other access device that is connected to the local area network and has established a connection with a remote server or a central device.

[0067] In this way, the controller can collect information characteristics of the traffic passing through other access devices.

[0068] For example, consider that various access devices connected to the same local area network establish connections with a controller to share information related to various external networks. Such a controller is, for example, an SDN controller.

[0069] In a particular embodiment, the method according to the invention selects one of said access devices to route said application data from (and accordingly to) said first device, taking into account said information relating to at least one of said external networks.

[0070] For example, when multiple access devices support the process for selecting at least one packet scheduling strategy according to an embodiment of the present invention, such a step can be implemented in particular by an access device connected to a local area network or by a controller.

[0071] In particular, the selection of one of the access devices also takes into account an identifier associated with the application data.

[0072] For example, an application identifier is associated with application data that is associated with a specific type of application with specific constraints (e.g., low latency). Thus, for example, all application data identified by the same application identifier will pass through the same access device.

[0073] In other embodiments, the invention relates to corresponding source and / or recipient entities.

[0074] Such a source entity, which is capable of communicating with a recipient entity, the source entity comprising at least one processor, or correspondingly, a recipient entity, which is capable of communicating with a source entity, the recipient entity comprising at least one processor, the at least one processor being configured to:

[0075] - selecting, for said source entity and said recipient entity, at least one policy for scheduling application data packets exchanged between said source entity and said recipient entity taking into account at least one characteristic of an application associated with said application data,

[0076] said at least one selected packet scheduling strategy being supported by said source entity and said receiver entity,

[0077] - establishing at least one connection between said source entity and said receiver entity to implement said at least one selected packet scheduling strategy.

[0078] Such an entity is particularly suitable for implementing the previously described method for managing data traffic. The source entity (respectively, the recipient entity) can of course support various features related to the method according to the present invention, which can be combined or adopted separately. In this way, the characteristics and advantages of the source entity (respectively, the recipient entity) are the same as the characteristics and advantages of the method according to at least one embodiment of the present invention described previously. Therefore, they will not be described in further detail.

[0079] One embodiment of the present invention is also intended to protect one or more computer programs and at least one computer-readable data medium, wherein the one or more computer programs include instructions suitable for implementing at least one step of the method according to at least one embodiment of the present invention as described above when the program or these programs are executed by a processor, and the at least one computer-readable data medium includes instructions of at least one computer program as described above. BRIEF DESCRIPTION OF THE DRAWINGS

[0080] Other characteristics and advantages of the invention will appear more clearly on reading the following description of specific embodiments provided as simple illustrative and non-limiting examples and the accompanying drawings, in which:

[0081] - Figure 1 shows the main steps implemented by a source and / or receiver entity according to at least one embodiment of the present invention;

[0082] - Figure 2 shows an example of a WAN network in which the present invention may be implemented,

[0083] - Figure 3 shows an example of a point-to-multipoint channel established for sharing information between various access devices connected to the same local area network,

[0084] - FIG. 4A to FIG. 4B Shows that considering Figure 3 When the information is transmitted in the channel, the access device is selected as the egress point.

[0085] - Figure 5 shows the selection of an access device as an exit point taking into account an application identifier,

[0086] - Figure 6 shows an example of a point-to-point channel established for sharing information between two access devices connected to the same local area network,

[0087] - FIG. 7A to FIG. 7B It shows that considering Figure 6 In the case of information transmitted in the channel, the access device is selected as the exit point.

[0088] - Figure 8 Shown are simplified structures of source and / or receiver entities according to certain embodiments of the invention. DETAILED DESCRIPTION

[0089] General principles

[0090] The general principle of the present invention is based on implementing a specific packet scheduling strategy on a connection established between a source entity and a recipient entity (referred to as a reference connection). The scheduling strategy is based on a mechanism (similar to a scheduler) for managing data packets and controlling congestion. Such a packet scheduling strategy is selected taking into account the application generating the application data traffic between the source entity and the recipient entity.

[0091] It should be noted that such application data represents data exchanged between a client (e.g., a terminal, an access device) and a remote server. Therefore, the exchange of the application data is based on the establishment of a specific connection, which is also referred to as an "application" connection, which may be different from the reference connection according to the present invention.

[0092] The proposed method is based in particular on the use of a packet scheduling policy enabled for a reference connection established between a source entity and a recipient entity.

[0093] Thanks to the approach, the packet scheduling policy is characteristic of the various applications that are the subject of the data exchange between the source entity and the recipient entity, which allows a level of granularity adapted to the various these applications and traffic profiles. Thus, this configuration is not "global", that is, it is not universal (that is, regardless of the number and nature of the applications that result in the data exchange between the source entity and the recipient entity), nor is it systematic (that is, the application of the scheduling policy is characteristic of the nature of these various applications, but also of the conditions of the access network and of the variations of these conditions). In other words, various packet scheduling policies can be dynamically negotiated and implemented for various reference connections established between entities connected to at least one network. In particular, various packet scheduling policies can be implemented for various applications that generate traffic between the same source entity and the same recipient entity, which traffic is routed along various routes connecting the source and recipient entities.

[0094] For example, in the context of a WAN network interconnecting several LANs hosted at separate sites of a company, the proposed solution helps to optimize the use of resources within and between sites so that traffic routing can reflect the dynamic execution of packet scheduling policies that are consistent with the characteristics of the various applications that may generate intra-site or inter-site traffic (in particular, consistent with the quality of service and / or security requirements of these applications).

[0095] According to at least one embodiment, the proposed solution contributes to improving the quality of experience perceived by users of connected services. The solution in particular makes it possible to detect (and therefore anticipate) any degradation in the quality of experience that may be caused, for example, by a network failure (failure or overloading of a communication link, overloading of a switching device, etc.). Furthermore, the proposed solution does not compromise the integrity of sensitive information and respects its confidentiality. In fact, no information used to manage the quality of experience perceived by users located on a given site is shared with external entities.

[0096] Figure 1 Main steps implemented by the source entity 11 and / or the recipient entity 12 for managing data traffic between the source entity 11 and the recipient entity 12 according to at least one embodiment of the present invention are shown.

[0097] This technique for managing data traffic implements the selection 13 of at least one policy (e.g., PSS for “Packet Scheduler SCHEMATICS”) for the source entity 11 and the recipient entity 12 for scheduling application data packets exchanged between the source entity 11 and the recipient entity 12, taking into account at least one characteristic of an application associated with the application data. For example, such a characteristic is of the type of maximum transmission time, maximum packet loss rate, maintaining confidentiality of the exchanged information, etc.

[0098] In particular, the at least one selected packet scheduling strategy is supported by the source entity 11 and the receiver entity 12. For example, the previous step of checking the capabilities of the source entity 11 and / or the receiver entity 12 may be implemented to determine one or more packet scheduling strategies supported by the source entity 11 and the receiver entity 12.

[0099] The technology for managing data traffic according to the present invention also implements the establishment 14 of at least one reference connection between the source entity 11 and the recipient entity 12. This reference connection is particularly configured, established and used to implement one or more selected packet scheduling policies. These policies can be implemented at the layer responsible for establishing the reference connection (e.g., TCP, QUIC) or at other levels (e.g., queue management in a network interface card, IP path management). When scheduling policies are configured for the reference connection but their implementation is not (exclusively) the responsibility of the layer responsible for establishing the reference connection, identifiers of these policies can be exposed via an API dedicated to accessing the module responsible for applying these policies.

[0100] For example, such a reference connection uses a transport layer protocol that improves the security of the exchange between the source entity and the recipient entity, such as the QUIC protocol. In other embodiments, the reference connection can be based on the use of another protocol (e.g., TCP (with or without MPTCP option), GRE, GTP, IKE).

[0101] As mentioned above, according to the first example, the source (receiver, respectively) entity may be a first device connected to a local area network, such as a terminal, and the recipient (receiver, respectively) entity may be a second device connected to at least one external network, such as a remote server, a second terminal, etc. According to the second example, the source (receiver, respectively) entity may be an access device connected to a local area network and at least one external network, routing application data from (receiver, respectively, to) the first device connected to the local area network, and the recipient (receiver, respectively) entity may be a second device connected to at least one external network, such as a remote server, a second terminal, etc. According to the third example, the source (receiver, respectively) entity may be an access device connected to a local area network and at least one external network, routing application data from (receiver, respectively, to) the first device connected to the local area network, and the recipient (receiver, respectively) entity may be a hub device (hub), routing application data to (receiver, respectively, from) the second device connected to at least one external network.

[0102] In the following, no assumptions are made about the nature of the entities involved (fixed terminals, mobile terminals, CPE (customer premises equipment), STB (set-top box), access points (e.g. hotspots), etc.), about the architecture of at least one local area network to which at least one of these entities is connected, about the architecture of the wide area network connecting at least one local area network to which at least one of these entities is connected (fixed or mobile infrastructure, public or private infrastructure, etc.), about the nature of the network supporting the communication established between the local area networks or on the Internet, etc. For example, the local area network or the wide area network may be a home network, a company network, a university campus network, a robot connecting sites, or an industrial network interconnecting several production sites, etc. Similarly, no assumptions are made about the nature of the application(s). The IP connection may in particular be provided via a wired network, a wireless network (e.g., 5G, beyond 5G (B5G), 6G), or both.

[0103] Example

[0104] Wide Area Network

[0105] Detailed examples of the present invention are given below.

[0106] For example, consider Figure 2 The WAN network shown interconnects at least one LAN network 21 (eg, associated with corporate site #i) and one or more external networks 221, 222, 22j (also referred to as access networks).

[0107] One or more terminals or hosts H1, H2, H3 are connected to the LAN 21. One or more access devices or client devices CE1, CEk are also connected to the LAN 21. These access devices enable the LAN 21 to be connected to at least one of the external networks 221, 222, 22j to which the server S can be connected.

[0108] For example:

[0109] - One or more access devices can be used to connect a local area network to the same external network: for example, access devices CE1 and CEk can connect local area network 21 to external network Net.#2 222,

[0110] - The same access device can be used to connect a local area network to several access networks: for example, access device CE1 can connect local area network 21 to external networks Net.#1 221 and Net.#2 222,

[0111] - A local area network can be connected to several access networks using one or more access devices: for example, access devices CE1 and CEk can connect local area network 21 to external networks Net.#1 221, Net.#2222 and Net.#j 22j.

[0112] In the following, the term "CE" is used to denote any device connected to a local area network and which can connect the local area network to at least one external (access) network. A CE may in particular be a router, or a device that simply forwards traffic to or from a local area network.

[0113] The CE may in particular be placed under the operational responsibility of a local area network administrator or an operator of one of the external networks or the like.

[0114] In a specific embodiment, at least one of the external networks 221, 222, 22j may be a wired access network, a cellular access network (5G, B5G, 6G, etc.), a transit network, etc.

[0115] In particular, the external network may provide, in particular, global IP connectivity (in particular enabling access to the Internet) or limited connectivity (e.g. only to sites of the same company, access to resources hosted in a private or public cloud infrastructure, etc.). Of these various accesses, one or more may be dedicated to the connection of a single site (as is often the case for companies that wish to benefit from an exclusive connection that is not shared with other entities). It should also be noted that these various accesses may be managed by the same operator or by separate operators.

[0116] When considering a WAN network that connects several LAN networks hosted on separate sites of the same company, the communication between the company's sites can be of various types:

[0117] - "Any-to-any": stations can communicate with each other without any restrictions,

[0118] - "hub-and-spoke": Spoke sites can only communicate with the hub site, while hub sites can communicate directly with each other.

[0119] - "hub-spoke-disjoint": This pattern is similar to the "hub-spoke" pattern, except that the "hubs" cannot communicate with each other.

[0120] These engineering choices may be distorted by the nature of the traffic that may be exchanged between sites, traffic prioritization policies, the engineering of access to the company's internal resources as users move around, and so on.

[0121] The present invention notably has application in these various contexts.

[0122] In certain embodiments, the CE may communicate with at least one network element referred to as a "network centric device" or "centric device" via all or some of these various external networks via a dedicated reference connection, typically based on the establishment of a tunnel.

[0123] No assumptions are made about the location of the central device.

[0124] As an example, at least one central device 23 may be deployed in at least one of the external networks 221 , 222 , 22j .

[0125] For example, consider that the first device is a terminal H1, which needs to run an application hosted by a server S. The application data exchanged between the terminal H1 and the server S is transmitted via an "application" connection between the terminal H1 and the server S, such as Figure 2 As shown by the dotted line in .

[0126] If both the terminal H1 and the server S support the process for selecting at least one packet scheduling strategy according to the present invention, the traffic distribution between various external networks can be managed by the terminal H1 and / or the server S. A reference connection according to the present invention can then be established between the terminal H1 and the server S. In this case, the application connection and the reference connection can be the same connection.

[0127] If the terminal H1 does not support the process for selecting at least one packet scheduling strategy according to the invention, but the server S does support such a process, the traffic distribution may be managed by at least one access device CE1, CEk of the local network and / or the server S. A reference connection according to the invention may then be established between the access device and the server. Such a reference connection may in particular be associated with an application connection for routing application data between the terminal and the server via the access device.

[0128] If neither the terminal H1 nor the server S supports the process for selecting at least one packet scheduling strategy according to the invention, the traffic distribution can be managed by at least one access device CE1, CEk of the local area network and / or by at least one central device 23. A reference connection according to the invention can then be established between the access device and the central device. Such a reference connection can be associated in particular with an application connection for routing application data between a client and a server via the access device and the central device.

[0129] An example of a reference connection 24 between an access device and a central device is shown in Figure 2 In particular, it is shown as a solid line.

[0130] Operation of access equipment and central equipment

[0131] For simplicity, the following is placed in the context of a process for selecting at least one packet scheduling strategy that is not supported by the terminal H1 and the server S. Therefore, the traffic distribution between the various external networks is managed and executed by at least one access device CE1, CEk and / or at least one central device 23 of the local area network, and the selected one or more packet scheduling strategies are implemented on a reference connection between the access device and the central device, which is therefore different from the application connection established between the terminal H1 and the server S.

[0132] However, it should be noted that this is merely an example, and for data traffic from a LAN to an external network, the steps described below for a CE may more generally be implemented by a source entity, and the steps described below for a central device may be implemented by a receiver entity.

[0133] For data traffic from the external network to the LAN, the source entity may be the central device, and the receiver entity is the CE.

[0134] According to the example considered, the CE may be configured with at least one information item for identifying or reaching at least one hub device. Several hub concentrators may be declared to the same CE, for example by means of static configuration or dynamic configuration using a protocol such as DHCP or CWMP or NETCONF, to provide identification / reachability information of the hub device(s).

[0135] In particular, if the network supporting inter-site communication is an SD-WAN network, i.e., a network whose resources are controlled and operated by a logically centralized computing intelligence (commonly referred to as an SDN controller), the central device can be an SD-WAN GW gateway.

[0136] The information used to identify the central device includes, for example, one or more IP addresses (IPv4 and / or IPv6), one or more port numbers and / or authentication identifiers, etc.

[0137] According to a first example, the authentication identifier can be used in particular to check whether the central device is authorized to establish a reference connection with the CE. This identifier can be checked when a first reference connection is established between the CE and this central device. This connection is usually established using a dedicated tunnel for each available access path established between the CE and the central device.

[0138] According to a second example, the address and / or port number may in particular be used as a destination address and / or port number of a reference connection to identify the central device.

[0139] As mentioned above, the central device is particularly configured to be able to route data received from one CE to another CE, to (respectively, from) a server located in a public cloud or a private cloud, or more generally, to (respectively, from) a server connected to the Internet. In addition, the central device can maintain entries in a table, such as a BIB (Binding Information Base), whose entries enable the central device to select the relevant CE to which the return traffic will be routed.

[0140] Data Packet Scheduling Strategy

[0141] As described above, in particular with respect to the general principles of the present invention, at least one data packet scheduling strategy (PSS) may be selected for a source entity / receiver entity pair. Such a data packet scheduling strategy may in particular support all or some of the following functions:

[0142] - Path management,

[0143] - congestion management,

[0144] - Packet reassembly,

[0145] - Group reordering,

[0146] -etc.

[0147] The PSS may consider other parameters for performing the previously described functions, such as:

[0148] - pricing conditions, for example as set out in contracts with operators of various external networks,

[0149] - user instructions, e.g. minimizing incurred costs, balancing path usage, etc.,

[0150] - Experience of use (past, history) of the resources associated with each external network, which makes it possible, for example, to qualify the stability of certain resources in use and to implement appropriate maintenance strategies.

[0151] An entity implementing the present invention (e.g., a CE or a hub) may specifically consider various parameters to select at least one PSS of application data exchanged between a source entity and a receiver entity, while considering at least one characteristic of an application associated with the application data. For example, an entity implementing the present invention may select at least one PSS so that the use of resources can be adapted, and / or the delay can be optimized, and / or the use of resources can be maximized, and / or their availability can be improved, etc.

[0152] An entity implementing the present invention (e.g. a CE or a hub) may in particular establish at least one reference connection between a source entity and a receiver entity, on which the selected PSS is implemented. In some embodiments, such a reference connection is based on at least two sub-connections, each of which is associated with a separate path between the source entity and the receiver entity. The selection of (multiple) sub-connections for routing application data may in particular depend on the application mode of the selected PSS.

[0153] The entity implementing the present invention (e.g., CE or hub) may in particular maintain information characteristics of at least one external network that feeds, for example, local functions for monitoring and detecting symptom characteristics of deterioration of the quality of service or quality of experience (QoE) of a given application. Such functions are, for example, based on the use of data that can be processed by artificial intelligence techniques (such as machine learning) and the use of specific learning algorithms (e.g., reinforcement learning algorithms) and are executed locally (usually supported by the CE). For example, such functions can be used to monitor:

[0154] - Queue Fill Rate: Monitors the queues observed on each interface that the CE uses to connect to the external network. The queue fill rate can provide information to the CE about the quality of transmission via the interfaces involved. This information can be used to decide which interface to use for routing data according to the quality of service or QoE requirements of a given application, e.g.

[0155] - the one-way transmission delay observed on the path,

[0156] - the round trip time (RTT) observed on the path, in particular on the path providing access to the central device,

[0157] - the packet loss observed on the path,

[0158] -Inter-packet delay variation or jitter,

[0159] - by simulating some application robots (such as VoIP robots or Advanced application parameters calculated by the robot,

[0160] - the history of congestion observed on the path,

[0161] -etc.

[0162] For example, monitoring the quality of service or QoE of a given application from the monitoring function specifically allows updating the application mode of the selected PSS. In other words, for example, depending on the quality of service or QoE constraints of the application, the CE (respectively the central device) can use these various information items to perform several actions characteristic of the application of the PSS. Such actions may include executing certain algorithms, such as:

[0163] - Round Robin Algorithm: The paths (also called "links") are called round robin according to the exit point (CE for traffic from the LAN to the external network) associated with each path. The weight of each path can be set by the administrator or calculated (dynamically) according to several parameters (such as the cost of optimizing the reference connection), for example.

[0164] - Optimize the storage time of packets in the queue with the help of time interval management,

[0165] - Priority-based: A priority is assigned to each path, e.g. considering a PBR (Policy Based Routing) policy,

[0166] -RTT threshold: A path is used until a certain RTT threshold is reached. For example, the threshold is set so that the PSS application can ensure that the used path does not have an RTT that does not meet the application's expectations. The (multiple) algorithms involved in the application of PSS (particularly the queue management algorithm) significantly enable active management of delay degradation,

[0167] - Priority assigned to the path with the lowest RTT ("Lowest RTT First"): such paths are preferred, for example, to route traffic to a central device.

[0168] -etc.

[0169] Various histograms and statistical distributions can also be maintained for active management of quality of service and QoE parameters. Traffic can then be allocated between various paths, for example, based on QoE targets, and not just based on the QoE observed at a given moment. For example, a CE can:

[0170] - duplicating a portion of data packets between several paths within a given time period (e.g. expressed as a percentage of the total traffic),

[0171] - Switching all or part of the traffic to one or more source entities based on observed queue filling rates, changes in RTT parameters, or based on other criteria or symptoms observed by the source entities.

[0172] In a particular embodiment, the data packet scheduling strategy PSS may be identified by a unique identifier. For example, the PSS may be identified by an integer, a name, etc. The PSS of each source entity / receiver entity "pair" may be specifically referenced in a register (e.g., PSS1 between a given CE and a given central device, PSS2 between a given central device and a given server, PSS3 between a given terminal and a given server).

[0173] Select and implement data packet scheduling strategies

[0174] Return to Figure 2 And an example according to which neither the terminal H1 nor the server S supports a process for selecting at least one packet scheduling strategy.

[0175] When establishing the first reference connection from the CE to the hub, the CE (e.g. CE1) checks whether the hub 23 supports the process for selecting at least one packet scheduling strategy according to the present invention. As a variant, the CE can use a dedicated connection to check whether the hub supports the process. The connection is then closed and is therefore not used to transmit application data.

[0176] For example, a first reference connection using a transport layer protocol (eg, QUIC) is established between CE1 and hub 23 .

[0177] According to a particular embodiment, the CE is able to use a new QUIC transmission parameter referred to herein as "Customized_PSS" to indicate that the entity sending the parameter (e.g., CE1 or hub 23) supports a process for selecting at least one packet scheduling policy.

[0178] For example, a "Customized_PSS" parameter set to "0x1" indicates that the entity sending the parameter supports the process for selecting at least one packet scheduling policy, and a "Customized_PSS" parameter set to "0x0" (or the absence of such a parameter) indicates that the sending entity (e.g., CE1 or hub 23) does not support the process for selecting at least one packet scheduling policy.

[0179] If a source entity (eg, CE1) receives a "Customized_PSS" parameter set to "0x1" from a receiver entity (eg, hub 23), the source entity may transmit to the receiver entity a packet scheduling policy or a list of policies supported by the source entity.

[0180] If the QUIC protocol is used on the first (dedicated or reference) connection established between a source entity and a recipient entity, the source entity may use a new QUIC frame (referred to herein as a QUIC PSS frame) to inform the destination entity of one or more packet scheduling policies supported by the source entity. The recipient entity may store in memory a list of PSSs supported by the source entity, in particular for return traffic management.

[0181] The receiver entity may send to the source entity a list of one or more packet scheduling strategies supported by the receiver entity (particularly if the source entity has not yet communicated to the receiver entity the PSS supported by the source entity), or a selection of packet scheduling strategies supported by the source entity and the receiver entity.

[0182] For example, the source entity receives in a QUIC PSS frame a list of PSSs supported by the destination entity: PSS#1, ..., PSS#i.

[0183] The source entity may specifically store in a memory a list of PSSs supported by the recipient entity.

[0184] For example, the transmission of the PSS list supported by the receiver entity from the receiver entity to the source entity may be implemented periodically (eg, every 24 hours) to refresh the PSS list stored in the memory of the source entity.

[0185] It is hereafter considered that the source entity and the receiver entity support at least one common PSS. It is also considered that the source entity and the receiver entity also support at least one same application mode of the PSS.

[0186] Among the PSSs supported by the source entity and the recipient entity, at least one PSS is selected taking into account characteristics of an application associated with application data exchanged between the source entity and the recipient entity. Such characteristics may in particular include constraints of the application in question.

[0187] At least one reference connection is established between the source entity and the recipient entity (for example, when starting or restarting the source entity, or when establishing the communication characteristics of the application used, such as when establishing an HTTP (application) connection from a terminal connected to a local area network in which one or more CEs according to the present invention are deployed, also called an application connection), and at least one selected PSS is implemented on the reference connection.

[0188] Such a reference connection is for example based on the QUIC protocol.

[0189] In one embodiment, at least one PSS is selected prior to establishing a reference connection. For example, the source entity selects a PSS to be enabled for a reference connection (associated with an application or a set of applications of the same type) and passes the PSS identifier to the recipient entity. The source entity and the recipient entity then enable the same PSS for the reference connection. In another embodiment, at least one PSS is selected simultaneously with the reference connection establishment. It should be noted that the same PSS may be applied to one or more reference connections established between the source entity and the recipient entity.

[0190] In particular, if the recipient entity supports PSS, the reference connection is accepted by the recipient entity. If negotiation of the PSS was previously performed between the source entity and the recipient entity, this step of checking the capabilities (to support said PSS) is not required and not when establishing the reference connection. If the PSS indicated by the source entity is not supported by the recipient entity or if the "Customized_PSS" parameter set to "0x1" has not been exchanged between the source entity and the recipient entity, the request to establish the reference connection is rejected.

[0191] A source entity, such as a CE, may in particular establish a reference connection comprising several sub-connections (also called multipath connections) with a recipient entity (e.g. a hub). As already indicated, the establishment of sub-connections enables traffic to be switched / redirected to one path or another, for example depending on the QoE target set by the application or according to changes in transmission conditions (e.g. a deterioration in transmission time).

[0192] To this end, for a reference connection for which at least one PSS has been selected, the source entity negotiates with the central device the application mode of the PSS to be executed for the application flow transmitted on the reference connection. The negotiation may be performed when establishing the communication characteristics of the application used between the terminal and the server (also called the application connection). The data packets sent over the reference connection are then distributed between various paths depending on the application mode of the enabled PSS and according to the quality of service and QoE conditions observed by the source entity.

[0193] Variants

[0194] In certain embodiments, traffic classification information may be provided to a source entity and / or a recipient entity to associate a type of application with a packet scheduling policy that will satisfy, for example, quality requirements associated with this type of application.

[0195] In other words, a source entity and / or a recipient entity may associate an "application" connection (which transports application data) with a reference connection over which a PSS is implemented that is selected to meet quality requirements associated with this type of application.

[0196] The classification information can be:

[0197] - configured by an administrator using an administration interface specific to the source entity and / or the recipient entity,

[0198] - Communication through a signaling mechanism such as the PCP (Port Control Protocol) protocol: the PCP client can then be embedded in a terminal connected to the local area network,

[0199] - Exposed by an application server via a dedicated API: For example, the calling of the API may be mediated by an agreement between the server provider and the entity managing the communication service (e.g., the operator of the SD-WAN network).

[0200] - via a transport API, such as the API described in document RFC6897 "Multipath TCP (MPTCP) Application Interface Considerations" from March 2013 or the "QUIC API for Peer-to-peer Connections" from the W3C Community Group Draft Report from March 3, 2022,

[0201] -etc.

[0202] Thus, the source entity may specifically select the application mode of the PSS to be implemented to associate the received traffic with a pre-established reference connection, or decide to establish a new reference connection, taking into account at least one element belonging to the group comprising:

[0203] - Traffic classification information items,

[0204] -PSS identifier,

[0205] - a heuristic local to the source entity,

[0206] - Changes in transmission conditions (e.g., degradation of the delay observed on the reference connection or a sub-connection).

[0207] Traffic is then associated with the output interface of the source entity and then routed through the associated sub-connection(s).

[0208] It should be noted that the source entity and the receiver entity may use different paths to route outbound and return traffic, for example, if the quality of service or QoE target is to be met in only one traffic routing direction (CE to hub or hub to CE).

[0209] In particular, if no available path meets the quality requirements of the application, the source entity may transmit an alarm to an entity having management responsibility for it (eg, an SDN controller of the site where the source entity is deployed).

[0210] The case where the source entity is an access device and the receiver entity is a central device (traffic comes from the LAN and goes to the external network) has been described above. Of course, the above operation can be implemented in the case where the source entity is a central device and the receiver entity is an access device (traffic comes from the external network and goes to the LAN). Similarly, if the process for selecting at least one packet scheduling strategy according to the present invention is supported, the above operation can be implemented by a first device such as a terminal, and / or if the process for selecting at least one packet scheduling strategy according to the present invention is supported, the above operation can be implemented by a second device such as another terminal, a server, etc. Therefore, the source entity can be a terminal and the receiver entity is a server (or vice versa), the source entity can be an access device and the receiver entity is a server (or vice versa), the source entity can be a central device and the receiver entity is a server (or vice versa), the source entity can be an access device and the receiver entity is a server (or vice versa), the source entity can be an access device and the receiver entity is a central device (or vice versa), and the source entity can be an access device and the receiver entity is a central device (or vice versa).

[0211] Multiple access devices

[0212] A specific embodiment is described below, according to which several access devices are connected to the same local area network. In this case, one of the access devices can be selected as a LAN exit point (corresponding entry point).

[0213] The various CEs connected to the same local area network can in particular use the dedicated channel to share with each other information related to the various external networks, for example, information characteristics of the traffic through the CEs connected to the external network. Such information can in particular be used to select one of the CEs connected to the local area network to route application data between the terminal and the server.

[0214] according to Figure 3 As a first example shown, the dedicated channel may be of the "point-to-multipoint" type.

[0215] Thus, the access device CE1 can receive information about at least one of the external networks from at least one other access device CE2, CE3, CEk connected to the local area network and capable of establishing a reference connection with the remote server S or the central device 23. One embodiment of this point-to-multipoint channel is based on a multicast transmission mode, in which all CEs subscribe to the same multicast group defined by a specific group address. For example, statically or dynamically using the resources of a protocol such as DHCP or CWMP or NETCONF, the multicast address is declared in all CEs that have subscribed to the same multicast group.

[0216] By CE (e.g. Figure 3 The information received by CE2 from other CEs (e.g., CE1) can thus feed the path selection process implemented by the CE to route data received from terminals connected to the local area network to one or more central devices. Such information is, for example, the characteristics of various types of traffic passing through various CEs, such as {source address; receiver address} pairs.

[0217] Thus, this information can be used by at least one CE to change the routing for application data traffic in the local area network according to a packet scheduling policy selected for an application associated with the application data. This information can be used in particular by at least one CE to determine an exit point for the application data traffic according to various criteria, such as the destination of the traffic sent by a terminal connected to the local area network, the nature of the traffic sent by the terminal connected to the local area network and its constraints in terms of latency or inter-packet delay variations that can impose one path rather than another to reach the central device, etc.

[0218] For example, the selection of a CE will be regulated by its capabilities to help meet the quality of experience (QoE) level characteristics of the nature of the service or application used by the terminal connected to the local area network to reach a given destination. To this end, each of the CEs used to reach the destination selects a preferred path based on local conditions (e.g., access to a service or remote site) that may optimize the user's perceived QoE and announces the path in the local area network. A CE that helps provide the best QoE will be selected to route traffic to a given destination. It should be noted that the same process can be used for the default path («wildcard»: «:: / 0» (IPv6) or «0.0.0.0 / 0» (IPv4)).

[0219] For example, consider an application connection established between terminal H2 and server S.

[0220] Figure 4A and Figure 4B A first path between the terminal H2 and the server S at time T0 and a second path at time T1 are shown.

[0221] At time T0, if Figure 4AAs shown, an application connection (e.g., via CE1) is associated with a reference connection established between CE1 and hub 23. In other words, the application connection that transmits application data between CE1 and hub 23 is associated with a reference connection established between CE and hub. Therefore, the application data passes through access device CE1 and the external network Net.#1. The various access devices CE1 and CEk can specifically observe the wide area network (transmission time, available bandwidth, traffic profile, etc.) and select an exit point (CE for traffic from the LAN to the external network) based on the QoS parameters observed by the CE and exchanged via the channels established between CEs of the same site (Site#i).

[0222] At time T1, if Figure 4B As shown, another exit point (CE) is selected. The application connection is then associated with the reference connection established between CEk and hub 23. The data is then transmitted through access device CEk and external network Net.#j.

[0223] It should be noted that, in the event that traffic is redirected to another exit point, the continuity of the application connection established between the terminal H2 and the server S can be maintained by the presence of the same central device 23 in the various sub-connections or paths taken by the data passing through this same central device.

[0224] In a particular embodiment, the selection of a CE from among several CEs connected to the local area network also takes into account identifiers associated with application data exchanged between the terminal and the server.

[0225] According to a first example, such an identifier is an application identifier, such as an "app-id". The "app-id" identifier can be used in particular by the terminal to route packet characteristics of a specific application, also called application data. As an example, applications with the same QoE constraints can be identified by the same application identifier. For example, an application can pass its identifier ("app-id") via a local network API to indicate to the routing / forwarding process embedded in the CE the "application" route to be used for routing the data of the application within the local area network. For example, a route announcement message contains an application identifier, which makes it possible to maintain specific routes for each application in the local area network. In doing so, the local area network can then maintain differentiated routes for each application, and therefore, a separate CE can be selected to route traffic to the same destination for a given application.

[0226] According to other examples, other identifiers may be used to select one route over another: for example, the same DSCP (DiffServ Code Point) encoding may result in the selection of a route for traffic marked EF (Expedited Forwarding) and another route for traffic marked AF (Assured Forwarding), without prejudging the nature of the application(s) that will benefit from such differentiated treatment. In this case, the "dscp-val" identifier may be associated with the routes advertised between CEs in messages exchanged between CEs over a dedicated channel.

[0227] As an example, Figure 5 The selection of an exit point (CE1 or CEk, for traffic from the LAN and to the external network) is shown based on the application ("app-id") and QoE parameters observed and exchanged between CEs at the same site (Site#i). Separate routes are used to route traffic based on application constraints and conditions observed by the various exit points (CEs) connected to the same local area network. For example, a first route via access device CE1 is preferably used for an application identified by an app-id=1 identifier, and a second route via access device CEk is preferably used for an application identified by an app-id=2 identifier.

[0228] It should be noted that, in the present embodiment of implementing multiple CEs, in order to avoid conflicting instructions between CEs at the same site (ie connected to the same local area network), the CE must inform other CEs before changing the route.

[0229] A first example has been described above, according to which the dedicated channel may be of the "point-to-multipoint" type.

[0230] Figure 6 A second example is shown according to which the channel dedicated to sharing information between CEs is a "point-to-point" channel.

[0231] According to this example, at least one access device connected to the local area network and enabling a reference connection to be established with a remote server S or central device 23 sends information related to at least one of the external networks to which it is connected to the controller 61. Such information can be used in particular to select one of the CEs connected to the local area network to route application data between the terminal and the server.

[0232] For example, one example of establishing such a point-to-point channel is establishing a (control) connection between a CE and one or more controllers operated by a company.

[0233] Such a controller 61 (e.g. an SDN controller) can be local to each site. In this way, watertight communication between the various sites can be maintained. In fact, the decisions taken by such a controller (routing policies, traffic redirection, site CE management, etc.) are local to the site. In fact, these decisions do not interfere with decisions taken by other controllers deployed on other sites. Such engineering is also used to be independent of the connections between sites, which helps to increase the robustness and the ability to apply the decisions taken by the controller without causing additional delays or compromising the application of the decisions, especially when decisions must be taken in response to new quality of service or QoE conditions observed at the site under consideration.

[0234] Alternatively, a single controller may be used to manage various sites where several CEs are deployed. In this case, the controller may associate the CEs with their deployment sites. For example, this information item may be configured in the controller by an administrator or retrieved from each CE using a protocol such as NETCONF.

[0235] Regardless of which engineering is chosen (one controller per site or one controller for all sites), the controller uses the information received from the various CEs to decide on a local policy for selecting (multiple) exit points within the LAN to route traffic to a given destination, for all destinations or a subset of destinations, taking into account several criteria such as quality of service or QoE conditions, the nature of the traffic, various traffic profiles, traffic prioritization strategies, etc.

[0236] As previously mentioned Figure 5 As described, the controller can specifically configure routes for a CE that are specific to a set of applications with similar quality of service or QoE constraints. For example, an "app-id" identifier can be used to demultiplex routes and select the exit point for each application (CE, for traffic from the LAN and going to the external network). The controller can also be responsible for establishing (multiple) channels dedicated to sharing information between CEs: exchanging information between CEs via such a point-to-point channel can also involve the controller itself, because the collected information can be used as input data for calculating the routes that will pass through this CE or that CE (and dynamically instantiating the associated "application" routing policy).

[0237] For example, consider an application connection established between terminal H2 and server S. Fig. 7A and Figure 7B A first path between the terminal H2 and the server S at time T0 and a second path at time T1 are shown.

[0238] At time T0, if Fig. 7AAs shown, data passes through access device CE1 and external network Net.#1. The application connection is associated with the reference connection established between CE1 and hub 23. The controller 61 can specifically collect information from the various access devices CE1 and CEk and select an exit point (CE for traffic from the LAN to the external network) based on the QoS parameters observed by the CE of the same site (Site#i).

[0239] At time T1, if Figure 7B As shown, another exit point (CE) is selected. Then, the data passes through the access device CEk and the external network Net.#j. The application connection is associated with the reference connection established between CEk and hub 23.

[0240] It should be noted that, in the case where traffic is redirected to another exit point, the continuity of the application connection established between the terminal H2 and the server S can be maintained by the presence of the same central device 23 in the various sub-connections or the various paths taken by the data through the same central device.

[0241] According to a specific embodiment, the channel type (point-to-point or point-to-multipoint) for sharing information between CEs can be provided to each CE of the same local area network or configured in each CE. If no such information is provided to the CE, the process for communicating and sharing information between CEs is disabled by default.

[0242] The corresponding entity

[0243] Finally, about Figure 8 A simplified structure of a source and / or receiver entity according to one embodiment of the invention is presented.

[0244] According to one embodiment of the present invention, the source and / or receiver entity includes a memory 81, a processing unit 82, which is equipped with, for example, a programmable computer machine or a dedicated computer machine, such as a processor P, and is controlled by a computer program 83 to implement the steps of the traffic management method according to at least one embodiment of the present invention.

[0245] Upon initialization, the code instructions of the computer program 83 are loaded into RAM memory, for example, before being executed by the processor of the processing unit 82 .

[0246] The processor of the processing unit 82 implements the steps of the previously described traffic management method according to the instructions of the computer program 83 to:

[0247] - selecting for said source entity and said recipient entity at least one policy for scheduling application data packets exchanged between said source entity and said recipient entity taking into account at least one characteristic of an application associated with the application data,

[0248] said at least one selected packet scheduling strategy being supported by said source entity and said receiver entity,

[0249] - establishing at least one connection between said source entity and said receiver entity, implementing said at least one selected packet scheduling strategy on said at least one connection.

Claims

1. A method for managing data traffic between a source entity (11) and a receiver entity (12), implementing the following steps: selecting (13) for said source entity and said recipient entity at least one policy for scheduling application data packets exchanged between said source entity and said recipient entity taking into account at least one characteristic of an application associated with the application data, said at least one selected packet scheduling strategy being supported by said source entity and said receiver entity, • Establishing (14) at least one connection between said source entity and said recipient entity, implementing said at least one selected packet scheduling strategy on said at least one connection.

2. The method according to claim 1, characterized in that The source entity sends to the recipient entity a list of at least one packet scheduling policy supported by the source entity.

3. The method according to any one of claims 1 and 2, characterized in that The source entity receives from the receiver entity a list of at least one packet scheduling policy supported by the receiver entity.

4. The method according to any one of claims 1 to 3, characterized in that The source entity sends parameters to inform the receiver entity that the source entity is capable of implementing the at least one selected packet scheduling strategy, or correspondingly, the receiver entity sends parameters to inform the source entity that the receiver entity is capable of implementing the at least one selected packet scheduling strategy.

5. The method according to any one of claims 2 to 4, characterized in that The list according to claim 2 or claim 3 and / or the parameters according to claim 4 are sent using a transport layer protocol between the source entity and the recipient entity.

6. The method according to any one of claims 1 to 5, characterized in that The connection comprises at least two sub-connections, each sub-connection being associated with a separate path between the source entity and the recipient entity, and the source entity transmits the application data over at least one of the sub-connections taking into account the at least one packet scheduling policy selected for the connection.

7. The method according to any one of claims 1 to 6, characterized in that The method includes receiving at least one item of traffic classification information such that at least one packet scheduling policy can be associated with an application type.

8. The method according to any one of claims 1 to 7, characterized in that The application mode of the at least one selected packet scheduling strategy is updated periodically and / or depending on changes in routing conditions of application data exchanged between the source entity and the receiver entity.

9. The method according to any one of claims 1 to 8, characterized in that The source entity is a first device connected to a local area network and the recipient entity is a second device connected to an external network, or respectively, the recipient entity is a first device connected to a local area network and the source entity is a second device connected to an external network.

10. The method according to any one of claims 1 to 8, characterized in that The source entity is an access device connected to a local area network and at least one external network, which routes the application data from a first device connected to the local area network, and the recipient entity is a second device connected to one of the at least one external networks, or correspondingly, the recipient entity is an access device connected to a local area network and at least one external network, which routes the application data to a first device connected to the local area network, and the source entity is a second device connected to one of the at least one external networks.

11. The method according to any one of claims 1 to 8, characterized in that The source entity is an access device connected to a local area network and at least one external network, which routes the application data from a first device connected to the local area network, and the recipient entity is a central device, which routes the application data to a second device connected to one of the at least one external networks, or correspondingly, the recipient entity is an access device connected to a local area network and at least one external network, which routes the application data to a first device connected to the local area network, and the source entity is a central device, which routes the application data from a second device connected to one of the at least one external networks.

12. The method according to any one of claims 10 and 11, characterized in that The access device establishes at least two connections between the source entity and the receiver entity, each connection implementing a separate packet scheduling strategy selected in consideration of at least one characteristic of an application.

13. The method according to any one of claims 10 to 12, characterized in that The access device receives information about at least one of the external networks from at least one other access device, which is connected to the local area network and has established a connection with the second device according to claim 10 or the central device according to claim 11.

14. The method according to any one of claims 10 to 12, characterized in that The access device sends information related to at least one of the external networks to the controller, and the controller receives information related to at least one of the external networks from at least one other access device, wherein the at least one other access device is connected to the local area network and has established a connection with the second device according to claim 10 or the central device according to claim 11.

15. The method according to claim 13 or claim 14, characterized in that The method selects one of the access devices to route the application data from the first device or, respectively, to the first device, taking into account the information related to at least one of the external networks.

16. The method according to claim 15, characterized in that The selection of one of the access devices also takes into account an identifier associated with the application data.

17. A source (11) entity capable of communicating with a receiver (12) entity, the source (11) entity comprising at least one processor, or, respectively, a receiver (12) entity capable of communicating with a source (11) entity, the receiver (12) entity comprising at least one processor, the at least one processor being configured to: selecting (13) for said source entity and said recipient entity at least one policy for scheduling application data packets exchanged between said source entity and said recipient entity taking into account at least one characteristic of an application associated with the application data, said at least one selected packet scheduling strategy being supported by said source entity and said receiver entity, • Establishing (14) at least one connection between said source entity and said recipient entity, implementing said at least one selected packet scheduling strategy on said at least one connection.

Images