Method for managing access to a traffic policy management function and associated device

Abstract

The invention relates to a method for managing access to a traffic policy management function (111), the function being implemented by a terminal (100) connected to a telecommunications network (200), the method comprising the following steps, implemented by an operating system (110) of this terminal (100): checking that a computer application (120) of the terminal (100) wishing to access the traffic policy management function (111) is authorized to invoke this function, using an authorization procedure implemented via the telecommunications network and selected by a controller (210) of the telecommunications network (200); and authorizing the computer application to access the function (111) based on a result of the check.

Description

Description Title of the invention: Method for managing access to a traffic policy management function and associated device Technical Field [1] The present invention belongs to the general field of telecommunications. It relates more particularly to a method for managing access to a traffic policy management function, a method for accessing a traffic policy management function, and a terminal configured to implement such methods. [2] It also relates to a method for controlling access to a traffic policy management function, and a controller of a telecommunications network configured to implement this access control method. [3] The present invention also relates to a general method for accessing a traffic policy management function, as well as a system for accessing a traffic policy management function comprising the terminal and the controller. [4] The invention finds a particularly advantageous, although in no way limiting, application in the case of a fifth generation (5G) telecommunications network. Prior art [5] In order to adapt to the continuous and ever-increasing growth of data traffic emitted by telecommunications systems, various technologies are being implemented to improve the efficiency of telecommunications networks. These mechanisms are still being refined with a view to optimal operation in the years to come. [6] Among the various technologies implemented, the "differential treatment of telecommunications network traffic" (hereinafter referred to as "differential treatment") aims in particular to prevent or even better manage network congestion. Such congestion can typically occur when data packets transiting on this network are in competition with other packets also seeking to access the resources of this network. Differential treatment can also be applied to ensure that service level agreements ("Service Level Agreement" in English terminology) are respected. [7] Different actions can be implemented within this framework, such as packet scheduling, selecting one or more paths that minimize transmission delay, or selecting a path that guarantees a certain level of service (including a level of security). More generally, differentiated treatment includes different ways in which data packets can be treated differently from each other during their routing to their respective recipients through one or more telecommunications networks. Thus, the scope of differentiated treatment encompasses classical scheduling, shaping and queue management techniques by which data packets are processed, for example, at the node level of a network, but also techniques by which data streams are separated and / or routed through different physical or logical paths of the network. [8] Telecommunications network operators commonly use this differentiated treatment, for example to adapt the quality of service offered to a customer according to a subscription level, to manage the traffic of a large number of customers likely to cause network congestion, to prioritize the transmission of control or signaling data on the network, to guarantee the provision of a service according to a certain quality of service, for example defined within the framework of a service level agreement, or to ensure a balance between signaling, voice and multimedia data, so as to guarantee a certain user experience ("Quality of Experience" according to Anglo-Saxon terminology). [9] To do this, operators define service policies that include flow or packet classification policies, scheduling policies and / or routing policies that are typically formalized in the form of rules.

[0010] The fact remains that these rules defined and implemented by operators are not necessarily adapted to the needs of a particular terminal wishing to access a particular remote application. Indeed, these needs may depend in particular on the characteristics of the terminal, the application itself (e.g. whether or not it relies on voice communications, streaming video and / or the use of a web browser), options subscribed to or not with the manager or supplier of this application, etc.

[0011] There is therefore a need to improve existing solutions in terms of traffic processing, in order to optimize the quality of service offered, but also the experience as perceived by a user. Statement of the invention

[0012] The present invention aims to remedy all or part of the drawbacks of the prior art, in particular those set out above, by proposing a solution which allows a computer application of a terminal to access a traffic policy management function, under the control of the telecommunications operator.

[0013] To this end, and according to a first aspect, the invention relates to a method for managing access to a traffic policy management function, the function being implemented by a terminal connected to a telecommunications network (such a function typically being exposed via a local API). The method comprises the following steps, implemented by an operating system of said terminal:

[0014] - a verification that a computer application of the terminal wishing to access the traffic policy management function is authorized to invoke this function, using an authorization procedure implemented via the telecommunications network and selected by a telecommunications network controller; and,

[0015] - authorization to access the function by said computer application, based on a result of the verification.

[0016] Generally speaking, it is considered that the steps of a process should not be interpreted as being linked to a notion of temporal succession.

[0017] As mentioned above, "traffic policy management" means an adaptation of the way in which data packets are treated differently from one another during their routing to their respective recipients through one or more telecommunications networks (also referred to as "differentiated traffic policy"). This adaptation includes in particular the ordering of packets, the management of queues by which data packets are processed, the separation of data flows, the routing of data flows through different physical or logical paths of the telecommunications network, the invocation of an acceleration or encoding function supported by the hardware, the selection of a class or a network slice, etc.

[0018] As is well known, a "computer application" is a computer program used to provide one or more services. Generally, applications are deployed using a client / server model. Applications are deployed on an electronic device (such as a user terminal or a server), and run using the services of the operating system of the device on which they are deployed, to use the software and / or hardware resources of that device. The application embedded in a device is usually the "client" part but the server mode is also covered (e.g. video content streaming server). No assumption is made about the nature of the application.

[0019] The "operating system", often called "OS" (acronym for "operating system") is a set of programs that acts as an intermediary between the resources of the electronic device and the computer applications of this device. The operating system manages in particular the use of storage resources (for example access to RAM and / or mass memories), computing resources, and / or resources in terms of communication with peripherals or via the telecommunications network.

[0020] For the purposes of the invention, this operating system is considered to be trusted by the telecommunications network operator. Thus, this operating system meets certain security standards required by this operator, which are for example compliant with the "common criteria" certifications. These common criteria are a set of internationally recognized standards (ISO / IEC 15408) whose objective is to impartially evaluate the security of computer systems and software.

[0021] The "telecommunications network controller" is a software module deployed on an electronic device of the telecommunications network, or which is provided or located with an element of the telecommunications network. Thus, when the telecommunications network considered corresponds to a 5G network, this controller is for example provided by the SMF entity (acronym for "Session Management Function") which is typically responsible for managing the network control plane, and more specifically for controlling PDU sessions (acronym for "Packet Data Unit"). This SMF entity is notably described in the technical specification 3GPP TS 29.502, 5G System; Session Management Services; Stage 3, V18.4.0, published in September 2023.

[0022] Alternatively, this telecommunications network controller is integrated into an SDN (Software-Defined Networking) network controller. As is commonly known, an SDN network controller is an entity in a telecommunications network that allows network resources to be optimized and the network to be quickly adapted to changing business, application, and traffic needs. An SDN network controller provides network orchestration, management, statistics collection, and automation functions.

[0023] The authorization procedure is selected by the telecommunications network, and implemented at least in part by this same telecommunications network, which thus allows the network operator to control - that is to say to authorize or not - the computer application to access this traffic policy management function. As discussed in more detail below, this authorization procedure may include one or more distinct authorization mechanisms, such as a verification based on identification data of this computer application and / or a verification that the computer application is validly authenticated to the telecommunications network.

[0024] If this computer application is actually authorized to invoke (or call) this function, for example because it has been identified as a trusted application on the basis of its identifier and / or it is validly authenticated to the telecommunications network, the operating system, which then plays a sort of firewall role, authorizes access to this traffic policy management function.

[0025] More precisely, the operating system then allows this application to invoke functionalities (or primitives) of this traffic policy management function, but also to obtain a result representative of an implementation of these functionalities.

[0026] If, on the other hand, this application is not authorized to access this function, the operating system will then block access to the traffic policy management function by the computer application. In addition, this access ban may also result in the operating system refusing to invoke this function. In this case, in response to a new invocation of the traffic policy management function by this same computer application, the operating system ignores this new invocation, or even blocks any new attempt to invoke the function.

[0027] In particular modes of implementation, the access management method may further comprise one or more of the following characteristics, taken in isolation or in all technically possible combinations.

[0028] In particular modes of implementation, the method for managing access further comprises a reception, by the operating system and from the controller of the telecommunications network, of data representing computer applications authorized or not to manage the traffic policy, and of data representing an authentication mechanism of a computer application wishing to access the function of managing a traffic policy with said network. telecommunication; and the verification that the computer application is authorized to manage the traffic policy is implemented based on said data received.

