WO2024028472A1 - Procédé de traitement d'une requête d'analyse statistique ou prédictive, procédé de communication et entités applicatives aptes à mettre en oeuvre ces procédés - Google Patents

Procédé de traitement d'une requête d'analyse statistique ou prédictive, procédé de communication et entités applicatives aptes à mettre en oeuvre ces procédés Download PDF

Info

Publication number
WO2024028472A1
WO2024028472A1 PCT/EP2023/071633 EP2023071633W WO2024028472A1 WO 2024028472 A1 WO2024028472 A1 WO 2024028472A1 EP 2023071633 W EP2023071633 W EP 2023071633W WO 2024028472 A1 WO2024028472 A1 WO 2024028472A1
Authority
WO
WIPO (PCT)
Prior art keywords
analysis
application entity
request
context
entity
Prior art date
Application number
PCT/EP2023/071633
Other languages
English (en)
Inventor
Philippe Tamagnan
Antoine Mouquet
Original Assignee
Orange
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 filed Critical Orange
Publication of WO2024028472A1 publication Critical patent/WO2024028472A1/fr

Links

Classifications

    • 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/14—Network analysis or design
    • H04L41/142—Network analysis or design using statistical or mathematical methods
    • 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/14—Network analysis or design
    • H04L41/147—Network analysis or design for predicting network behaviour
    • 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/14—Network analysis or design
    • H04L41/149—Network analysis or design for prediction of maintenance
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00—Arrangements for monitoring or testing data switching networks
    • H04L43/04—Processing captured monitoring data, e.g. for logfile generation
    • 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

