Methods for selecting network slices suitable for a service, for managing at least one network slice and for communication, and entities configured to implement these methods

Abstract

Methods for selecting network slices suitable for a service, for managing at least one network slice and for communication, and entities configured to implement these methods. The selection method according to the invention is implemented by a proxy located on a data path relating to the service exchanged between two devices during a communication and comprises: the selection (F60) for each device of at least one network slice suitable for said service and usable by that device during said communication; if a said device is not connected to at least one said network slice selected or capable of being selected for that device, the sending (F80) to at least one network controller managing that network slice of a request to connect said device to that network slice; and the sending (F110) of a message to each device indicating said at least one network slice selected usable by that device during the communication.Figure for the abridged version: Fig. 5.

Description

Title of the invention: Methods for selecting network slices adapted to a service, for managing at least one network slice and for communication, and entities configured to implement these methods Prior art

[0001] The invention belongs to the general field of telecommunications.

[0002] It relates more particularly to a method and a system for optimizing the management of communications in an environment using the concept of network slices.

[0003] Such a concept is typically envisaged today in 5G (5th generation) mobile infrastructures as defined by several 3GPP standards. However, it can also be used in other contexts, such as in the context of a network infrastructure shared between several operators, a network architecture based on network functions virtualization (or NFV for "Network Functions Virtualization" in English), or even an SD-WAN architecture (for "Software-Defined Wide Area Network" in English), etc.

[0004] A network slice can be defined as a virtual private network (VPN) deployed on a fixed or mobile network infrastructure or both, and aimed at ensuring a specific set of performances. It can be seen as a logical network offering connectivity to its users and having its own characteristics in terms of capacity (bandwidth), quality of service (latency, throughput, one-way transit time, jitter (or inter-packet delay variation, etc.) and security (for example, preserving the confidentiality of information transmitted within a VPN through the use of encryption techniques).

[0005] Network slicing is in principle facilitated by the use of advanced software-defined network (SDN) and / or network function virtualization (NFV) techniques, not described in detail here. It can be applied at different levels of a network; for example, for a 5G network, at the radio access network level for dynamic allocation of radio resources, at the edge computing resources (MEC for Multi-access Edge Computing), or at the core network level, in particular to isolate traffic and ensure security.

[0006] Such network slicing advantageously allows various network applications or services with specific needs to coexist on the same infrastructure. shared network structure, whether physical or virtual. Each network slice is allocated a set of resources (e.g., computing resources, storage, network resources, or radio frequency spectrum) to meet the specific needs of a service or type of service with which it is associated. Network slicing is based on the definition of a set of policies (which may take the form of traffic classification rules, among other things) and mechanisms that identify the traffic flows associated with each network slice.

[0007] Thus, for example, a network slice may be optimized for latency-sensitive gaming or virtual reality applications. Another network slice may be optimized for applications requiring high bandwidth such as video streaming or cloud computing applications. As an illustration, the 3GPP TS 23.501 standard entitled “Technical Specification Group Services and System Aspects; System architecture for the 5G System (5GS); Stage 2 (Release 17)”, vl7.9.0, June 2023, in paragraph 5.15.2.2, defines several types of network slices for managing different categories of services, and associated respectively with SST values ​​(for “Service / Slice Type” in English). Thus, this 3GPP standard considers: - a type of network slice called eMBB for “enhanced Mobile BroadBand” in English (“improved mobile broadband service” in French), corresponding to a value SST=1: this type of network slice is suitable, for example, for services based on very high data rates allowing new experiences to be offered to users (e.g. High Definition (HD) video broadcasting); - a type of network slice called URLLC for “Ultra Reliable Low Latency Communications” in English (“ultra reliable and low latency communication” in French), corresponding to an SST value=2: this type of network slice is suitable for example for services with strict requirements in terms of latency and reliability of data exchanges (e.g. remote management services, industrial robots or telesurgery); - a type of network slice called mloT for “massive Internet of Things” in English (massive deployment of the Internet of Things in French), corresponding to an SST value=3: this type of network slice is suitable for example for services with high requirements in terms of deployment density (e.g. connected city, connected agriculture); - a type of network slice called V2X for “Vehicular to Everything” in English (“vehicle to everything” in French), corresponding to an SST value=4: this type of network slice is suitable for example for communication services involving vehicles (e.g. assistance service for driving, autonomous driving service or road traffic management service); and - a type of network slice called HMTC for “High performance Machine Type Communications” in English (“high performance machine type communications” in French), corresponding to an SST value=5: this type of network slice is suitable for example for services also having high requirements in terms of deployment density, low latency and high transmission rates. Each of these types is associated with a set of characteristics documented by 3GPP standards. This is only an illustrative example and other network slice types, as well as other network slice type indicators and SST values, can be considered.

[0008] Thus, the choice to design and deploy a particular type of slice is conditioned by the nature of the traffic characteristic of the applications used or the services subscribed to by the network users. 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, so that it is a natural client for a URLLC type slice.

[0009] It should be noted that current 3GPP standards allow a user equipment (or UE) of a 5G network to connect simultaneously to 8 network slices and therefore to simultaneously access as many services requiring distinct connectivity needs.

[0010] As mentioned previously, the routing of traffic associated with a UE to a particular network slice authorized for the UE relies on traffic classification rules, applied at the UE level but also at the network level. In the example of a 5G network, these traffic classification rules, also known as URSP rules (for "UE Route Selection Policy") are transmitted to the UE at the control plane level by the policy control function (or PCF for "Policy Control Function" in English) of the network or pre-configured at the UE level. The URSP rules indicate for a given type of traffic, which network slice(s) the UE can use.

[0011] Traffic classification rules can be extremely complex due to the different levels of granularity considered for the engineering and deployment of network slices (e.g., a network slice deployed to route traffic destined for the Internet network or a dedicated network slice deployed to route application traffic exchanged between two given UEs). Furthermore, the enactment and application of such traffic classification rules are likely to evolve over time, sometimes with high frequency, with the diversity of traffic and its change, the dynamicity of EU needs, the emergence of new services, the network slice selection criteria applied and / or the network slice usage patterns, etc. This also results in a difficulty in configuring such rules and a risk of errors.

[0012] There is therefore a need for a mechanism which makes it possible to optimize access to a service by a client device (UE or other such as a router, a residential gateway (or CPE for “Customer Promises Equipment” in English), a TV decoder, etc.) via one or more network slices which does not have these drawbacks. Statement of the invention

[0013] The invention responds in particular to this need by proposing a method for selecting network slices adapted to a service and intended to be used during a communication between two devices via at least one network, this method being implemented by a “proxy” located on a data path relating to the service and exchanged between the devices involved in the communication. The selection method comprises: - a selection step, based on a given selection policy, for each device, of at least one network slice adapted to the service usable by this device during communication; - if said device is not connected to at least one said network slice selected or likely to be selected for this device, a step of sending to at least one network controller of said at least one network managing said at least one network slice a request to connect the device to said at least one network slice; and - a step of sending a message to each device indicating to it said at least one network slice selected for this device usable by said device during communication.

[0014] Correlatively, the invention relates to a proxy located on a data path relating to a service and exchanged via at least one network during a communication between two devices involved in a communication, this proxy comprising: - a selection module, configured to select according to a given selection policy, for each device, at least one network slice adapted to the service usable by this device during the communication - a communication module, activated if a said device is not connected to at least one said network slice selected or likely to be selected for this device, this communication module being configured to send to at least one network controller of said at least one network managing said at least one network slice a request for connection of this device to said at least one network slice; and - a sending module, configured to send a message to each device indicating to it said at least one network slice selected for this device usable by said device during communication.

[0015] By "at least one network slice usable during the communication", we mean that the device must use at least one of the network slices indicated by the proxy during the communication, as soon as it has been informed of this selection (in other words, following receipt of the message from the proxy).

[0016] No limitation is attached to the nature of the service in the context of which data are exchanged in the context of the invention nor to the number of “terminal” devices involved in a communication. It can be any type of offer proposed by a service provider based on the orchestration of a set of resources of one or more networks (network resources, computing resources, storage resources, etc.), such as for example a voice over IP service, a telemedicine service, an HD video broadcasting service, a conference service, etc. Furthermore, no assumption is made as to the nature of each device involved in the communication. It can be a terminal, such as a smartphone, a digital tablet, a laptop, but also a router, a CPE, a TV decoder, etc. It can be single-interface or multi-interface (or MIF for "Multi-InterFace" in English), i.e. capable of simultaneously activating and operating several logical interfaces linked to one or more physical connection interfaces, such as for example a connection interface to a fixed network, a connection interface to a mobile network or a connection interface to a wireless local area network or WLAN (for "Wireless Local Area Network" in English). This MIF characteristic has many advantages for the UE, such as the possibility of aggregating the bandwidth of different networks, better availability of access to the network(s), distribution of traffic over several communication links, etc.It should be noted, however, that this MIF characteristic is volatile, because the ability of a device to use multiple interfaces (and thus aggregate multiple communication links, i.e. communicate using multiple paths) depends on various factors, such as its connection conditions to the network(s), its location, etc.

[0017] Similarly, the network slices envisaged in the context of the invention may be supported by one or more networks (these are referred to as “multi-domain” slices or “stitched slices” in English), be located at different levels (for example at the level of an access network, a collection network, the core network, a transit network or a transport network), be associated with other network slices, etc., and a The same network slice can be used to carry traffic for one or more services.

[0018] The invention thus proposes a mechanism for selecting, by a proxy, network slices making it possible to optimize, with regard to given criteria (participating in the definition of a “selection policy” within the meaning of the invention), an end-to-end service between a transmitting device and a receiving device. It should be noted that for this purpose, the selection method according to the invention can be implemented by one or more proxies located on the path of the data exchanged within the framework of the service between the transmitting device and the receiving device. In other words, the two devices envisaged in the selection method can be the transmitting device and the receiving device, or the transmitting device and a proxy associated with the receiving device, or the receiving device and a proxy associated with the transmitting device.

[0019] The proxy according to the invention has, in accordance with the invention, visibility over the network slices accessible by the "terminal" devices in the flow cut-off of which it is located and has the capacity to communicate with one or more network controllers to possibly trigger (and if necessary negotiate) the connection of these devices to other network slices if these prove to be relevant with regard to its selection policy to provide the service optimally to the devices. Such a connection can be requested by the proxy upstream of the selection of the network slices for the devices (for network slices likely to be selected by the proxy for the devices), or after having selected the network slices (it is then possible to limit oneself to requesting the connection of the network slices which have been selected and to which the devices are not already connected).The proxy is thus able to establish a correspondence between a service and the network slices enabling this service to be provided optimally, and is assisted in this regard by the network(s) supporting the network slices in question.

[0020] The proxy being in the plane of the data exchanged between the two devices, it can advantageously select different network slices for each of the devices, including network slices supported by different networks: its position in the data plane allows it to be able to carry out the interconnection between such different network slices, and accordingly mark the data packets passing through it or modify their headers so that they are appropriately directed towards the appropriate network slices.

[0021] The selection policy applied by the proxy can advantageously take into account, in addition to the quality of the service, constraints imposed by the service provider, or by the operator or operators of the network(s) on which the network slices are based, the authorization of the devices to access one or more network slices, a complexity of implementation, etc.

[0022] For example, the selection policy applies at least one of the following rules: - a first rule according to which, when the devices are connected to at least one network slice of the same type (for example associated with the same SST value in the context of a 5G network compliant with 3GPP standards) adapted to the service, said at least one network slice of the same type is selected for the devices; and / or - a second rule according to which at least one network slice selected for at least one said device is a network slice to which this device is already connected; and / or - a third rule according to which the network slices selected for the devices optimize a quality of service.

[0023] Of course, the selection policy applied by the proxy may include other rules in addition to or in replacement of all or part of the rules mentioned above.

[0024] The first rule favors the selection of network slices to which the devices are already connected and which are compatible with each other, as long as these network slices are adapted to the service. This makes it possible to accelerate the provision of the service and to limit the complexity of implementing the invention. In addition, the presence of the proxy and its involvement in establishing communications makes it possible to preserve the same level of service.

[0025] The second rule may be relevant when one of the devices does not support the procedure proposed by the invention. This procedure is called in the remainder of the application “SLALOM” in reference to the possibility it offers of “slaloming” between the network slices offered by one or more networks during communication between two devices.

[0026] The third rule advantageously makes it possible to choose the network slices which optimize the quality of the service relating to the data exchanged between the devices. For this purpose, different elements can be taken into account such as the type of service envisaged, the determining quality parameters for this service (latency, throughput, etc.), the guarantees offered by the network slices “visible” to the proxy (i.e. which can be selected by it), etc. It is noted that such a third rule can, in certain cases, be an instantiation of the first rule.

[0027] The invention therefore offers greater granularity in the choice of network slices that can be used to satisfy the needs of a service, different network slices being able to be used on different segments of the communication, and on the same communication segment, on multiple paths implemented on this segment (in other words, on different “sub-connections” or “sub-sessions”). ("subflow" in English) depending on the protocols considered). It also makes it possible to take into account the network slices or types of network slice available to the two devices involved in the communication, i.e. that they are authorized to use.