[0029] In particular implementation modes, the "data identifying computer applications authorized or not to manage the traffic policy" comprises or makes it possible to determine identifiers of computer applications of the terminal which are authorized to manage the traffic policy, and the verification that said computer application is authorized to manage the traffic policy comprises a comparison between the identifier of said computer application and the identifiers of computer applications of the terminal which are authorized to manage the traffic policy.

[0030] In particular implementation modes, the verification is implemented in response to a call to the traffic policy management function by the computer application of said terminal. More precisely, the verification may be conditioned by the detection, by the operating system, of a call to this management function.

[0031] In particular modes of implementation, the function of managing a traffic policy and, where appropriate, the functionality(s) or primitive(s) of this function, are presented by the operating system to the computer application through an application programming interface (or API, acronym for "application programming interface").

[0032] According to a second aspect, the invention relates to a method of accessing a traffic policy management function, the function being implemented by a terminal connected to a telecommunications network, the method comprising the following steps implemented by a computer application of said terminal:

[0033] - an invocation of the traffic policy management function;

[0034] - a transmission, to an operating system of the terminal, of an authentication element received from an authentication system of the telecommunications network and required by an authorization procedure selected and implemented via the telecommunications network; and,

[0035] - access to said traffic policy management function, based on the result of the authorization procedure.

[0036] For the purposes of the invention, the authentication system may comprise only the telecommunications network controller previously mentioned, or the telecommunications network controller coupled with an authentication manager. One or more controllers may be deployed.

[0037] It is also important to remember that the steps of a method should not be interpreted as being linked to a notion of temporal succession. Also, the transmission step mentioned above can be implemented before the step of invoking the traffic policy management function, and vice versa. Furthermore, as discussed in more detail below, these two steps of invocation and transmission can also correspond to a single step.

[0038] Thus, in particular implementations, the authentication element includes an authentication token passed to the operating system when the function is invoked.

[0039] In particular modes of implementation, the access method further comprises a transmission, to the operating system, of terminal identification data and / or a timestamp.

[0040] This transmission of the terminal identification data and / or the time stamp may correspond to a transmission distinct from the invocation and the transmission previously mentioned, or correspond to a single step. In the latter case, the terminal identification data and / or the time stamp may then be transmitted as a parameter of the invocation of the function.

[0041] In particular implementations, the authentication element includes a response associated with a challenge transmitted to the operating system following receipt of the challenge from the operating system.

[0042] In particular implementations, the traffic policy management function includes adding, deleting and / or modifying a traffic classification rule generated by a telecommunications network manager. This manager corresponds, for example, to the telecommunications operator or a service manager of the telecommunications network.

[0043] In particular modes of implementation, the function of managing a traffic policy comprises the addition of a rule for associating at least one flow of a communication with the terminal with at least one network slice of the telecommunications network accessible by said terminal.

[0044] Recent developments in fifth-generation networks now make it possible to create tailor-made logical subnetworks based on the same physical network infrastructure. These logical subnetworks are called "network slices" and allow a customer to access a service by relying on both virtualized network functions which can be activated, deactivated and configured according to needs, but also by relying on network functions deployed on a physical network infrastructure. Thus, adding a rule relating to the use of a specific network slice for at least one flow of a communication between the terminal and a service accessible through the telecommunications network advantageously makes it possible to offer the quality of service required by this service, and a fortiori a user experience adapted to this service.

[0045] In particular embodiments, the method further comprises an exchange, between the terminal and the telecommunications network, of their respective capacities to control access to the traffic policy management function of said terminal.

[0046] In particular modes of implementation, the exchange comprises the following steps implemented by the terminal:

[0047] - a transmission, to the telecommunications network controller, of an indication according to which said terminal is configured to control the access of computer applications of said terminal to the traffic policy management function;

[0048] - a receipt, from the telecommunications network controller, of an indication according to which said terminal is authorized or not to allow access by computer applications of said terminal to the traffic policy management function.

[0049] In particular implementations, the authorization procedure includes token authentication or challenge-response authentication.

[0050] In particular implementations, the authentication token is an "ephemeral authentication token" which is typically usable only once, a "long-lived authentication token", or a "persistent token" with no lifetime.

[0051] In particular modes of implementation, the authorization procedure comprises authentication by authentication token, and the method further comprises a step implemented by the operating system of the transmission terminal, to said controller, of an authentication request from the computer application including an authentication token previously generated by an authentication system and provided to the operating system by the computer application.

[0052] In particular modes of implementation, the authentication request further includes identification data for the computer application, said identification data being controlled by the operating system of the terminal.

[0053] The fact that this identification data of the computer application is controlled by the terminal operating system and then transmitted to the network controller rather than being directly transmitted by the computer application to the network controller allows the controller to ensure that the application calling the traffic policy management function is not malicious. Thus, this feature offers the advantage of improving the security of access to this management function, by preventing an attack by impersonation of a malicious computer application.

[0054] In particular modes of implementation, the authentication request further includes terminal identification data previously communicated by the authentication system and provided to the operating system by the computer application.

[0055] This terminal identification data is intended to allow the controller to check whether said terminal is malicious or not. A fortiori, this characteristic offers the advantage of improving the security of access to this management function, by preventing an attack by impersonation of a malicious terminal. Indeed, this terminal identification data, which corresponds for example to an identifier of said terminal within the telecommunications network, is for example generated by the authentication system mentioned above in response to the reception of a request to obtain an authentication token, before being retransmitted to the computer application. It is this latter computer application which, by calling the traffic policy management function, also transmits this terminal identification data to the operating system. The latter then generates the authentication request and includes this terminal identification data therein.By receiving the request, the telecommunications network controller is then able to compare this terminal identification data with a set of authorized terminal identification data to enable traffic policy management by one of its IT applications.

[0056] In particular implementations, the authentication request further includes a timestamp previously communicated by the authentication system and provided to the operating system by the computer application.

[0057] This timestamp is intended to allow the controller to check whether the authentication request is maliciously repeated or not. More precisely, the timestamp is for example generated by the authentication system mentioned above in response to a request to obtain an authentication token, before being retransmitted to the computer application. It is this latter computer application which, by calling the traffic policy management function, also transmits this timestamp to the operating system. The latter then generates the authentication request and includes this timestamp. Upon receiving the request, the telecommunications network controller will then be able to verify the validity of the request, for example by comparing the difference between a value representing the current time and the value of the timestamp with a predetermined time interval. If this timestamp is not included in this interval, this means that the authentication request is probably being replayed.

[0058] In particular embodiments, the authentication is a long-lived authentication token authentication, and if the authentication of said computer application is valid, a result of the authentication provided by the controller to the operating system includes a duration during which a new access to the traffic policy management function must be authorized by the operating system without a new authentication of said computer application with the telecommunications network being necessary.

[0059] Compared to ephemeral token authentication, this feature offers the advantage of reducing the number of exchanges between the terminal and the authentication service.

[0060] In particular embodiments, the method further comprises receiving, from said controller, a result of the authentication of the computer application.

[0061] In particular embodiments, the authorization procedure is a challenge-response authentication, and the method further comprises the following steps, implemented by the operating system:

[0062] - a transmission, to the computer application, of a challenge;

[0063] - a transmission, to said controller, of configuration data including the challenge and a first response associated with the challenge;

[0064] - a receipt of a second response previously provided to said computer application by the controller in response to a receipt of a request for a response issued by the computer application and including said challenge;

[0065] and access to the traffic policy management function is allowed if the first and second responses are equal.

[0066] In particular modes of implementation, the method for managing access further comprises a step of comparison, by the operating system of the terminal, of the first and second responses.

[0067] In particular modes of implementation, the configuration data and the request for obtaining a response also include identification data for said computer application controlled by the operating system of the terminal.

[0068] In particular embodiments, the authorization procedure is a challenge-response authentication, and the access method further comprises the following steps, implemented by the computer application:

[0069] - a transmission, to the controller, of a request for a response including a challenge provided to the computer application by the operating system; and,

[0070] - a transmission, to the operating system, of a second response provided to the computer application by the controller following receipt of the request for a response.

[0071] According to a third aspect, the invention relates to a method for controlling access to a traffic policy management function, the function being implemented by a terminal connected to a telecommunications network, the method comprising the following steps implemented by a controller of the telecommunications network:

