EP4082232B1 - Procédé de configuration d'un equipement utilisateur, equipement utilisateur, entite de gestion de regles, procédé de gestion de règles et système - Google Patents

Procédé de configuration d'un equipement utilisateur, equipement utilisateur, entite de gestion de regles, procédé de gestion de règles et système Download PDF

Info

Publication number
EP4082232B1
EP4082232B1 EP20845789.5A EP20845789A EP4082232B1 EP 4082232 B1 EP4082232 B1 EP 4082232B1 EP 20845789 A EP20845789 A EP 20845789A EP 4082232 B1 EP4082232 B1 EP 4082232B1
Authority
EP
European Patent Office
Prior art keywords
user
rule
user equipment
network
identifier
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.)
Active
Application number
EP20845789.5A
Other languages
German (de)
English (en)
Other versions
EP4082232A1 (fr
EP4082232C0 (fr
Inventor
Pierre-Alexandre MASSON
Xiaobao Chen
Antoine Mouquet
Kevin DERVAL
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
Publication of EP4082232A1 publication Critical patent/EP4082232A1/fr
Application granted granted Critical
Publication of EP4082232C0 publication Critical patent/EP4082232C0/fr
Publication of EP4082232B1 publication Critical patent/EP4082232B1/fr
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W8/00—Network data management
    • H04W8/18—Processing of user or subscriber data, e.g. subscribed services, user preferences or user profiles; Transfer of user or subscriber data
    • H04W8/183—Processing at user equipment or user record carrier
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/08—Configuration management of networks or network elements
    • H04L41/085—Retrieval of network configuration; Tracking network configuration history
    • H04L41/0853—Retrieval of network configuration; Tracking network configuration history by actively collecting configuration information or by backing up configuration information
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/08—Configuration management of networks or network elements
    • H04L41/0894—Policy-based network configuration management
    • 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/14—Routing performance; Theoretical aspects
    • 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/38—Flow based routing
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W28/00—Network traffic management; Network resource management
    • H04W28/02—Traffic management, e.g. flow control or congestion control
    • H04W28/08—Load balancing or load distribution
    • H04W28/086—Load balancing or load distribution among access entities
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W48/00—Access restriction; Network selection; Access point selection
    • H04W48/18—Selecting a network or a communication service
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W60/00—Affiliation to network, e.g. registration; Terminating affiliation with the network, e.g. de-registration
    • H04W60/005—Multiple registrations, e.g. multihoming
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W88/00—Devices specially adapted for wireless communication networks, e.g. terminals, base stations or access point devices
    • H04W88/02—Terminal devices
    • H04W88/06—Terminal devices adapted for operation in multiple networks or having at least two operational modes, e.g. multi-mode terminals
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W8/00—Network data management
    • H04W8/02—Processing of mobility data, e.g. registration information at HLR [Home Location Register] or VLR [Visitor Location Register]; Transfer of mobility data, e.g. between HLR, VLR or external networks
    • H04W8/06—Registration at serving network Location Register, VLR or user mobility server
    • H04W8/065—Registration at serving network Location Register, VLR or user mobility server involving selection of the user mobility server

Definitions

  • the present invention lies in the field of telecommunications.
  • the invention applies in a preferred manner to mobile telecommunications networks.
  • the architecture of mobile telecommunications networks currently deployed or in the process of being deployed is defined by the standardization group known as 3GPP (Third Generation Partnership Project). This is particularly the case for the so-called second generation mobile networks (“2G or GSM”), third generation (“3G”), and fourth generation (“4G”).
  • 3GPP Third Generation Partnership Project
  • the network architectures defined by the 3GPP group are most often based on specific equipment, dedicated to precise functionalities, whether at the level of the access network or the core network, in particular with regard to the transmission of packets from or to a mobile terminal.
  • 5G next generation of mobile networks
  • 5G networks are intended to concern both mobile and fixed networks.
  • a network slice is composed of network functions, hardware resources (e.g. storage and computing) and configurations to satisfy the requirements related to the services, clients and/or terminals attached to this slice.
  • hardware resources e.g. storage and computing
  • the figure 1 represents a simplified view of a communications infrastructure INF comprising network slices SL1, SL2 and SL3 each representing a mobile network, the network slices SL1, SL2 and SL3 sharing functions implemented in data centers, such as for example routing, addressing, data flow control, naming, etc.
  • network slices SL1, SL2 and SL3 provide access to three separate data networks DN1, DN2 and DN3. It should be noted, however, that network slices may provide access to the same data network.
  • Each network slice may be related to a separate mobile network, and is determined by the characteristics of the data flows transiting this network slice, which have common points in terms of, for example, destination, routing, and security constraints, justifying common management within the same network slice.
  • Each of the slices is thus optimized for the needs of a type of service and/or a type of customer and/or terminals.
  • terminal T1 is connected to the network slices SL1 and SL2
  • terminal T2 is connected to slice SL2
  • terminal T3 is connected to slice SL3.
  • Mobile network user terminals also now support an ever-increasing number of applications offered by various players in the telecommunications world (network operators, service providers, terminal manufacturers, etc.). Each of these applications may have specific needs regarding the routing of the data attached to it (in other words, that it sends or receives).
  • This data is conveyed on network slices after which the terminal is registered or associated, via for example a USIM (Universal Subscriber Identity Module) module embedded in the terminal.
  • a USIM module designates an application stored in a UICC (Universal Integrated Circuit Card), also commonly called a SIM card, allowing a terminal to register securely on a network and in particular on a cellular network.
  • UICC Universal Integrated Circuit Card
  • some terminals are configured to receive two USIM cards (known as a "dual SIM" terminal). These two USIM cards allow them to benefit simultaneously or not from connectivity offered for example by two separate network infrastructures managed by different operators, or by the same network infrastructure but according to two different offers, for example a "professional offer” and a "personal offer", each offer being able to be associated with specific services offered by the operator of the network infrastructure.
  • the user of a "dual SIM" terminal can, if his terminal allows it, manually configure in his terminal which USIM card he wishes to use according to the type of traffic sent and received by the terminal (voice, data or SMS (Short Message Service) messages).
  • the 3GPP TS 23.501 technical specification does not mention how to manage the use of this type of "dual SIM” terminals, or more generally “multi SIM” in combination with a network slicing technique.
  • the document WO 2018/141148 A1 describes a method for enabling a user equipment (UE) with multiple subscriptions to communicate over a network.
  • the UE is a multi-SIM device capable of connecting to different mobile networks, and can also support multiple concurrent network slices through its multiple SIMs.
  • the document WO 2018/220291 A1 describes a method of selecting, by a user terminal, a set of functions of a network slice for the routing of data relating to an application installed on the user terminal attached to this network slice.
  • the user equipment or UE for "User Equipment” in English
  • It can be a terminal such as a smartphone, a laptop, a digital tablet, a connected object, but also a router, etc.
  • the different modules of the user equipment can be hosted by different physical entities.
  • identifiers are, for example, identifiers of the IMSI (International Mobile Subscriber Identifier) type used in particular in 4G networks or of the SU-PI (SUbscription Permanent Identifier) type used in particular in 5G networks, or of the MAC (Medium Access Control) address type for non-3GPP networks of the WLAN (Wireless Access Network) type.
  • IMSI International Mobile Subscriber Identifier
  • SU-PI SUbscription Permanent Identifier
  • MAC Medium Access Control
  • identifiers that are allocated to the user independently of each other and permanently: in other words, they are invariant as long as the user benefits from a subscription or a subscription to a network.
  • These identifiers may be stored respectively, in a particular embodiment, in a plurality of embedded USIM modules and/or network cards in the user equipment.
  • the invention also relates to user equipment configured to receive a plurality of USIM modules and/or network cards, each card or each module being associated with an identifier distinct from the plurality of identifiers allocated to the user.
  • This plurality of identifiers identify the user and allow him to register via his user equipment with a plurality of distinct networks (for example with different public land mobile networks or PLMNs (for Public Land Mobile Network)), or with the same network but benefiting from independent offers or subscriptions, each associated with a different user identifier (for example a "professional subscription” and a "personal subscription” offered by the same network operator and relying on the same network infrastructure). From the point of view of the networks, these identifiers are managed as if they were allocated to as many different users respectively.
  • PLMNs Public Land Mobile Network
  • the invention proposes to configure (for example, automatically) a user's equipment having a plurality of identifiers allowing the user equipment to access one or more networks, with one or more rules allocating one or more slices of this or these networks to at least one flow of an application.
  • Each rule preferably comprises an identifier of the application to which it relates. It is noted that the rules can associate with all the flows of the same application the same slices of the network or networks to which the user equipment can access via the plurality of identifiers allocated to the user.
  • the invention also offers, if necessary, an additional granularity making it possible to distinguish the network slices to be used according to different types of flows that can be transmitted or received by the same application, or even individually from each flow that can be transmitted or received by the same application.
  • Different types of flows or different flows may correspond for example to flows carrying data of different natures (audio, video, text, etc.), to flows having different destination addresses, a different remote IP address, a different remote port, etc.
  • flow differentiation criteria listed in Table 5.2.1 of the 3GPP TS 24.526 specification entitled “User Equipment (UE) policies for 5G System (5GS); Stage 3”, v16.1.0, September 2019 may be considered.
  • the rules transmitted to the user equipment for its configuration take into account the fact that the latter benefits from multiple connectivity thanks to the multiple identifiers that are allocated to the user. They are advantageously established by taking into account the characteristics of the network slices associated with the different network(s) with which the user equipment can register and the services associated with these network slices taking into account the specificities of the applications considered. It is noted that the rules provided to the user equipment may concern applications that are not installed on the latter or that will not be executed by the latter; in this case they are not taken into account by the latter, and may be deleted from its configuration if necessary.
  • the rules obtained by the user equipment relate to applications installed thereon.
  • the user equipment may provide a policy entity with the identifiers of the applications it hosts, when registering with the network or networks on which the user has identifiers, or at any other time (e.g. when installing a new application).
  • each rule with each network slice advantageously makes it possible to uniquely designate the network to which the slice is attached if the identifiers allocated to the user correspond to different networks, or if the slices are attached to the same network, the identifier that the user equipment must use to access this network slice.
  • the information associated with each network slice associated with an application flow contains either a direct reference to the identifier of the user to be used to communicate on this network slice, or an indirect reference to this identifier via, for example, the module that contains this identifier or the network to which it is attached (if the identifiers allocated to the user typically identify it on different networks).
  • this information thus makes it possible to designate the SIM to which corresponds to the slice in question and that the user equipment must use for the application flow which is associated with this slice.
  • a multi-SIM user equipment can thus receive rules for association between applications (or even application flows) and network slices for each of the USIM modules and/or network cards that it embeds.
  • the invention thus makes it possible to associate for an application of the user equipment, or even for different flows of the same application of the user equipment, a USIM module and a slice of the corresponding network.
  • the flows of the same application can therefore be distributed over different slices of different networks according to the specificity of each of these flows: we are no longer limited to a static distribution according to a type of traffic exchanged with the user equipment (voice, data, SMS).
  • the granularity offered by the invention results in a better adaptation of the characteristics of the network to the specificities of each application installed on the terminal, a better availability of the applications and services offered to the user resulting therefrom, and therefore an improved user experience compared to the state of the art.
  • the rules obtained by the user equipment are determined by a rule management entity.
  • This rule management entity may be located in a mediation gateway between the different networks to which the user is subscribed or if the user is subscribed to a single network via different subscriptions, in this network. Alternatively, it is not necessarily associated with the networks and may be an entity independent of the latter.
  • the transmission of the rule to the user equipment can be done directly or indirectly via one or more entities of the networks to which the user equipment is subscribed.
  • said at least one rule is obtained upon association (or registration or attachment) of the user equipment to said at least one communications network.
  • the user equipment automatically and without delay has the rules to apply to access the applications that it hosts or that it is likely to access. This is done transparently for the user of the user equipment.
  • the rules can be configured manually in the user equipment, e.g. example by the user of the user equipment, via a user interface provided for this purpose.
  • a user interface is for example a settings menu available on the user equipment.
  • the rules may be statically configured in the user equipment software.
  • the rules are determined for each application by taking into account the different network slices and, where applicable, the different available networks. It is noted that they are preferably determined by taking into account the characteristics and subscriptions of each user, however, it is also possible to envisage, in a particular embodiment, that the rules are defined solely according to the specificities of the applications and that the same rules are sent to all users, it being up to them to then disregard the rules that are not applicable. They can also take into account other parameters, such as, for example, hardware and/or software characteristics of the user equipment.
  • a single rule can associate a plurality of distinct network slices with one or more flows of an application.
  • This plurality of network slices can correspond to a single network or to distinct communications networks.
  • the application can simultaneously access the different network slices identified by the rule, for example for the sake of distributing the load between the different network slices.
  • a priority of use may be assigned to each of said plurality of distinct slices.
  • network e.g. which USIM or network card
  • the usage priorities assigned to the different network slices contained in a rule may be assigned, in a particular embodiment, by the rule management entity, for example so as to achieve load distribution across the different network slices.
  • other criteria may be envisaged for establishing priorities between the network slices. These criteria may be linked to the user more specifically, for example based on the subscription he has with the network(s) concerned, or the network coverage he has, etc.
  • the rules may also contain instructions for using the network slices included in the rules, such as in a rule comprising a plurality of distinct network slices, the instruction to perform load balancing between these distinct network slices, or to use one slice nominally and another as backup, etc.
  • the management entity can associate with each rule an execution priority of said rule.
  • Such a priority allows the user equipment, in case of conflicts between two rules determined for two different applications to be executed simultaneously (e.g. the user equipment can only carry traffic with one network at a given time, and two running applications are associated with network slices belonging to distinct networks), to select the rule to be applied first.
  • this priority may be given for information purposes and the user equipment may decide to act otherwise in case of conflicts.
  • the configuration method and/or the method rule management is implemented by a computer.
  • the invention also relates to a computer program on a recording medium, this program being capable of being implemented in a computer or more generally in user equipment in accordance with the invention and comprising instructions adapted to the implementation of a configuration method as described above.
  • the invention also relates to a computer program on a recording medium, this program being capable of being implemented in a computer or more generally in a rule management entity in accordance with the invention and comprising instructions adapted to the implementation of a rule management method as described above.
  • Each program may use any programming language, and may be in the form of source code, object code, or code intermediate between source code and object code, such as in a partially compiled form, or in any other desirable form.
  • the invention also relates to an information medium or a recording medium readable by a computer, and comprising instructions of the computer program mentioned above.
  • the information or recording medium may be any entity or device capable of storing programs.
  • the medium may include a storage medium, such as a ROM, for example a CD ROM or a microelectronic circuit ROM, or a magnetic recording medium, for example a hard disk, or a flash memory.
  • the information or recording medium may be a transmissible medium such as an electrical or optical signal, which may be conveyed via an electrical or optical cable, by radio link, by wireless optical link or by other means.
  • the program according to the invention can in particular be downloaded from an Internet-type network.
  • the information or recording medium may be an integrated circuit in which a program is incorporated, the circuit being adapted to execute or to be used in the execution of the configuration method, according to the invention, or of the rule management method, according to the invention.
  • said plurality of identifiers are allocated to the user by a single communications network and the rules management entity is an entity of this single communications network.
  • the rules management entity is an entity independent of said at least one network.
  • the configuration method, the rule management method, the user equipment, the rule management entity and the system according to the invention have in combination all or part of the aforementioned characteristics.
  • the invention falls within the context of communication networks using network slicing techniques.
  • the user equipment proposes a mechanism for configuring a user equipment with rules, each rule associating one or more flows of a given application with one or more network slices, these network slices possibly being attached to distinct networks (e.g. PLMN).
  • PLMN Public Land Mobile Network
  • the user equipment is for example equipped with a plurality of USIM modules and/or network cards allowing it to associate with these different networks, or with a single network but via various subscriptions (subscriptions).
  • the invention applies to any type of application (audio, video, for text transfer, multimedia player, etc.), real time or not, which can be installed natively on user equipment, or downloaded from an application server, public or managed by a service provider, or by the operator of one of the networks, etc.
  • FIG. 2 represents a system 1 according to the invention, configured for the implementation of such a mechanism, in a first embodiment.
  • a user U has a user equipment UE2, in accordance with the invention, and configured to receive a plurality of UICC cards (for example K UICC cards, K designating an integer greater than or equal to 2), each UICC card storing a USIM module.
  • Each USIMk module, k designating an integer between 1 and K comprises an application allowing the user U to register and securely access a separate communications network NWk with which he has subscribed.
  • each USIMk module stores an identifier IDk(U) allocated to the user U by the operator of the network NWk. This identifier uniquely identifies him in a permanent and invariant manner on the network. NWk (ie for the entire duration of his subscription or his subscription to the network).
  • NWk ie for the entire duration of his subscription or his subscription to the network.
  • the user U can indifferently designate an individual user or a group of users, such as for example a community.
  • the communications networks NW1,...,NWK are 3GPP 5GS (5G System) networks
  • the IDk(U) identifiers are SUPI type identifiers.
  • This may include any cellular mobile networks as defined by the 3GPP standard (2G, 3G, 4G, 5G, etc.), or other types of networks, such as fixed networks, non-3GPP networks such as WLAN (Wireless Local Area Network) networks (e.g. Wi-Fi (Wireless Fidelity) networks), etc.
  • the IDk(U) identifiers depend on the nature of the networks considered. For example, this could be IMSI identifiers for 2G, 3G, 4G networks, a MAC address for a WLAN network, etc.
  • each NWk network implements a slicing technique for its subscribers, as mentioned in the 3GPP TS 23.501 specification cited above.
  • SL1(k),...,SLNk(k) denotes the available slices of the NWk network, Nk designating an integer greater than or equal to 1 corresponding to the number of slices offered by the NWk network, Nk being able to vary from one NWk network to another, and being likely to evolve over time.
  • SL1(k),...,SLNk(k) denotes the available slices of the NWk network, Nk designating an integer greater than or equal to 1 corresponding to the number of slices offered by the NWk network, Nk being able to vary from one NWk network to another, and being likely to evolve over time.
  • Such a slicing technique is known per se and not described in more detail here.
  • each network slice is uniquely identified on the network to which it belongs by an S-NSSAI identifier (for "Single Network Slice Selection Assistance Information") defined by the 3GPP standard in the TS 23.501 and TS 23.003 specifications entitled “Technical Specification Group Core Network and Terminals; Numbering, addressing and Identification”, v16.0.0, September 2019.
  • S-NSSAI identifier for "Single Network Slice Selection Assistance Information”
  • the rules, generally denoted RUL, used for the configuration of the user equipment UE2 are determined by a rule management entity 3, in accordance with the invention, associated with the different networks NW1,...,NWK, and hosted in a mediation gateway 4 interfacing with these different networks. More particularly here, in the case of 5G networks, the mediation gateway 4 interfaces with the PCF (Policy Control Function) entities for managing the flow policy of each of the networks NW1,...,NWK, referenced by PCF1,...,PCFK respectively.
  • PCF Policy Control Function
  • the PCF entities enable the control of policies in the 5GS networks, in particular at the level of the AMF (Access and Mobility Management Function) entities of the NW1,...,NWK networks (referenced by AMF1,...,AMFK respectively), responsible for the registration/attachment (or more generally the association) of user equipment with the NW1,...,NWK networks and their location.
  • AMF Access and Mobility Management Function
  • the rule management entity 3 is associated with the K networks NW1,...,NWK corresponding to the K USIM modules of the user equipment UE2, i.e. it defines RUL rules for users who have subscribed to subscriptions with these networks and, for this purpose, has visibility over the characteristics of the network slices corresponding to these different networks.
  • the rule management entity 3 may be associated with other networks in addition to the networks NW1,...,NWK.
  • NW1 may also be an entity independent of the networks NW1,...,NWK (which may, for example, exploit the connectivity of one of the networks to communicate with the user equipment UE2 and discover, through information sent to it by the user equipment UE2, the slices offered to it by each of the networks).
  • the mediation gateway 4 has the hardware architecture of a computer, as schematically represented in FIG. figure 3 , on which the rule management entity 3 is based. It includes in particular a processor 5, a RAM 6, a memory dead 7, a non-volatile flash memory 8, as well as communication means 9 comprising one or more communication interfaces allowing it to communicate in particular with the PGF entities of the networks NW1,...,NWK.
  • the user equipment UE2 is a terminal, such as for example a smart phone or smartphone, a computer, or even a digital tablet.
  • the user equipment UE2 is a so-called dual-SIM device, that is to say that it is configured to receive two separate USIM modules, namely a USIM1 module and a USIM2 module, allowing it to associate respectively with the two networks NW1 and NW2.
  • the user equipment UE2 also comprises a TE module (for "Terminal Equipment” in English) and two ME modules (for "Mobile Equipment” in English).
  • Each ME module itself comprises a TA module (for "Terminal adaptor"), an NT module (for “Network Termination”) and an RT module (for "Radio Termination”).
  • TA module for "Terminal adaptor”
  • NT module for “Network Termination”
  • RT module for "Radio Termination”
  • These different modules communicate with each other via various interfaces (Cu, R, Tu, Uu) as illustrated in the figure.
  • Such modules and interfaces are known per se and described in particular in the 3GPP specification document TS 21.905 entitled “Technical Specification Group Services and System Aspects; Vocabulary for 3GPP Specifications", v15.1.0, December 2018, and in Chapter 9 of A.
  • the Tu interface connects the access network and core network specific parts in the user equipment; it is usually proprietary.
  • the modules 2A, 2B and 2C are for example software modules defined by means of instructions of a computer program PROG2, comprising instructions corresponding to the main steps of a configuration method according to the invention.
  • the invention indeed also applies to other types of user equipment than terminals, and in particular to routers, or to user equipment whose TE and ME modules can be distributed over several distinct physical entities (for example partly on a terminal and partly on a company router, etc.).
  • the RUL rules are determined by the rule management entity 3 associated with the networks NW1,...,NWK, via its determination module 3A, during a so-called provisioning phase, for a plurality of applications App (step E10).
  • the rule management entity 3 determines RUL rules individually for each user for which it is responsible for defining rules (in other words here, for each user having subscribed to a subscription with the networks NW1,...,NWK with which the rule management entity 3 is associated). For this purpose, the rule management entity 3 takes into account the characteristics of the user's subscriptions/subscriptions with the operators of the networks NW1,...,NWK. It is assumed for this purpose that the rule management entity 3 is for example configured with information on the subscriptions available to each of the users for which it must define rules. In particular, the rule management entity 3 is configured here with the list of networks (e.g.
  • the rule management entity 3 can access this information by directly consulting the operators of the networks with which the users have subscribed or by accessing a database entered and updated by these operators so that it reflects a current status of the subscriptions subscribed by the users with these operators.
  • an application installed in the user equipment of users managed by the policy management entity 3 may be configured to register with the policy management entity 3 and provide it with this information.
  • rule management entity 3 can determine RUL rules no longer individually for each user, but by application, all users combined.
  • the plurality of applications for which the rule management entity 3 determines a set of RUL rules for each user is predefined.
  • These may include applications for which agreements have been established between the application providers and the operators of the NW1,...,NWK networks associated with the rule management entity 3, or those with which the user U in question has taken out a subscription.
  • the plurality of applications may be established based on the services subscribed to by the user U from the networks NW1,...,NWK associated with the rule management entity 3. It may also take into account the applications installed on the user equipment UE2 of the user U.
  • the rule management entity 3 can determine rules for the three applications App1, App2 and App3 installed on the user equipment UE2.
  • the user equipment UE2 informs the rule management entity 3 of the applications that it hosts via a network to which it is associated via one of its USIM modules.
  • such a network can detect that an application is installed on the user equipment UE2 (by analyzing the traffic relating to the user equipment UE2) and inform the rule management entity 3 thereof.
  • each rule determined by the rule management entity 3 via its determination module 3A associates with at least one flow of a given application App, for the routing of data relating to this flow, at least one slice of a communication network among the networks NW1,...,NWK with which the user U has subscribed.
  • a different rule can be determined for each distinct flow of the application, for part of the flows (for example by type of flow), or for all of the flows of the application, depending on the desired granularity.
  • Distributing flows of the same application on distinct network slices, for example according to the nature (i.e. the type) of these flows (e.g. audio, video, text), can allow better adaptation of the transmission conditions of these flows. This can also allow distribution of the load on the different available network slices.
  • the rule management entity 3 advantageously has visibility over all the network slices offered by all the networks NW1,...,NWK, so that it can associate network slices belonging to different networks with a flow of an application.
  • This association can be made dynamically, based on knowledge of the state of the available network slices corresponding to the different networks NW1,...,NWK. It can also rely on the consultation of a database internal to the rule management entity 3 or accessible on an external server by the latter associating with an application identifier and/or one or more flow identifiers of said application, network slices adapted for routing data relating to these flows. Such a database can be established in consultation with the operators of the networks NW1,...,NWK corresponding to the available network slices.
  • each rule determined for one or more flows of an application for the user U associates with this or these flows, at least one network slice SLi(k) (i possibly being equal to 1,...,Nk) and (explicit) information linking this network slice to the identifier IDk(U) uniquely identifying the user U on the network NWk (k possibly being equal to 1,...K) to which this network slice belongs.
  • each identifier IDk(U) identifying the user U on a different network NWk this information may consist of an identifier of the network NWk, also commonly referred to as PLMNId and corresponding to the MCC (for “Mobile Country Code” in English) and MNC (for “Mobile Network Code” in English) codes of the network NWk.
  • PLMNId an identifier of the network NWk
  • MCC for “Mobile Country Code” in English
  • MNC for “Mobile Network Code” in English
  • this information may be the identifier IDk(U) itself, or an identifier of a module of the user equipment UE2 of the user U containing said identifier IDk(U) (e.g. USIM module or network card), such as an identifier IGGid (serial number of a UICC card) or eID.
  • identifier IDk(U) itself, or an identifier of a module of the user equipment UE2 of the user U containing said identifier IDk(U) (e.g. USIM module or network card), such as an identifier IGGid (serial number of a UICC card) or eID.
  • IGGid serial number of a UICC card
  • the rule management entity 3 may associate with each flow or a set of flows of an application one or more distinct network slices, selected by the rule management entity 3 from among the network slices offered by the networks NW1,...,NWK.
  • Each flow and each application concerned by a rule are identified in the rule by an identifier making it possible to designate them uniquely to the networks and to the user equipment UE2.
  • these network slices may belong to the same network or to different networks.
  • they may be associated with a usage priority assigned by the rule management entity 3 or the rule may comprise one or more instructions for using these multiple network slices, such as for example an instruction to distribute the load over the different network slices.
  • Different criteria may be considered by the rule management entity 3 to assign a usage priority to each network slice.
  • the priorities set by the rule management entity 3 may take into account, for example, the characteristics of the subscription of the user U, and/or the hardware and/or software specificities of the user equipment UE2 of the user U, or aim at achieving load distribution across the different network slices, etc.
  • the management entity 3 can insert into each rule a priority of use of the rule to prioritize in some way the access to the slices of the networks NW1,...,NWK by the applications.
  • These priorities of use are intended to allow management of conflicts between rules that may arise at the level of the user equipment UE2 during concurrent access to several applications simultaneously. For example, such a conflict arises when several applications are executed simultaneously and each rule associated with each application refers to the use of a separate network while the user equipment UE2 can only access a single network at a given time (the user equipment UE2 is then said to be “single active”). It is noted that these priorities of use can have a binding value for the user equipment UE2 (which is then required to apply them to manage conflicts between applications), or on the contrary an indicative value that the user equipment UE2 is free not to take into account.
  • the user equipment UE2 is required to use as a priority for the flows corresponding to the identifier Flow1 of the application App1 the network slice S-NSSAI1 of the network NW1 (corresponding to the identifier PLMN1). If it does not have connectivity on the NW1 network (for example because its USIM1 module is disabled), then it can use the S-NSSAI1 network slice of the NW2 network for these flows.
  • the user equipment UE2 may have been preconfigured to manage a load distribution for one or more given applications.
  • the user equipment UE2 upon receipt of a rule associating several distinct network slices with one or more flows of an application, in the absence of additional instruction provided by the rule management entity 3 for the use of these multiple network slices, the user equipment UE2 can query the rule management entity 3 on the possibility of distributing the load between these multiple network slices, and implement such load distribution upon receipt of a positive response from the rule management entity 3.
  • RUL rules Once the RUL rules have been determined by the management entity 3 for each user and for each application, they are transmitted by the latter via its transmission module 3B to the users concerned (step E20). In the first embodiment described here, this transmission is done indirectly via the networks NW1,...,NWK with which the users have subscribed, and more particularly via the PCF and AMF entities of these networks.
  • the rule management entity 3 thus sends the RUL(U) rules determined for the user U to the PCF1, PCF2,...PCFK entities of the networks NW1,NW2,...,NWK. This transmission closes the provisioning phase.
  • rule management entity 3 can, in order to guarantee the integrity and timeliness of the RUL(U) rules arriving at the user equipment U via the networks NW1,..,NWK, sign these rules (in a manner known per se and not described here) and/or associate a timestamp with them.
  • the rules RUL(U) determined by the rule management entity 3 for the user U are transmitted to the user equipment UE2 when they associate with the different networks NW1,...,NWK.
  • a USIMk module (k selected from 1,...,K) is activated on the user equipment UE2 to access the network NWk (manually by the user U or automatically, for example when the user equipment UE2 is powered on) (step F10)
  • the user equipment UE2 associates itself via its USIMk module with the corresponding network NWk by means of the identifier IDk(U) uniquely identifying the user U on the network NWk (step F20).
  • This association may consist, depending on the network concerned, of a registration (or an attachment) of the user equipment UE2 with the network NWk and more particularly with the AMFk entity of the network NWk here, and comprise in particular an authentication of the latter by means of the identifier IDk(U).
  • This association triggers the obtaining by the user equipment UE2 of the rules RUL(U) determined by the rule management entity 3 for the user U for a plurality of applications App (step F30). More specifically, the AMFk entity with which the user equipment UE2 associates requests the PCFk entity to obtain the rules RUL(U) determined by the rule management entity 3. On receipt of these rules RUL(U), the AMFk entity transmits them to the user equipment UE2, and more specifically to module 2B of the TE module of the UE2 user equipment, for example in the URSP (UE Route Selection Policy) rules defined by the 3GPP standard and described in particular in the 3GPP TS 24.526 document cited above.
  • URSP UE Route Selection Policy
  • the RUL(U) rules thus obtained are transmitted to the execution module 2C of the user equipment UE2 for interpretation and application. They are stored by the latter, for example in the non-volatile memory of the user equipment UE2 (step F40).
  • the module TE is then configured to execute, via its execution module 2C, the RUL(U) rules when the user equipment UE2 accesses, via its access module 2A, one of the applications that it hosts (in the example of the figure 3 , to any of the applications App1, App2 and App3) (or alternatively, which is located on a remote server).
  • This operation is repeated for each network NWk to which the user equipment UE2 associates using the unique identifier IDk(U) allocated to it by the network NWk. It is noted that the user equipment UE2 can therefore receive the rules RUL(U) several times.
  • the rule management entity 3 can send to the user equipment UE2 priority rules to be applied where appropriate between the rules received from the different networks NWk, in particular if these differ from each other.
  • the execution module 2C Upon detection by the TE module of the user equipment UE2 of access to an application Appj (yes response to test step F50), the execution module 2C identifies whether at least one rule among the RUL(U) rules concerns the application Appj and, if applicable, executes, when accessing the application Appj, the identified rule(s), denoted RUL(U)/Appj, for routing the flows relating to this application (step F60). In other words, it transmits and receives on the network slice(s) associated with the flows indicated in the RUL(U)/Appj rules the flows of the application according to the instructions indicated in the rules and, if applicable, the priorities assigned to the different network slices.
  • the user equipment UE2 can select the rule to be executed based on a usage priority provided by the rule management entity 3 in each rule.
  • a new application is installed on the user equipment UE2 and the latter does not have rules for this application, it can request the rule management entity 3 to provide it with such a rule by indicating to it, for example, the identifier of the newly installed application.
  • the user equipment UE2 can benefit from the combined advantages of network slicing, multiple connectivity, and differentiated processing of applications that can go as far as differentiating the flows relating to each application. This results in a greatly improved user experience compared to the prior art, and this in a transparent manner for the user, the configuration of his user equipment UE2 being able to be done automatically without requiring his intervention. It should be noted however that in a particular embodiment, it is possible to envisage manual configuration of the user equipment UE2 by the user U to use the rules RUL(U). The user can for example make a selection from the rules that are proposed to him, or delete those that do not concern applications installed on his user equipment UE2, etc.
  • NW1,...,NWK for example, managed by different operators.
  • the USIM1 module corresponds for example to a personal subscription taken out by the user U with the operator of a network NW1 (and corresponding to an identifier ID1(U)) and the USIM2 module to a professional subscription taken out by the user U with the operator of the same network NW1 (and corresponding to an identifier ID2(U)).
  • the identifiers ID1(U) and ID2(U) are for example IMSI or SUPI identifiers uniquely and distinctly identifying the user U on the network NW1 within the framework of his two subscriptions.
  • the user equipment UE2 accesses the network NW1 via the personal subscription of the user U, it uses the USIM1 module to associate itself with the network NW1 and the corresponding identifier ID1(U) stored in the USIM1 module.
  • user equipment UE2 accesses the NW1 network via user U's professional subscription, it uses the USIM2 module to associate with the NW1 network and the corresponding ID2(U) stored in the USIM2 module.
  • the network slices considered by the rule management entity 3 during the step E10 of determining the rules therefore belong to the same network NW1. However, they may correspond to different subscriptions of the user U and therefore to different qualities of service, access to different services, etc. In other words, a user may have access to different network slices depending on the subscription and more precisely the USIM module that he uses to access the network NW1.
  • the information linking each slice identified in a rule to an identifier IDk(U) of the user U cannot then be limited to an identifier of the network NW1 since the latter is the same for each identifier IDk(U) of the user U.
  • this information therefore preferably consists of the identifier IDk(U) itself corresponding to the network considered, or of an identifier of the USIM module containing the identifier IDk(U) and therefore used to access the network considered.
  • the rule management entity 3 may be integrated into an entity of the network NW1.
  • the RUL(U) rules may be transmitted directly by the rule management entity 3 to the user equipment UE2 when it is associated with the network NW1 (regardless of the USIM module used) or via, as in the first embodiment previously described, one or more PCF and AMF modules of the network NW1 (depending on the architecture envisaged, one may consider the same PCF and the same AMF for both subscriptions, or a dedicated PCF and AMF for each subscription).
  • a third embodiment may also be envisaged in which the user equipment UE2 is configured to receive USIM modules enabling it to associate with distinct networks and USIM modules enabling it to associate with the same network, corresponding to a combination of the first two embodiments described.
  • the rule management entity 3 is an entity external to the networks considered, and the information linking each network slice to an identifier IDk(U) of the user U is, as in the second embodiment, either the identifier IDk(U) itself or an identifier of the module containing the identifier IDk(U).
  • the RUL(U) rules are provided to the user equipment UE2 when it associates with the network(s) with which it has subscribed.
  • these RUL(U) rules are provided at other times, for example upon request from the user equipment UE2 (following the installation of a new application, for example for which it does not have rules), etc.
  • the user U via the aforementioned user interface, can then define the rules RUL(U) for using these different slices for all or part of the flows of each application installed on its user equipment and configure by this means the user equipment so that it uses these rules when it accesses an application.
  • the configuration of the user equipment may be done "hard” in the software of the user equipment according to RUL(U) rules provided for example by an external entity such as the rule management entity 3 or by the user U.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Databases & Information Systems (AREA)
  • Computer Security & Cryptography (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Telephonic Communication Services (AREA)

Description

    Technique antérieure
  • La présente invention se situe dans le domaine des télécommunications.
  • Elle concerne plus particulièrement les architectures de réseaux de télécommunications mettant en oeuvre une technique de découpage de réseaux en tranches, plus communément appelée « network slicing » en anglais.
  • L'invention s'applique de façon privilégiée aux réseaux de télécommunications mobiles.
  • L'architecture des réseaux de télécommunications mobiles actuellement déployés ou en cours de déploiement est définie par le groupe de standardisation connu sous le nom de 3GPP (Third Génération Partnership Project). C'est le cas notamment des réseaux mobiles dits de deuxième génération (« 2G ou GSM»), de troisième génération (« 3G »), et de quatrième génération (« 4G »).
  • Jusqu'à la quatrième génération, les architectures de réseau définies par le groupe 3GPP reposent le plus souvent sur des équipements spécifiques, dédiés à des fonctionnalités précises, que ce soit au niveau du réseau d'accès ou du coeur de réseau, notamment en ce qui concerne la transmission de paquets depuis ou à destination d'un terminal mobile.
  • Le manque de flexibilité et d'évolutivité inhérent à ce type d'architecture a conduit le groupe 3GPP à envisager l'adoption d'architectures plus flexibles pour la prochaine génération de réseaux mobiles dite « 5G », afin de pouvoir répondre rapidement à des demandes extrêmement diverses en termes de trafic et/ou de qualité de service envisagées par les réseaux 5G. Il est à noter que les réseaux 5G ont vocation à concerner aussi bien les réseaux mobiles que les réseaux fixes.
  • Parmi les solutions envisagées, une des solutions les plus prometteuses repose sur une technique de découpage par tranches du réseau ou « network slicing ». Cette technique est décrite notamment dans la spécification technique 3GPP TS 23.501 v15.7.0, septembre 2019. Elle permet à l'opérateur d'un réseau de créer des réseaux logiques de bout-en-bout sur mesure et indépendants pour ses clients, à partir d'une même infrastructure de réseau physique, capables de fournir des solutions optimisées pour des scénarii variés correspondant à des contraintes diverses en termes de fonctionnalités, de performances et de qualités de service.
  • Plus spécifiquement, le concept de tranches de réseau permet de créer plusieurs instances de réseau aussi appelées « network slices » en anglais. Une tranche de réseau est composée de fonctions réseaux, de ressources matérielles (par exemple de stockage et de calcul) et de configurations permettant de satisfaire les exigences liées aux services, aux clients et/ou terminaux rattachés à cette tranche.
  • A titre illustratif, la figure 1 représente une vue simplifiée d'une infrastructure de communications INF comprenant des tranches de réseau SL1, SL2 et SL3 représentant chacune un réseau mobile, les tranches de réseau SL1, SL2 et SL3 se partageant des fonctions mises en oeuvre dans des centres de données (ou « data centers » en anglais), telles que par exemple des fonctions de routage, d'adressage, de contrôle de flux de données, de nommage, etc. Dans l'exemple de la figure 1, les tranches de réseau SL1, SL2 et SL3 donnent accès à trois réseaux de données distincts DN1, DN2 et DN3. On note toutefois que des tranches de réseau peuvent donner accès à un même réseau de données. Chaque tranche de réseau peut être apparentée à un réseau mobile distinct, et est déterminée par les caractéristiques des flux de données transitant par cette tranche de réseau, qui présentent des points communs en termes par exemple de destination, d'acheminement, et de contraintes de sécurité, justifiant une gestion commune au sein d'une même tranche de réseau. Chacune des tranches est ainsi optimisée pour les besoins d'un type de service et/ou d'un type de client et/ou de terminaux. Dans l'exemple illustré à la figure 1, le terminal T1 est connecté aux tranches de réseau SL1 et SL2, le terminal T2 est connecté à la tranche SL2, et le terminal T3 est connecté à la tranche SL3.
  • Les terminaux des utilisateurs des réseaux mobiles supportent par ailleurs aujourd'hui un nombre toujours plus important d'applications proposées par divers acteurs du monde des télécommunications (opérateurs de réseau, fournisseurs de services, constructeurs de terminaux, etc.). Chacune de ces applications peut avoir des besoins spécifiques en ce qui concerne l'acheminement des données qui lui sont attachées (en d'autres termes, qu'elle émet ou reçoit). Ces données sont véhiculées sur des tranches du réseau après duquel le terminal est enregistré ou associé, via par exemple un module USIM (Universal Subscriber Identity Module) embarqué dans le terminal. De façon connue, un module USIM désigne une application stockée dans une carte UICC (Universal Integrated Circuit Card), aussi couramment appelée carte SIM, permettant à un terminal de s'enregistrer de manière sécurisée sur un réseau et notamment sur un réseau cellulaire.
  • Il est donc recommandé de sélectionner, pour véhiculer les données émises et reçues par chaque application, une tranche du réseau adaptée à ses besoins. La spécification technique 3GPP TS 23.501 v15.7.0, septembre 2019, indique que le réseau peut fournir au terminal des règles lui permettant de sélectionner une tranche d'un réseau en fonction des services qu'il veut utiliser. Toutefois, cette spécification technique considère un terminal équipé d'une unique carte USIM lui permettant de s'enregistrer auprès d'un unique réseau. Ainsi, les règles fournies au terminal concernent implicitement les tranches d'un unique réseau auprès duquel le terminal peut s'enregistrer via sa carte USIM.
  • Or certains terminaux sont configurés pour recevoir deux cartes USIM (on parle de terminal « dual SIM »). Ces deux cartes USIM leur permettent de bénéficier simultanément ou non d'une connectivité offerte par exemple par deux infrastructures de réseaux distinctes gérées par des opérateurs différents, ou par une même infrastructure de réseau mais selon deux offres différentes, par exemple une « offre professionnelle » et une « offre personnelle », chaque offre pouvant être associée à des services spécifiques proposés par l'opérateur de l'infrastructure de réseau. Dans l'état actuel de la technique, l'utilisateur d'un terminal « dual SIM » peut, si son terminal le permet, configurer manuellement dans son terminal quelle carte USIM il souhaite utiliser en fonction du type de trafic émis et reçu par le terminal (voix, données ou messages SMS (Short Message Service)). Dès lors, tout le trafic de type voix émis ou reçu par le terminal utilise la carte USIM configurée manuellement par l'utilisateur pour le trafic de type voix, tout le trafic de type données émis ou reçu par le terminal utilise la carte USIM configurée manuellement par l'utilisateur pour le trafic de type données, tout le trafic de type SMS émis ou reçu par le terminal utilise la carte USIM configurée manuellement par l'utilisateur pour le trafic de type SMS, et ce, toutes applications installées sur le terminal confondues.
  • La spécification technique 3GPP TS 23.501 n'évoque pas comment gérer l'utilisation de ce type de terminaux « dual SIM », ou plus généralement « multi SIM » en combinaison avec une technique de découpage en tranches de réseau.
  • Le document WO 2018/141148 A1 décrit un procédé permettant à un équipement utilisateur (UE) bénéficiant d'une souscription multiple de communiquer sur un réseau. L'UE est un équipement multi-SIM capable de se connecter à différents réseaux mobiles, et peut également supporter des tranches de réseau multiples concurrentes par l'intermédiaire de ses SIM multiples.
  • Le document WO 2018/220291 A1 décrit un procédé de sélection, par un terminal utilisateur, d'un ensemble de fonctions d'une tranche de réseau pour l'acheminement de données relatives à une application installée sur le terminal utilisateur attaché à cette tranche de réseau.
    • Exposé de l'invention
  • L'invention est définie par les revendications indépendantes 1, 6, 16, 18 et 19. L'invention remédie notamment à cet inconvénient en proposant un procédé de configuration d'un équipement utilisateur destiné à être utilisé par un utilisateur auquel est allouée une pluralité d'identifiants identifiant chacun de manière unique ledit utilisateur sur au moins un réseau de communications, ce procédé étant mis en oeuvre par l'équipement utilisateur et comprenant, pour au moins une application :
    • une étape d'obtention d'au moins une règle associant à au moins un flux de ladite application, au moins une tranche dudit au moins un réseau de communications pour un acheminement de données relatives audit au moins un flux et une information reliant ladite tranche à un identifiant parmi ladite pluralité d'identifiants de l'utilisateur ; et
    • une étape de configuration de l'équipement utilisateur avec ladite au moins une règle pour qu'il exécute ladite au moins une règle lors d'un accès à ladite application.
  • Corrélativement, l'invention vise aussi un équipement utilisateur destiné à être utilisé par un utilisateur auquel est allouée une pluralité d'identifiants identifiant chacun de manière unique l'utilisateur sur au moins un réseau de communications, cet équipement utilisateur comprenant :
    • un module d'obtention, configuré pour obtenir au moins une règle associant à au moins un flux d'une application, au moins une tranche dudit au moins un réseau de communications pour un acheminement de données relatives audit au moins un flux et une information reliant ladite tranche à un identifiant parmi ladite pluralité d'identifiants de l'utilisateur ; et
    • un module d'exécution, configuré pour exécuter ladite au moins une règle lors d'un accès à l'application.
  • Par application, on entend ici tout type de programme ou de logiciel, destiné à être installé sur un équipement pour réaliser une tâche, ou un ensemble de tâches élémentaires qui s'exécute en utilisant le système d'exploitation et les ressources matérielles de l'équipement. Il peut s'agir par exemple d'un jeu électronique, d'un navigateur web, d'un lecteur multimédia, d'une application de commerce en ligne, de transmission de données de santé, etc. On note que l'invention s'applique aussi bien lorsque l'application est installée sur l'équipement utilisateur ou sur un autre équipement accessible par l'équipement utilisateur (par exemple sur un serveur distant, etc.).
  • Aucune limitation n'est attachée à la nature de l'équipement utilisateur (ou UE pour « User Equipment » en anglais) auquel s'applique l'invention. Il peut s'agir d'un terminal tel qu'un téléphone intelligent (ou « smartphone »), un ordinateur portable, une tablette numérique, un objet connecté, mais également un routeur, etc. Par ailleurs, les différents modules de l'équipement utilisateur peuvent être hébergés par des entités physiques différentes.
  • On note que l'invention est décrite, eu égard au problème technique évoqué précédemment, en référence à un équipement utilisateur « dual SIM » ou « multi SIM » ; toutefois elle s'applique de manière plus générale à tout équipement utilisateur destiné à être utilisé par un utilisateur auquel est allouée une pluralité d'identifiants distincts l'identifiant chacun de manière unique sur au moins un réseau de communications. De tels identifiants sont par exemple des identifiants de type IMSI (International Mobile Subscriber Identifier) utilisés notamment dans les réseaux 4G ou de type SU-PI (SUbscription Permanent Identifier) utilisés notamment dans les réseaux 5G, ou encore de type adresse MAC (Medium Access Control) pour des réseaux non-3GPP de type WLAN (Wireless Access Network). Ce sont des identifiants qui sont alloués à l'utilisateur de façon indépendante les uns des autres et de façon permanente : en d'autres termes, ils sont invariants tant que l'utilisateur bénéficie d'un abonnement ou d'une souscription auprès d'un réseau. Ces identifiants peuvent être stockés respectivement, dans un mode particulier de réalisation, dans une pluralité de modules USIM embarqués et/ou de cartes réseaux dans l'équipement utilisateur.
  • Ainsi, dans un mode particulier de réalisation, l'invention concerne également un équipement utilisateur configuré pour recevoir une pluralité de modules USIM et/ou de cartes réseau, chaque carte ou chaque module étant associé(e) à un identifiant distinct de la pluralité d'identifiants alloués à l'utilisateur.
  • Cette pluralité d'identifiants identifient l'utilisateur et lui permettent de s'enregistrer via son équipement utilisateur auprès d'une pluralité de réseaux distincts (par exemple auprès de réseaux mobiles terrestres publics ou PLMN (pour Public Land Mobile Network) différents), ou auprès d'un même réseau mais en bénéficiant d'offres ou d'abonnements indépendant(e)s, associé(e)s chacun(e) à un identifiant de l'utilisateur différent (par exemple un « abonnement professionnel » et un « abonnement personnel » proposés par le même opérateur de réseau et s'appuyant sur la même infrastructure de réseau). Du point de vue des réseaux, ces identifiants sont gérés comme s'ils étaient alloués respectivement à autant d'utilisateurs différents.
  • L'invention propose de configurer (par exemple, automatiquement) un équipement d'un utilisateur disposant d'une pluralité d'identifiants permettant à l'équipement utilisateur d'accéder à un ou plusieurs réseaux, avec une ou plusieurs règles allouant une ou plusieurs tranches de ce ou de ces réseaux à au moins un flux d'une application. Chaque règle comprend préférentiellement un identifiant de l'application à laquelle elle se rapporte. On note que les règles peuvent associer à tous les flux d'une même application les mêmes tranches du ou des réseaux auxquels l'équipement utilisateur peut accéder via la pluralité d'identifiants alloués à l'utilisateur. Toutefois l'invention offre également, si besoin, une granularité supplémentaire permettant de distinguer les tranches de réseau à utiliser en fonction de différents types de flux pouvant être émis ou reçus par une même application, voire individuellement de chaque flux pouvant être émis ou reçu par une même application. Différents types de flux ou différents flux peuvent correspondre par exemple à des flux transportant des données de natures différentes (données audio, vidéo, texte, etc.), à des flux ayant des adresses de destination différentes, une adresse IP distante différente, un port distant différent, etc. Par exemple, les critères de différentiation de flux listés dans la table 5.2.1 de la spécification 3GPP TS 24.526 intitulée « User Equipment (UE) policies for 5G System (5GS) ; Stage 3 », v16.1.0, septembre 2019 peuvent être considérés.
  • En d'autres termes, les règles transmises à l'équipement utilisateur pour sa configuration tiennent compte du fait que celui-ci bénéficie d'une connectivité multiple grâce aux multiples identifiants qui sont alloués à l'utilisateur. Elles sont avantageusement établies en tenant compte des caractéristiques des tranches de réseau associées au(x) différent(s) réseau(x) auprès duquel/desquels l'équipement utilisateur peut s'enregistrer et des services associés à ces tranches de réseau compte tenu des spécificités des applications considérées. On note que les règles fournies à l'équipement utilisateur peuvent concerner des applications qui ne sont pas installées sur ce dernier ou qui ne seront pas exécutées par ce dernier ; elles ne sont dans ce cas pas prises en compte par celui-ci, et peuvent être supprimées le cas échéant de sa configuration.
  • Dans une variante de réalisation, les règles obtenues par l'équipement utilisateur concernent des applications installées sur celui-ci.
  • Par exemple, l'équipement utilisateur peut fournir à une entité en charge d'établir les règles les identifiants des applications qu'il héberge, lors de son enregistrement auprès du réseau ou des réseaux sur le(s)quel(s) l'utilisateur dispose d'identifiants, ou à tout autre moment (ex. lors de l'installation d'une nouvelle application).
  • L'information associée explicitement dans chaque règle à chaque tranche de réseau conformément à l'invention permet avantageusement de désigner de manière univoque le réseau auquel la tranche est rattachée si les identifiants alloués à l'utilisateur correspondent à des réseaux différents, ou si les tranches sont rattachées à un même réseau, l'identifiant que l'équipement utilisateur doit utiliser pour accéder à cette tranche de réseau.
  • Dans un mode particulier de réalisation, cette information comprend pour une tranche d'un réseau de communications :
    • ledit identifiant parmi ladite pluralité d'identifiants de l'utilisateur ;
    • un identifiant d'un module dudit terminal contenant ledit identifiant ; ou
    • un identifiant du réseau de communication pour lequel est alloué ledit identifiant audit utilisateur.
  • En d'autres termes, l'information associée à chaque tranche de réseau associée à un flux d'application contient soit une référence directe à l'identifiant de l'utilisateur à utiliser pour communiquer sur cette tranche de réseau, soit une référence indirecte à cet identifiant par le biais par exemple du module qui contient cet identifiant ou encore du réseau auquel il est rattaché (si les identifiants alloués à l'utilisateur l'identifie typiquement sur des réseaux différents). Dans l'exemple d'un équipement utilisateur multi-SIM, cette information permet ainsi de désigner la SIM auquel correspond la tranche en question et que l'équipement utilisateur doit utiliser pour le flux de l'application qui est associé à cette tranche.
  • Il résulte de l'invention qu'un équipement utilisateur multi-SIM peut ainsi recevoir des règles d'association entre applications (voire flux d'applications) et tranches de réseau pour chacune des modules USIM et/ou des cartes réseaux qu'il embarque. L'invention permet ainsi d'associer pour une application de l'équipement utilisateur, voire pour différents flux d'une même application de l'équipement utilisateur, un module USIM et une tranche du réseau correspondant. Les flux d'une même application peuvent donc être répartis sur différentes tranches de différents réseaux en fonction de la spécificité de chacun de ces flux : on ne se limite plus à une répartition statique en fonction d'un type de trafic échangé avec l'équipement utilisateur (voix, données, SMS). De la granularité offerte par l'invention découle une meilleure adaptation des caractéristiques du réseau aux spécificités de chaque application installée sur le terminal, une meilleure disponibilité des applications et des services offerts à l'utilisateur en découlant, et donc une expérience utilisateur améliorée par rapport à l'état de la technique.
  • Dans un mode particulier de réalisation, les règles obtenues par l'équipement utilisateur sont déterminées par une entité de gestion des règles. Cette entité de gestion des règles peut être située dans une passerelle de médiation entre les différents réseaux auprès desquels l'utilisateur est abonné ou si l'utilisateur est abonné auprès d'un seul réseau via des souscriptions différentes, dans ce réseau. En variante, elle n'est pas nécessairement associée aux réseaux et peut être une entité indépendante de ces derniers.
  • Ainsi, selon un autre aspect, l'invention vise également un procédé de gestion de règles, mis en oeuvre par une entité de gestion de règles, ce procédé comprenant, pour au moins un utilisateur auquel est allouée une pluralité d'identifiants identifiant respectivement ledit utilisateur de manière unique sur au moins un réseau de communications :
    • une étape de détermination d'au moins une règle associant à au moins un flux d'une application, au moins une tranche dudit au moins un réseau de communications pour un acheminement de données relatives audit au moins un flux et une information reliant ladite tranche à un identifiant parmi ladite pluralité d'identifiants dudit utilisateur ; et
    • une étape de transmission de ladite au moins une règle vers un l'équipement utilisateur de l'utilisateur.
  • Corrélativement, l'invention vise aussi une entité de gestion de règles comprenant :
    • un module de détermination, configuré pour déterminer au moins une règle associant à au moins un flux d'une application, au moins une tranche d'au moins un réseau de communications pour un acheminement de données relatives audit au moins un flux et une information reliant ladite tranche à un identifiant parmi une pluralité d'identifiants alloués audit utilisateur et identifiant respectivement ledit utilisateur de manière unique sur ledit au moins un réseau de communications ; et
    • un module de transmission configuré pour transmettre ladite au moins une règle vers un équipement utilisateur de l'utilisateur.
  • On note que selon le contexte considéré, la transmission de la règle vers l'équipement utilisateur peut se faire directement ou indirectement via une ou plusieurs entités des réseaux auprès desquels l'équipement utilisateur est abonné.
  • Par exemple, dans un mode particulier de réalisation, ladite au moins une règle est obtenue lors d'une association (ou d'un enregistrement ou d'un attachement) de l'équipement utilisateur audit au moins un réseau de communications.
  • De cette sorte, l'équipement utilisateur dispose automatiquement et sans délai des règles à appliquer pour accéder aux applications qu'il héberge ou auxquelles il est susceptible d'accéder. Ceci se fait de manière transparente pour l'utilisateur de l'équipement utilisateur.
  • En variante, les règles peuvent être configurées manuellement dans l'équipement utilisateur, par exemple par l'utilisateur de l'équipement utilisateur, via une interface utilisateur prévue à cet effet. Une telle interface est par exemple un menu de paramétrage disponible sur l'équipement utilisateur.
  • Selon une autre variante encore, les règles peuvent être configurées de manière statique dans le logiciel de l'équipement utilisateur.
  • Comme mentionné précédemment, les règles sont déterminées pour chaque application en tenant compte des différentes tranches de réseau et le cas échéant des différents réseaux disponibles. On note que préférentiellement, elles sont déterminées en tenant compte des caractéristiques et des souscriptions de chaque utilisateur, toutefois on peut envisager également, dans un mode particulier de réalisation, que les règles soient définies uniquement en fonction des spécificités des applications et que les mêmes règles soient envoyées à tous les utilisateurs, charge à eux ensuite de ne pas tenir compte des règles qui ne sont pas applicables. Elles peuvent par ailleurs tenir compte d'autres paramètres, comme par exemple des caractéristiques matérielles et/ou logicielles de l'équipement utilisateur.
  • Diverses configurations peuvent être envisagées pour chaque règle.
  • Ainsi, par exemple une même règle peut associer à un ou plusieurs flux d'une application une pluralité de tranches de réseau distinctes. Cette pluralité de tranches de réseau peut correspondre à un même réseau ou à des réseaux de communications distincts.
  • Dans ce mode de réalisation, l'application peut accéder simultanément aux différentes tranches de réseau identifiées par la règle, par exemple dans un souci de répartir la charge entre les différentes tranches de réseau.
  • En variante, une priorité d'utilisation peut être attribuée à chacune de ladite pluralité de tranches distinctes.
  • Si ces tranches sont rattachées à des réseaux distincts, cela permet à l'équipement utilisateur de déterminer quel réseau (par exemple, quel module USIM ou quelle carte réseau) il doit utiliser en premier lieu, et si celui-ci n'est pas accessible (par exemple parce que le module USIM ou la carte réseau correspondant(e) n'est pas activé(e) au sein de l'équipement utilisateur), une solution de repli.
  • Les priorités d'utilisation attribuées aux différentes tranches de réseau contenues dans une règle peuvent être attribuées, dans un mode particulier de réalisation, par l'entité de gestion des règles, par exemple de sorte à réaliser une répartition de charge sur les différentes tranches de réseau. En variante, d'autres critères peuvent être envisagés pour établir des priorités entre les tranches de réseau. Ces critères peuvent être liés à l'utilisateur plus particulièrement, par exemple en fonction de l'abonnement dont il dispose auprès du ou des réseaux concernés, ou de la couverture réseau dont il dispose, etc.
  • Les règles peuvent également contenir des instructions d'utilisation des tranches de réseau comprises dans les règles, comme par exemple dans une règle comprenant une pluralité de tranches de réseau distinctes, l'instruction de réaliser une répartition de la charge entre ces tranches de réseau distinctes, ou d'utiliser telle tranche de façon nominale et telle autre en secours, etc.
  • Par ailleurs, dans un mode particulier de réalisation, l'entité de gestion peut associer à chaque règle une priorité d'exécution de ladite règle.
  • Une telle priorité permet à l'équipement utilisateur, en cas de conflits entre deux règles déterminées pour deux applications différentes devant être exécutées simultanément (par exemple l'équipement utilisateur ne peut véhiculer de trafic qu'avec un réseau à un instant donné, et deux applications en cours d'exécution sont associées à des tranches de réseau appartenant à des réseaux distincts), de sélectionner la règle à appliquer en premier lieu. En variante, cette priorité peut être donnée à titre indicatif et l'équipement utilisateur peut décider d'agir autrement en cas de conflits.
  • Dans un mode particulier de réalisation de l'invention, le procédé de configuration et/ou le procédé de gestion de règles est mis en oeuvre par un ordinateur.
  • Dans un mode de réalisation non revendiqué, l'invention vise également un programme d'ordinateur sur un support d'enregistrement, ce programme étant susceptible d'être mis en oeuvre dans un ordinateur ou plus généralement dans un équipement utilisateur conforme à l'invention et comporte des instructions adaptées à la mise en oeuvre d'un procédé de configuration tel que décrit ci-dessus.
  • Dans un mode de réalisation non revendiqué, l'invention vise aussi un programme d'ordinateur sur un support d'enregistrement, ce programme étant susceptible d'être mis en oeuvre dans un ordinateur ou plus généralement dans une entité de gestion de règles conforme à l'invention et comporte des instructions adaptées à la mise en oeuvre d'un procédé de gestion de règles tel que décrit ci-dessus.
  • Chaque programme peut utiliser n'importe quel langage de programmation, et être sous la forme de code source, code objet, ou de code intermédiaire entre code source et code objet, tel que dans une forme partiellement compilée, ou dans n'importe quelle autre forme souhaitable.
  • Dans un mode de réalisation non revendiqué, l'invention vise aussi un support d'information ou un support d'enregistrement lisibles par un ordinateur, et comportant des instructions du programme d'ordinateur mentionné ci-dessus.
  • Le support d'information ou d'enregistrement peut être n'importe quelle entité ou dispositif capable de stocker les programmes. Par exemple, le support peut comporter un moyen de stockage, tel qu'une ROM, par exemple un CD ROM ou une ROM de circuit microélectronique, ou encore un moyen d'enregistrement magnétique, par exemple un disque dur, ou une mémoire flash.
  • D'autre part, le support d'information ou d'enregistrement peut être un support transmissible tel qu'un signal électrique ou optique, qui peut être acheminé via un câble électrique ou optique, par lien radio, par lien optique sans fil ou par d'autres moyens.
  • Le programme selon l'invention peut être en particulier téléchargé sur un réseau de type Internet.
  • Alternativement, le support d'informations ou d'enregistrement peut être un circuit intégré dans lequel un programme est incorporé, le circuit étant adapté pour exécuter ou pour être utilisé dans l'exécution du procédé de configuration, conforme à l'invention, ou du procédé de gestion de règles, conforme à l'invention.
  • Selon un autre aspect, l'invention vise un système comprenant :
    • au moins un équipement utilisateur selon l'invention, destiné à être utilisé par un utilisateur auquel est allouée une pluralité d'identifiants identifiant de manière unique ledit utilisateur sur au moins un réseau de communications ;
    • une entité de gestion des règles selon l'invention.
  • Dans un mode particulier de réalisation :
    • ledit au moins un réseau de communications comprend une pluralité de réseaux de communications ;
    • le module de transmission de ladite entité de gestion est configuré pour transmettre ladite au moins une règle à une entité gérant ledit utilisateur dans chaque réseau de communications ; et
    • chaque entité gérant ledit utilisateur dans chaque réseau de communications est configurée pour transmettre (directement ou indirectement) ladite au moins une règle audit équipement utilisateur de l'utilisateur lors d'une association dudit équipement utilisateur auprès de ce réseau de communications.
  • Dans un autre mode de réalisation, ladite pluralité d'identifiants est allouée à l'utilisateur par un unique réseau de communications et l'entité de gestion des règles est une entité de cet unique réseau de communications.
  • Dans un autre mode de réalisation encore, l'entité de gestion des règles est une entité indépendante dudit au moins un réseau.
  • Le système bénéficie des mêmes avantages que les procédés de configuration et de gestion de règles (ainsi que l'équipement utilisateur et l'entité de gestion des règles) selon l'invention, cités précédemment.
  • On peut également envisager, dans d'autres modes de réalisation, que le procédé de configuration, le procédé de gestion des règles, l'équipement utilisateur, l'entité de gestion des règles et le système selon l'invention présentent en combinaison tout ou partie des caractéristiques précitées.
    • Brève description des dessins
  • D'autres caractéristiques et avantages de la présente invention ressortiront de la description faite ci-dessous, en référence aux dessins annexés qui en illustrent un exemple de réalisation dépourvu de tout caractère limitatif. Sur les figures :
    • [Fig. 1] la figure 1, déjà décrite, représente une infrastructure réseau de l'état de la technique dans laquelle une technique de découpage par tranche est mise en oeuvre ;
    • [Fig. 2] la figure 2 représente un système conforme à l'invention dans un premier mode de réalisation ;
    • [Fig. 3] la figure 3 représente un exemple d'architecture matérielle d'une entité de gestion des règles conforme à l'invention, appartenant au système de la figure 2, dans un mode particulier de réalisation ;
    • [Fig. 4] la figure 4 représente un exemple d'architecture matérielle et fonctionnelle d'un équipement utilisateur conforme à l'invention, appartenant au système de la figure 2, dans un mode particulier de réalisation ;
    • [Fig. 5] la figure 5 illustre les principales étapes d'un procédé de gestion de règles tel qu'il est mis en oeuvre par l'entité de gestion de règles du système de la figure 2, dans le premier mode de réalisation ; et
    • [Fig. 6] la figure 6 illustre les principales étapes d'un procédé de configuration tel qu'il est mis en oeuvre par un équipement utilisateur du système de la figure 2, dans le premier mode de réalisation.
    Description de l'invention
  • Comme mentionné précédemment, l'invention s'inscrit dans le contexte des réseaux de communication utilisant des techniques de découpage par tranches ou network slicing.
  • Dans ce contexte, elle propose un mécanisme permettant de configurer un équipement utilisateur avec des règles, chaque règle associant un ou plusieurs flux d'une application donnée à une ou plusieurs tranches de réseau, ces tranches de réseau pouvant éventuellement être rattachées à des réseaux (ex. PLMN) distincts. A cet effet, l'équipement utilisateur est par exemple doté d'une pluralité de modules USIM et/ou de cartes réseaux lui permettant de s'associer à ces différents réseaux, ou à un seul réseau mais via diverses souscriptions (abonnements).
  • On note que l'invention s'applique à tout type d'applications (audio, vidéo, pour le transfert de texte, lecteur multimédia, etc.), temps réel ou non, pouvant être installées de manière native sur les équipements utilisateurs, ou téléchargées depuis un serveur d'applications, public ou géré par un fournisseur de services, ou encore par l'opérateur de l'un des réseaux, etc.
  • La figure 2 représente un système 1 conforme à l'invention, configuré pour la mise en oeuvre d'un tel mécanisme, dans un premier mode de réalisation.
  • Dans ce premier mode de réalisation, on suppose qu'un utilisateur U dispose d'un équipement utilisateur UE2, conforme à l'invention, et configuré pour recevoir une pluralité de cartes UICC (par exemple K cartes UICC, K désignant un entier supérieur ou égal à 2), chaque carte UICC stockant un module USIM. Chaque module USIMk, k désignant un entier compris entre 1 et K, comprend une application permettant à l'utilisateur U de s'enregistrer et d'accéder de manière sécurisée à un réseau de communications distinct NWk auprès duquel il a souscrit à un abonnement. A cet effet, chaque module USIMk stocke un identifiant IDk(U) alloué à l'utilisateur U par l'opérateur du réseau NWk. Cet identifiant l'identifie de manière unique et de manière permanente et invariante sur le réseau NWk (i.e. pendant toute la durée de son abonnement ou de sa souscription au réseau). On note que l'utilisateur U peut désigner indifféremment un utilisateur individuel ou un groupe d'utilisateurs, comme par exemple une collectivité.
  • Dans l'exemple sur la figure 2, les réseaux de communications NW1,...,NWK sont des réseaux 3GPP 5GS (5G System), et les identifiants IDk(U) sont des identifiants de type SUPI. Toutefois, aucune limitation n'est attachée à la nature des réseaux de communications NW1, NW2,...,NWK, ni à la nature des réseaux d'accès permettant d'y accéder. Il peut s'agir notamment de n'importe quels réseaux mobiles cellulaires tels que définis par le standard 3GPP (2G, 3G, 4G, 5G, etc.), ou d'autres types de réseaux, comme par exemple des réseaux fixes, des réseaux non-3GPP tels que des réseaux WLAN (Wireless Local Area Network) (ex. réseaux Wi-Fi (Wireless Fidelity)), etc.. Les identifiants IDk(U) dépendent de la nature des réseaux considérés. Ainsi, il peut s'agir par exemple en variante d'identifiants de type IMSI pour des réseaux 2G, 3G, 4G, d'une adresse MAC pour un réseau WLAN, etc.
  • On suppose que chaque réseau NWk met en oeuvre pour ses abonnés une technique de découpage en tranches, telle qu'évoquée dans la spécification 3GPP TS 23.501 citée précédemment. On note SL1(k),...,SLNk(k) les tranches disponibles du réseau NWk, Nk désignant un nombre entier supérieur ou égal à 1 correspondant aux nombres de tranches proposées par le réseau NWk, Nk pouvant varier d'un réseau NWk à l'autre, et étant susceptible d'évoluer dans le temps. Une telle technique de découpage en tranches est connue en soi et non décrite plus en détail ici. De façon connue, chaque tranche de réseau est identifiée de manière unique sur le réseau auquel elle appartient par un identifiant S-NSSAI (pour « Single Network Slice Sélection Assistance Information ») défini par le standard 3GPP dans les spécifications TS 23.501 et TS 23.003 intitulée « Technical Spécification Group Core Network and Terminals; Numbering, addressing and Identification », v16.0.0, septembre 2019.
  • Dans le premier mode de réalisation décrit ici, les règles, notées de façon générale RUL, utilisées pour la configuration de l'équipement utilisateur UE2 sont déterminées par une entité 3 de gestion de règles, conforme à l'invention, associée aux différents réseaux NW1,...,NWK, et hébergée dans une passerelle 4 de médiation s'interfaçant avec ces différents réseaux. Plus particulièrement ici, dans l'hypothèse de réseaux 5G, la passerelle 4 de médiation s'interface avec les entités PCF (Policy Control Function) de gestion de la politique des flux de chacun des réseaux NW1,...,NWK, référencées par PCF1,...,PCFK respectivement. De façon connue en soi, les entités PCF permettent le contrôle des politiques dans les réseaux 5GS, notamment au niveau des entités AMF (Access and Mobility Management Function) des réseaux NW1,...,NWK (référencées par AMF1,...,AMFK respectivement), chargées de l'enregistrement/attachement (ou plus généralement de l'association) des équipements utilisateurs auprès des réseaux NW1,...,NWK et de leur localisation.
  • On note que dans l'exemple envisagé à la figure 2, par souci de simplification, l'entité 3 de gestion des règles est associée aux K réseaux NW1,...,NWK correspondant aux K modules USIM de l'équipement utilisateur UE2, c'est-à-dire qu'elle définit des règles RUL pour les utilisateurs ayant souscrit à des abonnements auprès de ces réseaux et a, à cet effet, une visibilité sur les caractéristiques des tranches de réseau correspondant à ces différents réseaux. Toutefois cette hypothèse n'est pas limitative en soi. L'entité 3 de gestion des règles peut être associée à d'autres réseaux en supplément des réseaux NW1,...,NWK. Il peut s'agir également d'une entité indépendante des réseaux NW1,...,NWK (qui peut exploiter par exemple la connectivité de l'un des réseaux pour communiquer avec l'équipement utilisateur UE2 et découvrir par des informations que lui envoie l'équipement utilisateur UE2, les tranches offertes à celui-ci par chacun des réseaux).
  • Dans le mode de réalisation décrit ici, la passerelle 4 de médiation a l'architecture matérielle d'un ordinateur, telle que représentée schématiquement à la figure 3 , sur laquelle s'appuie l'entité 3 de gestion des règles. Elle comprend notamment un processeur 5, une mémoire vive 6, une mémoire morte 7, une mémoire flash non volatile 8, ainsi que des moyens de communication 9 comprenant une ou plusieurs interfaces de communication lui permettant de communiquer notamment avec les entités PGF des réseaux NW1,...,NWK.
  • Dans le mode de réalisation décrit ici, la mémoire morte 7 de la passerelle 4 de médiation est un support d'enregistrement conforme à l'invention, lisible par le processeur 5 et sur lequel est enregistré un programme d'ordinateur PROG4 selon l'invention, qui comporte des instructions définissant les principales étapes d'un procédé de gestion de règles conforme à l'invention. Le programme PROG4 définit de manière équivalente des modules fonctionnels de l'entité 3 de gestion des règles (et corrélativement de la passerelle 4 de médiation), qui s'appuient ou commandent les éléments matériels 5 à 9 cités précédemment. Ces modules fonctionnels comprennent notamment (cf. figure 2) :
    • un module 3A de détermination, configuré pour déterminer, pour au moins un équipement utilisateur, au moins une règle RUL telle que décrite plus en détail ultérieurement, associant une ou plusieurs tranches d'un ou de plusieurs réseaux à un ou plusieurs flux d'au moins une application ; et
    • un module 3B de transmission configuré pour transmettre ladite au moins une règle RUL vers le ou les équipements utilisateurs concernés. On note que cette transmission peut se faire de manière directe ou indirecte, via un ou plusieurs noeuds intermédiaires. Ainsi, dans le premier mode de réalisation décrit ici, les règles RUL sont envoyées vers les équipements utilisateurs concernés par l'intermédiaire des entités PCF et AMF des réseaux auxquels ils sont associés, comme décrit davantage ultérieurement.
  • Dans l'exemple envisagé à la figure 2, l'équipement utilisateur UE2 est un terminal, tel que par exemple un téléphone intelligent ou smartphone, un ordinateur, ou encore une tablette numérique.
  • La figure 4 illustre schématiquement un exemple d'architecture fonctionnelle et matérielle de l'équipement utilisateur UE2. Dans l'exemple de la figure 4, l'équipement utilisateur UE2 est un dispositif dit dual-SIM, c'est-à-dire qu'il est configuré pour recevoir deux modules USIM distincts, à savoir un module USIM1 et un module USIM2, lui permettant de s'associer respectivement aux deux réseaux NW1 et NW2.
  • De façon conventionnelle, l'équipement utilisateur UE2 comprend également un module TE (pour « Terminal Equipment » en anglais) et deux modules ME (pour « Mobile Equipment » en anglais). Chaque module ME comprend lui-même un module TA (pour « Terminal adaptator »), un module NT (pour « Network Termination ») et un module RT (pour « Radio Termination »). Ces différents modules communiquent entre eux via diverses interfaces (Cu, R, Tu, Uu) comme illustré sur la figure. De tels modules et interfaces sont connus en soi et décrits notamment dans le document de spécification 3GPP TS 21.905 intitulé « Technical Spécification Group Services and System Aspects; Vocabulary for 3GPP Spécifications », v15.1.0, décembre 2018, et au chapitre 9 du livre de A. Kukushkin intitulé « Introduction to Mobile Network Engineering: GSM, 3G-WCDMA, LTE and the Roard to 5G », John Wiley and Sons, 2018 (cf. figure 9.3 en page 123). L'interface Tu relie les parties spécifiques au réseau d'accès et au coeur de réseau dans l'équipement utilisateur ; elle est généralement propriétaire.
  • Le module TE de l'équipement utilisateur UE2 se distingue d'un module TE conventionnel en ce qu'il intègre ici différents modules configurés pour mettre en oeuvre un procédé de configuration selon l'invention, et plus particulièrement dans le premier mode de réalisation décrit ici :
    • un module 2A d'accès, configuré pour accéder via une interface applicative prévue à cet effet, à une pluralité d'applications Appj, j=1,...,J, J désignant un entier supérieur ou égal à 1, installées par exemple sur l'équipement utilisateur UE2 (par exemple dans une mémoire non volatile 10 de l'équipement utilisateur UE2). Dans l'exemple illustré à la figure 4, trois applications App1, App2 et App3 sont installées sur l'équipement utilisateur UE2 ;
    • un module 2B d'obtention, configuré pour obtenir au moins une règle RUL telle que déterminée par l'entité 3 de gestion des règles pour les applications installées sur l'équipement utilisateur UE2 ; et
    • un module 2C d'exécution, configuré pour exécuter ladite au moins une règle lors d'un accès aux applications installées sur l'équipement utilisateur UE2.
  • Dans le premier mode de réalisation décrit ici, les modules 2A, 2B et 2C sont par exemple des modules logiciels définis au moyen d'instructions d'un programme d'ordinateur PROG2, comprenant des instructions correspondant aux principales étapes d'un procédé de configuration selon l'invention.
  • On note que les applications Appj, j=1,...,J ne sont pas nécessairement des applications présentes nativement sur l'équipement utilisateur UE2 ; elles peuvent, au moins pour une partie d'entre elles, avoir été téléchargées ultérieurement sur l'équipement utilisateur UE2 depuis un serveur d'applications public ou privé. En outre, les applications et le nombre d'applications présentes sur l'équipement utilisateur UE2 sont susceptibles d'évoluer dans le temps (des applications peuvent être supprimées, d'autres ajoutées, si bien que les règles RUL configurées au niveau de l'équipement utilisateur UE2 sont également susceptibles d'évoluer dans le temps). On suppose ici que chaque application installée ou non sur l'équipement utilisateur UE2 et notée de manière générale App (par exemple App=App1, App2 ou App3 dans l'exemple envisagé sur la figure 4), est identifiée par un identifiant d'application noté IDApp. Aucune limitation n'est attachée à la forme de cet identifiant dès lors qu'il est compréhensible et connu de l'entité de gestion 3 et de l'équipement utilisateur UE2.
  • En variante, tout ou partie des applications APPj, j=1,...,J peut être installée sur une entité physique distincte de l'équipement utilisateur UE2, par exemple sur un serveur accessible par ce dernier.
  • Par ailleurs, aucune limitation n'est attachée à la nature de l'équipement utilisateur UE2. L'invention s'applique en effet également à d'autres types d'équipements utilisateurs que des terminaux, et notamment à des routeurs, ou à des équipements utilisateurs dont les modules TE et ME peuvent être répartis sur plusieurs entités physiques distinctes (par exemple en partie sur un terminal et en partie sur un routeur d'entreprise, etc.).
  • Nous allons maintenant décrire, en référence à la figure 5 , les différentes étapes du procédé de gestion de règles selon l'invention telles qu'elles sont mises en oeuvre par l'entité 3 de gestion des règles dans le premier mode de réalisation.
  • Dans ce premier mode de réalisation, les règles RUL sont déterminées par l'entité 3 de gestion des règles associée aux réseaux NW1,...,NWK, via son module de détermination 3A, lors d'une phase dite de provisionnement, pour une pluralité d'applications App (étape E10). Cette pluralité d'applications inclut notamment ici tout ou partie des applications Appj, j=1,...,J installées sur l'équipement utilisateur UE2 de l'utilisateur U.
  • En outre, dans le premier mode de réalisation décrit ici, l'entité 3 de gestion des règles détermine des règles RUL individuellement pour chaque utilisateur pour lequel elle est chargée de définir des règles (autrement dit ici, pour chaque utilisateur ayant souscrit un abonnement auprès des réseaux NW1,...,NWK auxquels l'entité 3 de gestion des règles est associée). A cet effet, l'entité 3 de gestion des règles tient compte des caractéristiques des abonnements/souscriptions de l'utilisateur auprès des opérateurs des réseaux NW1,...,NWK. On suppose à cet effet que l'entité 3 de gestion des règles est par exemple configurée avec des informations sur les souscriptions dont dispose chacun des utilisateurs pour lesquels elle doit définir des règles. En particulier, l'entité 3 de gestion des règles est configurée ici avec la liste des réseaux (ex. PLMN) auxquels ces utilisateurs ont accès via leurs équipements utilisateurs respectifs, les droits offerts par leurs abonnements, les attributs de qualité de service associés, les caractéristiques matérielles et logicielles des équipements utilisateurs des utilisateurs, etc. Bien entendu cette liste n'est ni exhaustive ni limitative de l'invention. Il ne s'agit que d'exemples illustratifs d'informations avec lesquelles l'entité 3 de gestion des règles peut être configurée et qu'elle peut utiliser pour définir les règles RUL. En outre, il convient de noter que ces informations sont susceptibles d'évoluer dans le temps et sont donc mises à jour dynamiquement au niveau de l'entité 3 de gestion des règles (par exemple de façon continue, ou à des intervalles de temps (pré)déterminés, ou encore sur détection d'un changement, etc.).
  • En variante, l'entité 3 de gestion des règles peut accéder à ces informations en consultant directement les opérateurs des réseaux auprès desquels les utilisateurs ont souscrit un abonnement ou en accédant à une base de données renseignée et mise à jour par ces opérateurs de sorte qu'elle reflète un état courant des abonnements souscrits par les utilisateurs auprès de ces opérateurs.
  • Selon une autre variante encore, une application installée dans les équipements utilisateurs des utilisateurs gérés par l'entité 3 de gestion des règles peut être configurée pour s'enregistrer auprès de l'entité 3 de gestion des règles et lui fournir ces informations.
  • On note que dans un autre mode de réalisation, l'entité 3 de gestion des règles peut déterminer des règles RUL non plus individuellement pour chaque utilisateur, mais par application, tous utilisateurs confondus.
  • Dans le premier mode de réalisation décrit ici, la pluralité d'applications pour laquelle l'entité 3 de gestion des règles détermine un ensemble de règles RUL pour chaque utilisateur est prédéfinie. Dans la suite de la description, on fait référence pour faciliter la compréhension aux règles établies pour l'utilisateur U, les considérations présentées s'appliquant toutefois indifféremment à tous les utilisateurs gérés par l'entité 3 de gestion de règles.
  • Il peut s'agir notamment d'applications pour lesquelles des accords ont été établis entre les fournisseurs des applications et les opérateurs des réseaux NW1,...,NWK associés à l'entité 3 de gestion des règles, ou ceux auprès desquels l'utilisateur U considéré a souscrit à un abonnement.
  • En variante, la pluralité d'applications peut être établie en fonction des services souscrits par l'utilisateur U auprès des réseaux NW1,...,NWK associés à l'entité 3 de gestion des règles. Elle peut également tenir compte des applications installées sur l'équipement utilisateur UE2 de l'utilisateur U. Ainsi, dans l'exemple envisagé à la figure 3, l'entité 3 de gestion des règles peut déterminer des règles pour les trois applications App1, App2 et App3 installées sur l'équipement utilisateur UE2. A cet effet, on peut envisager que l'équipement utilisateur UE2 informe l'entité 3 de gestion des règles des applications qu'il héberge via un réseau auquel il est associé par l'intermédiaire d'un de ses modules USIM. Alternativement, un tel réseau peut détecter qu'une application est installée sur l'équipement utilisateur UE2 (par analyse du trafic relatif à l'équipement utilisateur UE2) et en informer l'entité 3 de gestion des règles.
  • Comme mentionné précédemment, chaque règle déterminée par l'entité 3 de gestion des règles via son module 3A de détermination associe à au moins un flux d'une application App donnée, pour l'acheminement des données relatives à ce flux, au moins une tranche d'un réseau de communication parmi les réseaux NW1,...,NWK auprès desquels l'utilisateur U a souscrit un abonnement. Une règle différente peut être déterminée pour chaque flux distinct de l'application, pour une partie des flux (par exemple par type de flux), ou pour la totalité des flux de l'application, selon la granularité souhaitée. Répartir des flux d'une même application sur des tranches de réseau distinctes, par exemple en fonction de la nature (i.e. du type) de ces flux (ex. audio, vidéo, texte), peut permettre une meilleure adaptation des conditions de transmission de ces flux. Cela peut également permettre une répartition de la charge sur les différentes tranches de réseau disponibles.
  • Aucune limitation n'est attachée aux critères retenus pour associer les tranches de réseau aux flux de chaque application considérée par l'entité 3 de gestion des règles. L'entité 3 de gestion des règles dispose avantageusement d'une visibilité sur l'ensemble des tranches de réseau proposées par l'ensemble des réseaux NW1,...,NWK, si bien qu'elle peut associer à un flux d'une application des tranches de réseau appartenant à des réseaux différents.
  • Cette association peut être faite dynamiquement, en fonction de connaissances sur l'état des tranches de réseau disponibles correspondant aux différents réseaux NW1,...,NWK. Elle peut également s'appuyer sur la consultation d'une base de données interne à l'entité 3 de gestion des règles ou accessible sur un serveur externe par celle-ci associant à un identifiant d'application et/ou à un ou plusieurs identifiants de flux de ladite application, des tranches de réseau adaptées pour l'acheminement des données relatifs à ces flux. Une telle base de données peut être établie en concertation avec les opérateurs des réseaux NW1,...,NWK correspondants aux tranches de réseau disponibles.
  • Plus spécifiquement, conformément à l'invention, chaque règle déterminée pour un ou plusieurs flux d'une application pour l'utilisateur U associe à ce ou ces flux, au moins une tranche de réseau SLi(k) (i pouvant être égal à 1,...,Nk) et une information (explicite) liant cette tranche de réseau à l'identifiant IDk(U) identifiant l'utilisateur U de manière unique sur le réseau NWk (k pouvant être égal à 1,...K) auquel cette tranche de réseau appartient.
  • Dans le premier mode de réalisation, chaque identifiant IDk(U) identifiant l'utilisateur U sur un réseau NWk différent, cette information peut consister en un identifiant du réseau NWk, aussi couramment désigné par PLMNId et correspondant aux codes MCC (pour « Mobile Country Code » en anglais) et MNC (pour « Mobile Network Code » en anglais) du réseau NWk. En effet, cet identifiant de réseau désigne dans le premier mode de réalisation de façon univoque l'identifiant IDk(U) et donc le module USIMk que l'utilisateur U doit utiliser pour accéder à cette tranche de réseau.
  • En variante, cette information peut être l'identifiant IDk(U) lui-même, ou un identifiant d'un module de l'équipement utilisateur UE2 de l'utilisateur U contenant ledit identifiant IDk(U) (ex. module USIM ou carte réseau), tel un identifiant IGGid (numéro de série d'une carte UICC) ou eID.
  • Comme mentionné ci-avant, l'entité 3 de gestion des règles peut associer à chaque flux ou à un ensemble de flux d'une application une ou plusieurs tranches de réseau distinctes, sélectionnées par l'entité 3 de gestion des règles parmi les tranches de réseau offertes par les réseaux NW1,...,NWK. Chaque flux et chaque application concernés par une règle sont identifiés dans la règle par un identifiant permettant de les désigner de manière univoque auprès des réseaux et auprès de l'équipement utilisateur UE2. Lorsque plusieurs tranches de réseau sont associées à un même flux ou un même ensemble de flux, ces tranches de réseau peuvent appartenir à un même réseau ou à des réseaux différents. En outre, elles peuvent être associées à une priorité d'utilisation attribuée par l'entité 3 de gestion des règles ou la règle peut comprendre une ou plusieurs instructions d'utilisation de ces multiples tranches de réseau, comme par exemple une instruction de répartir la charge sur les différentes tranches de réseau.
  • Différents critères peuvent être considérés par l'entité 3 de gestion des règles pour attribuer une priorité d'utilisation à chaque tranche de réseau. Les priorités fixées par l'entité 3 de gestion des règles peuvent tenir compte par exemple des caractéristiques de l'abonnement de l'utilisateur U, et/ou des spécificités matérielles et/ou logicielles de l'équipement utilisateur UE2 de l'utilisateur U, ou viser la réalisation d'une répartition de charge sur les différentes tranches de réseau, etc.
  • A titre illustratif, des exemples de règles sont fournis dans la table 1 ci-dessous. [Table 1]
    RUL IDApp IDFlow Contexte S-NSSAI/PLMNId
    RUL1 App1 Flow1 Connectivité unique PRIO1: S-NSSAI1/PLMN1
    PRIO2: S-NSSAI1/PLMN2
    RUL2 App1 Flow1 Connectivité multiple S-NSSAI1/PLMN1
    S-NSSAI1/PLMN2
    RUL3 App1 Flow1 Connectivité multiple S-NSSAI1/PLMN1
    S-NSSAI1/PLMN2
    instruction : réaliser une répartition de charge entre les tranches
  • Dans cette table :
    • le champ « IDFlow » désigne les identifiants du ou des flux concernés par la règle ; on note que les flux concernés par les règles peuvent être désignés par leurs caractéristiques (par exemple un flux peut être désigné par son adresse de destination, le port qu'il utilise, etc.), sans avoir besoin nécessairement de recourir à un identifiant ;
    • le champ « Contexte » indique dans quel contexte de connectivité de l'équipement utilisateur la règle s'applique (selon s'il est dans une configuration où il bénéficie d'une connectivité unique, i.e. via un unique module USIM, ou d'une connectivité multiple simultanée) ; on note que ce contexte peut être transmis dans la règle ou être un pré-requis de l'équipement utilisateur ; et
    • le champ « S-NSSAI/PLMNId» désigne les tranches associées au flux, chaque tranche étant identifiée par un identifiant S-NSSAI et associée à une information permettant de relier cette tranche à un identifiant de l'utilisateur U l'identifiant de manière unique sur le réseau auquel appartient la tranche. Dans la table 1, cette information est l'identifiant du réseau NWk concerné (PLMNId). Chaque tranche peut également être associée à une priorité d'utilisation et/ou, lorsque plusieurs tranches sont désignées, une règle d'utilisation de ces tranches peut être ajoutée dans la règle.
  • En outre, lorsque des règles sont déterminées pour une pluralité d'applications, l'entité de gestion 3 peut insérer dans chaque règle une priorité d'utilisation de la règle pour hiérarchiser en quelque sorte l'accès aux tranches des réseaux NW1,...,NWK par les applications. Ces priorités d'utilisation visent à permettre une gestion des conflits entre règles pouvant se présenter au niveau de l'équipement utilisateur UE2 lors d'un accès concurrent à plusieurs applications simultanément. Par exemple, un tel conflit se présente lorsque plusieurs applications sont exécutées simultanément et que chaque règle associée à chaque application renvoie vers l'utilisation d'un réseau distinct alors que l'équipement utilisateur UE2 ne peut accéder qu'à un seul réseau à un instant donné (l'équipement utilisateur UE2 est alors dit « single active »). On note que ces priorités d'utilisation peuvent avoir une valeur contraignante pour l'équipement utilisateur UE2 (qui est alors tenu de les appliquer pour gérer les conflits entre applications), ou au contraire une valeur indicative que l'équipement utilisateur UE2 est libre de ne pas prendre en compte.
  • Ainsi, selon la règle RUL1, lorsque l'équipement utilisateur UE2 bénéficie d'une connectivité simple via l'un de ses modules USIM (i.e. il ne peut utiliser que l'un de ces modules à un instant donné, par exemple parce qu'il est configuré en mode « single active »), les flux d'identifiant Flow1 de l'application App1 sont associés en priorité (correspondant à « PRIO1 ») à la tranche du réseau NW1 (PLMNId=PLMN1) ayant l'identifiant S-NSSAI1, puis selon une priorité moindre (correspondant à « PRIO2 »), à la tranche du réseau PLMN2 ayant l'identifiant S-NSSAI1. En d'autres termes, selon cette règle RUL1, l'équipement utilisateur UE2 est tenu d'utiliser en priorité pour les flux correspondant à l'identifiant Flow1 de l'application App1 la tranche de réseau S-NSSAI1 du réseau NW1 (correspondant à l'identifiant PLMN1). S'il ne dispose pas de connectivité sur le réseau NW1 (par exemple parce que son module USIM1 est désactivé), alors il peut utiliser pour ces flux la tranche de réseau S-NSSAI1 du réseau NW2.
  • Selon la règle RUL2, lorsque l'équipement utilisateur UE2 bénéficie d'une connectivité multiple via ses deux modules USIM (i.e. il peut utiliser ses modules USIM1 et USIM2 simultanément), les flux d'identifiant Flow1 de l'application App1 peuvent être envoyés indifféremment sur la tranche du réseau NW1 (PLMNId=PLMN1) ayant l'identifiant S-NSSAI1, ou sur la tranche du réseau PLMN2 ayant l'identifiant S-NSSAI1.
  • Selon la règle RUL3, lorsque l'équipement utilisateur UE2 bénéficie d'une connectivité multiple via ses deux modules USIM (i.e. il peut utiliser ses modules USIM1 et USIM2 simultanément), les flux d'identifiant Flow1 de l'application App1 sont répartis sur la tranche du réseau NW1 (PLMNId=PLMN1) ayant l'identifiant S-NSSAI1 et sur la tranche du réseau PLMN2 ayant l'identifiant S-NSSAI1 de sorte à équilibrer la charge entre les deux tranches de réseau. A cet effet, l'équipement utilisateur UE2 peut avoir été préconfiguré pour gérer une répartition de la charge pour une ou plusieurs applications données.
  • On note qu'en variante, sur réception d'une règle associant à un ou plusieurs flux d'une application plusieurs tranches de réseau distinctes, en l'absence d'instruction complémentaire fournie par l'entité 3 de gestion des règles pour l'utilisation de ces multiples tranches de réseau, l'équipement utilisateur UE2 peut interroger l'entité 3 de gestion des règles sur la possibilité de répartir la charge entre ces tranches de réseau multiple, et mettre en oeuvre une telle répartition de charge sur réception d'une réponse positive de l'entité 3 de gestion des règles.
  • Bien entendu ces exemples ne sont donnés qu'à titre illustratif et d'autres exemples de règles peuvent être envisagés.
  • Une fois les règles RUL déterminées par l'entité 3 de gestion pour chaque utilisateur et pour chaque application, elles sont transmises par cette dernière via son module de transmission 3B vers les utilisateurs concernés (étape E20). Dans le premier mode de réalisation décrit ici, cette transmission est faite de manière indirecte via les réseaux NW1,...,NWK auprès desquels les utilisateurs ont souscrit un abonnement, et plus particulièrement via les entités PCF et AMF de ces résea ux.
  • Plus spécifiquement, dans le premier mode de réalisation décrit ici, lors de la phase de provisionnement, l'entité 3 de gestion des règles envoie à chaque entité PCFk, k=1,...,K de chaque réseau NWk, k=1,...,K, les règles RUL des utilisateurs ayant souscrit un abonnement auprès de ce réseau. Dans l'exemple de l'utilisateur U ayant souscrit un abonnement auprès des réseaux NW1,...,NWK, l'entité 3 de gestion des règles envoie ainsi les règles RUL(U) déterminées pour l'utilisateur U aux entités PCF1, PCF2,...PCFK des réseaux NW1,NW2,...,NWK. Cette transmission clôture la phase de provisionnement.
  • On note que l'entité 3 de gestion des règles peut, dans un souci de garantir l'intégrité et l'actualité des règles RUL(U) arrivant à l'équipement utilisateur U via les réseaux NW1,..,NWK, signer ces règles (de façon connue en soi et non décrite ici) et/ou leur associer un horodatage.
  • Nous allons maintenant décrire, en référence à la figure 6 , les différentes étapes du procédé de configuration selon l'invention telles qu'elles sont mises en oeuvre par l'équipement utilisateur UE2 de l'utilisateur U (et plus spécifiquement par son module TE) dans le premier mode de réalisation.
  • Dans ce premier mode de réalisation, les règles RUL(U) déterminées par l'entité 3 de gestion des règles pour l'utilisateur U sont transmises à l'équipement utilisateur UE2 lorsqu'ils s'associent aux différents réseaux NW1,...,NWK.
  • Plus spécifiquement, lorsqu'un module USIMk (k choisi parmi 1,...,K) est activé sur l'équipement utilisateur UE2 pour accéder au réseau NWk (manuellement par l'utilisateur U ou automatiquement, par exemple lors de la mise sous tension de l'équipement utilisateur UE2) (étape F10), l'équipement utilisateur UE2 s'associe par l'intermédiaire de son module USIMk au réseau NWk correspondant au moyen de l'identifiant IDk(U) identifiant l'utilisateur U de manière unique sur le réseau NWk (étape F20). Cette association peut consister, selon le réseau concerné, en un enregistrement (ou un attachement) de l'équipement utilisateur UE2 auprès du réseau NWk et plus particulièrement de l'entité AMFk du réseau NWk ici, et comprendre notamment une authentification de ce dernier au moyen de l'identifiant IDk(U). Une telle procédure est connue en soi et n'est pas décrite davantage ici.
  • Cette association déclenche l'obtention par l'équipement utilisateur UE2 des règles RUL(U) déterminées par l'entité 3 de gestion des règles pour l'utilisateur U pour une pluralité d'applications App (étape F30). Plus spécifiquement, l'entité AMFk auprès de laquelle s'associe l'équipement utilisateur UE2 sollicite l'entité PCFk pour obtenir les règles RUL(U) déterminées par l'entité 3 de gestion des règles. Sur réception de ces règles RUL(U), l'entité AMFk les transmet à l'équipement utilisateur UE2, et plus spécifiquement au module 2B du module TE de l'équipement utilisateur UE2, par exemple dans les règles URSP (UE Route Sélection Policy) définies par le standard 3GPP et décrites notamment dans le document 3GPP TS 24.526 cité précédemment.
  • Les règles RUL(U) ainsi obtenues sont transmises au module 2C d'exécution de l'équipement utilisateur UE2 pour interprétation et application. Elles sont mémorisées par ce dernier, par exemple dans la mémoire non volatile de l'équipement utilisateur UE2 (étape F40). Dès lors, le module TE est configuré pour exécuter par l'intermédiaire de son module d'exécution 2C les règles RUL(U) lorsque l'équipement utilisateur UE2 accède, via son module d'accès 2A à l'une des applications qu'il héberge (dans l'exemple de la figure 3, à l'une quelconque des applications App1, App2 et App3) (ou en variante, qui se trouve sur un serveur distant).
  • Cette opération est répétée pour chaque réseau NWk auquel l'équipement utilisateur UE2 s'associe en utilisant l'identifiant unique IDk(U) qui lui a été alloué par le réseau NWk. On note que l'équipement utilisateur UE2 peut de ce fait recevoir plusieurs fois les règles RUL(U). Dans une variante de réalisation, l'entité 3 de gestion des règles peut envoyer à l'équipement utilisateur UE2 des règles de priorité à appliquer le cas échéant entre les règles reçues des différents réseaux NWk, notamment si celles-ci diffèrent les unes des autres.
  • Sur détection par le module TE de l'équipement utilisateur UE2 d'un accès à une application Appj (réponse oui à l'étape test F50), le module 2C d'exécution identifie si au moins une règle parmi les règles RUL(U) concerne l'application Appj et le cas échéant, exécute lors de l'accès à l'application Appj la ou les règles identifiées, notées RUL(U)/Appj, pour l'acheminement des flux relatifs à cette application (étape F60). En d'autres termes, il émet et reçoit sur la ou les tranches de réseau associées aux flux indiquées dans les règles RUL(U)/Appj les flux de l'application selon les consignes indiquées dans les règles et le cas échéant, les priorités attribuées aux différentes tranches de réseau.
  • On note qu'en cas d'exécution simultanée de plusieurs applications et de règles en conflit, comme décrit précédemment, l'équipement utilisateur UE2 peut sélectionner la règle à exécuter en fonction d'une priorité d'utilisation fournie par l'entité 3 de gestion des règles dans chaque règle.
  • Par ailleurs, on note que si une nouvelle application est installée sur l'équipement utilisateur UE2 et que celui-ci ne dispose pas de règles pour cette application, il peut solliciter l'entité 3 de gestion des règles pour qu'elle lui fournisse une telle règle en lui indiquant par exemple l'identifiant de l'application nouvellement installée.
  • Ainsi grâce à l'invention, l'équipement utilisateur UE2 peut bénéficier des avantages combinés du « network slicing », d'une multiple connectivité, et d'un traitement différencié des applications pouvant aller jusqu'à une différenciation des flux relatifs à chaque application. Il en résulte une expérience utilisateur grandement améliorée par rapport à l'état de la technique, et ce de façon transparente pour l'utilisateur, la configuration de son équipement utilisateur UE2 pouvant se faire automatiquement sans nécessiter son intervention. On note toutefois que dans un mode particulier de réalisation, on peut envisager une configuration manuelle de l'équipement utilisateur UE2 par l'utilisateur U pour utiliser les règles RUL(U). L'utilisateur peut par exemple opérer une sélection parmi les règles qui lui sont proposées, ou supprimer celles qui ne concernent pas des applications installées sur son équipement utilisateur UE2, etc.
  • Dans le premier mode de réalisation qui vient d'être décrit en référence aux figures 2 à 6, les identifiants IDk(U) stockés dans les modules USIMk, k=1,...,K embarqués dans l'équipement utilisateur UE2 identifient l'utilisateur U sur des réseaux NW1,...,NWK distincts (par exemple, gérés par des opérateurs différents). Toutefois l'invention ne se limite pas à ce contexte. Elle peut également s'appliquer, dans un deuxième mode de réalisation, lorsque les les identifiants IDk(U) stockés dans les modules USIMk, k=1,...,K embarqués dans l'équipement utilisateur UE2 identifient l'utilisateur U sur un même réseau (ex. NW1=NW2=...=NWK correspondent à une même infrastructure de réseau gérée par un même opérateur et associée à un même code opérateur MCC-MNC), mais correspondent à des abonnements (ou offres de souscription) différents. Dans l'exemple illustré à la figure 4, le module USIM1 correspond par exemple à un abonnement personnel souscrit par l'utilisateur U auprès de l'opérateur d'un réseau NW1 (et correspondant à un identifiant ID1(U)) et le module USIM2 à un abonnement professionnel souscrit par l'utilisateur U auprès de l'opérateur du même réseau NW1 (et correspondant à un identifiant ID2(U)). Les identifiants ID1(U) et ID2(U) sont par exemple des identifiants IMSI ou SUPI identifiant de manière unique et distincte l'utilisateur U sur le réseau NW1 dans le cadre de ses deux abonnements. Ainsi, lorsque l'équipement utilisateur UE2 accède au réseau NW1 via l'abonnement personnel de l'utilisateur U, il utilise le module USIM1 pour s'associer au réseau NW1 et l'identifiant ID1(U) correspondant stocké dans le module USIM1. Lorsque l'équipement utilisateur UE2 accède au réseau NW1 via l'abonnement professionnel de l'utilisateur U, il utilise le module USIM2 pour s'associer au réseau NW1 et l'identifiant ID2(U) correspondant stocké dans le module USIM2.
  • Dans ce deuxième mode de réalisation, les tranches de réseau considérées par l'entité 3 de gestion des règles lors de l'étape E10 de détermination des règles appartiennent donc à un même réseau NW1. Toutefois elles peuvent correspondre à des abonnements différents de l'utilisateur U et donc à des qualités de service différentes, des accès à des services différents, etc. En d'autres termes, un utilisateur peut avoir accès à des tranches de réseau différentes selon l'abonnement et plus précisément le module USIM qu'il utilise pour accéder au réseau NW1. L'information reliant chaque tranche identifiée dans une règle à un identifiant IDk(U) de l'utilisateur U ne peut alors se limiter à un identifiant du réseau NW1 puisque celui-ci est le même pour chaque identifiant IDk(U) de l'utilisateur U. Dans le deuxième mode de réalisation, cette information consiste donc préférentiellement en l'identifiant IDk(U) lui-même correspondant au réseau considéré, ou en un identifiant du module USIM contenant l'identifiant IDk(U) et donc utilisé pour accéder au réseau considéré.
  • En outre, il convient de noter que dans le deuxième mode de réalisation, l'entité 3 de gestion des règles peut être intégrée dans une entité du réseau NW1. Dans ce cas, les règles RUL(U) peuvent être transmises directement par l'entité 3 de gestion des règles à l'équipement utilisateur UE2 lors de son association au réseau NW1 (quel que soit le module USIM utilisé) ou par l'intermédiaire, comme dans le premier mode de réalisation précédemment décrit, d'un ou de plusieurs modules PCF et AMF du réseau NW1 (on peut, selon l'architecture envisagée, considérée un même PCF et un même AMF pour les deux souscriptions, ou un PCF et un AMF dédiés pour chaque souscription).
  • Les autres étapes et modes de fonctionnement décrits en référence au premier mode de réalisation sont applicables au deuxième mode de réalisation.
  • On peut envisager également un troisième mode de réalisation dans lequel l'équipement utilisateur UE2 est configuré pour recevoir des modules USIM lui permettant de s'associer à des réseaux distincts et des modules USIM lui permettant de s'associer à un même réseau, correspondant à une combinaison des deux premiers modes de réalisation décrits. Préférentiellement, dans ce troisième mode de réalisation, l'entité 3 de gestion des règles est une entité externe aux réseaux considérés, et l'information reliant chaque tranche de réseau à un identifiant IDk(U) de l'utilisateur U est, comme dans le deuxième mode de réalisation, soit l'identifiant IDk(U) lui-même soit un identifiant du module contenant l'identifiant IDk(U).
  • Dans les trois modes de réalisation décrits précédemment, les règles RUL(U) sont fournies à l'équipement utilisateur UE2 lors de son association au(x) réseau(x) auprès duquel il a souscrit un abonnement. En variante, on peut envisager que ces règles RUL(U) soient fournies à d'autres moments, par exemple sur sollicitation de l'équipement utilisateur UE2 (suite à l'installation d'une nouvelle application, par exemple pour laquelle il ne dispose pas de règles), etc.
  • En outre, dans ces trois modes de réalisation, on a envisagé une configuration automatique de l'équipement utilisateur UE2 avec les règles fournies par l'entité 3 de gestion des règles, de façon transparente pour l'utilisateur U. Dans un quatrième mode de réalisation, on peut envisager que cette configuration soit mise en oeuvre par l'utilisateur U via une interface utilisateur de l'équipement utilisateur UE2, comme par exemple un menu de paramétrage disponible sur l'équipement utilisateur UE2 multi-SIM. A cet effet, l'équipement utilisateur UE2 dispose des identifiants de tranches de réseau auxquelles il a accès pour chaque réseau NWk pour lequel il dispose d'un identifiant unique IDk(U). L'utilisateur U, via l'interface utilisateur susmentionnée, peut alors définir les règles RUL(U) d'utilisation de ces différentes tranches pour tout ou partie des flux de chaque application installée sur son équipement utilisateur et configurer par ce biais l'équipement utilisateur pour qu'il utilise ces règles lorsqu'il accède à une application.
  • En variante, la configuration de l'équipement utilisateur peut être réalisée « en dur » dans le logiciel de l'équipement utilisateur en fonction de règles RUL(U) fournies par exemple par une entité externe telle que l'entité 3 de gestion des règles ou par l'utilisateur U.

Claims (21)

  1. Procédé de configuration d'un équipement utilisateur (UE2) destiné à être utilisé par un utilisateur (U) auquel est allouée une pluralité d'identifiants (ID1(U), ID2(U),...,IDK(U)), identifiant chacun de manière unique ledit utilisateur sur au moins un réseau de communications (NW1,...,NWK), ledit procédé étant mis en oeuvre par ledit équipement utilisateur et comprenant, pour au moins une application (Appj) :
    - une étape d'obtention (F30) d'au moins une règle associant à au moins un flux de ladite application, au moins une tranche dudit au moins un réseau de communications pour un acheminement de données relatives audit au moins un flux et une information reliant ladite tranche à un identifiant parmi ladite pluralité d'identifiants de l'utilisateur ;
    - une étape de configuration (F40) de l'équipement utilisateur avec ladite au moins une règle (RUL(U)/Appj) pour qu'il exécute (F60) ladite au moins une règle lors d'un accès à ladite application (F50).
  2. Procédé de configuration selon la revendication 1 dans lequel ladite au moins une règle est obtenue lors d'une association (F20) de l'équipement utilisateur audit au moins un réseau de communications.
  3. Procédé de configuration selon la revendication 1 ou 2 dans lequel ladite au moins une règle comprend une pluralité de tranches distinctes.
  4. Procédé de configuration selon la revendication 3 dans lequel, dans ladite au moins une règle, une priorité d'utilisation est attribuée à chacune de ladite pluralité de tranches distinctes.
  5. Procédé de configuration selon l'une quelconque des revendications 1 à 4 dans lequel les étapes d'obtention et de configuration de l'équipement utilisateur sont réalisées par l'intermédiaire d'une interface utilisateur disponible sur l'équipement utilisateur.
  6. Procédé de gestion de règles, mis en oeuvre par une entité (3) de gestion de règles, ledit procédé comprenant, pour au moins un utilisateur (U) auquel est allouée une pluralité d'identifiants (ID1(U), ID2(U),...,IDK(U)) identifiant respectivement ledit utilisateur de manière unique sur au moins un réseau de communications (NW1,...,NWK) :
    - une étape (E10) de détermination d'au moins une règle associant à au moins un flux d'une application, au moins une tranche dudit au moins un réseau de communications pour un acheminement de données relatives audit au moins un flux et une information reliant ladite tranche à un identifiant parmi ladite pluralité d'identifiants dudit utilisateur ; et
    - une étape (E20) de transmission de ladite au moins une règle vers un équipement utilisateur dudit utilisateur.
  7. Procédé de gestion de règles selon la revendication 6 comprenant en outre, une étape d'attribution, dans au moins une règle déterminée comprenant une pluralité de tranches dudit au moins un réseau de communications, d'une priorité d'utilisation à chaque tranche.
  8. Procédé de gestion de règles selon la revendication 6 ou 7 dans lequel au moins une règle déterminée comprenant une pluralité de tranches dudit au moins un réseau de communications comprend une instruction de réaliser une répartition de charge sur ladite pluralité de tranches.
  9. Procédé de gestion de règles selon l'une quelconque des revendications 6 à 8 dans lequel des règles associées à des flux d'applications différentes comprennent des priorités d'utilisation desdites règles.
  10. Procédé selon l'une quelconque des revendications 1 à 9 dans lequel ladite au moins une information comprend, pour une tranche d'un réseau de communications :
    - ledit identifiant parmi ladite pluralité d'identifiants de l'utilisateur ;
    - un identifiant d'un module dudit équipement utilisateur contenant ledit identifiant ; ou
    - un identifiant dudit réseau de communication pour lequel est alloué ledit identifiant audit utilisateur.
  11. Procédé selon l'une quelconque des revendications 1 à 10 dans lequel ladite au moins une règle comprend un identifiant de ladite application.
  12. Procédé selon l'une quelconque des revendications 1 à 11 dans lequel ladite application est une application installée sur ledit équipement utilisateur.
  13. Procédé selon l'une quelconque des revendications 1 à 12 dans lequel au moins deux desdits identifiants alloués à l'utilisateur identifient ledit utilisateur sur deux réseaux de communication différents.
  14. Procédé selon l'une quelconque des revendications 1 à 13 dans lequel au moins deux desdites identifiants alloués à l'utilisateur identifient ledit utilisateur sur un même réseau de communication.
  15. Procédé selon l'une quelconque des revendications 1 à 14 dans lequel au moins une règle associe une pluralité de tranches correspondant à des réseaux de communications distincts à au moins un flux d'une application.
  16. Equipement utilisateur (UE2) destiné à être utilisé par un utilisateur auquel est allouée une pluralité d'identifiants identifiant chacun de manière unique ledit utilisateur sur au moins un réseau de communications, ledit équipement utilisateur comprenant :
    - un module d'obtention (2B), configuré pour obtenir au moins une règle associant à au moins un flux d'une application, au moins une tranche dudit au moins un réseau de communications pour un acheminement de données relatives audit au moins un flux et une information reliant ladite tranche à un identifiant parmi ladite pluralité d'identifiants de l'utilisateur ;
    - un module d'exécution (2C), configuré pour exécuter ladite au moins une règle lors d'un accès à ladite application.
  17. Equipement utilisateur (UE2) selon la revendication 16, configuré pour recevoir une pluralité de modules USIM (Universal Subscriber Identity Module) et/ou de cartes réseaux, chaque carte et/ou chaque module (USIM1,...,USIMK) étant associé(e) à un identifiant (ID1(U),...,IDK(U)) distinct parmi ladite pluralité d'identifiants.
  18. Entité (3) de gestion de règles comprenant :
    - un module (3A) de détermination, configuré pour déterminer au moins une règle associant à au moins un flux d'une application, au moins une tranche d'au moins un réseau de communications pour un acheminement de données relatives audit au moins un flux et une information reliant ladite tranche à un identifiant parmi une pluralité d'identifiants alloués audit utilisateur et identifiant respectivement ledit utilisateur de manière unique sur ledit au moins un réseau de communications ; et
    - un module (3B) de transmission configuré pour transmettre ladite au moins une règle vers un équipement utilisateur dudit utilisateur.
  19. Système (1) comprenant :
    - au moins un équipement utilisateur (UE2) selon la revendication 16 ou 17, destiné à être utilisé par un utilisateur auquel est allouée une pluralité d'identifiants identifiant de manière unique ledit utilisateur sur au moins un réseau de communications ;
    - une entité (3) de gestion des règles selon la revendication 18.
  20. Système (1) selon la revendication 19 dans lequel :
    - ledit au moins un réseau de communications comprend une pluralité de réseaux de communications (NW1,..,NWK) ;
    - le module de transmission de ladite entité de gestion est configuré pour transmettre ladite au moins une règle à une entité (PCF1,...,PCFK) gérant ledit utilisateur dans chaque réseau de communications ; et
    - chaque entité (PCF1,...,PCFK) gérant ledit utilisateur de chaque réseau de communications est configurée pour transmettre ladite au moins une règle audit équipement utilisateur lors d'une association dudit équipement utilisateur auprès de ce réseau de communications.
  21. Système (1) selon la revendication 19 dans lequel ladite pluralité d'identifiants est allouée à l'utilisateur par un unique réseau de communications (NW1) et l'entité (3) de gestion des règles est une entité de cet unique réseau de communications.
EP20845789.5A 2019-12-23 2020-12-18 Procédé de configuration d'un equipement utilisateur, equipement utilisateur, entite de gestion de regles, procédé de gestion de règles et système Active EP4082232B1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR1915479A FR3105694A1 (fr) 2019-12-23 2019-12-23 Procédé de configuration d’un équipement utilisateur, équipement utilisateur, et entité de gestion de règles
PCT/FR2020/052525 WO2021130440A1 (fr) 2019-12-23 2020-12-18 Procede de configuration d'un equipement utilisateur, equipement utilisateur, et entite de gestion de regles

Publications (3)

Publication Number Publication Date
EP4082232A1 EP4082232A1 (fr) 2022-11-02
EP4082232C0 EP4082232C0 (fr) 2024-08-14
EP4082232B1 true EP4082232B1 (fr) 2024-08-14

Family

ID=70008807

Family Applications (1)

Application Number Title Priority Date Filing Date
EP20845789.5A Active EP4082232B1 (fr) 2019-12-23 2020-12-18 Procédé de configuration d'un equipement utilisateur, equipement utilisateur, entite de gestion de regles, procédé de gestion de règles et système

Country Status (9)

Country Link
US (1) US11962487B2 (fr)
EP (1) EP4082232B1 (fr)
JP (1) JP7642646B2 (fr)
KR (1) KR102889642B1 (fr)
CN (1) CN115053549B (fr)
BR (1) BR112022012370A2 (fr)
ES (1) ES2994298T3 (fr)
FR (1) FR3105694A1 (fr)
WO (1) WO2021130440A1 (fr)

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN113840312B (zh) * 2021-10-25 2023-09-05 全球能源互联网研究院有限公司 一种5g网络切片业务的配置方法及装置
WO2025074383A1 (fr) * 2023-10-04 2025-04-10 Jio Platforms Limited Système et procédé de gestion de distribution de charge de tranche de réseau dans un réseau

Family Cites Families (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9497102B2 (en) * 2011-12-06 2016-11-15 Qualcomm Incorporated Systems and methods for machine to machine device control and triggering
EP3188550A1 (fr) * 2015-12-30 2017-07-05 Deutsche Telekom AG Procede destine a l'etablissement d'une liaison de communication d'un appareil de communication par une tranche de reseau de communication
WO2018141081A1 (fr) * 2017-02-02 2018-08-09 Qualcomm Incorporated Partage de couche physique multi-abonnement assisté par réseau
CN108632945B (zh) * 2017-03-20 2020-11-06 华为技术有限公司 一种网络切片选择方法、用户设备及网络设备
KR102284317B1 (ko) * 2017-04-01 2021-07-30 후아웨이 테크놀러지 컴퍼니 리미티드 통신 방법, 코어 네트워크 디바이스 및 액세스 네트워크 디바이스
FR3067197A1 (fr) * 2017-06-01 2018-12-07 Orange Procede de selection d'une tranche de reseau relative a une application
EP3695653B1 (fr) 2017-10-11 2025-09-24 Nec Corporation Configuration et mise à jour d'ue avec une politique de sélection de tranche de réseau
US11303527B2 (en) * 2018-01-19 2022-04-12 Koninklike Kpn N.V. Network slice usage
WO2020252281A1 (fr) * 2019-06-14 2020-12-17 Convida Wireless, Llc Appareil, système et procédé pour apporter des améliorations à un tranchage de réseau et à l'architecture de politique d'un réseau 5g
US11070422B2 (en) * 2019-09-16 2021-07-20 Cisco Technology, Inc. Enabling enterprise segmentation with 5G slices in a service provider network

Also Published As

Publication number Publication date
ES2994298T3 (en) 2025-01-21
JP7642646B2 (ja) 2025-03-10
CN115053549B (zh) 2025-02-25
US11962487B2 (en) 2024-04-16
FR3105694A1 (fr) 2021-06-25
EP4082232A1 (fr) 2022-11-02
EP4082232C0 (fr) 2024-08-14
US20230030528A1 (en) 2023-02-02
JP2023508371A (ja) 2023-03-02
WO2021130440A1 (fr) 2021-07-01
KR102889642B1 (ko) 2025-11-20
KR20220119126A (ko) 2022-08-26
BR112022012370A2 (pt) 2022-09-27
CN115053549A (zh) 2022-09-13

Similar Documents

Publication Publication Date Title
EP4087305B1 (fr) Sélection d'une tranche de réseau relative à une application
EP3503508B1 (fr) Procédé de traitement de requêtes et serveur proxy
EP3427449B1 (fr) Sélection d'une instanciation de tranche de réseau pour la transmission de paquets montants
EP3298812B1 (fr) Chargement de profil d'abonnement dans une carte sim embarquée
WO2018229425A1 (fr) Procédé de configuration d'un terminal
EP2327200B1 (fr) Procede d'obtention d'informations d'un environnement local d'un terminal
EP3807760B1 (fr) Procédé d'installation d'une fonction réseau virtualisée
EP2625925B1 (fr) Identification d'un reseau hôte d'un terminal utilisateur d'une organisation
EP4082232B1 (fr) Procédé de configuration d'un equipement utilisateur, equipement utilisateur, entite de gestion de regles, procédé de gestion de règles et système
FR3121568A1 (fr) Procédés de gestion, d’enregistrement et de communication et entités configurées pour mettre en œuvre ces procédés
EP3014502B1 (fr) Architecture réseau coopérative
EP2638717B1 (fr) Terminal et procede pour transmettre un identifiant d'abonnement
WO2020120850A1 (fr) Terminal pouvant être connecté simultanément à plusieurs réseaux d'accès, procédé de différentiation de trafic émis par le terminal, dispositif et procédé de gestion du trafic
WO2009125145A1 (fr) Procede d'obtention de donnees relatives a la configuration d'un equipement terminal et serveur
EP3545711A1 (fr) Sélection d'une infrastructure de télécommunication
EP4335144A1 (fr) Parametrage d'un terminal
FR2973628A1 (fr) Procedes de resolution d'identifiants d'abonnes, de mise a jour d'une table de resolution d'adresses de routeurs d'acces et de mise a jour d'une table de resolution d'adresses ip de rattachement

Legal Events

Date Code Title Description
STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: UNKNOWN

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE INTERNATIONAL PUBLICATION HAS BEEN MADE

PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: REQUEST FOR EXAMINATION WAS MADE

17P Request for examination filed

Effective date: 20220627

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO RS SE SI SK SM TR

DAV Request for validation of the european patent (deleted)
DAX Request for extension of the european patent (deleted)
REG Reference to a national code

Ref country code: DE

Ref legal event code: R079

Free format text: PREVIOUS MAIN CLASS: H04W0008180000

Ipc: H04W0060000000

Ref country code: DE

Ref legal event code: R079

Ref document number: 602020035933

Country of ref document: DE

Free format text: PREVIOUS MAIN CLASS: H04W0008180000

Ipc: H04W0060000000

GRAP Despatch of communication of intention to grant a patent

Free format text: ORIGINAL CODE: EPIDOSNIGR1

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: GRANT OF PATENT IS INTENDED

RIC1 Information provided on ipc code assigned before grant

Ipc: H04W 88/06 20090101ALN20230911BHEP

Ipc: H04W 8/06 20090101ALN20230911BHEP

Ipc: H04W 8/18 20090101ALI20230911BHEP

Ipc: H04W 48/18 20090101ALI20230911BHEP

Ipc: H04L 41/0894 20220101ALI20230911BHEP

Ipc: H04L 41/0853 20220101ALI20230911BHEP

Ipc: H04W 60/00 20090101AFI20230911BHEP

INTG Intention to grant announced

Effective date: 20231017

RAP3 Party data changed (applicant data changed or rights of an application transferred)

Owner name: ORANGE

GRAJ Information related to disapproval of communication of intention to grant by the applicant or resumption of examination proceedings by the epo deleted

Free format text: ORIGINAL CODE: EPIDOSDIGR1

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: REQUEST FOR EXAMINATION WAS MADE

GRAP Despatch of communication of intention to grant a patent

Free format text: ORIGINAL CODE: EPIDOSNIGR1

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: GRANT OF PATENT IS INTENDED

INTC Intention to grant announced (deleted)
RIC1 Information provided on ipc code assigned before grant

Ipc: H04W 88/06 20090101ALN20240221BHEP

Ipc: H04W 8/06 20090101ALN20240221BHEP

Ipc: H04W 8/18 20090101ALI20240221BHEP

Ipc: H04W 48/18 20090101ALI20240221BHEP

Ipc: H04L 41/0894 20220101ALI20240221BHEP

Ipc: H04L 41/0853 20220101ALI20240221BHEP

Ipc: H04W 60/00 20090101AFI20240221BHEP

INTG Intention to grant announced

Effective date: 20240313

GRAS Grant fee paid

Free format text: ORIGINAL CODE: EPIDOSNIGR3

GRAA (expected) grant

Free format text: ORIGINAL CODE: 0009210

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE PATENT HAS BEEN GRANTED

AK Designated contracting states

Kind code of ref document: B1

Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO RS SE SI SK SM TR

REG Reference to a national code

Ref country code: GB

Ref legal event code: FG4D

Free format text: NOT ENGLISH

REG Reference to a national code

Ref country code: CH

Ref legal event code: EP

REG Reference to a national code

Ref country code: DE

Ref legal event code: R096

Ref document number: 602020035933

Country of ref document: DE

REG Reference to a national code

Ref country code: IE

Ref legal event code: FG4D

Free format text: LANGUAGE OF EP DOCUMENT: FRENCH

U01 Request for unitary effect filed

Effective date: 20240912

U07 Unitary effect registered

Designated state(s): AT BE BG DE DK EE FI FR IT LT LU LV MT NL PT RO SE SI

Effective date: 20240930

U20 Renewal fee for the european patent with unitary effect paid

Year of fee payment: 5

Effective date: 20241121

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: NO

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20241114

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: PL

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20240814

Ref country code: GR

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20241115

REG Reference to a national code

Ref country code: ES

Ref legal event code: FG2A

Ref document number: 2994298

Country of ref document: ES

Kind code of ref document: T3

Effective date: 20250121

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: IS

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20241214

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: HR

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20240814

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: RS

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20241114

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: RS

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20241114

Ref country code: PL

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20240814

Ref country code: NO

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20241114

Ref country code: IS

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20241214

Ref country code: HR

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20240814

Ref country code: GR

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20241115

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: SM

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20240814

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: CZ

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20240814

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: SK

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20240814

PLBE No opposition filed within time limit

Free format text: ORIGINAL CODE: 0009261

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: NO OPPOSITION FILED WITHIN TIME LIMIT

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: MC

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20240814

26N No opposition filed

Effective date: 20250515

REG Reference to a national code

Ref country code: CH

Ref legal event code: PL

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: CH

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20241231

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: IE

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20241218

U20 Renewal fee for the european patent with unitary effect paid

Year of fee payment: 6

Effective date: 20251119

PGFP Annual fee paid to national office [announced via postgrant information from national office to epo]

Ref country code: GB

Payment date: 20251120

Year of fee payment: 6

U1N Appointed representative for the unitary patent procedure changed after the registration of the unitary effect

Representative=s name: KILBURN & STRODE LLP; GB

PGFP Annual fee paid to national office [announced via postgrant information from national office to epo]

Ref country code: ES

Payment date: 20260102

Year of fee payment: 6