A method for controlling communication during which data relating to a service are exchanged, and associated electronic devices.

Abstract

Method for controlling a communication during which data relating to a service are exchanged, and associated electronic devices. 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 process comprises the following steps implemented by the second electronic device: obtaining representative data of network slices supported by the network and accessible by the first electronic device; selecting network slices accessible by both the first and second electronic devices and compatible with the provision of the service and a communication flow management policy; and transmitting, to the first electronic device, representative data of the selected network slices and flow management policy for application by the first electronic device to this communication. Figure 1A illustrates this in the abstract.

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

[0001] 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

[0002] In order to adapt to the continuous and ever-increasing growth of data traffic emitted by telecommunications systems, different technologies are currently being implemented and are still being improved with a view to optimal exploitation in the years to come.

[0003] The architecture of mobile telecommunications networks currently deployed or in the process of being deployed is defined in particular by the standardization consortium known as 3GPP (Third Generation Partnership Project). This is the case in particular for so-called second generation ("2G or GSM"), third generation ("3G"), fourth generation ("4G") and fifth generation ("5G") mobile networks.

[0004] Up to the fourth generation, the mobile network architectures defined by the 3GPP consortium are most often based on specific equipment, dedicated to precise functions, whether at the level of the access network or the core network, in particular with regard to the transmission of packets from or to a mobile terminal.

[0005] The lack of flexibility and scalability inherent in this type of architecture has led the 3GPP consortium to consider adopting 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 diverse constraints, a 5G mobile network architecture may be based in particular on the concept of SBA ("Service-Based Architecture"), on the virtualization of network functions and on a division of the 5G telecommunications network into logical sub-networks ("network slicing" in English terminology). This slicing technique of a network is notably described in the technical specification 3GPP TS 23.501 v 18.3.0, published in September 2023. It allows the operator of a network to create tailor-made logical subnetworks, generally dedicated to the routing of traffic sent and received by mobile terminals, and based on the same physical network infrastructure.

[0006] These logical subnetworks called "network slices" allow a client to access a service by relying both on 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.

[0007] A priori, 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" according to English terminology).

[0008] 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 field of the Internet of Things (loT), the field of ultra-reliable low latency communications ("UltRa-Reliable Low Latency Communications (URLLC)) and that of connected vehicles (Vehicle-to-Everything, V2X).

[0009] The choice to design and deploy one or more particular types of slices is notably conditioned 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.

[0010] 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 routed correctly within one or more network slices, said traffic must be subject to of an authorization. Such an authorization is typically based on traffic classification rules. These rules are applied at the input of a network / subnetwork that supports the slice(s) concerned, 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 creating and properly operating a network supporting network slices. Statement of the invention

[0011] The present invention aims to remedy all or part of the drawbacks of the prior art, in particular those set out above, by proposing a solution which allows devices to agree on the network slices which they can use to establish communication.

[0012] 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; • a selection of network slices accessible by the first and second electronic devices and compatible with provision of the service, and a policy for managing communication flows via the selected network slices; • a transmission, to the first electronic device, of data representative of the network slices and of said flow management policy selected for application, by the first electronic device, to this communication.

[0013] This method of controlling a communication offers the advantage of allowing one of the devices involved in a communication in order to access a service, to control the network slice(s) 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 which are consistent with each other.

[0014] By "communication" is meant 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 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 can result in the establishment of one or more sessions. Generally, a session is defined as an association generally 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 certain contexts such as MPTCP (acronym for Multi-Path TCP), these sessions are called "subsessions" (also called "subflows").

[0015] No assumption is made as to which device (first or second device) originates the communication allowing access to the service.

[0016] Thus, in particular modes of implementation, the first device is the device at the origin of the communication to access the service, hereinafter referred to as “device requesting access to the service” (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 “service management device”, configured to control the communication during which data relating to this service are exchanged.

[0017] Alternatively, in other particular modes of implementation, 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 “device requesting access to the service”, (resp. to an intermediate device to which such a device is connected), and it is this device at the origin of the communication (resp. to this intermediate device) which is then configured to control the communication during which data relating to this service are exchanged.

[0018] By "communication control" is meant the application, to one or more of the flows of this communication, of particular 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 which this first electronic device wishes to access.

[0019] 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”).

[0020] 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).