[0072] - a determination that said terminal is authorized to allow access by computer applications of said terminal to the traffic policy management function; and,

[0073] - a transmission, to the terminal, of data identifying computer applications authorized or not to manage the traffic policy, and of data representing an authentication mechanism, with said telecommunications network (200), of a computer application wishing to access the traffic policy management function.

[0074] In particular modes of implementation, the access control method may further comprise one or more of the following characteristics, taken individually or in all technically possible combinations.

[0075] In particular embodiments, the aforementioned determination is implemented in response to receiving an indication from the terminal, according to which said terminal is configured to control the access of computer applications of said terminal to the traffic policy management function.

[0076] In particular embodiments, the authentication mechanism is authentication by authentication token, and the method further comprises the following steps, implemented by an authentication system of the telecommunications network:

[0077] - in response to receiving a request to obtain an authentication token issued by the computer application of the terminal and including identification data of said computer application, a verification, based on said identification data, whether said application can obtain an authentication token; and,

[0078] - a transmission, to the computer application, of an authentication token generated based on the verification.

[0079] In particular modes of implementation, the method of controlling access further comprises the following steps, implemented by the authentication system:

[0080] - a generation of identification data of said terminal (100); and,

[0081] - a transmission of the identification data of said terminal to the computer application.

[0082] As mentioned previously, this identification data of said terminal allows the controller to check whether it is a malicious terminal or not which issues a request for authentication of a computer application.

[0083] According to a fourth aspect, the invention relates to a terminal configured to implement the access management method and / or the access method previously mentioned.

[0084] According to a fifth aspect, the invention relates to a controller of a telecommunications network configured to implement the control method mentioned above.

[0085] According to a sixth aspect, the invention relates to a system for accessing a traffic policy management function comprising the terminal and the controller previously mentioned.

[0086] According to a seventh aspect, the invention relates to a computer program comprising instructions for implementing a method for managing access to a traffic policy management function, when said program is executed by a computer.

[0087] According to an eighth aspect, the invention relates to a computer program comprising instructions for implementing a method of accessing a traffic policy management function, when said program is executed by a computer.

[0088] According to a ninth aspect, the invention relates to a computer program comprising instructions for implementing a method for controlling access to a traffic policy management function, when said program is executed by a computer.

[0089] According to a tenth aspect, the invention relates to a computer-readable recording medium on which the computer program according to the seventh, eighth, and / or ninth aspect is recorded. Brief description of the drawings

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

[0091] [Fig.l] Figure 1 is an example of an access system in which a general method of accessing a differentiated traffic policy management function is implemented;

[0092] [Fig.2A] Figure 2A schematically represents modules embedded in a terminal, according to a simplified example of implementation of the invention;

[0093] [Fig.2B] Figure 2B represents an example of hardware architecture of a terminal;

[0094] [Fig.3 A] Figure 3 A schematically represents modules embedded in a controller of a telecommunications network, according to an exemplary implementation of the invention;

[0095] [Fig.3B] Figure 3B represents an example of hardware architecture of a controller of a telecommunications network;

[0096] [Fig.4] Figure 4 illustrates, in the form of a flowchart, the main steps of a general method of accessing a function for managing a differentiated traffic policy, according to an exemplary implementation of the invention;

[0097] [Fig.5A] Figure 5A illustrates, in the form of a flowchart, a mechanism for authenticating a computer application to a telecommunications network by ephemeral authentication token, according to a first example of implementation of the invention;

[0098] [Fig.SB] Figure 5B illustrates, in the form of a flowchart, a mechanism for authenticating a computer application to a telecommunications network by ephemeral authentication token, according to a second example of implementation of the invention;

[0099] [Fig.SC] Figure 5C illustrates, in the form of a flowchart, a mechanism for authenticating a computer application to a telecommunications network by ephemeral authentication token, according to a third example of implementation of the invention;

[0100] [Fig.6] Figure 6 illustrates, in the form of a flowchart, a mechanism for authenticating a computer application to a telecommunications network by means of a long-life authentication token, according to an exemplary implementation of the invention;

[0101] [Fig.7] Figure 7 illustrates, in the form of a flowchart, a mechanism for authenticating a computer application to a telecommunications network by challenge-response, according to an exemplary implementation of the invention. Description of the embodiments

[0102] The terms "first(s)", "second(s)", etc. are used in this document by arbitrary convention to identify and distinguish different elements (such as messages, etc.) considered in the embodiments described below, and do not imply any particular sequencing, except where explicitly indicated.

[0103] Figure 1 is an example of an access system in which a general method for accessing a traffic policy management function is implemented. The procedure proposed by the invention is called in the remainder of the description IMURIG (for “Innovative Management of Unreceived collaborative API Gating control”).

[0104] This system comprises a terminal 100 connected to a telecommunications network 200. The terminal 100 supports, for example, the IP communication protocol, and can be a user terminal - taking, for example, the form of a laptop, a personal assistant, a connected object, or a mobile telephone of the "smartphone" type - a router, a home gateway, a TV decoder, etc.

[0105] As illustrated in FIG. 1, this terminal 100 comprises an operating system 110 including an IMURIG module 112 configured to implement a method for managing access to a function 111 for managing a traffic policy (typically a policy of differentiated traffic), this function 111 itself being implemented by the operating system 110, as well as an application programming interface (or API) through which the functionalities (or "primitives") of the function 111 for managing a traffic policy are presented to one or more computer applications 120 of the terminal 100.

[0106] The use of an API is advantageous since it allows the computer application 120 of the terminal 100 to communicate with the function 111 for managing a traffic policy, without having to know the details of implementing the functionalities of this function.

[0107] As illustrated in Figure 1, the system further comprises a remote server 300 also connected to the telecommunications network 200 through a data network DN such as the Internet or a local / private network, and configured to provide a service S. In a manner known per se, a service is defined as a computer program directly used to perform a task, or a set of elementary tasks in the same domain. This is for example a service for providing multimedia content (such as video on demand), a service for accessing a social network or a payment service.

[0108] In the present embodiment, and for the purpose of simplifying the description, it is considered that the access system comprises a single terminal 100, as well as a single remote server 300 offering a single service S, these two devices being connected through a telecommunications network including a single IMURIG_CTRL controller 210. It should however be noted that no assumption is made as to the number of terminals, remote servers and services deployed, the number of networks and controllers considered. The following developments can in fact be generalized without difficulty by the person skilled in the art to the case where more than one terminal, more than one remote server, more than one service S, more than one telecommunications network and / or more than one controller are considered.

[0109] As illustrated in FIG. 1, the telecommunications network 200 comprises in this example a radio access network RAN ​​and a core network CN connected to each other. In other words, the radio networks RAN and core CN compose, in the embodiment described here, the telecommunications network 200 to which the terminal 100 is connected, and are able to communicate with each other.

[0110] For the remainder of the description, it is considered, in a non-limiting manner, that this telecommunications network 200 is a 5G type mobile network. However, it should be specified that the invention remains applicable to other types of telecommunications network 200, such as for example a 4G mobile network, a B5G network (acronym for "Beyond 5G"), a 6G network, a WLAN network (such as a Wi-Fi network), an IP / MPLS network, etc.

[0111] The RAN radio access network is, for example, a V-RAN (Virtual-RAN). A V-RAN is a RAN radio access network whose network functions are deployed as virtualized instances located at different locations in the network, for example, according to a deployment strategy of the telecom operator. This approach offers the advantage of limiting the use of expensive equipment, and facilitates the creation of network slices that coexist simultaneously on the same hardware.

[0112] The core network CN comprises an IMURIG_CTRL controller 210 of the telecommunications network module configured to implement a method for controlling access to the function 111 for managing a traffic policy. As illustrated in FIG. 1, this controller 210 is deployed on an electronic device 2100 of the core network CN. Alternatively, this controller 210 is provided or co-located with an element of the telecommunications network.

[0113] Thus, this controller is for example provided by the SMF entity (acronym for "Session Management Function") which is typically responsible for managing the network control plane, and more specifically for controlling PDU sessions (acronym for "Packet Data Unit"). This SMF entity is notably described in sections 4 ("Overview") and 5 ("Services offered by the SMF") of the technical specification 3GPP TS 29.502, "5 G System; Session Management Services; Stage 3", V18.4.0, published in September 2023.

