Get the trained ML model from UE

Abstract

A device is provided, comprising: one or more processors, and a memory storing instructions, which, when executed by the one or more processors, causes the device to: monitor whether a trained model is available at a terminal; if the trained model is available at the terminal, notify a network that the trained model is available at the terminal.

Description

Technical Field

[0001] The present disclosure relates to obtaining one or more trained ML models from a UE.

[0002] abbreviation

[0003] 3GPP: Third Generation Partnership Project

[0004] 3G / 4G / 5G: third generation / fourth generation / fifth generation

[0005] AI: Artificial Intelligence

[0006] AMF: Access and Mobility Management Function

[0007] CN: Core Network

[0008] gNB: 5G base station

[0009] IE: Information Element

[0010] LTE: Long Term Evolution

[0011] MDT: Minimized Drive Test

[0012] ML: Machine Learning

[0013] MR-DC: Multi-RAT-Dual Connectivity

[0014] MTC: Machine Type Communication

[0015] NF: Network Function

[0016] NG-RAN: Next Generation RAN

[0017] NR: New Radio

[0018] O&M: Operations and Maintenance

[0019] RAN: Radio Access Network

[0020] RAT: Radio Access Technology

[0021] Rel: version

[0022] RRC: Radio Resource Control

[0023] RRM: Radio Resource Management

[0024] SA: System Architecture

[0025] SON: Self-Optimizing Network

[0026] SRB: Signalling Radio Bearer

[0027] TS: Technical Specification

[0028] UE: User Equipment

[0029] UL: Uplink Background Art

[0030] 5G networks are expected to meet the challenges of joint optimization of an ever-increasing number of performance metrics. In addition, 5G brings complex system design and optimization problems introduced by NR architecture / features (including MR-DC, beamforming, etc.), which make traditional human-machine interaction slow, error-prone, costly and difficult to cope with these challenges.

[0031] 5G evolution drives the need to study use cases and propose potential service requirements for 5G systems supporting artificial intelligence (AI) / machine learning (ML). The 3GPP SA1 study project agreed in S1-193606 describes the objectives and emphasizes that ML and AI will be involved in specific 5G network entities and infrastructure. The way machine learning processes and models are developed already assumes that 5G services and end-user devices will participate in ML model training.

[0032] The book "Understanding Machine Learning: From Theory to Algorithms" by Shai Shalev-Shwartz and Shai Ben-David (Cambridge University Press, 2014) describes ML as follows: "As an interdisciplinary field, machine learning shares common ties with mathematical areas such as statistics, information theory, game theory, and optimization. It is a natural subfield of computer science, since the goal is to program machines so that they can learn. In a sense, machine learning can be considered a branch of AI (artificial intelligence), because after all, the ability to transform experience into expertise or to detect meaningful patterns in complex sensory data is a cornerstone of human (and animal) intelligence". Furthermore, in this book, machine learning (ML) is defined as that part of automated learning by which computers are programmed so that they can "learn" from the input available to them. Learning is defined as the process of transforming experience into expertise or knowledge. The input to the learning algorithm is training data representing experience, and the output is some expertise, which usually takes the form of another computer program that can perform some task.

[0033] ML execution in 5G may require the end user to train the ML model (i.e., the UE learns from the provided data during the training process).

[0034] At the same time, 3GPP RAN discussed use cases that can be achieved through AI. They include energy saving, service control, mobility optimization, load balancing, physical layer configuration optimization, etc.

[0035] 3GPP Rel-16 defines 5G features under the RAN-centric data collection mechanism, which addresses many network optimization related use cases. Under the RAN data collection framework of Rel.16, the 5G standard supports SON and MDT reports [3GPP TS37.320] to provide operators with a means to monitor and optimize the performance of any kind of 5G deployment and related issues. By default, MDT reports can be classified according to optimization use cases (for example, for radio coverage, the UE records the radio signal level together with the positioning data; for mobility robustness, the UE records the radio signal level when a radio link failure is detected, etc.). In general, MDT and SON enable data collection for both user performance and network performance.

[0036] Training of ML models requires a lot of data. Therefore, SON / MDT features constitute an efficient method for collecting UE data. SON / MDT measurement logs made by end users are very good candidates for predictions of using ML models to monitor mobile services / users. UEs may have several trained ML models available locally. ML model training can be performed per use case or optimization problem.

