WO2025003097A1 - Procédés d'accès à un service, procédé de fourniture de services, procédé de contrôle, procédé de gestion, terminal, instance de service, contrôleur, nœud de bordure et programmes d'ordinateur correspondants - Google Patents

Procédés d'accès à un service, procédé de fourniture de services, procédé de contrôle, procédé de gestion, terminal, instance de service, contrôleur, nœud de bordure et programmes d'ordinateur correspondants Download PDF

Info

Publication number
WO2025003097A1
WO2025003097A1 PCT/EP2024/067744 EP2024067744W WO2025003097A1 WO 2025003097 A1 WO2025003097 A1 WO 2025003097A1 EP 2024067744 W EP2024067744 W EP 2024067744W WO 2025003097 A1 WO2025003097 A1 WO 2025003097A1
Authority
WO
WIPO (PCT)
Prior art keywords
identifier
terminal
service
network
network slice
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Ceased
Application number
PCT/EP2024/067744
Other languages
English (en)
Inventor
Mohamed Boucadair BOUCADAIR
Christian Jacquenet
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Orange SA
Original Assignee
Orange SA
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Orange SA filed Critical Orange SA
Priority to EP24734902.0A priority Critical patent/EP4736394A1/fr
Publication of WO2025003097A1 publication Critical patent/WO2025003097A1/fr
Anticipated expiration legal-status Critical
Ceased legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/302—Route determination based on requested QoS
    • H04L45/306—Route determination based on the nature of the carried application