[0114] Alternatively, this controller 210 of the telecommunications network 200 is integrated into an SDN network controller. In a manner known per se, an SDN network controller is an entity of a telecommunications network which makes it possible to optimize network resources and quickly adapt the network to the changing needs of businesses, applications and traffic, and which offers for this purpose functions of orchestration, management, statistics and automation of said network.

[0115] In particular implementation modes, the core network CN further comprises an authentication manager AUTH_MNG 220 connected to the controller IMURIG_CTRL 210, and in particular configured to generate authentication elements such as authentication tokens.

[0116] In particular implementations, the RAN and CN core radio access networks support one or more network slices. In general, it is important to note that no assumptions are made about the nature of slices deployed in a network, their number, and the paths between instances or sub-instances of slices.

[0117] Figure 2A schematically represents modules embedded in a terminal, such as the terminal 100 of Figure 1, according to a simplified example of implementation of the invention.

[0118] As illustrated in FIG. 2A, the terminal 100 comprises an operating system 110 and at least one computer application 120 wishing to access the function of managing a (differentiated) traffic policy and referenced 111 in FIG. 1. The operating system 110 comprises a MOD_CHK verification module and a MOD_AUTH access authorization module, the functionalities of which are described with reference to FIG. 2B. The computer application 120 comprises, for its part, a MOD_CALL invocation and transmission module, and a MOD_ACC access module, the functionalities of which are also described with reference to FIG. 2B.

[0119] Figure 2B represents an example of hardware architecture of a terminal 100. As illustrated by Figure 2B, the terminal 100 has the hardware architecture of a computer. Thus, the terminal 100 comprises, in particular, a processor 1, a random access memory 2, a read-only memory 3 and a non-volatile memory 4. It further comprises a communication module 5.

[0120] The read-only memory 3 or the non-volatile memory 4 of the terminal 100 constitutes a recording medium as proposed, readable by the processor 1 and on which is recorded a first computer program PROG executed by the operating system 110, comprising instructions for the execution of steps of the method for managing an access as proposed below. The program PROG defines one or more functional sub-modules of the operating system 110, which rely on or control the hardware elements 1 to 5 cited previously, and which include in particular:

[0121] - a MOD_CHK module for verifying that the computer application 120 wishing to access the traffic policy management function 111 is authorized to invoke this function, using an authorization procedure implemented via the telecommunications network 200 and selected by a controller 210 of the telecommunications network 200; and,

[0122] - a MOD_AUTH module for authorizing access to the function 111 for managing a traffic policy by this computer application 120, based on a result of the verification.

[0123] The read-only memory 3 or the non-volatile memory 4 of the terminal 100 also constitutes a recording medium for a second computer program PROG_APP executed by the computer application 120, and comprising instructions for executing steps of the access method as proposed below. The program PROG_APP defines one or more functional sub-modules, which rely on or control the hardware elements 1 to 5 cited above, and which include in particular:

[0124] - a MOD_CALL module for invoking the function 111 for managing a traffic policy and transmitting, to an operating system 110 of the terminal 100, an authentication element received from an authentication system 210, 220 of the telecommunications network 200 and required by an authorization procedure selected and implemented via the telecommunications network 200; and,

[0125] - a MOD_ACC module for accessing said traffic policy management function, based on a result of the authorization procedure.

[0126] Furthermore, the terminal 100 may also include other modules, in particular for implementing particular modes of the access management method, as described in more detail later.

[0127] Figure 3 A schematically represents modules embedded in a controller 210 of a telecommunications network 200, according to an exemplary implementation of the invention.

[0128] As illustrated by FIG. 3A, the electronic device 2100 of the core network CN comprises a controller 210 of a telecommunications network including a determination module MOD_DET and a transmission module M0D_TX whose functionalities are described with reference to FIG. 3B.

[0129] Figure 3B represents an example of hardware architecture of an electronic device 2100 comprising a controller 210. As illustrated by Figure 3B, the electronic device 2100 has the hardware architecture of a computer. Thus, the electronic device 2100 comprises, in particular, a processor 1, a RAM 2, a read-only memory 3 and a non-volatile memory 4. It also includes a communication module 5.

[0130] The read-only memory 3 or the non-volatile memory 4 of the electronic device constitutes a recording medium as proposed, readable by the processor 1 and on which is recorded a computer program PROG_CTRL comprising instructions for the execution of steps of the access control method as proposed below. The program PROG_CTRL defines one or more functional sub-modules of the electronic device 2100, which rely on or control the hardware elements 1 to 5 cited previously, and which include in particular:

[0131] - a MOD_DET module for determining that the terminal 100 is authorized to allow access to the function 111 for managing a traffic policy by its own computer applications; and,

[0132] - a module M0D_TX for transmitting data identifying computer applications authorized or not to manage the traffic policy, and data representing an authentication mechanism, with said telecommunications network 200, of a computer application wishing to access the function of managing a differentiated traffic policy.

[0133] Furthermore, the electronic device 2100 may also comprise other modules, in particular for implementing particular modes of the access control method, as described in more detail later.

[0134] Figure 4 illustrates, in the form of a flowchart, the main steps of a general method for accessing a traffic policy management function, according to an exemplary implementation of the invention.

[0135] This general method includes a method for managing access to a traffic policy management function (differentiated traffic policy in the example considered here) including steps S100 to S190 implemented by the operating system 110 of the terminal 100, and steps S300 and S310 implemented by a computer application 120 of the terminal 100, as well as a method for controlling access to a traffic policy management function (differentiated traffic policy in the example considered here) implemented by a controller 210 of a telecommunications network 200 and including steps S200 to S250.

[0136] In the following, it is considered that the messages exchanged between the terminal 100 and the controller 210 of the telecommunications network are mutually authenticated in accordance with an authentication method well known in the prior art, such as authentication by certificate or using pre-shared cryptographic keys ("Pre-Shared Keys", PSK, according to English terminology).

[0137] Authentication of the exchanged messages advantageously makes it possible to prevent malicious actions from being carried out by malware installed on the terminal 100 by usurping, for example, the identity of the IMURIG module 112.

[0138] The general method of accessing a traffic policy management function (differentiated traffic policy in the example considered here) comprises a first step SI 00 during which the terminal 100, and more specifically the IMURIG module 112 of the operating system 110, transmits to the controller 210 of the telecommunications network 200, an IMURIG_CAPABLE(UE_STATUS) indication according to which said terminal 100 is configured to control the access of computer applications of said terminal 100 to the traffic policy management function 111.

[0139] According to a particular implementation, this IMURIG_CAPABLE(UE_STATUS) indication is transmitted as part of the attachment to the telecommunications network 200, through a message comprising a specific information element. An information element corresponds to a field of an IEEE 802.11 management frame or of a message exchanged within a mobile telephone network between a base station and a user terminal. An information element generally uses a type-length-value coding scheme.

[0140] According to a particular implementation, the telecommunications network 200 is of the 5G type, and the information element is inserted for example in the "Extended protocol configuration option" field of the "PDU Session Establishment Request" message. This message corresponds to a request to establish a session allowing the exchange of data between a user terminal and a data network, such as the Internet network or a private network. It is for example compliant with section 5.6 of the 3GPP TS 23.501 standard, "System architecture for the 5G System (5GS)", version 18.3.0, published on September 19, 2023.

[0141] Alternatively, this IMURIG_CAPABLE(UE_STATUS) indication is transmitted to the controller 210 as an option of the dynamic configuration protocol DHCPvô (for "Dynamic Host Configuration Protocol version 6"), this protocol being for example defined in RFC 8415, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", published in November 2018 by the IETF (acronym for "Internet Engineering Task Force").

[0142] Alternatively, this IMURIG_CAPABLE(UE_STATUS) indication is transmitted to the controller 210 in the form of a value of a field of the "Neighbor Advertissement" message of the neighbor host discovery protocol ("Neighbor Discovery protocol" according to English terminology), this protocol being for example defined in the document RFC 4861, "Neighbor Discovery for IP version 6 (IPv6)", published in September 2007 by the IETF.