[0021] Generally, it is considered that the steps of a method should not be interpreted as being linked to a particular chronology.

[0022] 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.

[0023] 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.

[0024] 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.

[0025] 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 to access the service and a policy for managing communication flows.

[0026] These exchanges between the first and second electronic devices allow them to ensure that they comply with the invention, and more precisely 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 depending on the service that the first device wishes to access, but also depending on the capabilities of the first electronic device.

[0027] 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.

[0028] 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.

[0029] 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 is based on this at least one transport protocol making it possible to establish communication on multiple paths to access said service.

[0030] Thus, access to said service is implemented by exploiting the transport protocol selected for a communication using the selected network slice(s), between the first device and the second device.

[0031] In particular embodiments, 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.

[0032] 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: • 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 allowing communication to be established 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.

[0033] 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.

[0034] 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.

[0035] 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: • 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 device requesting access to a service or the intermediate device, of identification data of said at least one data packet scheduling mechanism selected to access said service.

[0036] 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.

[0037] In particular modes of implementation, the flow management policy includes a constraint of using a single slice or a plurality of network slices connected to each other (for example multi-domain slices or “stitched slices” mentioned below).

[0038] In particular modes of implementation, 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.

[0039] In particular modes of implementation, 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.

[0040] In particular modes of implementation, 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 of at least one communication flow management policy to be applied by said second device.

[0041] 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.

[0042] 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.

[0043] 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, coming from the second electronic device, said data being furthermore representative of a policy for managing the flow of communication via said at least one network slice; and, • an application of said at least one network slice and said flow management policy to communication.

[0044] As mentioned previously, the service can then be accessed in an appropriate manner, i.e. by considering the requirements in terms of quality of service required for the provision of this service, but also considering the constraints specific to the device(s) wishing to access this service.

[0045] In particular modes of implementation, the first device is an intermediate device to which a service access request device is connected, and the configuration method further comprises, upon request from 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.

[0046] 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 slices; 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 slices.

[0047] This feature advantageously makes it possible to associate flows, sub-sessions, etc. with slices.

[0048] 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.

[0049] 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.

[0050] 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.

[0051] According to an eighth aspect, the invention relates to an electronic device, called first electronic device, configured to implement the method of configuring a communication according to the fourth aspect.

[0052] In particular modes of implementation, this first device corresponds to an intermediate device to which a device for requesting access to a service is connected.

[0053] 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. Brief description of the drawings

[0054] Other features and advantages of the present invention will become apparent from the following: description made below, with reference to the attached figures which illustrate an example of embodiment without any limiting character. In the figures:

[0055] [Fig. 1 A] [Fig. 1 A] is a first example of a communication system in which a general method of accessing a service is implemented;

[0056] [Fig.lB] [Fig.lB] is a second example of a communication system in which a general method of accessing a service is implemented;

[0057] [Fig.lC] [Fig.lC] is a third example of a communication system in which a general method of accessing a service is implemented;

[0058] [Fig.lD] [Fig.lD] is a fourth example of a communication system in which a general method of accessing a service is implemented;

[0059] [Fig.2] [Fig.2] is a detailed view of a 5G mobile network supporting network slices;

[0060] [Fig.3A] [Fig.3A] represents modules embedded in a second electronic device, according to an exemplary implementation of the invention;

[0061] [Fig.3B] [Fig.3B] represents an example of hardware architecture of a second electronic device;

[0062] [Fig.4A] [Fig.4A] represents modules embedded in a first electronic device, according to an exemplary implementation of the invention;

[0063] [Fig.4B] [Fig.4B] represents an example of hardware architecture of a first electronic device;