Definitions

  • the field of the invention is that of communications within at least one communications network, and in particular that of value-added IP services.
  • the invention relates to access to at least one service using the network slice resources of a communications network.
  • the invention proposes a solution for selecting one or more network slices to be used for all or part of the traffic destined for a terminal.
  • a network slice can be defined as a partition of the network such as a virtual private network (VPN) deployed on fixed infrastructure, mobile infrastructure, or a combination of both.
  • VPN virtual private network
  • the characteristics of a network slice are mainly expressed in terms of capacity (bandwidth) and quality of service (e.g. latency, one-way transit time, etc.), or even security (e.g. preservation of the confidentiality of information transmitted within the VPN through the use of encryption techniques) and service functions (“Service Functions” or SFs).
  • bandwidth bandwidth
  • quality of service e.g. latency, one-way transit time, etc.
  • security e.g. preservation of the confidentiality of information transmitted within the VPN through the use of encryption techniques
  • service functions (“Service Functions” or SFs).
  • traffic that can be routed within a network slice is authorized (also called access control) to use the paths established within said network slice.
  • authorization is typically based on the application of traffic classification rules.
  • These rules are generally applied by a network access point within which network slices have been deployed.
  • This access point is a node located at the edge of the network and which is generally deployed in front of client accesses or used to connect a network to other neighboring networks.
  • an access point can be located at the connection interface of a gateway that provides access to the Internet network.
  • This gateway is called a "packet gateway” for the most recent generations (4G, 5G) of mobile networks.
  • the traffic classification function could be located at the connection interface of a "packet gateway" to the Internet network.
  • the access point may also be located at the interface for connecting a mobile terminal (or “User Equipment” or UE) to the radio access network (or “Radio Access Network” or RAN), in particular to optimize the use of radio resources according to the type of network slice and the profile of the traffic that it is likely to carry.
  • a traffic profile is the set of characteristics specific to the traffic. These characteristics may reflect the sensitivity of applications to latency, transit delay or packet loss, but also usage practices, for example traffic that would only be generated over a given period (for example management traffic linked to the execution of a maintenance operation on equipment scheduled during the night).
  • the traffic classification and admission control rules are therefore applied at the edge of the network.
  • traffic classification rules can be complex, because the level of granularity associated with the engineering and deployment of a network slice can be macroscopic (for example a network slice deployed to route traffic to the Internet), or microscopic (for example a network slice deployed for application traffic exchanged between two mobile terminals).
  • This granularity generates an overall complexity of network slice engineering, for example a difficulty in optimizing the use of resources implemented by a network slice, by a set of network slices, or by all network slices, or a difficulty in strictly guaranteeing the isolation of traffic routed within a network slice, or even a difficulty in strictly guaranteeing the level of quality or security associated with a network slice, or even the level of availability and resilience of a given network slice, etc.
  • the complexity of the configuration and application of traffic classification rules associated with the implementation of a given network slice evolves with the diversity of traffic, the richness of the organization of the structure that operates the network slice (for example, an accounting department, an R&D department, a production department) or the mode of use of the network slice (for example, management of traffic overloads during busy hours, principles of distribution of the traffic load).
  • This complexity can in particular be aggravated by the evolution of the traffic classification rules over time (for example, in the context of the deployment of a network slice for the retransmission of a sporting or cultural event, the traffic classification rules can evolve with the number and profile of users of the network slice).
  • Such a method can in particular be implemented by a terminal connected to the communications network.
  • Such a terminal obtains during a first step at least a first identifier intended for the classification of the traffic intended for the terminal.
  • a first identifier also called tag thereafter, is for example noted “inbound_flow_map” in one embodiment of the invention. It can be associated with a network slice or a type of network slice (for example EMBB, mIoT or URLLC if we consider a 5G network).
  • Such a first identifier of the traffic intended for the terminal is different from a network slice identifier used by equipment to connect to a network slice: this other network slice identifier is for example of the NSSAI 3GPP type.
  • Such a first identifier of the traffic intended for the terminal is for example generated by a network manager, for example implementing a session management function (“Session Manager Function” or SMF in English) or a network controller.
  • Session Manager Function or SMF in English
  • the first identifier intended for the classification of traffic to the terminal may in particular be received directly from the SMF manager or a network controller, or via an intermediate router, for example a CPE (“Customer Premises Equipment”) or other network connection equipment.
  • a CPE Customer Premises Equipment
  • such a first identifier may be inserted in a dedicated header (for example an HTTP header, a QUIC frame) or described in messages formatted according to protocols such as SIP (“Session Initiation Protocol”), SDP (“Session Description Protocol”) or WebRTC.
  • the terminal transmits said at least one first identifier to at least one first service instance (“Service Function Instance”, in English, for example an application server), for example by using a network slice configured for this purpose, or a default path.
  • a first identifier can be the subject of a parameter subsequently called SOLACE, for “Optimized Slicing A LA Carte”.
  • the terminal thus provides at least one first service instance with one or more first identifiers to be used to facilitate the identification of the network slice that the data associated with said at least one service intended for the terminal are authorized to use.
  • a service instance can be embedded in a remote terminal.
  • the terminal can thus receive a message comprising the data associated with said at least one service.
  • data is routed via at least one network slice selected by an edge node of the communication network by applying at least one traffic classification rule known to the edge node (for example previously configured in the edge node following the reception of said at least one rule from a controller).
  • the terminal communicates to a service instance a key taking the form of a first identifier intended for the classification of the traffic.
  • the service instance can insert this key in the return traffic to the terminal, directly or in a modified form.
  • This key can be extracted from the return traffic by an edge node of the communication network through which the return traffic passes, when it is directly inserted in the return traffic to the terminal or when a signaling protocol is used between a service instance and the communication network via a typically edge node, or be deduced or reconstructed by the edge node, when it is inserted in a modified form in the return traffic to the terminal (for example in the form of a digest).
  • the edge node can thus identify at least one network slice or a type of network slice associated with this key, without having to inspect the data (for example the content of the service considered, which can be encrypted) and select the network slice or a type of network slice to be used to route the data to the terminal.
  • the border node is a node that advertises the IP prefixes allocated to the various devices in the communication network.
  • the term "border node” is used here and throughout the rest of the document to designate a node at the edge of the network, for example of the "Autonomous System Border Router” or ASBR type, or a node at the edge of the network, for example of the "Provider Edge (router)" or PE type, in an IP/MPLS network.
  • the communication network (or more precisely the network edge node) thus knows which network slice(s) it can use to route traffic to the terminal.
  • traffic classification rules can be described in a traffic classification table, or algorithmically for example. No assumptions are made as to how the traffic classification rules are described.
  • this classification of network slices or types of network slices associated with forward and/or return traffic may be based on service logic (which may be integrated into the application embedded in the terminal) and/or decided by the network (for example by network equipment).
  • the classification may also be the subject of a decision taken by the terminal (for example, according to the choices and instructions of the terminal user).
  • the transmission mode can be negotiated during the phase of establishing a connection to a network slice between the terminal and the communication network.
  • the method implements the transmission, by the terminal, of a first indicator signaling that the terminal is able to implement a collaborative procedure for routing data associated with said at least one service and to said terminal based on the processing of said at least one first identifier.
  • This collaborative procedure is called SOLACE.
  • such a first indicator may be provided globally (e.g. when the terminal connects to the network) or when a network slice is activated.
  • the terminal implements the reception of a second indicator signaling that the provider of the network slices is able to implement a collaborative SOLACE procedure for the routing of data associated with said at least one service and to said terminal based on the processing of said at least one first identifier (SOLACE).
  • Such a second indicator is also noted as “Collaborative-Solace-Capable” subsequently.
  • the valuation of this parameter to "1" indicates for example that the said network supports the process described above.
  • said obtaining comprises obtaining at least one first identifier per network to which said terminal is connected.
  • a first different identifier per network can be obtained (for example a first tag TAG1 for the processing of data sent to the terminal by the service instance via the 5G network, and a second tag TAG2 for the processing of data sent to the terminal by the service instance via the Wi-Fi® network).
  • said method comprises transmitting, to the first service instance, at least one traffic classification rule.
  • the terminal explicitly indicates the destination address corresponding to each network to which it is connected.
  • the terminal can transmit several first identifiers each corresponding to at least one address of the terminal in the network concerned.
  • the application of the traffic classification rules allows the data associated with the service that the terminal wishes to access to be correctly routed via the network in which the terminal is identified by the corresponding destination address.
  • the use of an identifier different from that associated with a given network implies incorrect application of the classification rule for data sent by a service instance. The data sent by the service instance may then be rejected instead of being routed to the terminal.
  • classification rules can also take into account a destination port number.
  • the method implements a prior selection of said at least one first service instance authorized to receive said at least one first identifier.
  • the terminal can thus set up a selection procedure to choose the service or service instance authorized to receive the first identifier intended for the classification of traffic intended for the terminal.
  • the invention in another embodiment, relates to a terminal suitable for implementing the method of accessing at least one service described above.
  • a terminal suitable for implementing the method of accessing at least one service described above.
  • Such a terminal can of course have the various characteristics relating to the method of accessing at least one service according to the invention, which can be combined or considered in isolation.
  • the characteristics and advantages of this terminal are the same as those of the method and are not detailed further.
  • Such a method can in particular be implemented by a network controller, for example an SDN (“Software-Defined Networking”) controller.
  • a network controller for example an SDN (“Software-Defined Networking”) controller.
  • such a controller obtains at least a first identifier of the traffic destined for the terminal.
  • a first identifier can be generated by a SMF (“Session Manager Function”).
  • the first identifier can be generated by the controller.
  • the controller transmits the first identifier to the terminal, directly or via at least one intermediate router, for example a CPE.
  • the controller can also transmit to at least one edge node of the communication network at least one traffic classification rule, for example making it possible to associate said at least one first identifier with at least one network slice.
  • the second controller can in particular receive said at least one traffic classification rule from the first controller.
  • rules can be configured in the edge node, or transmitted in the form of an algorithm intended to be implemented by the edge node.
  • the controller can also transmit to the edge node(s) instructions specifying whether the identifier(s) (first identifier or second identifier) that an edge node receives from a service instance must be removed or maintained in the message comprising the data that will be transmitted via the selected network slice.
  • the method comprises transmitting said at least one first identifier to at least one other terminal connected to said communications network.
  • the same first identifier can be negotiated with several terminals. It is thus possible to share the traffic classification rules maintained by the edge nodes.
  • the invention in another embodiment, relates to a controller adapted to implement the method for controlling the provision of at least one service described above.
  • a controller can of course have the different characteristics relating to the method for controlling the provision of at least one service according to the invention, which can be combined or considered in isolation.
  • the characteristics and advantages of this controller are the same as those of the method and are not detailed further.
  • said data being intended to be routed via at least one network slice associated with said at least one first identifier
  • said at least one network slice being selected by said border node by applying at least one traffic classification rule known to said border node
  • said at least one second identifier being a function of said at least one first identifier.
  • Such a method may in particular be implemented by a service instance, which provides the service that the terminal wishes to access.
  • a service instance is an application server hosted by the service provider or another infrastructure.
  • such a service instance receives at least a first identifier, coming from the terminal (directly or via an intermediate router).
  • the first service instance can then return, to the terminal, a message containing the data associated with the service and at least a second identifier, a function of said first identifier.
  • a second identifier corresponds either to a first identifier received from the terminal, or to a new identifier obtained from a first identifier received from the terminal.
  • a second identifier is obtained by applying a hash function to a first identifier.
  • Other functions can be used, as long as they allow the two identifiers to be linked: the second identifier must be obtainable from the first identifier, and the first identifier must be found from the second identifier.
  • This message passes through an edge node that provides access to the terminal.
  • the edge node extracts the second identifier(s). If the second identifier matches a first identifier, the edge node identifies the network slice(s), or network slice type(s), associated with that first identifier. If the second identifier is obtained by applying a function distinct from an identity function to a first identifier, the edge node retrieves the first identifier, and identifies the network slice(s) associated with that first identifier, and the corresponding traffic classification rules.
  • the edge node may then relay the data to the terminal via the network slice(s), or type(s) of network slice(s) thus selected according to the application of traffic classification rules.
  • the edge node may remove the second identifier(s) from the message before transmitting the data to the terminal.
  • the method comprises receiving at least one traffic classification rule for routing data associated with said at least one first identifier, and storing said at least one traffic classification rule and said at least one associated first identifier.
  • Such a step is notably implemented when several first identifiers are communicated to the service instance, for example a first identifier A corresponding to a first address of the terminal and a first identifier B corresponding to a second address of the same terminal.
  • the first service instance receives at least two first identifiers each associated with at least one network slice and applies at least one traffic classification rule to select one of the first identifiers.
  • the service instance may select a first identifier associated with a network slice of type URLLC, rather than a first identifier associated with an EMBB network slice.
  • the first service instance implements the transmission of the message comprising said at least one second identifier and data associated with said at least one service to at least one second service instance capable of providing said at least one service.
  • a single service can thus involve a plurality of service instances, without requiring the terminal to transmit the first identifier(s) of the traffic to the service instances. This avoids unnecessary consumption of communication network resources.
  • Traffic classification rules resulting from the completeness of the SOLACE procedure can thus be synchronized between multiple service instances.
  • the invention relates to a service instance capable of implementing the method for providing at least one service described above.
  • a service instance can of course have the different characteristics relating to the method for providing at least one service according to the invention, which can be combined or considered in isolation.
  • the characteristics and advantages of this service instance are the same as those of the method and are not detailed further.
  • Such a method can in particular be implemented in an edge node of the communication network.
  • such an edge node can thus receive at least a second identifier and data associated with the service that the terminal wishes to access.
  • the edge node can in particular extract the second identifier(s), corresponding either to the first identifier(s) or to a function of the first identifier(s). In the latter case, the edge node can implement an inverse function to find the first identifier(s).
  • the edge node can then apply a traffic classification rule to check whether a network slice, or a type of network slice, is associated with this or these first identifier(s). If so, the data can be transmitted to the terminal via the network slice or the type of network slice thus identified. Otherwise, the data is not transmitted to the terminal or it is transmitted via a default path, or a route determined according to a classic IP routing scheme for example, which does not necessarily rely on the use of network slices.
  • the message received from the service instance may include the first identifier(s), encoded in a single field or in several fields, explicitly or implicitly.
  • the message In explicit mode, the message directly carries the first identifier(s).
  • the message In implicit mode, the message carries information (second identifiers) allowing the first identifier(s) to be found.
  • the edge node may remove the second identifier(s) from the message before transmitting the data to the terminal.
  • the invention relates to an edge node adapted to implement the method for managing access to at least one service described above.
  • an edge node can of course have the different characteristics relating to the method for managing access to at least one service according to the invention, which can be combined or considered in isolation.
  • the characteristics and advantages of this edge node are the same as those of the method and are not detailed further.
  • said at least one first identifier is associated with a validity period.
  • a first identifier may change over time.
  • said at least one second identifier may be associated with a validity period, identical to or different from that associated with the first identifier from which the second identifier is constructed.
  • said at least one first identifier may be associated with a security key, for example a token or a random number.
  • a random or pseudo-random number unique to a terminal, is also communicated to the terminal with the first identifier(s)/tag(s).
  • a security key can be used for authorization purposes. This improves the robustness of the process and prevents a terminal from using an identifier communicated to another terminal.
  • At least one of said network slices may be composed of at least one local network slice deployed in at least one subnetwork of the communication network (for example in an access network, a collection network, a core network, a transit network).
  • the invention further relates to at least one computer program comprising instructions for implementing at least one of the methods described above, when this or these programs are executed by a processor, as well as to at least one computer-readable information medium comprising instructions of at least one computer program as mentioned above.
  • the method according to the invention can be implemented in various ways, in particular in wired form or in software form.
  • the general principle of the invention is based on the use of one or more first identifiers (tags) intended for the classification of traffic destined for a terminal, to identify the network slice that traffic destined for a terminal is authorized to use.
  • This principle is part of a context where a terminal wishes to access at least one service via a communication network implementing network slices.
  • an edge node of the communication network can identify the network slice(s) via which the return traffic (i.e. destined for the terminal) must be routed, without having to inspect the data associated with the service considered.
  • the proposed solution offers, according to at least one embodiment, a mechanism for automatic and secure discovery of network slices deployed (or instantiated) on a fixed and/or mobile infrastructure and reserved for a certain use, for example the retransmission of a sporting or musical event.
  • the terminal does not control access to the network slice(s) used to route the data associated with the service in question and does not thus allow benefiting from the resources of the network slice that optimizes the quality of the service in question, as it can be perceived by the user of the terminal, in particular.
  • the terminal therefore does not have the means to verify that the network slice to which the service instance connects is the one that implements a traffic routing policy optimized for the service in question and as subscribed to by the customer.
  • the invention proposes a solution to this problem.
  • Such a system comprises a terminal UE 11 (“User Equipment” in English) wishing to access at least one service via a communication network SSP 12 (“Slice Service Provider” in English, or service provider based on network slices) implementing network slices, for example two network slices Sl. #1 161 and Sl. #2 162 (“Slice” in English).
  • UE 11 User Equipment
  • SSP 12 Session Service Provider
  • Terminal 11 may optionally be connected to network 12 via an intermediate router, for example a CPE.
  • an intermediate router for example a CPE.
  • the service may be provided by at least one service instance, for example by two service instances SFI #1 131 and SFI #2 132.
  • a service instance may be connected to the network 12 via a network edge node.
  • the first instance 131 is connected to the network 12 via the first border node BR 141 (“Border Router”), and the second instance 132 is connected to the network 12 via the second border node BR 142.
  • the service instances are not necessarily directly connected to the edge nodes.
  • At least one network controller 15 may be used to transmit to at least one edge node of the network 12 (for example in the edge nodes 141 and 142) traffic classification rules (for example in algorithmic form, or in the form of at least one traffic classification table, or in any other form).
  • the controller 15 may also transmit to the terminal 11 the first identifier(s) (also called “tags”) of the traffic destined for the terminal.
  • the controller 15, or the edge node may maintain at least one traffic classification rule, making it possible to associate a first identifier of the traffic with at least one network slice. It is noted that the configuration of the edge nodes and the terminals may be carried out by separate network entities.
  • the controller 15 obtains during a step 151 at least one first TAG identifier intended for the classification of traffic to the terminal 11.
  • a first identifier is associated with at least one network slice or one type of network slice.
  • the controller maintains a traffic classification rule according to which the first TAG identifier #1 is associated with the network slice Sl #1.
  • said at least one first TAG identifier is transmitted to the terminal 11, directly or via at least one intermediate router.
  • the controller 15 transmits, to at least one edge node of the communication network, for example the BR1 node 141, at least one traffic classification rule for selecting at least one network slice intended to route to the terminal data associated with said at least one service.
  • at least one edge node of the communication network for example the BR1 node 141
  • at least one traffic classification rule for selecting at least one network slice intended to route to the terminal data associated with said at least one service.
  • rules can be configured in the edge node, or implemented by the execution of an algorithm known to the edge node (received from a controller).
  • step 153 can be implemented before steps 151 and/or 152.
  • the transmission of the traffic classification rules to the border node can be implemented before or after having transmitted said at least one first TAG identifier to the terminal 11.
  • step 153 can be implemented by another controller.
  • the terminal 11 therefore receives said at least one first TAG identifier, from the controller 15, directly or via at least one intermediate router.
  • the terminal 11 transmits said at least one first TAG identifier to at least one first service instance capable of providing the service in question, for example to the first service instance SFI #1 131.
  • the first service instance 131 therefore receives said at least one first TAG identifier.
  • the first service instance 131 transmits, via at least one border node, for example the first border node BR 141, a message MSG1 comprising at least a second identifier and data D associated with the service considered.
  • This data D is intended for the terminal 11.
  • the second identifier is equal to the first identifier TAG.
  • the first identifier is used to calculate a second identifier which can be included in said message.
  • the second identifier is obtained by applying a hash function “Hash” to the first identifier.
  • the second identifier is equal to the first TAG identifier.
  • the message MSG1 sent by the first service instance 131 therefore comprises said at least one first TAG identifier and the data D.
  • the first border node 141 therefore receives the message MSG1 from the first service instance 131 comprising said at least one first TAG identifier and the data D.
  • the first border node 141 checks whether at least one network slice is associated with said at least one first TAG identifier by applying at least one traffic classification rule known to the first border node 141 (for example configured during a step 1411), and selects said at least one corresponding network slice.
  • the first border node 141 transmits the data D associated with the service considered on said at least one selected network slice.
  • the first border node 141 can retransmit to the terminal 11 the message MSG1 comprising said at least one first TAG identifier and the data D as received from the first service instance 131, or delete said at least one first TAG identifier to send only the data D to the terminal 11 in a message MSG1’.
  • the terminal 11 therefore receives the message MSG1’ comprising the data D routed via at least one network slice associated with said at least one first TAG identifier.
  • a network slice of the communication network can be associated with other network slices to provide value-added services.
  • a service provider can rely on slices set up in different subnetworks to provide a service whose traffic is intended to be routed in the "global" network slice composed of slices deployed in the different subnetworks. This is called a “multi-domain slice” (or “stitched slices” or “hierarchical slices” in English).
  • Such a network slice can indeed reflect a hierarchical structure.
  • the SSP network 12 may be composed of several subnetworks 121, 122 and 123. Each subnetwork may support one or more network slices.
  • the first subnetwork 121 supports four network slices
  • the second subnetwork 122 supports three network slices
  • the third subnetwork 123 supports four network slices.
  • the first network slice Sl. #1 161 of the communication network is for example composed of the network slices Sl. #3 deployed on the subnetwork 121, Sl. #2 deployed on the subnetwork 122 and Sl. #2 deployed on subnet 123.
  • connection interfaces between adjacent slices are for example managed using the mechanisms described in the document "YANG Data Models for 'Attachment Circuits'-as-a-Service (ACaaS)" by M. Boucadair et al., version 6 published on May 3, 2023.
  • each subnetwork may be associated with a distinct domain (for example, a communications network may consist of an access network, a collection network, a core network, and a transit network).
  • a communications network may consist of an access network, a collection network, a core network, and a transit network).
  • Each of these domains supports network slices whose engineering and operation are characteristic of the domain (for example, a slice deployed on a 5G mobile core network may use traffic processing and operating functions characteristic of a 5G mobile core network).
  • each domain access, collection, core, transit, etc.
  • each domain may exploit different technologies deployed in this domain for the realization of the network slices.
  • a first domain associated with the first subnet 121 sets up IPsec tunnels which are used to route traffic in the slices deployed in this domain
  • a second domain associated with the second subnet 122 uses network-level virtual private network engineering (Layer 3 VPN or L3VPN) combined with traffic engineering mechanisms ("Traffic Engineering” or TE in English) to route traffic in the slices deployed in this domain
  • a third domain associated with the third subnet 123 uses the resources of segment routing based on the IPv6 protocol (“Segment Routing IPv6" or SRv6 in English) to route traffic in the slices deployed in this domain.
  • a network slice in a mobile network may be based on the implementation of network slices in the following different subnetworks/segments: Radio Access Network (RAN), Core Network (CN) and Transport Network (TN).
  • RAN Radio Access Network
  • CN Core Network
  • TN Transport Network
  • the association between a network slice, for example a 5G network slice in the case of a latest generation mobile network, and the network slices deployed in each of the segments/subnetworks composing the 5G mobile network is performed in the control plane and at the edge of each of the RAN, CN and TN networks.
  • the network slice deployed in the TN network is sometimes called an “IETF Network Slice”.
  • no assumption is made as to the nature of the network slices, their number, and the "mapping" between network slices of neighboring domains (e.g. RAN and TN, TN and CN).
  • neighboring domains e.g. RAN and TN, TN and CN.
  • the same network slice can be used to aggregate traffic from one or more services.
  • a first service S1 served by one or more service instances 51 can be provided to a first client UE1 via a network slice Sl.
  • a second service S2 served by one or more service instances 52 can be provided to a second client UE2 via the same network slice Sl.
  • a third service S3 served by one or more service instances 53 can be provided to the second client UE2 via the same network slice Sl. #3 of the SSP network.
  • a network slice may involve one or more service functions (or “Service Functions” in English, according to the terminology used by RFC7665 - “Service Function Chaining (SFC) Architecture” by J. Halpern et al. published in October 2015, or "Network Functions” such as gNB (“gNodeB”) or UPF ("User Plane Functions”) according to the terminology used by 3GPP).
  • SFC Service Function Chaining
  • a single service function may be provided by one or more service instances.
  • a service instance may be hosted by the SSP (e.g. service instances 63 and 64) or within another infrastructure (e.g. service instance 65).
  • service chains (“Service Function Chain” or SFC in English) can be set up in order to facilitate the routing of traffic of different nature and having different profiles for the needs of the realization of a network slice or within a network slice (for example the service instances 611, 612 and 613 of the ).
  • the terminal 11 and the SSP 12 exchange messages to ensure that they both support the SOLACE procedure (“Slicing Optimisé A LA Carte”).
  • the terminal 11 values a first indicator or parameter noted “Collaborative-Solace-Capable” at a given value, for example “1”, to indicate to the SSP 12 that it is able to implement a collaborative procedure for routing data associated with at least one service which the terminal wishes to access and intended for the terminal, based on the processing of at least one identifier (tag) intended for the classification of traffic intended for the terminal.
  • a first indicator or parameter noted “Collaborative-Solace-Capable” at a given value for example “1”
  • This indication of support for the SOLACE procedure can be provided globally or when activating each network slice.
  • the SSP 12 If the SSP 12 supports the SOLACE procedure, it returns a second indicator or parameter “Collaborative-Solace-Capable” set to a given value, for example “1”, to indicate to the terminal 11 that it is capable of implementing a collaborative procedure for routing data associated with at least one service which the terminal wishes to access and to the terminal, based on the processing of at least one identifier (tag).
  • a second indicator or parameter “Collaborative-Solace-Capable” set to a given value, for example “1” to indicate to the terminal 11 that it is capable of implementing a collaborative procedure for routing data associated with at least one service which the terminal wishes to access and to the terminal, based on the processing of at least one identifier (tag).
  • the second indicator may be returned to the terminal 11 in response to receipt of the first indicator.
  • it is the first indicator that is returned by the terminal 11 in response to receipt of the second indicator.
  • a network controller 15 can transmit to the terminal 11 at least one identifier (tag) intended for the classification of the traffic destined for the terminal 11.
  • a tag noted for example “Inbound-Flow-Map”
  • the network controller 15 can in particular keep up to date at least one traffic classification rule associating at least one identifier of the traffic destined for the terminal, or tag, with at least one network slice.
  • the SOLACE collaborative mode can be negotiated with each of the networks to which the terminal can connect.
  • the terminal 11 can retrieve distinct tags per network to which the terminal 11 is connected.
  • a validity period or expiration may be associated with the tag.
  • a new tag (“Inbound-Flow-Map”) may be renegotiated with the network upon said expiration or upon expiration of said validity period.
  • a security key may be associated with the tag. For example, a random or pseudo-random number, or “nonce,” unique to a terminal is also communicated to the terminal with the tag(s). Such a security key may be used for authorization purposes.
  • the network controller 15 may also transmit to the edge nodes, for example to the first edge node BR 141 and to the second edge node BR 142, traffic classification rules to associate the traffic entering the edge node with the network slice(s) negotiated with the terminal 11 (and thus associate the identifier of the traffic destined for the associated terminal, or tag, with the network slice(s) negotiated with the terminal 11).
  • the terminal 11 can thus associate the return traffic of each service eligible for the operation of slices with at least one network slice, using at least one tag.
  • the return traffic of the same service can be associated with several network slices depending on the nature of the service.
  • the classification of each of these categories according to a type of network slice can be defined by the logic of the service (for example integrated into the application embedded in the terminal 11) or provided by the SSP network 12.
  • the classification of the different traffics can also be the subject of a decision taken by the terminal 11 (for example, according to the choices and instructions of the user of the terminal 11).
  • the terminal 11 can transmit one or more tags to at least one service instance capable of providing the service that the terminal wishes to access.
  • the terminal 11 uses a new parameter hereinafter called “Solace”, to transmit the tag(s) in a message that it sends to a service instance, for example to the first service instance SFI #1 131.
  • Solace parameter contains only one "Inbound-Flow-Map" tag, then this tag applies for all traffic emitted by the service instance.
  • this Solace parameter contains a list of "Inbound-Flow-Map" tags, then traffic classification rules are also provided by the terminal 11 to the service instance, so that the traffic emitted by the service instance and the associated tag can be identified.
  • the terminal 11 In a context where the terminal 11 is connected to several communication networks (context of “multihoming” for example), the terminal 11 ensures that the traffic classification rules thus generated make it possible to associate the traffic with the tag of the network intended to route said traffic.
  • the terminal 11 can be connected to a first communication network SSP1 and to a second communication network SSP2.
  • the terminal 11 can explicitly indicate, for example via the Solace parameter, its destination address in each communication network as a traffic classification rule, corresponding here to a demultiplexing parameter.
  • the new Solace parameter can be inserted into a dedicated header (e.g. HTTP header, QUIC frame) or described in characteristic messages of protocols such as SDP ("Session Description Protocol") or WebRTC.
  • a dedicated header e.g. HTTP header, QUIC frame
  • SDP Session Description Protocol
  • WebRTC WebRTC
  • the tag “156” (i.e. the identifier intended for the classification of traffic destined for the terminal) can be used by the service instance if the destination address used to send the traffic to the terminal 11 is “2001:db8::1”, while the tag “651” can be used by the service instance if the destination address used to send the traffic to the terminal 11 is “2001:db8::123”.
  • the message with the "Solace" parameter sent to a service instance is routed from terminal 11 using a network slice configured for this purpose or using a default path if no network slice is available or enabled to route traffic to that service instance.
  • the service instance Upon receipt of the message with the “Solace” parameter, the service instance checks for the presence of at least one tag (“Inbound-Flow-Map”).
  • the service instance extracts and then locally saves the traffic classification rule(s) transmitted by the terminal, as well as the associated tag(s).
  • the service instance confirms the correct implementation of the traffic classification rules.
  • This confirmation can be communicated to the terminal 11 using a dedicated acknowledgment parameter (e.g. HTTP header, QUIC frame) or described explicitly in messages characteristic of protocols such as SIP, SDP or WebRTC.
  • a dedicated acknowledgment parameter e.g. HTTP header, QUIC frame
  • the absence of an error message can also be interpreted as an implicit acknowledgment and confirmation.
  • the service instance marks the traffic with the corresponding tag.
  • the service instance can send an MSG1 message comprising one or more tags “tag” and, for each tag, the data associated with the service that the terminal wishes to access according to the traffic classification rules communicated by the terminal.
  • the tag(s) can be inserted in a UDP option, an HTTP header, a SIP header, the “Flow Label” field of an IPv6 packet header, an IPv6 extension header, etc.
  • the first service instance SFI #1 131 can forward the MSG1 message to other service instances involved in providing the service, such as the second service instance SFI #2 132.
  • This is advantageous because a single service can involve a plurality of service instances without having to repeat the phase of communication of the tags by the terminal with all the service instances.
  • This synchronization is particularly advantageous for services that use anycast addressing (i.e., the service instances can be reached from the same IP address).
  • the return traffic (from at least one service instance and destined for the terminal 11) is received by at least one border node, for example the first border node BR 141 and/or second border node BR 142.
  • the border node BR inspects, then extracts the tag(s) if necessary.
  • traffic is processed according to a default routing rule. For example, traffic is routed to terminal 11 via a default route (e.g. a route that is not established in any of the deployed network slices, or a network slice dedicated to so-called “Best Effort” traffic).
  • a default route e.g. a route that is not established in any of the deployed network slices, or a network slice dedicated to so-called “Best Effort” traffic.
  • the edge node BR 141 of the first SSP1 network receives data D1 and the identifier TAG1 from the service instance 131, and can select, from reading the traffic classification table, the network slice associated with the identifier TAG1 for routing the data D1 via the first SSP1 network, for example the network slice Sl. #3.
  • the edge node BR 842 of the second SSP2 network receives data D2 and the identifier TAG2 from the service instance 131, and can select, from reading the traffic classification table, the network slice associated with the identifier TAG2 for routing the data D2 via the second SSP2 network, for example the slice SL. #1.
  • the data D1 and D2 may be the same or different.
  • the edge node BR 141 of the first SSP1 network receives data D1 and the identifier TAG2 from the service instance 131, no entry is found in the traffic classification table.
  • the data D1 is therefore routed to the terminal 11 using a default route, or a route determined according to a classic IP routing scheme for example.
  • the BR edge node can remove the tag(s) before forwarding the data to the terminal.
  • the edge node BR checks for the presence of a security key, for example the presence of a valid “nonce” parameter associated with the terminal in question, before injecting the traffic into a network slice.
  • a security key for example the presence of a valid “nonce” parameter associated with the terminal in question.
  • the verification of the validation of the “nonce” can be performed locally or by involving a network controller, for example controller 15. The verification is not necessarily performed systematically for all packets of the MSG1 message that carry a tag and a security key.
  • the BR edge node can calculate a hash based on a first packet of the MSG1 message, and this hash can then be used to validate subsequent packets without requiring the intervention of a network controller.
  • the terminal 11 is not connected directly to the communication network, but via a connection equipment (for example a CPE or other intermediate router).
  • the connection equipment can implement the SOLACE procedure as if the terminal were directly connected to the network.
  • the CPE can negotiate with the terminal the activation of the SOLACE procedure. For example, the communication of tags to service instances is performed by the terminal.
  • the CPE inserts tags according to rules local to the CPE. These rules can be configured by the user or communicated by the terminal via a dedicated mechanism (PCP, for example).
  • PCP dedicated mechanism
  • the controller 15 can transmit the tag(s) to the CPE 10.
  • the terminal 11 can contact the CPE 10 to retrieve the tags associated with each network slice.
  • the terminal 11 uses new options that can be supported by different protocols such as PCP (Port Control Protocol), DHCP (Dynamic Host Configuration Protocol), RA (Router Advertisement message in IPv6 environment), etc., to obtain the tags.
  • PCP Port Control Protocol
  • DHCP Dynamic Host Configuration Protocol
  • RA Raster Advertisement message in IPv6 environment
  • the "Tag count” field indicates the number of tags included in the PCP option.
  • the "Traffic Selector” field can be filled in for a tag. This field describes for example the traffic classification rule eligible for marking with said tag (for example destination IP address, destination port number, protocol identifier), by a service instance, of the data associated with the service considered. If no rule is indicated, then the marking of the data with a tag is applicable to all traffic entering the service instance (i.e. to the terminal).
  • the terminal may indicate in a message to a service instance the list of network slices negotiated with the network.
  • the service instance may choose to invoke a slice distinct from the one used to route this message, for all or part of the traffic to the terminal.
  • a network slice can be deployed on a fixed infrastructure, mobile infrastructure, or a combination of the two.
  • such an entity comprises at least one memory 121 comprising a buffer memory, at least one processing unit 122, equipped for example with a programmable computing machine or a dedicated computing machine, for example a processor P, and controlled by the computer program 123, implementing steps of at least one method according to at least one embodiment of the invention.
  • the code instructions of the computer program 123 are for example loaded into a RAM memory before being executed by the processor of the processing unit 122.
  • said at least one network slice being selected by said border node by applying at least one traffic classification rule known to said border node.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

L'invention concerne un procédé d'accès à au moins un service par un terminal (11), via un réseau de communication mettant en œuvre des tranches réseau, comprenant : • l'obtention (111) d'au moins un identifiant destiné à la classification du trafic à destination dudit terminal, ledit au moins un identifiant étant associé à au moins une tranche réseau ou un type de tranche réseau, • la transmission (112) dudit au moins un identifiant à au moins une première instance de service (131) apte à fournir ledit au moins un service audit terminal, • la réception (113) d'un message comportant des données associées audit au moins un service acheminées via au moins une tranche réseau associée audit au moins un identifiant, sélectionnée par un nœud de bordure (141) dudit réseau de communication en appliquant au moins une règle de classification de trafic connue dudit nœud de bordure.

Description

Procédés d’accès à un service, procédé de fourniture de services, procédé de contrôle, procédé de gestion, terminal, instance de service, contrôleur, nœud de bordure et programmes d’ordinateur correspondants. 1. Domaine technique
Le domaine de l’invention est celui des communications au sein d’au moins un réseau de communication, et notamment celui des services IP à valeur ajoutée.
Plus précisément, l’invention concerne l’accès à au moins un service en utilisant les ressources de tranches réseau (« network slice » ou « slice » en anglais) d’un réseau de communication.
En particulier, l’invention propose une solution pour la sélection d’une ou plusieurs tranches réseau à utiliser pour tout ou partie du trafic à destination d’un terminal.
2. Art antérieur
Une tranche réseau peut être définie comme une partition du réseau telle qu’un réseau privé virtuel (RPV, ou VPN pour « Virtual Private Network » en anglais) déployé sur une infrastructure fixe, mobile, ou une combinaison des deux.
Les caractéristiques d’une tranche réseau sont principalement exprimées en termes de capacité (bande passante) et de qualité de service (par exemple latence, temps de transit unidirectionnel, etc.), voire de sécurité (par exemple préservation de la confidentialité des informations transmises au sein du RPV moyennant l’utilisation de techniques de chiffrement) et de fonctions service (« Service Functions » ou SF).
Les caractéristiques d’une tranche réseau sont par exemple présentées dans le document « A Framework for IETF Network Slices » de A. Farrel et al., version 21 publiée le 15 juin 2023.
Un exemple d’utilisation de tranches réseau déployées dans une infrastructure mobile 5G est présenté dans le document « A Realization of IETF Network Slices for 5G Networks Using Current IP/MPLS Technologies » de K. G. Szarkowicz et al., version 9 publiée le 23 mai 2023.
Classiquement, le trafic susceptible d’être acheminé au sein d’une tranche réseau fait l’objet d’une habilitation (aussi appelée contrôle d’accès) à emprunter les chemins établis au sein de ladite tranche réseau. Une telle habilitation repose typiquement sur l’application de règles de classification de trafic. Ces règles sont en général appliquées par un point d’accès au réseau au sein duquel des tranches réseau ont été déployées. Ce point d’accès est un nœud situé en périphérie du réseau et qui est généralement déployé en frontal des accès clients ou bien utilisé pour connecter un réseau à d’autres réseaux voisins. Par exemple, un tel point d’accès peut être situé à l’interface de raccordement d’une passerelle qui permet d’accéder au réseau Internet. Cette passerelle est désignée « packet gateway » pour les générations (4G, 5G) les plus récentes des réseaux mobiles. Dans ce cas, la fonction de classification de trafic pourrait être localisée à l‘interface de raccordement d’une « packet gateway » au réseau Internet. Le point d’accès peut également se situer à l’interface de raccordement d’un terminal mobile (ou « User Equipment » ou UE en anglais) au réseau d’accès radio (ou « Radio Access Network » ou RAN en anglais), de façon notamment à optimiser l’usage des ressources radio en fonction du type de la tranche réseau et du profil du trafic qu’elle est susceptible d’acheminer. Un profil de trafic est l’ensemble des caractéristiques propres au trafic. Ces caractéristiques peuvent refléter la sensibilité des applications à la latence, au délai de transit ou à la perte de paquets, mais également des pratiques d’usage, par exemple un trafic qui ne serait généré que sur une période donnée (par exemple un trafic de gestion lié à l’exécution d’une opération de maintenance d’un équipement programmée pendant la nuit). Les règles de classification et de contrôle d’admission de trafic sont donc appliquées à la périphérie du réseau.
On rappelle par ailleurs que l’organisme 3GPP a défini différents types de tranches réseau, selon leurs caractéristiques :
  • un premier type de tranches réseau permettant d’offrir un service mobile large bande amélioré (« Enhanced Mobile BroadBand » ou EMBB en anglais) ;
  • un deuxième type de tranches réseau permettant d’offrir un service dans le cadre d’un déploiement (massif) de l’Internet des Objets (« massive Internet of Things » ou mIoT en anglais) ; et
  • un troisième type de tranches réseau permettant d’offrir un service de communication ultra fiable et à faible latence (« Ultra Reliable Low Latency Communications ou URLLC en anglais).
Le choix de concevoir et de déployer l’un ou l’autre de ces types de tranche réseau est conditionné par la nature du trafic caractéristique des applications ou services utilisés ou souscrits par un utilisateur. Par exemple, un service dit « immersif » qui exploite des techniques de réalité augmentée ou virtuelle est généralement très exigeant en termes de latence et de fiabilité des échanges de données : l’utilisation de tranches de type URLLC est donc privilégiée pour un service immersif de ce type.
On note par ailleurs que les règles de classification de trafic peuvent être complexes, car le niveau de granularité associé à l’ingénierie et au déploiement d’une tranche réseau peut être macroscopique (par exemple une tranche réseau déployée pour acheminer le trafic à destination de l’Internet), ou bien microscopique (par exemple une tranche réseau déployée pour le trafic applicatif échangé entre deux terminaux mobiles).
Cette granularité génère une complexité globale de l’ingénierie des tranches réseau, par exemple une difficulté à optimiser l’usage des ressources mises en œuvre par une tranche réseau, par un ensemble de tranches réseau, ou par toutes les tranches réseau, ou une difficulté à garantir strictement l’isolation du trafic acheminé au sein d’une tranche réseau, ou encore une difficulté à garantir strictement le niveau de qualité ou de sécurité associé à une tranche réseau, voire le niveau de disponibilité et de résilience d’une tranche réseau donnée, etc.
En particulier, la complexité de la configuration et de l’application de règles de classification de trafic associées à la mise en place d’une tranche réseau donnée évolue avec la diversité des trafics, la richesse de l’organisation de la structure qui exploite la tranche réseau (par exemple un service de comptabilité, un service de R&D, un service de production) ou encore le mode d’usage de la tranche réseau (par exemple, gestion des surcharges de trafic lors des heures chargées, principes de répartition de la charge de trafic). Cette complexité peut notamment être aggravée par l’évolution des règles de classification de trafic au cours du temps (par exemple, dans le contexte du déploiement d’une tranche réseau pour la retransmission d’un événement sportif ou culturel, les règles de classification de trafic peuvent évoluer avec le nombre et le profil des utilisateurs de la tranche réseau).
Il existe donc un besoin pour une nouvelle technique d’accès à un service cherchant à améliorer l’utilisation des ressources de tranches réseau, notamment pour l’acheminement du trafic retour vers le terminal.
3. Exposé de l’invention
L’invention propose une solution ne présentant pas l’ensemble des inconvénients de l’art antérieur sous la forme d’un procédé d’accès à au moins un service par un terminal, via un réseau de communication mettant en œuvre des tranches réseau, comprenant :
  • l’obtention d’au moins un premier identifiant destiné à la classification du trafic à destination dudit terminal, ledit au moins un premier identifiant étant associé à au moins une tranche réseau ou un type de tranche réseau,
  • la transmission dudit au moins un premier identifiant à au moins une première instance de service apte à fournir ledit au moins un service audit terminal,
  • la réception d’un message comportant des données associées audit au moins un service acheminées via au moins une tranche réseau associée audit au moins un premier identifiant, sélectionnée par un nœud de bordure dudit réseau de communication en appliquant au moins une règle de classification de trafic connue dudit nœud de bordure.
Un tel procédé peut notamment être mis en œuvre par un terminal connecté au réseau de communication.
Un tel terminal obtient au cours d’une première étape au moins un premier identifiant destiné à la classification du trafic à destination du terminal. Un tel premier identifiant, également appelé tag par la suite, est par exemple noté « inbound_flow_map » dans un mode de réalisation de l’invention. Il peut être associé à une tranche réseau ou à un type de tranche réseau (par exemple EMBB, mIoT ou URLLC si l’on considère un réseau 5G). Un tel premier identifiant du trafic à destination du terminal est différent d’un identifiant de tranche réseau utilisé par un équipement pour se connecter à une tranche réseau : cet autre identifiant de tranche réseau est par exemple de type NSSAI 3GPP. Un tel premier identifiant du trafic à destination du terminal est par exemple généré par un gestionnaire du réseau, mettant par exemple en œuvre une fonction de gestion de session (« Session Manager Function » ou SMF en anglais) ou un contrôleur réseau.
Le premier identifiant destiné à la classification du trafic à destination du terminal peut notamment être reçu directement du gestionnaire SMF ou d’un contrôleur réseau, ou via à routeur intermédiaire, par exemple un CPE (« Customer Premises Equipment ») ou un autre équipement de raccordement au réseau. Notamment, un tel premier identifiant peut être inséré dans un en-tête dédié (par exemple un en-tête HTTP, une trame QUIC) ou décrit dans des messages formatés selon des protocoles comme SIP (« Session Initiation Protocol »), SDP (« Session Description Protocol ») ou WebRTC.
Au cours d’une deuxième étape, le terminal transmet ledit au moins un premier identifiant à au moins une première instance de service (« Service Function Instance », en anglais, par exemple un serveur d’application), par exemple en utilisant une tranche réseau configurée à cet effet, ou un chemin par défaut. En particulier, un tel premier identifiant peut faire l’objet d’un paramètre appelé par la suite SOLACE, pour « Slicing Optimisé A LA CartE ». Le terminal fournit ainsi à au moins une première instance de service un ou plusieurs premiers identifiants à utiliser pour faciliter l’identification de la tranche réseau que les données associées audit au moins un service à destination du terminal sont habilitées à emprunter. On note qu’une instance de service peut être embarquée dans un terminal distant.
Au cours d’une troisième étape, le terminal peut ainsi recevoir un message comportant les données associées audit au moins un service. De telles données sont acheminées via au moins une tranche réseau sélectionnée par un nœud de bordure du réseau de communication en appliquant au moins une règle de classification de trafic connue du nœud de bordure (par exemple préalablement configurée dans le nœud de bordure suite à la réception de ladite au moins une règle en provenance d’un contrôleur).
De cette façon, le terminal communique à une instance de service une clé prenant la forme d’un premier identifiant destiné à la classification du trafic. Par exemple, l’instance de service peut insérer cette clé dans le trafic retour à destination du terminal, directement ou sous une forme modifiée. Cette clé peut être extraite du trafic retour par un nœud de bordure du réseau de communication par lequel transite le trafic retour, lorsqu’elle est directement insérée dans le trafic retour à destination du terminal ou lorsqu’un protocole de signalisation est utilisé entre une instance de service et le réseau de communication via un nœud de bordure typiquement, ou bien être déduite ou reconstruite par le nœud de bordure, lorsqu’elle est insérée sous une forme modifiée dans le trafic retour à destination du terminal (par exemple sous la forme d’un condensé). Le nœud de bordure peut ainsi identifier au moins une tranche réseau ou un type de tranche réseau associée à cette clé, sans avoir à inspecter les données (par exemple le contenu du service considéré, qui peut être chiffré) et sélectionner la tranche réseau ou un type de tranche réseau à utiliser pour acheminer les données vers le terminal. Par exemple, le nœud de bordure est un nœud qui annonce les préfixes IP alloués aux différents équipements du réseau de communication. On utilise ici et dans toute la suite du document le terme « nœud de bordure » pour désigner un nœud en bordure du réseau, par exemple de type « Autonomous System Border Router », ou ASBR, ou un nœud en périphérie du réseau, par exemple de type « Provider Edge (router) », ou PE, dans un réseau IP/MPLS.
Le réseau de communication (ou plus précisément le nœud de bordure du réseau) sait ainsi quelle(s) tranche(s) réseau il peut utiliser pour acheminer le trafic vers le terminal.
On note que les règles de classification de trafic peuvent être décrites dans une table de classification de trafic, ou algorithmiquement par exemple. Aucune hypothèse n’est faite quant à la manière dont les règles de classification de trafic sont décrites.
Dans un mode de réalisation particulier, ladite au moins une tranche réseau ou ledit type de tranche réseau est associé à un mode de transmission appartenant au groupe comprenant :
  • l’acheminement de données à destination du terminal,
  • l’acheminement de données en provenance du terminal,
  • l’acheminement de données à destination du terminal et en provenance du terminal.
Par exemple, cette classification des tranches réseau ou des types de tranches réseau associés au trafic aller et/ou retour peut reposer sur une logique du service (qui peut être intégrée dans l’applicatif embarqué dans le terminal) et/ou décidée par le réseau (par exemple par un équipement du réseau). La classification peut également faire l’objet d’une décision prise par le terminal (par exemple, selon les choix et instructions de l’utilisateur du terminal).
Le mode de transmission peut être négocié lors de la phase d’établissement d’une connexion à une tranche réseau entre le terminal et le réseau de communication.
Dans un mode de réalisation particulier, le procédé met en œuvre la transmission, par le terminal, d’un premier indicateur signalant que le terminal est apte à mettre en œuvre une procédure collaborative pour l’acheminement des données associées audit au moins un service et à destination dudit terminal reposant sur le traitement dudit au moins un premier identifiant. Cette procédure collaborative est appelée SOLACE.
Par exemple, un tel premier indicateur est noté « Collaborative-Solace-Capable » par la suite. La valorisation de ce paramètre à « 1 » indique par exemple que le terminal supporte le procédé décrit ci-dessus.
En particulier, un tel premier indicateur peut être fourni globalement (par exemple lorsque le terminal se connecte au réseau) ou lors de l’activation d’une tranche réseau.
Dans un mode de réalisation particulier, le terminal met en œuvre la réception d’un deuxième indicateur signalant que le fournisseur des tranches réseau est apte à mettre en œuvre une procédure collaborative SOLACE pour l’acheminement des données associées audit au moins un service et à destination dudit terminal reposant sur le traitement dudit au moins un premier identifiant (SOLACE).
Par exemple, un tel deuxième indicateur est également noté « Collaborative-Solace-Capable » par la suite. La valorisation de ce paramètre à « 1 » indique par exemple que ledit réseau supporte le procédé décrit ci-dessus.
Selon une caractéristique particulière, ladite obtention comprend l’obtention d’au moins un premier identifiant par réseau auquel ledit terminal est connecté.
Par exemple, si le terminal est connecté à une instance de service via différents réseaux (par exemple en 5G et en Wi-Fi®), un premier identifiant différent par réseau peut être obtenu (par exemple un premier tag TAG1 pour le traitement des données envoyées vers le terminal par l’instance de service via le réseau 5G, et un deuxième tag TAG2 pour le traitement de données envoyées vers le terminal par l’instance de service via le réseau Wi-Fi®).
Dans un mode de réalisation particulier, ledit procédé comprend la transmission, à la première instance de service, d’au moins une règle de classification de trafic.
Par exemple, dans un contexte de « multihoming » selon lequel le terminal est connecté à plusieurs réseaux, le terminal indique explicitement l’adresse destination correspondant à chaque réseau auquel il est connecté. En d’autres termes, le terminal peut transmettre plusieurs premiers identifiants correspondant chacun à au moins une adresse du terminal dans le réseau concerné. L’application des règles de classification de trafic permet que les données associées au service auquel le terminal souhaite accéder soient correctement acheminées via le réseau dans lequel le terminal est identifié par l’adresse destination correspondante. L’utilisation d’un identifiant différent de celui associé à un réseau donné implique une mauvaise application de la règle de classification des données envoyées par une instance de service. Les données envoyées par l’instance de service risquent alors d’être rejetées au lieu d’être acheminées vers le terminal.
Dans un autre exemple, les règles de classification peuvent également tenir compte d’un numéro de port destination.
Dans un mode de réalisation particulier, le procédé met en œuvre une sélection préalable de ladite moins une première instance de service habilitée à recevoir ledit au moins un premier identifiant.
Le terminal peut ainsi mettre en place une procédure de sélection pour choisir le service ou l’instance de service habilitée à recevoir le premier identifiant destiné à la classification du trafic à destination du terminal.
Dans un autre mode de réalisation, l’invention concerne un terminal adapté à mettre en œuvre le procédé d’accès à au moins un service décrit précédemment. Un tel terminal peut bien sûr présenter les différentes caractéristiques relatives au procédé d’accès à au moins un service selon l’invention, qui peuvent être combinées ou considérées isolément. Ainsi, les caractéristiques et avantages de ce terminal sont les mêmes que ceux du procédé et ne sont pas détaillés plus amplement.
L’invention concerne par ailleurs un procédé de contrôle de la fourniture d’au moins un service à un terminal, via un réseau de communication mettant en œuvre des tranches réseau, comprenant :
  • l’obtention d’au moins un premier identifiant destiné à la classification du trafic à destination dudit terminal, ledit au moins un premier identifiant étant associé à au moins une tranche réseau ou un type de tranche réseau,
  • la transmission dudit au moins un premier identifiant audit terminal, directement ou via au moins un routeur intermédiaire,
  • la transmission, à au moins un nœud de bordure dudit réseau de communication, d’au moins une règle de classification de trafic pour la sélection d’au moins une tranche réseau destinée à acheminer vers ledit terminal des données associées audit au moins un service.
Un tel procédé peut notamment être mis en œuvre par un contrôleur réseau, par exemple un contrôleur SDN (« Software-Defined Networking »).
Au cours d’une première étape, un tel contrôleur obtient au moins un premier identifiant du trafic à destination du terminal. Comme indiqué précédemment, un tel premier identifiant peut être généré par une SMF (« Session Manager Function »). Éventuellement, le premier identifiant peut être généré par le contrôleur.
Au cours d’une deuxième étape, le contrôleur transmet le premier identifiant au terminal, directement ou via au moins un routeur intermédiaire, par exemple un CPE.
Le contrôleur (premier contrôleur), ou un autre contrôleur (deuxième contrôleur), peut également transmettre à au moins un nœud de bordure du réseau de communication au moins une règle de classification de trafic, permettant par exemple d’associer ledit au moins un premier identifiant à au moins une tranche réseau. Le deuxième contrôleur peut notamment recevoir ladite au moins une règle de classification de trafic en provenance du premier contrôleur. Par exemple, de telles règles peuvent être configurées dans le nœud de bordure, ou transmises sous la forme d’un algorithme destiné à être mis en œuvre par le nœud de bordure.
Selon un mode de réalisation particulier, le contrôleur peut également transmettre au(x) nœud(s) de bordure des consignes spécifiant si le ou les identifiants (premier identifiant ou deuxième identifiant) qu’un nœud de bordure reçoit en provenance d’une instance de service doivent être retirés ou maintenus dans le message comportant les données qui seront transmises via la tranche réseau sélectionnée.
Dans un mode de réalisation particulier, le procédé comprend la transmission dudit au moins un premier identifiant à au moins un autre terminal connecté audit réseau de communication.
De cette façon, un même premier identifiant peut être négocié avec plusieurs terminaux. Il est ainsi possible de mutualiser les règles de classification de trafic maintenues par les nœuds de bordure.
Dans un autre mode de réalisation, l’invention concerne un contrôleur adapté à mettre en œuvre le procédé de contrôle de la fourniture d’au moins un service décrit précédemment. Un tel contrôleur peut bien sûr présenter les différentes caractéristiques relatives au procédé de contrôle de la fourniture d’au moins un service selon l’invention, qui peuvent être combinées ou considérées isolément. Ainsi, les caractéristiques et avantages de ce contrôleur sont les mêmes que ceux du procédé et ne sont pas détaillés plus amplement.
L’invention concerne par ailleurs un procédé de fourniture d’au moins un service à un terminal, via un réseau de communication mettant en œuvre des tranches réseau, comprenant :
  • la réception d’au moins un premier identifiant destiné à la classification du trafic à destination dudit terminal, ledit au moins un premier identifiant étant associé à au moins une tranche réseau ou un type de tranche réseau,
  • la transmission, via au moins un nœud de bordure dudit réseau de communication, d’un message comportant au moins un deuxième identifiant et des données associées audit au moins un service,
lesdites données étant destinées à être acheminées via au moins une tranche réseau associée audit au moins un premier identifiant,
ladite au moins une tranche réseau étant sélectionnée par ledit nœud de bordure en appliquant au moins une règle de classification de trafic connue dudit nœud de bordure, et
ledit au moins un deuxième identifiant étant fonction dudit au moins un premier identifiant.
Un tel procédé peut notamment être mis en œuvre par une instance de service, qui fournit le service auquel souhaite accéder le terminal. Par exemple, une telle instance de service est un serveur applicatif hébergé par le fournisseur de services ou une autre infrastructure.
Ainsi, au cours d’une première étape, une telle instance de service, dite première instance de service, reçoit au moins un premier identifiant, en provenance du terminal (directement ou via un routeur intermédiaire).
La première instance de service peut alors renvoyer, à destination du terminal, un message comportant les données associées au service et au moins un deuxième identifiant, fonction dudit premier identifiant.
En d’autres termes, un deuxième identifiant correspond soit à un premier identifiant reçu du terminal, soit à un nouvel identifiant obtenu à partir d’un premier identifiant reçu du terminal. Par exemple, un deuxième identifiant est obtenu en appliquant une fonction de hachage (« hash » en anglais) à un premier identifiant. D’autres fonctions peuvent être utilisées, tant qu’elles permettent de lier les deux identifiants : le deuxième identifiant doit pouvoir être obtenu à partir du premier identifiant, et le premier identifiant retrouvé à partir du deuxième identifiant.
Ce message transite via un nœud de bordure qui permet d’accéder au terminal. Le nœud de bordure extrait le ou les deuxièmes identifiants. Si le deuxième identifiant correspond à un premier identifiant, le nœud de bordure identifie la ou les tranches réseau, ou type(s) de tranches réseau, associé(e)s à ce premier identifiant. Si le deuxième identifiant est obtenu en appliquant une fonction distincte d’une fonction identité à un premier identifiant, le nœud de bordure retrouve le premier identifiant, et identifie la ou les tranches réseau associée(s) à ce premier identifiant, et les règles de classification de trafic correspondantes.
Le nœud de bordure peut alors relayer les données au terminal via la ou les tranches réseau, ou type(s) de tranches réseau ainsi sélectionnée(s) selon l’application de règles de classification de trafic. Éventuellement, le nœud de bordure peut supprimer le ou les deuxièmes identifiants du message avant de transmettre les données au terminal.
Dans un mode de réalisation particulier, le procédé comprend la réception d’au moins une règle de classification de trafic pour l’acheminement des données associées audit au moins un premier identifiant, et le stockage de ladite au moins une règle de classification de trafic et dudit au moins un premier identifiant associé.
Une telle étape est notamment mise en œuvre lorsque plusieurs premiers identifiants sont communiqués à l’instance de service, par exemple un premier identifiant A correspondant à une première adresse du terminal et une premier identifiant B correspondant à une deuxième adresse du même terminal.
Dans un mode de réalisation particulier, la première instance de service reçoit au moins deux premiers identifiants associés chacun à au moins une tranche réseau et applique au moins une règle de classification de trafic pour sélectionner l’un des premiers identifiants.
Par exemple, si le service est de type immersif, l’instance de service peut sélectionner un premier identifiant associé à une tranche réseau de type URLLC, plutôt qu’un premier identifiant associé à une tranche réseau EMBB.
Dans un mode de réalisation particulier, la première instance de service met en œuvre la transmission du message comportant ledit au moins un deuxième identifiant et des données associées audit au moins un service à au moins une deuxième instance de service apte à fournir ledit au moins un service.
Un même service peut ainsi impliquer une pluralité d’instances de service, sans pour autant nécessiter la transmission, par le terminal, du ou des premiers identifiants du trafic à destination des instances de service. On évite de cette façon de consommer inutilement des ressources du réseau de communication.
Les règles de classification de trafic issues de la complétude de la procédure SOLACE peuvent ainsi être synchronisées entre plusieurs instances de service.
Dans un autre mode de réalisation, l’invention concerne une instance de service capable de mettre en œuvre le procédé de fourniture d’au moins un service décrit précédemment. Une telle instance de service peut bien sûr présenter les différentes caractéristiques relatives au procédé de fourniture d’au moins un service selon l’invention, qui peuvent être combinées ou considérées isolément. Ainsi, les caractéristiques et avantages de cette instance de service sont les mêmes que ceux du procédé et ne sont pas détaillés plus amplement.
L’invention concerne encore un procédé de gestion de l’accès à au moins un service par un terminal, via un réseau de communication, comprenant :
  • la réception d’au moins un message en provenance d’au moins une première instance de service apte à fournir ledit au moins un service, ledit message comportant au moins un deuxième identifiant, fonction d’au moins un premier identifiant destiné à la classification du trafic à destination dudit terminal et des données associées audit au moins un service,
ledit au moins un premier identifiant étant associé à au moins une tranche réseau ou un type de tranche réseau,
  • la sélection d’au moins une tranche réseau associée audit au moins un premier identifiant en appliquant au moins une règle de classification de trafic connue (reçue d’un contrôleur),
  • la transmission desdites données associées audit au moins un service sur ladite au moins une tranche réseau sélectionnée.
Un tel procédé peut notamment être mis en œuvre dans un nœud de bordure du réseau de communication.
Comme indiqué précédemment, un tel nœud de bordure peut ainsi recevoir au moins un deuxième identifiant et des données associées au service auquel le terminal souhaite accéder. Le nœud de bordure peut notamment extraire le ou les deuxièmes identifiants, correspondant soit au(x) premier(s) identifiant(s), soit à une fonction du ou des premiers identifiants. Dans ce dernier cas, le nœud de bordure peut mettre en œuvre une fonction inverse pour retrouver le ou les premiers identifiants. Le nœud de bordure peut ensuite appliquer une règle de classification de trafic pour vérifier si une tranche réseau, ou un type de tranche réseau, est associé(e) à ce ou ces premiers identifiants. Si oui, les données peuvent être transmises au terminal via la tranche réseau ou le type de tranche réseau ainsi identifié(e). Sinon, les données ne sont pas transmises au terminal ou alors elles sont transmises via un chemin par défaut, ou une route déterminée selon un schéma de routage IP classique par exemple, qui ne repose pas nécessairement sur l’utilisation de tranches réseau.
Ainsi, le message reçu de l’instance de service peut comporter le ou les premiers identifiants, encodés dans un seul champ ou dans plusieurs champs, explicitement ou implicitement. Dans le mode explicite, le message transporte directement le ou les premiers identifiants. Dans le mode implicite, le message transporte des informations (deuxièmes identifiants) permettant de retrouver le ou les premiers identifiants.
Éventuellement, le nœud de bordure peut supprimer le ou les deuxièmes identifiants du message avant de transmettre les données au terminal.
Dans un autre mode de réalisation, l’invention concerne un nœud de bordure adapté à mettre en œuvre le procédé de gestion de l’accès à au moins un service décrit précédemment. Un tel nœud de bordure peut bien sûr présenter les différentes caractéristiques relatives au procédé de gestion de l’accès à au moins un service selon l’invention, qui peuvent être combinées ou considérées isolément. Ainsi, les caractéristiques et avantages de ce nœud de bordure sont les mêmes que ceux du procédé et ne sont pas détaillés plus amplement.
Dans les différents modes de réalisation envisagés, ledit au moins un premier identifiant est associé à une durée de validité. Par exemple, un tel premier identifiant peut évoluer au cours du temps. De même, ledit au moins un deuxième identifiant peut être associée à une durée de validité, identique ou différente de celle associée au premier identifiant à partir duquel le deuxième identifiant est construit.
En particulier, ledit au moins un premier identifiant peut être associé à une clé de sécurité, par exemple un jeton (« token ») ou un nombre aléatoire (« nonce »).
Par exemple, un nombre aléatoire ou pseudo-aléatoire, unique pour un terminal, est également communiqué au terminal avec le ou les premiers identifiants / tags. Une telle clé de sécurité peut être utilisée à des fins d’autorisation. On améliore ainsi la robustesse du procédé et évite qu’un terminal utilise un identifiant communiqué à un autre terminal.
Dans les différents modes de réalisation envisagés, au moins une desdites tranches réseau peut être composée d’au moins une tranche réseau locale déployée dans au moins un sous-réseau du réseau de communication (par exemple dans un réseau d’accès, un réseau de collecte, un réseau cœur, un réseau de transit).
L’invention concerne en outre au moins un programme d’ordinateur comportant des instructions pour la mise en œuvre d’au moins un des procédés décrits ci-dessus, lorsque ce ou ces programmes sont exécutés par un processeur, ainsi qu’au moins un support d’informations lisible par un ordinateur comportant des instructions d’au moins un programme d’ordinateur tel que mentionné ci-dessus.
Le procédé selon l’invention peut être mis en œuvre de diverses manières, notamment sous forme câblée ou sous forme logicielle.
4. Liste des figures
D’autres caractéristiques et avantages de l’invention apparaîtront plus clairement à la lecture de la description suivante d’un mode de réalisation particulier, donné à titre d’exemple illustratif et non limitatif, et des dessins annexés, parmi lesquels :
  • la représente un système dans lequel l’invention peut être mise en œuvre ;
  • la illustre les principales étapes des procédés selon au moins un mode de réalisation de l’invention ;
  • la illustre les principaux messages échangés lors de la mise en œuvre des procédés selon la  ;
  • la illustre un exemple de réseau de communication composé de plusieurs sous-réseaux ;
  • la illustre un exemple d’agrégation de plusieurs services au sein d’une même tranche réseau ;
  • la illustre un exemple de déploiement de plusieurs instances de service ;
  • la présente les différentes entités intervenant dans le déroulement du mode collaboratif de la procédure SOLACE ;
  • la illustre un exemple d’association de trafic à des tranches réseau et arrivant à un nœud de bordure et à destination du terminal ;
  • la illustre un exemple de problème empêchant l’association de trafic à des tranches réseau et arrivant à un nœud de bordure ;
  • la illustre un exemple d’activation de la procédure SOLACE en présence d’un CPE ;
  • la présente un exemple d’option PCP (« Port Control Protocol ») mis en œuvre par un terminal pour obtenir au moins un premier identifiant destiné à la classification du trafic à destination du terminal et habilité à être acheminé via une tranche donnée ;
  • la présente la structure simplifiée des différentes entités selon un mode de réalisation particulier.
5. Description d’un mode de réalisation de l’invention
5.1 Principe général
Le principe général de l’invention repose sur l’utilisation d’un ou plusieurs premiers identifiants (tags, en anglais) destinés à la classification du trafic à destination d’un terminal, pour identifier la tranche réseau qu’un trafic à destination d’un terminal est habilité à emprunter. Ce principe s’inscrit dans un contexte où un terminal souhaite accéder à au moins un service via un réseau de communication mettant en œuvre des tranches réseau. De cette façon, un nœud de bordure du réseau de communication peut identifier la ou les tranches réseau via lesquelles le trafic retour (i.e. à destination du terminal) doit être acheminé, sans avoir à inspecter les données associées au service considéré.
Ainsi, la solution proposée offre, selon au moins un mode de réalisation, un mécanisme de découverte automatique et sécurisée de tranches réseau déployées (ou instanciées) sur une infrastructure fixe et/ou mobile et réservées à un certain usage, par exemple la retransmission d’un évènement sportif ou musical.
En particulier, la plupart des solutions existantes suppose que le trafic aller entre le terminal et le fournisseur de service, et le trafic retour entre le fournisseur de service et le terminal sont acheminés via une même tranche réseau. Selon l’art antérieur, le terminal ne contrôle pas l’accès à la ou aux tranches réseau utilisée(s) pour acheminer les données associées au service considéré et ne permet pas de bénéficier ainsi des ressources de la tranche réseau qui optimise la qualité du service considéré, telle qu’elle peut être perçue par l’utilisateur du terminal, notamment. Le terminal ne dispose donc pas de moyens de vérifier que la tranche réseau à laquelle l’instance de service se raccorde est celle qui met en place une politique d’acheminement de trafic optimisée pour le service considéré et tel que souscrit par le client.
L’invention, selon au moins un mode de réalisation, propose une solution à ce problème.
La illustre un exemple de système dans lequel l’invention peut être mise en œuvre. Un tel système comprend un terminal UE 11 (« User Equipment » en anglais) souhaitant accéder à au moins un service via un réseau de communication SSP 12 (« Slice Service Provider » en anglais, ou fournisseur de services reposant sur des tranches réseau) mettant en œuvre des tranches réseau, par exemple deux tranches réseau Sl. #1 161 et Sl. #2 162 (« Slice » en anglais).
Le terminal 11 peut éventuellement être connecté au réseau 12 via un routeur intermédiaire, par exemple un CPE.
Le service peut être fourni par au moins une instance de service, par exemple par deux instances de services SFI #1 131 et SFI #2 132. Une instance de service peut être connectée au réseau 12 par l’intermédiaire d’un nœud de bordure du réseau. Par exemple, la première instance 131 est connectée au réseau 12 par l’intermédiaire du premier nœud de bordure BR 141 (« Border Router » en anglais), et la deuxième instance 132 est connectée au réseau 12 par l’intermédiaire du deuxième nœud de bordure BR 142. Les instances de service ne sont pas nécessairement directement connectées aux nœuds de bordure.
Au moins un contrôleur réseau 15 peut être utilisé pour transmettre à au moins un nœud de bordure du réseau 12 (par exemple dans les nœuds de bordure 141 et 142) des règles de classification de trafic (par exemple sous forme algorithmique, ou sous la forme d’au moins une table de classification de trafic, ou sous toute autre forme). Le contrôleur 15 peut également transmettre au terminal 11 le ou les premiers identifiants (également appelés « tags ») du trafic à destination du terminal. Le contrôleur 15, ou le nœud de bordure, peut maintenir au moins une règle de classification du trafic, permettant d’associer un premier identifiant du trafic à au moins une tranche réseau. On note que la configuration des nœuds de bordure et des terminaux peut être effectuée par des entités réseau distinctes.
On présente désormais, en relation avec la , les principales étapes mises en œuvre par les différents procédés selon un mode de réalisation de l’invention.
On considère que le contrôleur 15 obtient au cours d’une étape 151 au moins un premier identifiant TAG destiné à la classification du trafic à destination du terminal 11. Un tel premier identifiant est associé à au moins une tranche réseau ou un type de tranche réseau. Par exemple, le contrôleur maintient une règle de classification de trafic selon laquelle le premier identifiant TAG #1 est associé à la tranche réseau Sl #1.
Au cours d’une étape 152, ledit au moins un premier identifiant TAG est transmis au terminal 11, directement ou via au moins un routeur intermédiaire.
Au cours d’une étape 153, le contrôleur 15 transmet, à au moins un nœud de bordure du réseau de communication, par exemple le nœud BR1 141, au moins une règle de classification de trafic pour la sélection d’au moins une tranche réseau destinée à acheminer vers le terminal des données associées audit au moins un service. Par exemple, de telles règles peuvent être configurées dans le nœud de bordure, ou mises en œuvre par l’exécution d’un algorithme connu du nœud de bordure (reçu d’un contrôleur).
On note que l’étape 153 peut être mise en œuvre avant les étapes 151 et/ou 152.En d’autres termes, la transmission des règles de classification de trafic au nœud de bordure peut être mise en œuvre avant ou après avoir transmis ledit au moins un premier identifiant TAG au terminal 11. Eventuellement, l’étape 153 peut être mise en œuvre par un autre contrôleur.
Au cours d’une étape 111, le terminal 11 reçoit donc ledit au moins un premier identifiant TAG, en provenance du contrôleur 15, directement ou via au moins un routeur intermédiaire.
Au cours d’une étape 112, le terminal 11 transmet ledit au moins un premier identifiant TAG à au moins une première instance de service apte à fournir le service considéré, par exemple à la première instance de service SFI #1 131.
Au cours d’une étape 1311, la première instance de service 131 reçoit donc ledit au moins un premier identifiant TAG.
Au cours d’une étape 1312, la première instance de service 131 transmet, via au moins un nœud de bordure, par exemple le premier nœud de bordure BR 141, un message MSG1 comportant au moins un deuxième identifiant et des données D associées au service considéré. Ces données D sont destinées au terminal 11. Par exemple, le deuxième identifiant est égal au premier identifiant TAG. Dans une variante, le premier identifiant est utilisé pour calculer un deuxième identifiant qui peut être inclus dans ledit message. Par exemple, le deuxième identifiant est obtenu en appliquant une fonction de hachage « Hash » au premier identifiant.
Dans l’exemple illustré, on considère que le deuxième identifiant est égal au premier identifiant TAG. Le message MSG1 émis par la première instance de service 131 comporte donc ledit au moins un premier identifiant TAG et les données D.
Au cours d’une étape 1412, le premier nœud de bordure 141 reçoit donc le message MSG1 en provenance de la première instance de service 131 comportant ledit au moins un premier identifiant TAG et les données D.
Au cours d’une étape 1413, le premier nœud de bordure 141 vérifie si au moins une tranche réseau est associée audit au moins un premier identifiant TAG en appliquant au moins une règle de classification de trafic connue du premier nœud de bordure 141 (par exemple configurée au cours d’une étape 1411), et sélectionne ladite au moins une tranche réseau correspondante.
Au cours d’une étape 1414, le premier nœud de bordure 141 transmet les données D associées au service considéré sur ladite au moins une tranche réseau sélectionnée. Le premier nœud de bordure 141 peut retransmettre au terminal 11 le message MSG1 comportant ledit au moins un premier identifiant TAG et les données D tels que reçus de la première instance de service 131, ou supprimer ledit au moins un premier identifiant TAG pour n’envoyer que les données D au terminal 11 dans un message MSG1’.
Au cours d’une étape 113, le terminal 11 reçoit donc le message MSG1’ comportant les données D acheminées via au moins une tranche réseau associée audit au moins un premier identifiant TAG.
La est un diagramme de flux illustrant les messages échangés selon les principales étapes décrites en .
De manière plus générale, on considère qu’une tranche réseau du réseau de communication peut être associée à d’autres tranches réseau pour fournir des services à valeur ajoutée. Par exemple, un fournisseur de service peut s’appuyer sur des tranches mises en place dans différents sous-réseaux pour fournir un service dont le trafic est destiné à être acheminé dans la tranche réseau « globale » composée des tranches déployées dans les différents sous-réseaux. On parle alors de « tranche multi-domaines » (ou « stitched slices » ou « hierarchical slices » en anglais). Une telle tranche réseau peut en effet refléter une structure hiérarchique.
Par exemple, comme illustré par la , le réseau SSP 12 peut être composé de plusieurs sous-réseaux 121, 122 et 123. Chaque sous-réseau peut supporter une ou plusieurs tranches réseau. Par exemple, le premier sous-réseau 121 supporte quatre tranches réseau, le deuxième sous-réseau 122 supporte trois tranches réseau, et le troisième sous-réseau 123 supporte quatre tranches réseau. La première tranche réseau Sl. #1 161 du réseau de communication est par exemple composée des tranches réseau Sl. #3 déployée sur le sous-réseau 121, Sl. #2 déployée sur le sous-réseau 122 et Sl. #2 déployée sur le sous-réseau 123. Les interfaces de raccordement entre tranches adjacentes (« Attachment Circuits » en anglais) sont par exemple gérées en utilisant les mécanismes décrits dans le document « YANG Data Models for 'Attachment Circuits'-as-a-Service (ACaaS) » de M. Boucadair et al., version 6 publiée le 3 mai 2023.
Par exemple, chaque sous-réseau peut être associé à un domaine distinct (par exemple, un réseau de communication peut être composé d’un réseau d’accès, d’un réseau de collecte, d’un réseau cœur et d’un réseau de transit). Chacun de ces domaines supporte des tranches réseau dont l’ingénierie et l’exploitation sont caractéristiques du domaine (par exemple, une tranche déployée sur un réseau cœur mobile 5G peut faire appel à des fonctions de traitement de trafic et d’exploitation caractéristiques d’un réseau cœur mobile 5G). Ainsi, chaque domaine (accès, collecte, cœur, transit, etc.) peut exploiter différentes technologies déployées dans ce domaine pour la réalisation des tranches réseau.
Ainsi, la réalisation d’une tranche réseau qui s’étend sur plusieurs domaines n’est pas conditionnée par la disponibilité ou l’activation des mêmes technologies utilisées pour la réalisation des tranches « locales » à chaque domaine.
Par exemple, en référence à la , un premier domaine associé au premier sous-réseau 121 met en place des tunnels IPsec qui sont exploités pour acheminer le trafic dans les tranches déployées dans ce domaine, alors qu’un deuxième domaine associé au deuxième sous-réseau 122 utilise une ingénierie de réseau privé virtuel de niveau réseau (Layer 3 VPN ou L3VPN en anglais) combiné avec des mécanismes d’ingénierie de trafic (« Traffic Engineering » ou TE en anglais) pour acheminer le trafic dans les tranches déployées dans ce domaine, tandis qu’un troisième domaine associé au troisième sous-réseau 123 utilise les ressources du routage par segments reposant sur le protocole IPv6 (« Segment Routing IPv6 » ou SRv6 en anglais) pour acheminer le trafic dans les tranches déployées dans ce domaine.
Selon un autre exemple, une tranche réseau dans un réseau mobile (5G par exemple) peut reposer sur la mise en place de tranches réseau dans les différents sous-réseaux/segments suivants : réseau d’accès radio (« Radio Access Network » ou RAN), réseau cœur (« Core Network » ou CN) et réseau de transport (« Transport Network » ou TN).
L’association entre une tranche réseau, par exemple une tranche réseau 5G dans le cas d’un réseau mobile de dernière génération, et les tranches réseau déployées dans chacun des segments / sous-réseaux composant le réseau mobile 5G est réalisée dans le plan de contrôle et à la périphérie de chacun des réseaux RAN, CN et TN. La tranche réseau déployée dans le réseau TN est parfois appelée « IETF Network Slice ».
Selon l’invention, aucune hypothèse n’est faite quant à la nature des tranches réseau, leur nombre, et le « mapping » entre des tranches réseau de domaines voisins (par exemple RAN et TN, TN et CN).
Par exemple, les mécanismes décrits dans le document « A Realization of IETF Network Slices for 5G Networks Using Current IP/MPLS Technologies » précédemment cité sont mis en œuvre pour la réalisation des tranches réseau dans un réseau IP/MPLS (qui est un exemple de réseau de transport au sens du 3GPP).
On note par ailleurs qu’une même tranche réseau peut être utilisée pour agréger le trafic d’un ou plusieurs services. Ainsi, comme illustré par la , un premier service S1 servi par une ou plusieurs instances de service 51 peut être fourni à un premier client UE1 via une tranche réseau Sl. #3 du réseau SSP, un deuxième service S2 servi par une ou plusieurs instances de service 52 peut être fourni à un deuxième client UE2 via la même tranche réseau Sl. #3 du réseau SSP, un troisième service S3 servi par une ou plusieurs instances de service 53 peut être fourni au deuxième client UE2 via la même tranche réseau Sl. #3 du réseau SSP.
De plus, une tranche réseau peut impliquer une ou plusieurs fonctions service (ou « Service Functions » en anglais, selon la terminologie utilisée par le document RFC7665 – « Service Function Chaining (SFC) Architecture » de J. Halpern et al. publié en octobre 2015, ou « Network Functions » comme gNB (« gNodeB ») ou des fonctions UPF (« User Plane Functions ») selon la terminologie utilisée par le 3GPP). Une même fonction service peut être fournie par une ou plusieurs instances de service.
La illustre un exemple de déploiement d’instances de service. En particulier, une instance de service peut être hébergée par le SSP (par exemple les instances de service 63 et 64) ou au sein d’une autre infrastructure (par exemple l’instance de service 65).
Dans un mode de réalisation particulier, des chaînes de service (« Service Function Chain » ou SFC en anglais) peuvent être mises en place afin de faciliter l’acheminement de trafics de différente nature et présentant des profils différents pour les besoins de la réalisation d’une tranche réseau ou au sein d’une tranche réseau (par exemple les instances de service 611, 612 et 613 de la ).
5.2 Exemples de mise en œuvre
On présente désormais des exemples de mise en œuvre de l’invention. Par souci de simplification, on considère ci-après que le premier identifiant et le deuxième identifiant sont identiques. On utilise donc simplement le terme « identifiant ».
En se référant de nouveau à la , on considère que le terminal 11 négocie avec le SSP 12 une liste d’au moins une tranche réseau que le terminal 11 est susceptible d’utiliser pour envoyer ou recevoir du trafic. Le terminal 11 peut indiquer le cas échéant le mode de transmission envisagé pour chacune des tranches réseau de ladite liste :
  • l’acheminement de données à destination du terminal 11 ( « receive-only »),
  • l’acheminement de données en provenance du terminal 11 (« send-only »),
  • l’acheminement de données associées à destination du terminal 11 et en provenance du terminal 11 (« send-receive »).
Selon cet exemple de mise en œuvre de l’invention, le terminal 11 et le SSP 12 échangent des messages pour s’assurer qu’ils supportent bien l’un et l’autre la procédure SOLACE (« Slicing Optimisé A LA CartE ».
Par exemple, le terminal 11 valorise un premier indicateur ou paramètre noté « Collaborative-Solace-Capable » à une valeur donnée, par exemple « 1 », pour indiquer au SSP 12 qu’il est apte à mettre en œuvre une procédure collaborative pour l’acheminement des données associées à au moins un service auquel le terminal souhaite accéder et à destination du terminal, reposant sur le traitement d’au moins un identifiant (tag) destiné à la classification du trafic à destination du terminal.
Cette indication de support de la procédure SOLACE peut être fournie globalement ou lors de l’activation de chaque tranche réseau.
Si le SSP 12 supporte la procédure SOLACE, il retourne un deuxième indicateur ou paramètre « Collaborative-Solace-Capable » valorisé à une valeur donnée, par exemple « 1 », pour indiquer au terminal 11 qu’il est apte à mettre en œuvre une procédure collaborative pour l’acheminement des données associées à au moins un service auquel le terminal souhaite accéder et à destination du terminal, reposant sur le traitement d’au moins un identifiant (tag).
Le deuxième indicateur peut être retourné au terminal 11 en réponse à la réception du premier indicateur. En variante, c’est le premier indicateur qui est retourné par le terminal 11 en réponse à la réception du deuxième indicateur.
Le mode collaboratif de la procédure SOLACE est alors activé par le terminal 11 et le SSP 12.
A l’inverse, si le deuxième indicateur ou paramètre « Collaborative-Solace-Capable » retourné par le SSP 12 est égal à « 0 », alors le terminal 11 désactive le mode collaboratif de la procédure SOLACE.
On suppose par la suite que le mode collaboratif de la procédure SOLACE est activé.
Comme illustré par la , un contrôleur réseau 15 peut transmettre au terminal 11 au moins un identifiant (tag) destiné à la classification du trafic à destination du terminal 11. Un tel tag, noté par exemple « Inbound-Flow-Map », peut être retourné pour chaque tranche réseau négociée avec le terminal 11. Le contrôleur réseau 15 peut notamment maintenir à jour au moins une règle de classification de trafic associant au moins un identifiant du trafic à destination du terminal, ou tag, avec au moins une tranche réseau.
Ainsi, l’absence du tag et/ou du deuxième indicateur « Collaborative-Solace-Capable » est une indication implicite du non-support du mode collaboratif de la procédure SOLACE par le SSP 12.
En particulier, le mode collaboratif SOLACE peut être négocié avec chacun des réseaux auxquels le terminal peut se connecter. Dans ce cas, le terminal 11 peut récupérer des tags distincts par réseau auquel le terminal 11 est connecté.
Dans un mode de réalisation particulier, une durée de validité ou une échéance peut être associée au tag. Dans ce cas, un nouveau tag (« Inbound-Flow-Map ») peut être renégocié avec le réseau à ladite échéance ou à l’expiration de ladite durée de validité.
Dans une autre variante, une clé de sécurité peut être associée au tag. Par exemple, un nombre aléatoire ou pseudo-aléatoire, ou « nonce », unique pour un terminal, est également communiqué au terminal avec le ou les tags. Une telle clé de sécurité peut être utilisée à des fins d’autorisation.
Le contrôleur réseau 15 (ou un autre contrôleur réseau) peut également transmettre aux nœuds de bordure, par exemple au premier nœud de bordure BR 141 et au deuxième nœud de bordure BR 142, des règles de classification de trafic pour associer le trafic entrant sur le nœud de bordure à la ou aux tranches réseau négociées avec le terminal 11 (et donc associer l’identifiant du trafic à destination du terminal associé, ou tag, à la ou aux tranches réseau négociées avec le terminal 11).
On note qu’un même tag peut être négocié avec plusieurs terminaux pour optimiser la taille des tables de classification de trafic lorsque les règles de de classification de trafic sont stockées dans des tables maintenues par les nœuds de bordure.
Le terminal 11 peut ainsi associer le trafic retour de chaque service éligible à l’exploitation de tranches avec au moins une tranche réseau, grâce à au moins un tag. Le trafic retour d’un même service peut être associé à plusieurs tranches réseau selon la nature du service. La classification de chacune de ces catégories selon un type de tranche réseau peut être définie par la logique du service (par exemple intégrée dans l’applicatif embarqué dans le terminal 11) ou fournie par le réseau SSP 12. La classification des différents trafics peut également faire l’objet d’une décision prise par le terminal 11 (par exemple, selon les choix et instructions de l’utilisateur du terminal 11).
Pour ce faire, le terminal 11 peut transmettre un ou plusieurs tags à au moins une instance de service apte à fournir le service auquel le terminal souhaite accéder. Par exemple, le terminal 11 utilise un nouveau paramètre appelé ci-après « Solace », pour transmettre le ou les tags dans un message qu’il envoie à une instance de service, par exemple à la première instance de service SFI #1 131.
Si le paramètre Solace ne contient qu’un seul tag « Inbound-Flow-Map », alors ce tag s’applique pour tout le trafic émis par l’instance de service.
Si ce paramètre Solace contient une liste de tags « Inbound-Flow-Map », alors des règles de classification de trafic sont également fournies par le terminal 11 à l’instance de service, de façon à pouvoir identifier le trafic émis par l’instance de service et le tag associé.
Dans un contexte où le terminal 11 est connecté à plusieurs réseaux de communication (contexte de « multihoming » par exemple), le terminal 11 s’assure que les règles de classification de trafic ainsi générées permettent d’associer le trafic avec le tag du réseau destiné à acheminer ledit trafic.
Par exemple, comme illustré en , le terminal 11 peut être connecté à un premier réseau de communication SSP1 et à un deuxième réseau de communication SSP2. Le terminal 11 peut indiquer explicitement, par exemple via le paramètre Solace, son adresse destination dans chaque réseau de communication comme règle de classification de trafic, correspondant ici à un paramètre de démultiplexage.
Ainsi, le paramètre Solace contient par exemple une liste de tags dont un premier tag TAG1 correspondant à l’adresse du terminal via le premier réseau SSP1 (notée dst@1), et un deuxième tag TAG2 correspondant à l’adresse du terminal via le deuxième réseau SSP2 (notée dst@2) : Solace {dst@1=TAG1, dst@2=TAG2}.
En particulier, le nouveau paramètre Solace peut être inséré dans un en-tête dédié (par exemple en-tête HTTP, trame QUIC) ou décrit dans des messages caractéristiques de protocoles tels que SDP (« Session Description Protocol ») ou WebRTC.
L’exemple suivant illustre l’usage d’un nouvel attribut SDP pour la transmission du paramètre Solace entre le terminal 11 et une instance de service, appelé ci-après « a=slice-tag » :
v=0
o=- 25678 753849 IN IP6 2001:db8::1
s=
c=IN IP6 2001:db8::1
t=0 0
m=audio 12340 RTP/AVP 0 8
a=slice-tag:156 IP6 2001:db8::1 45678
a=slice-tag:651 IP6 2001:db8::123 12340
Selon cet exemple, le tag « 156 » (i.e. l’identifiant destiné à la classification du trafic à destination du terminal) peut être utilisé par l’instance de service si l’adresse destination utilisée pour envoyer le trafic vers le terminal 11 est « 2001:db8::1 », alors que le tag « 651 » peut être utilisé par l’instance de service si l’adresse destination utilisée pour envoyer le trafic vers le terminal 11 est « 2001:db8::123 ».
Il est bien entendu que cet exemple n’est fourni qu’à titre d’illustration ; d’autres paramètres pour caractériser le trafic associé à chaque tag peuvent être indiqués dans une offre/réponse SDP par exemple.
En revenant à la , le message comportant le paramètre « Solace » envoyé vers une instance de service est acheminé depuis le terminal 11 en utilisant une tranche réseau configurée à cet effet ou en utilisant un chemin par défaut si aucune tranche réseau n’est disponible ou activée pour acheminer le trafic à destination de cette instance de service.
Sur réception du message comportant le paramètre « Solace », l’instance de service vérifie la présence d’au moins un tag (« Inbound-Flow-Map »).
Par exemple, l’instance de service extrait puis enregistre localement la ou les règles de classification de trafic transmises par le terminal, ainsi que le ou les tags associés.
Le cas échéant, ces tags remplacent ceux déjà présents pour les mêmes règles de classification de trafic.
De façon optionnelle, l’instance de service confirme la bonne mise en place des règles de classification de trafic. Cette confirmation peut être communiquée au terminal 11 en utilisant un paramètre d’acquittement dédié (par exemple en-tête HTTP, trame QUIC) ou décrite explicitement dans des messages caractéristiques de protocoles tels que SIP, SDP ou WebRTC. Pour certains services, l’absence de message d’erreur peut aussi être interprétée comme un acquittement et une confirmation implicites.
Si un trafic sortant (issu d’au moins une instance de service et à destination du terminal 11) est associé à une règle de classification de trafic communiquée par le terminal, alors l’instance de service marque le trafic avec le tag correspondant. En d’autres termes, l’instance de service peut émettre un message MSG1 comportant un ou plusieurs tags « tag » et, pour chaque tag, les données associées au service auquel le terminal souhaite accéder selon les règles de classification de trafic communiquées par le terminal. Par exemple, le ou les tags peuvent être insérés dans une option UDP, un en-tête HTTP, un en-tête SIP, le champ « Flow Label » d’un entête de paquet IPv6, un entête d’extension IPv6, etc.
Par exemple, comme illustré par la , la première instance de service SFI #1 131 peut transférer le message MSG1 à d’autres instances de service impliquées dans la fourniture du service, telles que la deuxième instance de service SFI #2 132. Ceci est avantageux car un même service peut impliquer une pluralité d’instances de service sans pour autant devoir réitérer la phase de communication des tags par le terminal avec toutes les instances de service. Cette synchronisation est notamment avantageuse pour les services qui utilisent un adressage anycast (c’est-à-dire, les instances de service sont joignables depuis une même adresse IP).
Le trafic retour (issu d’au moins une instance de service et à destination du terminal 11) est reçu par au moins un nœud de bordure, par exemple le premier nœud de bordure BR 141 et/ou deuxième nœud de bordure BR 142. Sur réception du message MSG1 envoyé par l’instance de service, le nœud de bordure BR inspecte, puis extrait le cas échéant le ou les tags.
Si aucun tag n’est présent, alors le trafic est traité selon une règle d’acheminement par défaut. Par exemple, le trafic est acheminé au terminal 11 via une route par défaut (par exemple une route qui n’est pas établie dans l’une quelconque des tranches réseau déployées, ou une tranche réseau dédiée au trafic dit « Best Effort »).
Si un tag est présent, le nœud de bordure BR applique les règles de classification de trafic ad hoc (par exemple en consultant une table de classification de trafic qu’il maintient localement) pour identifier la tranche réseau associée au tag :
  • si aucune entrée dans la table de classification de trafic n’est trouvée, alors le trafic peut être acheminé vers le terminal 11 via une route par défaut, ou bien bloqué. Par exemple, en , le nœud de bordure BR 142 ne dispose pas, dans la table de classification de trafic, d’une entrée descriptive de la tranche réseau associée au tag reçu dans le message MSG1. Les données sont donc acheminées selon une route par défaut, qui ne repose pas nécessairement sur l’utilisation de tranches réseau.
  • si une entrée dans la table de classification de trafic est identifiée par le nœud de bordure BR, alors celui-ci achemine le trafic selon le contenu de cette entrée, c'est-à-dire via la tranche réseau identifiée à partir du tag. Par exemple, en , le nœud de bordure BR 141 reconnaît que le tag reçu dans le message MSG1 est associé à la tranche réseau Sl. #2. Il peut donc transmettre les données au terminal 11 via la tranche réseau Sl. #2.
En revenant à la , le nœud de bordure BR 141 du premier réseau SSP1 reçoit des données D1 et l’identifiant TAG1 en provenance de l’instance de service 131, et peut sélectionner, à partir de la lecture de la table de classification de trafic, la tranche réseau associée à l’identifiant TAG1 pour l’acheminement des données D1 via le premier réseau SSP1, par exemple la tranche réseau Sl. #3. Le nœud de bordure BR 842 du deuxième réseau SSP2 reçoit des données D2 et l’identifiant TAG2 en provenance de l’instance de service 131, et peut sélectionner, à partir de la lecture de la table de classification de trafic, la tranche réseau associée à l’identifiant TAG2 pour l’acheminement des données D2 via le deuxième réseau SSP2, par exemple la tranche SL. #1. Les données D1 et D2 peuvent être identiques ou différentes.
En revanche, comme illustré par la , si le nœud de de bordure BR 141 du premier réseau SSP1 reçoit des données D1 et l’identifiant TAG2 en provenance de l’instance de service 131, aucune entrée n’est trouvée dans la table de classification de trafic. Les données D1 sont donc acheminée vers le terminal 11 en utilisant une route par défaut, ou une route déterminée selon un schéma de routage IP classique par exemple.
De façon optionnelle, le nœud de bordure BR peut retirer le ou les tags avant de retransmettre les données vers le terminal.
Dans une variante, le nœud de bordure BR vérifie la présence d’une clé de sécurité, par exemple la présence d’un paramètre « nonce » valide associé au terminal considéré, avant d’injecter le trafic dans une tranche réseau. La vérification de la validation du « nonce » peut être effectuée localement ou en faisant intervenir un contrôleur réseau, par exemple le contrôleur 15. La vérification n’est pas nécessairement effectuée systématiquement pour tous les paquets du message MSG1 qui transportent un tag et une clé de sécurité.
Dans une variante, le nœud de bordure BR peut calculer un condensé (« hash ») sur la base d’un premier paquet du message MSG1, et ce « hash » peut ensuite être utilisé pour valider les paquets suivants sans solliciter l’intervention d’un contrôleur réseau.
Si le terminal 11 détecte une anomalie/incohérence entre la tranche réseau utilisée pour un trafic retour d’un service donné et les indications communiquées à l’instance de service, notamment le tag destiné à la classification du trafic retour et/ou la clé de sécurité, le terminal peut procéder comme suit :
  • renvoyer les instructions de marquage à l’instance de service, i.e. renvoyer le paramètre Solace,
  • négocier une nouvelle procédure SOLACE avec le réseau, i.e. renégocier la liste de tranches réseau que le terminal est susceptible d’utiliser pour envoyer ou recevoir du trafic,
  • ajuster les règles de classification de trafic.
Dans un autre mode de réalisation, le terminal 11 n’est pas connecté directement au réseau de communication, mais par l’intermédiaire d’un équipement de raccordement (par exemple un CPE ou autre routeur intermédiaire). Dans ce mode de réalisation, l’équipement de raccordement peut mettre en œuvre la procédure SOLACE comme si le terminal était directement connecté au réseau.
En variante, le CPE peut négocier avec le terminal l’activation de la procédure SOLACE. Par exemple, la communication des tags aux instances de service est effectuée par le terminal.
Dans une autre variante, le CPE insère les tags selon des règles locales au CPE. Ces règles peuvent être configurées par l’utilisateur ou communiquées par le terminal via un mécanisme dédié (PCP, par exemple).
Ainsi, comme illustré par la , le contrôleur 15 peut transmettre le ou les tags au CPE 10. Le terminal 11 peut contacter le CPE 10 pour récupérer les tags associés à chaque tranche réseau. Par exemple, le terminal 11 utilise de nouvelles options qui peuvent être supportées par différents protocoles tels que PCP (Port Control Protocol), DHCP (Dynamic Host Configuration Protocol), RA (message « Router Advertisement » en environnement IPv6), etc., pour obtenir les tags.
Un exemple d’option PCP utilisée à cet effet est proposé en . Selon cet exemple, le champ « Tag count » indique le nombre de tags inclus dans l’option PCP. De manière optionnelle, le champ « Traffic Selector » peut être renseigné pour un tag. Ce champ décrit par exemple la règle de classification de trafic éligible au marquage avec ledit tag (par exemple adresse IP destination, numéro de port destination, identifiant de protocole), par une instance de service, des données associées au service considéré. Si aucune règle n’est indiquée, alors le marquage des données avec un tag est applicable à tout le trafic entrant sur l’instance de service (i.e. à destination du terminal).
Si le mode collaboratif de la procédure SOLACE est désactivé, le terminal peut notamment indiquer dans un message à destination d’une instance de service la liste des tranches réseau négociées avec le réseau. Sur réception de ce message, l’instance de service peut choisir d’invoquer une tranche distincte de celle utilisée pour acheminer ce message, pour tout ou partie du trafic à destination du terminal.
On a décrit ci-dessus différents exemples de mise en œuvre de l’invention. Bien entendu, ces exemples sont purement illustratifs et non limitatifs. En particulier, comme déjà indiqué, aucune hypothèse n’est faite selon l’invention quant à la nature des tranches réseau, leur nombre, et le « mapping » éventuel entre des tranches réseau de domaines voisins (par exemple RAN et TN, TN et CN). Notamment, une tranche réseau peut être déployée sur une infrastructure fixe, mobile, ou une combinaison des deux.
5.3 Structure simplifiée des entités correspondantes
On présente finalement, en relation avec la , les structures simplifiées d’une entité, par exemple un terminal, un contrôleur, une instance de service, ou un nœud de bordure selon au moins un mode de réalisation décrit ci-dessus.
Comme illustré par la , une telle entité comprend au moins une mémoire 121 comprenant une mémoire tampon, au moins une unité de traitement 122, équipée par exemple d’une machine de calcul programmable ou d’une machine de calcul dédiée, par exemple un processeur P, et pilotée par le programme d’ordinateur 123, mettant en œuvre des étapes d’au moins un procédé selon au moins un mode de réalisation de l’invention.
A l’initialisation, les instructions de code du programme d’ordinateur 123 sont par exemple chargées dans une mémoire RAM avant d’être exécutées par le processeur de l’unité de traitement 122.
Si l’entité est un terminal, le processeur de l’unité de traitement 122 met en œuvre des étapes du procédé d’accès à au moins un service décrit précédemment, selon les instructions du programme d’ordinateur 123, pour :
  • obtenir au moins un premier identifiant destiné à la classification du trafic à destination dudit terminal,
ledit au moins un premier identifiant étant associé à au moins une tranche réseau ou un type de tranche réseau,
  • transmettre dit au moins un premier identifiant à au moins une première instance de service apte à fournir ledit au moins un service audit terminal,
  • recevoir un message comportant des données associées audit au moins un service acheminées via au moins une tranche réseau associée audit au moins un premier identifiant, ladite au moins une tranche réseau étant sélectionnée par un nœud de bordure dudit réseau de communication en appliquant au moins une règle de classification de trafic connue dudit nœud de bordure.
Si l’entité est un contrôleur, le processeur de l’unité de traitement 122 met en œuvre des étapes du procédé de contrôle de la fourniture d’au moins un service décrit précédemment, selon les instructions du programme d’ordinateur 123, pour :
  • obtenir au moins un premier identifiant destiné à la classification du trafic à destination dudit terminal,
ledit au moins un premier identifiant étant associé à au moins une tranche réseau ou un type de tranche réseau,
  • transmettre ledit au moins un premier identifiant audit terminal, directement ou via au moins un routeur intermédiaire,
  • transmettre, à au moins un nœud de bordure dudit réseau de communication, au moins une règle de classification de trafic pour la sélection d’au moins une tranche réseau destinée à acheminer vers ledit terminal des données associées audit au moins un service.
Si l’entité est une instance de service, le processeur de l’unité de traitement 122 met en œuvre des étapes du procédé de fourniture d’au moins un service décrit précédemment, selon les instructions du programme d’ordinateur 123, pour :
  • recevoir au moins un premier identifiant destiné à la classification du trafic à destination dudit terminal,
ledit au moins un premier identifiant étant associé à au moins une tranche réseau ou un type de tranche réseau,
  • la transmission, via au moins un nœud de bordure dudit réseau de communication, d’un message comportant au moins un deuxième identifiant, fonction dudit au moins un premier identifiant, et des données associées audit au moins un service, lesdites données étant destinées à être acheminées via au moins une tranche réseau associée audit au moins un premier identifiant,
ladite au moins une tranche réseau étant sélectionnée par ledit nœud de bordure en appliquant au moins une règle de classification de trafic connue dudit nœud de bordure.
Si l’entité est un nœud de bordure, le processeur de l’unité de traitement 122 met en œuvre des étapes du procédé de gestion de l’accès à au moins un service décrit précédemment, selon les instructions du programme d’ordinateur 123, pour :
  • recevoir au moins un message en provenance d’au moins une première instance de service apte à fournir ledit au moins un service, ledit message comportant au moins un deuxième identifiant, fonction d’au moins un premier identifiant destiné à la classification du trafic à destination dudit terminal, et des données associées audit au moins un service,
ledit au moins un premier identifiant étant associé à au moins une tranche réseau ou un type de tranche réseau,
  • sélectionner au moins une tranche réseau associée audit au moins un premier identifiant en appliquant au moins une règle de classification de trafic connue,
  • transmettre lesdites données associées audit au moins un service sur ladite au moins une tranche réseau sélectionnée.

Claims (20)

  1. Procédé d’accès à au moins un service par un terminal (11), via un réseau de communication mettant en œuvre des tranches réseau, comprenant :
    • l’obtention (111) d’au moins un premier identifiant destiné à la classification du trafic à destination dudit terminal, ledit au moins un premier identifiant étant associé à au moins une tranche réseau ou un type de tranche réseau,
    • la transmission (112) dudit au moins un premier identifiant à au moins une première instance de service (131) apte à fournir ledit au moins un service audit terminal,
    • la réception (113) d’un message comportant des données associées audit au moins un service acheminées via au moins une tranche réseau associée audit au moins un premier identifiant, sélectionnée par un nœud de bordure (141) dudit réseau de communication en appliquant au moins une règle de classification de trafic connue dudit nœud de bordure.
  2. Procédé selon la revendication 1, caractérisé en ce que ladite au moins une tranche réseau ou ledit type de tranche réseau est associé à un mode de transmission appartenant au groupe comprenant :
    • l’acheminement de données à destination dudit terminal,
    • l’acheminement de données en provenance dudit terminal,
    • l’acheminement de données à destination dudit terminal et en provenance dudit terminal.
  3. Procédé selon l'une quelconque des revendications précédentes, caractérisé en ce que ladite obtention comprend l’obtention d’au moins un premier identifiant par réseau auquel ledit terminal est connecté.
  4. Procédé selon l'une quelconque des revendications précédentes, caractérisé en ce qu’il comprend la transmission, à ladite première instance de service, d’au moins une règle de classification de trafic.
  5. Procédé selon l'une quelconque des revendications précédentes, caractérisé en ce qu’il met en œuvre une sélection préalable de ladite moins une première instance de service habilitée à recevoir ledit au moins un premier identifiant.
  6. Procédé de contrôle de la fourniture d’au moins un service à un terminal (11), via un réseau de communication mettant en œuvre des tranches réseau, comprenant :
    • l’obtention (151) d’au moins un premier identifiant destiné à la classification du trafic à destination dudit terminal, ledit au moins un premier identifiant étant associé à au moins une tranche réseau ou un type de tranche réseau,
    • la transmission (152) dudit au moins un premier identifiant audit terminal, directement ou via au moins un routeur intermédiaire,
    • la transmission (153), à au moins un nœud de bordure (141) dudit réseau de communication, d’au moins une règle de classification de trafic pour la sélection d’au moins une tranche réseau destinée à acheminer vers ledit terminal des données associées audit au moins un service.
  7. Procédé selon la revendication 6, caractérisé en ce qu’il comprend la transmission dudit au moins un premier identifiant à au moins un autre terminal connecté audit réseau de communication.
  8. Procédé de fourniture d’au moins un service à un terminal (11), via un réseau de communication mettant en œuvre des tranches réseau, comprenant :
    • la réception (1311) d’au moins un premier identifiant destiné à la classification du trafic à destination dudit terminal, ledit au moins un premier identifiant étant associé à au moins une tranche réseau ou un type de tranche réseau,
    • la transmission (1312), via au moins un nœud de bordure (141) dudit réseau de communication, d’un message comportant au moins un deuxième identifiant, fonction dudit au moins un premier identifiant, et des données associées audit au moins un service, lesdites données étant destinées à être acheminées via au moins une tranche réseau associée audit au moins un premier identifiant, sélectionnée par ledit nœud de bordure en appliquant au moins une règle de classification de trafic connue dudit nœud de bordure.
  9. Procédé selon la revendication 8, caractérisé en ce qu’il comprend la réception d’au moins une règle de classification de trafic pour l’acheminement des données associées audit au moins un premier identifiant, et le stockage de ladite au moins une règle de classification de trafic et dudit au moins un premier identifiant associé.
  10. Procédé selon l'une quelconque des revendications 8 et 9, caractérisé en ce que ladite réception comprend la réception d’au moins deux premiers identifiants associés chacun à au moins une tranche réseau et l’application d’au moins une règle de classification de trafic pour sélectionner l’un desdits premiers identifiants.
  11. Procédé selon l'une quelconque des revendications 8 à 10, caractérisé en ce qu’il comprend la transmission dudit message comportant ledit au moins un deuxième identifiant et des données associées audit au moins un service à au moins une deuxième instance de service apte à fournir ledit au moins un service.
  12. Procédé de gestion de l’accès à au moins un service par un terminal, via un réseau de communication, comprenant :
    • la réception (1412) d’au moins un message en provenance d’au moins une première instance de service (131) apte à fournir ledit au moins un service, ledit message comportant au moins un deuxième identifiant, fonction d’au moins un premier identifiant destiné à la classification du trafic à destination dudit terminal, et des données associées audit au moins un service,
      ledit au moins un premier identifiant étant associé à au moins une tranche réseau ou un type de tranche réseau,
    • la sélection (1413) d’au moins une tranche réseau associée audit au moins un premier identifiant en appliquant au moins une règle de classification de trafic connue,
    • la transmission (1414) desdites données associées audit au moins un service sur ladite au moins une tranche réseau sélectionnée.
  13. Procédé selon l'une quelconque des revendications 1 à 12 caractérisé en ce que ledit au moins un premier identifiant est associé à une durée de validité.
  14. Procédé selon l'une quelconque des revendications 1 à 13 caractérisé en ce que ledit au moins un premier identifiant est associé à une clé de sécurité.
  15. Procédé selon l'une quelconque des revendications 1 à 14 caractérisé en ce qu’au moins une desdites tranches réseau est composée d’au moins une tranche réseau locale déployée dans au moins un sous-réseau dudit réseau de communication.
  16. Terminal (11) apte à accéder à au moins un service, via un réseau de communication mettant en œuvre des tranches réseau, comprenant au moins un processeur configuré pour :
    • obtenir au moins un premier identifiant destiné à la classification du trafic à destination dudit terminal, ledit au moins un premier identifiant étant associé à au moins une tranche réseau ou un type de tranche réseau,
    • transmettre dit au moins un premier identifiant à au moins une première instance de service apte à fournir ledit au moins un service audit terminal,
    • recevoir un message comportant des données associées audit au moins un service acheminées via au moins une tranche réseau associée audit au moins un premier identifiant, sélectionnée par un nœud de bordure dudit réseau de communication en appliquant au moins une règle de classification de trafic connue dudit nœud de bordure.
  17. Contrôleur (15) apte à contrôler la fourniture d’au moins un service à un terminal, via un réseau de communication mettant en œuvre des tranches réseau, comprenant au moins un processeur configuré pour :
    • obtenir au moins un premier identifiant destiné à la classification du trafic à destination dudit terminal, ledit au moins un premier identifiant étant associé à au moins une tranche réseau ou un type de tranche réseau,
    • transmettre ledit au moins un premier identifiant audit terminal, directement ou via au moins un routeur intermédiaire,
    • transmettre, à au moins un nœud de bordure dudit réseau de communication, au moins une règle de classification de trafic pour la sélection d’au moins une tranche réseau destinée à acheminer vers ledit terminal des données associées audit au moins un service.
  18. Instance de service (131, 132) apte à fournir au moins un service à un terminal, via un réseau de communication mettant en œuvre des tranches réseau, comprenant au moins un processeur configuré pour :
    • recevoir au moins un premier identifiant destiné à la classification du trafic à destination dudit terminal, ledit au moins un premier identifiant étant associé à au moins une tranche réseau ou un type de tranche réseau,
    • la transmission, via au moins un nœud de bordure dudit réseau de communication, d’un message comportant au moins un deuxième identifiant, fonction dudit au moins un premier identifiant, et des données associées audit au moins un service, lesdites données étant destinées à être acheminées via au moins une tranche réseau associée audit au moins un premier identifiant, sélectionnée par ledit nœud de bordure en appliquant au moins une règle de classification de trafic connue dudit nœud de bordure.
  19. Nœud de bordure (141, 142) apte à gérer l’accès à au moins un service par un terminal, via un réseau de communication, comprenant au moins un processeur configuré pour :
    • recevoir au moins un message en provenance d’au moins une première instance de service apte à fournir ledit au moins un service, ledit message comportant au moins un deuxième identifiant, fonction d’au moins un premier identifiant destiné à la classification du trafic à destination dudit terminal, et des données associées audit au moins un service,
      ledit au moins un premier identifiant étant associé à au moins une tranche réseau ou un type de tranche réseau,
    • sélectionner au moins une tranche réseau associée audit au moins un premier identifiant en appliquant au moins une règle de classification de trafic connue,
    • transmettre lesdites données associées audit au moins un service sur ladite au moins une tranche réseau sélectionnée.
  20. Programme d’ordinateur comportant des instructions pour la mise en œuvre d’un procédé selon l'une quelconque des revendications 1 à 15 lorsque ce programme est exécuté par un processeur.
PCT/EP2024/067744 2023-06-29 2024-06-25 Procédés d'accès à un service, procédé de fourniture de services, procédé de contrôle, procédé de gestion, terminal, instance de service, contrôleur, nœud de bordure et programmes d'ordinateur correspondants Ceased WO2025003097A1 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
EP24734902.0A EP4736394A1 (fr) 2023-06-29 2024-06-25 Procédés d'accès à un service, procédé de fourniture de services, procédé de contrôle, procédé de gestion, terminal, instance de service, contrôleur, noeud de bordure et programmes d'ordinateur correspondants

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR2306885A FR3150670A1 (fr) 2023-06-29 2023-06-29 Procédés d’accès à un service, procédé de fourniture de services, procédé de contrôle, procédé de gestion, terminal, instance de service, contrôleur, nœud de bordure et programmes d’ordinateur correspondants.
FRFR2306885 2023-06-29

Publications (1)

Publication Number Publication Date
WO2025003097A1 true WO2025003097A1 (fr) 2025-01-02

Family

ID=88779705

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2024/067744 Ceased WO2025003097A1 (fr) 2023-06-29 2024-06-25 Procédés d'accès à un service, procédé de fourniture de services, procédé de contrôle, procédé de gestion, terminal, instance de service, contrôleur, nœud de bordure et programmes d'ordinateur correspondants

Country Status (3)

Country Link
EP (1) EP4736394A1 (fr)
FR (1) FR3150670A1 (fr)
WO (1) WO2025003097A1 (fr)

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2017200978A1 (fr) * 2016-05-16 2017-11-23 Idac Holdings, Inc. Sélection et attribution de tranches à base de sécurité
US10785652B1 (en) * 2019-09-11 2020-09-22 Cisco Technology, Inc. Secure remote access to a 5G private network through a private network slice
US20220141713A1 (en) * 2020-10-30 2022-05-05 Verizon Patent And Licensing Inc. Systems and methods of application mapping for network slicing using group segmentation

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2017200978A1 (fr) * 2016-05-16 2017-11-23 Idac Holdings, Inc. Sélection et attribution de tranches à base de sécurité
US10785652B1 (en) * 2019-09-11 2020-09-22 Cisco Technology, Inc. Secure remote access to a 5G private network through a private network slice
US20220141713A1 (en) * 2020-10-30 2022-05-05 Verizon Patent And Licensing Inc. Systems and methods of application mapping for network slicing using group segmentation

Non-Patent Citations (5)

* Cited by examiner, † Cited by third party
Title
DE A. FARREL ET AL., A FRAMEWORK FOR IETF NETWORK SLICES, 15 June 2023 (2023-06-15)
DE J. HALPERN ET AL., SERVICE FUNCTION CHAINING (SFC) ARCHITECTURE, October 2015 (2015-10-01)
DE K. G. SZARKOWICZ ET AL., A REALIZATION OF IETF NETWORK SLICES FOR 5G NETWORKS USING CURRENT IP/MPLS TECHNOLOGIES, 23 May 2023 (2023-05-23)
DE M. BOUCADAIR ET AL., YANG DATA MODELS FOR 'ATTACHMENT CIRCUITS'-AS-A-SERVICE (ACAAS, 3 May 2023 (2023-05-03)
WEI Y ET AL: "Network Service Header (NSH) Metadata Type 2 Variable-Length Context Headers ;rfc9263.txt", 9 August 2022 (2022-08-09), pages 1 - 9, XP015154231, Retrieved from the Internet <URL:https://tools.ietf.org/html/rfc9263> [retrieved on 20220809] *

Also Published As

Publication number Publication date
EP4736394A1 (fr) 2026-05-06
FR3150670A1 (fr) 2025-01-03

Similar Documents

Publication Publication Date Title
EP3646557A1 (fr) Procédé de communication quic via des chemins multiples
EP3284224B1 (fr) Procédé d&#39;émulation dune connexion à chemins multiples
FR3053197A1 (fr) Procede de communication udp via des chemins multiples entre deux terminaux
WO2008077928A1 (fr) Procede de reservation et d&#39;allocation dynamique de creneaux temporels dans un reseau avec garantie de service
EP3739843A1 (fr) Procédé de communication udp via des chemins multiples entre deux terminaux
WO2020260813A1 (fr) Procédé de gestion d&#39;une communication entre terminaux dans un réseau de communication, et dispositifs pour la mise en oeuvre du procédé
FR3072238B1 (fr) Dispositif et procede de transmission de donnees
EP3682601A1 (fr) Routage de donnees dans une passerelle residentielle mettant en oeuvre l&#39;agregation de liens
EP3682600B1 (fr) Gestion de la connexion avec d&#39;autres passerelles residentielles d&#39;une passerelle residentielle mettant en oeuvre l&#39;agregation de liens
WO2025003097A1 (fr) Procédés d&#39;accès à un service, procédé de fourniture de services, procédé de contrôle, procédé de gestion, terminal, instance de service, contrôleur, nœud de bordure et programmes d&#39;ordinateur correspondants
CA3240305A1 (fr) Mecanismes de communication avec un service accessible via un reseau de telecommunication prenant en compte la mobilite des services, des utilisateurs et des equipements
EP1432210A1 (fr) Dispositif de contrôle de traitements associés a des flux au sein d&#39;un reseau de communications
FR3150669A1 (fr) Procédés d’accès à un service et de fourniture de services, terminal, instance de service, et programmes d’ordinateur correspondants.
FR3154268A1 (fr) Procédés de vérification, de gestion, de contrôle, d’exécution d’une vérification de l’accessibilité d’un équipement, équipement, serveur de contrôle, contrôleur réseau, entité relais et programme d’ordinateur correspondants.
EP2640004B1 (fr) Procede de gestion des echanges de flux de donnees dans un reseau de telecommunication autonomique
WO2025078597A1 (fr) Procédés d&#39;acheminement de données, de configuration, d&#39;allocation d&#39;identifiants et d&#39;accès à un service dans un réseau de communication mettant en œuvre des tranches réseau, entités et programme d&#39;ordinateur correspondants
WO2025078594A1 (fr) Procédés de sélection de tranches réseau adaptées à un service, de gestion d&#39;au moins une tranche réseau et de communication, et entités configurées pour mettre en œuvre ces procédés
FR3157769A1 (fr) Procédé d’accès à un service par un dispositif de communication via au moins un réseau de communication
WO2025093520A1 (fr) Procédés et dispositifs pour la configuration et l&#39;utilisation d&#39;un réseau supportant des tranches réseau
EP4595404A1 (fr) Procédé de gestion du trafic de données entre une entité source et une entité destinataire, entité et programme d&#39;ordinateur correspondants
FR3153206A1 (fr) Procédés, dispositifs et système de contrôle d’une communication dans un réseau
EP2439901A1 (fr) Procédé de traitement dans un module d&#39;un dispositif d&#39;accès adapté pour connecter un réseau distant à une pluralité de réseaux locaux, module et programme d&#39;ordinateur associés

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 24734902

Country of ref document: EP

Kind code of ref document: A1

WWE Wipo information: entry into national phase

Ref document number: 2024734902

Country of ref document: EP

NENP Non-entry into the national phase

Ref country code: DE

ENP Entry into the national phase

Ref document number: 2024734902

Country of ref document: EP

Effective date: 20260129

ENP Entry into the national phase

Ref document number: 2024734902

Country of ref document: EP

Effective date: 20260129