WO2025104061A1 - Method for controlling a communication during which data relating to a service are exchanged, and associated electronic devices - Google Patents

Abstract

The invention relates to a method for controlling a communication during which data relating to a service are exchanged between a first electronic device and a second electronic device via a telecommunications network supporting a plurality of network slices. The method comprises the following steps, implemented by the second electronic device: obtaining a datum representative of network slices supported by the network and accessible to the first electronic device; selecting network slices accessible to the first and second electronic devices and compatible with provision of the service, and a communication flow management policy; and transmitting, to the first electronic device, a datum representative of the selected network slices and of the selected flow management policy to be applied, by the first electronic device, to this communication.

Description

Description Title of the invention: Method for controlling a communication during which data relating to a service are exchanged, and associated electronic devices Technical field [1] The present invention belongs to the general field of telecommunications. It relates more particularly to a method for controlling a communication during which data relating to a service are exchanged between a first electronic device and a second electronic device. It also relates to a method for configuring a communication between the first and second electronic devices, as well as these first and second electronic devices. Prior art [2] In order to adapt to the continuous and ever-increasing growth in data traffic emitted by telecommunications systems, different technologies are currently implemented, and are still being improved with a view to optimal operation in the years to come. [3] The architecture of mobile telecommunications networks currently deployed or in the process of being deployed is in particular defined by the standardization consortium known as 3GPP (Third Generation Partnership Project). This is particularly the case for so-called second generation ("2G or GSM"), third generation ("3G"), fourth generation ("4G") and fifth generation ("5G") mobile networks. [4] Up to the fourth generation, the mobile network architectures defined by the 3GPP consortium are most often based on specific equipment, dedicated to specific functions, whether at the access network or core network level, particularly with regard to the transmission of packets from or to a mobile terminal. [5] The lack of flexibility and scalability inherent in this type of architecture has led the 3GPP consortium to consider the adoption of more flexible architectures for the so-called "5G" (fifth generation) generation of mobile networks, in particular in order to be able to respond quickly to extremely diverse demands in terms of traffic and/or quality of service. To meet these various constraints, a 5G mobile network architecture can be based in particular on the concept of SBA ("Service-Based Architecture", in English), on the virtualization of network functions and on slicing the 5G telecommunications network into logical subnets ("network slicing" in English terminology). This network slicing technique is described in particular in the 3GPP TS 23.501 v18.3.0 technical specification, published in September 2023. It allows a network operator to create tailor-made logical subnets, generally dedicated to the routing of traffic sent and received by mobile terminals, and based on the same physical network infrastructure. [6] These logical subnetworks, called "network slices", allow a customer to access a service by relying on both virtualized network functions that can be activated, deactivated and configured according to needs, but also by relying on network functions deployed on a physical network infrastructure. For each network slice, these different types of network functions are then configured to be able to satisfy the requirements of the services supported by the network slice that supports such functions and which typically correspond to the services subscribed to by the users of this slice. [7] A priori, the network slices are controlled independently. Each slice is generally adapted to a specific use, and therefore has specific characteristics in terms of quality of service (for example in terms of latency, throughput, one-way transit time), security and/or capacity. This division allows a telecommunications operator to offer different levels of service meeting different service level agreements ("Service Level Agreement" in Anglo-Saxon terminology). [8] Thus, the 3GPP consortium has defined types of slices capable of meeting as many different needs as the field of high-bandwidth mobile services ("enhanced Mobile Broadband", eMBB), the Internet of Things (IoT), the field of ultra-reliable low-latency communications (URLLC) and that of connected vehicles (Vehicle-to-Everything, V2X). [9] The choice to design and deploy one or more particular types of slices is conditioned in particular by the nature of the traffic generated by the applications used or the services subscribed to by a user of the network supporting slices. For example, a so-called "immersive" service which uses augmented reality or virtual reality techniques is generally very demanding in terms of latency and reliability of data exchanges. Such an immersive service is therefore a "natural" client of a URLLC type slice.[10] The design and deployment of network slices is a complex activity to implement, as it requires taking into account multiple configuration parameters. Furthermore, to ensure that data packet traffic is correctly routed within one or more network slices, said traffic must be authorized. Such authorization is typically based on traffic classification rules. These rules are applied at the ingress of a network/subnetwork that supports the slice(s) in question, more particularly by one or more edge nodes. However, the design of such traffic classification rules and their application by these edge nodes also contribute significantly to the overall complexity of implementing and properly operating a network supporting network slices. Disclosure of the invention [11] The present invention aims to overcome all or some of the drawbacks of the prior art, in particular those set out above, by proposing a solution that allows devices to agree on the network slices they can use to establish communication. [12] To this end, and according to a first aspect, the invention relates to a method for controlling a communication during which data relating to a service are exchanged between a first electronic device and a second electronic device via at least one telecommunications network supporting a plurality of network slices, the method comprising the following steps implemented by the second electronic device: - obtaining data representative of network slices supported by said at least one network and accessible by the first electronic device; - selecting network slices accessible by the first and second electronic devices and compatible with provision of the service, and a policy for managing the flow of the communication via the selected network slices; - transmitting, to the first electronic device, data representative of the network slices and said policy for managing the flow selected for application, by the first electronic device, to this communication. [13] This method for controlling a communication offers the advantage of allowing one of the devices involved in a communication with a view to accessing a service, to control the or the network slices to be used to access this service, but also to negotiate a policy for managing the flows of this communication. In this way, it is no longer necessary to establish traffic rules relating to any authorization that are consistent with each other. [14] "Communication" means any exchange of information between two electronic devices, for example a transmitter or source device at the origin of the communication and a receiver or destination device, using signals produced by the electronic devices. This information is typically exchanged through one or more data streams, each stream corresponding to a sequence of coherent signals digitally encoded to transmit this information in the form of data packets. A communication may result in the establishment of one or more sessions. Generally, a session is defined as an association usually identified by the 4-tuple (source address, source port number, destination address, destination port number) or by connection identifiers (CID, "Connection Identifier") during which the two communicating devices exchange data (e.g. an electronic device performs operations for a client). Several sessions can be used for the same communication. In some contexts such as MPTCP (acronym for Multi-Path TCP), these sessions are called "sub-sessions" (also called "subflows"). [15] No assumption is made as to which device (first or second device) is at the origin of the communication allowing access to the service. [16] Thus, in particular embodiments, the first device is the device at the origin of the communication to access the service, hereinafter referred to as the “service access request device” (resp. an intermediate device to which such a device is connected), and the second electronic device is a device involved in the management of the service, hereinafter referred to as the “service management device”, configured to control the communication during which data relating to this service are exchanged. [17] Alternatively, in other particular embodiments, the first device corresponds to the service management device, the second electronic device corresponds to the device at the origin of the communication to access the service, called the “service access request device”, (resp. an intermediate device to which such a device is connected), and it is this device at the origin of the communication (resp. this intermediate device) which is then configured to control the communication during which data relating to this service are exchanged.[18] "Communication control" means the application, to one or more of the flows of this communication, of specific parameters or processing, such as the use of specific network slices to exchange data, while applying a flow management policy. As mentioned below, this flow management policy is defined according to the capabilities of the first electronic device, but also according to constraints specific to the service to which this first electronic device wishes to access. [19] Thus, the invention allows access to the service in an adapted manner, that is to say by considering the requirements in terms of quality of service required for the provision of this service, but also by considering the constraints specific to the device(s) wishing to access this service (hereinafter referred to as the "service access request device"). [20] In particular embodiments, this service is provided by the second electronic device. Alternatively, this service is provided by a third device distinct from the first and second electronic devices. In this case, the communication according to the invention includes a first exchange between the first and second devices (for example through a first sub-session), then a second exchange between the first and third devices (for example through a second sub-session). [21] Generally, it is considered that the steps of a method should not be interpreted as being linked to a particular chronology. [22] In particular embodiments, the method for controlling a communication may further comprise one or more of the following characteristics, taken in isolation or in all technically possible combinations. [23] In particular embodiments, the first device is a device for requesting access to a service, the second electronic device is a service management device, and obtaining the data representative of network slices accessible by the first device includes receiving, by the management device, said data from the device for requesting access to a service. [24] In particular embodiments, the method according to the invention further comprises an exchange, between the first and second devices, of their respective capacities to use at least one network slice selected from a plurality of network slices and to apply a policy for managing the characteristic communications flows which are routed in said at least one selected network slice.[25] In particular embodiments, the first device is a device for requesting access to a service or an intermediate device to which the device for requesting access to a service is connected, the second electronic device is a service management device, and the method further comprises the following steps, implemented by the second electronic device: − a reception of data, called first data, from the first electronic device and representative of a capacity of the first electronic device to use at least one network slice selected from a plurality of network slices and to apply a policy for managing the flows of the selected communication; and, − a transmission, to the first electronic device, of data, called second data, representative of a capacity of the second electronic device to select at least one compatible network slice for accessing the service and a policy for managing the flows of the communication. [26] These exchanges between the first and second electronic devices allow them to ensure that they comply with the invention, and more specifically that the first electronic device is able to configure a communication in accordance with the instructions of the second electronic device, and that the second electronic device is able to select a suitable configuration based on the service that the first device wishes to access, but also based on the capabilities of the first electronic device. [27] In particular modes of implementation, the first data is transmitted through a message, called the first message, corresponding to a request to establish a communication or to a request to add an additional sub-session to a pre-established session. [28] In particular modes of implementation, the flow management policy comprises at least one transport protocol supported by the first electronic device and making it possible to establish communication on multiple paths. [29] In this case, the use of network slices and the application of the management policy includes use of at least one of the selected network slices and is based on this at least one transport protocol allowing communication to be established on multiple paths to access said service.[30] Thus, access to said service is implemented by exploiting the selected transport protocol for communication using the selected network slice(s), between the first device and the second device. [31] In particular implementations, the at least one transport protocol used is one of: the TCP protocol with the "Multipath TCP" option, the UDP protocol with a "Multipath UDP" extension, the QUIC protocol with the "Multipath QUIC" extension and the MDCCP "Multipath Datagram Congestion Control Protocol" protocol. [32] In particular embodiments, the first device is a service access request device or an intermediate device to which the service access request device is connected, the second electronic device is a service management device, and the method further comprises: - a transmission, by the service access request device or the intermediate device, and to the management device, of data relating to a plurality of transport protocols making it possible to establish communication on multiple paths and which can be used by said service access request device or by said intermediate device; - a selection, by the management device and from among the plurality of transport protocols making it possible to establish communication on multiple paths, of at least one transport protocol adapted to the provision of said service, the selected flow management policy including said at least one transport protocol; and, − a transmission, by the management device and to the device requesting access to a service or the intermediate device, of identification data of said at least one transport protocol selected to access said service. [33] In particular modes of implementation, the flow management policy comprises at least one data packet scheduling mechanism to be applied by the first electronic device to said communication. [34] In this case, the use of the network slices and the application of the management policy comprises a use of at least one of the selected network slices and said at least one data packet scheduling mechanism to access said service. [35] In particular modes of implementation, the first device is a device requesting access to a service or an intermediate device to which the device is connected requesting access to a service, the second electronic device is a service management device, and the method further comprises: − a transmission, by the service access request device or the intermediate device and to the management device, of data relating to a plurality of data packet scheduling mechanisms applicable by said service access request device or said intermediate device; − a selection, by the management device and from among the plurality of data packet scheduling mechanisms, of at least one data packet scheduling mechanism suitable for providing said service, the selected flow management policy including said at least one data packet scheduling mechanism; and − a transmission, by the management device and to the service access request device or the intermediate device, of identification data of said at least one data packet scheduling mechanism selected for accessing said service. [36] In particular embodiments, the flow management policy comprises a constraint on a direction of at least one flow of the communication through at least one of the selected network slices. [37] In particular embodiments, the flow management policy comprises a constraint on the use of a single slice or a plurality of network slices connected to each other (for example multi-domain slices or “stitched slices” mentioned below). [38] In particular embodiments, the data representative of the network slices supported by said at least one network and accessible by said first electronic device includes at least one type of network slice and/or at least one network slice identifier. [39] In particular embodiments, the data representative of the network slices of the plurality accessible by said first electronic device further includes at least one data item from among: a network identifier, a flow identifier, an address identifier, a maximum number of flows per slice, data representative of a constraint on a flow direction. [40] In particular embodiments, the method further comprises a selection, by the second device, of at least one network slice accessible by said second device, and adapted to the provision of the service (S), and/or at least one communication flow management policy to be applied by said second device. [41] According to a second aspect, the invention relates to a computer program comprising instructions for implementing the control method mentioned above, when said program is executed by a processor. [42] According to a third aspect, the invention relates to a computer-readable recording medium on which the computer program according to the second aspect is recorded. [43] According to a fourth aspect, the invention relates to a method for configuring a communication during which data relating to a service are exchanged between a first electronic device and a second electronic device via at least one telecommunications network supporting a plurality of network slices, the method comprising the following steps implemented by the first electronic device: − a reception of data representative of at least one network slice accessible by the first and second electronic devices and compatible with a provision of the service, from the second electronic device, said data being furthermore representative of a policy for managing the flow of the communication via said at least one network slice; and, − an application of said at least one network slice and said flow management policy to the communication. [44] As mentioned previously, the service can then be accessed in an adapted manner, that is to say by considering the requirements in terms of quality of service required for the provision of this service, but also by considering the constraints specific to the device(s) wishing to access this service. [45] In particular embodiments, the first device is an intermediate device to which a service access request device is connected, and the configuration method further comprises, at the request of the service access request device, a step of transmission, by the intermediate device and to said service access request device, of the data representing the network slices and of said flow management policy. [46] In particular embodiments, the configuration method further comprises the following steps implemented by the intermediate device: − a reception of at least one traffic classification rule aimed at distributing data of said communication across at least one of the selected slots; and, − an application of said at least one rule, so as to associate at least one flow of said communication with at least one of said slots. [47] This feature advantageously makes it possible to associate flows, sub-sessions, etc. with slots. [48] According to a fifth aspect, the invention relates to a computer program comprising instructions for implementing the configuration method mentioned above, when said program is executed by a processor. [49] According to a sixth aspect, the invention relates to a computer-readable recording medium on which the computer program according to the fifth aspect is recorded. [50] According to a seventh aspect, the invention relates to an electronic device, called a second electronic device, configured to implement the method for controlling a communication according to the first aspect. [51] According to an eighth aspect, the invention relates to an electronic device, called the first electronic device, configured to implement the method for configuring a communication according to the fourth aspect. [52] In particular embodiments, this first device corresponds to an intermediate device to which a device for requesting access to a service is connected. [53] According to a ninth aspect, the invention relates to a communication system comprising a first electronic device according to the eighth aspect, and a second electronic device according to the seventh aspect. [54] Brief description of the drawings [55] Other characteristics and advantages of the present invention will emerge from the description given below, with reference to the appended figures which illustrate an exemplary embodiment thereof without any limiting character. In the figures: [56] [Fig.1A] Figure 1A is a first example of a communication system in which a general method for accessing a service is implemented; [57] [Fig.1B] Figure 1B is a second example of a communication system in which a general method of accessing a service is implemented; [58] [Fig. 1C] Figure 1C is a third example of a communication system in which a general method for accessing a service is implemented; [59] [Fig. 1D] Figure 1D is a fourth example of a communication system in which a general method for accessing a service is implemented; [60] [Fig. 2] Figure 2 is a detailed view of a 5G mobile network supporting network slices; [61] [Fig. 3A] Figure 3A represents modules embedded in a second electronic device, according to an exemplary implementation of the invention; [62] [Fig. 3B] Figure 3B represents an example of hardware architecture of a second electronic device; [63] [Fig. 4A] Figure 4A represents modules embedded in a first electronic device, according to an exemplary implementation of the invention; [64] [Fig.4B] Figure 4B represents an example of hardware architecture of a first electronic device; [65] [Fig.5A] Figure 5A illustrates, in the form of a flowchart, the main steps of a general method of accessing a service, according to a first example of implementation of the invention; [66] [Fig.5B] Figure 5B is a detailed view of the step of applying the network slices and the selected flow management policy of Figure 5A, according to an example of implementation of the invention; [67] [Fig.6] Figure 6 illustrates, in the form of a flowchart, the main steps of a general method of accessing a service, according to a second example of implementation of the invention; [68] [Fig.7] Figure 7 illustrates, in the form of a flowchart, the main steps of a method for controlling an intermediate device involved in a communication during which data relating to a service are exchanged, according to an exemplary implementation of the invention; [69] [Fig.8] Figure 8 is an example of the format of a PCP (Port Control Protocol) option for transmitting parameters relating to the network slices accessible by the device requesting access to a service; and, [70] [Fig.9] Figure 9 is an example of the format of a PCP option for transmitting traffic classification rules.[71] Description of the Embodiments [72] The terms "first(s)", "second(s)", etc. are used in this document by arbitrary convention to identify and distinguish different elements (such as messages, devices, etc.) considered in the embodiments described below, and do not imply any particular sequencing, except when explicitly indicated. [73] Figures 1A to 1D illustrate different configurations of a communication system comprising at least a first device and a second device according to the invention, and in which a general method for accessing a service is implemented. This method for accessing a service is based on a configuration method and a control method according to the invention implemented respectively by the first and by the second device, as explained in more detail later. [74] Figure 1A is a first example of a communication system in which a general method for accessing a service is implemented. [75] This system comprises a device (20) for requesting access to a service (S) connected to a telecommunications network (10-1). The device (20) for requesting access to a service (S) supports the IP communication protocol. This device can be a user terminal – taking for example the form of a laptop, a personal assistant, a connected object, or a mobile telephone of the "smartphone" type – a router, a home gateway, or even a TV decoder, etc. [76] The system further comprises a device (30) for managing the service (S) taking for example the form of a terminal or a remote server, and also connected to the telecommunications network (10-1). As illustrated in Figure 1A, this device (30) for managing the service (S) is configured to provide a service S. This service can be defined as a computer program directly used to carry out a task, or a set of elementary tasks in the same domain. This is for example a service for providing multimedia content (such as video on demand), a service for accessing a social network or a payment service. [77] According to another embodiment, the service ^^^^ is not deployed on the device (30) for managing the service, but on a third device separate from the devices for requesting access to a service and for managing the service (S). In this case, the service is for example a "service function" or one of the service functions ("Service Function" in English) of a Service Function Chain, as illustrated in Figure 2. [78] In the case where the service (S) is provided by this third device, in a particular embodiment, the management device (30) acts as a relay between the device (20) requesting access to the service, and the third device which provides the service (S). The management device (30) can also act as a security device which selectively blocks or authorizes data packets to access the third device. [79] According to another embodiment, the service (S) is deployed on the device (20) requesting access to a service. [80] In the present embodiment, and for the purpose of simplifying the description, it is considered that the communication system comprises a single device (20) requesting access to a service, as well as a single management device (30) offering a single service (^^^^), these two devices being connected through a network. It should be noted, however, that no assumption is made as to the number of service access request devices (20), the number of management devices (30), the number of services (^^^^), or the number of networks considered. The following developments can in fact be generalized without difficulty by the person skilled in the art to the case where more than one service access request device (20), more than one management device (30), more than one service (^^^^) and more than one network are considered. [81] As illustrated in FIG. 1A, the service access request and management devices (20, 30) are both connected to a telecommunications network 10-1. The telecommunications network 10-1 comprises in this example several subnetworks (or "segments" or "domains"): a radio access network (RAN), a core network (CN), and a transit network (TN) connected to the radio access network (RAN) and to the core network (CN). The radio (RAN), transit (TN) and core (CN) networks make up, in the embodiment described here, the telecommunications network 10-1 to which the device (20) for requesting access to a service is connected, and are capable of communicating with each other. For the remainder of the description, it is considered in a non-limiting manner that this telecommunications network 10-1 is a 5G type mobile network. [82] The radio access network (RAN) supports one or more RAN_SL network slices, the transit network (TN) one or more TN_SL slices, and the core network (CN) one or more TN_CN slices.[83] Generally, it is important to note that no assumptions are made regarding the nature of the slices deployed in a network, their number, and the paths between instances or sub-instances of slices. The functions used by these slices are described in more detail with reference to Figure 2. [84] The radio access network (RAN) is, for example, a V-RAN. A virtual radio access network (V-RAN) is a radio access network (RAN) whose network functions are deployed as virtualized instances located at different locations in the network, for example, according to a telecom operator's deployment strategy. This approach offers the advantage of limiting the use of expensive equipment and facilitates the creation of network slices that coexist simultaneously on the same hardware. [85] It should however be specified that the invention remains applicable to other types of telecommunications network 10-1, such as for example a 4G mobile network, a B5G network (acronym for "Beyond 5G"), a 6G network, a WLAN network (such as a Wi-Fi network), an IP/MPLS network, etc. [86] Figure 1B is a second example of a communication system in which a general method of accessing a service is implemented. [87] This system comprises a device (20) for requesting access to a service (S) as well as a device (30) for managing the service (S). Unlike the system of Figure 1A, the devices (20, 30) for requesting access to a service and for managing the service (S) are connected to each other through a plurality of telecommunications networks, 10-1, 10-2. [88] The first telecommunications network 10-1 corresponds for example to that previously described with reference to Figure 1A, and the second telecommunications network 10-2 is a wireless local area network ("Wireless Local Area Network", WLAN, according to English terminology) which also supports a plurality of slices. [89] The devices (20, 30) for requesting access to a service and for managing a service (S) are therefore capable of activating and exploiting several logical network interfaces linked to one or more physical network interfaces. Such devices are generally called "multi-interfaces" ("Multi-InterFace", MIF, according to English terminology).[90] Several IP addresses can thus be assigned to a MIF device so that it can connect simultaneously or not to several telecommunications networks (for example, accessible via a Wi-Fi interface, an optical interface or a 5G interface of the device). These IP addresses can: − belong to the same address family or to distinct address families (e.g., IPv4, IPv6 or both); − have different lifetimes. Thus, an IPv6 address is, for example, only used by the device (20) requesting access to a service for the duration of a communication, whereas an IPv4 address can be permanently assigned to the interface connecting the device (20) requesting access to a service to a telecommunications network, for example, an Ethernet interface; − have different scopes. Thus, a first private IPv4 address is for example only used in a domestic environment because it is not routable on the Internet, a second address is of the unique IPv6 type with local scope ("Unique Local Address"), and a third address is of the IPv6 type with global scope ("Global Unicast Address"); and − be assigned to the same logical network interface or to different logical network interfaces. [91] It is also important to note that the "multi-interface" aspect of an electronic device is volatile, because the capacity to use several interfaces depends on the conditions of connection to the network(s), the location of the electronic device, or other factors. The "multi-interface" electronic device can in particular exploit the plurality of interfaces at its disposal when establishing a simple communication (i.e., a communication established along a single path with a given correspondent), or even after establishing a simple communication. It should also be noted that a "multi-interface" electronic device does not know a priori whether it is possible to use several distinct paths to establish communication with a given correspondent. [92] The devices (20, 30) for requesting access to a service and for managing a service (S) being "multi-interface", they benefit from "hybrid" access since different network access technologies can be used, for example to enable it to aggregate bandwidth or improve the availability of access to this/these network(s). [93] It should be recalled in this regard that, in the field of networks, the notion of "aggregation" refers to the grouping of several paths associated with as many logical network interfaces. of a MIF device, as if it were a single path associated with a single network interface. The flows of the same communication can then transit through this plurality of paths. Path aggregation is, for example, carried out with the aim of increasing throughput beyond the limits of a single path, but also in order to apply the same operating procedures to all the paths thus aggregated (the notion of "fate sharing" in English). [94] Path aggregation also makes it possible to ensure that other network interfaces take over if one of the paths becomes unavailable, for example in the event of a cable break or a radio link failure, by virtue of a resilience principle which makes it possible to improve the availability of access to the network. Path aggregation can apply to all or part of the traffic carried along these paths, including IP traffic. [95] Path aggregation can also be used to distribute traffic across multiple paths. In this case, the distribution of traffic between the paths being aggregated depends on various parameters. Traffic distribution depends, for example, on the type of traffic, such as TCP (Transmission Control Protocol) or UDP (User Datagram Protocol) traffic, or on a set of traffic engineering, quality of service and/or security policies implemented by the operator(s) in charge of the telecommunications network(s) supporting these aggregated paths. [96] Thus, various aggregation modes can be envisaged, including the following three modes: − the backup mode, which consists of using secondary paths in the event of unavailability of the primary paths, in order to improve the availability of the network and, de facto, of the services accessible through the network, the robustness and reliability of the IP communications established on the different paths; − the associative mode, which consists of using the resources associated with all or part of the available paths, the IP flows associated with the same service (or application) being able to be distributed between several paths. The choice of exploiting all the paths, or only some of them, can for example be conditioned by the nature of the traffic or the availability or reliability characteristics associated with each path, which can vary greatly from one path to another; and − the so-called "comfort" mode, which is similar to the associative mode, except that the traffic characteristic of a given service is not distributed among several paths, but sent on a single path. [97] These different modes are not mutually exclusive. Nor are they specific to a particular type of traffic. Thus, one or other of these modes can be implemented independently of the nature of the traffic that is routed along the aggregated paths. [98] The device (20) for requesting access to a service (S) can also be configured to refrain from exploiting a path aggregation mechanism deployed in certain telecommunications networks. Indeed, to avoid over-using a first network such as the mobile network 10-1, the device (20) for requesting access to a service (S) is for example configured to only pass voice communications via a second network, such as the local wireless network WLAN (10-2), at certain times of the day. According to another example, the device (20) for requesting access to a service (S) is configured not to activate aggregation under certain operating conditions, for example in the event of overloading of the network concentrators, such as OLT ("Optical Line Termination") equipment in a fiber access network based on a PON ("Passive Optical Network" or "passive optical network") architecture. [99] Figure 1C is a third example of a communication system in which a general method for accessing a service is implemented. [100] The communication system comprises a device (20) for requesting access to a service (S) and connected to an intermediate device (50). This intermediate device (50) of the MIF type, in the example envisaged here, is connected to a device (30) for managing a service through a plurality of networks, such as the networks 10-1 and 10-2 described with reference to Figure 1B. [101] The communication system of Figure 1C is therefore distinguished from that of Figure 1B by the fact that the device (20) for requesting access to a service (S) is not directly connected to the telecommunications networks 10-1 and 10-2, but that it is indirectly connected to these networks through said intermediate device (50). Thus, the device (20) for requesting access to a service (S) does not require activating a plurality of network interfaces for multi-path communication to be established. [102] For the purposes of the invention, an "intermediate device" is equipment located in the network and acting on behalf of one or more other devices. This "intermediate device" corresponds, for example, to a user terminal – such as a computer portable device, a personal assistant, a connected object, or a mobile phone such as a "smartphone" – or to equipment installed in a customer's environment (individual, business) and which is connected to the infrastructure of an operator/service provider (referred to as "Customer Premises Equipment", CPE, according to English terminology), such as a router or a home gateway. [103] The deployment of one or more intermediary devices in the network allows the device(s) connected to this (their) intermediary device(s) to benefit from optimized use of available network resources. This deployment of intermediary devices also makes it possible to establish communications over multiple paths in a reduced time, without prejudging the capabilities of the recipient(s) with whom an electronic device wishes to communicate. [104] Figure 1D is a fourth example of a communication system in which a general method of accessing a service is implemented. Figure 1D differs from Figure 1C in that the device (20) for requesting access to a service is a "multi-interface" device both connected to the intermediate device (50), but also connected to the device (30) for managing the service (S) through a telecommunications network 10-3 supporting several network slices. [105] Thus, in this fourth example, the device (20) for requesting access to a service, the management device (30) and the intermediate device (50) are all three multi-interface devices. [106] Of course, these examples are given for illustrative purposes only and other configurations can be envisaged. [107] Figure 2 is a detailed view of a 5G mobile network supporting network slices, such as the network 10-1 of Figures 1A-1D. [108] As mentioned previously, to meet various constraints, for example in terms of quality of service, the 3GPP consortium has specified in particular how a 5G telecommunications network can support "network slices". In particular, the 3GPP consortium has defined the notion of "network slice instance". Each instance is broken down into sub-instances ("Sub-Network Instance" according to Anglo-Saxon terminology). Thus, a network slice instance is for example composed of a sub-instance ^^^^^^^^^^^^^_^^^^^^^^^^^^RAN access network and a sub-instance ^^^^^^^^_^^^^^^^^^^^^of CN core network. From In this way, a service provider can rely on slices (in particular sub-instances of slices) set up in different networks (RAN, CN) to provide a service whose traffic will be routed in a network slice instance composed of sub-instances of slices deployed in the different networks mentioned above. [109] More generally, when network slices (e.g. network slice instances) rely on other network slices (e.g. sub-instances of network slices), for example, in order to offer value-added services, this is sometimes referred to as "multi-domain slices" (or "stitched slices" or "hierarchical slices" in English). Attachment Circuits between adjacent slices are managed, for example, using mechanisms such as those described in the document "YANG Data Models for 'Attachment Circuits'-as-a-Service (ACaaS)", draft-boro-opsawg- teas-attachment-circuit-07, M. Boucadair, Ed. & Al., published on July 10, 2023 by the IETF (acronym for "Internet Engineering Task Force"). [110] Each of the subnetworks (e.g., RAN, CN) supports network slices whose engineering and operation are specific to that subnetwork. Thus, a slice (^^^^^^^^^_{^^^^^^^^^^^^=1..3}) deployed on a core network (CN) uses traffic processing and operating functions characteristic of a 5G mobile core network. In other words, each subnetwork (or "domain") uses technologies deployed in this subnetwork for the realization of the network slices that compose it. The realization of a network slice (e.g. a network slice instance) that extends over several subnetworks (or domains) is not conditioned by the availability or activation of the same technologies used for the realization of the sub-instances of slices specific to each subnetwork. For example, a first subnetwork may handle communications established according to the IPsec (Internet Protocol Security) protocol suite, a second subnetwork may use Layer 3 VPN (L3VPN) combined with Traffic Engineering (TE) mechanisms, and a third subnetwork may use IPv6-based Segment Routing (SRv6) resources to route traffic in the slices deployed in this third subnetwork. [111] Figure 2 illustrates an example of a communications network comprising a RAN access network supporting three sub-instances of network slices ^^^^^^^^^^^^^_{^^^^^^^^^^^^=1..3}and a CN core network also supporting three network slice sub-instances ^^^^^^^^_{^^^^^^^^^^^^=1..3}. [112] In the present embodiment illustrated by Figure 2, and for the purpose of simplifying the description, it is considered that the telecommunications network comprises only an access network (RAN) and a core network (CN), but the following developments can be generalized without difficulty by those skilled in the art to the case where the telecommunications network also comprises one or more transit networks (TN). Thus, the mechanisms described in the document "A Realization of IETF Network Slices for 5G Networks Using Current IP/MPLS Technologies", draft-ietf-teas-5g-ns-ip-mpls-00, Krzysztof Grzegorz Szarkowicz & Al., published by the IETF on June 27, 2023 can, for example, be implemented to deploy network slices in this transit network (TN). [113] Furthermore, it is also important to recall that no assumptions are made about the nature of slices (e.g., slice instances and slice sub-instances) deployed in a network, their number, and the links between slice sub-instances (e.g., between RAN and TN, or between TN and CN). [114] As illustrated in Figure 2, the sub-instance ^^^^^^^^^^^^^_{^^^^^^^^^^^^=1}of the RAN access network, and the sub-instances ^^^^^^^^_{^^^^^^^^^^^^=1}and ^^^^^^^^_{^^^^^^^^^^^^=2}of the core network (CN) belong to the same instance ^^^^^^^^_{^^^^^^^^^^^^^^^^}network slice to which a user terminal 20-1 is connected. This instance ^^^^^^^^_{^^^^^^^^^^^^^^^^}network slice is for example dedicated to mobile virtual network operators ("MVNOs" in English terminology) which do not have a frequency spectrum concession or their own radio network infrastructure, and which, to offer mobile communications services to their customers, rely on the infrastructures of one or more mobile network operators. [115] The communications network further comprises an instance ^^^^^^^^^_{^^^^^^^^^^^^^^^^}network slice to which a user terminal 20-2 is connected. This instance ^^^^^^^^_{^^^^^^^^^^^^^^^^}network slice is for example dedicated to high bandwidth services for wireless connectivity (eMBB). This instance ^^^^^^^^^_{^^^^^^^^^^^^^^^^}includes a sub-instance ^^^^^^^^^^^^_{^^^^^^^^^^^^=2}of the RAN access network, as well as the sub-instance instance ^^^^^^^^_{^^^^^^^^^^^^=2}previously mentioned. In other words, the sub-instance ^^^^^^^^_{^^^^^^^^^^^^=2}is shared between the network slice instance ^^^^^^^^_{^^^^^^^^^^^^^^^^}and the network slice instance ^^^^^^^^_{^^^^^^^^^^^^^^^^}. [116] Finally, the telecommunications network includes an instance ^^^^^^^^_^^^^^^^^^^^^of network slice to which a 20-3 sensor is connected. This instance ^^^^^^^^_^^^^^^^^^^^^network slice is for example dedicated to objects and terminals equipped with sensors and configured to transmit and receive data. This instance ^^^^^^^^_^^^^^^^^^^^^includes a sub-instance ^^^^^^^^^^^^_{^^^^^^^^^^^^=3}of the RAN access network, as well as a sub-instance instance ^^^^^^^^_{^^^^^^^^^^^^=3}of the CN core network. [117] A network slice may involve one or more "Service Functions" (according to the terminology used in the document "Service Function Chaining (SFC) Architecture", RFC7665, published in October 2015 by the IETF) also called Network Functions (according to the terminology used by the 3GPP consortium). A sub-instance of a network slice of an access network (RAN) involves for example: a DU function (Distributed Unit) configured to manage the sub-layers of the data link layer, namely the MAC sub-layer (acronym for "Media Access Control") and the RLC sub-layer (acronym for "Radio Link Control"); and a CU (Centralized Unit) configured to manage the PDCP (Packet Data Convergence Protocol), SDAP (Service Data Adaptation Protocol) and RRC (Radio Resource Control) sub-layers. A network slice sub-instance of a core network (CN) involves a UPF (User Plane Function), as defined for example by the 3GPP TS 23.501 specification "System architecture for the 5G System (5GS)", version 18.2.2, published on July 7, 2023. This UPF acts as a kind of gateway between the radio access network (RAN) and a data network, such as the Internet or a local/private network. It is also important to note that the same service function can be provided by one or more service instances. [118] Furthermore, service chains (SFC, according to English terminology) can be set up to facilitate the routing of traffic of different types within a slice. As illustrated in Figure 2, each network slice sub-instance ^^^^^^^^_^^^^^^^^1and ^^^^^^^^_^^^^^^^^2includes an SFC service string. The network slice sub-instance ^^^^^^^^_^^^^^^^^1includes a string of ^^^^ virtual network functions ("Virtual Network Function",^^^^^^^^^^^^^_^^^^=1..^^^^, according to Anglo-Saxon terminology), and the network slice sub-instance ^^^^^^^^_^^^^^^^^2includes a chain composed in particular of ^^^^ virtual network functions ^^^^^^^^^^^^^_^^^ ^′^_=1..^^^^. In the following, no assumption is made regarding the structuring of service chains of service S or the network slices requested. [119] Figure 3A represents modules embedded in a second electronic device, according to an exemplary implementation of the invention.[120] This second electronic device corresponds for example to the device (30) for managing a service, to the device (20) for requesting access to a service or to the intermediate device (50) and comprises in particular a MOD_OBT module, a MOD_SEL module and a MOD_TX module whose functions are described below with reference to Figure 3B. [121] Figure 3B represents an example of hardware architecture of a second electronic device. [122] As illustrated by Figure 3B, the second electronic device has the hardware architecture of a computer. Thus, the second electronic device comprises in particular a processor 1, a random access memory 2, a read-only memory 3 and a non-volatile memory 4. It further comprises a communication module 5. [123] The read-only memory 3 of the second electronic device constitutes a recording medium as proposed, readable by the processor 1 and on which is recorded a computer program PROG in accordance with the invention, comprising instructions for executing steps of the method for controlling a communication as proposed below. The program PROG_M defines one or more functional modules of the second electronic device, which rely on or control the hardware elements 1 to 5 cited above, and which comprise in particular: − a module MOD_OBT for obtaining data representative of network slices supported by a network and accessible by a first electronic device wishing to access a service S; − a MOD_SEL module for selecting network slices accessible by the first and second electronic devices and compatible with the provision of the service S, and a policy for managing the communication flows via the selected network slices; − a MOD_TX module for transmitting, to the first electronic device, data representing the network slices and said selected flow management policy so that they are applied, by the first electronic device, to this communication. [124] Furthermore, the second electronic device may also comprise other modules, in particular for implementing particular modes of the communication control method, as described in more detail later.[125] Figure 4A represents modules embedded in a first electronic device, according to an exemplary implementation of the invention. [126] This first electronic device corresponds for example to the device (20) for requesting access to a service, or to the intermediate device (50) connected to the requesting device (20), and notably comprises a MOD_RX module and a MOD_APP module whose functions are described below with reference to Figure 4B. [127] Figure 4B represents an example of hardware architecture of a first electronic device. [128] As illustrated by Figure 4B, the first electronic device has the hardware architecture of a computer. Thus, the first electronic device comprises in particular a processor 1, a random access memory 2, a read-only memory 3 and a non-volatile memory 4. It further comprises a communication module 5. [129] The read-only memory 3 of the first electronic device constitutes a recording medium as proposed, readable by the processor 1 and on which is recorded a computer program PROG_S in accordance with the invention, comprising instructions for executing steps of the method for configuring a communication as proposed below. The program PROG_S defines one or more functional modules of the first electronic device, which rely on or control the hardware elements 1 to 5 cited above, and which comprise in particular: − a MOD_RX module for receiving, from the second device, data representing network slices accessible by the first and second electronic devices and compatible with a provision of the service (S), said data being furthermore representative of a policy for managing the flow of the communication via said network slices; and, − a MOD_APP module for applying said network slices and said flow management policy to the communication. [130] Furthermore, the first electronic device may also comprise other modules, in particular for implementing particular modes of a method for configuring a communication, as described in more detail later. [131] Figure 5A illustrates, in the form of a flowchart, the main steps of a general method for accessing a service, according to a first example of implementation of the invention. This The method comprises a method for controlling a communication including steps S200, S210 to S290 and implemented by a device (30) for managing the service (S) (which is thus a second device within the meaning of the invention in this first example of implementation), as well as a method for configuring a communication including steps S10, S100, S110 to S160 and implemented by a device (20) for requesting access to the service (S) (which is thus a first device within the meaning of the invention in this first example of implementation). [132] The general method for accessing a service comprises a first initialization step S10 during which the device (20) for requesting access to a service obtains a list of slice(s) which it can access to send or receive traffic (i.e. it is authorized to use the resources of the listed slice(s). [133] According to a particular implementation, this list is communicated (e.g. transmitted) by the network slice provider(s) ("Slice Service Provider", SSP, according to the English terminology) to which the device (20) requesting access to a service is connected, and received by this device (20) requesting access to a service. This step is for example in accordance with section 4.9.2 "Network Slice as a Service" of the specification TS 28.801, "Telecommunication management; Study on management and orchestration of network slicing for next generation network", version 15.1.0, published on January 4, 2018 by the 3GPP consortium. [134] Alternatively, it is a service of the access request device (20) which implements steps S10, S100 to S160 of this method – the device (20) for requesting access to a service then corresponding for example to a hardware resource of a telecommunications network –, and the list of slices that said device is likely to use to send or receive traffic is obtained at the end of a configuration of said service, which involves configuring all of the slices that the first device is likely to use to send or receive traffic. Such a configuration is for example integrated into the client application used to access the service. [135] For each network slice, its type is obtained by the device (20) for requesting access to a service. It is also important to note that several types of slices can be associated with the same slice. In this case, for a given slice, several types are obtained by the device (20) for requesting access to a service. This feature is particularly advantageous when a single slice (or slice instance) is designed to aggregate several other sub-slices (or slice sub-instances). The type of a network slice corresponds, for example, to one of the slice types defined by the 3GPP consortium (e.g., eMBB, IoT, URRLLC, or V2X), or to other types previously defined by the network slice provider.[136] Alternatively, rather than obtaining a particular type of network slice, network slice identifiers (Slice Identifiers, SIDs) or appropriate markers (tags) are obtained by the service access request device (20). [137] According to a particular implementation, the service access request device (20) also obtains all or part of the following data: − a network identifier (NID). This identifier can be used to determine whether the two devices 20 and 30 are connected to the same network. In this case, this network identifier can be used to mark the packets of a sub-session. The exchange of this network identifier also makes it possible to verify the correlation between the network identifiers of the service access request and management devices (20, 30); − a maximum number of sub-sessions per given slice (MAX_SubFlow_Slice). This parameter can be provided as a system parameter or be a parameter configured by default in an application or a service. This parameter can also be configured by a user (for example, an administrator of a service instance). [138] As illustrated by FIG. 5A, the general method for accessing a service further comprises a transmission step S100 during which a message MSG1 is transmitted by the device (20) requesting access to a service to the device (30) for managing the service. [139] This first message MSG1 includes, in the implementation example envisaged here, a SLICE_CAPABLE_1 data item representative of a capability of the device (20) requesting access to a service to use at least one network slice selected from a plurality of network slices of a telecommunications network supporting network slices, and to apply a communication flow management policy selected by the device (30) for managing the service. [140] According to a particular implementation, this MSG1 message corresponds to a request to establish communication. A transport protocol including TCP and its MPTCP option are for example considered, and this MSG1 message corresponds to a TCP SYN message. Still considering the MPTCP option, this MSG1 message corresponds for example to a request to initialize an additional TCP sub-session. [141] According to a particular implementation, this SLICE_CAPABLE_1 data corresponds to a value of a field (or "attribute") (e.g. a field or attribute called here SLICE_CAPABLE) of the MSG1 message, this field then being dedicated to representing a capacity of an electronic device to use at least one network slice selected from a plurality of network slices of a telecommunications network, and to apply a policy for managing the flow of the communication selected by another device. [142] According to a particular implementation, this SLICE_CAPABLE_1 data further comprises an indication that the device (20) requesting access to a service is capable of exchanging data within the framework of a communication established on multiple paths within this telecommunications network supporting network slices. Thus, if the value of the SLICE_CAPABLE field of the MSG1 message is for example equal to "1", this means that the device having sent this frame is capable of using at least one network slice selected from a plurality of network slices of a telecommunications network, of applying a communication flow management policy selected by another device, and of exchanging data within the framework of a communication established on multiple paths within this network. [143] This MSG1 message is received by the service management device (30) during a step S200. During a step S210, the management device (30) extracts data from the message received in step S200. The general method for accessing the service further comprises a step S220 during which it is determined whether or not the management device (30) is capable of selecting at least one network slice from a plurality of network slices of the telecommunications network, as a function of the constraints or requirements of the service (S) but also as a function of the capabilities of the service access request device (20), and of selecting an appropriate flow management policy. [144] According to a particular implementation, this step S220 also aims to determine whether or not the management device (30) is capable of using a communication established on multiple paths within this telecommunications network supporting network slices. [145] If the management device (30) is not capable of doing so (choice "N"), it implements step S230. According to a first example of implementation of step S230, the MSG1 message received in step S200 is ignored and the communication establishment procedure is terminated. According to a second implementation example, the SLICE_CAPABLE_1 data is ignored by the service management device (30). In this case, if the transport protocol used is the TCP protocol which uses the MPTCP option, a second message is sent by the management device (30) to the service access request device (20), which corresponds for example to the SYN/ACK message as defined by the RFC 9293 standard.[146] If, on the other hand, the service management device (30) is capable of selecting at least one network slice from a plurality of network slices of a telecommunications network based on the requirements of the service (S) but also on constraints of the service access request device (20), and of selecting a flow management policy (choice "Y"), it then implements a step S240. During this step S240, a second message, MSG2, is transmitted by the management device (30) to the service access request device (20), which includes a SLICE_CAPABLE_2 data item representative of a capability of the management device (30) to select at least one compatible network slice for accessing the service (S), as well as a communication flow management policy. [147] According to a particular implementation, this MSG2 message corresponds to an acknowledgment ACK of the communication establishment request. Alternatively, if the transport protocol used is the TCP protocol which uses the MPTCP option and the MSG1 message relates to the initialization of a TCP sub-session, this MSG2 message corresponds to an acknowledgment of receipt of the request to initialize an additional TCP sub-session. [148] According to a particular implementation, this SLICE_CAPABLE_2 data corresponds to a value of a field (called for example SLICE_CAPABLE) of the MSG2 message, this field then being dedicated to representing a capacity of an electronic device to select at least one compatible network slice to access the service (S), as well as a policy for managing the communication flows. [149] According to a particular implementation, this SLICE_CAPABLE_2 data further comprises an indication according to which the device (30) for managing a service is capable of using a communication established on multiple paths within this telecommunications network supporting network slices. Thus, if the value of the SLICE_CAPABLE field of the MSG2 message is for example equal to "1", this means that the device having sent this message is capable of selecting at least one compatible network slice as well as a flow management policy, and of using a communication established on multiple paths within this network. [150] The second MSG2 message is received by the device (20) requesting access to a service during a step S110. The general method for accessing a service further comprises a step S120 during which the data are extracted from the received MSG2 message. More precisely, the device (20) requesting access to a service checks for the presence of the SLICE_CAPABLE_2 data item. Indeed, the absence of this data item in a response to a communication establishment request (MSG1) which contains the data item SLICE_CAPABLE_1 means that the management device (30) does not support the method according to the invention. [151] If the second message MSG2 comprises the data item SLICE_CAPABLE_2, step S130 is then implemented. During this step S130, a third message MSG3 is sent by the service access request device (20) to the service management device (30), which includes a SLICE_SET data item representative of network slices supported by said at least one network and accessible by the service access request device (20). This SLICE_SET data item includes at least one type of network slice and/or at least one network slice identifier obtained during step S10. [152] According to a particular implementation, this SLICE_SET data item further includes at least one data item from among the following data: − a network identifier obtained in step S10; − a maximum number of sub-sessions per given slice ("MAX_SubFlow_Slice") for example obtained in step S10; − one or more address identifiers ("Address Identifier", Address ID). This identifier is used to associate the slices reachable via the same address. This parameter is for example generated by the device (20) requesting access to a service according to a mechanism similar to that of the MPTCP ADD_ADDR option. − an indication of support for asymmetric sub-sessions. This indication corresponds for example to a specific field taking one of the following values: IN, OUT or BOTH. This parameter explicitly indicates the capacity to associate the outgoing (OUT) or incoming (IN) traffic of the same sub-session with distinct network slices. The value BOTH is used to indicate that the same slice must be used for the incoming and outgoing traffic of the same sub-session. However, the sub-sessions of the same communication can be associated with distinct slices. [153] According to a particular implementation, the third message MSG3 further comprises data, OTHER_TSV, relating to the transport protocol(s) applicable, by the device (20) requesting access to a service, to the communication between the device (20) requesting access to a service and the device (30) for managing the service (S). These transport protocols make it possible, for example, to establish communication on multiple paths. For this, the message comprises, for example, a dedicated field whose “protocol#i” values correspond to transport protocol identifiers. The OTHER_TSV data can apply to an end-to-end communication, to a sub- session, or to a specific slot. In the latter case, the listed protocol(s) are only eligible for communications or sub-sessions via this specific slot. [154] According to a particular implementation, the third message further comprises SCHEDULER data relating to the traffic scheduling mechanism(s) supported by the device (20) requesting access to a service (S) and the device (30) managing the service (S). For this purpose, the message comprises, for example, a dedicated field whose sc#j values correspond to identifiers of applicable traffic scheduling mechanisms (e.g., the value "0" for Round-Robin, "1" for Lowest Round-Trip-Time First, "2" for Round-Trip-Time Threshold, and "3" for Priority-based). The SCHEDULER data may apply to an end-to-end communication, to a sub-session, or to a specific slice. In the latter case, the listed scheduling mechanism(s) are only eligible for establishing communications or sub-sessions via this specific slice. [155] The general method for accessing a service further comprises a step S250 during which the MSG3 message is received by the management device (30). This step is for example implemented by the MOD_OBT module of the service management device (30). [156] After receiving this MSG3 message, the service management device (30) extracts the data from the MSG3 message and saves it in a local cache (step S260). [157] During a step S270, the service management device (30) selects network slices accessible by the service access request device (30) and compatible with the provision of the service S, as well as a policy for managing the communication flows via the selected network slices. This step is for example implemented by the MOD_SEL module of the service management device (30). [158] The selection of a previously mentioned flow management policy comprises all or part of the following elements: − a traffic scheduling mechanism to be applied by the service access request device (20) to the communication; − a transport protocol making it possible to establish communications on multiple paths to be applied, by the service access request device (20), to the communication; − a constraint on a direction of at least one communication flow through at least one of the selected network slices;− a specific distribution of the communication flows (or where appropriate of the sub-sessions on which the communication is based) and whose traffic is routed in the selected network slice(s), and, − a constraint of using a single slice or a plurality of network slices connected to each other. [159] Of course, other elements can be envisaged in the management policy as a variant or in addition to the aforementioned elements. [160] Step S270 comprises a comparison, by the management device (30), of the extracted data with its own information and service instructions. These service instructions correspond to requirements (e.g. a given network slice type, a traffic scheduling mechanism, a specific transport protocol, a specific flow distribution, a slice usage constraint) required to be able to optimally access the service S. [161] Step S270 makes it possible to determine whether at least one network slice is both accessible by the device (20) requesting access to a service and compatible with the constraints or requirements of the service (S) and/or with those of the device on which this service is deployed. According to a particular implementation, this step includes a comparison between the type(s) of network slices of the MSG2 message, and that or those compatible with the service (S). [162] According to a particular implementation, this step S270 further comprises a selection of one or more transport protocols allowing the device (20) to send a request for access to a service and compatible with the constraints or requirements of the service (S). These transport protocols are, for example, transport protocols that allow communications to be established over multiple paths, such as the TCP protocol with the "Multipath TCP" option, the UDP protocol with a "Multipath UDP" extension, the QUIC protocol with the "Multipath QUIC" extension, and the MDCCP protocol (Multipath Datagram Congestion Control Protocol). [163] MPTCP is an option of the well-known TCP protocol itself, which therefore allows TCP communication to be established whose flows take several network paths. The MPTCP option defines the notion of sub-session ("subflow" in English terminology) to designate a TCP session based on the use of one of the available IP addresses/port numbers. Also, an MPTCP communication corresponds to an aggregate of TCP sub-sessions. The MPTCP option is specified by the standard RFC8684, "TCP Extensions for Multipath Operation with Multiple Addresses", published in March 2020 by the IETF. The extension Multipath of the UDP protocol allows UDP communications to be established over multiple paths. The Multipath extension of the QUIC protocol is described in the "Multipath Extensions for QUIC (MP-QUIC)" specification, draft-ietf-quic-multipath, version 06, published in October 2023 by the IETF. Finally, MPDCCP is an extension of the DCCP transport protocol, which is particularly suited for services with high latency requirements. This option is defined in the "DCCP Extensions for Multipath Operation with Multiple Addresses" specification, version 11, published in October 2023 by the IETF. [164] According to a particular implementation, if the MSG3 message comprises SCHEDULER data relating to the traffic scheduling mechanism(s) applicable, by the device (20) requesting access to a service, to the communication between the device (20) requesting access to a service and the device (30) for managing the service (S), step S270 also comprises the selection of at least one scheduling mechanism from among the scheduling mechanisms identified in the MSG3 message, which is also compatible with the requirements of the service (S) and/or the device on which this service is deployed. [165] According to a particular implementation, this step S270 further comprises a selection, by the management device (30), of at least one network slice accessible by this same management device (30), and adapted to the provision of the service (S) (for example here to the device (20) requesting access to said service). This network slice accessible by this management device (30) is for example identical to that selected for the device (20) requesting access to the service. [166] According to a particular implementation, this step S270 further comprises a selection, by the management device (30), of a management policy applicable, by this same management device (30), to the communication between the access request device (20) and this management device (30), and adapted to the provision of the service (S) (for example here, to the device (20) requesting access to said service). This management policy applicable by this management device (30) is for example identical to that selected for the device (20) requesting access to the service. [167] If a network slice that is both accessible by the device (20) requesting access to a service and compatible with the constraints or requirements of the service (S) is identified, step S280-1 is implemented during which the identified slice is associated with the outgoing traffic of the communication or of the sub-session. The method according to the invention further comprises a step S290-1 during which the management device (30) transmits, to the device (20) requesting access to the service, a fourth MSG4 message including a SLICE_SET_SELECT data item representative of the network slices and of said flow management policy selected during step S270. According to a particular implementation, this data is recorded in the SLICE_SET field, and optionally, in the OTHER_TSV and SCHEDULER fields of the fourth MSG4 message. This step is for example implemented by the MOD_TX module of the management device (30). [168] If, on the other hand, no network slice is both accessible by the device (20) requesting access to a service (S) and compatible with the requirements of this service (S), then the service management device (30) implements a step S280-2. During this step S280-2, the management device (30) selects an alternative transport protocol to the one previously used by the device (20) requesting access to a service. According to a particular implementation, this alternative transport protocol is a default protocol. Alternatively, this alternative transport protocol is selected from the OTHER_TSV data relating to the transport protocols included in the MSG3 message. Then, during a step S290-2, the management device (30) transmits, to the access request device (20), a fourth MSG4' message including data representative of the transport protocol selected during the step S280-2. [169] This fourth message (MSG4, MSG4') is received by the service access request device (20) during a step S140. This step is for example implemented by the MOD_RX module of the service access request device (20). [170] The method according to the invention further comprises a step S150 during which the data are extracted from the fourth message (MSG4, MSG4') received, and recorded in a local cache. [171] Finally, the device (20) for requesting access to a service implements a step S160 during which the network slices and the flow management policy selected during step S270 are applied to the communication established between the device (20) for requesting access to a service and the device (30) for managing this service (S). This step S160 is for example implemented by the module MOD_APP of the device (20) for requesting access to a service. This step S160 is described in more detail with reference to FIG. 5B. [172] According to a variant, the method according to the invention does not comprise steps S100, S200 to S240, S110 and S120. In this particular case, the first and second messages MSG1, MSG2 are therefore not exchanged between the first and second electronic devices, and the third message MSG3 then comprises the data SLICE_CAPABLE_1 representative of a capacity of the device (20) requesting access to a service to use at least one network slice selected from a plurality of network slices of a network of 5B is a detailed view of an example implementation of step S160 during which the selected network slices and flow management policy are applied to the communication between the device (20) requesting access to a service and the device (30) managing this service (S). [174] As illustrated by FIG. 5B, step S160 comprises a first step S5110 during which the device (20) requesting access to a service (S) determines whether the data extracted during step S150 includes data relating to selected network slices. If this is the case, step S5120 is implemented during which the selected network slices are associated with the communication or sub-session established between the device (20) requesting access to a service and the device (30) for managing this service (S). [175] Then, during a step S1540, the flow management policy selected by the management device (30) is obtained. More precisely, it is for example determined whether the extracted data includes a transport protocol to be used, for example by checking whether the OTHER_TSV field of the fourth message MSG4 is empty or not, and if it is not empty, by checking whether the value of said field corresponds to one of the values identifying the transport protocols transmitted through the third message MSG3. If this is the case (e.g. if the OTHER_TSV field includes the identifier "protocol#i" of at least one transport protocol that can be applied by the service access request device (20), the access request device (20) uses the transport protocol identified by "protocol#i" for sending data packets via the selected slot in the context of the communication between this service access request device (20) and the device (30) for managing said service. [176] In a relatively similar manner, it is for example determined whether the extracted data includes a specific traffic scheduling mechanism to be applied, by checking whether the SCHEDULER field of the fourth MSG4 message is empty or not, and if it is not empty, by checking whether the value of said field corresponds to one of the values identifying the traffic scheduling mechanisms transmitted through the third MSG3 message. If this is the case (e.g. if the SCHEDULER field includes the identifier sc#j of at least one traffic scheduling mechanism that can be applied by the service access request device (20), the service access request device (20) uses the mechanism traffic scheduling identified by sc#j for sending data packets via the selected slice as part of the communication established between this device (20) requesting access to a service and the device (30) for managing said service [177] Finally, during a step S5140, the device (20) requesting access to a service associates the outgoing traffic of the communication (or sub-session) with the slice selected by the management device (30). The marking of the traffic is that associated with the slice thus selected. Separate slices per traffic direction can also be used. [178] Returning to step S5110, if the extracted data does not include data relating to the selected network slices, then it is determined, during a step S5150, whether the extracted data includes an alternative transport protocol to that previously used by the requesting device (20). [179] If this is the case (choice "Y"), steps S5160 and S5170 are implemented. During step S5160, the service access request device (20) detects the closure of the communication established between the service access request device (20) and the service management device (30). [180] According to a first example, the closure of the communication established between the service access request device (20) and the service management device (30) is triggered immediately. [181] According to a second example, the communication established between the service access request device (20) and the service management device (30) is maintained and is therefore not immediately closed, and step S5160 comprises the detection of an event relating to the closure of the current communication. The wait for the detection of such an event is for example triggered after the reception of the fourth message MSG4, and this, for a predetermined period of time (e.g. 24 hours). Finally, step S5170 is implemented during which a new communication is established using the transport protocol “protocol#i”. [182] Returning to step S5150, if the extracted data does not include an alternative transport protocol to that previously used by the device (20) requesting access to a service (choice “N”), then the current communication is closed (step S5180). [183] Figure 6 illustrates, in the form of a flowchart, the main steps of a general method for accessing a service, according to a second exemplary implementation of the invention. The Figure 6 illustrates a variant in which the selection of compatible slots and the flow management policy is implemented by the service access request device (20) rather than by the service management device (30). [184] The general method for accessing a service comprises a first initialization step (S10) during which the service access request device (20) obtains a list of slots to which it can access to send or receive traffic. This step is for example implemented by the MOD_OBT module of the service access request device (20). [185] As illustrated by Figure 6, the general method for accessing a service further comprises a transmission step S6100 during which a message MSG1 is transmitted by the service access request device (20) to the service management device (30). This message includes, in the implementation example considered here, a SLICE_CAPABLE_3 data item representative of a capability of the device (20) requesting access to a service to select at least one compatible network slice to access the service (S), as well as a policy for managing the communication flows. [186] According to a particular implementation, this MSG1 message corresponds to a request to establish communication. A transport protocol such as TCP and its MPTCP option are for example considered, and this MSG1 message corresponds to a TCP SYN message. Still considering the MPTCP option, this MSG1 message corresponds for example to a request to initialize an additional TCP sub-session. [187] According to a particular implementation, this SLICE_CAPABLE_3 data corresponds to a value of a field (or "attribute") (e.g. a field or attribute called here SLICE_CAPABLE) of the MSG1 message, this field then being dedicated to the representation of a capacity of an electronic device to select at least one compatible network slice to access a service, as well as a policy for managing the communication flows. [188] According to a particular implementation, this SLICE_CAPABLE_3 data further comprises an indication according to which the device (20) requesting access to a service is capable of exchanging data within the framework of a communication established on multiple paths within this telecommunications network supporting network slices. Thus, if the value of the SLICE_CAPABLE field of the MSG1 message is for example equal to "1", this means that the device having sent the MSG1 message is capable of selecting at least one network slice from a plurality of network slices deployed within a telecommunications network, as well as a communication flow management policy, and to exchange data in the context of a communication established on multiple paths within this network. [189] This MSG1 message is received by the service management device (30) during a step S6200. During a step S6210, the service management device (30) extracts data from the message received in step S6200. The general method for accessing the service further comprises a step S6220 during which it is determined whether or not the management device (30) is capable of using a network slice selected by the service access request device (20) from among a plurality of network slices of the telecommunications network, and of applying a flow management policy also selected by the requesting device (20). [190] According to a particular implementation, this step S6220 also aims to determine whether or not the management device (30) is capable of using a communication established on multiple paths within this telecommunications network. [191] If the management device (30) is not capable of doing so (choice "N"), it implements step S6230. According to a first example of implementation of step S6230, the message MSG1 received in step S6200 is ignored and the procedure for establishing the communication is terminated. According to a second example of implementation, the data SLICE_CAPABLE_3 is ignored by the device (30) for managing a service. [192] If the service management device (30) is, on the other hand, capable of using a network slice selected by the service access request device (20) from among a plurality of network slices of the telecommunications network, and of applying a flow management policy also selected by the service access request device (20), it implements a step S6240. [193] During this step S240, a second MSG2 message is transmitted by the management device (30) to the service access request device (20), which includes a SLICE_CAPABLE_4 data item representative of a capacity of the management device (30) to use at least one compatible network slice as well as to apply a certain communication flow management policy. [194] According to a particular implementation, this SLICE_CAPABLE_4 data corresponds to a value of a field (called for example SLICE_CAPABLE) of the MSG2 message, this field then being dedicated to representing a capacity of an electronic device to use at least one compatible network slice as well as to apply a policy for managing the communication flows selected by another electronic device.[195] According to a particular implementation, this SLICE_CAPABLE_4 data item further comprises an indication that the service management device (30) is capable of using a communication established on multiple paths within this telecommunications network supporting network slices. Thus, if the value of the SLICE_CAPABLE field of the MSG2 message is for example equal to "1", this means that the device having sent this message is capable of using at least one network slice and of applying a policy for managing the communication flows selected by another electronic device, and of using a communication established on multiple paths within this network. [196] This second message further comprises SLICE_SET data item representing network slices supported by the communication network, and accessible by the service management device (30). According to a particular implementation, this second MSG2 message further comprises OTHER_TSV data relating to the transport protocol(s) usable for accessing the service (S), and/or SCHEDULER data relating to the traffic scheduling mechanism(s) applicable for accessing the service (S). [197] This OTHER_TSV and SCHEDULER data corresponds for example to that previously described with reference to FIG. 5A. [198] The second MSG2 message is received by the device (20) for requesting access to a service during a step S6110. The general method for accessing a service further comprises a step S6120 during which the data is extracted from the received MSG2 message. More precisely, the device (20) for requesting access to a service checks for the presence of the SLICE_CAPABLE_4 data. Indeed, the absence of this data in a response to a communication establishment request (MSG1) which contains the data SLICE_CAPABLE_3 means that the device (30) for managing a service does not support the procedure according to the invention. [199] If the second message MSG2 comprises the data SLICE_CAPABLE_4, step S6125 is then implemented. During this step, the device (20) requesting access to a service selects network slices which it can access and which are also compatible with the provision of the service, as well as a policy for managing the communication flows via the selected network slices. This step is similar to step S270 described with reference to Figure 5A, and is for example implemented by the module MOD_SEL of the device (20) requesting access to a service. [200] The method further comprises a step S6130 during which a third message MSG3 is transmitted by the device (20) for requesting access to a service to destination of the service management device (30). This step is for example implemented by the MOD_TX module of the service access request device (20). This third MSG3 message comprises a piece of data, SLICE_SET_SELECT, representing the network slices and said flow management policy selected during step S6125. According to a particular implementation, this data is recorded in the SLICE_SET field, and optionally, in the OTHER_TSV and SCHEDULER fields of the third MSG3 message. [201] The method for accessing a service further comprises a step S6250 during which the MSG3 message is received by the service management device (30). [202] After receiving this MSG3 message, the management device (30) extracts the data from the MSG3 message and saves it in a local cache during a step S6260. A step S6280 is then implemented during which the identified slice is associated with the outgoing traffic of the communication (or of the sub-session) between the device (20) requesting access to a service and the device (30) for managing this service (S). The method according to the invention further comprises a step S6290 during which the management device (30) transmits, to the device (20) requesting access to a service, a fourth MSG4 message including an ACK. [203] This fourth MSG4 message is received by the device (20) requesting access to a service during a step S6140. The method according to the invention further comprises a step S6150 during which the device (20) requesting access to a service extracts the data from the fourth message received. [204] Finally, the device (20) for requesting access to a service implements a step S6160 similar to step S160 of Figure 5A. [205] Figure 7 illustrates, in the form of a flowchart, the main steps of a method for controlling an intermediate device involved in a communication during which data relating to a service are exchanged, according to an exemplary implementation of the invention. [206] This method is implemented in the case where the first device corresponds to the intermediate device (50), and this, after step S150 during which the data of the fourth message are received, and recorded in a local cache by the intermediate device (50).[207] The method for controlling an intermediate device then comprises, in the example envisaged here, a first step S7100, implemented by the device (20) requesting access to a service, during which a request REQ aims to obtain data (e.g. SLICE_SET_SELECT) representative of the selected network slices and flow management policy. [208] This request is received by the intermediate device (50) during a step S7500. The control method further comprises a step S7510, implemented by the intermediate device (50), of transmitting to the device (20) requesting access to the service, the data SLICE_SET_SELECT representative of the selected network slices and flow management policy. The message including this SLICE_SET_SELECT data is for example in accordance with the format described with reference to Figure 8. This data is received by the device (20) requesting access to a service during a step S7110. [209] Then, during a step S7120, the device (20) requesting access to a service transmits, to the intermediate device (50), one or more traffic classification rules R aimed at distributing data of said communication across at least one of the selected slices. A classification rule can be developed from several criteria such as the destination address of the traffic, the [source address; destination address] pair, a protocol identifier, port numbers, or any combination of these different criteria. A traffic selector is defined and is responsible for associating the traffic with one or other of these rules, depending on the content of the headers of the data packets, for example. [210] The message including these R rules is for example compliant with the format described with reference to Figure 9. These R rules are received by the intermediate device (50) during a step S7520. [211] Finally, step S160 of applying the selected network slices and flow management policy is implemented, by applying, during a step S7530, the received R rules. [212] Figure 8 is an example of the format of a PCP option for exchanging, between the device (20) requesting access to a service and the intermediate device (50), parameters relating to the selected network slices and flow management policy, in a particular example of implementation. This format is for example compliant with section 7.3 ("Options") of the "Port Control Protocol (PCP)" specification, RC6887, published in April 2013 by the IETF.[213] As illustrated in Figure 8, the "Option" field includes: − an "Option Code" field coded on 8 bits, the most significant bit of which indicates whether this option is mandatory or optional; − a "Reserved" field coded on 8 bits, usually set to "0" in transmission and ignored in reception; − an "Option Length" field coded on 16 bits, which indicates the length of the data relating to said option; − a "SLICE SET Count" field coded on 16 bits, which indicates the number of SLICE_SET objects contained in this option; − a "Slice SET Length" field coded on 16 bits, which indicates the size of a SLICE_SET object; − a "Slice Type" field coded on 16 bits, which indicates the type of slice selected by the second electronic device; − an 8-bit "SID Count" field that indicates the number of Slice Identifiers (SIDs) included in a SLICE_SET object. − an 8-bit "NID Count" field that indicates the number of Network IDentifiers (NIDs) included in a SLICE_SET object. [214] According to a particular implementation, when the "SID Count" or "NID Count" fields have a value of "0", this means that no SID or NID is present in the message. [215] Figure 9 is an example of the format of a PCP option for transmitting traffic classification rules. As illustrated in Figure 9, the "Option" field includes in particular: − a 16-bit "SLICE Binding Count" field that includes a number of traffic classification rules; − for each rule, a "Binding Rule Length" field coded on 16 bits and delimiting the descriptive information of the rule. − for each rule, a "Slice Type" field; − for each rule, a "Slice Count" field. The presence of SID being optional in a rule, if the "Slice Count" field takes the value "0", this means that no SID is present in the message. − for each rule, a "Traffic Selector" field, for example, structured in accordance with the "Dissemination of Flow Specification Rules" specification, RFC8955, published by the IETF in December 2020, or in accordance with the "Dissemination of Flow Specification Rules for IPv6" specification, RFC8956, also published by the IETF in December 2020. [216] Of course, protocols other than TCP can be considered to exchange parameters relating to the network slices and the flow management policy selected between the device (20) requesting access to a service and the intermediate device (50), such as the UPnP protocol (acronym for "Universal Plug and Play"), the IGD protocol (acronym for "Internet Gateway Device"), the HTTPS protocol (acronym for "Hyper Text Transfer Protocol Secure"), the CoAP protocol (acronym for "Constrained Application Protocol") or the NETCONF protocol.

Claims

Claims [Claim 1] Method for controlling a communication during which data relating to a service (S) are exchanged between a first electronic device and a second electronic device via at least one telecommunications network supporting a plurality of network slices, the method comprising the following steps implemented by the second electronic device: - obtaining (S250, S10) data (SLICE_SET) representative of network slices supported by said at least one network and accessible by the first electronic device; - selecting (S270, S5100) network slices accessible by the first and second electronic devices and compatible with a provision of the service, and a policy for managing the flow of the communication via the selected network slices; − a transmission (S290, S5110), to the first electronic device (20), of data (SLICE_SET_SELECT) representative of the network slices and of said flow management policy selected for application, by the first electronic device, to this communication. [Claim 2] Control method according to claim 1, in which the flow management policy comprises at least one transport protocol supported by the first electronic device and making it possible to establish the communication on multiple paths. [Claim 3] Control method according to claim 1, in which the flow management policy comprises at least one data packet scheduling mechanism to be applied by the first electronic device to said communication. [Claim 4] Control method according to one of claims 1 to 3, in which the flow management policy comprises a constraint on a direction of at least one flow of the communication through at least one of the selected network slices. [Claim 5] Control method according to one of claims 1 to 4, in which the data (SLICE_SET) representative of the network slices supported by said at least one network and accessible by said first electronic device includes at least one type of network slice and/or at least one network slice identifier. [Claim 6] Control method according to one of claims 1 to 5, in which the data (SLICE_SET) representative of the network slices of the plurality accessible by said first electronic device further includes at least one data item from among: a network identifier, a flow identifier, an address identifier, a maximum number of flows per slice, a data item representative of a constraint on a flow direction. [Claim 7] Control method according to one of claims 1 to 6, further comprising a selection, by the second device, of at least one network slice accessible by said second device, and adapted to the provision of the service (S), and/or of at least one communication flow management policy to be applied by said second device. [Claim 8] Method for configuring a communication during which data relating to a service (S) are exchanged between a first electronic device and a second electronic device via at least one telecommunications network supporting a plurality of network slices, the method comprising the following steps implemented by the first electronic device: − a reception (S140, S6250), from the second electronic device, of a data item (SLICE_SET_SELECT) representative of at least one network slice accessible by the first and second electronic devices and compatible with a provision of the service (S), said data item (SLICE_SET_SELECT) being furthermore representative of a policy for managing the flow of the communication via said at least one network slice; and, − an application (S160, S6280) of said at least one network slice and of said flow management policy to the communication. [Claim 9] Configuration method according to claim 8, in which the first device is an intermediate device (50) to which a device (20) for requesting access to the service (S) is connected, and the method comprises, upon request from the device (20) for requesting access to the service, a step of transmission, by the intermediate device (50) and to said device (20) for requesting access to the service, of the data (SLICE_SET) representative of the network slices and of said flow management policy. [Claim 10] Configuration method according to claim 9 further comprising the following steps, implemented by the intermediate device (50): − a reception (S7520) of at least one traffic classification rule aimed at distributing data of said communication across at least one of the selected slices; and, − an application (S7530) of said at least one rule, so as to associate at least one flow of said communication with at least one of said slices. [Claim 11] Electronic device, called second electronic device, configured to implement the method for controlling a communication according to any one of claims 1 to 7. [Claim 12] Electronic device, called first electronic device, configured to implement the method for configuring a communication according to one of claims 8 to 10. [Claim 13] Electronic device according to claim 12, said device corresponding to an intermediate device (50) to which a device (20) for requesting access to a service (S) is connected. [Claim 14] Communication system comprising a first electronic device according to claim 12 or 13, and a second electronic device according to claim 11.