[0037] MDT is an existing framework that allows radio measurement acquisition. Data collection in Rel.16 for 5G inherits (from LTE) two types of MDT: an immediate MDT method for delivering real-time measurements (e.g., immediate MDT when the results of measurements performed for typical RRM operations in RRC CONNECTED) and a logged MDT method for delivering non-real-time measurement results obtained during the release or suspension of the UE context at the network (logged MDT when the UE is in RRC IDLE or INACTIVE state). Immediate MDT reporting means that the UE generates a real-time report of the radio measurements immediately after performing the radio measurements. For logged MDT reporting, the UE is configured when it is in connected mode. The UE collects data when the UE is in (enters) RRCIDLE or RRC INACTIVE mode. When the UE (re)enters connected mode, a delayed report in the form of a log is sent to the network; the UE can indicate the measurement availability to the network via an RRC message, and the network can obtain the logged report via the UE information process. 3GPP TS37.320 and TS38.331 define these processes.

[0038] By using the method for ML training at the UE described in the MDT configuration of PCT / EP2020 / 061734, the network instructs the UE to autonomously train the ML model. Summary of the invention

[0039] The object of the present invention is to improve the prior art.

[0040] According to a first aspect of the present invention, a device is provided, comprising: one or more processors, and a memory storing instructions, which, when executed by the one or more processors, causes the device to: monitor whether a trained model is available at a terminal; if the trained model is available at the terminal, notify a network that the trained model is available at the terminal.

[0041] According to a second aspect of the present invention, a device is provided, comprising: one or more processors, and a memory storing instructions, which, when executed by the one or more processors, causes the device to: monitor whether information about the availability of a trained model at a terminal is received; and if the information is received, request the terminal to provide the trained model.

[0042] According to a third aspect of the present invention, a method is provided, the method comprising: monitoring whether a trained model is available at a terminal; if the trained model is available at the terminal, notifying a network that the trained model is available at the terminal.

[0043] According to a fourth aspect of the present invention, there is provided a method comprising: monitoring whether information that a trained model is available at a terminal is received; and if the information is received, requesting the terminal to provide the trained model.

[0044] Each of the methods of the third aspect and the fourth aspect may be a machine learning method.

[0045] According to a fifth aspect of the present invention, there is provided a computer program product comprising an instruction set, which, when executed on a device, is configured to cause the device to perform a method according to any one of the third and fourth aspects. The computer program product may be embodied as a computer readable medium or directly loadable into a computer.

[0046] According to some embodiments of the present invention, at least one of the following advantages can be achieved:

[0047] The network can retrieve the trained ML model from the UE;

[0048] The network may receive information that allows a decision on the time to retrieve a trained ML model and / or a decision on the priority of retrieving a trained ML model.

[0049] It should be understood that any of the above modifications may be applied individually or in combination to the various aspects to which they refer, unless they are explicitly stated to exclude alternatives. BRIEF DESCRIPTION OF THE DRAWINGS

[0050] Additional details, features, objects and advantages will become apparent from the following detailed description of preferred embodiments of the present invention taken in conjunction with the accompanying drawings, in which:

[0051] Figure 1 shows a high-level message flow in a standalone 5G architecture according to some example embodiments of the present invention;

[0052] Figure 2 shows message flows according to some example embodiments of the present invention;

[0053] Figure 3 shows message flows according to some example embodiments of the present invention;

[0054] Figure 4 shows message flows according to some example embodiments of the present invention;

[0055] Figure 5 shows message flows according to some example embodiments of the present invention;

[0056] Figure 6 shows message flows according to some example embodiments of the present invention;

[0057] Figure 7 An apparatus according to an example embodiment of the present invention is shown;

[0058] Figure 8 A method according to an example embodiment of the present invention is shown;

[0059] Fig. 9 An apparatus according to an example embodiment of the present invention is shown;

[0060] Fig.10 A method according to an example embodiment of the present invention is shown; and

[0061] Fig.11 An apparatus according to an example embodiment of the invention is shown. DETAILED DESCRIPTION

[0062] Hereinafter, certain embodiments of the present invention are described in detail with reference to the accompanying drawings, wherein the features of the embodiments may be freely combined with each other unless otherwise described. However, it should be clearly understood that the description of certain embodiments is given by way of example only, and is by no means intended to be understood as limiting the present invention to the disclosed details.