[0064] [Fig.5A] [Fig.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;

[0065] [Fig.5B] [Fig.5B] is a detailed view of the step of applying the network slices and the selected flow management policy of [Fig.5A], according to an exemplary implementation of the invention;

[0066] [Fig.6] [Fig.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;

[0067] [Fig.7] [Fig.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 example of implementation of the invention;

[0068] [Fig.8] [Fig.8] is an example of a 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,

[0069] [Fig.9] [Fig.9] is an example of the format of a PCP option for transmitting traffic classification rules. Description of the embodiments

[0070] The terms "first(s)", "second(s)", etc. are used in this document by arbitrary convention to allow different elements (such as messages, devices, etc.) considered in the embodiments described below to be identified and distinguished, and do not imply any particular sequencing, except when explicitly indicated.

[0071] 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.

[0072] [Fig. 1 A] is a first example of a communication system in which a general method of accessing a service is implemented.

[0073] 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.

[0074] 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 by [Fig.lA], 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. It 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.

[0075] According to another embodiment, the service 5 is not deployed on the service management device (30), but on a third device separate from the service access request and service management devices (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 ("Service Function Chain" in English), as illustrated by [Fig.2].

[0076] In the case where the service (S) is provided by this third device, in a particular mode of implementation, 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) may also act as a security device that selectively blocks or allows data packets to access the third device.

[0077] According to another embodiment, the service (S) is deployed on the device (20) requesting access to a service.

[0078] In the present embodiment, and for the purpose of simplifying the description, it is considered that the communication system comprises a single device (20) for requesting access to a service, as well as a single management device (30) offering a single service (5), these two devices being connected through a network. It should however be noted that no assumption is made as to the number of devices (20) for requesting access to a service, the number of management devices (30), the number of services (S), 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 device (20) for requesting access to a service, more than one management device (30), more than one service (5) and more than one network are considered.

[0079] As illustrated by [Fig.lA], 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 service access request device (20) 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.

[0080] 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.

[0081] Generally, it is important to note that no assumptions are made about 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 [Fig.2].

[0082] The radio access network (RAN) is for example a virtual network V-RAN ("Virtual-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 deployment strategy of the telecommunications operator. This approach offers the advantage of limiting the use of expensive equipment, and facilitates the creation of network slices which coexist simultaneously on the same hardware equipment.

[0083] 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.

[0084] [Fig.lB] is a second example of a communication system in which a general method of accessing a service is implemented.

[0085] 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 [Fig.lA], 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.

[0086] The first telecommunications network 10-1 corresponds for example to that previously described with reference to [Fig.1A], and the second telecommunications network 10-2 is a wireless local area network (WLAN) which also supports a plurality of slices.

[0087] The devices (20, 30) for requesting access to a service and for managing a service (S) are therefore capable of activating and operating several logical network interfaces linked to one or more physical network interfaces. Such devices are generally called "multi-interface" ("Multi-InterFace", MIF, according to Anglo-Saxon terminology).

[0088] 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 for connecting the device (20) requesting access to a service to a telecommunications network, for example an Ethernet type interface; • have different scopes. For example, a first private IPv4 address is only used in a domestic environment because it is not routable on the Internet, a second address is a unique IPv6 address with a local scope ("Unique Local Address"), and a third address is a global IPv6 address ("Global Unicast Address"); And • be assigned to the same logical network interface or to different logical network interfaces.

[0089] It is also important to note that the "multi-interface" aspect of an electronic device is volatile, because the ability 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 available to it 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 will also be noted that a "multi-interface" electronic device does not know a priori whether it is possible for it to use several distinct paths to establish a communication with a given correspondent.

[0090] The devices (20, 30) for requesting access to a service and for managing a service (S) being "multi-interfaces", 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).

[0091] It is 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. The aggregation of paths is for example carried out with the aim of increasing the flow rate beyond the limits of a single path, but also in order to apply the same operating procedures to all the paths thus aggregated (notion of "fate sharing" in English).

[0092] Path aggregation also allows other network interfaces to take over if one of the paths becomes unavailable, for example in the event of a cable break or radio link failure, under a resilience principle that improves the availability of network access. Path aggregation may apply to all or part of the traffic carried along these paths, including IP traffic.

[0093] 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. The distribution of traffic depends, for example, on the type of traffic, such as TCP (Transmission Control Protocol) traffic or UDP (User Datagram Protocol) traffic. "User Datagram Protocol"), or 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.

[0094] Thus, various aggregation modes can be envisaged, including the following three modes: • the fallback mode ("backup" in English) 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; • associative mode ("bonding" in English) 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 part 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 between several paths, but sent on a single path.

[0095] These different modes are not mutually exclusive. Nor are they specific to a particular type of traffic. Thus, either of these modes can be implemented regardless of the nature of the traffic that is carried along the aggregated paths.

[0096] The device (20) for requesting access to a service (S) may also be configured to refrain from exploiting a path aggregation mechanism deployed in certain telecommunications networks. Indeed, to avoid placing too much strain on 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.

[0097] [Fig.lC] is a third example of a communication system in which a general process for accessing a service is implemented.

[0098] 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 [Fig. 1B].

[0099] The communication system of [Fig.lC] is therefore distinguished from that of [Fig.lB] 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.

[0100] For the purposes of the invention, an "intermediate device" is a piece of 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 laptop, a personal assistant, a connected object, or a mobile telephone of the "smartphone" type - or to equipment installed in the environment of a customer (individual, company) and which is connected to the infrastructure of an operator / service provider (designated by "Customer Promises Equipment", CPE, according to English terminology), such as a router or a home gateway.

[0101] The deployment of one or more intermediate devices in the network allows the device(s) connected to this (these) intermediate device(s) to benefit from optimized use of the available network resources. This deployment of intermediate devices also makes it possible to establish communications on multiple paths in a reduced time, without prejudging the capabilities of the recipient(s) with which an electronic device wishes to communicate.

[0102] [Fig.lD] is a fourth example of a communication system in which a general method for accessing a service is implemented. [Fig.lD] is distinguished from [Fig.lC] by the fact that the device (20) for requesting access to a service is a "multi-interface" device connected both 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.

[0103] 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.

[0104] Of course, these examples are given for illustrative purposes only and other configurations can be envisaged.

[0105] [Fig.2] is a detailed view of a 5G mobile network supporting slices network, such as network 10-1 of Figures 1A-1D.

[0106] As mentioned above, 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 English terminology). Thus, a network slice instance is for example composed of a RANsl. sub-instance of RAN access network and a CNSL. sub-instance of CN core network. 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 previously mentioned.

[0107] More generally, when network slices (e.g. network slice instances) rely on other network slices (e.g. network slice sub-instances), for example, in order to offer value-added services, this is sometimes referred to as "multi-domain slices" (or "stitched slices" or "hierarchical slices"). Connection interfaces between adjacent slices ("Attachment Circuits" in English) are, for example, managed 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").

[0108] Each of the subnetworks (e.g. RAN, CN) supports network slices whose engineering and operation are specific to said subnetwork. Thus, a slice (CNSL) 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 can manage communications established according to the IPsec protocol suite (acronym for "Internet Protocol Security"), a second subnetwork can use network-level virtual private network engineering ("Layer 3 VPN", L3VPN, according to English terminology) combined with traffic engineering mechanisms ("Traffic Engineering", TE, according to English terminology), and a third subnetwork can use the resources . segment routing based on the IPv6 protocol ("Segment Routing IPv6", SRv6, in English terminology) to route traffic in the slices deployed in this third subnet.

[0109] Figure 2 illustrates an example of a communication network comprising a RAN access network supporting three sub-instances of RANSL network slices., and a CN core network also supporting three CNSL network slice sub-instances._i y

[0110] In the present embodiment illustrated by [Fig.2], and for the purpose of simplifying the description, it is considered that the telecommunications network only comprises 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 1TETF on June 27, 2023 can for example be implemented to deploy network slices in this transit network (TN).

[0111] Furthermore, it is also important to recall that no assumption is made as to the nature of the 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).