[0028] On the contrary, in the state of the art mentioned above, a UE only has knowledge of the network slices that are authorized to it by the network to select the network slice that it will use to access a service. It has no visibility on the network slices available for the remote device with which it establishes a communication to access the service. Each device (UE or remote device) has only reduced visibility on the network slices likely to satisfy the needs of a service that it is accessing, and can only use the network slices that are communicated to it by the network to which it is connected.It also has no visibility into other slices available within a network to provide the service, and even less into those accessible by the other device, so that when it chooses a network slice to access a service based on the URSP rules communicated to it, it is this same network slice that is used from end-to-end to the remote device.

[0029] Furthermore, in accordance with the invention, the proxy is involved in accessing the service: it selects for a given service the network slices to be used by the devices during communication and informs them of this selection. This results in a dynamic configuration (addition, deletion, etc.) of the traffic classification rules applied by the devices, as soon as they can be able to use new network slices to which they were not initially connected. The invention thus allows the devices to automatically and securely discover deployed network slices reserved for (or optimized for) the use of a given service.

[0030] Furthermore, since the proxy is located on the paths of data relating to the service and exchanged during communication between the devices, it is possible to envisage implementing a control at the proxy level aimed at ensuring that the devices during this communication actually access the claimed service and use the network slices that it has selected for them for this service. The invention thus makes it possible to protect against usurpation procedures implemented by malicious applications and aimed at using unauthorized privileges in the network.

[0031] In a particular embodiment, the selection method comprises a step of obtaining from at least one said device, at least one piece of information representative of at least one network slice to which this device is connected.

[0032] Such information includes, for example, at least one element among: a type of said network slice; an identifier of said network slice; - a network identifier to which said network slice is attached; - at least one Internet Protocol (IP) address identifier associated with said network slice.

[0033] In particular, it allows the proxy to apply the selection rules mentioned previously in its selection policy.

[0034] Furthermore, in a particular embodiment of the selection method, the step of sending a connection request relates to a network slice capable of being selected for said device and is implemented before the selection step.

[0035] This embodiment allows faster use of the selected slot(s) for the device from its / their selection and thus reduces the service access time.

[0036] Thus, the connection to other network slices for a device can be requested by the proxy before or after the selection of network slices suitable for a service for this device. This provides flexibility in implementing the invention.

[0037] In a particular embodiment, the selection method according to the invention further comprises a step of sending to at least one said device at least one piece of information representative of at least one network slice to which the proxy is connected.

[0038] This embodiment allows automatic discovery by the devices of proxies capable of optimizing their communications so as to include these "proxies" on the path of these communications. Other information can be acquired by the devices, such as for example at least one communication protocol implemented by the proxy.

[0039] The device can thus easily include on the path of its communication with another device a proxy connected to a network slice to which it itself is connected or which is accessible via this network slice.

[0040] The announcement of the communication protocol can further allow the device to choose a proxy implementing a protocol supporting extensions allowing communications to be established via multiple paths, a proxy that can act as a multipath concentrator, which can be advantageous when one of the devices does not know the capabilities of the other device in this regard, or a proxy that allows advanced transport functions to be used without such functions actually being supported by all the devices involved in a communication. Such a communication protocol is, for example, the TCP (Transmission Control Protocol) transport protocol and its multipath option MPTCP (for "Multipath TCP"), the QUIC transport protocol and its multipath extension MPQUIC (for "Multipath QUIC") or the DCCP transport protocol (for "Datagram Congestion Control Protocol") and its multi-path extension MPDCCP (for "Multipath DCCP"), or the conversion protocol "0-RTT Covered Protocol".

[0041] Furthermore, the various information exchanged between devices and proxies within the framework of the invention can be done via extensions of these protocols defined for this purpose.

[0042] In a particular embodiment, the selection method according to the invention comprises, following the step of sending the message to each device indicating the network slice(s) selected for it, a step of maintaining the proxy on at least one said data path relating to said service exchanged between said devices during said communication via at least one network slice selected for said devices.

[0043] In other words, the proxy remains involved in the communication between the two devices until the end of this communication. This embodiment has an advantage when all or part of the network slices selected for the two devices differ, the proxy making it possible to achieve the interconnection between different network slices used by the two devices for the same communication.

[0044] It should be noted that this embodiment does not prevent future communications relating to the same service from being established directly between the two devices (without the intervention of the proxy) via the slot(s) selected by the proxy. This makes it possible to simplify the establishment of connections between the two devices.

[0045] In another embodiment, following the step of sending said message to each device, a step of removing said proxy from at least one said data path relating to said service exchanged between said devices during said communication via the same network slice selected for said devices.

[0046] As appears from what has just been described, the invention relies on a proxy, but also on the devices exchanging data relating to a service during a communication, and on the network controller(s) capable of triggering the connection of a device to a network slice that they manage at the request of the proxy.

[0047] Thus, according to a second aspect, the invention aims at a method for managing at least one network slice by a network controller of a network, said method comprising: - a step of receiving, from at least one proxy located on a data path relating to a service and exchanged via at least said network during a communication between two devices involved in the communication, a request for connection of at least one of the devices to at least one network slice managed by said network controller; and - a step of triggering said connection.

[0048]

[0049]

[0050]

[0051]

[0052] Correlatively, the invention also relates to a network controller of a network comprising: - a reception module, capable of receiving from at least one proxy located on a data path relating to a service and exchanged via at least said network during a communication between two devices involved in the communication, a request for connection of at least one of said devices to at least one network slice managed by said controller; and - a connection trigger module, configured to trigger said connection. According to a third aspect, the invention relates to a method of communication by a first device with a proxy located on a data path relating to a service and exchanged via at least one network with a second device during a communication, said method comprising a step of receiving, from said proxy, a message indicating to the first device at least one network slice adapted to the service usable by said first device during the communication and selected by the proxy according to a given selection policy. Correlatively, the invention relates to a communication device, called the first communication device, comprising: - a reception module, configured to receive from a proxy located on a data path relating to a service and exchanged via at least one network with a second communication device during a communication involving the first and the second device, a message indicating to said communication device at least one network slice adapted to the service usable by said first device during the communication and selected by the proxy according to a given selection policy; and - a communication module, configured to use during communication at least one said network slice indicated by the proxy. The first communication device according to the invention and the network controller, as well as the communication and management methods implemented respectively by these devices, benefit from the same advantages cited previously as the proxy and the selection method according to the invention. In a particular embodiment, the communication method further comprises, prior to the reception step, a step of sending via said proxy a request to establish a connection with the second device for communication, the establishment request comprising at least one piece of information representative of at least one network slice to which the first device is connected.

[0053] In a particular embodiment, the communication method further comprises: - a step of receiving a request to establish a connection with said second device for said communication relayed by said proxy; and - a step of sending to said proxy a message comprising at least one piece of information representative of at least one network slice to which said first device is connected.

[0054] These embodiments rely on existing messages to convey various information promoting the implementation of the invention. In addition, they make it possible to involve the proxy from the phase of access to the service by the devices.

[0055] In another embodiment, the communication method comprises, prior to the sending step, a step of discovering at least one proxy connected to at least one network slice to which the first device is connected and implementing at least one communication protocol used during the communication, the proxy being selected by the first device from among said at least one proxy discovered during the discovery step.

[0056] As mentioned previously, this embodiment allows automatic discovery by the devices of the proxies available for implementing the invention.

[0057] In a particular embodiment, the selection, management and communication methods are implemented by a computer.

[0058] The invention also relates to a computer program on a recording medium, this program being capable of being implemented in a computer or more generally in a proxy in accordance with the invention and comprising instructions adapted to the implementation of a selection method as described above.