[0063] Furthermore, it should be understood that the apparatus is configured to perform the corresponding method, although in some cases only the apparatus or only the method is described.

[0064] Although most AI algorithms may be implementation specific, the trigger conditions for acquiring ML trained models at the UE as well as the ML execution targets should preferably be standardized. Therefore, the signaling support for ML training and execution between the user and the network may be adapted to some of the existing frameworks, which makes standardized signaling for ML support feasible and a major goal from a standards perspective.

[0065] To enable the ML model trained in the UE to be available for use in a 3GPP compliant architecture (RAN, CN), the 5G RAN network nodes may support signaling capabilities that will facilitate the transfer of the trained ML model (i.e., its parameters).

[0066] Currently, there is no signaling framework in the standard for:

[0067] Know that the UE has participated in ML training, especially after it has transitioned to RRCIDLE and the network has released the UE context;

[0068] Get the trained ML model (its parameters);

[0069] Control model data acquisition without affecting normal radio operations and

[0070] Prioritize

[0071] While there may be different methods for engaging the UE in ML execution and triggering ML model training, it is proposed to define a standard interface for signaling for obtaining ML models trained in the UE. Artificial Intelligence (AI) / Machine Learning (ML) support for model distribution and transmission (download, upload, update, etc.) in 5G systems does not yet exist. When the ML model is trained in the UE, some example embodiments of the present invention signal the configuration and / or status of the ML model process to the network. MDT can be used as a signaling baseline for ML purposes.

[0072] Some example embodiments of the present invention address the case where an ML model is trained in a UE that should be acquired for execution in a network. They include control plane signaling and a process for acquiring an ML model trained in a UE by the network. Some example embodiments provide new "ML-specific" parameters that are used to determine ML model characteristics in a process related to ML model training or setting conditions when the ML model is to be acquired. These parameters can be used as conditions for determining additional signaling of (multiple) RRC parameters or indicators to enable the network to decide the best way to acquire the trained ML model.

[0073] Acquisition can be broken down into three main parts:

[0074] 1. Get initiated by ML-specific behaviors and actions in the UE through the following methods

[0075] Trigger:

[0076] - ML Model Availability Happens . The UE determines that it has an available (trained) ML model and makes this information available to the RRC layer. The UE may determine whether the ML model is sufficiently trained based on one or more parameters related to the training. In detail, it may compare the actual value of such a parameter with a target value for the parameter. The network may provide the target value to the UE, or the target value may be predefined. Examples of such parameters are ML model maturity level and ML model status, as described below. The network (gNB) may determine (calculate) the target value itself, or it may receive the target value directly or indirectly from an entity (e.g., a server) that hosts the configuration of the ML model. An example of such an entity is an O&M center, which may determine the target value or may forward the target value to the gNB from another entity that hosts the configuration of the ML model.

[0077] - To the network (represented by gNB) ML Model Availability Indicator . The availability may be attributed to the ML model maturity level and / or the ML model state. The UE may signal the gNB with respect to the ML model availability and may provide parameters such as the ML model maturity level and / or the ML model state to the gNB.

[0078] 2. The gNB takes action in response, accordingly:

[0079] - gNB requests ML model acquisition, If the UE provides ML model parameters, the gNB requests ML model acquisition customized by one or more ML model parameters. The request can be immediate or deferred. Furthermore, it can have normal priority or reduced priority.