[0112] As illustrated in Figure 2, the sub-instance RAN^. of the RAN access network, and the sub-instances CNSLj_^ and CNSL._? of the core network (CN) belong to the same network slice SLMVNO instance to which a user terminal 20-1 is connected. This network slice SLMVNO instance is for example dedicated to mobile virtual network operators ("Mobile Virtual Network Operators", MVNO, according to the 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.

[0113] The communication network further comprises a network slice instance SLeMBB to which a user terminal 20-2 is connected. This network slice instance SLeMBB is for example dedicated to high bandwidth services for wireless connectivity (eMBB). This SLeMBB instance comprises a RAN sub-instance SL, 2 of the RAN access network, as well as the CN instance sub-instance SL._^ previously mentioned. In other words, the CNsLj-2 sub-instance is shared between the network slice instance SLMVNO and the network slice instance SLeMBB.

[0114] Finally, the telecommunications network comprises a network slice SLloT instance to which a sensor 20-3 is connected. This network slice $LIoT instance is for example dedicated to objects and terminals equipped with sensors and configured to transmit and receive data. This SLIoT instance comprises a RANSL.y sub-instance of the RAN access network, as well as a CNSL^ sub-instance of the CN core network.

[0115] A network slice may involve one or more "service functions" ("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 ("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 ("Distributed Unit") function 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") function configured to manage the PDCP (acronym for "Packet Data Convergence Protocol"), SDAP (acronym for "Service Data Adaptation Protocol") and RRC (acronym for "Radio Resource Control") sublayers.A network slice sub-instance of a core network (CN) involves a User Plane Function (UPF), 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.

[0116] Furthermore, service chains (SFCs) can be set up to facilitate the routing of traffic of different types within a slice. As illustrated in Figure 2, each CNSL and CNSL network slice sub-instance comprises an SFC service chain. The CNSL network slice sub-instance comprises a chain composed of n virtual network functions (VNFs), and the CN^ network slice sub-instance comprises a chain composed in particular of m virtual network functions VNFs. ■ In the following, no assumption is made as to the structuring of the service S into service chains or the network slices requested.

[0117] [Fig.3A] represents modules embedded in a second electronic device- electronics, according to an exemplary implementation of the invention.

[0118] 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 module M0D_0BT, a module MOD_SEL and a module M0D_TX whose functions are described below with reference to [Fig.3B].

[0119] [Fig.3B] represents an example of hardware architecture of a second electronic device.

[0120] As illustrated by [Fig.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.

[0121] 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 the execution of 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 include in particular: • a MOD_OBT module 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 service S, and a policy for managing communication flows via the selected network slices; • a module M0D_TX for transmitting, to the first electronic device, data representing the network slices and said flow management policy selected so that they are applied, by the first electronic device, to this communication.

[0122] 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.

[0123] [Fig.4A] represents modules embedded in a first electronic device, according to an exemplary implementation of the invention.

[0124] 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 request device (20), and comprises in particular a module M0D_RX and a MOD_APP module whose functions are described below with reference to [Fig.4B].

[0125] [Fig.4B] represents an example of hardware architecture of a first electronic device.

[0126] As illustrated by [Fig.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.

[0127] 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 the execution of 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 module M0D_RX 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 communication.

[0128] 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.

[0129] [Fig.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 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).

[0130] The general method for accessing a service comprises a first initialization step S10 during which the device (20) 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 slice(s) listed).

[0131] 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.

[0132] 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.

[0133] For each network slice, its type is obtained by the service access request device (20). 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 service access request device (20). This characteristic proves to be particularly advantageous when the same 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 types of slices defined by the 3GPP consortium (e.g. eMBB, loT, URRLLC or V2X), or to other types previously defined by the network slice provider.

[0134] Alternatively, rather than obtaining a particular type of network slice, network slice identifiers ("Slice Identifier", SID, according to English terminology) or suitable markers ("tags") are obtained by the device (20) requesting access to a service.

[0135] According to a particular implementation, the device (20) for requesting access to a service also obtains all or part of the following data: • a network identifier ("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 allows also to verify the correlation between the network identifiers of the devices (20, 30) requesting access to a service and management; • a maximum number of sub-sessions per given slice ("MAX_SubFlow_Slice"). This parameter can be provided as a system parameter or be a default parameter configured in an application or service. This parameter can also be configured by a user (for example, an administrator of a service instance).

[0136] 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.

[0137] This first message MSG1 includes, in the implementation example envisaged here, a SLICE_CAPABLE_1 data item 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 telecommunications network supporting network slices, and to apply a communication flow management policy selected by the service management device (30).

[0138] According to a particular implementation, this MSG1 message corresponds to a request for establishing 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 for initialization of an additional TCP sub-session.

[0139] 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 the representation of 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.

[0140] 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 in the context 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 policy of management of communication flows selected by another device, and to exchange data within the framework of a communication established on multiple paths within this network.

[0141] This message MSG1 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.

[0142] According to a particular implementation, this step S220 also aims to determine whether or not the management device (30) is capable of using communication established on multiple paths within this telecommunications network supporting network slices.

[0143] 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 message MSG1 received in step S200 is ignored and the procedure for establishing the communication is terminated. According to a second example of implementation, the data SLICE_CAPABLE_1 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.

[0144] 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 as a function of the requirements of the service (S) but also of 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 capacity 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.

[0145] 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 message MSG1 is about the initialization of a TCP sub-session, this message MSG2 corresponds to an acknowledgment of receipt of the request to initialize an additional TCP sub-session.

[0146] 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.

[0147] According to a particular implementation, this SLICE_CAPABLE_2 data further comprises an indication that 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.

[0148] The second message MSG2 is received by the service access request device (20) 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 service access request device (20) 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 SLICE_CAPABLE_1 data item means that the management device (30) does not support the method according to the invention.

[0149] If the second message MSG2 comprises the data 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 representing 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 network slice type and / or at least one network slice identifier obtained during step S10.

[0150] According to a particular implementation, this SLICE_SET data further includes at least one of 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 using a mechanism similar to that of the MPTCP ADD_ADDR option. • an indication of asymmetric subsession support. This indication corresponds, for example, to a specific field taking one of the following values: IN, OUT or BOTH. This parameter explicitly indicates the ability to associate outgoing (OUT) or incoming (IN) traffic of the same subsession with separate network slices. The BOTH value is used to indicate that the same slice should be used for incoming and outgoing traffic of the same subsession. However, subsessions of the same communication can be associated with separate slices.

[0151] 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 may apply to an end-to-end communication, to a sub-session, or to a specific slice. In the latter case, the listed protocol(s) are only eligible for communications or sub-sessions via this specific slice.

[0152] According to a particular implementation, the third message further comprises SCHEDULER data relating to the traffic scheduling mechanism(s) supported by the device (20) for requesting access to a service (S) and the device (30) for managing the service (S). For this, the message comprises for example a dedicated field whose values ​​sc#j correspond to identifiers of applicable traffic scheduling mechanisms (e.g. the value "0" for Round-Robin (or "tourniquet" in French), "1" for "Lowest Round-Trip-Time First", "2" for "Round-Trip-Time Threshold", and "3" for "Priority-based"). The SCHEDULER data can apply to an end-to-end communication, to a sub-session, or to a specific slot. In the latter case, the listed scheduling mechanism(s) are only eligible for establishing communications or sub-sessions via that specific slot.

[0153] The general method for accessing a service further comprises a step S250 during which the message MSG3 is received by the management device (30). This step is for example implemented by the module MOD_OBT of the management device (30) of the service.

[0154] After receiving this MSG3 message, the service management device (30) extracts the data from the MSG3 message and saves them in a local cache (step S260).

[0155] 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).

[0156] The selection of a flow management policy previously mentioned includes all or part of the following elements: • a traffic scheduling mechanism to be applied by the device (20) requesting access to a communication service; • a transport protocol allowing communications to be established on multiple paths to be applied, by the device (20) requesting access to a service, to the communication; • a constraint on a direction of at least one flow of communication through at least one of the selected network slices; • a specific distribution of the communication flows (or where applicable 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.

[0157] Of course, other elements can be considered in the management policy as an alternative or in addition to the aforementioned elements.

[0158] 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 distribution of flows, a slice usage constraint) required to be able to optimally access the service S.

[0159] 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 slice(s) of the MSG2 message, and that or those compatible with the service (S).

[0160] According to a particular implementation, this step S270 further comprises a selection of one or more transport protocols enabling 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 which enable communications to be established on 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 "Multipath Datagram Congestion Control Protocol" protocol.

[0161] MPTCP is an option of the well-known TCP protocol, which therefore allows the establishment of a TCP communication whose flows take several paths of the network. The MPTCP option defines the notion of sub-session ("subflow" according to the 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 1TETF. The Multipath extension of the UDP protocol allows UDP communications to be established on multiple paths. The Multipath extension of the QUIC protocol is described in the specification "Multipath Extensions for QUIC (MP-QUIC)", 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 suitable 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.

[0162] 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.

[0163] 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.

[0164] According to a particular implementation, this step S270 further comprises a selection, by the management device (30), of an applicable management policy, 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 access request device (20) to said service). This management policy applicable by this management device (30) is for example identical to that selected for the service access request device (20).

[0165] If a network slice both accessible by the service access request device (20) 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 sub-session.The method according to the invention further comprises a step S290-1 during which the management device (30) transmits, to the service access request device (20), a fourth MSG4 message including SLICE_SET_SELECT data representing the network slices and 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 M0D_TX module of the management device (30).

[0166] 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 that used until now 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.

[0167] This fourth message (MSG4, MSG4') is received by the device (20) requesting access to a service during a step S140. This step is for example implemented by the module M0D_RX of the device (20) requesting access to a service.

[0168] 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.

[0169] 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 M0D_APP of the device (20) for requesting access to a service. This step S160 is described in more detail with reference to [Fig.5B].

[0170] 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 telecommunications network, and to apply a policy for managing the communication flows selected by the device (30) for managing the service.

[0171] [Fig.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).

[0172] As illustrated by [Fig.5B], step S160 comprises a first step S5110 during which the device (20) for 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) for requesting access to a service and the device (30) for managing this service (S).

[0173] 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 (for exampleif the OTHER_TSV field includes the identifier “protocol#i” of at least one transport protocol that can be applied by the device (20) requesting access to a service), the device (20) requesting access uses the transport protocol identified by “protocol#i” for sending data packets via the selected slot as part of the communication between this device (20) requesting access to a service and the device (30) for managing said service.

[0174] In a relatively similar manner, it is for example determined whether the extracted data include 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 traffic scheduling mechanism identified by sc#j for sending data packets via the selected slot as part of the communication established between this service access request device (20) and the device (30) for managing said service

[0175] Finally, during a step S5140, the device (20) for 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.

[0176] Returning to step S5110, if the extracted data does not include data relating to the selected network slices, then it is determined, in a step S5150, whether the extracted data includes an alternative transport protocol to that hitherto used by the requesting device (20).

[0177] 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).

[0178] According to a first example, the closure of the communication established between the device (20) requesting access to a service and the device (30) managing a service is triggered immediately.

[0179] According to a second example, the communication established between the device (20) for requesting access to a service and the device (30) for managing a service 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”.

[0180] Returning to step S5150, if the extracted data does not include an alternative transport protocol to that used until now by the device (20) requesting access to a service (choice "N"), then the current communication is closed (step S5180).

[0181] [Fig. 6] illustrates, in the form of a flowchart, the main steps of a general method for accessing a service, according to a second example of implementation of the invention. [Fig. 6] illustrates a variant in which the selection of compatible slots and the flow management policy is implemented by the device (20) for requesting access to a service rather than by the device (30) for managing a service.

[0182] The general method for accessing a service comprises a first initialization step (S 10) during which the device (20) requesting access to a service obtains a list of slots which it can access to send or receive traffic. This step is for example implemented by the module M0D_0BT of the device (20) requesting access to a service.

[0183] As illustrated by [Fig.6], the general method for accessing a service further comprises a transmission step S6100 during which a message MSG1 is transmitted by the device (20) requesting access to a service to the device (30) for managing the service. This message includes, in the implementation example envisaged 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 for accessing the service (S), as well as a policy for managing the communication flows.

[0184] According to a particular implementation, this MSG1 message corresponds to a request for establishing 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 for initialization of an additional TCP sub-session.

[0185] 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.

[0186] According to a particular implementation, this SLICE_CAPABLE_3 data further comprises an indication that the device (20) requesting access to a service is capable of exchanging data in the context 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 slices network deployed within a telecommunications network, as well as a policy for managing communication flows, and exchanging data within the framework of communication established on multiple paths within this network.

[0187] This message MSG1 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 request device (20).

[0188] According to a particular implementation, this step S6220 also aims to determine whether or not the management device (30) is capable of using communication established on multiple paths within this telecommunications network.

[0189] 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.

[0190] 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.

[0191] During this step S240, a second message MSG2 is transmitted by the management device (30) and to the device (20) requesting access to a service, 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.

[0192] 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.

[0193] According to a particular implementation, this SLICE_CAPABLE_4 data further comprises an indication according to which the device (30) for managing a service is capable of using 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 communication established on multiple paths within this network.

[0194] This second message further comprises SLICE_SET data 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).

[0195] These OTHER_TSV and SCHEDULER data correspond for example to those previously described with reference to [Fig.5A].

[0196] The second message MSG2 is received by the service access request device (20) during a step S6110. The general method for accessing a service further comprises a step S6120 during which the data are extracted from the received MSG2 message. More precisely, the service access request device (20) checks for the presence of the data item SLICE_CAPABLE_4. Indeed, the absence of this data item in a response to a communication establishment request (MSG1) which contains the data item SLICE_CAPABLE_3 means that the service management device (30) does not support the procedure according to the invention.

[0197] If the second message MSG2 includes the data SLICE_CAPABLE_4, step S6125 is then implemented. During this step, the device (20) for 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 [Fig.5A], and is for example implemented by the module MOD_SEL of the device (20) for requesting access to a service.

[0198] The method further comprises a step S6130 during which a third message MSG3 is transmitted by the service access request device (20) to the service management device (30). This step is for example implemented by the module M0D_TX of the service access request device (20). This third message MSG3 comprises a piece of data, SLICE_SET_SELECT, representative of 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.

[0199] The method for accessing a service further comprises a step S6250 during which the message MSG3 is received by the device (30) for managing a service.

[0200] After receiving this MSG3 message, the management device (30) extracts the data from the MSG3 message and saves them 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 acknowledgment ACK.

[0201] This fourth message MSG4 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.

[0202] Finally, the device (20) for requesting access to a service implements a step S6160 similar to step S160 of [Fig.5A].

[0203] [Fig.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.

[0204] 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).

[0205] 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 network slices and the selected flow management policy.

[0206] 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 service access request device (20), the SLICE_SET_SELECT data representing the selected network slices and the flow management policy. The message including this SLICE_SET_SELECT data is for example in accordance with the format described with reference to the [Fig.8]. This data is received by the device (20) requesting access to a service during a step S7110.

[0207] 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 from said communication across at least one of the selected slots. A classification rule can be developed from several criteria such as the destination address of the traffic, the pair [source address; destination address], 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.

[0208] The message including these rules R is for example in accordance with the format described with reference to [Fig.9]. These rules R are received by the intermediate device (50) during a step S7520.

[0209] Finally, step S160 of applying the network slices and the selected flow management policy is implemented, by applying, during a step S7530, the received rules R.

[0210] [Fig.8] is an example of a format of a PCP option for exchanging, between the service access request device (20) 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.

[0211] As illustrated in [Fig.8], the "Option" field includes: • an “Option Code” field coded on 8 bits and whose most significant bit 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 and which indicates the number of SLICE_SET objects contained in this option; • a “Slice SET Length” field coded on 16 bits and which indicates the size of a SLICE_SET object; • a “Slice Type” field coded on 16 bits and which indicates the type of slice selected by the second electronic device; • an 8-bit “SID Count” field that indicates the number of network slice identifiers (“Slice Identifier”, SID) included in a SLICE_SET object. • an 8-bit “NID Count” field that indicates the number of network identifiers (“Network IDentifier”, NID) included in a SLICE_SET object.

[0212] According to a particular implementation, when the "SID Count" or "NID Count" fields have the value "0", this means that no SID or NID is present in the message.

[0213] [Fig.9] is an example of the format of a PCP option for transmitting traffic classification rules. As illustrated in [Fig.9], the "Option" field includes, among other things: • a “SLICE Binding Count” field coded on 16 bits and including 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 op tional 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.

[0214] Of course, other protocols than the TCP protocol can be envisaged for exchanging 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

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.;

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 allowing communication to be established on multiple paths.

3. Control method according to claim 1, wherein the flow management policy comprises at least one data packet scheduling mechanism to be applied by the first electronic device to said communication.

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.

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 network slice type and / or at least one network slice identifier.

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: a network identifier, a flow identifier, an address identifier, a maximum number of flows per slice, data item representative of a constraint on a flow direction.

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.

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 (S 140, 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 (S 160, S6280) of said at least one network slice and of said flow management policy to the communication.

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 transmitting, by the intermediate device (50) and to said device (20) requesting access to the service, the data (SLICE_SET) representing the network slices and said flow management policy.

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.

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.

12. Electronic device, called first electronic device, configured to implement the method of configuring a communication according to one of claims 8 to 10.

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.

14. A communication system comprising a first electronic device according to claim 12 or 13, and a second electronic device according to claim 11.

Images