[0059] The invention also relates to a computer program on a recording medium, this program being capable of being implemented in a computer or more generally in a network controller in accordance with the invention and comprising instructions adapted to the implementation of a management method as described above.

[0060] The invention also relates to a computer program on a recording medium, this program being capable of being implemented in a computer or more generally in a communication device in accordance with the invention and comprising instructions adapted to the implementation of a communication method as described above.

[0061] Each of these programs can use any programming language, and be in the form of source code, object code, or code intermediate between source code and object code, such as in a partially compiled form, or in any other desirable form.

[0062] The invention also relates to an information medium or a recording medium readable by a computer, and comprising instructions of a computer program as mentioned above.

[0063] The information or recording medium may be any entity or device capable of storing the programs. For example, the medium may comprise a storage means, such as a ROM, for example a CD ROM or a microelectronic circuit ROM, or a magnetic recording means, for example a hard disk, or a flash memory.

[0064] On the other hand, the information or recording medium may be a transmissible medium such as an electrical or optical signal, which may be conveyed via an electrical or optical cable, by radio link, by wireless optical link or by other means.

[0065] The program according to the invention can in particular be downloaded from an Internet-type network.

[0066] Alternatively, the information or recording medium may be an integrated circuit in which a program is incorporated, the circuit being adapted to execute or to be used in the execution of the selection, management, and communication methods according to the invention.

[0067] According to a fourth aspect, the invention also relates to a system comprising: - at least two communication devices according to the invention, exchanging data relating to a service during a communication via at least one network; - at least one proxy according to the invention located on a path of all or part of said data; and - at least one network controller of said at least one network according to the invention.

[0068] The two communication devices may be the device initiating the communication and the remote device with which the communication is established. Alternatively, one of the devices may be a proxy according to the invention.

[0069] It may also be envisaged, in other embodiments, that the selection, management and communication methods, the proxy, the network controller, the communication devices and the system according to the invention have in combination all or part of the aforementioned characteristics. Brief description of the drawings

[0070] Other characteristics and advantages of the present invention will emerge from the description given below, with reference to the appended drawings which illustrate an example thereof. of embodiment without any limiting character. In the figures:

[0071] [Fig. 1] [Fig.l] represents, in its environment, a system conforming to the invention, in one embodiment;

[0072] [Fig.2] [Fig.2] represents the hardware architecture of a computer on which the various elements of the system of [Fig.l] (communication devices, network controllers and proxies in accordance with the invention) are based on, in a particular embodiment;

[0073] [Fig.3] Figures 3A and 3B represent the main steps of a com method communication according to the invention, as implemented respectively by a communication device UE1 and a communication device UE2 of the system of [Fig.l], in a particular embodiment;

[0074] [Fig.4] [Fig.4] represents the main stages of a selection process according to the invention, as implemented by a proxy of the system of [Fig.l], in a particular embodiment;

[0075] [Fig.5] [Fig.5] represents the main stages of a management process according to the invention, as implemented by a network controller of the system of [Fig.l], in a particular embodiment;

[0076] [Fig.6] Figures 6A, 6B and 6C illustrate examples of messages in TLV format (Type, Length, Value) allowing information exchanged in a particular embodiment of the invention to be conveyed;

[0077] [Fig.7] Figures 7A and 7B illustrate information exchanges between a device communication and a proxy of the system of [Fig.l], during a discovery phase, in a particular embodiment, in which the TCP protocol is used; and

[0078] [Fig.8] [Fig.8] illustrates information exchanges between communication devices nication and a proxy of the system of [Fig.l], in a particular embodiment, in which the TCP protocol is used; and

[0079] [Fig.9] [Fig.9] represents, in its environment, a system conforming to the invention, in another embodiment. Description of the invention

[0080] [Fig.l] represents, in its environment, a system 1 according to the invention, in one embodiment, in which one or more communication networks NW1, NW2,..., NWN, N designating an integer greater than or equal to 1, implement network slices for the provision of various services. Each network NWn, n=1,...,N supports a plurality of network slices SLn1, SLn2,..., SLnK(n), K(n) designating an integer greater than 1, and which may vary from one network NWn to another. The plurality of network slices SLn1,..., SLnK(n) supported by a network NWn, n=1,...,N is managed by one or more network controllers or NSC (for “Network Slice Controller » in English), according to the invention, and belonging to system 1. An NSC controller of an NWn network is typically a computing logic in charge of the engineering and deployment of network slices; it is for example an SDN controller. For the sake of simplification here, we consider a single NSCn controller for each NWn network, n=1,.. .,N, in system 1.

[0081] No limitation is attached to the nature of the communication networks NW1,..., NWN. These may include, for example, 5G mobile networks, SD-WAN networks, networks implementing SDN or NFV architecture, etc., and which use, in a manner known per se, separate control and data planes.

[0082] A single NWn network, n=l,.. .,N, can be segmented into several distinct networks (also referred to as “network segments”), which make up as many domains (not shown in [Fig.l]). For example, a 5G mobile communication NWn network as defined by the 3GPP organization can be composed of a radio access network (or RAN for “Radio Access Network” in English), a core network (or CN for “Core Network” in English) and a transport network (or TN for “Transport Network” in English) ensuring connectivity within and between the core network and the radio access network. Each of the domains supports network slices whose engineering and operation are characteristic of the domain. For example, a slice deployed on a 5G mobile core network uses traffic processing and operating functions characteristic of a 5G mobile core network.

[0083] Thus, a network slice used to provide a service via an NWn network, n=l,...,N can span multiple domains and consist of multiple “local” network slices deployed in the different domains. How to design and deploy network slices to offer services is known per se and is not described in detail here. As an illustration, the document by KG Szarkowicz entitled “A Realization of IETF Network Slices for 5G Networks Using Current IP / MPLS Technologies”, draft-ietf-teas-5g-ns-ip-mpls, published by 1TETF on June 27, 2023, describes such a way for an IP / MPLS network (example of a transport network).

[0084] Such a network slice spanning multiple domains is said to be "multi-domains" (or "stitched slice" or "hierarchical slice" in English). Connection interfaces (or "Attachment circuits" in English) are provided between the local and managed network slices using, for example, mechanisms such as those described in the document by M. Boucadair et al. entitled "YANG Data Models for 'Attachment Circuits'-as-a-Service (ACaas)", draft-boro-opsawg-teas-attachment-circuit-07, published on July 10, 2023 by 1TETF. The association between the local network slices deployed in the different domains and a multi-domain network slice is typically carried out in the control plane, at the edge of each domain.

[0085] It should be noted that the network slices local to each domain do not necessarily rely on the same technologies. For example: - a first domain can set up IPsec tunnels to route traffic in the network slices deployed in this first domain; - a second domain may use network-level virtual private network engineering (L3VPN) combined with traffic engineering (TE) mechanisms; and - a third domain can use the resources of segment routing based on the IPv6 protocol (SRv6 for "Segment Routing IPv6" in English) to route traffic in the network slices deployed in this domain.

[0086] Furthermore, each network slice (local or multi-domain) may involve one or more service functions (or "Service Functions" in English) also called network functions (or "Network Functions" in English) in the 3GPP context. Such service / network functions are for example base station functions or gNB (for "gNodeB" in English), user plane functions or UPF (for "User Plane Function" in English), traffic marking, classification and scheduling functions, etc. The same service / network function may be provided by one or more service instances (or "Service Function Instances" in English) or network function instances.Service chains or SFCs (for "Service Function Chains" in English) can be set up to facilitate the routing of traffic of different natures and presenting different profiles for the needs of the realization (i.e. design and deployment) of a network slice or within a network slice.

[0087] In the example of [Fig.l], two service providers based on network slices (or SSPs for "Service Slice Provider" in English) are considered, SSP1 and SSP2. The network slices in question (referenced by SSP1-SL1,... and SSP2-SL1,... in [Fig.l]) are deployed on one or more networks among the networks NW1,..., NWN. No assumption is made as to the nature or the number of services provided by each of them, nor the number of network slices or the networks on which these services are based, nor the configuration of the network slices (single or multi-domain).

[0088] According to the invention, the system 1 comprises at least two communication devices UE1 and UE2, according to the invention. In the embodiment, these two communication devices UE1 and UE2 are multi-interface user equipment (or UE), capable of being connected to several access networks such as for example a WLAN network and a 5G cellular mobile network. It is assumed that the communication devices UE1 and UE2 use the TCP transport protocol and its MPTCP option for managing multiple paths established where appropriate via their multiple interfaces. The communication devices UE1 and UE2 may be smartphones, personal computers, servers, etc. They can access, via the access networks to which they are connected, one or more service providers SSPs based on network slices from which they have subscribed to one or more services. In the example envisaged in [Fig.l], it is assumed in particular that the communication devices UE1 and UE2 are connected to the service provider SSP1 and have subscribed to the service S.

[0089] These hypotheses are not, however, limiting in themselves, and the invention can be applied to other communication devices, software or hardware, fixed or mobile, such as for example a residential gateway or CPE, a service instance, a proxy, etc. These communication devices can be single or multi-interface, use other transport protocols such as QUIC and where appropriate its MPQUIC extension, or DCCP and where appropriate its MPDCCP extension, etc. Those skilled in the art will have no difficulty in transposing what is described below with reference to TCP segments to other types of data packets or more generally to other messages according to the transport protocol envisaged.

[0090] In the embodiment, the system 1 also comprises at least one proxy or relay device, PI, ..., PM, M designating an integer greater than or equal to 1, in accordance with the invention. These proxies PI,...,PM are typically found in the access networks to which the communication devices UE1 and UE2 are connected or can be reached via such access networks. Alternatively, they can be hosted in public, private or hybrid cloud infrastructures, which may or may not exploit MEC (for "Multi-access Edge Computing") resources of edge networks. They integrate, in the example of [Fig.l] exploiting multiple paths, multipath concentrators and implement the "0-RTT TCP Convert Protocol" conversion protocol (also known as "MPTCP Plain Mode") described in the document RFC 8803 published by the IETF (July 2020).In the following, we refer to this protocol for simplicity as the Convert protocol.

[0091] Such a concentrator makes it possible, in a manner known per se, to establish single or multi-path communications between two communication devices, including when one and / or the other of these communication devices does not have MIF capabilities and / or does not support multi-path transport protocols. The use of the Convert protocol advantageously allows the establishment of a TCP connection which makes it possible to immediately exchange useful data between the two communication devices via the concentrator without waiting for the result of the execution of the “3-way handshake” (3WHC) mechanism characteristic of the protocol TCP (i.e., communication devices can exchange useful data from the exchange of a first message aimed at establishing a connection between the communication devices); as is known per se, in the context of the TCP protocol, the establishment of a connection is done by means of the three-step 3WHC mechanism which is based on the exchange of segments (i.e., messages) TCP SYN, SYN+ACK and ACK.