[0080] 3. The gNB distributes the ML model to other network entities. This step involves distributing the ML model over the network interface within the RAN node and subsequent nodes (e.g., to the CN, such as Figure 1 If the trained ML model is only used in the gNB itself, this step can be omitted.

[0081] The basic overview of these three steps is as follows Figure 1As shown, ML model data is sent to the core network (AMF) as an example of another network function that uses ML model data. That is, the UE performs training of the ML model. If the model is trained to a certain extent, the UE notifies the NG-RAN of it through the RRC procedure. In addition to information about the availability of the trained ML model, the information may include one or more parameters related to the training of the ML model. One such parameter is the maturity level, which will be described in more detail below. Note that the message flow shown in the figure depicts only messages related to some example embodiments of the present invention, and omits messages that may be required when preparing or tracking related messages.

[0082] Based on the availability indication including parameters (if any), the RAN decides to obtain the ML model data. Therefore, it sends a corresponding UE information request UEInformationRequest to the UE. The UE responds with the ML model data. The RAN can forward the ML model data to other network functions (e.g., AMF) or other RAN nodes.

[0083] In the following, some example embodiments will be described in more detail. As a premise, it is assumed that the UE has participated in the ML model training and the ML model exists in the UE.

[0084] Each ML model (and its training) is applicable to one or more RRC states (RRC_IDLE, RRC_INACTIVE or RRC_CONNECTED) in the UE. This means that the UE is selected and instructed to train the ML model and / or execute the ML model in at least one RRC state. For example, if the ML model targets the RRC state RRC_IDLE, the UE learns radio measurements, or any other measurements selected for ML training performed in the RRC_IDL state. If the ML model target RRC state is RRC_CONNECTED, the UE learns radio measurements performed in this RRC_CONNECT state.

[0085] If the UE performs training in the RRC CONNECT state, the UE can enable data acquisition by the network while in the same state (i.e., in the RRC CONNECT state before releasing the RRC connection). When the UE trains an ML model in an RRC state (i.e., RRC_IDLE, RRC_INACTIVE) without an active RRC connection to the network, the ML model data cannot be transmitted to the network in the same RRC state. Therefore, for ML model data acquisition, the UE must perform an RRC state transition. This means that if the UE is selected and instructed to train and / or execute an ML model in the RRC IDLE and RRC INACTIVE states, the UE maintains the ML model data in an RRC state during which the network has no RRC connection to the UE. It retains the ML model data, at least until an RRC connection occurs (i.e., the UE enters RRC CONNECTED). In the RRC_CONNECTED state, the UE can transmit RRC model data to the network.

[0086] Explain the detailed implementation of the three main parts outlined above according to some example embodiments:

[0087] 1. ML model acquisition initiated by UE: This process consists of two steps, namely:

[0088] a) The UE detects that the ML model is available (trained). The UE determines that it has an available trained ML model and makes the RRC layer aware of the availability. The UE may use one or more of the training-related parameters to evaluate whether the ML model is sufficiently trained.

[0089] b) UE signals ML model availability to gNB

[0090] The ML model availability determination may be a simple Boolean function (true / false). In some example embodiments, the UE may additionally determine actual values ​​of one or more parameters of the availability and inform the gNB of these parameter values ​​via corresponding RRC information elements. The gNB may take these one or more parameter values ​​into account when deciding whether to obtain ML model data from the UE. The UE may even decide not to inform the network of the availability based on these one or more parameter values ​​of the ML model. Due to these one or more parameters for determining the availability of the ML model, overly frequent and inefficient signaling overhead may be avoided.

[0091] Below, we describe in more detail example parameters that can be used by a UE to determine the presence of a sufficiently trained ML model, namely, ML model maturity level and ML model status parameters.

[0092] ML Model Maturity Level: The ML model maturity level is a parameter that defines how mature the ML model is in the training process based on at least one of the following:

[0093] Time: The UE can decide the maturity of the ML model by determining the length of time the ML model has been trained, or the time that has passed since the ML model was uploaded to the UE. The actual and target values ​​of the parameters of the ML model define the evaluation conditions of the UE, i.e., how the UE should determine the ML model maturity with respect to time. It may have values ​​such as "short", "medium", or "long", or it may explicitly indicate the time that has passed since the training started, or since the ML model was uploaded to the UE. If the ML model is actively evaluated by the UE according to the target value of the parameter (e.g., it took a long time to run the ML model), the UE sets the RRC parameter accordingly to signal the actual value of the ML model maturity level parameter.

[0094] Thresholds: The UE may decide the maturity of the ML model by determining how much the trained data deviates from the original ML model, or whether convergence is reached within a certain confidence threshold in the trained ML model. Alternatively, the threshold may comprise a classification decision threshold, which indicates that when the classification threshold is exceeded, the trained ML model decides to perform an action, and when the classification threshold is not exceeded, the trained ML model decides to perform a different action. If the result is above a certain predefined threshold, the threshold may be further used by the UE to compare the results. For example, this may involve a case where the UE is assigned to log a radio signal strength measurement if the measurement exceeds a predefined radio level (expressed in dB) threshold. The signaled parameter value may be a Boolean value (lower or higher than a predefined threshold).