[0143] According to a particular implementation, this IMURIG_CAPABLE(UE_STATUS) indication comprises a UE_STATUS flag indicating whether or not said terminal 100 is configured to control the access of computer applications of said terminal 100 to the function 111 for managing a traffic policy. Thus, if the UE_STATUS flag is for example equal to "1", this means for example that the terminal 100 is configured to control the access of its own computer applications to the function 111 for managing a traffic policy. If the UE_STATUS flag is for example equal to "0", this means that said terminal 100 cannot control the access of its own computer applications to the function 111 for managing a traffic policy, and that it therefore does not authorize its computer applications to access this function 111 for managing a traffic policy.

[0144] In the latter case, the functionalities offered by the traffic policy management function 111 are not exposed by the operating system through an API. Alternatively, the functionalities (or "primitives") are exposed through an API, but the operating system does not respond to calls (or invocations) from computer applications wishing to access these functionalities.

[0145] This IMURIG_CAPABLE(UE_STATUS) indication is received by the controller 210 of the telecommunications network 200 during a step S200. The method further comprises a step S210 during which the controller 210 extracts the information from the received message.

[0146] In a step S220, the controller 210 checks whether the telecommunications network 200 offers the possibility of authorizing a terminal to control access to the traffic policy management function in accordance with the IMURIG procedure. If this is not the case (choice "N"), the controller implements a step S225. According to a first example of implementation of step S225, the message received in step S200 is ignored and the procedure for establishing the communication is terminated. According to a second example of implementation, only the IMURIG_CAPABLE(UE_STATUS) indication is ignored by the controller 210.

[0147] If, on the other hand, the telecommunications network 200 offers the possibility of authorizing a terminal to control access to the traffic policy management function in accordance with the IMURIG procedure (choice "Y"), a step S230 is implemented by the controller 210 during which the latter verifies whether the terminal 100 having transmitted this IMURIG_CAPABLE(UE_STATUS) indication can be authorized or not to allow access to the traffic policy management function 111 to at least one of its computer applications. This authorization granted or not to the terminal depends for example on the congestion conditions in the telecommunications network, or on restrictions linked to the service offers subscribed to by the user of said terminal 100.

[0148] If the terminal 100 is not authorized by the controller 210 to allow access to the traffic policy management function 111 to at least one of its computer applications (choice "N"), the controller then implements a step S240 during which an IMURIG_CAPABLE(NWK_STATUS) indication representing the fact that the network 200 does not authorize the terminal 100 to allow access to the traffic policy management function 111 is transmitted to the operating system 110.

[0149] In a particular implementation, this IMURIG_CAPABLE(NWK_STATUS) indication is transmitted through the "PDU Session Establishment Accept" message. Alternatively, this IMURIG_CAPABLE(NWK_STATUS) indication is transmitted through the "PDU Session Establishment Reject" message. These messages are, for example, compliant with 3GPP TS 23.501, "System architecture for the 5G System (5GS)", version 18.3.0, published on September 19, 2023.

[0150] According to a particular implementation, in the case where the request to establish the PDU session is rejected, the "PDU Session Establishment Reject" message includes a specific cause code ("5GSM cause") whose value is representative of the fact that the terminal 100 is not authorized to allow access to the function 111 for managing a traffic policy to its applications. The cause codes so far standardized within the framework of 3GPP are for example defined in the standard TS 29.524, "5G System; Cause codes mapping between 5GC interfaces; Stage 3", version 17.3.0, published in December 2021.

[0151] This message is received by the operating system 110 during a step S110.

[0152] Returning to step S230, if on the contrary the terminal 100 is actually authorized by the controller 210 to allow access to the function 111 for managing a traffic policy to at least one of its computer applications (choice "Y"), a step S250 is implemented by the controller 210 during which the latter transmits a message including data IMURIG_CAPABLE(LIST;GRANT_M) representative of the fact that this terminal 100 is authorized to allow access to function 111 for managing a traffic policy to at least one of its applications.

[0153] According to a particular implementation, this IMURIG_CAPABLE(LIST,GRANT_M) data is transmitted through a specific information element of the "Extended Protocol Configuration Options" field of the "PDU Session Establishment Accept" message.

[0154] According to a particular implementation, this IMURIG_CAPABLE(LIST,GRANT_M) data includes data identifying computer applications authorized or not by the controller 210 to access the function 111 for managing a traffic policy.

[0155] This identification data corresponds for example to a list LIST of identifier(s) of computer applications authorized by the controller 210 to access the function 111 for managing a traffic policy.

[0156] Alternatively, this identification data corresponds to a list LIST of identifier(s) of computer applications which are not authorized to access the function 111 for managing a traffic policy. Thus, by comparing the identifiers of the computer applications which are not authorized to access the function 111 for managing a traffic policy and those of the computer applications installed on the terminal 100, the operating system 110 is then able to determine the computer application(s) installed on said terminal 100 and also authorized by the controller 210 to access the function 111 for managing a traffic policy.

[0157] Alternatively, this identification data {APP_FILTER , OP} corresponds to at least one pair including an APP_FILTER filter on which an OP operand is applied. The APP_FILTER filter makes it possible to identify one or more computer applications, for example using an application identifier ("APPJD",} or a set of applications ("groupjd"}, a domain name, etc.

[0158] The OP operand characterizes the operation to be applied to the APP_FILTER filter, and refers either to an exact match or to the logical operator "Not". This OP operand takes, for example, the value "0" when referring to an exact match and "1" when referring to the "Not" operator.

[0159] If the operand OP refers to an exact match, only the computer applications identified by the filter APP_FILTER are authorized to access the function 111 for managing a traffic policy. For example, the identification data {4234d49b, 0} is returned by the controller 210 to indicate to the terminal 100 that only the application having the identifier "4234d49b" is authorized to access the function 111 for managing a traffic policy. traffic policy, and calls from other applications are systematically refused by the operating system 110.

[0160] If, on the other hand, the operand OP refers to the logical operator "No", this means that all computer applications except those identified by the filter APP_FILTER are authorized to access the function 111 for managing a traffic policy. For example, the identification data {4234d49b; 1} is returned by the network to indicate to the terminal 100 that all applications except the one with the identifier "4234d49b" are authorized to access the function 111 for managing a traffic policy.

[0161] It is also important to note that several pairs {APP_FILTER , OP} may be transmitted to the terminal 100 by the controller 210 of the telecommunications network in the form of an ordered list LIST. Typically, these pairs have the same operand value. If the pairs of the list LIST comprise distinct operands, then the filters are applied in accordance with the order in which they are listed.

[0162] According to a particular implementation, this IMURIG_CAPABLE(LIST, GRANT_M] data further comprises a GRANT_M data representative of an authentication mechanism with said telecommunications network of a computer application wishing to access the traffic policy management function.

[0163] In other words, this GRANT_M data characterizes the authentication mechanism to be initiated by the operating system 110 of the terminal 100 with the telecommunications network so that one of its computer applications wishing to access the function 111 for managing a traffic policy authenticates itself with the telecommunications network.

[0164] This data "GRANT_M" takes here for example the value "0" when the authentication mechanism is an authentication by ephemeral token, "1" when the authentication mechanism is an authentication by long-lived token, and "2" when it is a challenge-response authentication. These different authentication mechanisms are described in more detail with reference to figures 5A-C, 6 and 7. Of course, other authentication mechanisms or more generally authorization mechanisms can be considered.

[0165] The data IMURIG_CAP ABLE (LIST, GRANT_M] representing the fact that this terminal 100 is authorized to allow access to the function 111 for managing a traffic policy to at least one of its applications is received by the operating system 110 during a step S120. Then, during a step S130, the operating system 110 extracts the information from the message received in step S120, then records it in a dedicated table OIG. This information is associated, in the table OIG, with a data item for identifying the network telecommunication network 200 having issued this data IMURIG_CAP ABLE (LIST , GRANT_M). The identification data of the telecommunication network 200 corresponds for example to an identifier of the local interface of a terminal used to communicate with said network, a domain name, or to a public land mobile network identifier ("Public Land Mobile Network", PLMN, according to English terminology).

[0166] The general access method further comprises a step S300, implemented by a computer application 120 of the terminal 100, for calling or invoking the function 111 for managing a traffic policy. This step S300 is for example implemented by the MOD_CALL module previously mentioned. This call is detected by the operating system 110 during a step S140.