[0092] It should be noted that the “0-RTT Convert Protocol” conversion protocol is a generic conversion protocol that can be applied for transport protocols other than the TCP protocol and its MPTCP option. The use of this protocol is advantageous here because it makes it possible to convey application data and control data in the payload of the TCP segments. Of course, these different hypotheses are not limiting in themselves, and other configurations of the system 1 can be envisaged. It is possible to envisage using protocols other than the Convert protocol, such as for example MASQUE (for “Multiplexed Application Substrate over QUIC Encryption”) or SOCKS, and / or conveying the control data relating to the invention in a dedicated channel. It is also possible to envisage an embodiment in which only simple communications (i.e. established on a single path) are implemented and / or the PI proxies, etc.,PM does not aggregate or use multiple sub-connections (paths) of the same device.

[0093] In the embodiment described here, the communication devices UE1 and UE2, the proxies PI,..., PM and the network controllers NSC1,..., NSCN each have the hardware architecture of a computer 2 as illustrated in [Fig.2]. This hardware architecture notably comprises a processor PROC, a random access memory MEM, a read only memory ROM, a non-volatile memory NVM, and communication means COM. The non-volatile memory NVM constitutes a recording medium in accordance with the invention, readable by the processor PROC and on which a program in accordance with the invention is recorded.

[0094] This program, noted PROG-P when the hardware architecture of the computer 2 is that of a proxy according to the invention such as the proxies PI,..., PM, is recorded in the non-volatile memory NVM and comprises instructions defining the main steps of a selection method according to the invention as implemented by each proxy Pm, m=l,.. .,M. It defines more specifically the functional modules of each of the proxies Pm, m=l,...,M (represented in [Fig.l] only for the proxy PmO for the sake of simplification), which rely on and / or control all or part of the PROC, MEM, ROM, NVM, and COM elements of the computer 2 cited above. These functional modules comprise, in the embodiment described here, when the proxy Pm is on the data path relating to a service “S” provided by a service provider SSP based on network slices (for example service provider SSP1) and exchanged during a COM communication between two communication devices such as communication devices UE1 and UE2: - a selection module 3A, configured to select, according to a given selection POL policy, for each communication device at least one network slice adapted to the service “S” usable by this communication device during the COM communication. By “usable by the communication device”, it is meant that the communication device must use at least one of these network slices for the communication as soon as it has been informed of the selection of the proxy. The selection POL policy is for example a local policy stored in the NVM memory of the computer 2; - a communication module 3B, activated if a said communication device is not connected to at least one said network slice adapted to the service “S” and selected or intended to be selected by the selection module 3A for this communication device. The communication module 3B is configured to send to at least one network controller managing said at least one network slice among the network controllers NCS1,..., NSCN, a request for connection of the communication device in question to said at least one network slice; and - a sending module 3C, configured to send a message to each communication device (UE1, UE2 in the example considered here) indicating to it the network slice(s) which have been selected for it by the selection module 3A, and which can be used by the communication device during COM communication.

[0095] In the embodiment described here, the program PROG-P also defines the following functional modules of each proxy Pm, m=l,...,M: - a 3D announcement module, configured to announce to each communication device (UE1 and UE2 in the example envisaged here) the network slice(s) to which it is connected. The 3D announcement module can also be configured to announce at least one communication protocol supported by the proxy Pm and which can be used to convey various information used for the implementation of the invention. Such a protocol can in particular be a given transport protocol, such as, in the example envisaged here, TCP and its MPTCP option, supplemented by new extensions defined for the implementation of the invention, as described in more detail later. Other protocols can alternatively be envisaged, such as for example other transport protocols such as QUIC and where applicable its extension MPQUIC or DCCP and where applicable its extension MPDCCP, or application protocols such as HTTP (for “HyperText Transfer Protocol” in English) or protocols implemented at the IP layer level such as GRE (for “Generic Routing Encapsulation” in English); and - a reception module 3E, configured to receive from communication devices (and in particular from devices UE1 and UE2 in the example envisaged here) information relating to the network slices to which these communication devices are connected. In another embodiment, the proxy Pm can obtain this information from another entity, for example from controllers NSC1,..., NSCN.

[0096] The operation of modules 3A to 3E of a proxy Pm, m=l,.. .,M is described in more detail later with reference to the steps of the selection method.

[0097] When the hardware architecture of the computer 2 is that of a communication device according to the invention (in the example envisaged, of the device UEi with i=1 or 2), the computer program stored in the memory NVM is a program PROG-UE, comprising instructions defining the main steps of a communication method according to the invention as implemented by the communication device in question. It defines more specifically the functional modules of the communication device, which rely on and / or control all or part of the PROC, MEM, ROM, NVM, and COM elements of the computer 2 cited above. These functional modules comprise, in the embodiment described here, for the communication device considered (for example UEI, respectively UE2): - a reception module 4A, configured to receive from a proxy Pm according to the invention located on a path of all or part of the data relating to a service (for example the service S provided by the service provider SSP1) exchanged during a communication (for example the COM communication introduced previously) with another communication device involved in the communication (for example with UE2, respectively UEI), a message indicating to it at least one network slice adapted to this service usable by the communication device during the communication and selected by the proxy for this communication device according to a given selection policy (for example here the selection policy POL); and - a communication module 4B, configured to use at least one network slice indicated by the proxy during said communication.

[0098] In the embodiment described herein, the PROG-UE program also defines - a discovery module 4C, configured to discover one or more proxies conforming to the invention which support a given communication protocol (typically here the TCP protocol and its MPTCP option for managing multiple paths) and which are connected to one or more network slices to which the communication device is itself connected; and - a 4D sending module, configured to send to one of the discovered proxies, the network slice(s) to which the communication device is connected.

[0099] The operation of the modules 3A to 3E of a communication device according to the invention is described in more detail later with reference to the steps of the communication method.

[0100] When the hardware architecture of the computer 2 is that of a network controller according to the invention, for example an NSCn controller, n=1,.. .,N of the NWn network in the example envisaged here, the computer program stored in the NVM memory is a PROG-NSC program, comprising instructions defining the main steps of a management method according to the invention as implemented by the NSCn network controller in question. It defines more specifically the functional modules of the NSCn network controller (represented only in [Fig.1] for the NSC1 controller for the sake of simplification), which rely on and / or control all or part of the PROC, MEM, ROM, NVM, and COM elements of the computer 2 cited above. These functional modules comprise, in the embodiment described here: - a reception module 5A, capable of receiving from a proxy conforming to the invention (for example Pm) located on a path of all or part of the data relating to a service (for example the service S provided by the service provider SSP1) and exchanged during a communication (for example the aforementioned COM communication) via the network NWn in particular, between two communication devices (for example UE1 and UE2) involved in the communication, a request for connection of at least one of said devices to at least one network slice managed by the controller NSCn; and - a trigger module 5B, configured to trigger the requested connection. Note that the trigger module 5B is configured to initiate at least this connection; it is nevertheless not necessarily the only active module to actually connect the network slice in question to the communication device, and one or more entities other than the network controller NSCn may be involved to carry out this connection at the initiative of the network controller NSCn.

[0101] The operation of modules 5A and 5B of an NSCn controller, n=l,.. .,N is described in more detail later with reference to the steps of the management process.

[0102] We will now describe, with reference to Figures 3 to 5, the main steps of the methods implemented by each of the aforementioned devices (communication devices, proxies and network controllers) in accordance with the invention in the embodiment of the invention.

[0103] For illustrative purposes, to describe this embodiment, we consider the context of the COM communication between the communication devices UE1 and UE2, introduced previously, and during which application data relating to the service “S” provided by the service provider SSP1 are exchanged between the communication devices UE1 and UE2 involved in the COM communication. In the example envisaged here where the communication devices UE1 and UE2 are multi-interface and implement the TCP protocol and its MPTCP option, the COM communication can rely on one or more “simple” TCP connections between the communication devices UE1 and UE2, using one or more communication paths (or links). We speak of link aggregation when the COM communication results from the aggregation of several simple TCP connections; the COM communication is then said to have multiple paths.It is noted that link aggregation can alternatively take place at the level of the concentrator embedded in a proxy Pm, m=l,... M. .

[0104] In this context, Figures 3A and 3B represent the main steps of the communication method according to the invention as implemented respectively by the communication devices UE1 and UE2; [Fig. 4] represents the main steps of the selection method as implemented by the proxy(ies) of the system 1 involved in the COM communication (and which are on a path taken by the application data exchanged during the COM communication between the communication devices UE1 and UE2), and [Fig. 5] represents the main steps of the management method implemented by the network controller(s) used in the context of the invention. As mentioned previously, the term "SLALOM" refers to the overall procedure proposed by the invention for optimally accessing a service provided by an SSP service provider.

[0105] With reference to Figures 3A and 3B, each communication device UE1, UE2 negotiates with each service provider SSP with which it is connected a list of network slices that it is likely to use to send or receive traffic (i.e. application data) when it accesses a given service (step E10). In the example envisaged here, the devices UE1 and UE2 negotiate in particular with the service provider SSP1, a list of network slices that they can use to access the services to which they have subscribed with the service provider SSP1, and in particular to the service S, and their connection to these network slices. This list identifies the network slices in question as well as the types of these network slices. By For example, we consider here the types of network slices corresponding to the SST values ​​defined in the 3GPP TS 23.501 document cited above. We designate LIST1 and LIST2 the lists of network slices obtained respectively by the communication devices UE1 and UE2.

[0106] Alternatively, these lists may be communicated to the communication devices UE1 and UE2 by the networks with which the communication devices UE1 and UE2 are registered. According to yet another alternative, if one of the communication devices UE1 or UE2 is a TV decoder or a set-top box, such a list may be obtained from a platform managing the decoder or the set-top box, connected to the network, and operated by the service provider (e.g. an IPTV or VoD service for “Video on Demand”).

[0107] Then, in the embodiment described here, each communication device UE1, UE2 discovers, via its discovery module 4C, the proxies in accordance with the invention located in a network to which it is connected or reachable via such a network and connected to at least one network slice to which the communication device UE1, UE2 is connected (step E20).