[0095] Model size: The UE decides the maturity of the ML model by determining the size of the data used for training. In this case, the larger the size of the ML model, the more mature the ML model is considered. The model size may be calculated after the ML model has been trained for a sufficient period of time, for example, after a period of time or a certain behavior of the model convergence is observed. The parameter may have values ​​such as "small", "medium", and "large". In addition, the model size may depend on the actual size (in MB) required to describe the trained ML model in terms of the total number of layers, layer types, output shape of each layer, number of weights per layer, etc.

[0096] ML Model Status: ML Model Status is another parameter that indicates the status of model training. Example values ​​for ML Model Status can be:

[0097] In Progress (UE is continuing the ML training process)

[0098] Inactive (UE has no active ML training for the time being, e.g., no conditions are met)

[0099] Trained (UE has completed the ML training process)

[0100] Signaling such parameter values ​​(e.g., ML model maturity level and ML model status) to the network allows the UE to convey additional information in addition to initiating the acquisition procedure that will help the gNB make appropriate decisions regarding the acquisition of the ML model.

[0101] If the ML model is trained in one of the states without an RRC connection to the network (e.g., RRC_IDLE, RRC_INACTIVE), the starting point of the process for indicating the availability of the trained ML model to the network may be the initiation of an RRC connection (i.e., an RRC establishment process). Figure 2 Indicates how the ML model acquisition initiated by the UE is implemented.

[0102] For ML model acquisition initiation by the UE, there are several options:

[0103] a. In one option, ML model availability is determined by New RRC establishment reason or two different situations during RRC establishment Signs under In this case, the availability is either explicitly indicated as a Boolean variable (true / false) or implicitly indicated by the presence or absence of a corresponding parameter. In the first case, due to the size limitation of the RRC Setup Request message, the new establishment reason (e.g., "ML model data") is understood as an implicit method for indicating to the gNB that the ML model is available for acquisition. In the second option, (instead of using RRCSetupRequest) a flag (true / false) can be passed in the RRC Setup Complete message. In order to avoid signaling overhead, the UE can decide whether to indicate the availability of the trained model to the network based on one or more parameters (e.g., maturity level, status). In some example embodiments, only one of these alternatives is implemented, while in some other example embodiments, both of these alternatives are implemented. Examples such as Figure 2 shown.

[0104] b. Option a is related to the initial RRC procedure (RRC establishment). Therefore, if the ML model availability is determined in the RRC_CONNECTED state, or if the UE wishes to inform the network of the ML model availability only after the RRC state transitions to the RRC_CONNECT state, option a may not be used. At least in these cases, the UE may use the UEAssistanceInformation RRC procedure. Compared to the RRC establishment, this procedure is less restrictive in size and therefore provides greater flexibility in signaling capabilities. The message flow is as follows Figure 3 Greater flexibility allows the UE to indicate parameters (e.g., maturity and / or status) of ML model training to the gNB. The UEAssistanceInformation RRC procedure may also be used as a complementary procedure to the indication of ML model availability during the RRC establishment procedure. In this case, the UEAssistanceInformation RRC procedure may be used to communicate the determined training parameter value(s) (e.g., maturity and / or status) to the gNB.

[0105] The UEAssistanceInformation RRC procedure provides the possibility to inform the network about the availability of a trained ML model any time the UE is in the RRC_CONNECTED state, independently of any state transition.

[0106] 2. ML model acquisition by gNB:

[0107] After receiving an indication from the UE that a trained model is available, the gNB may request the ML model using an RRC procedure. For example, as an RRC request message, the gNB may use an RRC UE INFORMATION REQUEST message. The UE responds accordingly (e.g., via an RRC UE INFORMATION RESPONSE message) with the ML model, such as Figure 4 shown.

[0108] The UE may have several ML models available locally. These ML models may be used to train and further solve one or more optimization problems (ML model for coverage optimization, ML model for mobility robustness, etc.). In this case, the request from the network may be per trained use case / ML model, or the gNB may fetch multiple models with a single request.

[0109] If the UE provides the gNB with actual parameter values ​​for the training of the ML model (e.g., ML model maturity level, ML model status), the gNB may decide to lower the priority of the signaling to be used for ML model acquisition based on the parameter values. For example, in order to support a lower priority, the gNB may decide to configure SRBs with a lower priority compared to the regular more important dedicated signaling (SRB1, SRB2, SRB3). A new SRB (e.g., "SRB4") may be defined and used for the acquisition process of ML related content, i.e., the existing RRC UE information process may be used with the new (lower priority) allocation.