[0167] Then, during a step S150, the operating system 110 determines whether this computer application (120) wishing to access the management function 111 is authorized, by the telecommunications network 200, to access it. This step is for example implemented by the MOD_CHK verification module previously mentioned. To do this, the operating system 110 determines whether there is a correspondence between the identifier of the computer application 120 wishing to access the management function 111 and one of the rules of the list LIST as maintained in the OIG table. In other words, the operating system 110 checks, using its identifier, whether this computer application 120 wishing to access the management function 111 is listed as being authorized to access this function or is not listed as an application whose access to this function must not be permitted.

[0168] If this computer application is not authorized (choice "N"), the operating system 110 implements a step S160 during which it rejects the call detected in step S140.

[0169] If, on the other hand, this computer application 120 is authorized to access the function 111, the operating system 110 implements a step S170 during which it determines the authentication mechanism to be initiated so that this computer application 120 is authenticated with the telecommunications network, for example by consulting the OIG table, and initiates this authentication mechanism. This step is for example also implemented by the MOD_CHK verification module previously mentioned.

[0170] If the authentication of the computer application 120 with the telecommunications network is valid, the general access method further comprises a step S180 during which access to the function 111 for managing a traffic policy is authorized for this computer application 120. This step is for example implemented by the MOD_AUTH access authorization module previously mentioned. More precisely, the operating system 110 authorizes the computer application 120 to call one or more functionalities (or "primitives") of the traffic policy management function 111.

[0171] According to a particular implementation, these functionalities include an addition, a deletion and / or a modification of a traffic classification rule generated by the manager of the telecommunications network 200. This or these traffic classification rules are for example stored in the memory of the terminal 100.

[0172] According to a particular implementation, the functionality called corresponds to the addition of a rule for associating at least one flow of a communication with the terminal 100 to at least one network slice of the telecommunications network 200 accessible by said terminal 100.

[0173] Then the operating system 110 transmits, to the application 120, an acknowledgment CALL_ACK of the call CALL during a step S190. This acknowledgment comprises a result of access to the functionality of the traffic policy management function, and is received by the computer application 120 during a step S310. This step S310 is for example implemented by the previously mentioned MOD_ACC module.

[0174] Figure 5A illustrates, in the form of a flowchart, a mechanism for authenticating a computer application to a telecommunications network by ephemeral authentication token, according to a first example of implementation of the invention.

[0175] In this first example, an authentication system is envisaged which includes on the one hand an authentication manager AUTH_MNG 220 of the telecommunications network 200 configured in particular to generate an authentication token, and on the other hand the controller 210 previously mentioned to verify the validity of this authentication token.

[0176] As illustrated in FIG. 5A, this ephemeral token authentication mechanism comprises a first step S400-1, implemented by the computer application 120, during which this computer application 120 obtains an identification data item as used by the operating system 110 to identify this computer application 120. Typically, this identification data item corresponds to an application identifier chosen by the developer of the computer application according to a specific nomenclature. Alternatively, the application identifier is instantiated by the operating system 110, for example at the time of installation of this application 120, and the operating system 110 then transmits this identifier to the application IT ZI 120, or presents to the IT application 120 an API allowing it to obtain this application identifier.

[0177] The authentication mechanism further comprises a step S410-1 of transmission, by the computer application 120 and to an authentication manager AUTH_MNG 220 of the telecommunications network 200, of a request to obtain an authentication token GET_TOKEN including the identifier APPJD of the computer application 120. This request is received by the authentication manager 220 during a step S500-1. During a step S510-1, the authentication manager 220 extracts the identifier APPJD of the computer application 120 from the received message, then verifies, from the extracted identifier, whether this computer application 120 can actually receive an authentication token (step S520-1).

[0178] If this is the case (choice "Y"), the authentication manager 220 implements a step S530-1 during which an ephemeral authentication token TKN, a timestamp TS, and a UE identifier JD of the terminal 100 are generated. Alternatively, the UE identifier JD of the terminal 100 is generated by an electronic device separate from the controller 210 and the authentication manager 220. During a step S540-1, the authentication manager 220 transmits, to the controller 210, the generated ephemeral authentication token TKN, the timestamp TS, and the UEJD identifier of the terminal 100. These data are received by the controller 210 during a step S600-1, and are for example recorded in an ACTIVE_TOKENS table.

[0179] This data is also transmitted by the authentication manager 220 to the computer application 120, during a step S550-1, and received by this same computer application 120 during a step S420-1.

[0180] The ephemeral token authentication mechanism further comprises a call (i.e. an invocation) S430-1 of the traffic policy management function 111, which is detected by the operating system 110 during a step S700-1. This call CALL notably comprises the ephemeral authentication token TKN, the timestamp TS, and the identifier UEJD of the terminal 100. Steps S430 and S700 correspond respectively to steps S300 and S140 previously described with reference to FIG. 4. Then, during a step S710-1, the operating system 110 extracts the data from the received message, and determines the identification data (APPJD) of the computer application 120 having made this call.

[0181] During a step S720-1, the operating system 110 transmits, to the controller 210, an authentication request CHECK_TOKEN including the token ephemeral authentication TKN, the timestamp TS, the UE identifier JD of the terminal 100 and the identifier APPJD of the computer application having issued the call to the function 111 for managing a traffic policy. This authentication request CHECK_TOKEN is received by the controller 210 during a step S610-1.

[0182] Then, during a step S620-1, the controller 210 extracts the information from the request, and compares this information with the data recorded in the ACTIVE_TOKENS table during a step S630-1. If a valid entry is found in the ACTIVE_TOKENS table, the controller 210 then implements a step S640-1 during which a confirmation ACK of the validity of the authentication is transmitted to the operating system 110, and received by this operating system 110 during a step S730-1.

[0183] If, on the other hand, no valid entry is found (choice "N"), the controller 210 then implements a step S650-1 during which an indication NACK according to which the authentication of the computer application 120 is not valid is transmitted to the operating system 110, and received by this operating system 110 during a step S740-1.

[0184] Figure 5B illustrates, in the form of a flowchart, a mechanism for authenticating a computer application to a telecommunications network by ephemeral authentication token, according to a second example of implementation of the invention. This second example corresponds to a variant of steps S400-1 to S420-1, S500-1 to S550-1, and S600-1 in dotted lines in Figure 5A.

[0185] In this second example, an authentication system is envisaged which includes an authentication manager part AUTH_MNG 220 of the telecommunications network 200 configured in particular to generate an authentication token, and on the other hand the controller 210 to verify the validity of this authentication token, but unlike the first example, the computer application 120 no longer interacts directly with the authentication manager 220, but with the controller 210 which is then responsible for communicating with the authentication manager 220.

[0186] As illustrated by FIG. 5B, this ephemeral token authentication mechanism comprises a first step S400-2, implemented by the computer application 120, during which this computer application 120 obtains an identification data APPJD as used by the operating system to identify this computer application 120. This step is similar to the step S400-1 previously mentioned with reference to FIG. 5A.

[0187] The authentication mechanism further comprises a step S410-2 of transmission, by the computer application 120 and to the controller 210 of the telecommunications network 200, of a GET_TOKEN request to obtain an authentication token TKN including the identifier APP JD of the computer application 120. This request is received by the controller 210 during a step S600-2. During a step S610-2, the controller 210 extracts the identifier APPJD of the computer application 120 from the received message, then verifies, from the extracted identifier APPJD, whether this computer application 120 can actually receive an authentication token (step S620-2).

[0188] If this is the case (choice "Y"), the controller 210 transmits, during a step S630-2, a GET_TOKEN request to obtain an authentication token, which is received by the authentication manager 220 during a step S500-2. The authentication manager 220 implements a step S510-2 during which an ephemeral authentication token TKN, a timestamp TS and an identifier UEJD of the terminal 100 are generated. Alternatively, the identifier UEJD of the terminal 100 is generated by an electronic device separate from the controller 210 and the authentication manager 220.