[0108] It is assumed, in the embodiment described here, that the proxies Pm, m=l,.. .,M are configured (or declared) at each communication device UE1, UE2 explicitly by the user of the communication device UE1, UE2 or by the operator of an access network to which the communication device UE1, UE2 is connected. Each communication device UE1, UE2 then obtains the list of network slices to which each proxy Pm, m=l,.. .,M is connected by establishing a connection with it, via a network slice defined by default.

[0109] To this end, in the embodiment described here, the communication device UE1, UE2 (and more particularly its discovery module 4C) uses to communicate with the proxy Pm the Convert protocol supplemented by two new extensions defined for the needs of the invention making it possible to exchange various information between the communication devices UE1, UE2 and the proxy Pm (and more particularly here, various control information, i.e. data characteristic of an exchange which is located in the control plane such as a route using a network slice).More specifically, a first extension, called here PC-SC (for “Proxy Control Slalom Capable”) makes it possible to signal the capacity of a device (communication device UE1, UE2 or proxy Pm) to support the SLALOM procedure; a second extension, called here PC-SS (for “Proxy Control Slice Set”) makes it possible to signal the network slices to which the device in question is connected. In accordance with the Convert protocol, these extensions here take the form of messages in TLV format. In the following, the Convert control messages are referred to interchangeably as “TLVs”, “messages”. TLV”, or “message in TLV format”. Note that one or more TLV Convert messages can be included in the same TLV message.

[0110] Figure 6A illustrates an example of a PC-SC TLV message. In the example illustrated by Figure 6A, the “Value” field of the PC-SC TLV is set to “0”, however any other value can be considered as a variant. The presence of the PC-SC TLV in a message sent by the device in question is sufficient in itself to indicate the device’s ability to support the SLALOM procedure.

[0111] Figure 6B represents an example of a PC-SS TLV message that can be inserted into a message sent by a communication device UE1, UE2 to a proxy Pm (m=1,..,M) in order to obtain information representative of the network slices to which the proxy Pm is connected. The “Value” part of the message is then set to “0” (or to any other predefined value).

[0112] Figure 6C represents an example of a PC-SS TLV message that can be inserted into a message sent in response to the communication device by the proxy Pm (by its 3D announcement module for example), following reception of the PC-SS TLV of Figure 6B. In Figure 6C, the first line L1 provides the type of TLV (PC-SS), its length, and the number of sets of network slices provided (“Slice Set Count”) in the PC-SS TLV, each set corresponding to a type of network slices (“Slice Type”). The second line L2 indicates the start of the first set, “SID Count” designating the number of network slices in the first set, and “Slice Type” the type of network slices in the first set. The following lines referenced by SID#1, ..., SID#n, ... provide the information relating to the network slices of the first set, identified respectively by the network slice identifiers or SID (for “Slice IDentifier” in English).Line L3 indicates the start of a second set of network slices, information about which is provided in the lines following line L3, identified by the identifiers SID#1, ..., SID#m, .... .

[0113] It is of course possible to envisage protocols other than the Convert protocol for conveying the information illustrated by Figures 6A to 6C.

[0114] Figures 7A and 7B illustrate examples of using messages in PC-SC TLV and PC-SS TLV format based on the TCP protocol. In these examples, the PC-SC and PC-SS TLVs are inserted into the payload of TCP segments, and more particularly of SYN, SYN+ACK and ACK segments exchanged during the establishment of a connection. However, these are only illustrative examples and are not limiting in themselves.

[0115] Thus, in Figure 7A, the PC-SC TLV is inserted into a TCP SYN segment sent to the proxy Pm by the communication device UE1, UE2 to establish a connection with it and signal to it that it supports the SLALOM procedure. In a particular embodiment, the communication device UE1, UE2 can also signal on this occasion to the Pm proxy, via the MPTCP option MP_CAPABLE, that it supports multipath communications. If the Pm proxy also supports the SLALOM procedure, it responds to the communication device UE1, UE2 by inserting a PC-SC TLV in a TCP SYN+ACK segment. This is followed by an ACK segment sent by the communication device UE1, UE2 to the Pm proxy acknowledging receipt of the SYN+ACK segment (and the PC-SC TLV) sent by the Pm proxy. If the Pm proxy does not support the SLALOM procedure, it does not insert a PC-SC TLV in its SYN+ACK segment. Following the establishment of the connection between the communication device UE1, UE2 and the proxy Pm, the communication device UE1, UE2 sends to the proxy Pm in a TCP segment (generally noted TCP-PKT) a PC-SS TLV as represented by figure 6B with the Value field set to “0” (noted PC-SS(O) in figure 7A), requesting the proxy Pm for the network slices to which it is connected.The proxy Pm responds by inserting a PC-SS TLV as shown in Figure 6C and identifying the different network slices to which it is connected (denoted PC-SS(Pm) in Figure 7A), in a TCP segment. Then the device UE1, UE2 closes the connection.

[0116] Figure 7B illustrates an alternative embodiment in which the proxy Pm sends to the communication device UE1, UE2 a PC-SS TLV identifying the network slices to which it is connected (i.e. as shown in Figure 6C), in the SYN+ACK segment that it sends to the communication device UE1, UE2 when establishing the connection. The presence of such a PC-SS TLV implicitly indicates that the proxy Pm supports the SLALOM procedure. Then the device UE1, UE2 closes the connection.

[0117] In an alternative embodiment, the PC-SC and PC-SS messages can be exchanged between the 4C discovery module of the communication device UE1, UE2 and the 3D announcement module of the proxy Pm in other TCP segments than the SYN and SYN+ACK segments, or using a transport protocol other than TCP. In yet another alternative, the control information relating to the support of the SLALOM procedure and to the network slices to which the proxy Pm is connected can be exchanged between each communication device UE1, UE2 and the proxy Pm via a dedicated control channel.

[0118] In another embodiment, the discovery of proxies by the communication devices UE1, UE2 is carried out using the DNS SVCB mechanism described in the document by B. Schwartz et al. published by the IETF, entitled “Service binding and parameter specification via the DNS”, draft-ietf-dnsop-svcb-https-12, March 11, 2023. This mechanism defines a type of SVCB RR record (for “Resource Record SVBC” in English) at the level of the name servers used during name resolution (also more commonly called DNS servers for “Domain Name System » in English) offering the possibility to a client device to obtain, when it queries a DNS server, various information to facilitate access to a service, and in particular configuration information of the transport protocol to be used to access this service (this information is typically indicated in the service parameter « ALPN » of an SVBC RR record). It is possible to envisage introducing a new SvcParam field in the SCVB RR record of a proxy Pm, m=l,.. .,M, called for example here, for illustration purposes, « slicehint », and defined for the needs of the invention, in which the list of network slices to which the proxy Pm is connected is announced. This list may include for example the identifiers and / or the types of these network slices.

[0119] It should be noted that the communication devices UE1 and UE2 may discover the same proxies or different proxies during step E20. For the sake of simplification here, it is assumed that the same proxies Pm, m=l,...,M are discovered by the two communication devices.

[0120] Once the proxies Pm, m=l,.. .,M and the network slices to which they are connected have been discovered by the communication device UE1, UE2, the latter (via for example its discovery module 4C) stores the information obtained in a cache, and performs a filtering among the discovered proxies to retain only the one or ones which implement a given communication protocol PROT used by the communication device UE1, UE2, and which are connected to a network slice to which it is itself connected.

[0121] For example, here, the PROT communication protocol is a specific transport protocol, namely the TCP protocol and its MPTCP option, supported by the communication device UE1, UE2. But as mentioned previously, other transport protocols, applications or those working at the IP layer level can be considered as a variant by defining appropriate extensions for implementing the invention. Such extensions can take different forms depending on the protocol considered. For example, for the TCP / MPTCP protocol they can take the form of new TCP options or new “flags”. For the QUIC / MPQUIC protocol, they can take the form of a new transport parameter, a new QUIC frame, an error message, etc. When the Convert protocol is considered in addition to the TCP protocol, new messages in TLV format can be defined.Those skilled in the art will easily transpose the extensions described here for the implementation of the invention in the particular example of the Convert, TCP protocols and its MPTCP option, to other communication protocols, taking into account their specificities.

[0122] The filtering carried out by the communication device UE1, UE2 can be carried out globally, or for each communication, or even for each service, the protocol PROT may differ for each filtering. In addition, the communication device UE1, UE2 may maintain lists of discovered proxies per protocol (e.g., one list of proxies for the TCP / MPTCP transport protocol, one for the QUIC / MPQUIC transport protocol) and select for a communication a given transport protocol PROT and the corresponding list of proxies.

[0123] It is now assumed that the communication device UE1 wishes to exchange application data during a COM communication with the communication device UE2 within the framework of the service “S” (“data relating to the service “S”” within the meaning of the invention), using the PROT protocol (PROT = TCP / MPTCP here) and relying on the SLALOM procedure.

[0124] In the embodiment described here, the SLALOM procedure is advantageously triggered concomitantly with the establishment of the connection between the communication devices UE1 and UE2, and certain information useful for this implementation is conveyed in the messages exchanged during this establishment. Typically in the example of the TCP protocol, such information can be conveyed in the TCP segments SYN, SYN+ACK and ACK exchanged during the three-step procedure “3WHS” mentioned above making it possible to establish a connection, as illustrated in an example by [Fig. 8]. However, as a variant, another embodiment can be envisaged in which dedicated messages (for example dedicated TCP segments) are provided for the implementation of the invention.

[0125] With reference to FIG. 3A, the communication device UE1 selects a proxy from among the proxies discovered and filtered during step E20 supporting the PROT protocol, for example the proxy PmO (step E30), then sends, via the selected proxy PmO, a connection establishment request M1 in accordance with the PROT protocol to the communication device UE2 (step E40). Thus, the proxy PmO is on the path of the application data relating to the service S (i.e. the data plane) exchanged during the COM communication between the communication devices UE1 and UE2 involved in the COM communication (it should be noted that the connection establishment request M1 may, possibly already, convey application data relating to the service “S”).

[0126] The connection request M1 is sent by the communication device UE1, via its sending module 4D, using a network slice to which the proxy PmO and the communication device UE1 are both connected, and which is adapted to the service “S” to which the communication device UE1 wishes to access (the communication device UE1 selects this network slice depending for example on its type and the constraints associated with the service “S”, in a manner known per se). It takes the form here of a TCP segment comprising the MPTCP option supported by the communication device UE1, and including in its payload, in accordance with the Covered protocol, a message in the Connect TLV format requesting establishment of a connection with the PmO proxy. The Connect message carries a PC-SS TLV as illustrated in Figure 6C, referenced in the figures by PC-SS(UEl), indicating to the PmO proxy the network slices to which the communication device UE1 is connected. All or part of the elements relating to the network slices, indicated in the PC-SS(UEl) TLV may have been provided to the communication device UE2 during step E10, for example in the list LISTL