[0110] In some example embodiments, if the UE provides (multiple) ML model parameter values, the gNB may decide, based on the (multiple) parameter values, when to acquire the ML model. For example, it may decide to acquire the ML model immediately, or to defer the acquisition to a later point in time. Of course, the gNB may also decide not to acquire the ML model (=delay to eternity) based on the parameter values.

[0111] In some example embodiments, the gNB may use the same parameter value to decide both deprioritization and delay. For example, the gNB may use one or both of the actual value of the ML model maturity level and the actual value of the ML model status to decide both deprioritization and delay. In some example embodiments, the gNB may use different parameters for these decisions. For example, it may use the ML model maturity level to decide deprioritization and the ML model status to decide delay (or vice versa).

[0112] The existing RRC UE INFORMATION procedure has the capability to provide information split in segments of several UE INFORMATION messages. In this case, the UE simply indicates in the UE INFORMATION message that it has more segments of the ML model to send, and consecutive UE INFORMATION RESPONSE messages will appear (see Figure 5 , the last three messages from UE to NG-RAN).

[0113] In another example embodiment, the UE's own behavior in response to the ML Get command may segment the UL message (e.g., in the case where the ML model data does not fit into one RRC message). To achieve this, the ULDedicatedMessageSegment RRC message is extended with a new parameter for segmentation of the ML model (see Figure 6 ), that is, the applicability of the existing RRC message ULDedicatedMessageSegment is extended to the ML use case. Figure 6As shown in the example of , the network makes acquisition decisions based on the maturity level of the ML model, which maturity level can be determined based on the ML model size received from the UE at the network. In this way, the network can implicitly determine how many different segments are required to transmit the entire ML model based on the overall ML model size and the maximum size of the ULDedicatedMessageSegment RRC message. As another alternative in the ULDedicatedMessageSegment RRC message, the UE can indicate not only the number of segments sent each time, but also the total number of segments it has segmented the ML model into, for example, segment 1 of 3 segments, segment 2 of 3 segments, and segment 3 of 3 segments. These two alternatives can be used separately as two different options (implicit and explicit) for indicating the total number of segments to the network. As another possibility, these two alternatives (implicit and explicit) can be used together so that the UE can indicate the ML model size to the network and at the same time can indicate the number of segments sent each time and the total number of segments to the network.

[0114] 3. gNB distributes ML model parameters forward to other network entities (optional)

[0115] Depending on the use case, the ML model trained on the UE side and acquired by the gNB using the above process can be executed in other network entities (network functions) outside the gNB, such as in the core network. This scenario requires further distribution of the acquired UE ML model on the network interface between the gNB and other network entities, such as Figure 1 shown.

[0116] Although AI / ML algorithms are implementation dependent, it is recommended to standardize signaling support to obtain trained ML models from the UE and forward them to another network entity (network function) that executes the ML model (ML inference host). The option of training the model (or part of the model) in the UE is the best solution for many use cases that require a large number of UE measurements and / or information, as it maintains spectral efficiency without jeopardizing regular radio resource usage. At the same time, it enables the RAN to participate in the ML architecture and ML data acquisition to use ML in standardized 5G deployments.

[0117] Figure 7 An apparatus according to an embodiment of the present invention is shown. The apparatus may be a terminal, such as a UE or an MTC device, or an element thereof. Figure 8 A method according to an embodiment of the present invention is shown. Figure 7 The device can perform Figure 8 method, but not limited to this method. Figure 8 The method can be Figure 7 The present invention is performed by a device, but is not limited to being performed by the device.

[0118] The device includes a component 20 for monitoring and a component 30 for notifying. The component 20 for monitoring and the component 30 for notifying may be a monitoring component and a notifying component, respectively. The component 20 for monitoring and the component 30 for notifying may be a monitor and a notifier, respectively. The component 20 for monitoring and the component 30 for notifying may be a monitoring processor and a notification processor, respectively.

[0119] The monitoring means 20 monitors whether the trained model (ML model) is available at the terminal (S20). If the trained model is available at the terminal (S20=Yes), the notification means notifies the network that the trained model is available at the terminal (S30). The network may be a network to which the terminal is connected.