[0189] During a step S520-2, the authentication manager 220 transmits, to the controller 210, the ephemeral authentication token TKN, the timestamp TS, and the identifier UEJD of the terminal 100 generated. This data is received by the controller 210 during a step S640-2, and is for example recorded in an ACTIVE_TOKENS table. This data is then transmitted by the controller 210 and to the computer application 120 during a step S650-2, and received by this same computer application 120 during a step S420-2.

[0190] The authentication mechanism further comprises steps S430-1, S700-1 and following previously described with reference to FIG. 5A, and which are therefore not repeated here, for the sake of brevity.

[0191] Figure 5C illustrates, in the form of a flowchart, a mechanism for authenticating a computer application to a telecommunications network by ephemeral authentication token, according to a third example of implementation of the invention. This third example corresponds to a variant of steps S400-1 to S420-1, S500-1 to S550-1, and S600-1 in dotted lines in Figure 5A. In this third example, the authentication system comprises only the controller 210.

[0192] As illustrated by FIG. 5C, this ephemeral token authentication mechanism comprises a first step S400-3, implemented by the computer application 120, during which this computer application 120 obtains an identification data APPJD as used by the operating system to identify this computer application 120. This step is similar to the step S400-1 previously mentioned with reference to FIG. 5 A.

[0193] The ephemeral token authentication mechanism further comprises a step S410-3 of transmission, by the computer application 120 and to the controller 210 of the telecommunications network 200, of a GET_TOKEN request to obtain an authentication token TKN including the identifier APPJD of the computer application 120. This request is received by the controller 210 during a step S600-3.

[0194] In a step S610-3, the controller 210 extracts the identifier APPJD of the computer application 120 from the received message, then checks, from the extracted identifier APPJD, whether this computer application 120 can actually receive an authentication token (step S620-3). If this is the case (choice "Y"), the controller 210 implements a step S630-3 during which an ephemeral authentication token TKN, a timestamp TS, and an identifier UEJD of the terminal 100 are generated. Alternatively, the identifier UE JD of the terminal 100 is generated by an electronic device separate from the controller 210 and the authentication manager 220.

[0195] Then, during a step S640-3, the controller 210 transmits, to the computer application 120, the ephemeral authentication token TKN, the timestamp TS, and the identifier UEJD of the terminal 100 generated. This data is received by this same computer application 120 during a step S420-3.

[0196] The authentication mechanism further comprises steps S430-1, S700-1 and following previously described with reference to FIG. 5A, and which are therefore not repeated here, for the sake of brevity.

[0197] Figure 6 illustrates, in the form of a flowchart, a mechanism for authenticating a computer application to a telecommunications network by means of a long-lived authentication token, according to an exemplary implementation of the invention.

[0198] As illustrated in Figure 6, this long-lived token authentication mechanism comprises a first step S400-4, implemented by the computer application 120, during which this computer application 120 obtains an identification data item as used by the operating system to identify this computer application 120. Typically, this identification data corresponds to an APPJD application identifier chosen by the developer of the computer application according to a specific nomenclature. Alternatively, the APPJD application identifier is instantiated by the operating system 110, for example at the time of installation of this application, and the operating system 110 then transmits this APPJD identifier to the computer application 120, or presents to the computer application 120 an API allowing it to obtain this APPJD application identifier.

[0199] The authentication mechanism further comprises a step S410-4 of transmission, by the computer application 120 and to the controller 210 of the telecommunications network 200, of a GET_TOKEN request to obtain an authentication token including the APPJD identifier of the computer application 120. This request is received by the controller 210 during a step S600-4. During a step S610-4, the controller 210 extracts the APPJD identifier of the computer application 120 from the received message, then verifies, from the extracted identifier, whether this computer application 120 can actually receive an authentication token (step S620-4).

[0200] If this is the case (choice "Y"), the controller 210 implements a step S630-4 during which a long-lived authentication token TKN and an identifier UEJD of the terminal 100 are generated. These data are then, for example, recorded in an ACTIVE_TOKENS table accessible by this controller 210. During a step S640-4, the controller 210 transmits, to the computer application 120, the authentication token TKN and the identifier UEJD of the terminal 100, which are received by the computer application 120 during a step S420-4.

[0201] The long-life token authentication mechanism further comprises a step S430-4 of calling (invoking) the traffic policy management function 111, this call CALL then being detected by the operating system 110 during a step S700-4. The call notably comprises the authentication token TKN and the identifier UEJD of the terminal 100 previously received in step S420-4. Then, during a step S710-4, the operating system 210 extracts the data from the received message, and determines the identification data APPJD of the computer application 120 having made this call.

[0202] Then, during a step S720-4, the operating system 110 transmits, to the controller 210, an authentication request CHECK_TOKEN including the authentication token TKN, the identifier UEJD of the terminal 100 and the identifier APPJD of the computer application having issued the call to the function 111 for managing a policy of traffic. This CHECK_TOKEN authentication request is received by the controller 210 during a step S650-4.

[0203] In a step S660-4, the controller 210 extracts the information from the request, and compares this information with the data recorded in the ACTIVE _TOKENS table in a step S630-1. If no valid entry is found in the ACTIVE _TOKENS table (choice "N"), the controller 210 then implements a step S670-1 during which a NACK indication according to which the authentication of the computer application 120 is not valid is transmitted to the operating system 110, and received by this operating system 110 in a step S730-4.

[0204] If, on the other hand, a valid entry is found (choice "Y"), the controller 210 then implements a step S680-4 during which a confirmation ACK of the validity of the authentication of the computer application 120 is transmitted to the operating system 110, and received by this operating system 110 during a step S740-4. This confirmation ACK includes a value P representative of a duration during which a new access to the function 111 for managing a traffic policy must be authorized by the operating system 110 without a new authentication of said computer application 120 with said telecommunications network 200 being necessary.

[0205] In response to the receipt of this confirmation ACK, the operating system 110 implements a step S750-4 during which it authorizes access to the function 111 for managing a traffic policy by the computer application 120. During this same step S750-4, the operating system 110 records the authentication token TKN, the identifier UEJD of the terminal 100, the identifier APPJD of the computer application, as well as the value of the duration P in a table "LOCAL_TOKENS".

[0206] Finally, the authentication mechanism comprises a step S760-4, implemented by the operating system 110 after the duration P has elapsed, and during which the operating system 110 removes the corresponding entry from the LOCAL_TOKENS table.

[0207] Thus, in the context of this embodiment, as soon as a call to the traffic policy management function 111 is detected by the operating system 110, the latter consults the LOCAL_TOKENS table and checks whether it contains an entry including the identifier of the calling computer application. If this is the case, this means that a new authentication of the calling computer application with the telecommunications network 200 is not necessary, and access to the function 111 is then authorized by the operating system 110.

[0208] The long-lived authentication token authentication mechanism has so far been described in the case where the authentication system only comprises the controller 210. It nevertheless remains applicable in the case where the authentication system comprises the controller 210 and the authentication manager, as presented with reference to FIGS. 5A and 5B.

[0209] Figure 7 illustrates, in the form of a flowchart, a mechanism for authenticating a computer application to a telecommunications network by challenge-response, according to an exemplary implementation of the invention.

[0210] As illustrated in Figure 7, the mechanism for authenticating a computer application by challenge-response comprises a first step S400-5, implemented by a computer application 120, of calling (or invoking) the function 111 for managing a traffic policy. This call CALL is detected by the operating system 110 during a step S700-5. In response to this detection, the operating system 110 transmits, to the application, a message CHALLENGE including a challenge CHAL as well as a timestamp TS, and which is received by the application 120 during a step S410-5.

[0211] During a step S720-5, the operating system 110 determines the identification data APPJD of the computer application 120 having made this call CALL. Then it transmits, to the controller 210, SHARE_CHALLENGE configuration data of an authentication including the CHAL challenge, a RESP response - called first response - associated with the CHAL challenge, and the timestamp TS. This configuration data is received by the controller 210 during a step S600-5. Then, during a step S610-5, the controller 210 extracts the SHARE_CHALLENGE configuration data, and records it in a table ACR.