Definitions

  • the invention belongs to the general field of telecommunications.
  • 5G core network or “5GC” for “5G Core network” in English
  • application entities are for example devices (hardware or software) hosting network functions (or NF for “Network Functions” in English) implementing functionalities such as network access, user mobility or even session management established in the network, storage and publication of network function profiles, etc.
  • the NF functions can call on a specific NF function responsible for collecting and analyzing network data, called the NWDAF function (for “NetWork Data Analytics Function”). in English).
  • NWDAF function offers the NF functions of the network which request it, statistical and/or predictive analyzes on the behavior of the network in terms in particular of quality of service and/or on the behavior of user equipment (or UE for “User Equipment” in English).
  • the analyzes carried out can be global, that is to say be established at the level of the network, a server, an application or even a region (e.g.
  • the analyzes are carried out on the basis of raw data that the NWDAF function collects from other NF functions in the network and/or from nodes of the radio access network via the network management entity in charge of operations, administration and maintenance, also known as an OAM entity (for “Operations, Administration and Maintenance” in English), and to which the NWDAF function applies one or more analysis models depending on the analyzes requested from it .
  • Such analysis models are for example statistical analysis models such as a moving average, a moving exponential average, etc., or predictive analysis models using in particular supervised or unsupervised learning technologies.
  • the statistical and/or predictive analyzes typically make it possible to implement corrective modifications to the network parameters in advance in order to optimize its operation. More specifically, the entities using these analyses, in other words the NF client functions of the NWDAF function (which may or may not be distinct from the NF functions having collected and provided the raw data to the NWDAF function), are able, depending on the statistical and/or predictive analyzes received from the NWDAF function, to adapt their behavior in order to optimize the operation of the network and the quality of the service delivered to each user on their UE.
  • the client NF functions of the NWDAF function are for example an AMF (for “Access and Mobility management Function” in English) for access management, an SMF (for “Session Management Function” in English) for session management, a PCF (Policy Control Function) function for controlling policies, etc.
  • AMF for “Access and Mobility management Function” in English
  • SMF for “Session Management Function” in English
  • PCF Policy Control Function
  • mobility forecasts of the UEs can be used by the AMF function to optimize the management of the mobility of the UEs, and in particular the determination of their registration area (or RA for “Registration Area”). in English), this recording area making it possible to locate UEs in standby and to send them solicitation messages (or “paging” in English) when data intended for them reaches the network, etc.
  • the SMF function may prove useful for the SMF function to have statistics or predictions on network traffic (e.g. load) during selection of a user plane UPF (for “User Plane Function”) for routing data from PDU sessions (for “Packet Data Unit” in English).
  • network traffic e.g. load
  • a PCF function can request statistical dispersion analyzes to modify policies or to determine the average throughput for a slice ( or “slice” in English) of a network. It should further be noted that the same statistical and/or predictive analysis may be required to support different network NF functions in different contexts and/or to implement diverse functionalities.
  • the invention responds in particular to this need by proposing a method for processing a statistical or predictive analysis request received by a first application entity of a communications network coming from a second application entity of the network, this method comprising: a step of carrying out said required statistical or predictive analysis by means of an analysis model selected as a function of a context of formulation of said request by said second application entity, determined from at least one information conveyed by the request; and a step of providing at least one result of the analysis carried out in response to the request from the second application entity.
  • the invention also relates to an application entity of a communications network, called a first application entity, comprising: a reception module configured to receive from a second application entity of the network, a statistical analysis request or predictive; a processing module, configured to carry out said analysis by means of an analysis model selected as a function of a context of formulation of said request by said second application entity, determined from at least one piece of information conveyed by said request ; and a supply module, configured to provide at least one result of the analysis carried out in response to the request from the second application entity.
  • the invention has a preferred but non-limiting application in the context of a 5G core network.
  • the first application entity and the second application entity host network functions, the network function hosted by the first application entity being a network data collection and analysis function.
  • the need for statistical and/or predictive analyzes has been formulated in the context of a 5G network. it nevertheless remains that such a need may arise in other situations, notably in other communication networks (for example proprietary networks), between application entities other than an NF function and a NWDAF function, etc.
  • NF network function
  • IP network for “Internet Protocol” in English
  • the invention proposes to improve the quality and precision of the statistical and predictive analyzes required by an application entity (second application entity within the meaning of the invention) from another application entity (first application entity within the meaning of the invention). meaning of the invention) taking into account the context in which this request is formulated, that is to say the context of use of the predictive and/or statistical analysis requested.
  • a context of formulation or use of the required analysis
  • the formulation context identifies a procedure intended to be executed by the second application entity in the network using the analysis result provided by the first application entity (e.g. registration of a UE, opening a data session, etc.).
  • each procedure of the network which calls for the performance of statistical and/or predictive analyzes constitutes a specific use case for which it is desirable that the NWDAF function (first application entity within the meaning of the invention) delivers the most relevant result in order to optimize this procedure.
  • the same statistical and/or predictive analysis may be required by the same application entity or by distinct application entities during two different procedures, in other words for different uses (e.g. long-term needs vs. short-term needs).
  • the NWDAF function relies solely on the parameters provided in the request which strictly speaking define the analysis which is required (e.g. type of analysis expected and its level of precision, the target of the analysis, etc.) and on the raw data it collects from various network entities.
  • the analysis model used by the NWDAF function may become less effective if it has to respond to a plurality of different use cases.
  • the formulation context obtained therefore constitutes an external aid which makes it possible to guide the choices made by the first application entity to carry out the analysis requested of it and to take adequate measures to obtain a relevant result for this analysis.
  • the formulation context is indicated by a parameter inserted by the second application entity in a dedicated field of the request.
  • the formulation context is explicitly informed by the second application entity, in a specific parameter, when it formulates its request.
  • a dedicated parameter is for example named UseCaseContext.
  • Different formats can be considered for this dedicated parameter, such as for example an integer, a character string, a list of integers or character strings, etc.
  • the parameter values may or may not be predefined.
  • This embodiment is particularly simple to implement and allows the first application entity to obtain reliable and precise information about the context of formulation of the request.
  • the formulation context can be determined by the first application entity from a plurality of parameters defining the analysis required by the second application entity and provided in the request.
  • parameters are taken for example from: an identity of the second application entity; a parameter representative of a type of analysis required (e.g. type and quantity of results obtained, etc.); at least one piece of equipment on which the analysis relates; a parameter representative of a condition for carrying out the analysis (e.g. geographical area, period of time, network slice concerned, etc.); an expected level of precision for the analysis; a parameter representative of a method of notification of said at least one result of the analysis (e.g. periodicity, subscription, etc.).
  • Certain groups of parameters provided in the request and the values associated with these groups of parameters can in fact be considered as signatures representative of distinct contexts. Different possibilities can then be considered: the first application entity is configured with a certain number of signatures with which contexts are associated. On receipt of the request, the first application entity determines from the parameters provided in the request, whether they correspond to one of the signatures it has. Where applicable, the context in which the request is formulated is that which is associated with the signature; the first application entity implements a learning phase during which it analyzes the parameters present in the requests received and determines, for example by means of a classification algorithm, which groups of parameters and associated values are significant and representative of a particular context.
  • the different groups of parameters and associated values thus obtained define a set of signatures corresponding to distinct formulation contexts.
  • the first application entity is able to distinguish between distinct formulation contexts, and to associate a given formulation context with a request, but it does not necessarily have the necessary information to associate with this formulation context a specific operation executed or intended to be executed by the second application entity (e.g. determination of a recording zone).
  • the formulation context provided by the second application entity in a specific field of the request is refined by the first application entity by exploiting the parameters conveyed by the request defining the analysis required by the second application entity.
  • the formulation context determined by the first application entity then includes the context provided by the second application entity (e.g. the procedure within the framework of which the request is formulated and the analysis result will be used) possibly supplemented by others information from the analysis definition parameters (e.g. UE or a group of UEs or a cell, etc.).
  • the context of formulating the query is used by the first application entity to select a relevant analysis model to carry out the statistical and/or predictive analysis requested of it.
  • the selection of the analysis model can be carried out at different levels. Thus, it may include, for example, a selection of at least one element from: a statistical or predictive analysis technique to be used to carry out the analysis; at least one characteristic of a dataset to be used to perform the analysis and/or train an analysis technique used to perform the analysis; a setting of an analysis technique used to perform the analysis; etc.
  • the processing method comprises a preliminary step of configuring the first application entity with a list of analysis models in which each analysis model is associated with at least one context of formulation of a query, the analysis model applied during the production step being an analysis model associated in this list with the context determined during the obtaining step.
  • This embodiment consists of a pre-configuration of the first application entity, for example by the network operator, with a list of possible models adapted to different contexts. It is relatively simple to implement. It should be noted that an update of the list thus preconfigured can be carried out at any time via an appropriate configuration message sent to the first application entity.
  • the processing method comprises a learning step during which the first application entity: establishes correlations between analysis models, contexts for formulating a query, and quality indicators of the analyzes carried out using said models in said contexts; and associates, from the correlations established, with at least one context for formulating a query an analysis model optimizing said quality, the analysis model applied during the production step being selected from the associations established during of the learning stage.
  • the treatment method comprises:
  • This embodiment advantageously combines the two previous ones, and thus benefits from the advantages associated with each of them.
  • the invention is based on the first application entity which obtains a context for formulating the analysis request addressed to it and uses this context to optimize the analysis results that it provides in response to this request, but also, in a particular embodiment, on the second application entity at the origin of the request and which provides the first application entity with said formulation context.
  • the invention relates to a method of communication with a first application entity of a communications network, this communication method being implemented by a second application entity of the network and comprising: a step sending to the first application entity a statistical or predictive analysis request comprising, in a dedicated field of the request, a parameter indicating a context for formulating the request; and a step of receiving, in response to the request, at least one result of the required analysis carried out by the first application entity by means of an analysis model selected according to this context.
  • the invention also targets an application entity of a communications network, called a second application entity, comprising: a sending module, configured to send to a first application entity of the network a statistical analysis request or predictive comprising, in a dedicated field of the query, a parameter indicating a context for formulating the query; and a reception module, configured to receive in response to said request, at least one result of the required analysis carried out by the first application entity by means of an analysis model selected according to this context.
  • a sending module configured to send to a first application entity of the network a statistical analysis request or predictive comprising, in a dedicated field of the query, a parameter indicating a context for formulating the query
  • a reception module configured to receive in response to said request, at least one result of the required analysis carried out by the first application entity by means of an analysis model selected according to this context.
  • the invention also relates to a system in a communications network comprising at least one first application entity and at least one second application entity conforming to the invention.
  • the communication method, the second application entity and the system according to the invention benefit from the same advantages mentioned above as the processing method and the first application entity.
  • processing and communication methods are 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 a first application entity conforming to the invention and comprising instructions adapted to the implementation of a treatment process 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 second application entity conforming to the invention and comprising instructions adapted to the implementation of a communication method as described above.
  • Each of these programs can use any programming language, and be in the form of source code, object code, or intermediate code between source code and object code, such as in a partially compiled form, or in any other desirable shape.
  • the invention also relates to an information medium or a recording medium readable by a computer, and comprising instructions for a computer program as mentioned above.
  • the information or recording medium can be any entity or device capable of storing programs.
  • the medium may comprise a storage means, such as a ROM, for example a CD ROM or a microelectronic circuit ROM, or even a magnetic recording means, for example a hard disk, or a flash memory.
  • the information or recording medium can be a transmissible medium such as an electrical or optical signal, which can be routed via an electrical or optical cable, by radio link, by optical link without wire or by other means.
  • the program according to the invention can in particular be downloaded onto 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 management, recording and communication according to the invention.
  • processing and communication methods, the first and second application entities and the system according to the invention present in combination all or part of the aforementioned characteristics.
  • Figure 1 represents, in its environment, a system in a network according to the invention, in a particular embodiment
  • FIG. 2 schematically represents the hardware architecture of a computer capable of hosting any of the entities according to the invention belonging to the system of Figure 1;
  • Figure 3 represents the functional modules of the application entities conforming to the invention of the system of Figure 1;
  • Figure 4 represents the main steps of a processing method according to the invention as they are implemented by a first application entity of the system of Figure 1;
  • Figure 5 represents the main steps of a communication method according to the invention as they are implemented by a second application entity of the system of Figure 1.
  • Figure 1 represents, in its environment, a system 1 in a communications network CN, according to the invention, in a particular embodiment.
  • the CN network is a 5GC core network of a 5G communications NW network as defined by the 3GPP standard, relying on a plurality of application entities hosting functions network (or NF functions) implementing various functionalities or services in the core network, such as network access, user mobility or even the management of sessions established in the network, storage and publication of network function profiles, etc. .
  • the NF functions can call on a specific NF function responsible for collecting and analyzing network data, called the NWDAF function (for “NetWork Data Analytics Function” in English).
  • This NWDAF function offers the NF functions of the network which request it, statistical and/or predictive analyzes on the behavior of the CN network, or more generally of the NW network, in particular in terms of quality of service, and/or on the behavior of the UEs. of the NW network.
  • These analyzes can be global (e.g. established at the level of the network, a server, an application or even a region), or be individual (ie relate to a particular UE or group of UEs). They are produced from raw data collected by the NWDAF function and statistical and/or predictive analysis models applied to this raw data.
  • the system 1 comprises: at least a first application entity 2, in accordance with the invention.
  • the application entity 2 hosts an NWDAF network function for collecting and analyzing data from the NW network as described above, and is designated in the remainder of the description by NWDAF entity 2; and at least one second application entity 3, in accordance with the invention, configured to consume the services offered by the NWDAF entity 2, in other words, request the NWDAF entity 2 to obtain statistical and/or predictive analyzes on the behavior of the network and/or a UE or a group of UEs.
  • the application entity(ies) 3 also host NF functions of the CN core network. No limitation is attached to the NF functions hosted by the application entities 3.
  • the system 1 comprises a plurality of application entities 3 conforming to the invention, including in particular an entity application entity 3-1 hosting an AMF network access function (also referred to below as AMF entity 3-1), an application entity 3-2 hosting an SMF session management function (or SMF entity 3-2), an application entity 3-3 hosting a PCF policy control function (or PCF entity 3-3), and an application entity 3-4 hosting an application AF function (or AF entity 3-4).
  • AMF entity 3-1 hosting an AMF network access function
  • SMF entity 3-2 hosting an SMF session management function
  • PCF entity 3-3 PCF policy control function
  • an application entity 3-4 hosting an application AF function or AF entity 3-4
  • Each application entity of system 1 is a communicating device, hardware or virtual (i.e. software), configured to implement a specific processing logic, corresponding to the network function that it hosts.
  • a communicating device hardware or virtual (i.e. software)
  • virtual i.e. software
  • the invention applies equally to software or virtual application entities and to hardware application entities hosting network functions.
  • the application entities considered are hardware devices (for example servers of a CN core network infrastructure), they then have the hardware architecture of a computer 4, as illustrated in Figure 2.
  • This hardware architecture is based on a PROC processor, a MEM RAM, a ROM read-only memory, a non-volatile memory NVM, and COM means of communications with other entities, for example, other application entities of the CN core network , entities of an access network to the core network CN such as for example an OAM entity for managing the NW network (not shown in Figure 1), or even with UEs of the NW network.
  • COM means of communication can in particular rely on a wired or wireless communication interface, known per se and not described in more detail here, but also on one or more software interfaces such as an application programming interface (or API for “Application Programming Interface” in English) or a point-to-point communication interface.
  • an application programming interface or API for “Application Programming Interface” in English
  • a point-to-point communication interface such as an application programming interface (or API for “Application Programming Interface” in English) or a point-to-point communication interface.
  • the application entities considered are software, they are themselves hosted by a hardware device having the hardware architecture of the computer 4, and can then rely on the hardware means of the computer 4 mentioned above front (PROC, MEM, ROM, NVM, COM).
  • PROC, MEM, ROM, NVM, COM the hardware means of the computer 4 mentioned above front
  • the non-volatile memory NVM of the computer 4 constitutes a recording medium in accordance with the invention, readable by the PROC processor and on which a computer program in accordance with the invention is recorded.
  • this computer program is referenced by PROG2 and includes instructions defining the main steps of a processing method according to the invention.
  • PROG3 the computer program in question is referenced by PROG3 and includes instructions defining the main steps of a communication method according to the invention.
  • the PROG2 program defines the functional modules of an application entity 2 and in particular of the NWDAF entity 2 of system 1, which rely on or control the PROC, MEM, ROM, NVM, and COM elements of the computer 4, cited previously.
  • These functional modules include in particular, in the embodiment described here, as illustrated in Figure 3: a reception module 2A configured to receive from an application entity 3 of system 1 a REQ request for statistical or predictive analysis; a determination module 2B, configured to obtain from at least one piece of information conveyed by this REQ request, a CTX context for formulating the request by the application entity 3.
  • Such a CTX formulation context is typically representative of the case of use of the required statistical or predictive analysis, it identifies for example a procedure that the application entity 3 will execute using the result of the requested statistical or predictive analysis; a processing module 2C, configured to carry out the required analysis by means of an analysis model selected according to the CTX context determined by the determination module 2B; and a 2D supply module, configured to provide at least one result of the analysis carried out by the 2C processing module in response to the REQ request from the application entity 3.
  • the PROG3 program defines the functional modules of an application entity 3, and more particularly of each of the entities AMF 3-1, SMF 3-2, PCF 3-3 and AF 3-4 of system 1 , these functional modules relying on or controlling the PROC, MEM, ROM, NVM, and COM elements of the computer 4, cited above.
  • the functional modules of an application entity 3 according to the invention include in particular, as illustrated in Figure 3: a sending module 3A, configured to send to the application entity 2, and more particularly here to the NWDAF entity 2, a REQ request for statistical or predictive analysis.
  • the sending module 3A is configured to use, to send the REQ request, an API of the NWDAF entity 2, as detailed further later.
  • a reception module 3B configured to receive in response to the REQ request addressed to the NWDAF entity 2, at least one result of the required analysis carried out by the NWDAF entity 2 by means of an analysis model selected by this depending on the CTX context
  • an execution module 3C configured to execute a procedure associated with the network function hosted by the application entity 3 using an analysis result received by the reception module 3B. The procedure executed depends of course on the network function hosted by the application entity 3.
  • It may for example be a registration procedure or determination of a registration zone for the AMF entity 3-1 , a session opening procedure or selection of a UPF function of the user plane of the CN core network for the SMF 3-2 entity, a procedure for modifying a policy or determining an average throughput for a given network slice for a PCF 3-3 entity, a procedure for optimizing a setting for a UE or detecting fraud for an AF 3-4 entity, etc.
  • the AMF entity 3-1 via its sending module 3A, sends a REQ request to the NWDAF entity 2, and more particularly to its receiving module 2A, requesting a prediction of EU 5 mobility (step E10).
  • the module 3A for sending the AMF entity 3-1 uses for this purpose the Nnwdaf_AnalyticsInfo service of the API of the NWDAF entity 2, described in the documents 3GPP TS 23.288 entitled “Architecture Enhancements for 5G system (5GS) to support network data analytics services (Release 17)”, V17.4.0, March 2022, and TS 28.520 entitled “Technical Specification Group Core Network and Terminals; 5G System; Network Data Analytics Services; Stage 3; (Release 17)”, V17.6.0, March 2022.
  • the REQ request here is a simple Nnwdaf_AnaiyticsInfo Request type request.
  • the sending of the REQ request by the sending module 3A is not necessarily carried out synchronously with this procedure. It can be carried out asynchronously, typically upstream of the procedure in question, in advance, to be able to have the result of the analysis to execute the procedure in question without delay.
  • the module 3A for sending the AMF entity 3-1 provides in the REQ request various P-DEF parameters defining the requested statistical and/or predictive analysis, and in particular: identity of the application entity at the origin of the request, that is to say here the identity of the AMF 3-1 entity; one or more parameters representative of the type of analysis requested.
  • identity of the application entity at the origin of the request that is to say here the identity of the AMF 3-1 entity
  • parameters representative of the type of analysis requested can in particular define the nature of the analysis or, equivalently, the type of expected result (e.g. mobility prediction here), the expected quantity of results, etc. ; the target of the analysis, that is to say the equipment(s) on which the analysis relates (e.g.
  • EU 5 here); one or more parameters representative of the conditions for carrying out the analysis, for example the period of time targeted, the geographical area targeted, the network slice concerned, etc. ; an expected level of precision for the analysis; one or more parameters representative of the analysis network's notification methods (e.g. periodicity, subscription, etc.).
  • the module 3A for sending the AMF entity 3-1 also inserts in the REQ request, in a dedicated field and more particularly in the UseCaseContext field introduced previously, a P-CTX parameter indicating the CTX context in which the REQ request is formulated, that is to say the context of use of the result(s) of the analysis requested in the REQ request.
  • the P-CTX parameter here identifies the PROC procedure that the AMF 3-1 entity is about to execute using the result of the prediction requested in the REQ request.
  • the P-CTX parameter contained in the UseCaseContext field of the REQ request identifies as procedure, the determination of the registration zone of the UE 5.
  • a new UseCaseContent field is added to the messages exchanged using the Nnwdaf_AnalyticsInfo and Nnwdaf_AnalyticsSubscription services.
  • No limitation is attached to the format of the P-CTX parameter. It can be an integer uniquely designating the CTX context, a character string defining this CTX context, or even a list of integers or character strings, etc.
  • the parameter in question takes a predefined value from a set of predefined values, each uniquely associated with a particular context (e.g.
  • Appendix 1 provides, by way of illustration, a non-exhaustive list established by the inventors, of contexts and associated predictive or statistical analyzes likely to be requested from an NWDAF function in a 5G network, and therefore incidentally in the CN network.
  • the same CTX context can be associated with different statistical/predictive analyses: for example, the context “Modification of RFSP policies by a PCF” can be based on analyzes relating to the load of slices of the network or on analyzes relating to UE communications and the observed service experience (or OSE for “Observed Service Experience” in English).
  • the corresponding requests addressed in this example by the PCF entity to the NWDAF entity include the same P-CTX parameter designating the context "Modification by a PCF of RFSP policies", while the P-DEF parameters provided in the requests designate for one of the queries, a statistical/predictive analysis relating to the load of the network slices, and for the other, statistical/predictive analyzes relating to UE communications and the OSE.
  • V2X vehicular communication service
  • the type of entity X considered may influence the choice of the analysis model.
  • the determination by the sending module 3A of the AMF entity 3-1 of the CTX context for formulating the REQ request does not pose any difficulty in itself since it reflects the PROC procedure currently being carried out. execution by the AMF 3-1 entity (and more particularly by its processing module 3C) or a PROC procedure that this AMF 3-1 entity is about to execute (the REQ request not necessarily being sent synchronously by relation to the execution of the procedure in question).
  • the NWDAF entity 2 upon receipt of the REQ request by its reception module 2A (step F10), the NWDAF entity 2, via its processing module 2C, determines from the parameters P -DEF provided in the REQ request, the statistical and/or predictive analysis requested by the AMF entity 3-1 (step F20), namely in the illustrative example considered here, a prediction of the mobility of the UE 5 under the conditions established by the P-DEF parameters.
  • the NWDAF entity 2 via its determination module 2B, also determines, from at least one piece of information conveyed by the REQ request, the CTX context in which the REQ request was formulated (step F30).
  • This CTX context for formulating the REQ request gives the NWDAF entity 2 an indication of how the prediction requested by the AMF entity 3-1 will be used.
  • the determination module 2B extracts the P-CTX parameter contained in the UseCaseContext field of the REQ request which identifies the PROC procedure requesting the statistical or predictive analysis requested in the REQ query.
  • the REQ request includes the UseCaseContext field, and this field is supplied by the AMF 3-1 entity with the P-CTX parameter identifying the context in which is formulated the REQ query.
  • the determination module 2B determines the CTX context from the content of the P-CTX parameter included in the UseCaseContext field of the REQ request.
  • the UseCaseContext field is optional, and that in the absence of such a field in the request, the determination module 2B is configured to determine the CTX context for formulating the REQ request from the information.
  • the P-DEF parameters mentioned previously namely the P-DEF parameters provided by the AMF 3-1 entity in the REQ request representative of its identity, the type of requested analysis, the target of this analysis (e.g. a UE or a group of UEs, a cell, etc.), the conditions for carrying out this analysis, the expected level of precision, methods of reporting the results of the analysis, etc.
  • the determination module 2B can rely on a supervised or unsupervised artificial intelligence (or AI) technique, or be configured with pre-established rules, defined for example by the operator of the CN core network, establishing a correspondence between the values of all or part of the aforementioned P-DEF parameters conveyed by the REQ request and different contexts of formulation of this REQ request.
  • AI artificial intelligence
  • certain groups of P-DEF parameters provided in the REQ request and the values associated with these groups of parameters can be used to define signatures representative of distinct contexts.
  • the NWDAF entity 2 and more particularly its determination module 2B is configured with a certain number of signatures with which contexts are associated, and that upon receipt of the REQ request, the determination module 2B determines from the P-DEF parameters provided in the REQ request, whether they correspond to one of the signatures with which it has been configured. If applicable, the context for formulating the request determined by the determination module 2B is that which is associated with the signature.
  • the configuration of the NWDAF entity 2 can be carried out in particular by the operator of the CN network by means of signatures determined by the latter, for example during a configuration phase such as conventionally implemented during the the introduction of new equipment or services into a network.
  • the module 2B for determining the NWDAF entity 2 can implement a learning phase during which it analyzes the P-DEF parameters present in a set of REQ requests previously received by the NWDAF entity 2, and determines, for example by means of a classification algorithm, which groups of parameters and associated values are significant and representative of a particular context. The different groups of parameters and associated values thus obtained define a set of signatures corresponding to distinct formulation contexts.
  • the determination module 2B is able to distinguish between distinct formulation contexts, and to associate a given formulation context with a request; however, it does not necessarily have the information necessary to associate with this formulation context, a specific operation executed or intended to be executed by the application entity at the origin of the REQ request (e.g. determination of a zone of registration).
  • the P-DEF parameters include three parameters X, Y, Z, and that the determination module 2B determines during the learning phase that:
  • the determination module 2B On receipt of a new REQ request, the determination module 2B is capable, from these signatures, of determining whether the context of formulation of the new REQ request is the CTX1 context or the CTX2 context, but in the absence of additional information, it is not capable of identifying the procedure associated with the context thus determined, that is to say for example, that CTX1 identifies a procedure for determining a recording area and CTX2 identifies a procedure for optimizing paging.
  • the determination module 2B being configured, for example by the network operator CN, with rules for matching the labels determined during the phase learning by the determination module 2B and procedures likely to be implemented by the application entities corresponding to these labels.
  • the determination module 2B is configured with the following associations:
  • CTX1 Determination of a UE registration zone
  • CTX2 Optimization of paging
  • the group of signatures on which the determination module 2B is based may be required to evolve over time; in particular, it can be supplemented with new signatures, or these can be modified when new learning phases are carried out.
  • the NWDAF 2 entity exploits (i.e. uses) the CTX context for formulating the REQ request to select a relevant analysis model to carry out the analysis requested by the AMF 3-1 entity. , and more particularly here, a prediction of the mobility of EU 5 (step F40).
  • an NWDAF network function (and a fortiori the NWDAF entity 2 and its processing module 2C) has at its disposal a plurality of analysis techniques that it can use depending on the nature of the analyzes requested of it.
  • models conventionally used by an NWDAF network function are in particular: a model carrying out a moving average on all or part of the data collected by the NWDAF network function; a model performing a moving exponential average on all or part of the data collected by the NWDAF network function; etc.
  • the prediction models typically used by an NWDAF network function rely in particular on time series modeling techniques using machine learning techniques.
  • supervised or unsupervised which can exploit a wide variety of algorithms, such as Markov chains, neural networks (e.g. LSTM type neural networks for “Long Short Term Memory” in English), exponential smoothing (or “Long Short Term Memory”). exponential smoothing" in English), models of the ARCH type (for "AutoRegressive Conditional Heteroskedasticity” in English), or of the ARMA or ARIMA type which combine autoregressive process (AR for "AutoRegressive” in English), moving average (MA for “Moving Average” in English) and possibly integration (I for “Integrated” in English), etc.
  • each of the aforementioned analysis techniques can be configured differently, or rely on data sets having distinct characteristics (in addition to the nature of the data collected, such as the quantity of data, etc. ) for the analysis or for the training of said analysis technique, which leads to as many distinct models that can be selected by the NWDAF 2 entity.
  • the CTX context provides the latter with a guide which allows it to make an informed and relevant selection of the analysis model to be applied to respond to the request of the AMF entity 3-1, and more particularly of at least one element among: a statistical or predictive analysis technique to be used to carry out the analysis among a plurality of predefined techniques, such as for example, an ARIMA model, an ARCH model, exponential smoothing, moving average, etc.
  • the selection can be made, for example, from different families of known models such as those mentioned above or combinations of such models; and/or at least one characteristic (e.g. a quantity of data) of a data set to be used to carry out the analysis and/or train an analysis technique used to carry out the analysis; and/or a parameter setting (e.g. in a neural network, number of layers, neurons per layer, synaptic weights, etc.) of an analysis technique used to carry out the analysis. It should be noted that such configuration is not limited to taking into account the input parameters provided by the AMF 3-1 entity at the origin of the REQ request.
  • the selection of an analysis model by the processing module 2C as a function of the CTX context determined by the determination module 2B is permitted via a prior (pre)configuration of the NWDAF entity 2. More specifically, it is assumed that during a preliminary configuration step (step F00), the NWDAF entity 2 has been configured, for example by the NW network operator via an appropriate interface or the use of 'an appropriate configuration protocol, with a LIST of statistical and predictive analysis models, in which each analysis model is associated with at least one query formulation context. This LIST list is stored for example in the non-volatile memory NVM of the NWDAF entity 2. It should be noted that a formulation context can be associated with several analysis models or with a family of analysis models.
  • the module 2C for processing the entity NWDAF 2 consults the list LIST preconfigured during step F00, and selects an analysis model MOD(CTX) in the list LIST, associated with the CTX context. If several analysis models are possible, the 2C processing module chooses one, for example taking into account criteria such as the calculation time or the calculation power necessary with regard to all or part of the P-DEF parameters provided in the REQ query (for example, the level of precision and/or the delivery time of analysis results).
  • the LIST list stored in the non-volatile memory NVM of the NWDAF entity 2 is not necessarily fixed, and may be required to evolve over time (step F00').
  • the LIST list can be updated and/or supplemented to reflect this evolution in a manner similar or identical to what was described previously for step F00.
  • the NWDAF entity 2 can be updated by the NWDAF entity 2 itself, for example by its processing module 2C, during a learning or training phase, during which the module 2C processing may be required to revise the associations included in the LIST list between analysis models and formulation contexts, and/or create new associations relating to new analysis models and/or new formulation contexts.
  • These new analysis models and/or formulation contexts can be communicated to the NWDAF 2 entity by the network operator or by another actor, for example the designer of the NWDAF 2 entity, or also be determined by learning .
  • This learning phase can be based as training data on the analyzes previously carried out by the 2C processing module. She can also or alternatively exploit learning data provided by a third party, such as for example by the network operator, by the designer of the NWDAF 2 entity, etc.
  • the processing module 2C can evaluate the quality of the results obtained using determined quality indicators.
  • the processing module 2C can for example, following obtaining an analysis result such as a prediction, continue to collect data and verify that the prediction obtained is correct, or re-evaluate from these new data a new prediction and compare the re-evaluated prediction with the initial prediction.
  • an analysis result such as a prediction
  • other techniques can be considered to evaluate the quality of the results obtained by the 2C processing module.
  • the processing module 2C correlates the statistical analysis models available to it, the different possible values of formulation contexts, and the quality indicators of the analyzes carried out from these models. analysis for these formulation contexts. Then it selects, for a given formulation context, the analysis model(s) leading to the best quality indicators. It then updates the LIST list with the (new) context - analysis model(s) associations thus obtained if necessary (in other words, it updates/corrects certain associations of the LIST list and/or completes the list LIST with new associations obtained during the learning phase).
  • the processing module 2C can execute several learning phases at different times depending on the learning data available to it; thus in particular, it can during a learning phase, target the learning data that it uses by retaining only the learning data associated with a particular formulation context, to determine the model(s). ) analysis the most relevant(s) for this context, and make this formulation context evolve from one learning phase to another.
  • no preconfiguration of the NWDAF 2 entity is implemented, and it is the NWDAF 2 entity via its processing module 2C which itself establishes the LIST list and the updates over time during at least one learning (or training) phase identical or similar to what has just been described.
  • This training sentence can be supervised or not (i.e. rely on training data provided by the network operator and/or the designer of the NWDAF 2 entity or only on data of learning collected by the NWDAF entity 2).
  • the processing module 2C collects the INPUT_DATA network data necessary to carry out the statistical and/or predictive analysis which was requested of it. This collection can be carried out from different entities, depending on the type of analysis required, using the procedures described in particular in document 3GPP TS 23.288 in paragraph 6.7.2.4.
  • the 2C processing module carries out the statistical and/or predictive analysis (EU 5 mobility prediction in the example considered here) which was requested by the AMF 3.1 entity by applying the MOD(CTX) analysis model to the collected INPUT_DATA data (step F50).
  • the function of the processing module 2C has been considered here as a whole, without prejudging the way in which the processing module 2C is strictly speaking organized to ensure this function.
  • the NWDAF entity in a 5G core network can be broken down into two functions or modules, an MLTF module (for “Model Training Logical Function” in English) responsible for training and providing the analysis models and an AnLF module (for “Analytics Logical Function” in English) responsible for producing the analyzes using the models provided by the MLTF module.
  • the analysis models are obtained by the AnLF module using the Nnwdaf_MLModelProvision and Nnwdaf_MLModelInfo services defined by the 3GPP standard. If such an organization is envisaged for the NWDAF 2 entity, then we can add to the services Nnwdaf_MLModelProvision and Nnwdaf_MLModelInfo a new UseCaseContent field, as was done previously for the Nnwdaf_AnalyticsInfo and Nnwdaf_AnalyticsSubscription services, so that the AnLF module can specify to the MLTF module the CTX context for formulating the REQ request and the MLTF module selects the analysis model to apply according to this formulation CTX context. In a variant embodiment, the AnLF module itself selects the analysis model to use according to the CTX context then requests the selected model from the MTLF module.
  • the NWDAF entity 2 provides, through its 2D supply module, the RES analysis result obtained by the processing module 2C (prediction of the mobility of the UE 5 in the example envisaged here ) to the AMF entity 3-1 in response to its REQ request (step F60).
  • the module 2C for executing the AMF entity 3-1 executes the PROC procedure within the framework of which it requested the NWDAF entity 2 using the RES analysis result provided by the NWDAF entity 2 (step E30).
  • the execution module 3C determines the registration zone of the UE 5 using the mobility prediction of the UE 5 provided by the NWDAF entity 2, in a manner known in self.
  • the invention has just been described in the context of a 5G core network, and in particular of an NWDAF function of such a network, advantageously relying on the APIs defined by the 3GPP standard, modified to the needs of the invention.
  • the invention can however be applied in other contexts, and in particular to other networks, for example to proprietary networks, future generation networks or corresponding to other versions (or “Releases” in English) of a 5G network, IP networks, etc., to other application entities, such as routers, SDN controllers, etc. which can be requested by various application entities of the network in order to deliver statistical and/or predictive analyses, and exploit interfaces other than APIs (e.g. point-to-point interfaces) to implement the invention.
  • APIs e.g. point-to-point interfaces

Landscapes

  • Engineering & Computer Science (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Mathematical Analysis (AREA)
  • Mathematical Optimization (AREA)
  • Mathematical Physics (AREA)
  • Probability & Statistics with Applications (AREA)
  • Pure & Applied Mathematics (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Algebra (AREA)
  • Data Mining & Analysis (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

L'invention concerne un procédé de traitement d'une requête (REQ) d'analyse statistique ou prédictive reçue par une première entité applicative d'un réseau de communications en provenance d'une deuxième entité applicative du réseau, ce procédé comprenant : - une étape (F30) de détermination, à partir d'au moins une information véhiculée (P-CTX, P-DEF) par ladite requête, d'un contexte (CTX) de formulation de ladite requête par ladite deuxième entité applicative; - une étape (F50) de réalisation de ladite analyse statistique ou prédictive requise au moyen d'un modèle (MOD(CTX)) d'analyse sélectionné (F40) en fonction dudit contexte déterminé; et - une étape (F60) de fourniture d'au moins un résultat (RES) de l'analyse réalisée en réponse à ladite requête de la deuxième entité applicative.

Description

Description
Titre de l'invention : Procédé de traitement d'une requête d'analyse statistique ou prédictive, procédé de communication et entités applicatives aptes à mettre en œuvre ces procédés
Technique antérieure
[0001] L'invention appartient au domaine général des télécommunications.
[0002] Elle concerne plus particulièrement les réseaux de communication s'appuyant sur une pluralité d'entités applicatives implémentant diverses fonctionnalités ou services dans le réseau, comme par exemple un réseau cœur 5G (ou « 5GC » pour « 5G Core network » en anglais) tel que défini par le standard 3GPP. De telles entités applicatives sont par exemple des dispositifs (matériels ou logiciels) hébergeant des fonctions réseau (ou NF pour « Network Functions » en anglais) implémentant des fonctionnalités telles que l'accès au réseau, la mobilité des utilisateurs ou encore la gestion des sessions établies dans le réseau, le stockage et la publication des profils des fonctions réseau, etc.
[0003] Afin d'optimiser les procédures au sein du réseau cœur 5G, les fonctions NF peuvent faire appel à une fonction NF spécifique chargée de collecter et d'analyser des données du réseau, appelée fonction NWDAF (pour « NetWork Data Analytics Function » en anglais). La fonction NWDAF propose aux fonctions NF du réseau qui la sollicitent, des analyses statistiques et/ou prédictives sur le comportement du réseau en termes notamment de qualité de service et/ou sur le comportement des équipements utilisateurs (ou UE pour « User Equipment » en anglais). Les analyses réalisées peuvent être globales, c'est-à-dire être établies au niveau du réseau, d'un serveur, d'une application ou encore d'une région (ex. taux de charge des ressources du réseau à un moment particulier de la journée ou de l'année, qualité de service moyenne, nombre d'utilisateurs connectés au réseau ou de sessions actives, etc.), ou être individuelles, c'est-à-dire porter sur un UE ou sur un groupe d'UE particulier (ex. future localisation d'un UE, volumétrie d'une future session de communication d'un UE, etc.). Les analyses sont réalisées sur la base de données brutes que la fonction NWDAF collecte auprès d'autres fonctions NF du réseau et/ou auprès de nœuds du réseau d'accès radio via l'entité de gestion du réseau en charge des opérations, de l'administration et de la maintenance, aussi connue sous le nom d'entité OAM (pour « Operations, Administration and Maintenance » en anglais), et auxquelles la fonction NWDAF applique un ou plusieurs modèles d'analyse en fonction des analyses qui lui sont demandées. De tels modèles d'analyse sont par exemple des modèles d'analyse statistique tels qu'une moyenne mobile, une moyenne exponentielle mobile, etc., ou des modèles d'analyse prédictive utilisant notamment des technologies d'apprentissage supervisé ou non supervisé.
[0004] Une fois établies, les analyses statistiques et/ou prédictives permettent typiquement de mettre en œuvre de façon anticipée des modifications correctives sur les paramètres du réseau afin d'optimiser son fonctionnement. Plus spécifiquement, les entités utilisatrices de ces analyses, autrement dit les fonctions NF clientes de la fonction NWDAF (qui peuvent être distinctes ou non des fonctions NF ayant collecté et fourni les données brutes à la fonction NWDAF), sont en mesure, en fonction des analyses statistiques et/ou prédictives reçues de la fonction NWDAF, d'adapter leur comportement en vue d'optimiser le fonctionnement du réseau et la qualité du service délivré à chaque utilisateur sur son UE. Les fonctions NF clientes de la fonction NWDAF sont par exemple une fonction AMF (pour « Access and Mobility management Function » en anglais) de gestion d'accès, une fonction SMF (pour « Session Management Function » en anglais) de gestion de sessions, une fonction PCF (pour « Policy Control Function » en anglais) de contrôle des politiques, etc.
[0005] Le document 3GPP TR 23.791, intitulé « Technical Specification Group Services and System Aspects ; Study of Enablers for Network Automation for 5G (Release 16) », V16.2.0, juin 2019, évoque différents cas d'usage de telles analyses statistiques et/ou prédictives dans un réseau 5G. [0006] Ainsi, par exemple, des prévisions de mobilité des UE peuvent être utilisées par la fonction AMF pour optimiser la gestion de la mobilité des UE, et en particulier la détermination de leur zone d'enregistrement (ou RA pour « Registration Area » en anglais), cette zone d'enregistrement permettant de localiser des UE en veille et de leur adresser des messages de sollicitation (ou « paging » en anglais) lorsque des données leur étant destinées parviennent au réseau, etc. Ce cas d'usage est également décrit dans le document 3GPP TS 23.501, intitulé « Technical Specification Group Services and System aspects ; System architecture for the 5G system (5GS) ; Stage 2 (Release 17) », V17.4.0, mars 2022, notamment au paragraphe 5.3.2.
[0007] Selon un autre exemple également décrit dans le document 3GPP TS 23.501 au paragraphe 6.3.3.3, il peut s'avérer utile à la fonction SMF de disposer de statistiques ou de prédictions sur le trafic réseau (ex. charge) lors de la sélection d'une fonction UPF (pour « User Plane Function » en anglais) de plan utilisateur permettant d'acheminer les données des sessions PDU (pour « Packet Data Unit » en anglais).
[0008] Selon un autre exemple encore décrit notamment dans le document 3GPP TS 23.503, intitulé « Technical Specification Group Services and System aspects ; Policy and charging control framework for the 5G system (5GS) ; Stage 2 (Release 17) », V17.4.0, mars 2022, notamment aux paragraphes 4.2.3 et 6.1.1.3, une fonction PCF peut demander des analyses statistiques de dispersion pour modifier des politiques ou pour déterminer le débit moyen pour une tranche (ou « slice » en anglais) d'un réseau. Il convient de noter en outre qu'une même analyse statistique et/ou prédictive peut être requise pour assister différentes fonctions NF du réseau dans différents contextes et/ou pour implémenter des fonctionnalités diverses.
[0009] On comprend bien dès lors, au vu des nombreux cas d'usage des analyses statistiques et/ou prédictives délivrées par la fonction NWDAF et de leur importance dans le fonctionnement opérationnel du réseau, que ces analyses doivent être précises et pertinentes.
Exposé de l'invention
[0010] L'invention répond notamment à ce besoin en proposant un procédé de traitement d'une requête d'analyse statistique ou prédictive reçue par une première entité applicative d'un réseau de communications en provenance d'une deuxième entité applicative du réseau, ce procédé comprenant : une étape de réalisation de ladite analyse statistique ou prédictive requise au moyen d'un modèle d'analyse sélectionné en fonction d'un contexte de formulation de ladite requête par ladite deuxième entité applicative, déterminé à partir d'au moins une information véhiculée par la requête ; et une étape de fourniture d'au moins un résultat de l'analyse réalisée en réponse à la requête de la deuxième entité applicative.
[0011] Corrélativement, l'invention concerne également une entité applicative d'un réseau de communications, dite première entité applicative, comprenant : un module de réception configuré pour recevoir d'une deuxième entité applicative du réseau, une requête d'analyse statistique ou prédictive ; un module de traitement, configuré pour réaliser ladite analyse au moyen d'un modèle d'analyse sélectionné en fonction d'un contexte de formulation de ladite requête par ladite deuxième entité applicative, déterminé à partir d'au moins une information véhiculée par ladite requête ; et un module de fourniture, configuré pour fournir au moins un résultat de l'analyse réalisée en réponse à la requête de la deuxième entité applicative.
[0012] Comme évoqué précédemment, l'invention a une application privilégiée mais non limitative dans le contexte d'un réseau cœur 5G. Ainsi, par exemple, la première entité applicative et la deuxième entité applicative hébergent des fonctions réseau, la fonction réseau hébergée par la première entité applicative étant une fonction de collecte et d'analyse de données du réseau. [0013] Il convient toutefois de noter que si le besoin d'analyses statistiques et/ou prédictives a été formulé dans le contexte d'un réseau 5G. il n'en demeure pas moins qu'un tel besoin peut se présenter dans d'autres situations, notamment dans d'autres réseaux de communication (par exemple des réseaux propriétaires), entre d'autres entités applicatives qu'une fonction NF et une fonction NWDAF, etc. Par entité applicative, on entend ici tout type de dispositif communicant, matériel ou virtuel (i.e. logiciel), configuré pour mettre en œuvre une logique de traitement déterminée, comme par exemple un dispositif offrant et/ou consommant des services dans un réseau telle qu'une fonction réseau (NF) ou une instance de fonction réseau d'un réseau cœur conforme au standard 3GPP, mais également une unité de gestion de routeurs ou encore un contrôleur SDN (pour « Software Defined Network » en anglais) dans un réseau IP (pour « Internet Protocol » en anglais), etc.
[0014] Ainsi, l'invention propose d'améliorer la qualité et la précision des analyses statistiques et prédictives requises par une entité applicative (deuxième entité applicative au sens de l'invention) auprès d'une autre entité applicative (première entité applicative au sens de l'invention) en tenant compte du contexte dans lequel est formulée cette requête, c'est-à-dire le contexte d'usage de l'analyse prédictive et/ou statistique demandée. Un tel contexte de formulation (ou d'usage de l'analyse requise) peut typiquement comprendre la raison de cette requête, c'est-à-dire la destination du résultat d'analyse ou le cas d'usage pour lequel l'analyse statistique et/ou prédictive est requise. Ainsi, dans un mode particulier de réalisation, le contexte de formulation identifie une procédure destinée à être exécutée par la deuxième entité applicative dans le réseau en utilisant le résultat d'analyse fourni par la première entité applicative (ex. enregistrement d'un UE, ouverture d'une session de données, etc.).
[0015] Les inventeurs ont en effet constaté que, dans un réseau cœur 5G, chaque procédure du réseau qui appelle la réalisation d'analyses statistiques et/ou prédictives (ex. enregistrement, ouverture de session, optimisation d'un profil d'usager, etc.) constitue un cas d'usage spécifique pour lequel il est souhaitable que la fonction NWDAF (première entité applicative au sens de l'invention) délivre le résultat le plus pertinent afin d'optimiser cette procédure. Par ailleurs, comme évoqué précédemment, une même analyse statistique et/ou prédictive peut être requise par une même entité applicative ou par des entités applicatives distinctes au cours de deux procédures différentes, autrement dit pour des usages différents (ex. besoins de long terme vs besoins de court terme). Or à ce jour, pour réaliser l'analyse qui lui est demandée, la fonction NWDAF s'appuie uniquement sur les paramètres fournis dans la requête qui définissent à proprement parler l'analyse qui est requise (ex. type d'analyse attendue et son niveau de précision, la cible de l'analyse, etc.) et sur les données brutes qu'elle collecte auprès de diverses entités du réseau. Le modèle d'analyse utilisé par la fonction NWDAF peut perdre en efficacité à devoir répondre à une pluralité de cas d'usage différents.
[0016] La connaissance du contexte de formulation de la requête et en particulier la motivation pour laquelle cette requête a été faite, constitue une information précieuse pour la première entité applicative pour améliorer la précision et la pertinence de l'analyse statistique et/ou prédictive qu'elle réalise. En effet, cette information offre la possibilité à la première entité applicative de sélectionner de manière parfaitement adaptée le modèle d'analyse qui va délivrer la meilleure analyse statistique et/ou prédictive pour une situation applicative donnée, autrement dit pour un cas d'usage donné. Par exemple, pour une fonction AMF, savoir que l'on utilise une analyse pour une mise à jour d'une zone d'enregistrement ou pour localiser un UE (aussi plus communément désigné par l'appellation anglaise « paging ») peut conduire à choisir des modèles d'analyse très différents en termes de technique mathématique et/ou de paramètres de réglage. Pour mieux comprendre l'apport de l'invention, on peut faire l'analogie avec la vie courante et la situation d'un médecin qui devrait réaliser des analyses sur un patient sans disposer d'informations sur son patient (ex. son âge, s'il est fumeur ou non, etc.) ni la raison pour laquelle ces analyses sont nécessaires (ex. présence de douleurs).
[0017] Le contexte de formulation obtenu constitue donc une aide externe qui permet de guider les choix faits par la première entité applicative pour réaliser l'analyse qui lui est demandée et de prendre des dispositions adéquates pour obtenir un résultat pertinent pour cette analyse.
[0018] Différentes façons peuvent être envisagées pour obtenir le contexte de formulation.
[0019] Ainsi, dans un mode particulier de réalisation, le contexte de formulation est indiqué par un paramètre inséré par la deuxième entité applicative dans un champ dédié de la requête.
[0020] En d'autres mots, le contexte de formulation est renseigné explicitement par la deuxième entité applicative, dans un paramètre spécifique, lorsqu'elle formule sa requête. Un tel paramètre dédié est par exemple nommé UseCaseContext. Différents formats peuvent être envisagé pour ce paramètre dédié, tels que par exemple un entier, une chaîne de caractères, une liste d'entiers ou de chaînes de caractères, etc. Les valeurs du paramètre peuvent être prédéfinies ou non.
[0021] Ce mode de réalisation est particulièrement simple à mettre en œuvre et permet à la première entité applicative d'obtenir une information fiable et précise du contexte de formulation de la requête.
[0022] En variante, le contexte de formulation peut être déterminé par la première entité applicative à partir d'une pluralité de paramètres définissant l'analyse requise par la deuxième entité applicative et fournis dans la requête. De tels paramètres sont pris par exemple parmi : une identité de la deuxième entité applicative ; un paramètre représentatif d'un type d'analyse requis (ex. type et quantité de résultats obtenus, etc.) ; au moins un équipement sur lequel porte l'analyse ; un paramètre représentatif d'une condition de réalisation de l'analyse (ex. zone géographique, période de temps, tranche de réseau concernée, etc.) ; un niveau de précision attendu pour l'analyse ; un paramètre représentatif d'une modalité de notification dudit au moins un résultat de l'analyse (ex. périodicité, souscription, etc.).
[0023] Certains groupes de paramètres fournis dans la requête et les valeurs associées à ces groupes de paramètres peuvent en effet être considérés comme des signatures représentatives de contextes distincts. Différentes possibilités peuvent alors être envisagées : la première entité applicative est configurée avec un certain nombre de signatures auxquelles sont associées des contextes. Sur réception de la requête, la première entité applicative détermine à partir des paramètres fournis dans la requête, s'ils correspondent à l'une des signatures dont elle dispose. Le cas échéant, le contexte de formulation de la requête est celui qui est associée à la signature ; la première entité applicative met en œuvre une phase d'apprentissage au cours de laquelle elle analyse les paramètres présents dans les requêtes reçues et détermine, par exemple au moyen d'un algorithme de classification, quels groupes de paramètres et valeurs associées sont significatifs et représentatifs d'un contexte particulier. Les différents groupes de paramètres et valeurs associées ainsi obtenus définissent un ensemble de signatures correspondant à des contextes de formulation distincts. Il convient de noter que dans ce cas, la première entité applicative est en mesure de faire le distinguo entre des contextes de formulation distincts, et d'associer un contexte de formulation donné à une requête, mais elle ne dispose pas nécessairement des informations nécessaires pour associer à ce contexte de formulation une opération spécifique exécutée ou destinée à être exécutée par la deuxième entité applicative (ex. détermination d'une zone d'enregistrement).
[0024] Il convient par ailleurs de noter que certains des paramètres fournis dans la requête peuvent présenter une certaine variabilité pour un cas usage donné ; aussi il convient de bien sélectionner les paramètres permettant à la première entité applicative de déduire le contexte de formulation de la requête en fonction des différents cas d'usage.
[0025] Dans une autre variante de réalisation, on peut envisager que le contexte de formulation renseigné par la deuxième entité applicative dans un champ spécifique de la requête soit affiné par la première entité applicative en exploitant les paramètres véhiculés par la requête définissant l'analyse requise par la deuxième entité applicative. Le contexte de formulation déterminé par la première entité applicative comprend alors le contexte renseigné par la deuxième entité applicative (ex. la procédure dans le cadre de laquelle la requête est formulée et le résultat d'analyse va être exploité) éventuellement complété par d'autres informations issues des paramètres de définition de l'analyse (ex. UE ou un groupe d'UE ou une cellule, etc.).
[0026] Comme évoqué précédemment, conformément à l'invention, le contexte de formulation de la requête est utilisé par la première entité applicative pour sélectionner un modèle d'analyse pertinent pour réaliser l'analyse statistique et/ou prédictive qui lui est demandée.
[0027] La sélection du modèle d'analyse peut s'opérer à différents niveaux. Ainsi, elle peut comprendre par exemple une sélection d'au moins un élément parmi : une technique d'analyse statistique ou prédictive à utiliser pour réaliser l'analyse ; au moins une caractéristique d'un jeu de données à utiliser pour réaliser l'analyse et/ou entraîner une technique d'analyse utilisée pour réaliser l'analyse ; un paramétrage d'une technique d'analyse utilisée pour réaliser l'analyse ; etc.
[0028] L'ajustement de tout ou partie des éléments précités permet à la première entité applicative d'obtenir des résultats d'analyse très pertinents pour la deuxième entité applicative, ce qui permet à cette dernière d'optimiser les procédures qu'elle met en œuvre dans le cadre des fonctions qui lui sont confiées dans le réseau.
[0029] Pour permettre la sélection par la première entité applicative d'un modèle d'analyse adapté au contexte de formulation de la requête, différentes façons de procéder peuvent être envisagées.
[0030] Ainsi, dans un mode particulier de réalisation, le procédé de traitement comprend une étape préliminaire de configuration de la première entité applicative avec une liste de modèles d'analyse dans laquelle chaque modèle d'analyse est associé à au moins un contexte de formulation d'une requête, le modèle d'analyse appliqué lors de l'étape de réalisation étant un modèle d'analyse associé dans cette liste au contexte déterminé lors de l'étape d'obtention.
[0031] Ce mode de réalisation consiste en une pré-configuration de la première entité applicative, par exemple par l'opérateur du réseau, avec une liste de modèles possibles adaptés à différents contextes. Il est relativement simple à mettre en œuvre. Il convient de noter qu'une mise à jour de la liste ainsi préconfigurée peut être effectuée à tout moment via un message de configuration approprié envoyé à la première entité applicative.
[0032] Dans un autre mode de réalisation, le procédé de traitement comprend une étape d'apprentissage au cours de laquelle la première entité applicative : établit des corrélations entre des modèles d'analyse, des contextes de formulation d'une requête, et des indicateurs de qualité des analyses réalisées à partir desdits modèles dans lesdits contextes ; et associe, à partir des corrélations établies, à au moins un contexte de formulation d'une requête un modèle d'analyse optimisant ladite qualité, le modèle d'analyse appliqué lors de l'étape de réalisation étant sélectionné à partir des associations établies lors de l'étape d'apprentissage.
[0033] Ce mode de réalisation a une application privilégiée lorsque la première entité applicative ne dispose pas de pré-configuration pour un contexte de formulation donné, ou de façon générale, ne dispose d'aucune pré-configuration. Dans ce mode de réalisation, c'est la première entité applicative qui optimise, par apprentissage, la sélection d'un modèle d'analyse en fonction du contexte de formulation de la requête d'analyse qui lui est adressée. Ce mode de réalisation est avantageusement évolutif et permet à la première entité applicative de tenir compte de la qualité des résultats d'analyse qu'elle obtient pour optimiser le choix des modèles d'analyse. [0034] Dans un autre mode de réalisation encore, le procédé de traitement comprend :
- une étape préliminaire de configuration de la première entité applicative avec une liste comprenant au moins un modèle d'analyse associé à au moins un contexte de formulation d'une requête ; une étape d'apprentissage au cours de laquelle la première entité applicative : o établit des corrélations entre des modèles d'analyse, des contextes de formulation d'une requête, et des indicateurs de qualité des analyses statistiques réalisées à partir desdits modèles dans lesdits contextes ; et o met à jour et/ou complète ladite liste à partir desdites corrélations établies ; le modèle d'analyse appliqué lors de l'étape de réalisation étant un modèle d'analyse associé au contexte déterminé lors de l'étape d'obtention dans la liste mise à jour ou complétée lors de l'étape d'apprentissage.
[0035] Ce mode de réalisation combine avantageusement les deux précédents, et bénéficie ainsi des avantages associés à chacun d'entre eux.
[0036] Au vu de ce qui précède, l'invention s'appuie sur la première entité applicative qui obtient un contexte de formulation de la requête d'analyse qui lui est adressée et exploite ce contexte pour optimiser les résultats d'analyse qu'elle fournit en réponse à cette requête, mais également, dans un mode particulier de réalisation, sur la deuxième entité applicative à l'origine de la requête et qui fournit à la première entité applicative ledit contexte de formulation.
[0037] Ainsi, selon un autre aspect, l'invention concerne un procédé de communication avec une première entité applicative d'un réseau de communications, ce procédé de communication étant mis en œuvre par une deuxième entité applicative du réseau et comprenant : une étape d'envoi à la première entité applicative d'une requête d'analyse statistique ou prédictive comprenant, dans un champ dédié de la requête, un paramètre indiquant un contexte de formulation de la requête ; et une étape de réception, en réponse à la requête, d'au moins un résultat de l'analyse requise réalisée par la première entité applicative au moyen d'un modèle d'analyse sélectionné en fonction de ce contexte.
[0038] Corrélativement, l'invention vise aussi une entité applicative d'un réseau de communications, dite deuxième entité applicative, comprenant : un module d'envoi, configuré pour envoyer à une première entité applicative du réseau une requête d'analyse statistique ou prédictive comprenant, dans un champ dédié de la requête, un paramètre indiquant un contexte de formulation de la requête ; et un module de réception, configuré pour recevoir en réponse à ladite requête, au moins un résultat de l'analyse requise réalisée par la première entité applicative au moyen d'un modèle d'analyse sélectionné en fonction de ce contexte.
[0039] Selon un autre aspect encore, l'invention concerne également un système dans un réseau de communications comprenant au moins une première entité applicative et au moins une deuxième entité applicative conformes à l'invention.
[0040] Le procédé de communication, la deuxième entité applicative et le système selon l'invention bénéficient des mêmes avantages cités précédemment que le procédé de traitement et la première entité applicative.
[0041] Dans un mode particulier de réalisation, les procédés de traitement et de communication sont mis en œuvre par un ordinateur.
[0042] L'invention vise également un programme d'ordinateur sur un support d'enregistrement, ce programme étant susceptible d'être mis en œuvre dans un ordinateur ou plus généralement dans une première entité applicative conforme à l'invention et comportant des instructions adaptées à la mise en œuvre d'un procédé de traitement tel que décrit ci-dessus. [0043] L'invention vise également un programme d'ordinateur sur un support d'enregistrement, ce programme étant susceptible d'être mis en œuvre dans un ordinateur ou plus généralement dans une deuxième entité applicative conforme à l'invention et comportant des instructions adaptées à la mise en œuvre d'un procédé de communication tel que décrit ci-dessus.
[0044] Chacun de ces programmes 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.
[0045] L'invention vise aussi un support d’information ou un support d'enregistrement lisibles par un ordinateur, et comportant des instructions d'un programme d’ordinateur tel que mentionné ci-dessus.
[0046] 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.
[0047] 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.
[0048] Le programme selon l’invention peut être en particulier téléchargé sur un réseau de type Internet.
[0049] Alternativement, le support d’information 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 des procédés de gestion, d'enregistrement et de communication selon l'invention.
[0050] On peut également envisager, dans d’autres modes de réalisation, que les procédés de traitement et de communication, les première et deuxième entités applicatives 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
[0051] 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 représente, dans son environnement, un système dans un réseau conforme à l'invention, dans un mode particulier de réalisation ;
[Fig. 2] la figure 2 représente schématiquement l'architecture matérielle d'un ordinateur pouvant héberger l'une quelconque des entités selon l'invention appartenant au système de la figure 1 ;
[Fig. 3] la figure 3 représente les modules fonctionnels des entités applicatives conformes à l'invention du système de la figure 1 ;
[Fig. 4] la figure 4 représente les principales étapes d'un procédé de traitement selon l'invention telles qu'elles sont mises en œuvre par une première entité applicative du système de la figure 1 ;
[Fig. 5] la figure 5 représente les principales étapes d'un procédé de communication selon l'invention telles qu'elles sont mises en œuvre par une deuxième entité applicative du système de la figure 1.
Description de l'invention
[0052] La figure 1 représente, dans son environnement, un système 1 dans un réseau de communications CN, conforme à l'invention, dans un mode particulier de réalisation.
[0053] Dans l'exemple envisagé à la figure 1, le réseau CN est un réseau cœur 5GC d'un réseau NW de communications 5G tel que défini par le standard 3GPP, s'appuyant sur une pluralité d'entités applicatives hébergeant des fonctions réseau (ou fonctions NF) implémentant diverses fonctionnalités ou services dans le réseau cœur, comme l'accès au réseau, la mobilité des utilisateurs ou encore la gestion des sessions établies dans le réseau, le stockage et la publication des profils des fonctions réseau, etc. [0054] Comme évoqué précédemment, afin d'optimiser les procédures au sein du réseau cœur CN, les fonctions NF peuvent faire appel à une fonction NF spécifique chargée de collecter et d'analyser des données du réseau, appelée fonction NWDAF (pour « NetWork Data Analytics Function » en anglais). Cette fonction NWDAF propose aux fonctions NF du réseau qui la sollicitent, des analyses statistiques et/ou prédictives sur le comportement du réseau CN, ou plus généralement du réseau NW, en termes notamment de qualité de service, et/ou sur le comportement des UE du réseau NW. Ces analyses peuvent être globales (ex. établies au niveau du réseau, d'un serveur, d'une application ou encore d'une région), ou être individuelles (i.e. porter sur un UE ou sur un groupe d'UE particulier). Elles sont réalisées à partir de données brutes collectées par la fonction NWDAF et de modèles d'analyse statistique et/ou prédictive appliqués à ces données brutes.
[0055] Conformément à l'invention, le système 1 comprend : au moins une première entité applicative 2, conforme à l'invention. Dans le mode de réalisation décrit ici, l'entité applicative 2 héberge une fonction réseau NWDAF de collecte et d'analyse de données du réseau NW telle que décrite ci-avant, et est désignée dans la suite de la description par entité NWDAF 2 ; et au moins une deuxième entité applicative 3, conforme à l'invention, configurée pour consommer les services offerts par l'entité NWDAF 2, autrement dit, solliciter l'entité NWDAF 2 pour obtenir des analyses statistiques et/ou prédictives sur le comportement du réseau et/ou d'un UE ou d'un groupe d'UE. Dans le mode de réalisation décrit ici, la ou les entités applicatives 3 hébergent également des fonctions NF du réseau cœur CN. Aucune limitation n'est attachée aux fonctions NF hébergées par les entités applicatives 3. Ainsi, dans l'exemple représenté sur la figure 1, le système 1 comprend une pluralité d'entités applicatives 3 conformes à l'invention, parmi lesquelles notamment une entité applicative 3-1 hébergeant une fonction AMF d'accès au réseau (aussi désignée ci-après par entité AMF 3-1), une entité applicative 3-2 hébergeant une fonction SMF de gestion de sessions (ou entité SMF 3-2), une entité applicative 3-3 hébergeant une fonction PCF de contrôle de politique (ou entité PCF 3-3), et une entité applicative 3-4 hébergeant une fonction AF d'application (ou entité AF 3-4). Cette liste n'est pas limitative et n'est donnée qu'à titre illustratif.
[0056] Chaque entité applicative du système 1 est un dispositif communicant, matériel ou virtuel (i.e. logiciel), configuré pour mettre en œuvre une logique de traitement déterminée, correspondant à la fonction réseau qu'elle héberge. Ainsi l'invention s'applique indifféremment à des entités applicatives logicielles ou virtuelles et à des entités applicatives matérielles hébergeant des fonctions réseau.
[0057] Lorsque les entités applicatives considérées sont des dispositifs matériels (par exemple des serveurs d'une infrastructure du réseau cœur CN), elles ont alors l'architecture matérielle d'un ordinateur 4, tel qu'illustrée à la figure 2. Cette architecture matérielle s'appuie sur un processeur PROC, une mémoire vive MEM, une mémoire morte ROM, une mémoire non volatile NVM, et des moyens COM de communications avec d'autres entités, par exemple, d'autres entités applicatives du réseau cœur CN, des entités d'un réseau d'accès au réseau cœur CN comme par exemple une entité OAM de gestion du réseau NW (non représentée sur la figure 1), ou encore avec des UE du réseau NW. Ces moyens COM de communication peuvent notamment s'appuyer sur une interface de communication filaire ou sans fil, connue en soi et non décrite plus en détail ici, mais également sur une ou plusieurs interfaces logicielles telles qu'une interface de programmation applicative (ou API pour « Application Programming Interface » en anglais) ou une interface de communication point-à-point.
[0058] Lorsque les entités applicatives considérées sont logicielles, elles sont elles-mêmes hébergés par un dispositif matériel ayant l'architecture matérielle de l'ordinateur 4, et peuvent alors s'appuyer sur les moyens matériels de l'ordinateur 4 évoqués ci-avant (PROC, MEM, ROM, NVM, COM). Dans la suite de la description, par souci de simplification, on fait indifféremment référence aux moyens PROC, MEM, ROM, NVM, COM de l'entité applicative considérée, que celle-ci soit matérielle ou logicielle. [0059] La mémoire non volatile NVM de l'ordinateur 4 constitue un support d'enregistrement conforme à l'invention, lisible par le processeur PROC et sur lequel est enregistré un programme d'ordinateur conforme à l'invention. Dans le cas d'une entité applicative 2, ce programme d'ordinateur est référencé par PROG2 et comporte des instructions définissant les principales étapes d'un procédé de traitement selon l'invention. Pour une entité applicative 3, le programme d'ordinateur en question est référencé par PROG3 et comporte des instructions définissant les principales étapes d'un procédé de communication selon l'invention.
[0060] Le programme PROG2 définit les modules fonctionnels d'une entité applicative 2 et notamment de l'entité NWDAF 2 du système 1, qui s'appuient ou commandent les éléments PROC, MEM, ROM, NVM, et COM de l'ordinateur 4, cités précédemment. Ces modules fonctionnels comprennent notamment, dans le mode de réalisation décrit ici, comme illustré sur la figure 3 : un module 2A de réception configuré pour recevoir d'une entité applicative 3 du système 1 une requête REQ d'analyse statistique ou prédictive ; un module 2B de détermination, configuré pour obtenir à partir d'au moins une information véhiculée par cette requête REQ, un contexte CTX de formulation de la requête par l'entité applicative 3. Un tel contexte CTX de formulation est représentatif typiquement du cas d'usage de l'analyse statistique ou prédictive requise, il identifie par exemple une procédure que l'entité applicative 3 va exécuter en utilisant le résultat de l'analyse statistique ou prédictive demandée ; un module 2C de traitement, configuré pour réaliser l'analyse requise au moyen d'un modèle d'analyse sélectionné en fonction du contexte CTX déterminé par le module 2B de détermination ; et un module 2D de fourniture, configuré pour fournir au moins un résultat de l'analyse réalisée par le module 2C de traitement en réponse à la requête REQ de l'entité applicative 3.
[0061] La configuration et le fonctionnement des modules 2A à 2D de l'entité applicative 2 et plus particulièrement de l'entité NWDAF 2 sont décrits plus en détail ultérieurement en référence aux étapes du procédé de traitement selon l'invention.
[0062] De façon similaire, le programme PROG3 définit les modules fonctionnels d'une entité applicative 3, et plus particulièrement de chacune des entités AMF 3-1, SMF 3-2, PCF 3-3 et AF 3-4 du système 1, ces modules fonctionnels s'appuyant ou commandant les éléments PROC, MEM, ROM, NVM, et COM de l'ordinateur 4, cités précédemment. Dans le mode de réalisation décrit ici, les modules fonctionnels d'une entité applicative 3 conforme à l'invention comprennent notamment, comme illustré sur la figure 3 : un module 3A d'envoi, configuré pour envoyer à l'entité applicative 2, et plus particulièrement ici à l'entité NWDAF 2, une requête REQ d'analyse statistique ou prédictive. Dans le mode de réalisation décrit ici, le module 3A d'envoi est configuré pour utiliser, pour envoyer la requête REQ, une API de l'entité NWDAF 2, comme détaillé davantage ultérieurement. Il est en outre configuré pour insérer dans la requête REQ, dans un champ dédié de la requête nommé à titre illustratif UseCaseContext, un paramètre indiquant le contexte CTX de formulation de la requête, autrement dit le contexte d'usage du ou des résultats de l'analyse requise ; un module 3B de réception, configuré pour recevoir en réponse à la requête REQ adressée à l'entité NWDAF 2, au moins un résultat de l'analyse requise réalisée par l'entité NWDAF 2 au moyen d'un modèle d'analyse sélectionné par celle-ci en fonction du contexte CTX ; et un module 3C d'exécution, configuré pour exécuter une procédure associée à la fonction réseau hébergée par l'entité applicative 3 en utilisant un résultat d'analyse reçu par le module 3B de réception. La procédure exécutée dépend bien entendu de la fonction réseau hébergée par l'entité applicative 3. Il peut s'agir par exemple d'une procédure d'enregistrement ou de détermination d'une zone d'enregistrement pour l'entité AMF 3-1, d'une procédure d'ouverture de session ou de sélection d'une fonction UPF du plan utilisateur du réseau cœur CN pour l'entité SMF 3-2, d'une procédure de modification d'une politique ou de détermination d'un débit moyen pour une tranche réseau donnée pour une entité PCF 3-3, d'une procédure d'optimisation d'un réglage pour un UE ou de détection d'une fraude pour une entité AF 3-4, etc.
[0063] La configuration et le fonctionnement des modules 3A à 3C des entités applicatives 3 sont décrits plus en détail ultérieurement en référence aux étapes du procédé de communication selon l'invention.
[0064] Nous allons maintenant décrire, en référence aux figures 4 et 5 respectivement, les principales étapes d'un procédé de traitement et d'un procédé de communication selon l'invention, telles que mises en œuvre dans un mode particulier de réalisation par l'entité NWDAF 2 et par l'une des entités applicatives 3 du système 1. On considère plus particulièrement ici, à titre illustratif, l'entité AMF 3- 1 ; toutefois, les étapes du procédé de communication sont mises en œuvre de façon similaire ou identique par toute autre entité applicative 3 du système 1.
[0065] On suppose donc ici que l'entité AMF 3-1 a besoin, pour exécuter l'une des procédures PROC dont elle a la charge dans le réseau cœur CN, d'analyses statistiques et/ou prédictives. Plus particulièrement, dans l'exemple illustratif envisagé ici, on suppose que l'entité AMF 3-1 a besoin d'une prédiction de la mobilité d'un UE donné, par exemple de l'UE 5 représenté sur la figure 1, et ce en vue de déterminer une zone d'enregistrement pour cet UE 5 (procédure PROC = détermination de la zone d'enregistrement de l'UE 5).
[0066] Bien entendu, ces hypothèses ne sont pas limitatives en soi et uniquement formulées à titre illustratif. D'autres procédures peuvent être mises en œuvre par l'entité AMF 3-1 dans le cadre de la fonction réseau implémentée par cette entité, et nécessiter ou s'appuyer sur des analyses statistiques et/ou prédictives de l'entité NWDAF 2, qui peuvent porter par ailleurs sur d'autres types d'analyses qu'une prédiction de mobilité d'un UE, comme par exemple, une prédiction concernant la nature des communications d'un UE, etc.). Ainsi, le document 3GPP TR 23.791 évoqué précédemment évoque différents cas d'usage d'analyses statistiques et/ou prédictives réalisées par une fonction réseau NWDAF dans un réseau 5G.
[0067] En référence à la figure 5, l'entité AMF 3-1, par le biais de son module 3A d'envoi, envoie une requête REQ à l'entité NWDAF 2, et plus particulièrement à son module 2A de réception, demandant une prédiction de la mobilité de l'UE 5 (étape E10).
[0068] Dans le mode de réalisation décrit ici, le module 3A d'envoi de l'entité AMF 3-1 utilise à cet effet le service Nnwdaf_AnalyticsInfo de l'API de l'entité NWDAF 2, décrit dans les documents 3GPP TS 23.288 intitulé « Architecture Enhancements for 5G system (5GS) to support network data analytics services (Release 17) », V17.4.0, mars 2022, et TS 28.520 intitulé « Technical Specification Group Core Network and Terminals; 5G System; Network Data Analytics Services; Stage 3; (Release 17) », V17.6.0, mars 2022. La requête REQ est ici une requête simple de type Nnwdaf_AnaiyticsInfo Request. En variante, elle peut prendre la forme d'une souscription (service Nnwdaf_AnalyticsSubscription et souscription Nnwdaf_AnaiyticsSubscription Subscribe), comme décrit dans les documents 3GPP TS 23.288 et TS 29.520. Il convient d'ailleurs de noter que l'envoi de la requête REQ par le module 3A d'envoi, bien qu'étant lié à une procédure mise en œuvre par l'entité AMF 3-1 (et plus particulièrement exécutée ou destinée à être exécutée par son module 3C d'exécution), n'est pas nécessairement réalisé de façon synchrone avec cette procédure. Il peut être réalisé de façon asynchrone, typiquement en amont de la procédure en question, de façon anticipée, pour pouvoir disposer du résultat de l'analyse pour exécuter sans délai la procédure concernée.
[0069] Comme défini par le standard 3GPP, le module 3A d'envoi de l'entité AMF 3-1 fournit dans la requête REQ divers paramètres P-DEF définissant l'analyse statistique et/ou prédictive demandée, et notamment : l'identité de l'entité applicative à l'origine de la requête, c'est-à-dire ici l'identité de l'entité AMF 3-1 ; un ou plusieurs paramètres représentatifs du type d'analyse demandé. Ce ou ces paramètres peuvent notamment définir la nature de l'analyse ou de façon équivalente le type de résultat attendu (ex. prédiction de mobilité ici), la quantité de résultats attendue, etc. ; la cible de l'analyse, c'est-à-dire le ou les équipements sur le(s)quel(s) porte l'analyse (ex. l'UE 5 ici) ; un ou plusieurs paramètres représentatifs de conditions de réalisation de l'analyse, par exemple la période de temps visée, la zone géographique visée, la tranche de réseau concernée, etc. ; un niveau de précision attendu pour l'analyse ; un ou plusieurs paramètres représentatifs des modalités de notification du réseau d'analyse (ex. périodicité, souscription, etc.).
[0070] Bien entendu, cette liste n'est pas exhaustive, et l'homme du métier est invité à se référer aux documents 3GPP TS 23.288 et TS 29.520 précités pour obtenir la liste des paramètres P-DEF obligatoires, et le cas échéant optionnels, qui doivent ou peuvent être inclus par le module 3A d'envoi dans la requête REQ adressée à l'entité NWDAF 2.
[0071] Conformément à l'invention, le module 3A d'envoi de l'entité AMF 3-1 insère en outre dans la requête REQ, dans un champ dédié et plus particulièrement dans le champ UseCaseContext introduit précédemment, un paramètre P-CTX indiquant le contexte CTX dans lequel est formulée la requête REQ, c'est-à-dire le contexte d'usage du ou des résultats de l'analyse demandée dans la requête REQ. Le paramètre P-CTX identifie ici la procédure PROC que s'apprête à exécuter l'entité AMF 3-1 en utilisant le résultat de la prédiction demandée dans la requête REQ. Ainsi, dans l'exemple illustratif envisagé, le paramètre P-CTX contenu dans le champ UseCaseContext de la requête REQ identifie comme procédure, la détermination de la zone d'enregistrement de l'UE 5.
[0072] Ainsi, dans le mode de réalisation décrit ici, un nouveau champ UseCaseContent est ajouté dans les messages échangés en utilisant les services Nnwdaf_AnalyticsInfo et Nnwdaf_AnalyticsSubscription. [0073] Aucune limitation n'est attachée au format du paramètre P-CTX. Il peut s'agit d'un entier désignant de façon univoque le contexte CTX, d'une chaîne de caractères définissant ce contexte CTX, ou encore d'une liste d'entiers ou de chaînes de caractères, etc. En outre, on peut envisager que le paramètre en question prenne une valeur prédéfinie parmi un ensemble de valeurs prédéfinies, chacune associée de façon univoque à un contexte particulier (ex. 1 = « enregistrement d'un UE par une fonction AMF », 2 = « détermination d'une zone d'enregistrement d'un UE par une fonction AMF », etc.), ou a contrario, qu'il prenne une valeur quelconque dès lors que l'entité NWDAF 2 est capable d'associer cette valeur à un contexte particulier (il ne doit pas y avoir d'ambiguïté pour l'entité NWDAF 2 pour identifier à partir de la valeur en question quel contexte est désigné, autrement dit une même valeur ne doit pas identifier des contextes de formulation différents).
[0074] L'Annexe 1 fournit, à titre illustratif, une liste non exhaustive établie par les inventeurs, de contextes et d'analyses prédictives ou statistiques associées susceptibles d'être demandées à une fonction NWDAF dans un réseau 5G, et donc incidemment dans le réseau CN. Dans les exemples donnés en Annexe 1, un même contexte CTX peut être associé à des analyses statistiques/prédictives différentes : par exemple, le contexte « Modification par une PCF de politiques RFSP » peut s'appuyer sur des analyses portant sur la charge de tranches du réseau ou sur des analyses portant sur les communications UE et l'expérience de service observée (ou OSE pour « Observed Service Experience » en anglais). Les requêtes correspondantes adressées dans cet exemple par l'entité PCF à l'entité NWDAF comprennent le même paramètre P-CTX désignant le contexte « Modification par une PCF de politiques RFSP », tandis que les paramètres P-DEF fournis dans les requêtes désignent pour l'une des requêtes, une analyse statistique/prédictive portant sur la charge des tranches du réseau, et pour l'autre, des analyses statistiques/prédictives portant sur les communications UE et sur l'OSE.
[0075] En revanche, il est possible d'associer un contexte différent à la même opération de modification par une PCF de politiques RFSP dès lors qu'elle est réalisée dans un but spécifique, par exemple pour préserver la qualité d'un service de communication véhiculaire dit V2X (pour « Vehicule-to-every- thing » en anglais). Il convient d'ailleurs de noter que le X dans V2X peut désigner toute sorte d'entités, comme par exemple un autre véhicule, un drone, une infrastructure, un piéton, etc., de sorte qu'un contexte différent peut être associé à chaque X différent envisagé pour le service V2X, le type d'entité X considérée pouvant influer sur le choix du modèle d'analyse.
[0076] Dans une variante de réalisation, on peut envisager d'inclure dans l'information de contexte les analyses statistiques/prédictives sur lesquelles s'appuie le cas échéant l'opération désignée par le contexte ou plus généralement le cas d'usage de ces analyses. Ainsi, à titre illustratif, dans l'exemple évoqué ci-avant, on peut envisager un premier contexte « Modification par une PCF de politiques RFSP sur la base d'analyse statistique/prédictive de la charge de tranches du réseau » et un deuxième contexte « Modification par une PCF de politiques RFSP sur la base d'analyses statistiques/prédictives de communications UE et d'OSE ». Il convient de noter que cette précision apportée dans le contexte n'implique pas nécessairement un changement du contenu des paramètres P-DEF fournis dans la requête. En effet, dans un souci de limiter l'impact de l'invention sur les messages existants déjà définis par le standard 3GPP (autrement dit de limiter les modifications à apporter à ces messages), on peut envisager de préciser à la fois dans le contexte et dans les paramètres P-DEF, les analyses statistiques/prédictives sur lesquelles s'appuient l'opération mise en œuvre par l'entité applicative à l'origine de la requête et qui sont requises auprès de l'entité NWDAF.
[0077] On note que la détermination par le module 3A d'envoi de l'entité AMF 3-1 du contexte CTX de formulation de la requête REQ ne pose aucune difficulté en soi puisque celui-ci reflète la procédure PROC en cours d'exécution par l'entité AMF 3-1 (et plus particulièrement par son module 3C de traitement) ou une procédure PROC que cette entité AMF 3-1 s'apprête à exécuter (la requête REQ n'étant pas nécessairement envoyée de façon synchrone par rapport à l'exécution de la procédure en question).
[0078] En référence à la figure 4, sur réception de la requête REQ par son module 2A de réception (étape F10), l'entité NWDAF 2, par l'intermédiaire de son module 2C de traitement, détermine à partir des paramètres P-DEF fournis dans la requête REQ, l'analyse statistique et/ou prédictive qui lui est demandée par l'entité AMF 3-1 (étape F20), à savoir dans l'exemple illustratif envisagé ici, une prédiction de la mobilité de l'UE 5 dans les conditions établies par les paramètres P-DEF.
[0079] L'entité NWDAF 2, par l'intermédiaire de son module 2B de détermination, détermine également, à partir d'au moins une information véhiculée par la requête REQ, le contexte CTX dans lequel la requête REQ a été formulée (étape F30). Ce contexte CTX de formulation de la requête REQ donne à l'entité NWDAF 2 une indication sur la façon dont va être utilisée la prédiction demandée par l'entité AMF 3-1.
[0080] A cet effet, dans le mode de réalisation décrit ici, le module 2B de détermination extrait le paramètre P-CTX contenu dans le champ UseCaseContext de la requête REQ qui identifie la procédure PROC sollicitant l'analyse statistique ou prédictive demandée dans la requête REQ.
[0081] Il convient de noter que dans le mode de réalisation décrit ici, la requête REQ comprend le champ UseCaseContext, et ce champ est alimenté par l'entité AMF 3-1 avec le paramètre P-CTX identifiant le contexte dans lequel est formulée la requête REQ. Ainsi, le module 2B de détermination détermine le contexte CTX à partir du contenu du paramètre P-CTX inclus dans le champ UseCaseContext de la requête REQ. On peut envisager en variante que le champ UseCaseContext soit optionnel, et qu'en l'absence d'un tel champ dans la requête, le module 2B de détermination soit configuré pour déterminer le contexte CTX de formulation de la requête REQ à partir des informations véhiculées par cette dernière, et notamment à partir de tout ou partie des paramètres P-DEF évoqués précédemment, à savoir les paramètres P-DEF fournis par l'entité AMF 3-1 dans la requête REQ représentatifs de son identité, du type d'analyse demandé, de la cible de cette analyse (ex. un UE ou un groupe d'UE, une cellule, etc.), des conditions de réalisation de cette analyse, du niveau de précision attendu, des modalités de notification des résultats de l'analyse, etc. A cet effet, le module 2B de détermination peut s'appuyer sur une technique d'intelligence artificielle (ou IA) supervisée ou non, ou être configuré avec des règles préétablies, définies par exemple par l'opérateur du réseau cœur CN, établissant une correspondance entre les valeurs de tout ou partie des paramètres P-DEF précités véhiculés par la requête REQ et différents contextes de formulation de cette requête REQ.
[0082] Dans une autre variante encore, on peut envisager un mode hybride dans lequel le module 2B de détermination détermine le contexte à partir du contenu du paramètre P-CTX compris dans le champ UseCaseContext et des autres informations véhiculées par la requête REQ, typiquement les paramètres P-DEF. Ce mode hybride permet d'obtenir un contexte plus précis (et une granularité plus fine dans le choix du modèle d'analyse).
[0083] Par exemple, certains groupes de paramètres P-DEF fournis dans la requête REQ et les valeurs associées à ces groupes de paramètres peuvent être utilisés pour définir des signatures représentatives de contextes distincts.
[0084] On peut alors envisager, selon une variante de réalisation, que l'entité NWDAF 2, et plus particulièrement son module 2B de détermination, soit configurée avec un certain nombre de signatures auxquelles sont associées des contextes, et que sur réception de la requête REQ, le module 2B de détermination détermine à partir des paramètres P-DEF fournis dans la requête REQ, s'ils correspondent à l'une des signatures avec lesquelles il a été configuré. Le cas échéant, le contexte de formulation de la requête déterminé par le module 2B de détermination est celui qui est associée à la signature.
[0085] La configuration de l'entité NWDAF 2 peut être réalisée notamment par l'opérateur du réseau CN au moyen de signatures déterminées par celui-ci, par exemple lors d'une phase de configuration telle que classiquement mise en œuvre lors de l'introduction de nouveaux équipements ou services dans un réseau.
[0086] Selon une autre variante de réalisation, le module 2B de détermination de l'entité NWDAF 2 peut mettre en œuvre une phase d'apprentissage au cours de laquelle il analyse les paramètres P-DEF présents dans un ensemble de requêtes REQ précédemment reçues par l'entité NWDAF 2, et détermine, par exemple au moyen d'un algorithme de classification, quels groupes de paramètres et valeurs associées sont significatifs et représentatifs d'un contexte particulier. Les différents groupes de paramètres et valeurs associées ainsi obtenus définissent un ensemble de signatures correspondant à des contextes de formulation distincts.
[0087] Il convient de noter que dans cette variante de réalisation, le module 2B de détermination est en mesure de faire le distinguo entre des contextes de formulation distincts, et d'associer un contexte de formulation donné à une requête ; toutefois, il ne dispose pas nécessairement des informations nécessaires pour associer à ce contexte de formulation, une opération spécifique exécutée ou destinée à être exécutée par l'entité applicative à l'origine de la requête REQ (ex. détermination d'une zone d'enregistrement). A titre illustratif, supposons que les paramètres P-DEF comprennent trois paramètres X, Y, Z, et que le module 2B de détermination détermine pendant la phase d'apprentissage que :
- si X=0 et Y=l, quelle que soit la valeur du paramètre Z, on est toujours dans un contexte auquel le module 2B de détermination associe une étiquette CTX1 ; et
- si X=1 et Y=l, quelle que soit la valeur du paramètre Z, on est toujours dans un autre contexte auquel le module 2B de détermination attribue l'étiquette CTX2.
Sur réception d'une nouvelle requête REQ, le module 2B de détermination est capable à partir de ces signatures, de déterminer si le contexte de formulation de la nouvelle requête REQ est le contexte CTX1 ou le contexte CTX2, mais en l'absence d'informations supplémentaires, il n'est pas capable d'identifier la procédure associée au contexte ainsi déterminé, c'est-à-dire par exemple, que CTX1 identifie une procédure de détermination d'une zone d'enregistrement et CTX2 identifie une procédure d'optimisation d'un paging.
[0088] Pour remédier à cela, dans une autre variante encore, on peut envisager que le module 2B de détermination soit configuré, par exemple par l'opérateur du réseau CN, avec des règles de mise en correspondance des étiquettes déterminées lors de la phase d'apprentissage par le module 2B de détermination et des procédures susceptibles d'être mises en œuvre par les entités applicatives correspondant à ces étiquettes. Autrement dit, dans l'exemple illustratif envisagé ci-avant, le module 2B de détermination est configuré avec les associations suivantes :
CTX1 = Détermination d'une zone d'enregistrement d'un UE
CTX2 = Optimisation d'un paging
[0089] Quelle que soit la variante retenue, il convient de noter que le groupe de signatures sur lesquelles s'appuie le module 2B de détermination peut être amené à évoluer dans le temps ; notamment, il peut être complété avec de nouvelles signatures, ou celles-ci peuvent être modifiées lorsque de nouvelles phases d'apprentissage sont réalisées.
[0090] Conformément à l'invention, l'entité NWDAF 2 exploite (i.e. utilise) le contexte CTX de formulation de la requête REQ pour sélectionner un modèle d'analyse pertinent pour réaliser l'analyse demandée par l'entité AMF 3-1, et plus particulièrement ici, une prédiction de la mobilité de l'UE 5 (étape F40).
[0091] En effet, de façon connue en soi, pour réaliser les analyses statistiques et/ou prédictives qui lui sont demandées, une fonction réseau NWDAF (et a fortiori l'entité NWDAF 2 et son module 2C de traitement) a à sa disposition une pluralité de techniques d'analyse qu'elle peut utiliser en fonction de la nature des analyses qui lui sont demandées. Par exemple, pour une analyse statistique portant sur des comportements passés, des modèles classiquement utilisés par une fonction réseau NWDAF sont notamment : un modèle réalisant une moyenne mobile sur tout ou partie des données collectées par la fonction réseau NWDAF ; un modèle réalisant une moyenne exponentielle mobile sur tout ou partie des données collectées par la fonction réseau NWDAF ; etc.
Pour une analyse prédictive portant sur des comportements à venir, les modèles de prédiction classiquement utilisés par une fonction réseau NWDAF s'appuient notamment sur des techniques de modélisation de séries temporelles utilisant des techniques d'apprentissage automatique (ou « Machine Learning » en anglais), supervisé ou non supervisé, pouvant exploiter des algorithmes très variés, tels que des chaînes de Markov, des réseaux de neurones (ex. réseaux de neurones de type LSTM pour « Long Short Term Memory » en anglais), un lissage exponentiel (ou « exponential smoothing » en anglais), des modèles de type ARCH (pour « AutoRegressive Conditional Heteroske- dasticity » en anglais), ou de type ARMA ou ARIMA qui combinent processus autorégressif (AR pour « AutoRegressive » en anglais), moyenne mobile (MA pour « Moving Average » en anglais) et éventuellement intégration (I pour « Integrated » en anglais), etc.
[0092] En outre, chacune des techniques d'analyse précitées peut être paramétrée de façon différente, ou s'appuyer sur des jeux de données ayant des caractéristiques distinctes (outre la nature des données collectées, telles que la quantité de données, etc.) pour l'analyse ou pour l'entraînement de ladite technique d'analyse, ce qui conduit à autant de modèles distincts pouvant être sélectionnés par le l'entité NWDAF 2. Le contexte CTX fournit à cette dernière un guide qui lui permet de faire une sélection éclairée et pertinente du modèle d'analyse à appliquer pour répondre à la requête de l'entité AMF 3-1, et plus particulièrement d'au moins un élément parmi : une technique d'analyse statistique ou prédictive à utiliser pour réaliser l'analyse parmi une pluralité de techniques prédéfinies, comme par exemple, un modèle ARIMA, un modèle ARCH, un lissage exponentiel, une moyenne mobile, etc. La sélection peut être opérée par exemple parmi différentes familles de modèles connus tels que ceux précités ou des combinaisons de tels modèles ; et/ou au moins une caractéristique (ex. une quantité de données) d'un jeu de données à utiliser pour réaliser l'analyse et/ou entraîner une technique d'analyse utilisée pour réaliser l'analyse ; et/ou un paramétrage (ex. dans un réseau de neurones, nombre de couches, de neurones par couches, poids synaptiques, etc.) d'une technique d'analyse utilisée pour réaliser l'analyse. Il convient de noter qu'un tel paramétrage ne se limite pas à la prise en compte des paramètres d'entrée fournis par l'entité AMF 3-1 à l'origine de la requête REQ.
[0093] Dans le mode de réalisation décrit ici, la sélection d'un modèle d'analyse par le module 2C de traitement en fonction du contexte CTX déterminé par le module 2B de détermination est permise via une (pré)configuration préalable de l'entité NWDAF 2. Plus spécifiquement, on suppose que lors d'une étape préliminaire de configuration (étape F00), l'entité NWDAF 2 a été configurée, par exemple par l'opérateur du réseau NW via une interface appropriée ou l'utilisation d'un protocole de configuration approprié, avec une liste LIST de modèles d'analyse statistique et prédictive, dans laquelle chaque modèle d'analyse est associé à au moins un contexte de formulation d'une requête. Cette liste LIST est mémorisée par exemple dans la mémoire non volatile NVM de l'entité NWDAF 2. Il convient de noter qu'un contexte de formulation peut être associé à plusieurs modèles d'analyse ou à une famille de modèles d'analyse.
[0094] A titre illustratif, pour les contextes de définition d'une zone d'enregistrement d'un UE et d'optimisation du paging évoqués précédemment, on peut envisager dans la liste LIST les associations suivantes :
Tableau 1]
Figure imgf000017_0001
[0095] Bien entendu, cet exemple n'est donné qu'à titre illustratif et n'est pas limitatif de l'invention, d'autres contextes, modèles d'analyse et associations pouvant être envisagés en variante ou en complément. [0096] Ainsi, lors de l'étape de sélection F40, le module 2C de traitement de l'entité NWDAF 2 consulte la liste LIST préconfigurée lors de l'étape F00, et sélectionne un modèle d'analyse MOD(CTX) dans la liste LIST, associé au contexte CTX. Si plusieurs modèles d'analyse sont possibles, le module 2C de traitement en choisit un, par exemple en tenant compte de critères comme le temps de calcul ou la puissance de calcul nécessaire au regard de tout ou partie des paramètres P-DEF fournis dans la requête REQ (par exemple, du niveau de précision et/ou du délai de fourniture des résultats d'analyse).
[0097] Il convient de noter que la liste LIST stockée dans la mémoire non volatile NVM de l'entité NWDAF 2 n'est pas nécessairement figée, et peut être amenée à évoluer au cours du temps (étape F00').
[0098] Ainsi, la liste LIST peut être mise à jour et/ou complétée pour refléter cette évolution de façon similaire ou identique à ce qui a été décrit précédemment pour l'étape F00.
[0099] En variante, elle peut être mise à jour par l'entité NWDAF 2 elle-même, par exemple par son module 2C de traitement, lors d'une phase d'apprentissage ou d'entraînement, au cours de laquelle le module 2C de traitement peut être amené à réviser les associations comprises dans la liste LIST entre modèles d'analyse et contextes de formulations, et/ou créer de nouvelles associations portant sur de nouveaux modèles d'analyse et/ou de nouveaux contextes de formulation. Ces nouveaux modèles d'analyse et/ou contextes de formulation peuvent être communiqués à l'entité NWDAF 2 par l'opérateur du réseau ou par un autre acteur, par exemple le concepteur de l'entité NWDAF 2, ou être déterminés également par apprentissage. Cette phase d'apprentissage peut s'appuyer comme données d'apprentissage sur les analyses précédemment réalisées par le module 2C de traitement. Elle peut également ou en variante exploiter des données d'apprentissage fournies par un tiers, comme par exemple par l'opérateur du réseau, par le concepteur de l'entité NWDAF 2, etc.
[0100] Plus particulièrement, pour tout ou partie des analyses réalisées par le module 2C de traitement, celui-ci peut évaluer la qualité des résultats obtenus à l'aide d'indicateurs de qualité déterminés. A cet effet, le module 2C de traitement peut par exemple, suite à l'obtention d'un résultat d'analyse tel qu'une prédiction, continuer à collecter des données et vérifier que la prédiction obtenue est correcte, ou réévaluer à partir de ces nouvelles données une nouvelle prédiction et comparer la prédiction réévaluée avec la prédiction initiale. Bien entendu, d'autres techniques peuvent être envisagées pour évaluer la qualité des résultats obtenus par le module 2C de traitement.
[0101] Lors de la phase d'apprentissage, le module 2C de traitement corréle les modèles d'analyse statistique dont il dispose, les différentes valeurs possibles de contextes de formulation, et les indicateurs de qualité des analyses réalisées à partir de ces modèles d'analyse pour ces contextes de formulation. Puis il sélectionne, pour un contexte de formulation donné, le ou les modèles d'analyse conduisant aux meilleurs indicateurs de qualité. Il met alors à jour la liste LIST avec les (nouvelles) associations contexte - modèle(s) d'analyse ainsi obtenues le cas échéant (autrement dit, il met à jour/corrige certaines associations de la liste LIST et/ou complète la liste LIST avec de nouvelles associations obtenues lors de la phase d'apprentissage). Il convient de noter que le module 2C de traitement peut exécuter plusieurs phases d'apprentissage à différents instants en fonction des données d'apprentissage dont il dispose ; ainsi notamment, il peut lors d'une phase d'apprentissage, cibler les données d'apprentissage qu'il utilise en ne retenant que les données d'apprentissage associées à un contexte de formulation particulier, pour déterminer le(s) modèle(s) d'analyse le(s) plus pertinent(s) pour ce contexte, et faire évoluer ce contexte de formulation d'une phase d'apprentissage à une autre.
[0102] Dans un autre mode de réalisation, aucune préconfiguration de l'entité NWDAF 2 n'est mise en œuvre, et c'est l'entité NWDAF 2 via son module 2C de traitement qui établit elle-même la liste LIST et la met à jour au fil du temps au cours d'au moins une phase d'apprentissage (ou d'entraînement) identique ou similaire à ce qui vient d'être décrit. Cette phrase d'apprentissage peut être supervisée ou non (c'est-à-dire s'appuyer sur des données d'apprentissage fournies par l'opérateur du réseau et/ou le concepteur de l'entité NWDAF 2 ou uniquement sur des données d'apprentissages collectées par l'entité NWDAF 2).
[0103] En parallèle de cette sélection, ou indifféremment avant ou après cette sélection, le module 2C de traitement collecte les données de réseau INPUT_DATA nécessaires pour réaliser l'analyse statistique et/ou prédictive qui lui a été demandée. Cette collecte peut être réalisée auprès de différentes entités, en fonction du type d'analyse requis, en utilisant les procédures décrites notamment dans le document 3GPP TS 23.288 au paragraphe 6.7.2.4. Une fois les données INPUT_DATA collectées, le module 2C de traitement réalise l'analyse statistique et/ou prédictive (prédiction de mobilité de l'UE 5 dans l'exemple envisagé ici) qui lui a été demandée par l'entité AMF 3.1 en appliquant le modèle d'analyse MOD(CTX) aux données INPUT_DATA collectées (étape F50).
[0104] Il convient de noter que par souci de simplification, on a considéré ici la fonction du module 2C de traitement dans son ensemble, sans préjuger la façon dont le module 2C de traitement est organisé à proprement parler pour assurer cette fonction. Conformément aux Releases 17 et suivantes du standard 3GPP, l'entité NWDAF dans un réseau cœur 5G peut être décomposée en deux fonctions ou modules, un module MLTF (pour « Model Training Logical Function » en anglais) chargé d'entraîner et de fournir les modèles d'analyse et un module AnLF (pour « Analytics Logical Function » en anglais) chargé de produire les analyses en utilisant les modèles fournis par le module MLTF. Les modèles d'analyse sont obtenus par le module AnLF en utilisant des services Nnwdaf_MLModelPro- vision et Nnwdaf_MLModelInfo définis par le standard 3GPP. Si une telle organisation est envisagée pour l'entité NWDAF 2, alors on peut ajouter aux services Nnwdaf_MLModelProvision et Nnwdaf_MLModelInfo un nouveau champ UseCaseContent, comme cela a été fait précédemment pour les services Nnwdaf_AnalyticsInfo et Nnwdaf_AnalyticsSubscription, afin que le module AnLF puisse préciser au module MLTF le contexte CTX de formulation de la requête REQ et que le module MLTF sélectionne le modèle d'analyse à appliquer en fonction de ce contexte CTX de formulaiton. Dans une variante de réalisation, le module AnLF sélectionne lui-même le modèle d'analyse à utiliser en fonction du contexte CTX puis demande le modèle sélectionné au module MTLF.
[0105] Puis l'entité NWDAF 2 fournit, par le biais de son module 2D de fourniture, le résultat RES d'analyse obtenu par le module 2C de traitement (prédiction de la mobilité de l'UE 5 dans l'exemple envisagé ici) à l'entité AMF 3-1 en réponse à sa requête REQ (étape F60).
[0106] Sur réception de la réponse de l'entité NWDAF 2 contenant le résultat d'analyse RES par le module 3B de réception de l'entité AMF-1 (étape E20), le module 2C d'exécution de l'entité AMF 3-1 exécute la procédure PROC dans le cadre de laquelle il a sollicité l'entité NWDAF 2 en utilisant le résultat d'analyse RES fourni par l'entité NWDAF 2 (étape E30). Ainsi, dans l'exemple illustratif envisagé ici, le module 3C d'exécution détermine la zone d'enregistrement de l'UE 5 en utilisant la prédiction de mobilité de l'UE 5 fournie par l'entité NWDAF 2, de façon connue en soi.
[0107] L'invention vient d'être décrite dans le contexte d'un réseau cœur 5G, et notamment d'une fonction NWDAF d'un tel réseau, en s'appuyant avantageusement sur les API définies par le standard 3GPP, modifiées pour les besoins de l'invention. L'invention peut toutefois s'appliquer dans d'autres contextes, et notamment à d'autres réseaux, par exemple à des réseaux propriétaires, des réseaux de futures générations ou correspondant à d'autres versions (ou « Releases » en anglais) d'un réseau 5G, des réseaux IP, etc., à d'autres entités applicatives, comme par exemple à des routeurs, des contrôleurs SDN, etc. qui peuvent être sollicités par diverses entités applicatives du réseau en vue de délivrer des analyses statistiques et/ou prédictives, et exploiter d'autres interfaces que des API (ex. des interfaces point-à-point) pour mettre en œuvre l'invention.
Annexe 1
Figure imgf000020_0001
Figure imgf000021_0001

Claims

Revendications
[Revendication 1] Procédé de traitement d'une requête (REQ) d'analyse statistique ou prédictive reçue par une première entité applicative (2) d'un réseau (CN) de communications en provenance d'une deuxième entité applicative (3-1) du réseau, ledit procédé comprenant : une étape (F30) de détermination, à partir d'au moins une pluralité de paramètres véhiculés (P-CTX, P-DEF) par ladite requête et définissant l'analyse requise par la deuxième entité applicative, d'un contexte (CTX) de formulation de ladite requête par ladite deuxième entité applicative ; une étape (F50) de réalisation de ladite analyse statistique ou prédictive requise au moyen d'un modèle (MOD(CTX)) d'analyse sélectionné (F40) en fonction dudit contexte déterminé ; et une étape (F60) de fourniture d'au moins un résultat (RES) de l'analyse réalisée en réponse à ladite requête de la deuxième entité applicative.
[Revendication 2] Procédé de traitement selon la revendication 1 dans lequel lors de l'étape de détermination, ledit contexte de formulation est déterminé à partir en outre d'un paramètre (P-CTX) inséré par la deuxième entité applicative dans un champ dédié de la requête.
[Revendication 3] Procédé de traitement selon la revendication 1 ou 2 dans lequel ladite pluralité de paramètres sont pris parmi : une identité de la deuxième entité applicative ; un paramètre représentatif d'un type d'analyse requis ; au moins un équipement sur lequel porte ladite analyse ; un paramètre représentatif d'une condition de réalisation de ladite analyse ; un niveau de précision attendu pour ladite analyse ; un paramètre représentatif d'une modalité de notification dudit au moins un résultat de l'analyse.
[Revendication 4] Procédé de traitement selon l'une quelconque des revendications 1 à 3 dans lequel ledit contexte (CTX) de formulation identifie une procédure (PROC) destinée à être exécutée par la deuxième entité applicative dans le réseau en utilisant le résultat fourni par la première entité applicative.
[Revendication 5] Procédé de traitement selon l'une quelconque des revendications 1 à 4 dans lequel la sélection (F40) du modèle d'analyse comprend une sélection d'au moins un élément parmi : une technique d'analyse statistique ou prédictive à utiliser pour réaliser l'analyse ; au moins une caractéristique d'un jeu de données à utiliser pour réaliser l'analyse et/ou entraîner une technique d'analyse utilisée pour réaliser l'analyse ; un paramétrage d'une technique d'analyse utilisée pour réaliser l'analyse.
[Revendication 6] Procédé de traitement selon l'une quelconque des revendications 1 à 5 comprenant une étape préliminaire (F00) de configuration de la première entité applicative avec une liste (LIST) de modèles d'analyse dans laquelle chaque modèle d'analyse est associé à au moins un contexte de formulation d'une requête, ledit modèle d'analyse appliqué lors de l'étape de réalisation étant un modèle d'analyse associé dans ladite liste au contexte déterminé lors de l'étape d'obtention.
[Revendication 7] Procédé de traitement selon l'une quelconque des revendications 1 à 5 comprenant une étape d'apprentissage au cours de laquelle la première entité applicative : établit des corrélations entre des modèles d'analyse, des contextes de formulation d'une requête, et des indicateurs de qualité des analyses réalisées à partir desdits modèles dans lesdits contextes ; et associe, à partir desdites corrélations établies, à au moins un contexte de formulation d'une requête un modèle d'analyse optimisant ladite qualité, ledit modèle d'analyse appliqué lors de l'étape de réalisation étant sélectionné à partir des associations établies lors de l'étape d'apprentissage.
[Revendication 8] Procédé de traitement selon l'une quelconque des revendications 1 à 5 comprenant : une étape (F00) préliminaire (LIST) de configuration de la première entité applicative avec une liste comprenant au moins un modèle d'analyse associé à au moins un contexte de formulation d'une requête ; une étape (F00') d'apprentissage au cours de laquelle la première entité applicative : o établit des corrélations entre des modèles d'analyse, des contextes de formulation d'une requête, et des indicateurs de qualité des analyses statistiques réalisées à partir desdits modèles dans lesdits contextes ; et o met à jour et/ou complète ladite liste à partir desdites corrélations établies ; le modèle d'analyse appliqué lors de l'étape de réalisation étant un modèle d'analyse associé au contexte déterminé lors de l'étape d'obtention dans la liste mise à jour ou complétée lors de l'étape d'apprentissage.
[Revendication 9] Procédé de traitement selon l'une quelconque des revendications 1 à 8 dans lequel la première entité applicative (2) et la deuxième entité applicative (3-1) hébergent des fonctions réseau, ladite fonction réseau hébergée par la première entité applicative étant une fonction de collecte et d'analyse de données du réseau.
[Revendication 10] Programme d'ordinateur (PROG) comportant des instructions pour la mise en œuvre d'un procédé selon l'une quelconque des revendications 1 à 9 lorsque ledit programme est exécuté par un ordinateur.
[Revendication 11] Entité applicative (2) d'un réseau de communications, dite première entité applicative, comprenant : un module (2A) de réception configuré pour recevoir d'une deuxième entité applicative du réseau, une requête d'analyse statistique ou prédictive ; un module (2B) de détermination, configuré pour déterminer un contexte de formulation de ladite requête par ladite deuxième entité applicative à partir au moins d'une pluralité de paramètres (P-DEF) définissant l'analyse requise par la deuxième entité applicative et véhiculés dans la requête d'analyse ; un module (2C) de traitement, configuré pour réaliser ladite analyse au moyen d'un modèle d'analyse sélectionné en fonction dudit contexte de formulation déterminé par ledit module (2B) de détermination ; et un module (2D) de fourniture, configuré pour fournir au moins un résultat de l'analyse réalisée en réponse à ladite requête de la deuxième entité applicative..
[Revendication 12] Entité applicative (2) selon la revendication 11 dans laquelle ledit module (2B) de détermination est configuré pour déterminer ledit contexte de formulation à partir en outre d'un paramètre (P-CTX) inséré par la deuxième entité applicative dans un champ dédié de la requête.
[Revendication 13] Système (1) dans un réseau de communications comprenant : au moins une première entité applicative (2) selon la revendication 12 ; et au moins une deuxième entité applicative (3,3-1) comprenant : o un module (3A) d'envoi, configuré pour envoyer à ladite au moins une première entité applicative du réseau une requête d'analyse statistique ou prédictive comprenant une pluralité de paramètres (P-DEF) définissant l'analyse requise par la deuxième entité applicative et inséré dans un champ dédié de la requête, un paramètre indiquant un contexte de formulation de ladite requête ; et o un module (3B) de réception, configuré pour recevoir de ladite au moins une première entité applicative en réponse à ladite requête, au moins un résultat de l'analyse requise réalisée par ladite au moins une première entité applicative au moyen d'un modèle d'analyse sélectionné en fonction du contexte de formulation de la requête déterminé par ladite au moins une première entité applicative à partir de ladite pluralité de paramètres définissant l'analyse requise par la deuxième entité applicative et dudit paramètre inséré dans ledit champ dédié de la requête.
PCT/EP2023/071633 2022-08-05 2023-08-04 Procédé de traitement d'une requête d'analyse statistique ou prédictive, procédé de communication et entités applicatives aptes à mettre en oeuvre ces procédés WO2024028472A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FRFR2208145 2022-08-05
FR2208145A FR3138710A1 (fr) 2022-08-05 2022-08-05 Procédé de traitement d’une requête d’analyse statistique ou prédictive, procédé de communication et entités applicatives aptes à mettre en œuvre ces procédés

Publications (1)

Publication Number Publication Date
WO2024028472A1 true WO2024028472A1 (fr) 2024-02-08

Family

ID=83594325

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2023/071633 WO2024028472A1 (fr) 2022-08-05 2023-08-04 Procédé de traitement d'une requête d'analyse statistique ou prédictive, procédé de communication et entités applicatives aptes à mettre en oeuvre ces procédés

Country Status (2)

Country Link
FR (1) FR3138710A1 (fr)
WO (1) WO2024028472A1 (fr)

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20220108214A1 (en) * 2020-08-13 2022-04-07 Electronics And Telecommunications Research Institute Management method of machine learning model for network data analytics function device
WO2022164225A1 (fr) * 2021-01-28 2022-08-04 Samsung Electronics Co., Ltd. Formation d'un modèle d'analyse de réseau

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20220108214A1 (en) * 2020-08-13 2022-04-07 Electronics And Telecommunications Research Institute Management method of machine learning model for network data analytics function device
WO2022164225A1 (fr) * 2021-01-28 2022-08-04 Samsung Electronics Co., Ltd. Formation d'un modèle d'analyse de réseau

Non-Patent Citations (5)

* Cited by examiner, † Cited by third party
Title
3GPP TR 23.791
3GPP TS 23.288
3GPP TS 23.288 ET TS 29.520
3GPP TS 23.501
3GPP TS 23.503

Also Published As

Publication number Publication date
FR3138710A1 (fr) 2024-02-09

Similar Documents

Publication Publication Date Title
FR3023108A1 (fr) Procede et dispositif d'orchestration de ressources
EP3053326B1 (fr) Procédé d'accès d'un utilisateur a au moins un service de communication fourni par l'intermédiaire d'un centre informatique d'un système d'informatique en nuage
EP1995931A2 (fr) Système et procédé de mise a jour d'un etat de presence d'un utilisateur sur un terminal par agregation d'informations multi-sources
WO2021260312A1 (fr) Procédé d'ordonnancement de tâches dans un système de traitement, dispositif d'ordonnancement associé
EP2656589B1 (fr) Procede et dispositif de communication de donnees numeriques
WO2024028472A1 (fr) Procédé de traitement d'une requête d'analyse statistique ou prédictive, procédé de communication et entités applicatives aptes à mettre en oeuvre ces procédés
WO2019243700A1 (fr) Procédé d'installation d'une fonction réseau virtualisée
EP2984786B1 (fr) Architecture centralisée pour l'établissement de fédérations de distributeurs de contenus
EP3437292B1 (fr) Procede d'optimisation du debit de contenus multimedia accessibles par au moins un terminal utilisateur, produit programme d'ordinateur et dispositif de gestion correspondants
EP1801716B1 (fr) Diffusion de données par groupement
WO2023247303A1 (fr) Procédé de fourniture d'informations, procédé de sélection, et entités configurées pour mettre en œuvre ces procédés
EP3539259B1 (fr) Procédé et dispositif d'actualisation d'un modèle prédictif d'une variable relative à un terminal mobile
WO2023135043A1 (fr) Procédé, dispositif et système de modification d'une infrastructure de communication
WO2019186049A1 (fr) Procédé de gestion d'un groupe d'équipements, serveur et système associés
EP3542589B1 (fr) Délégation d'instructions à un dispositif en fonction de ses ressources
FR2918527A1 (fr) Procede et dispositif d'insertion d'une adresse dans une requete
EP2166731B1 (fr) Système et procédé d'établissement de communications.
WO2009013440A1 (fr) Procede d'echange de messages entre serveur de donnees de session et des services clients
EP1162799A1 (fr) Procédé de gestion d'un réseau de télécommunications et unité de gestion de réseau pour la mise en oevre du procédé
WO2023217638A1 (fr) Procédé, dispositif et système de certification d'une ressource
EP4335144A1 (fr) Parametrage d'un terminal
WO2022208034A1 (fr) PROCÉDÉS DE SOUSCRIPTION ET DE NOTIFICATION, ET ENTITÉS CONFIGURÉES POUR METTRE EN œUVRE CES PROCÉDÉS.
FR3135584A1 (fr) Procédé, dispositif et système d’élaboration dynamique d’une infrastructure de données
FR3037759A1 (fr) Procede et dispositif de determination de taille de tuiles d'image
WO2013045815A1 (fr) Procede et dispositif de gestion dynamique de la distribution de donnees dans un reseau de telecommunications

Legal Events

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

Ref document number: 23751019

Country of ref document: EP

Kind code of ref document: A1