[0127] Furthermore, in the embodiment described herein, the Connect TLV message also includes the following additional information for each network slice indicated in the PC-SS(UEl) TLV: - a network identifier or NID (for “Network IDentifier” in English) with which the network slice is associated (to typically distinguish two network slices bearing the same identifier but attached to different networks), and / or - one or more AddressID (for “Address IDentifier” in English) identifiers of IP addresses allocated to this network slice for the UE1 communication device, which can be used in particular in the presence of a NAT (for “Network Address Translation” in English) device between the UE1 communication device and the PmO proxy, in a manner known per se. This additional information may be transmitted in the PC-SS(UEl) TLV, for example in a similar manner to the SID identifiers, or in another message in the TLV format provided for this purpose. The NID identifiers may have been provided to the communication device UE1 during step E10, for example in the list LIST1, when the communication device UE1 connected to the service provider SSP1, or may have been configured at the communication device UE1, in a similar or identical manner to the elements of the PC-SS(UEl) TLV. The AddressID identifiers are generated by the communication device UE1, for example according to the same mechanism as that used for the MPTCP option ADD_ADDR.

[0128] As an illustration in [Fig.8], the request M1 corresponds to a TCP SYN(PC-SS(UE1)) segment sent by the communication device UE1 to the proxy PmO.

[0129] It is noted that during the proxy discovery step, in the embodiment described here, the communication device UE1 and the proxy PmO have already signaled their respective support of the SLALOM procedure via the PC-SC TLV. However, if this is not the case, for example because the proxy discovery relied on the SVCB DNS mechanism, such an exchange can be envisaged before the communication device UE1 sends to the proxy PmO the PC-SS(UEl) TLV identifying the network slices to which it is connected.

[0130] With reference to [Fig.4], upon receipt of the request M1 by its reception module 3E (step F10), the proxy PmO extracts the Connect TLV intended for it, and within this message, the information contained in the TLV PC-SS(UE1) and, where applicable, the additional information relating to the identifiers NID and / or AddressID (step F20). It stores this information in association with the communication device UE1, for example in a cache of its NVM memory.

[0131] Then the proxy PmO relays to the communication device UE2 the connection establishment request from the communication device UE1 (step F30). It previously enriches this request with various information, and more particularly, in the embodiment described here with an attribute SC (for “Slalom Capable”), reflecting the fact that it supports the SLALOM procedure (and is therefore a proxy conforming to the invention). This attribute takes the form, for example, of a new extension of the PROT protocol defined for the needs of the invention. Thus, in the embodiment described here, it is a new TCP option. However, as a variant, other forms are possible depending on the protocol considered.

[0132] Furthermore, the PmO proxy can enrich the connection establishment request with other information, such as for example the MPTCP MP_CAPABLE option reflecting, where appropriate, its capacity to support multi-path TCP communications.

[0133] The enriched connection establishment request is designated by Ml'. It is sent by the PmO proxy to the communication device UE2 using as source transport address (this comprising a source IP address and port number), the transport address of the PmO proxy (step F30). As an illustration in [Fig.8], the request Ml' corresponds to a TCP SYN(SC) segment sent by the PmO proxy to the communication device UE2.