[0120] Fig. 9 An apparatus according to an embodiment of the present invention is shown. The apparatus may be a base station, such as a gNB or an eNB, or an element thereof. Fig.10 A method according to an embodiment of the present invention is shown. Fig. 9 The device can perform Fig.10 method, but not limited to this method. Fig.10 The method can be Fig. 9 The present invention is performed by a device, but is not limited to being performed by the device.

[0121] The apparatus includes a component 120 for monitoring and a component 130 for requesting. The component 120 for monitoring and the component 130 for requesting may be a monitoring component and a requesting component, respectively. The component 120 for monitoring and the component 130 for requesting may be a monitor and a requester, respectively. The component 120 for monitoring and the component 130 for requesting may be a monitoring processor and a requesting processor, respectively.

[0122] The monitoring means 120 monitors whether information about the trained model (ML model) being available at the terminal is received (S120). If the information is received (S120=Yes), the requesting means 130 requests the terminal to provide the trained model (S130).

[0123] Fig.11 An apparatus according to an embodiment of the present invention is shown. The apparatus comprises at least one processor 810, at least one memory 820 including computer program code, and the at least one processor 810 together with the at least one memory 820 and the computer program code are arranged to cause the apparatus to at least perform a Figure 8 and Fig.10 And at least one of the related described methods.

[0124] Some example embodiments are explained with respect to 5G networks. However, the present invention is not limited to 5G. The present invention can be used in 3G or 4G networks that support terminals (UEs) to train ML models and future generations of 3GPP networks. In addition, the present invention is not limited to 3GPP networks. Other networks (e.g., WiFi networks) can use the present invention if the corresponding terminal trains the ML model and the results of the training will be delivered to the network.

[0125] In some contexts, parameter(s) related to ML model training may be represented as “attributes.” In this context, the terms “parameter” and “attribute” may be considered synonyms.

[0126] A piece of information can be transmitted from one entity to another in one or more messages. Each of these messages can include additional (different) information.

[0127] The names of network elements, network functions, protocols and methods are based on current standards. In other versions or other technologies, the names of these network elements and / or network functions and / or protocols and / or methods may be different, as long as they provide corresponding functions.

[0128] The terminal (UE) may be, for example, a mobile phone, a smartphone, an MTC device, a laptop, etc. The user may be a human user or a machine (eg, machine type communication (MTC)).

[0129] If not otherwise stated or otherwise clarified from the context, a statement that two entities are different means that they perform different functions. This does not necessarily mean that they are based on different hardware. That is, each entity described in this specification can be based on different hardware, or some or all entities can be based on the same hardware. This does not necessarily mean that they are based on different software. That is, each entity described in this specification can be based on different software, or some or all entities can be based on the same software. Each entity described in this specification can be deployed in the cloud.

[0130] According to the above description, it should be clear that the exemplary embodiments of the present invention, for example, provide a terminal (such as a UE or an MTC device, or a component thereof), an apparatus embodying the terminal, a method for controlling and / or operating the terminal, and a computer program (s) for controlling and / or operating the terminal, and a medium that carries such a computer program (s) and forms a computer program product (s). According to the above description, it should be clear that the exemplary embodiments of the present invention, for example, provide an access network (such as a RAN or a component thereof) (for example, an eNB or a gNB), an apparatus embodying the access network, a method for controlling and / or operating the access network, and a computer program (s) for controlling and / or operating the access network, and a medium that carries such a computer program (s) and forms a computer program product (s).

[0131] As non-limiting examples, implementation of any of the above blocks, devices, systems, techniques, or methods includes implementation as hardware, software, firmware, dedicated circuits or logic, general purpose hardware or controllers or other computing devices, or some combination thereof. Each entity described in this specification may be embodied in the cloud.

[0132] It should be understood that what has been described above is what is currently considered to be the preferred embodiment of the present invention. However, it should be noted that the description of the preferred embodiment is given by way of example only and various modifications can be made without departing from the scope of the present invention as defined in the appended claims.

Claims