[0212] In response to the reception S410-5 of the CHALLENGE message by the computer application 120, the latter transmits, during a step S430-5, a SEEK_RESPONSE request to obtain a response having as parameters the challenge CHAL, the timestamp TS, as well as the identifier of the application APPJD to the controller 210. This SEEK_RESPONSE request is received by the controller 210 during a step S620-5, which then checks during a step S630-5 whether an entry is present in the table ACR. If this is the case, the controller implements a step S640-5 of transmission, to the computer application 120, of an acknowledgment of receipt ACK including a response RESP* - called second response -, which corresponds to the response associated with the challenge CHAL in the ACR table. This acknowledgment ACK is received by the computer application 120 during a step S440-5.

[0213] The authentication mechanism further comprises a step S450-5 of transmitting this RESP* response to the operating system 110. This RESP* response is received by the operating system 110 during a step S740-5, and the latter compares the first and second responses, and checks whether they are equal or not. If this is the case (choice "Y"), access to the function 111 for managing a traffic policy is granted to the computer application 120.

[0214] It is important to note that step S710-5 and the two steps S720-5 and S730-5 are not linked to a notion of temporal succession. Indeed, step S710-5 and the two steps S720- 5 and S730-5 can be implemented simultaneously, but both steps S720-5 and S730-5 can also be implemented before step S710-5.

[0215] The challenge-response authentication mechanism has so far been described in the case where the authentication system only comprises the controller 210. It nevertheless remains applicable in the case where the authentication system comprises the controller 210 and the authentication manager, as presented with reference to FIGS. 5A and 5B.

Claims

Claims

1. Method for managing access to a traffic policy management function (111), the function being implemented by a terminal (100) connected to a telecommunications network (200), the method comprising the following steps, implemented by an operating system (110) of said terminal (100): - a verification (S150, S170) that a computer application (120) of the terminal (100) wishing to access the function (111) for managing a traffic policy is authorized to invoke this function, using an authorization procedure implemented via the telecommunications network and selected by a controller (210) of the telecommunications network (200); and, - an access authorization (S180) to the function (111) by said computer application, depending on a result of the verification.

2. Method for managing access according to claim 1, further comprising, a reception (S120), by the operating system (110) and coming from the controller (210) of the telecommunications network (200), of data representing computer applications authorized or not to manage the traffic policy, and of data representing an authentication mechanism of a computer application wishing to access the function (111) of managing a traffic policy with said telecommunications network (200); the verification that the computer application (120) is authorized to manage the traffic policy being implemented according to said received data.

3. Method for accessing a function (111) for managing a traffic policy, the function being implemented by a terminal (100) connected to a telecommunications network (200), the method comprising the following steps implemented by a computer application of said terminal (100): - an invocation (S300) of the function (111) for managing a traffic policy; a transmission, to an operating system (110) of the terminal (100), of an authentication element received from an authentication system (210, 220) of the telecommunications network (200) and required by an authorization procedure selected and implemented via the telecommunications network (200); and, - access (S310) to said function (111) for managing a traffic policy, based on a result of the authorization procedure.

4. The access method of claim 3, wherein the authentication element includes an authentication token (TKN) transmitted to the operating system (110) upon invocation of the function.

5. Access method according to claim 3 or 4, further comprising a transmission, to the operating system (110), of identification data (UEJD) of the terminal (100) and / or of a timestamp.

6. Access method according to claim 3, wherein the authentication element includes a response (RESP*) associated with a challenge (CHAL) transmitted (S450-5) to the operating system (110) following a reception (S410-5) of the challenge (CHAL) from the operating system (110).

7. Method according to one of claims 1 to 6, in which the function (111) of managing a traffic policy comprises an addition, a deletion and / or a modification of a traffic classification rule generated by a manager of the telecommunications network (200).

8. Method according to claim 7, in which the function (111) of managing a traffic policy comprises adding a rule for associating at least one flow of a communication with the terminal (100) with at least one network slice of the telecommunications network (200) accessible by said terminal (100).

9. Method according to one of claims 1 to 8, in which the authorization procedure comprises authentication by authentication token or challenge-response type authentication.

10. Method according to one of claims 1 to 9, in which the authorization procedure comprises an authentication by authentication token, and the method further comprises a step implemented by the operating system (110) of the terminal (100) of transmission (S720-1, S720-4), to said controller (210), of an authentication request (CHECK_TOKEN) of said computer application (120) including an authentication token (TKN) previously generated by an authentication system (210, 220) and supplied to the operating system (110) by the computer application (120). [Claim ll] Method according to claim 10, wherein the authentication request (CHECK_TOKEN) further includes an identification data (APPJD) of said computer application (120), said identification data (APPJD) being controlled by the operating system (110) of the terminal (100).

12. Method according to claim 10 or 11, in which the authentication request (CHECK_TOKEN) further includes identification data (UEJD) of the terminal (100) previously communicated by the authentication system (210, 220) and provided to the operating system by the computer application (120).

13. Method according to one of claims 10 to 12, in which the authentication request (CHECK_TOKEN) further includes a timestamp (TS) previously communicated by the authentication system (210, 220) and provided to the operating system (110) by the computer application (120).

14. Method according to one of claims 10 to 12, wherein the authentication is an authentication by long-lived authentication token, and if the authentication of said computer application (120) is valid, a result of the authentication provided by the controller (210) to the operating system (110) includes a duration (P) during which a new access to the function (111) for managing a traffic policy must be authorized by the operating system (110) without a new authentication of said computer application (120) with the telecommunications network (200) being necessary.

15. Method for managing access according to one of claims 1 or 2, in which the authorization procedure is a challenge-response authentication, and the method further comprises the following steps, implemented by the operating system (110): - a transmission (S710-5), to the computer application (120), of a challenge (CHAL); - a transmission (S730-5), to said controller (210), of parameterization data including the challenge (CHAL) and a first response (RESP) associated with the challenge (CHAL); - a reception (S740-5) of a second response (RESP*) previously provided to said computer application (120) by the controller (210) in response to a receiving (S620) a request (SEEK_RESPONSE) for obtaining a response, issued by the computer application (120) and including said challenge (CHAL); and access (S760-5) to the function (111) for managing a traffic policy is authorized if the first and second responses are equal.

16. Access method according to one of claims 3 to 9 in combination with claim 3, wherein the authorization procedure is a challenge-response authentication, and the method further comprises the following steps, implemented by the computer application (120): - a transmission (S430-5), to the controller (210), of a request (SEEK_RESPONSE) to obtain a response including a challenge (CHAL) provided to the computer application (120) by the operating system (110); and, - a transmission (450-5), to the operating system (110), of a second response (RESP*) provided to the computer application (120) by the controller (210) following the reception (S620-5) of the request (SEEK_RESPONSE) to obtain a response.

17. Method for controlling access to a traffic policy management function (111), the function being implemented by a terminal (100) connected to a telecommunications network (200), the method comprising the following steps implemented by a controller (210) of the telecommunications network (200): - a determination (S230) that said terminal (100) is authorized to allow access by computer applications of said terminal (100) to the function (111) of managing a traffic policy; and, - a transmission (S250), to the terminal (100), of data identifying computer applications authorized or not to manage the traffic policy, and of data representing an authentication mechanism, with said telecommunications network (200), of a computer application wishing to access the function (111) for managing a traffic policy.

18. A method of controlling access according to claim 17, wherein the authentication mechanism is authentication by authentication token, the method further comprising the following steps, implemented by an authentication system (210, 220) of the telecommunications network (200): - in response to a reception (S500-1, S600-2, S600-3, S600-4) of a request to obtain an authentication token issued by the computer application (120) of the terminal (100) and including identification data (APPJD) of said computer application (120), a verification (S520-1, S620-2, S620-3, S620-4), as a function of said identification data, whether said application (120) can obtain an authentication token; and, - a transmission (S550-1, S650-2, S640-3, S640-4), to the computer application (120), of an authentication token (TKN) generated as a function of the verification (S520-1, S620-2, S620-3, S620-4).

19. A method of controlling access according to claim 18, further comprising the following steps, implemented by the authentication system (210, 220): - a generation (S530-1, S510-2, S630-3, S630-4) of an identification data (UE JD) of said terminal (100); and, - a transmission (S550-1, S650-2, S640-3, S640-4) of the identification data (UEJD) of said terminal (100) to the computer application (120).

20. Terminal (100) configured to implement the method according to one of claims 1 to 16.

21. Controller (210) of a telecommunications network (200) configured to implement the control method according to one of claims 17 to 19.

Images