[0134] Upon receipt of the request M1' to establish a connection (step E30', FIG. 3B), if the communication device UE2 supports the SLALOM procedure (and is therefore a communication device in accordance with the invention), it responds to the proxy PmO by inserting in its response message M2 (via its sending module 4D), information relating to the network slices to which the communication device UE2 is connected, i.e. to the network slices of the list LIST2 provided by the service provider SSP1 in step E10) (step E40'). This information is included, in the embodiment described here, in an attribute SS (for "Slice Set") referenced by SS(UE2). As an illustration in [Fig. 8], the message M2 is for example a TCP segment SYN+ACK(SS(UE2)). The SS attribute may take the form of a new extension of the PROT protocol, i.e. TCP and its MPTCP option here, defined for the purposes of the invention.

[0135] The SS attribute here includes, for each network slice: - an ST type (for "Slice Type" in English) of the network slice. This ST type corresponds for example to an SST value defined by the 3GPP standards. Of course, other network slice type indicators can be considered as long as they are interpretable by the SSP service providers. Thus, standardized or specific types (for example decided in over-the-counter agreements between the SSP providers) can be considered. Furthermore, the same network slice can be associated with several slice types, in particular when this network slice aggregates several local network slices; and - a network slice identifier or SID (for “Slice IDentifier” in English).

[0136] The SS attribute may further comprise, for each network slice, other information such as for example a network identifier NID with which the network slice is associated (to typically make it possible to distinguish two network slices bearing the same identifier but attached to different networks), and / or one or more AddressID identifiers of IP addresses allocated to the communication device UE2 for this network slice, which may be used in particular in the presence of a NAT (Network Address Translation) device between the communication device UE2 and the PmO proxy, in a manner known per se.

[0137] All or part of the ST, SID and NID information may have been provided to the communication device UE2 during step E10, for example in the list LIST2, when the communication device UE2 connected to the service provider SSP1, or may have been configured at the level of the communication device UE2. The AddressID identifiers are generated by the communication device UE2, for example according to the same mechanism as that used for the MPTCP option ADD_ADDR.

[0138] On receipt of the response message M2 by its reception module 3E (step F40, [Fig.4]), the proxy PmO extracts the information contained in the attribute SS(UE2) and stores it in association with the communication device UE2, for example in a cache of its NVM memory (step F50).

[0139] Then the proxy PmO, via its selection module 3A, selects for each communication device UE1, UE2, according to the selection policy POL stored locally in its NVM memory, at least one network slice adapted to the service “S” usable by the communication device UE1, UE2 for the COM communication (step F60). In the remainder of the description, SL(UE1) denotes the network slice(s) selected for the communication device UE1 and SL(UE2) denotes the network slice(s) selected for the communication device UE2.

[0140] In the example considered here, the POL selection policy comprises several selection rules, which are hierarchical among themselves, i.e. intended to be applied in a certain order:

[0141] - a first RI rule called compatibility according to which when a condition of compatibility is verified according to which the communication devices UE1 and UE2 are connected to at least one network slice of the same type which is adapted to the service “S”, said at least one network slice of the same type is selected for these communication devices to be used during the COM communication;

[0142] - a second rule R2 according to which at least one selected network slice for at least one said device corresponds to a network slice to which this device is already connected. When applying this second rule R2, one of the two devices may be favored. For example, a network slice is selected to which the communication device UE2 is already connected; this may be relevant, for example, if the communication device UE2 does not support the SLALOM procedure. Alternatively, the communication device connected to the network slice that optimizes the quality of the service “S” may be favored, with regard to a determined criterion that depends on the service “S” or the type of service “S” (e.g., latency, throughput, error rate, communication connection setup time, or bandwidth); and

[0143] - a third rule R3 according to which the network slices selected for the dis communication devices UE1 and UE2 optimize the quality of service "S", for example with regard to a given criterion which depends on the service "S" or the type of service "S" (latency, throughput, error rate, connection establishment time of the communication, bandwidth, etc.). It should be noted that this rule R3 can be applied globally so as to optimize the overall quality of service "S" between the two communication devices UE1 and UE2 on the two network slices, or per communication segment, the criterion being applied a first time to select the slice SL(UEl) so as to optimize the quality of service "S" between the communication device UE1 and the proxy PmO, and a second time to select the slice SL(UE2) so as to optimize the quality of service "S" between the communication device UE2 and the proxy PmO.

[0144] As mentioned previously, these rules are hierarchical within the POL selection policy, i.e. applied in a certain order. For example, here, the first, second and third rules are hierarchical as follows:

[0145] - we first test whether the compatibility condition of the first RI rule is verified. If applicable, compatible network slices are selected, and if several network slices verify this condition, the third rule R3 is used to select among the compatible network slices; and

[0146] - if the compatibility condition is not verified, the second rule R2 is applied, favoring a network slice to which the UE2 communication device is already connected. If several network slices meet this condition, the third rule R3 is used to make the final selection.

[0147] It is noted that to identify the network slices suitable for the service “S” in each of the rules, the PmO proxy can use the service level objectives or SLOs (for “Service Level Objectives” in English) known for these network slices, which it compares to the requirements of the service “S”. It can for this purpose be configured with these SLOs (for example by type of slice) or obtain them from the controllers NSC1,..., NSCN managing the network slices in question. Furthermore, the application of the third rule R3 can use one or more quality criteria available in the SLOs.

[0148] Of course, other selection policies may be envisaged, prioritizing the rules stated above in a different way, or containing one or more rules among the rules above, and / or containing other rules. For example, a fourth rule may be envisaged consisting of selecting for at least one of the communication devices, a network slice adapted to the service to which the PmO proxy is connected, or even a fifth rule relating to parameters other than the quality of service such as in particular a security level.

[0149] Thus, in accordance with the selection policy POL, the proxy PmO first examines whether, among the network slices to which the communication devices UE1 and UE2 are connected, there are compatible network slices, i.e. identical or of the same type, which are suitable for the service “S”. It can for this purpose compare the information PC-SS(UEl) relating to the different network slices to which the communication device UE1 is connected with the information SS(UE2) relating to the different network slices to which the communication device UE2 is connected which it has in its non-volatile memory NVM, and if necessary, verify that the compatible network slices are suitable for the service “S” by considering their respective SLOs (the order in which the proxy PmO proceeds is unimportant).

[0150] Alternatively, when it identifies compatible network slices, the PmO proxy can compare, if it has such information, the SID identifiers of the network slices combined with the NID identifiers of the networks to which the network slices are attached. Indeed, it can be envisaged that a communication device UE1, UE2 announces distinct network slice SID identifiers per network. In this case, the association between a SID identifier of a network slice and a type of network slice depends on the NID identifier corresponding to this network slice.

[0151] If the PmO proxy identifies at least two compatible network slices among the network slices to which the communication devices UE1 and UE2 are connected, it selects for the communication devices UE1 and UE2 the corresponding network slices SL(UEl) and SL(UE2) (application of the first RI rule).

[0152] In the event that several pairs of two-by-two compatible network slices are identified by the PmO proxy, it can, depending on its configuration, select all or part of these pairs for the communication devices UE1 and UE2. For example, it can select a single pair corresponding to the network slices SL(UE1) and SL(UE2) which optimize (or whose types optimize) the quality of the service “S” with regard to the criterion or criteria considered in the third rule R3 (in other words, the selection made by the PmO proxy results from the application of the first rule RI then of the third rule R3). If it is the type of network slices which is considered, the PmO proxy then selects, from among the pairs of compatible network slices, a pair of network slices SL(UE1) and SL(UE2) of this type.

[0153] If there is no compatibility between the network slices to which the communication devices UE1 and UE2 are connected, then, in the example envisaged here, in accordance with the second rule R2, the PmO proxy selects for the communication device UE2, at least one network slice SL(UE2) to which the communication device UE2 is already connected and which is adapted to the service “S”. If several network slices are possible, the PmO proxy can select all or part of these slices. For example, it selects the network slice SL(UE2) which optimizes the quality of the service “S” between the PmO proxy and the communication device UE2 with regard to the criterion(s) considered in the third rule R3. It is noted that different network slices or different types of network slices can be selected for distinct access networks.Then the PmO proxy selects for the communication device UE1 at least one network slice SL(UEl) adapted to the service S which optimizes the quality of the service S with regard to the criterion(s) considered in the third rule R3.

[0154] For this purpose, the PmO proxy may have been configured beforehand (or dynamically) with all the available network slices supported by the networks NW1,..., NWN, as well as with information allowing it to identify and contact the controllers NSC1,..., NSCN managing these network slices. It may also have been configured with the SLOs associated with these network slices, or obtain them by querying the controllers NSC1,..., NSCN.

[0155] It should be noted that, depending on the applied POL selection policy, the network slices SL(UE1) and SL(UE2) selected for the communication devices UE1, UE2 for the COM communication may be identical or of the same type, or on the contrary, be different or of different types. It is thus possible for the PmO proxy to select network slices that optimize the COM communication on each segment of the connection supporting this communication. The PmO proxy is not born necessarily forced to select the same network slice (or the same type of network slice) from end to end.

[0156] For the sake of simplification, it is assumed in the following that only one network slice is selected for each communication device UE1, UE2. If several network slices are selected for a communication device UE1, U2, the PmO proxy proceeds in the same or similar manner as described below for each selected network slice.

[0157] Following the selection of the network slice SL(UEl), the proxy PmO examines whether the communication device UE1 is already connected to this network slice using the information PC-SS(UEl) stored in its non-volatile memory NVM (test step F70).

[0158] If this is not the case (response no to test step F70), it sends to the controller NSC managing the network slice SL(UEl), via its communication module 3B, a request M3 for connection of the communication device UE1 to this network slice SL(UEl) (step F80). It is assumed here that it is the controller NSCnO (nO being an integer among 1,.. ,,N) which manages the network slice SL(UEl).

[0159] With reference to [Fig.5], upon receipt of the request M3 for connection of the proxy PmO by its reception module 5A (step G10), the controller NSCnO checks in the embodiment described here, whether the communication device UE1 is authorized (i.e. authorized) to use the network slice SL(UEl) (test step G20). It can also carry out other checks, such as for example checking that the proxy PmO is authorized to request such a connection for the communication device UE1. These checks are known per se and are not detailed here.

[0160] If this is not the case (response no to test step G20), the connection request is rejected (step G30).

[0161] If the communication device UE1 is authorized to use the network slice SL(UEl) (response “yes” to the test step G20), the controller NSCnO triggers the requested connection via its trigger module 5B (step G40), and sends a message M4 confirming this connection to the proxy PmO (step G50). With reference to [Fig. 4], the confirmation message M4 is received by the proxy PmO (step F90). It should be noted that the controller NSCnO is not necessarily the only entity of the network involved in the connection of the communication device UE1 to the network slice SL(UEl); it is the origin (i.e. initiates) of the connection, but other entity(ies) may support the controller NSCnO to make this connection effective.

[0162] The NSCnO controller may communicate directly with the communication device UE1 for connection to the network slice SL(UEl), or another entity of the NWnO network may do so, for example a customer support center. The user of the communication device UE1 may also be informed of this connection, for example via an SMS (Short Message Service) type notification message possibly accompanied by descriptive information of the new network slice SL(UEl) to which the communication device UE1 is connected, such as the quality of the connection expected via this network slice SL(UEl), etc.

[0163] It should be noted that if the PmO proxy is not connected to one and / or the other of the network slices SL(UEl) and SL(UE2), it can similarly request its own connection to the NSC controllers managing these network slices.

[0164] Furthermore, in the embodiment, the connection of the communication device UE1 to the network slice SL(UE1) is requested from the controller NSCnO following the selection of the network slice SL(UE1) for the communication device SL(UE1). Alternatively, it may be envisaged that the proxy PmO requests this connection for the network slices likely to be selected for the COM communication before the selection step F50, i.e. even before applying the selection policy POL. Such network slices may be identified by the proxy PmO according to the characteristics of the service “S” (determined for example from the destination address or other service identifiers indicated in the access messages to the service S sent by the communication devices UE1, UE2), the capabilities of the communication devices UE1, UE1, etc.In this way, the POL selection policy is applied on network slices to which the communication devices UE1, UE2 are connected.

[0165] With reference to Figure 3A, following the connection of the communication device UE1 to the network slice SL(UEl) (response "yes" in test step E50), the communication device UE1 sends, via its sending module 4D, a message M5 to the proxy PmO indicating to it the new network slice SL(UEl) to which it is connected (step E60). The message M5 is for example a TCP segment including in its payload, in a PC-SS TLV referenced by PC-SS(UEl)', all the network slices to which the communication device UE1 is connected. The PC-SS(UEl)' TLV is therefore an update of the PC-SS(UEl) TLV previously sent by the communication device UE1 to the proxy PmO, which includes on the one hand the network slices identified in the list LIST1 received from the service provider SSP1 in step E10, and on the other hand, the new network slice SL(UEl). Alternatively, the M5 message may contain only the new network slice SL(UEl).For example, the new SL(UEl) network slice can be included in a new extension of the Convert protocol, here called PC-SS-UPD TLV, capable of indicating to the PmO proxy that its content is an update of the information previously transmitted in the PC-SS(UEl) message.

[0166] With reference to [Fig.4], upon receipt of the message M5 by its reception module 3E (step F100), the proxy PmO extracts the information contained in the message PC-SS(UEl)' and stores it in the cache of its non-volatile memory NVM in association with the communication device UE1 (step F110). If the message PC-SS(UEl)' contains the information relating to all the network slices to which the communication device UE1 is connected, this information is stored in the cache to replace the previously stored information; if it concerns only the new network slice SL(UEl), then it is stored in addition to the previously stored information.

[0167] If during the test step F70, the proxy PmO determines that the communication device UE1 is already connected to the network slice SL(UEl) selected for the communication device UE1 (response “yes” to the test step E70), or at the end of the step F1 10, the proxy PmO sends, via its sending module 3C, a message M6, M7 to each communication device UE1, UE2 to indicate to it said at least one slice SL(UEl), SL(UE2) selected for it by the proxy PmO and usable by the communication device UE1, UE2 during the communication COM (step F120). These network slices can be indicated respectively in the M6 ​​and M7 messages in a PC-SS TLV (denoted PC-SS(UEl)'”) and an SS attribute (denoted SS(UE2)') respectively. These network slices allow to optimize the quality of service "S" during COM communication.With reference to Figures 3A and 3B, upon receipt by its reception module 4A of this message M6 (step E70), M7 (step E50'), each communication device UE1, UE2 switches the COM communication to at least one of the indicated network slices SL(UE1), SL(UE2) if it is / are different from the one(s) it uses (steps E80, E60'). When several network slices are indicated, a load distribution algorithm (e.g. ECMP for "Equal-Cost Multi-Path" in English) can be used between the network slices. The different network slices indicated by the PmO proxy can also be associated with separate networks, so that the communication device UE1, UE2 can switch the communication to the network slice(s) associated with the network via which it has decided to send data relating to the service "S".In any case, the communication device UE1, UE2 must use during COM communication at least one of the network slices indicated to it by the PmO proxy.

[0168] The communication devices UE1 and UE2, via their respective application modules 4B, are now configured to use the network slice(s) SL(UEl), SL(UE2) during the COM communication: they associate the outgoing traffic linked to the COM communication with the slices SL(UEl) and SL(UE2), and the marking of the traffic is that associated with the slices SL(UEl) and SL(UE2).

[0169] As an illustration in [Fig.8], an example of the use of TCP segments SYN+ACK and ACK to carry messages M5 to M7 is shown.

[0170] According to this example, if the PmO proxy determines during the test step F70 that the communication device UE1 is not connected to the network slice SL(UE1), it sends it a segment SYN+ACK(PC-SS(UE1)”) where the TLV PC-SS(UE1)” contains the network slice, noted SLO, used by the communication device UE1 to send the message M1 to the PmO proxy. The communication device UE1 responds by sending a segment ACK(PC-SS(UE1)”)).