1. A device for processing a trained model, comprising: one or more processors, and a memory storing instructions that, when executed by the one or more processors, cause the apparatus to: Monitor whether the trained model is available at the terminal; If the trained model is available at the terminal, informing a network that the trained model is available at the terminal, wherein the apparatus is further caused to: determining actual values ​​of the trained parameters of the trained model; as well as If the trained model is available at the terminal, indicating the actual value of the parameter to the network, wherein the actual value is used to determine the time when the terminal is requested to provide one or more parameters of the trained model, and the request is prohibited before the determined time.

2. The apparatus of claim 1 , wherein the instructions, when executed by the one or more processors, further cause the apparatus to: supervising whether the terminal receives a request to provide the trained model to the network; and If the request is received, the trained model is provided to the network.

3. The apparatus of claim 2, wherein the trained model is provided to the network in a plurality of segments.

4. The apparatus of claim 1 , wherein the instructions, when executed by the one or more processors, further cause the apparatus to: checking whether the terminal is served by the network in a connected mode; and If the terminal is not served in the connected mode, before or together with notifying the network that the trained model is available at the terminal, initiating a transition of the terminal to the connected mode.

5. The apparatus according to claim 1, wherein the parameters include: At least one of a maturity level of the trained model and a status of the trained model.

6. The apparatus of claim 1 or 5, wherein the instructions, when executed by the one or more processors, further cause the apparatus to: Based on the actual value of the parameter and the target value of the parameter, deciding whether to notify the network that the trained model is available at the terminal; and If it is decided not to notify the network that the trained model is available at the terminal, then prohibiting the network from being notified that the trained model is available at the terminal.

7. The apparatus of claim 6, wherein the target value of the parameter is received from the network via a radio resource control command.

8. An apparatus for processing a trained model, comprising: one or more processors, and a memory storing instructions that, when executed by the one or more processors, cause the apparatus to: monitoring whether information that a trained model is available at the terminal is received; and If the information is received, requesting the terminal to provide the trained model, wherein the apparatus is further caused to: checking whether an actual value of the trained first parameter of the trained model is received; Based on the actual value of the first parameter, determining a time to request the terminal to provide one or more parameters of the trained model; as well as It is prohibited to request the terminal to provide the trained model earlier than the determined time.

9. The apparatus of claim 8, wherein the information is a reason or a flag in a request to serve the terminal in connected mode.

10. The apparatus of claim 8, wherein the instructions, when executed by the one or more processors, further cause the apparatus to: checking whether an actual value of the trained second parameter of the trained model is received; Based on the actual value of the second parameter, determining a priority for providing the trained model; as well as The provided radio bearers for the trained model are configured according to the priorities.

11. The apparatus according to claim 10, wherein the first parameter and the second parameter respectively include: At least one of a maturity level of the trained model and a status of the trained model.

12. The apparatus of claim 10, wherein the instructions, when executed by the one or more processors, further cause the apparatus to: The target value of the first parameter and the target value of the second parameter are respectively provided to the terminal via a radio resource control command. 13 . The apparatus according to claim 12 , wherein the target value of the first parameter and the target value of the second parameter are respectively received from an operation and maintenance center.

14. The apparatus of claim 8, wherein the instructions, when executed by the one or more processors, further cause the apparatus to: The trained model is received in a plurality of segments.

15. The apparatus of any one of claims 8 to 14, wherein the instructions, when executed by the one or more processors, further cause the apparatus to: supervising whether the trained model is received from the terminal in response to the request to provide the trained model; and If the trained model is received, the trained model is distributed to one or more network entities.

16. A method for processing a trained model, comprising: Monitor whether the trained model is available at the terminal; as well as If the trained model is available at the terminal, notifying the network that the trained model is available at the terminal, wherein the method further comprises: determining actual values ​​of the trained parameters of the trained model; as well as If the trained model is available at the terminal, indicating the actual value of the parameter to the network, wherein the actual value is used to determine the time when the terminal is requested to provide one or more parameters of the trained model, and the request is prohibited before the determined time.

17. A method for processing a trained model, comprising: monitoring whether information about the trained model being available at the terminal is received; as well as If the information is received, requesting the terminal to provide the trained model, wherein the method further comprises: checking whether an actual value of the trained first parameter of the trained model is received; Based on the actual value of the first parameter, determining a time to request the terminal to provide one or more parameters of the trained model; and It is prohibited to request the terminal to provide the trained model earlier than the determined time.

18. A computer-readable medium comprising program instructions which, when executed on a device, cause the device to at least perform the method according to claim 16 or 17.

Images