[0171] Following the connection of the communication device UE1 to the network slice SL(UEl), the message M5 sent by the communication device UE1 to the proxy PmO takes the form of an ACK(PC-SS(UE1)') segment. As introduced previously, the TLV PC-SS(UEl)' identifies all the network slices to which the communication device UE1 is connected, including the network slice SL(UEl). The message M6 then sent by the proxy PmO takes the form of an ACK(PC-SS(UE1)'”) segment containing the network slice SL(UEl) selected by the proxy PmO for the COM communication for the communication device UE1.

[0172] Similarly, the M7 message sent by the PmO proxy to the UE2 communication device takes the form of an ACK(SS(UE2)”) segment, in which the SS(UE2)” attribute contains the SL(UE2) network slice selected by the PmO proxy and usable for COM communication by the UE2 communication device.

[0173] It should be noted that other implementations than those shown in [Fig.8] are possible. For example, the PmO proxy may defer sending the SYN+ACK message to the communication device UE2 until it receives confirmation of this connection from the communication device UE1. According to yet another implementation, the connection may be requested upstream of the selection, so that the SYN+ACK segment sent to the communication device UE2 identifies in the TLV PC-SS(UEl)” the network slice(s) SL(UEl) selected for the communication device UE1 and usable for COM communication.

[0174] Following the switchover of the communication on the network slices SL(UE1) and SL(UE2), the proxy PmO may, depending on the context, remain or not be involved in the exchange of data between the communication devices UE1 and UE2, i.e. remain or not be on the path of the data exchanged between the communication devices UE1 and UE2 and ensure its function of relaying the data between the communication devices UE1 and UE2.

[0175] More particularly, if the network slices SL(UE1) and SL(UE2) used respectively by the communication devices UE1 and UE2 are identical, the PmO proxy can decide to withdraw from the path of the data exchanged between the communication devices UE1 and UE2 and let the communication devices UE1 and UE2 manage the end-to-end COM communication. For this purpose, the PmO proxy sends by example a withdrawal message to each communication device UE1, UE2; this withdrawal message uses for example the MPTCP REMOVE_ADDR option conveying the address of the PmO proxy and the PC-SS or SS extension conveying the network slice for which the PmO proxy is withdrawing. The communication devices UE1 and UE2 respectively signal their addresses, for example by means of the MPTCP ADD_ADDR option or the MP_JOIN option. Note that the PmO proxy can decide to withdraw for certain network slices only and to remain active for others. This decision depends, where appropriate, on instructions provided to the proxy by an operator.

[0176] The PmO proxy can conversely remain involved in the COM communication, in particular when the network slices SL(UEl) and SL(UE2) differ. It then performs the interconnection between the network slices SL(UEl) and SL(UE2), and its position in the plane of the data exchanged between the communication devices UE1 and UE2 allows it to access the marking of the data packets or the information contained in their headers which it can then modify to be able to adapt them to different network slices SL(UEl) and SL(UE2) and correctly direct the data packets to the correct network slices. For example, the proxy can modify the marking of the slices in accordance with the slices selected for a communication.

[0177] Furthermore, the communication devices UE1 and UE2 can memorize the network slices SL(UE1) and SL(UE2) selected for them for the service “S”, and during a future access to the service “S”, directly use these network slices without requesting the proxy PmO.

[0178] In the embodiment described here, the SLALOM procedure is triggered by the communication device UE1 when establishing the connection with the communication device UE2. It may be envisaged as a variant that it is triggered by the communication device UE2. Its sequence is then identical to that which has just been described for the communication device UE1.

[0179] In another embodiment, it is also possible to envisage that each communication device UE1, UE2 uses a different proxy, each of these proxies being on the path of all or part of the data exchanged during the COM communication between the two communication devices UE1 and UE2. [Fig. 9] illustrates a system 1' according to the invention corresponding to such a situation. In this figure, the communication device UE1 selects the proxy PmO and the communication device UE2 selects the proxy PkO, mO and kO designating two distinct integers. The SLALOM procedure, when triggered by the communication device UE1, is then implemented in a similar or identical manner to what has just been described between the communication device UE1 and the proxy PkO, then between the proxy PmO and the communication device UE2. In other terms, the PmO proxy selects for the communication device UE1 and for the PkO proxy the network slices to be used by these two devices for COM communication, then the PkO proxy selects for the PmO proxy and for the communication device UE2 the network slices to be used for COM communication by these two devices. The PmO and PkO proxies are therefore in turn proxies and communication devices in accordance with the invention.

[0180] Furthermore, in what has just been described, the communication devices UE1 and UE2 communicate directly with the proxies. It can be envisaged, in another embodiment, that the communication devices UE1 and / or UE2 are connected to equipment such as a residential gateway or CPE. In this case, the residential gateway is a communication device according to the invention and the SLALOM procedure applies in a similar or identical manner to what has just been described between the residential gateway and the remote communication device or the residential gateway to which this remote communication device is connected where appropriate.Each communication device UE1, UE2 located, where appropriate, behind a residential gateway communicates with it to obtain information relating to the network slices to which the gateway is connected (typically the information transmitted by the gateway to the proxy in the PC-SS or SS messages / attributes) and sends it the traffic classification rules to associate the outgoing flows with one or more suitable network slices corresponding to the network slices to which the gateway is connected. The communication device UE1, UE2 can for this purpose use new options or messages defined for the purposes of the invention depending on the protocol used to communicate these elements. For example, it is possible to envisage using the PCP (Port Control Protocol), DHCP (Dynamic Host Configuration Protocol), or an RA (Router Advertisement) message, etc.

Claims

Claims

1. Method for selecting network slices adapted to a service and intended to be used during a communication via at least one network between two devices (UE1, UE2) involved in said communication, said method being implemented by a proxy (PmO) located on at least one data path relating to said service and exchanged between said devices during said communication, said method comprising: - a step (F60) of selecting, as a function of a given selection policy, for each device (UE1, UE2), at least one network slice (SL(UE1), SL(UE2)) adapted to said service usable by this device during said communication;- if a said device (UE1) is not connected to at least one said network slice (SL(UEl)) selected or likely to be selected for this device, a step (F80) of sending to at least one network controller (NSCnO) of said at least one network managing said at least one network slice a request to connect said device to said at least one network slice; and - a step (F1 10) of sending a message to each device indicating to it said at least one network slice selected for said device usable by said device during communication.;

2. Selection method according to claim 1 further comprising a step (F20, F40) of obtaining from at least one said device, at least one piece of information representative of at least one network slice to which this device is connected.

3. Selection method according to claim 1 or 2 wherein the step of sending a connection request relates to a network slice capable of being selected for said device and is implemented before the selection step.

4. Selection method according to any one of claims 1 to 3 in which the selection policy applies at least one rule from among the following rules: - the network slices selected for said devices optimize a quality of said service; and / or - at least one network slice selected for at least one said device is a network slice to which this device is already connected; and / or - when said devices are connected to at least one network slice of the same type adapted to the service, said at least one network slice of the same type is selected for said devices.

5. Selection method according to any one of claims 1 to 4 further comprising a step of sending to at least one said device at least one piece of information representative of at least one network slice to which the proxy is connected.

6. Selection method according to any one of claims 1 to 5 comprising, following the step of sending said message to each device, a step of maintaining said proxy on at least one said data path relating to said service exchanged between said devices during said communication via at least one network slice selected for said devices.

7. Selection method according to any one of claims 1 to 5 comprising, following the step of sending said message to each device, a step of removing said proxy from at least one said data path relating to said service exchanged between said devices during said communication via the same network slice selected for said devices.

8. Selection method according to any one of claims 1 to 7 wherein said at least one information representative of a said network slice comprises at least one element among: - a type of said network slice; - an identifier of said network slice; - a network identifier to which said network slice is attached; - at least one IP (Internet Protocol) address identifier associated with said network slice.

9. Method for managing at least one network slice by a network controller (NSCnO) of a network, said method comprising: - a step (G 10) of receiving, from at least one proxy (PmO) located on a data path relating to a service and exchanged via at least said network during a communication (COM) between two devices (UE1, UE2) involved in said communication, a request for connection of at least one of the devices (UE1) to at least one network slice (SL(UEl)) managed by said network controller; and - a step (G40) of triggering said connection.

10. Method of communication by a first device (UE1, UE2) with a proxy (PmO) located on a data path relating to a service and exchanged with a second device (UE2, UE1) during a communication (COM) involving the first and the second device, said method comprising a step (E80, E50') of receiving, from said proxy (PmO), a message indicating to said first device (UE1, UE2) at least one network slice (SL(UE1), SL(UE2)) adapted to said service usable by said first device during said communication and selected by said proxy (PmO) according to a given selection policy.

11. Communication method according to claim 10 further comprising, prior to the reception step (E80), a step (E40) of sending via said proxy (PmO) a request to establish a connection with said second device (UE2) for said communication, said establishment request comprising at least one piece of information (PC-SS(UEl)) representative of at least one network slice to which said first device (UE1) is connected.

12. Communication method according to claim 11 further comprising, prior to the sending step (E80), a step (E20) of discovering at least one proxy (PmO) connected to at least one network slice to which said first device (UE1) is connected and implementing at least one given communication protocol used during said communication, said proxy (PmO) being selected by the first device from said at least one proxy discovered during the discovery step.

13. Communication method according to claim 10 comprising in furthermore: - a step (E30') of receiving a request (ME) to establish a connection with said second device (UE1) for said communication relayed by said proxy (PmO); and - a step (E40') of sending to said proxy (PmO) a message (M2) comprising at least one piece of information (SS(UE2)) representative of at least one network slice to which said first device (UE2) is connected.

14. Proxy (PmO) located on a data path relating to a service and exchanged via at least one network during a communication between two devices (UE1, UE2) involved in the communication, said proxy (PmO) comprising: - a selection module (3A), configured to select according to a given selection policy, for each device (UE1, UE2), at least one network slice (SL(UE1), SL(UE2)) adapted to said service usable by this device during said communication; - a communication module (3B), activated if a said device (UE1) is not connected to at least one said adapted network slice selected or capable of being selected for said device, configured to send to at least one network controller (NSCnO) of said at least one network managing said at least one network slice a request (M3) for connection of said device to said at least one network slice;and - a sending module (3C), configured to send a message to each device indicating to it said at least one network slice selected for said device and usable during communication.;

15. Network controller (NSCnO) of a network comprising: - a reception module (5A), capable of receiving from at least one proxy (PmO) located on a data path relating to a service and exchanged via at least said network between a first and a second device (UE1, UE2) during a communication involving said first and second devices, a request (M3) for connection of at least one of said devices (UE1) to at least one network slice (SL(UEl)) managed by said network controller (NSCnO); and - a trigger module (5B), configured to trigger said connection.

16. Communication device (UE1, UE2), called first communication device, comprising: - a reception module (4A), configured to receive from a proxy (PmO) located on a data path relating to a service and exchanged via at least one network with a second communication device (UE2, UE1) during a communication involving said first and second devices, a message (M6, M7) indicating to said first communication device at least one network slice (SL(UE1), SL(UE2)) adapted to said service usable by said first device during said communication and selected by said proxy (PmO) according to a given selection policy; - a communication module (4B), configured to use at least one said network slice (SL(UE1),SL(UE2)) indicated by the proxy during said communication with said second communication device (UE2,UE1).

17. System (1) comprising: - at least two communication devices (UE2, UE1) according to claim 16, exchanging data relating to a service during a communication via at least one network; - at least one proxy (PmO) according to claim 14 located on a path of all or part of said data; and - at least one network controller (NSCnO) of said at least one network according to claim 15.

18. System (1) according to claim 17 wherein at least one said communication device is a proxy (PkO) according to claim 14.

Images