JP7843859B2 - Machine learning fallback models for wireless devices - Google Patents

Description

Embodiments of this disclosure relate to wireless communications, and more specifically, to machine learning fallback models for wireless devices.

In general, all terms used herein should be interpreted according to their common meanings in the relevant technical field, unless otherwise explicitly stated, and/or unless otherwise suggested by the context in which they are used. All references to any element, apparatus, component, means, step, etc., should be openly interpreted as references to at least one example of such element, apparatus, component, means, step, etc., unless otherwise explicitly stated. Unless a step is explicitly described as following or preceding another, and/or it is implicitly understood that a step must follow or precede another, the steps of any method disclosed herein do not have to be performed in the strict order disclosed. Any feature of any embodiment disclosed herein may be applied to any other embodiment, where appropriate. Similarly, any advantage of any embodiment may apply to any other embodiment, and vice versa. Other purposes, features, and advantages of the embodiments included will become apparent from the following description.

Artificial intelligence (AI) and machine learning (ML) are seen in both academia and industry as promising tools for optimizing the design of air interfaces in wireless communication networks. Exemplary use cases include the use of autoencoders for channel status information (CSI) to reduce feedback overhead and improve channel prediction accuracy; the use of deep neural networks for classifying line-of-sight (LOS) and non-line-of-sight (NLOS) conditions to improve positioning accuracy; the use of reinforcement learning for beam selection on the network and/or user equipment (UE) side to reduce signaling overhead and beam alignment latency; and the use of deep reinforcement learning to learn optimal precoding policies for complex multiple-input multiple-output (MIMO) precoding problems.

The standardization work for Release 18 of the Third Generation Partnership Project (3GPP) New Radio (NR) includes a research item on AI/ML for NR air interfaces. This research item will explore the benefits of augmenting air interfaces with a set of features that enable improved support for AI/ML-based algorithms for performance improvements and/or reduction of complexity/overhead. Through the study of several selected use cases (CSI feedback, beam management, and positioning), the research item is intended to lay the foundation for leveraging AL/ML technology for future air interface use cases.

When applying AI/ML to an air interface use case, various levels of collaboration between network nodes and UEs are possible. In one use case, there is no collaboration between the network nodes and the UE. In this case, a private ML model operating on an existing standard air interface is applied to one end of the communication chain (e.g., the UE side), and model lifecycle management (e.g., model selection/training, model monitoring, model retraining, model updates) is performed at that node without inter-node support (e.g., provision of support information by network nodes).

Other use cases involve limited collaboration between network nodes and UEs. In this case, the ML model operates at one end of the communication chain (e.g., the UE side), but that node receives support from a node at the other end of the communication chain (e.g., next-generation node B (gNB)) for managing its AI model's lifecycle (e.g., for AI model training/retraining and model updates).

The third use case is coupled ML operation between network nodes and UEs. In this case, the AI model can be divided into one part located on the network side and the other part located on the UE side. Therefore, the AI model involves joint training between the network and the UE, with both ends of the communication chain involved in the lifecycle management of the AI model.

Building an AI model or any machine learning model involves numerous development steps, while the actual training of the AI model is merely one step in the training pipeline. A crucial aspect of AI development is the lifecycle management of the ML model. An example is shown in Figure 1.

Figure 1 illustrates the training and inference pipelines, as well as their interactions within the model lifecycle management procedure. Model lifecycle management typically consists of a training (retraining) pipeline, a deployment phase to integrate the trained (or retrained) AI model into the inference pipeline, the inference pipeline itself, and a drift detection phase that notifies about drift in model behavior.

The training (retraining) pipeline may include data intake, data preprocessing, model training, model evaluation, and model registration. Data intake refers to the collection of raw (training) data from data storage. After data intake, there may be steps to control the validity of the collected data.

Data preprocessing refers to the engineering characteristics applied to collected data, and may include, for example, data normalization and possibly data transformation required for input data to an AI model.

Model training refers to the actual model training stages outlined above.

Model evaluation refers to benchmarking the model's performance against a baseline. The cycle of model training and evaluation is repeated until an acceptable level of performance (as illustrated above) is achieved.

Model registration refers to registering an AI model, along with possibly the results of an AI model evaluation, including any corresponding AI metadata that provides information about how the AI model was developed.

The deployment phase involves integrating a pre-trained (or retrained) AI model into the inference pipeline.

The inference pipeline may include data intake, data preprocessing, model operation, and data and model monitoring. Data intake refers to the collection of raw (inference) data from data storage.

The data preprocessing stage is typically identical to the corresponding processing that occurs in the training pipeline.

Model operation refers to using a trained and deployed model in operation mode.

Data and model monitoring involves verifying that the inference data follows a distribution that closely matches the training data, as well as monitoring model outputs to detect any performance or operational drift.

During the drift detection phase, notifications are provided regarding drift in the model's behavior.

Currently, several challenges exist. For example, in one use case category, an ML model is deployed on the UE side, and the model output is reported from the UE to the network nodes. Based on the model output, the network takes actions that affect current and subsequent wireless communications between the network and the UE.

The ML model deployed on the UE side is not generalizable to all scenarios. Therefore, the output of the ML model (e.g., estimated channel quality indicator (CQI) values, predicted channel status information (CSI) in one or more subbands, predicted beam measurement results in the temporal and/or spatial domains, estimated UE location, etc.) may be inaccurate, the error interval may be higher than acceptable, or/or the accuracy (or accuracy interval) may be unacceptable. Since the network performs transmit and receive actions based on the ML model output, inaccurate model output can lead to incorrect decisions on the network side, negatively impacting wireless communication performance.

For example, based on erroneous beam measurement predictions reported by a UE, the network may activate (and/or trigger beam switching) Transmit Configuration Information (TCI) states at UEs that do not correspond to (or have poor coverage performance of) beams detectable by the UE. Such incorrect decisions could result in beam failure, radio link failure, poor throughput, and/or excessive signaling due to subsequent CSI measurement configuration/activation.

In other use case categories, the ML model is divided into two parts: one located on the network side and the other on the UE side. One exemplary use case is autoencoder (AE)-based CSI feedback/reporting, where an encoder operates in the UE to compress the estimated wireless channel, and the output from the encoder (estimated compressed wireless channel information) is reported from the UE to the gNB. The gNB uses a decoder to reconstruct the estimated wireless channel information. Therefore, the ML model for this use case category requires coupled operation between the network and the UE. If the UE-side portion of the ML model does not function properly, the overall performance of the related functionality (e.g., CSI reporting) will be affected.

If performance drift in an ML model is detected, it may be possible to start a new data set and retain the ML model. However, retaining such a data set and model can be time-consuming. Depending on the capabilities of the UE, online model retention may not be practical.

When ML models are used for critical functionality, it is crucial to ensure that the robustness and resilience of that functionality are not affected if the ML model malfunctions. If performance issues are detected or predicted in the active ML models associated with that critical functionality, prompt action is necessary.

Regarding the ML use case categories mentioned above, the current NR standard lacks a mechanism to guarantee/maintain the robustness and resilience of critical functionalities when an ML model operating for critical functionality is not functioning properly.

As described above, there are currently some challenges regarding preliminary machine learning models for wireless devices. Certain aspects of this disclosure and their embodiments may provide solutions to these or other challenges.

For example, a specific embodiment includes a user device (UE) capable of operating at least one machine learning (ML)-based feature for a certain functionality, and also supporting at least a preliminary feature for that functionality. The UE demonstrates to the network its capability to support a combination of at least one ML-based feature and the preliminary feature for the functionality.

If a performance issue is detected with at least one ML-based feature, the UE may either be instructed by the network to switch to a backup feature for that feature's functionality, or it may autonomously switch to the backup feature and indicate the feature switch to the network.

According to some embodiments, a method in a UE operating with at least one ML-based feature associated with a certain functionality includes sending a message to a network node indicating its ability to support a combination of at least one ML-based feature and at least one preliminary feature for the associated functionality.

In specific embodiments, the at least one ML-based feature is based on one or more ML models located in the UE. In specific embodiments, the at least one ML-based feature is based on one ML model that can be divided into two parts, one part located in the UE and the other part located in the network node. In specific embodiments, the at least one ML-based feature is based on multiple ML models, some of which are located in the UE and the remainder located in the network.

In specific embodiments, the preliminary features are features that can satisfy the same functionality as the ML-based features, but are not preferred compared to the ML-based alternative. In specific embodiments, the preliminary features are features with capabilities equal to or less than those of the ML-based features. In specific embodiments, the preliminary features are features with higher capabilities than the ML-based features, but are not preferred for other reasons, including higher complexity, longer processing delays, higher power consumption, and excessive consumption of time/frequency resources. The definition of higher capability depends on functionality; for example, for channel state information (CSI), higher capability may refer to more accurate CSI feedback (including subband selection, rank indicator (RI), precoding matrix indicator (PMI), and coding modulation scheme (MCS)); for beam management, higher capability may refer to higher accuracy in indicating the best candidate beam; and for positioning, higher capability may refer to a more accurate estimation of the UE's position.

In specific embodiments, the above preliminary features are based on a classical non-ML-based algorithm. In specific embodiments, the above preliminary features are an ML-based algorithm.

In specific embodiments, the above message indicates whether the at least one preliminary feature and the ML-based feature can be executed simultaneously. The message indicating its own ability to support a combination of at least one ML-based feature and at least one preliminary feature for the associated functionality is (part of) the UE capability parameters associated with the functionality. The message may explicitly indicate that a UE supporting a certain ML-based feature is also expected to support a preliminary feature for the associated functionality. The message may point to at least one entry for a composite codebook combination in which a certain codebook type is associated with an ML-based feature. The message may support different combinations of at least one ML-based feature and at least one preliminary feature between frequency division duplexing (FDD) and time division duplexing (TDD), between FR1 and FR2, and/or between multiple different bands.

In a specific embodiment, the message indicating its ability to support a combination of at least one ML-based feature and at least one preliminary feature relating to the associated functionality is a radio resource control (RRC) message, a media access control (MAC) control element (CE), Msg1, MsgA, Msg3, a combination of Msg1 and Msg3, uplink control information (UCI), or scheduling control information (SCI). The message may be transmitted when the UE activates/switches on/registers at least one ML model associated with the ML-based feature.

In a specific embodiment, the method further includes the UE receiving a first configuration message from the network node, which configures the UE to simultaneously execute/operate at least ML-based features and at least preliminary features with respect to the associated functionality.

In a specific embodiment, the method further includes the UE receiving a second configuration message from the network node, which configures the UE to deactivate/stop/switch off at least one ML-based feature of the associated functionality and activate/switch on the associated auxiliary feature. The network may transmit the second configuration message if a performance failure of at least one ML-based feature of the associated functionality is detected/predicted. The method further includes, in response to receiving the second configuration message from the network node, the UE deactivating/stopping the ML-based feature and activating/switching on the auxiliary feature according to the information contained in the second configuration message.

In a specific embodiment, the method further includes the UE monitoring the ML model performance of one or more ML-based features. The UE detects or predicts a performance failure of at least one ML-based feature with respect to the associated functionality, autonomously deactivates/stops at least the detected ML-based feature, and activates/switches on at least the associated backup feature. The method further includes the UE indicating the network node about the feature switching information (e.g., the deactivated/stopped/switched-off ML-based feature).

In a specific embodiment, if there are multiple preliminary features supported by the UE for the associated functionality, the order/sequence for the UE to switch between functions (for example, first switching to preliminary feature 1, and if a failure occurs, then switching to preliminary feature 2) is pre-configured by the network node or pre-defined in the standard.

In specific embodiments, examples of functionality include CSI reporting, time-domain beam prediction or beam selection, spatial-domain beam prediction or beam selection, beam fault prediction, radio link fault prediction, mobility management (e.g., handover determination), location estimation, and link adaptation (e.g., MCS selection).

In a specific embodiment, the above functionality is CSI reporting, the at least one ML-based feature is ML-based CSI reporting, and the at least one preliminary feature is a legacy CSI reporting type (e.g., Type 2 codebook-based CSI reporting, Type 2 codebook-based CSI reporting, or Type 1 single-panel-based CSI reporting).

According to some embodiments, the method at a network node includes receiving a message from the UE indicating the UE's ability to support a combination of at least one ML-based feature and at least one preliminary feature for a certain functionality.

In a specific embodiment, the method further includes the network node sending a first configuration message instructing the UE to simultaneously execute/operate at least ML-based features and at least preliminary features with respect to the associated functionality, in response to receiving capability information of the UE.

In a specific embodiment, the message further includes sending a second configuration message instructing the UE to deactivate/stop/switch off at least one detected/predicted ML-based feature that may have a performance issue, and to activate/switch on the associated auxiliary feature, in response to the detection/prediction of a performance issue in at least one ML-based feature of the associated functionality.

In a specific embodiment, the method further includes the UE receiving an indication from the UE regarding the switching information of the associated functionality (e.g., deactivated/stopped/switched-off ML-based features and activated/switched-on auxiliary features).

In a specific embodiment, the method further includes, for example, cases where the network node is based on an ML model in which the ML-based features are divided into two parts, one part of which is located in the UE and the other part in the network, or cases where the ML-based features are based on multiple ML models in which part of the model is located in the UE and the rest of the model is located in the network, deactivating/stopping/switching off the associated ML model on the network side for at least the ML-based features to be deactivated.

In a specific embodiment, the method further includes the network node sending a modified configuration and/or scheduling message to the UE accordingly. The modification by the modified configuration and/or scheduling message may include an updated reference signal resource configuration for the UE's measurements and/or an updated CSI reporting configuration for the UE to report the CSI using the preliminary features.

According to some embodiments, a method is performed by a wireless device for the fallback operation of an ML model. This method includes sending a message to a network node indicating the wireless device's ability to support a combination of at least one ML-based feature for a functionality and at least one preliminary feature for the functionality; activating the at least one ML-based feature for the functionality; and activating the at least one preliminary feature for the functionality.

In a specific embodiment, the above-described at least one ML-based feature is based on an ML model that is divided into two parts, one of which is located in the wireless device and the other in which is located in the network node.

In specific embodiments, the at least one preliminary feature is a feature that satisfies functionality equivalent to the ML-based feature, but is not preferred over the ML-based feature. The at least one preliminary feature may also be a feature with higher capabilities than the ML-based feature, but is not preferred. The at least one preliminary feature may be based on a non-ML-based algorithm, or on another ML-based algorithm (e.g., a more general-purpose ML-based algorithm).

In a specific embodiment, the above message indicates whether the at least one preliminary feature and the at least one ML-based feature can be executed simultaneously (for example, for a performance comparison between the two).

In a specific embodiment, the method further includes receiving a first configuration message that configures the wireless device to operate the at least one ML-based feature.

In a specific embodiment, the method further includes receiving a first configuration message that configures the wireless device to operate simultaneously with at least one ML-based feature and at least one auxiliary feature.

In a specific embodiment, the method further includes receiving a second configuration message that configures the wireless device to deactivate at least one ML-based feature and activate at least one auxiliary feature.

In a specific embodiment, the method further includes autonomously determining that at least one ML-based feature should be deactivated and at least one preliminary feature should be activated.

According to some embodiments, the wireless device comprises a processing circuit capable of performing any of the methods of the wireless device described above.

Furthermore, a computer program product is disclosed that includes a non-temporary computer-readable medium for storing computer-readable program code, the computer-readable program code being operable to perform any of the methods described above, when executed by a processing circuit, by the wireless device described above.

According to some embodiments, a method is performed by a network node to configure a wireless device for fallback operation of an ML model. This method includes receiving a message from the wireless device indicating the wireless device's ability to support a combination of at least one ML-based feature and at least one preliminary feature for the functionality; determining that the at least one preliminary feature should be activated; and sending a configuration message to the wireless device configuring it to deactivate the at least one ML-based feature and activate the at least one preliminary feature.

In a specific embodiment, the above-described at least one ML-based feature is based on an ML model that is divided into two parts, one of which is located in the wireless device and the other in which is located in the network node.

In a specific embodiment, the above message indicates whether the at least one preliminary feature and the at least one ML-based feature can be executed simultaneously.

In a specific embodiment, the method further includes sending a configuration message to the wireless device that configures the wireless device to operate the at least one ML-based feature.

In a specific embodiment, the method further includes transmitting a configuration message that configures the wireless device to operate simultaneously with at least one ML-based feature and at least one auxiliary feature.

Other computer program products include a non-temporary computer-readable medium for storing computer-readable program code, which, when executed by a processing circuit, is operable to perform one of the methods described above, which are performed by the network nodes.

A particular embodiment may provide one or more of the following technical advantages. For example, a specific embodiment ensures that a UE supporting ML-based features for a critical functionality also supports alternative features for that functionality. By sharing the capability information of such UEs with network nodes, the UEs (and network nodes) can switch to alternative features if performance problems are detected/predicted for the ML-based features. Thus, a specific embodiment ensures/maintains the robustness and resilience of a critical functionality when the ML model operating for that functionality is not functioning properly.

For a better understanding of the disclosed embodiments and their features and advantages, the following description is to be referred to hereafter in conjunction with the accompanying drawings:
This shows the training and inference pipelines, as well as their interactions in model lifecycle management procedures. This flowchart shows an example of a fallback for ML-based features supported by network nodes. This flowchart shows an example of autonomous ML-based feature fallback by the UE and reporting of that action to network nodes. An exemplary communication system according to one embodiment is shown. An exemplary UE according to one embodiment is shown. This shows an exemplary network node according to one embodiment. This shows a block diagram of a host according to one embodiment. This shows a virtualization environment in which a set of functions implemented by several embodiments according to one embodiment can be virtualized. This illustrates a host communicating with a UE via a network node over a partially wireless connection according to one embodiment. This describes a method performed by a wireless device according to one embodiment. This describes a method executed by a network node according to one embodiment.

As described above, there are currently some challenges regarding preliminary machine learning models for wireless devices. Certain aspects of this disclosure and their embodiments may provide solutions to these or other challenges.

For example, a specific embodiment includes a user device (UE) capable of operating at least one machine learning (ML)-based feature for a certain functionality, and also supporting at least a preliminary feature for that functionality. The UE demonstrates to the network its capability to support a combination of at least one ML-based feature and the preliminary feature for the functionality.

Specific embodiments will be described more thoroughly with reference to the attached drawings. However, other embodiments are included within the scope of the subject matter disclosed herein, and the disclosed subject matter should not be construed as being limited only to the embodiments described herein. Rather, those embodiments are provided as examples to convey the scope of the subject matter to those skilled in the art.

As used herein, the terms “ML model,” “AI-based feature,” and “ML-based feature” are interchangeable. An AI/ML model may be defined as a feature or part of a feature deployed/implemented within the first node. The first node may receive messages from the second node indicating that its feature is not working correctly, for example, if the prediction error is higher than a predefined value, the error interval is not within an acceptable level, or the prediction accuracy is lower than a predefined value.

Furthermore, the AI/ML model may be defined as a function or part of a function implemented/supported within the first node. The first node may point to the second node with the version of that function. If the ML model is updated, the version of the function may be changed by the first node.

An ML model can correspond to a function that accepts one or more inputs (e.g., measurement results) and provides one or more prediction/estimation results of a certain type as output. In one example, an ML model can correspond to a function that accepts the measurement result of a reference signal (e.g., transmitted on beam X) at time t0 as input and provides a prediction of the reference signal at timer t0+T as output. In another example, an ML model can correspond to a function that accepts the measurement result of a reference signal X (e.g., transmitted on beam X), such as a synchronous signal block (SSB) with index 'x', and provides a prediction of another reference signal transmitted on a different beam, such as reference signal Y (e.g., transmitted on beam X), such as an SSB with index 'x', as output.

Another example is an ML model that assists in the estimation of Channel State Information (CSI). In such a setup, the ML models are a unique ML model at the UE and a network-side ML model. Both ML models work together to provide coupled network functionality. The function of the UE ML model is to compress the channel input, while the function of the network-side ML model is to decompress the output received from the UE.

Furthermore, the ML model can be applied to positioning, in which case the input may be a channel impulse related to a temporal reference point (typically a transmission point (TP)). The network's objective is to detect multiple distinct peaks in the impulse response that reflect the multipath experienced by the radio signal reaching the UE. Another positioning method involves inputting multiple sets of measurement results into the ML network and deriving an estimated position of the UE based on these results.

Other ML models are those that assist in channel estimation or interference estimation for channel estimation in the UE. Channel estimation may, for example, be about a physical downlink shared channel (PDSCH) and may be associated with a specific set of reference signal patterns transmitted from the network to the UE. The ML model is part of the receiver chain within the UE and may not be directly visible within the reference signal patterns configured/scheduled for use between the network and the UE. Other examples of ML models for CSI estimation predict appropriate CQI, PMI, RI, CRI (CSI-RS resource indicator) or similar values into the future. "In the future" may refer to a specific slot at a future point in time, or it may refer to a number of slots after the UE has made its last measurement.

A network node may be one of the following: a general-purpose network node (gNB) base station unit within a base station that handles at least some of the operations described above; a relay node; a core network node; a core network node that handles at least some of the operations described above; a device that supports device-to-device (D2D) communication; a location management function (LMF); or another type of location server.

In the use cases described here, the ML-based features reside at least partially in the UE. In some use cases, the ML-based features may be based on multiple ML models deployed on the UE side (e.g., an ML model located on the UE side for RX beam prediction). In other use cases, the ML-based features are based on a single ML model divided into two parts, one located in the UE and the other in the network node (e.g., AE-based CSI feedback/reporting). In yet another use case, the ML-based features are based on multiple ML models, some of which reside in the UE and the remainder in the network (e.g., in ML-based beam pair prediction between a network node and a UE, an ML model is located in the network node for TX beam prediction, and other ML models are located in the UE for RX beam prediction).

If performance drift is detected in an ML model, one option is to start a new data set and retain the ML model. However, retaining such data sets and models can be time-consuming. Depending on the capabilities of the UE, online model retention may not be practical.

When an ML model is used for critical functionality, it is crucial to ensure that the robustness and resilience of that functionality will not be affected if the ML model malfunctions. If performance issues with the active ML model associated with that critical functionality are detected or anticipated, prompt action is necessary.

The specific embodiments described herein enable a UE operating with at least one ML-based feature for a critical functionality to rapidly switch to a backup feature for that functionality when a performance issue in the active ML model associated with that critical functionality is detected or predicted.

A preliminary feature may be a feature with capabilities equivalent to or less than those of an ML-based feature. A preliminary feature may be based on a classic, non-ML-based algorithm. For example, considering the use case of AE-based CSI feedback/reporting, the functionality is CSI feedback/reporting, one ML-based feature for this functionality may be AE-based CSI feedback/reporting (dual-sided ML algorithm), and one preliminary feature may be a legacy CSI reporting type (e.g., Type 2 codebook-based CSI reporting, Type 2 codebook-based CSI reporting, or Type 1 single-panel-based CSI reporting).

In some embodiments, the preliminary features may have higher capabilities than the ML-based features, however, such preliminary features are not preferred for other reasons, including higher complexity, longer processing delays, higher power consumption, and excessive consumption of time/frequency resources. Generally, the preliminary features satisfy equivalent functionality to the ML-based features, but are not preferred compared to ML-based alternatives.

What constitutes higher capability can depend on the function. For example, regarding CSI, higher capability might refer to more accurate CSI feedback (including subband selection, RI, PMI, and MCS). Regarding beam management, higher capability might refer to greater accuracy in identifying the best candidate beam. Regarding positioning, higher capability might refer to more accurate estimation of the UE's position.

While the specific examples focus on embodiments where the preliminary features are classical non-ML-based algorithms, in some embodiments, the preliminary features may also be ML-based.

In one example, the UE can support at least two ML models: a first ML model that is a generalized model usable in a wide range of deployments (e.g., indoor and outdoor, dense urban and rural, high mobility and low mobility); and a second ML model that is a specialized model trained to perform best for a specific deployment (e.g., an indoor factory). In this case, when the UE is deployed in the trained environment, the first ML model may be used as a preliminary feature, while the second model is activated as a preferred feature. Generally, one ML model may be more basic and used as a preliminary feature, while another ML model may be more sophisticated and used as a preferred model unless it is deemed inappropriate, for example, by detecting excessive errors during the monitoring period.

In other examples, the two ML models described above may be different versions or models/algorithms for the same functionality, and this should be considered independently of cases where one is more generalized than the other. These two ML models are identified in such cases by their model ID or model version. They may both support CSI reporting, for example, but their reporting resolution or detail may still differ. Similar aspects may be generalized so that the two ML models support only a subset of features or a lower resolution than the other.

In other examples, the UE can support at least two ML models, each using different inputs and/or outputs. In some embodiments, the first ML model is equivalent to a classical non-ML-based algorithm in terms of algorithm inputs and outputs; that is, the first ML model requires no interface changes in terms of signaling, configuration, measurement, reporting, etc. Therefore, the functionality can be equally "black-boxed" with either the classical algorithm or the first ML model, and the UE does not need to inform (and the network nodes do not need to be aware of) whether it is running the classical algorithm or the first ML model. This first ML model can be used as a preliminary feature. The second ML model requires explicit coordination between the network node and the UE to satisfy a more advanced algorithm, and this explicit coordination is reflected in changes to the Uu interface compared to the classical algorithm, including different RS configurations, different measurement modes, and different reporting from the UE.

Some embodiments include UE Capability Indication. To support the UE's switching from a critical functionality to a secondary functionality, the UE may support a combination of ML-based and secondary features for that functionality.

In some embodiments, a UE capable of operating at least one ML-based feature for a certain functionality is required to also support at least a preliminary feature for that functionality.

The requirement may be explicitly defined as part of the UE capability parameters in the specification. For example, the UE capability parameters in the specification may explicitly state that a UE supporting ML-based feature X must also support a preliminary feature Y for the associated functionality. The UE can then point to this capability information to network nodes using the various methods described below.

In some embodiments, the UE, in its report of capabilities, refers to its ability to support a combination of at least one ML-based feature and at least one preliminary feature relating to the associated functionality.

In some embodiments, a UE capable of operating at least one ML-based feature associated with a certain functionality sends a message to network nodes indicating its ability to support a combination of at least one ML-based feature and at least one preliminary feature for the associated functionality.

In some embodiments, the above message indicating its ability to support a combination of at least one ML-based feature and at least one preliminary feature for the associated functionality is (part of) the UE capability parameters associated with the functionality.

In some embodiments, the above message explicitly indicates that a UE supporting a certain ML-based feature also supports preliminary features for the associated functionality.

In some embodiments, a UE indicates its capability to support at least one combination of ML-based features in its capability report, and its support for at least one preliminary feature of the associated functionality that is not explicitly declared as capability. The network may require preliminary functionality for many UEs, regardless of their capabilities. For example, a UE may declare capability for ML-based demodulated reference signal (DMRS) channel estimation. This may take the form of supporting multiple different DMRS patterns or multiple different receiver requirements for a particular DMRS pattern. Furthermore, all UEs may also implement traditional non-ML channel estimation, and its use may be required by the network.

For example, regarding the functionality of codebook-based CSI feedback/reporting, the UE capability parameter codebookComboParametersAddition-r16 was incorporated in NR release 16 3GPP TS 38.306 v17.0.0, which indicates that UE supports complex codebook combinations, as shown in the table below.

For CSI feedback/reporting use cases, a message indicating a UE's ability to support a combination of ML-based features (e.g., ML-based CSI feedback/reporting) and at least one preliminary feature (e.g., Type 1 single panel) may be defined by a similar UE capability parameter, e.g., codebookComboParametersAddition-r18, with a new entry {Type 1 Single Panel, Type 3}, where Type 3 represents the ML-based CSI feedback feature. For more advanced UEs, new entries may be added to represent more than two codebook type combinations, e.g., {Type 1 Single Panel, Type 2, Type 3}.

In some embodiments, the above message indicating the UE's ability to support a combination of at least one ML-based feature and at least one preliminary feature regarding the functionality of CSI reporting is (part of) the UE capability parameter. The UE capability parameter includes at least one entry for a composite codebook combination in which a certain codebook type is associated with an ML-based feature.

In some embodiments, the above message may support different combinations of at least one ML-based feature and at least one preliminary feature between FDD and TDD, and/or between FR1 and FR2 (or other spectral ranges), multiple feature sets, and/or multiple different bands.

In some embodiments, when a UE activates/switches on/registers at least one ML model for a given ML-based feature, it may transmit information about that ML-based feature (e.g., the ML model ID) to the network node, and in addition, it may also transmit any preliminary features associated with that ML-based feature.

The message containing information about the ML-based features and the message containing the preliminary features associated with those ML-based features may be the same message or different messages.

The UE may activate/switch on/register the ML model and instruct network nodes to perform such actions, for example, by initiating a random access procedure or by sending an RRC message or MAC CE message. If the information payload size is small, the instructions may be given using the transmission of uplink control information (UCI) (e.g., the UE encodes the action as part of the UCI and sends it to the gNB), or using the transmission of sidelink control information (SCI) (e.g., the UE encodes the action as part of the SCI and sends it to other UEs).

In some embodiments, the above message is sent when the UE activates/switches on/registers at least one ML model associated with an ML-based feature.

In some embodiments, the above message, which indicates its ability to support a combination of at least one ML-based feature and at least one preliminary feature regarding the associated functionality, is an RRC message, MAC CE Msg1, MsgA, Msg3, a combination of Msg1 and Msg3, UCI, or SCI.

In some embodiments, a UE indication of its ability to support a combination of at least one ML-based feature and at least one preliminary feature for the same functionality includes an indication that those ML and preliminary features may be executed simultaneously. Alternatively, the UE may indicate that they may be executed one at a time rather than simultaneously.

Some embodiments include fallback of ML-based features supported by network nodes. For example, the UE may be instructed by the network to perform fallback/switching of ML-based features.

In some embodiments, when a UE reports its ability to perform simultaneous execution, upon receiving the UE's capability information, the network node may send a first configuration message instructing the UE to simultaneously execute/operate the ML-based feature and its associated preliminary feature. The outputs of both features (the ML-based feature and the preliminary feature) may be used by the network node to monitor or predict the performance of the ML-based feature using instantaneous or short-term comparisons.

To provide simultaneous feedback to network nodes regarding the above model and preliminary outputs, the UE may be configured with special reporting modes and reserved reporting resources, for example, such that some relevant reporting procedure is repeated twice, once for the ML model features and preliminary features. Alternatively, the reporting may be configured so that the ML-based and preliminary-based outputs are signaled to the network according to a predetermined pattern, such as an alternating pattern. Parallel execution of preliminary operations may be initiated at a low duty cycle, such as 5% of the total operation time, during which time the ML features may be initiated independently for the majority of the time.

In some embodiments, if the UE indicates a lack of ability to perform simultaneous execution, the UE may be configured to operate using, for example, ML and preliminary features alternately, and performance monitoring may be performed by comparing the two operating modes over a long period. The duration of ML-based and preliminary activity may be asymmetric/uneven, such that the UE operates in ML mode for most of the time if no performance problems are detected. In some embodiments, network nodes may perform performance monitoring of ML features based on comparison with reference performance of high-level KPIs (key performance indicators), such as typical TP detection, SINR, and serving beam selection.

Upon detection or prediction of a performance failure in at least one ML-based feature for an associated functionality, the network node sends a second configuration message instructing the UE to deactivate/stop/switch off the ML-based feature for that associated functionality and activate/switch on a backup feature.

Figure 2 is a flowchart illustrating an example of ML-based feature fallback supported by a network node. A specific embodiment may include at least some of the following steps. The order of some steps may be rearranged, and some steps may be optional.

Step 1: The UE (for example, UE 200, described in more detail below with respect to Figure 4) sends a message to a network node (for example, network node 300, described in more detail below with respect to Figure 4) indicating the UE's ability to support a combination of at least one ML-based feature and at least one preliminary feature for a certain functionality. The network node receives a message from the UE indicating the UE's ability to support a combination of at least one ML-based feature and at least one preliminary feature for a certain functionality.

Step 2 [Optional]: Upon receiving capability information from the UE, the network node sends a first configuration message instructing the UE to simultaneously execute/operate at least the ML-based features and their associated preliminary features for the associated functionality. Upon receiving the message, the UE simultaneously executes/operates the configured ML-based features and preliminary features for the associated functionality.

Step 3 [Optional]: The network node uses the outputs of the ML-based features and preliminary features to monitor or predict the performance of the ML-based features.

Step 4: The network node detects or predicts a performance failure in at least one ML-based feature related to the associated functionality described above.

Step 5: The network node sends a second configuration message instructing the UE to deactivate/stop/switch off the ML-based feature with performance issues and activate/switch on the associated backup feature. In response to the second message, the UE deactivates/stops/switches off the specified ML-based feature with performance issues and activates/switches on the associated backup feature.

Step 5 [Optional]: The network node deactivates/stops/switches off the associated ML models on the network side for at least the ML-based features to be deactivated, in cases where the ML-based feature is based on an ML model that is divided into two parts, one part of which is located in the UE and the other part in the network, or in cases where the ML-based feature is based on multiple ML models, with part of the model located in the UE and the rest in the network.

Step 6 [Optional]: The network node sends a reconciled configuration and/or scheduling message to the UE. For example, the reconciled configuration and/or scheduling message may include an updated reference signal resource configuration for the UE's measurements and/or an updated CSI reporting configuration for the UE to report the CSI using preliminary features.

Some embodiments include autonomous fallback of ML-based features by the UE, which reports its actions to network nodes. In some use cases involving more advanced UEs, the UE can monitor the ML model performance of one or more ML-based features and independently detect/predict issues with those features. In some embodiments, the UE autonomously performs fallback/switching of ML-based features and points this information to network nodes.

Figure 3 is a flowchart illustrating an example of autonomous ML-based feature fallback by the UE and its reporting to network nodes. A specific embodiment may include at least some of the following steps. The order of some steps may be rearranged, and some steps may be optional.

Step 1: The UE (for example, UE200, described in more detail below with respect to Figure 4) sends a message to a network node (for example, network node 300, described in more detail below with respect to Figure 4) indicating the UE's ability to support a combination of at least one ML-based feature and at least one preliminary feature for a certain functionality. The network node receives a message from the UE indicating the UE's ability to support a combination of at least one ML-based feature and at least one preliminary feature for a certain functionality.

Step 2: The network constitutes at least one ML-based feature.

Step 3: The UE monitors the ML model performance of one or more ML-based features.

Step 4: The UE detects or predicts performance failures in at least one ML-based feature for the associated functionality. This is similar to the network-side performance monitoring approach. In some embodiments, the UE may run/operate the ML-based feature and its associated preliminary feature concurrently, if concurrent execution is possible. The UE may use the outputs of both features (ML-based feature and preliminary feature) to monitor or predict the performance of the ML-based feature using instantaneous or short-term comparisons. Parallel operation may be initiated at a low duty cycle, for example, 5% of the total operation time. Concurrent execution does not necessarily mean strictly simultaneous execution; rather, it means that the same or very similar input data is used for both features so that performance can be compared between the ML-based feature and the preliminary feature, and therefore the original data may need to be acquired simultaneously or at very close time points.

For example, consider a use case where the above functionality relates to the construction of CSI reports. The same CSI-RS resource set/index may act as source data for both ML-based and preliminary features, but the actual data processing processes for both features do not need to occur simultaneously. Rather, they can be temporally dispersed for subsequent comparison of results or reporting to gNB.

In some embodiments, if the UE lacks the capability for simultaneous execution, the UE may operate using ML and preliminary features alternately, and performance monitoring may be performed by long-term comparison of the two operating modes. The duration of ML-based and preliminary activity may be asymmetric/uneven, such that the UE operates in ML mode for most of the time if no performance problems are detected. In some embodiments, the UE may perform performance monitoring of ML features based on comparison with reference performance of high-level KPIs, such as typical TP detection, SINR, and serving beam quality.

Step 5: The UE autonomously deactivates/stops at least the detected ML-based features that have performance issues, and activates/switches on the associated backup features.

Step 6: The UE indicates to the network nodes the fallback/switching information for the above features (e.g., deactivated/stopped/switched-off ML-based features).

Step 7 [Optional]: The network node deactivates/stops/switches off the associated ML models on the network side for at least the ML-based features to be deactivated, in cases where the ML-based feature is based on an ML model that is divided into two parts, one part of which is located in the UE and the other part in the network, or in cases where the ML-based feature is based on multiple ML models, with part of the model located in the UE and the rest in the network.

Step 8 [Optional]: The network node sends a reconciled configuration and/or scheduling message to the UE. For example, the reconciled configuration and/or scheduling message may include an updated reference signal resource configuration for the UE's measurements and/or an updated CSI reporting configuration for the UE to report the CSI using preliminary features.

While the example described here primarily focuses on reporting UE capabilities over the Uu interface, the same methodology may be applied to support ML-based feature fallback using signaling over the PC5 interface between different UEs.

Figure 4 shows an example of a communication system 100 according to several embodiments. In this example, the communication system 100 includes a telecommunications network 102 which includes an access network 104, such as a wireless access network (RAN), and a core network 106, which includes one or more core network nodes 108. The access network 104 includes one or more access network nodes, such as network nodes 110a and 110b (one or more of which may generally be referred to as network node 110), or some other similar Third Generation Partnership Project (3GPP) access node or non-3GPP access point. The network nodes 110 facilitate direct or indirect connections of user equipment (UEs), such as by connecting UEs 112a, 112b, 112c, and 112d (one or more of which may generally be referred to as UE 1112) to the core network 106 over one or more wireless connections.

Exemplary wireless communication on a wireless connection includes transmitting and/or receiving wireless signals using electromagnetic waves, radio waves, infrared waves, and/or other types of signals suitable for carrying information without using wires, cables, or other physical conductors. Furthermore, in various embodiments, the communication system 100 may include any number of wired or wireless networks, network nodes, UEs, and/or any other components or systems that can facilitate or participate in the communication of data and/or signals, regardless of whether the connection is wired or wireless. The communication system 100 may include and/or interface with any type of communication, telecommunications, data, cellular, wireless network, and/or other similar types of systems.

UE 112 may be any of a broad range of communication devices, including wireless devices that are arranged, configured, and/or capable of communicating wirelessly with network node 110 and other communication devices. Similarly, network node 110 is arranged, capable, configured, and/or capable of communicating directly or indirectly with UE 112 and/or other network nodes or devices within telecommunications network 102, in order to enable and/or provide network access, such as wireless network access, and/or to perform other functions, such as management within telecommunications network 102.

In the illustrated example, the core network 106 connects network nodes 110 to one or more hosts, such as host 116. These connections may be direct or indirect, via one or more intermediate networks or devices. In other examples, network nodes may be directly connected to hosts. The core network 106 includes one or more core network nodes (e.g., core network node 108) structured with hardware and software components. The functions of these components may be substantially the same as those described for the UE, network nodes, and/or hosts, and therefore those descriptions are generally applicable to the corresponding components of core network node 108. An exemplary core network node includes one or more of the following functions: Mobile Switching Center (MSC), Mobility Management Entity (MME), Home Subscriber Server (HSS), Access and Mobility Management Function (AMF), Session Management Function (SMF), Authentication Server Function (AUSF), Subscription Identifier Decryption Function (SIDF), Unified Data Management (UDM), Security Edge Protected Proxy (SEPP), Network Exposure Function (NEF), and/or User Plane Function (UPF).

Host 116 may be owned by or under the control of a service provider other than the operator, or a provider of the access network 104 and/or the telecommunications network 102, and may be operated by or on behalf of such service provider. Host 116 may host a variety of applications and provide one or more services. Examples of such applications include live and pre-recorded audio/video content, data acquisition services such as the acquisition and editing of data on various ambient conditions detected by multiple UEs, analytical functionality, social media, functions for controlling or otherwise interacting with remote devices, functions for alarm and monitoring centers, or any other such functions performed by a server.

Overall, the communication system 100 in Figure 4 enables connectivity between the UE, network nodes, and hosts. In this sense, the communication system may be configured to operate according to predefined rules or procedures, such as certain standards, including, but not limited to, the following: GSM (Global System for Mobile Communications), UMTS (Universal Mobile Telecommunications System), Long-Term Evolution (LTE), and/or other suitable 2G, 3G, 4G, 5G standards, or any applicable future-generation standards (e.g., 6G), WLAN (wireless local area network) standards such as the IEEE (Institute of Electrical and Electronics Engineers) 802.11 standard (Wi-Fi), and/or any other suitable wireless communication standards such as WiMax (Worldwide Interoperability for Microwave Access), Bluetooth, Z-Wave, NFC (Near Field Communication) ZigBee, LiFi, and/or any LPWAN (low-power wide-area network) standards such as LoRa and Sigfox.

In some examples, the telecommunications network 102 is a cellular network implementing functions standardized by 3GPP. Therefore, the telecommunications network 102 may support network slicing to provide various logical networks to various devices connected to the telecommunications network 102. For example, the telecommunications network 102 may provide ultra-high reliability low-latency communications (URLLLC) services to some UEs while providing extended mobile broadband (eMBB) services to other UEs, and may also provide massive machine type communications (mMTC)/massive IoT services to further UEs.

In some examples, UE 112 is configured to transmit and/or receive information without direct human interaction. For example, the UE may be designed to transmit information to the access network 104 on a predetermined schedule, triggered by internal or external events, or in response to a request from the access network 104. Additionally, the UE may be configured to operate in single, multi-RAT, or multi-standard modes. For example, the UE may be configured and operate for any one or a combination of Wi-Fi, NR (New Radio), and LTE, i.e., for multi-radio dual connectivity (MR-DC) such as E-UTRAN (Evolved-UMTS Terrestrial Radio Access Network) New Radio-Dual Connectivity (EN-DC).

In the above example, the hub 114 communicates with the access network 104 to facilitate indirect communication between one or more UEs (e.g., UE 112c and/or 112d) and a network node (e.g., network node 110b). In some examples, the hub 114 may be a controller, router, content source and analytics, or any other communication device described herein with respect to the UE. For example, the hub 114 may be a broadband router that enables the UE to access the core network 106. In another example, the hub 114 may be a controller that sends commands or instructions to one or more actuators within the UE. Commands or instructions may be received from the UE or network node 110, or accepted by executable code, scripts, processes, or other instructions within the hub 114. In yet another example, the hub 114 may be a data controller that acts as temporary storage for the UE's data, and in some embodiments, it may perform analysis or other processing of that data. In yet another example, the hub 114 may be a content source. For example, with respect to a UE that is a VR headset, display, loudspeaker, or other media delivery device, the hub 114 may acquire media or data related to VR assets, video, audio, or other sensory information via network nodes, in which case the hub 114 provides it to the UE either directly, after local processing, and/or after adding additional local content. In another example, the hub 114 acts as a proxy server or orchestrator for the UE, particularly when one or more of the UEs are low-energy IoT devices.

Hub 114 may have a steady/permanent or intermittent connection to network node 110b. Furthermore, hub 114 may enable different communication methods and/or schedules between hub 114 and UEs (UE 112c and/or 112d), and between hub 114 and the core network 106. In other examples, hub 114 is connected to the core network 106 and/or one or more UEs via a wired connection. Additionally, hub 114 may be configured to connect to an M2M service provider on the access network 104 and/or to other UEs via a direct connection. In some scenarios, a UE may establish a wireless connection with network node 110 while still being connected via hub 114 via a wired or wireless connection. In some embodiments, hub 114 may be a dedicated hub, i.e., a hub whose primary function is to route communication between UEs and network node 110b. In other embodiments, the hub 114 may be a non-dedicated hub, i.e., a device capable of routing communication between the UE and the network node 110b, but also capable of acting as the source and/or destination of communication for some data channel.

Figure 5 shows several embodiments of the UE200. As used herein, UE refers to a device capable of, configured, deployed, and/or operating wirelessly with network nodes and/or other UEs. Examples of UEs include, but are not limited to, smartphones, mobile phones, cell phones, VoIP (Voice over IP) phones, wireless local loop phones, desktop computers, personal digital assistants (PDAs), wireless cameras, game consoles or devices, music storage devices, playback appliances, wearable terminal devices, wireless endpoints, mobile stations, tablets, laptops, laptop embedded devices (LEEs), laptop-based devices (LMEs), smart devices, wireless customer premises equipment (CPEs), and vehicle-mounted or vehicle-embedded/integrated wireless devices. Other examples include any UE identified by the Third Generation Partnership Project (3GPP), including Narrowband Internet of Things (NB-IoT) UEs, Machine Type Communications (MTC) UEs, and/or Enhanced MTC (eMTC) UEs.

The UE may support device-to-device (D2D) communication, for example, by implementing 3GPP standards for side-link communication, dedicated short-range communication (DSRC), vehicle-to-vehicle (V2V), vehicle-to-infrastructure (V2I), or vehicle-to-everything (V2E). In other examples, the UE does not necessarily have a user in the sense of a human user who owns and/or operates the device in question. Instead, the UE may represent a device (e.g., a smart sprinkler controller) that is intended for sale to or operation by a human user, but may not be associated with a specific human user, at least initially. Alternatively, the UE may represent a device (e.g., a smart power meter) that is not intended for sale to or operation by an end user, but may be associated with or operated for the benefit of a user.

The UE 200 includes a processing circuit 202, a power supply 208, a memory 210, a communication interface 212, and/or any other components, or any combination thereof, operably connected to the input/output interface 206 via the bus 204. A given UE may utilize all or a subset of the components shown in Figure 5. The level of integration between components may vary between one UE and another. Furthermore, a given UE may include multiple instances of components, such as multiple processors, memories, transceivers, transmitters, receivers, etc.

The processing circuit 202 is configured to process instruction sets and data, and may implement some sequential state machine capable of executing instruction sets stored in memory 210 as machine-readable computer programs. The processing circuit 202 may be implemented as one or more hardware-implemented state machines (e.g., discrete logic, field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), etc.), programmable logic with appropriate firmware, one or more stored computer programs, a general-purpose processor such as a microprocessor or digital signal processor (DSP) with appropriate software, or any combination of the above. For example, the processing circuit 202 may include multiple central processing units (CPUs).

In the above example, the input/output interface 206 may be configured to provide an input device, an output device, or one or more interfaces to one or more input/output devices. Examples of output devices include speakers, sound cards, video cards, displays, monitors, printers, actuators, emitters, smart cards, other output devices, or any combination thereof. Input devices may allow a user to capture information to the UE200. Examples of input devices include touch-sensitive or presence-sensitive displays, cameras (e.g., digital cameras, digital video cameras, webcams, etc.), microphones, sensors, mice, trackballs, directional pads, trackpads, scroll wheels, and smart cards. Presence-sensitive displays may include capacitive or resistive touch sensors for sensing user input. Sensors may include, for example, accelerometers, gyroscopes, tilt sensors, force sensors, magnetometers, light sensors, proximity sensors, biometric sensors, or any combination thereof. Output devices may use the same type of interface port as input devices. For example, a Universal Serial Bus (USB) port may be used to provide input and output devices.

In some embodiments, the power supply 208 is structured as a battery or battery pack. Other types of power sources, such as an external power source (e.g., an electrical outlet), a solar power device, or a battery, may also be used. The power supply 208 may further include a power circuit for transmitting power from the power supply 208 itself and/or an external power source to various parts of the UE 200 via an interface such as an input circuit or a power cable. Power transmission may, for example, be for charging the power supply 208. The power circuit may perform some shaping, conversion, or other modification of the power from the power supply 208 to suit the power of each component of the UE 200 to which it is supplied.

Memory 210 may be random access memory (RAM), read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electro-erasable programmable read-only memory (EEPROM), magnetic disks, optical disks, hard disks, removable cartridges, and flash drives, or may be configured to include such memory. In one example, memory 210 includes one or more application programs 214, such as an operating system, a web browser application, a widget, a gadget engine, or other application, and corresponding data 216. Memory 210 may store any of a wide variety of operating systems or combinations of multiple operating systems for use by UE200.

The memory 210 may be configured to include multiple physical drive units such as RAID (Redundant Array of Independent Disks), flash memory, USB flash drive, external hard disk drive, thumb drive, pen drive, key drive, HD-DVD (High-Density Digital Versatile Disc), optical disc drive, internal hard disk drive, Blu-ray optical disc drive, HDDS (Holographic Digital Data Storage) optical disc drive, external mini DIMM (Dual In-Line Memory Module), SDRAM (Synchronous Dynamic Random Access Memory), external micro DIMM SDRAM, smart card memory such as a UICC (universal integrated circuit card) containing one or more SIMs (subscriber identity modules) such as USIM and/or ISIM, other memories, or any combination thereof. The UICC may be, for example, an embedded UICC (eUICC), an integrated UICC (iUICC), or a removable UICC commonly known as a "SIM card." The memory 210 may enable the UE 200 to access instruction sets and application programs stored in temporary or non-temporary storage media to offload or upload data. Product items, such as those utilizing communication systems, may be tangibly embodied as a device-readable storage medium or containing one, or within the memory 210 .

The processing circuit 202 may be configured to communicate with an access network or other network using a communication interface 212. The communication interface 212 may include one or more communication subsystems, and may include or be communicatively connected to an antenna 222. The communication interface 212 may include one or more transceivers used for communication, such as by communicating with one or more remote transceivers of other wirelessly communicable devices (e.g., network nodes in other UEs or access networks). Each transceiver may include a transmitter 218 and/or receiver 220 appropriate for providing network communication (e.g., optical, electrical, frequency-allocated, etc.). Furthermore, the transmitter 218 and receiver 220 may be connected to one or more antennas (e.g., antenna 222), and they may share circuit components, software, or firmware, or alternatively, be implemented separately.

In the illustrated embodiment, the communication functions of the communication interface 212 may include cellular communication, Wi-Fi communication, LPWAN communication, data communication, voice communication, multimedia communication, near-field communication such as Bluetooth, location-based communication such as the use of GPS (Global Positioning System) for location determination, other similar communication functions, or any combination thereof. Communication may be implemented in accordance with one or more communication protocols and/or standards such as IEEE 802.11, Code Division Multiple Access (CDMA), Wideband Code Division Multiple Access (WCDMA), GSM, LTE, New Radio (NR), UMTS, WiMax, Ethernet, TCP/IP (transmission control protocol/internet protocol), SONET (synchronous optical networking), ATM (Asynchronous Transfer Mode), QUIC, and HTTP (Hypertext Transfer Protocol).

Regardless of the sensor type, a UE may provide an output of data captured by its sensor to a network node via a wireless connection through its communication interface 212. The data captured by the UE's sensor may be communicated to a network node via another UE through a wireless connection. The output may be periodic (e.g., every 15 minutes when reporting measured temperature), random (e.g., to smooth out the load from reports from multiple sensors), triggered by an event (e.g., an alert is sent when moisture is detected), requested (e.g., a request initiated by a user), or a continuous stream (e.g., a feed of live patient video).

As another example, the UE may include actuators, motors, or switches associated with a communication interface configured to receive wireless input from a network node via a wireless connection. The state of the actuator, motor, or switch may change in response to the received wireless input. For example, the UE may include a motor that adjusts the control surface or rotor of a drone in flight according to the received input, or a robotic arm that performs a medical procedure according to the received input.

If a UE is in the form of an Internet of Things (IoT) device, it may be a device for use in one or more application domains, which include, but are not limited to, wearable technology in urban environments, augmented industrial applications, and healthcare. Non-exclusive examples of such IoT devices include connected refrigerators or freezers, TVs, connected lighting devices, electric meters, robotic vacuum cleaners, voice-controlled smart speakers, home security cameras, motion detectors, thermostats, smoke detectors, door/window sensors, flood/moisture sensors, electric door locks, connected doorbells, air conditioning systems such as heat pumps, autonomous vehicles, surveillance systems, climate monitoring devices, parking monitoring devices, vehicle charging stations, smartwatches, fitness trackers, head-mounted displays for augmented reality (AR) or virtual reality (VR), wearables for haptic or perceptual augmentation, watersplinters, animal or object tracking devices, sensors for monitoring plants or animals, industrial robots, unmanned aerial vehicles (UAVs), and any type of medical device, or devices incorporated therein, such as heart rate monitors or remotely controlled surgical robots. A UE in the form of an IoT device comprises, in addition to circuitry and/or software that depends on the intended application of the IoT device, other components such as those described in relation to the UE200 shown in Figure 5.

In another specific example, in an IoT scenario, the UE may represent a machine or other device that performs monitoring and/or measurement and transmits the results of such monitoring and/or measurement to other UEs and/or network nodes. In this case, the UE may be an M2M device, and in the context of 3GPP, it may be referred to as an MTC device. As one specific example, the UE may implement the 3GPP NB-IoT standard. In other scenarios, the UE may represent a passenger car, bus, truck, ship, or aircraft, or other equipment capable of monitoring and/or reporting its operational status or other functions associated with its operation.

In practice, any number of UEs may be used together for a single use case. For example, the first UE may be a drone or integrated into a drone, providing drone speed information (obtained through a speed sensor) to a second UE, which is a remote controller operating the drone. When the user makes changes from the remote controller, the first UE may adjust the drone's throttle (e.g., by controlling actuators) to increase or decrease the drone's speed. The first and/or second UEs may include more than one of the functionalities described above. For example, the UE may include sensors and actuators and handle data communication for both the speed sensor and the actuators.

Figure 6 shows network nodes 300 according to several embodiments. As used herein, a network node refers to a device that is capable of communicating directly or indirectly with other network nodes or devices within the UE and/or telecommunications network, and is configured, positioned, and/or operational in such a manner. Examples of network nodes include, but are not limited to, access points (APs) (e.g., radio access points) and base stations (BSs) (e.g., radio base stations, node B, evolved node B (eNB), and NR node B (gNB)).

Base stations may be categorized based on the amount of coverage they provide (or, in other words, their transmit power level), and therefore may be referred to as femto base stations, pico base stations, micro base stations, or macro base stations, depending on the amount of coverage they provide. A base station may also be a relay node or a relay donor node controlling a relay device. A network node may include one or all parts of a distributed radio base station, such as a centralized digital unit and/or a remote radio unit (RRU), sometimes called a remote radio head (RRH). Such a remote radio unit may or may not be integrated with an antenna, such as an antenna-integrated radio. Some parts of a distributed radio base station may be referred to as nodes within a distributed antenna system (DAS).

Other examples of network nodes include multi-transmitting point (multi-TRP) 5G access nodes, multi-standard radio (MSR) equipment such as MSR BS, network controllers such as radio network controllers (RNCs) or base station controllers (BSCs), base station transceivers (BTSs), transmit points, transmit nodes, multi-cell/multicast cooperative entities (MCEs), operation and maintenance (O&M) nodes, operation support system (OSS) nodes, self-organizing network (SON) nodes, and positioning nodes (e.g., including evolved serving mobile location centers (E-SMLCs) and/or drive test minimization (MDTs)).

The network node 300 includes a processing circuit 302, a memory 304, a communication interface 306, and a power supply 308. The network node 300 may consist of multiple physically distinct components (e.g., a node B component and an RNC component, or a BTS component and a BSC component), each of which may have its own respective components. In a scenario in which the network node 300 has multiple distinct components (e.g., BTS and BSC components), one or more of those distinct components may be shared among several network nodes. For example, a single RNC may control multiple node Bs. In such a scenario, each unique pair of node Bs and RNCs may, in some examples, be considered a single distinct network node. In some embodiments, the network node 300 may be configured to support multiple radio access technologies (RATs). In such embodiments, some components may be redundant (e.g., separate memories 304 for different RATs), and some components may be reused (e.g., the same antenna 310 may be shared by multiple different RATs). Furthermore, the network node 300 may include multiple sets of diverse exemplified components for various wireless technologies integrated into the network node 300, such as GSM, WCDMA, LTE, NR, Wi-Fi, Zigbee, Z-Wave, LoRaWAN, RFID (Radio Frequency Identification), or Bluetooth wireless technologies. These wireless technologies may be integrated into the same or different chips or sets of chips and other components within the network node 300.

The processing circuit 302 may include one or more combinations of microprocessors, controllers, microcontrollers, central processing units, digital signal processors, application-specific integrated circuits, field-programmable gate arrays, or other suitable computing devices, resources, or hardware, software, and/or coding logic, capable of operating independently or in conjunction with other network node 300 components such as memory 304 to provide the functionality of the network node 300.

In some embodiments, the processing circuit 302 includes a system-on-a-chip (SOC). In some embodiments, the processing circuit 302 includes one or more of the radio frequency (RF) transceiver circuit 312 and the baseband processing circuit 314. In some embodiments, the radio frequency (RF) transceiver circuit 312 and the baseband processing circuit 314 may reside on separate chips (or sets of chips), substrates, or units, such as a radio unit and a digital unit. In alternative embodiments, some or all of the RF transceiver circuit 312 and the baseband processing circuit 314 may reside on the same chip or set of chips, substrate, or unit.

Memory 304 may include, but is not limited to, any form of volatile or non-volatile computer-readable memory, including persistent storage, solid-state memory, remotely mounted memory, magnetic media, optical media, random-access memory (RAM), read-only memory (ROM), large storage media (e.g., hard disk), removable storage media (e.g., flash drive, compact disc (CD) or digital video disc (DVD)), and/or any other volatile or non-volatile non-temporary device-readable and/or computer-executable memory device, for storing information, data and/or instructions that can be used by the processing circuit 302. Memory 304 may store any suitable instructions, data or information, including applications, and/or other instructions, which are executable by the processing circuit 302 and available to the network node 300, including one or more computer programs, software, logic, rules, code, and tables. Memory 304 may also be used to store any calculation results produced by the processing circuit 302 and/or any data received via the interface 306. In some embodiments, the processing circuit 302 and the memory 304 are integrated.

The communication interface 306 is used in wired or wireless signaling and/or data transmission between network nodes, access networks, and/or UEs. As illustrated, the communication interface 306 includes, for example, a port/terminal 316 for sending and receiving data to and from the network over a wired connection. The communication interface 306 also includes a wireless front-end circuit 318, which is connected to or, in some embodiments, part of the antenna 310. The wireless front-end circuit 318 includes a filter 320 and an amplifier 322. The wireless front-end circuit 318 may be connected to the antenna 310 and the processing circuit 302. The wireless front-end circuit may be configured to adjust signals communicated between the antenna 310 and the processing circuit 302. The wireless front-end circuit 318 can receive digital data to be sent to other network nodes or UEs via the wireless connection. The wireless front-end circuit 318 can convert its digital data into a wireless signal with appropriate channel and bandwidth parameters using a combination of the filter 320 and/or the amplifier 322. The wireless signal can then be transmitted via the antenna 310. Similarly, when data is received, the antenna 310 collects the wireless signal, which can then be converted into digital data by the wireless front-end circuit 318. The digital data can then be passed to the processing circuit 302. In other embodiments, the communication interface may include different components and/or different combinations of components.

In one alternative embodiment, the network node 300 does not need to include a separate wireless front-end circuit 318; rather, the processing circuit 302 may include the wireless front-end circuit and be connected to the antenna 310. Similarly, in some embodiments, all or some of the RF transceiver circuits 312 are part of the communication interface 306. In yet another embodiment, the communication interface 306, as part of a wireless unit (not shown), includes one or more ports or terminals 316, a wireless front-end circuit 318, and RF transceiver circuits 312, and the communication interface 306 communicates with a baseband processing circuit 314, which is part of a digital unit (not shown).

Antenna 310 may include one or more antennas or antenna arrays configured to transmit and/or receive wireless signals. Antenna 310 may be connected to the wireless front-end circuit 318 and may be any type of antenna capable of wirelessly transmitting and receiving data and/or signals. In one embodiment, antenna 310 is separate from the network node 300 and is connectable to the network node 300 via an interface or port.

The antenna 310, communication interface 306, and/or processing circuit 302 may be configured to perform any receiving operations and/or acquisition operations described herein as being performed by a network node. Any information, data, and/or signals may be received from the UE, other network nodes, and/or any other network equipment. Similarly, the antenna 310, communication interface 306, and/or processing circuit 302 may be configured to perform any transmitting operations described herein as being performed by a network node. Any information, data, and/or signals may be transmitted to the UE, other network nodes, and/or any other network equipment.

The power supply 308 provides power to the various components of the network node 300 in a format suitable for each component (for example, at the voltage and current levels required for each component). The power supply 308 may include, or be connected to, a power management circuit for supplying power to the components of the network node 300 to perform the functions described herein. For example, the network node 300 may be connectable to an external power source (e.g., a power grid, an electrical outlet) via an input circuit or interface such as an electrical cable, thereby allowing the external power source to supply power to the power circuit of the power supply 308. As a further example, the power supply 308 may include a power source in the form of a battery or battery pack connected to or integrated into the power circuit. The battery may provide backup power in case of failure of the external power source.

Embodiments of the network node 300 may include additional components other than those shown in Figure 6 to provide a functional view of the network node, including any functionality necessary to support any of the functionalities described herein and/or any functionality necessary to support the subject matter described herein. For example, the network node 300 may include user interface equipment that enables the input of information to and output of information from the network node 300. This may enable users to perform diagnostic, maintenance, repair, and other management functions on the network node 300.

Figure 7 is a block diagram of a host 400 that may be an embodiment of host 116 in Figure 4, relating to the various perspectives described herein. Where used herein, host 400 may be, or include, a variety of hardware-aware and/or software, including standalone servers, blade servers, cloud-implemented servers, distributed servers, virtual machines, containers, or processing resources within a server farm. Host 400 can provide one or more services to one or more UEs.

The host 400 includes a processing circuit 402 operably connected to an input/output interface 406 via a bus 404, a network interface 408, a power supply 410, and memory 412. Other components may be included in other embodiments. The functions of these components may be substantially the same as those described for the devices in previous drawings such as Figures 3 and 4, and therefore, those descriptions are generally applicable to the corresponding components of the host 400.

Memory 412 may include one or more computer programs, including one or more host application programs 414, and data 416, which may include user data, such as data generated by a UE for the host 400 or data generated by the host 400 for a UE. Embodiments of the host 400 may utilize only a subset or all of the illustrated components. The host application program 414 may be implemented in a container-based architecture and may provide support for video codecs (VVC (Versatile Video Coding), HEVC (High Efficiency Video Coding), AVC (Advanced Video Coding), MPEG, VP9) and audio codecs (e.g., FLAC, AAC (Advanced Audio Coding), MPEG, G.711), including transcoding for multiple different classes, types, or implementations of UEs (e.g., handsets, desktop computers, wearable display systems, head-up display systems). Furthermore, the host application program 414 may provide user authentication and license checks, and may periodically report health, route, and content availability to central nodes such as devices within or at the edge of the core network. Therefore, host 400 may select and/or point to different hosts for over-the-top services for the UE. The host application program 414 may support a variety of protocols, including HLS (HTTP Live Streaming), RTMP (Real-Time Messaging Protocol), RTSP (Real-Time Streaming Protocol), and MPEG-DASH (Dynamic Adaptive Streaming over HTTP).

Figure 8 is a block diagram showing a virtualization environment 500 in which functions implemented by several embodiments can be virtualized. In this context, the virtualization means for generating a virtual version of a device or apparatus may include a virtualization hardware platform, storage devices, and networking resources. As used herein, virtualization can be applied to any of the devices or components thereof described herein, and relates to implementation examples in which at least some of its functionality is implemented as one or more virtual components. Some or all of the functions described herein may be implemented as virtual components executed by one or more virtual machines (VMs) implemented within one or more virtual environments 500 hosted by one or more hardware nodes, such as network nodes, UEs, core network nodes, or hardware computing devices acting as hosts. Furthermore, in embodiments in which the virtual node does not require radio connectivity (e.g., a core network node or host), the node as a whole may be virtualized.

Application 502 (which may alternatively be referred to as a software instance, virtual appliance, network function, virtual node, virtual network function, etc.) runs in a virtualized environment 500 to implement some of the features, functions, and/or benefits of some of the embodiments disclosed herein.

Hardware 504 includes a processing circuit, a memory for storing software and/or instruction sets executable by the hardware processing circuit, and/or hardware devices as described herein, such as network interfaces and input/output interfaces. The software is executed by the processing circuit to instantiate one or more virtualization layers 506 (also referred to as a hypervisor or virtual machine monitor (VMM)), provide VMs 508a and 508b (one or more of which may be collectively referred to as VM 508), and/or perform any of the functions, features, and/or benefits described herein in relation to some of the embodiments described herein. The virtualization layer 506 may present a virtual operating platform that appears to the virtual machine 508 as networking hardware.

VM508 includes virtual processing, virtual memory, virtual networking or interfaces, and virtual storage, and may be executed by the corresponding virtualization layer 506. Various embodiments of instances of the virtual appliance 502 may be implemented in one or more of the VM508, and such implementation may be carried out in various ways. Hardware virtualization is referred to as network function virtualization (NFV) in several contexts. NFV can be used to consolidate many types of network equipment into industry-standard, high-capacity server hardware, physical switches, and physical storage that can reside within data centers and customer premises equipment.

In the context of NFV, VM 508 may be a software implementation of a physical machine that runs a program as if it were running on a physical, non-virtualized machine. Each VM 508, and the portion of hardware 504 running the VM, forms a separate virtual network element, whether it is dedicated hardware for that VM or/or hardware shared by that VM with other VMs. Also in the context of NFV, the virtual network function is responsible for handling the specific network functions running in one or more VMs 508 at the highest level of hardware 504, and corresponds to application 502.

Hardware 504 may be implemented in a standalone network node with general or specific components. Hardware 504 may implement some functions through virtualization. Alternatively, hardware 504 may be part of a larger hardware cluster (such as one in a data center or CPE) where multiple hardware nodes cooperate and are managed via management and orchestration 510, which, among other things, oversees the lifecycle management of application 502. In some embodiments, hardware 504 is connected to one or more radio units, each including one or more transmitters and one or more receivers, which can be connected to one or more antennas. The radio units may communicate directly with other hardware nodes via one or more suitable network interfaces, or they may be used in combination with virtual components to provide radio capabilities to virtual nodes, such as radio access nodes or base stations. In some embodiments, some signaling can be provided in conjunction with the use of a control system 512, which may alternatively be used for communication between hardware nodes and radio units.

Figure 9 shows a communication diagram of a host computer 602 communicating with a UE 606 via a network node 604 over a partially wireless connection according to several embodiments. Exemplary implementations of various embodiments of the UEs (UE 112a in Figure 4 and/or UE 200 in Figure 5), network nodes (network node 110a in Figure 4 and/or network node 300 in Figure 6), and hosts (host 116 in Figure 4 and/or host 400 in Figure 7) discussed in the preceding paragraphs will now be described with reference to Figure 9.

Similar to host 400, embodiments of host 602 include hardware such as a communication interface, processing circuitry, and memory. Host 602 further includes software stored within or accessible by host 602, which is executable by the processing circuitry. This software may include a host application capable of operating to provide services to remote users, such as UE 606, connected via an over-the-top (OTT) connection 650 extending between UE 606 and host computer 602. While providing services to remote users, the host application may provide user data transmitted using the OTT connection 650.

Network node 604 includes hardware that enables communication with host 602 and UE 606. Connection 660 is direct or may traverse one or more other intermediate networks, such as a core network (like core network 106 in Figure 4) and/or one or more public, private, or hosted networks. For example, the intermediate network may be a backbone network or the internet.

UE606 includes software stored within or accessible by UE606, and executable by the UE's processing circuitry. This software, with the support of host 602, may operate to provide services to human or non-human users via UE606, including client applications such as web browsers or service provider-specific "apps." On host 602, the host application to be executed may communicate with the client application to be executed via an OTT connection 650 terminating at UE606 and host 602. During service provision to a user, the UE's client application may receive request data from the host's host application and provide user data in response to that request data. The OTT connection 650 may transport both request data and user data. The UE's client application may interact with the user to generate user data that it provides to the host application via the OTT connection 650.

The OTT connection 650 extends via connection 660 between host 602 and network node 604, and via wireless connection 670 between network node 604 and UE 606, potentially providing connectivity between host 602 and UE 606. To illustrate the communication between host 602 and UE 606 via network node 604 without explicit reference to any intermediate devices or the precise routing of messages through those devices, the connections 660 and wireless connection 670, which may be provided by the OTT connection 650, are depicted abstractly.

As an example of transmitting data over the OTT connection 650, in step 608, host 602 provides user data, which may be done by running a host application. In some embodiments, the user data is associated with a specific human user interacting with UE 606. In other embodiments, the user data is associated with UE 606 sharing data with host 602 without explicit human interaction. In step 610, host 602 initiates a transmission to UE 606 carrying the user data. Host 602 may initiate such a transmission in response to a request transmitted by UE 606. Such a request may be triggered by human interaction with UE 606 or by the operation of a client application running on UE 606. The transmission may pass through network node 604 in accordance with the teachings of the embodiments described through this disclosure. Accordingly, in step 612, the network node 604 transmits the user data carried in the transmission initiated by host 602 to UE 606, in accordance with the teachings of the embodiments described through this disclosure. In step 614, UE 606 receives the user data carried in the transmission, which may be done by a client application running on UE 606 associated with a host application running on host 602.

In some examples, UE606 executes a client application, thereby providing user data destined for host 602. The user data may be provided as a reaction or response to receiving data from host 602. Accordingly, in step 616, UE606 may provide user data, which may be done by executing a client application. While providing user data, the client application may further consider user input received from the user via the input/output interface of UE606. Regardless of the specific manner in which the user data is provided, in step 618, UE606 initiates transmission of the user data to host 602 via network node 604. In step 620, in accordance with the teachings of the embodiments described through this disclosure, network node 604 receives user data from UE606 and initiates transmission of the received user data to host 602. In step 622, host 602 receives the user data carried in the transmission initiated by UE606.

One or more of the various embodiments improve the performance of the OTT service provided to the UE 606 using the OTT connection 650, with the wireless connection 670 forming the final segment. More precisely, the teachings of these embodiments may improve the delay of directly activating SCell by RRC and the power consumption of user equipment, thereby providing benefits such as reduced user latency and extended battery life.

In an exemplary scenario, host 602 may collect and analyze factory status information. As another example, host 602 may process audio and video data, which may be acquired from the UE, for use in generating maps. As yet another example, host 602 may collect and analyze real-time data to assist in controlling vehicle congestion (e.g., traffic light control). As yet another example, host 602 may store surveillance video uploaded by the UE. As yet another example, host 602 may store or control access to media content such as video, audio, VR, or AR that can be broadcast, multicast, or unicast to the UE. As yet another example, host 602 may be used for energy pricing, remote control of non-time-critical power loads for balancing power generation needs, location services, presentation services (such as editing diagrams from data collected from remote devices), or any other function of collecting, acquiring, storing, analyzing, and/or transmitting data.

In some examples, measurement procedures may be provided for the purpose of monitoring data rate, latency, and other factors that may be improved by one or more embodiments. Further network functionality may exist as an option for reconfiguring the OTT connection 650 between host 602 and UE 606 in response to variations in the measurement results. The measurement procedures and/or network functionality for reconfiguring the OTT connection may be implemented in the software and hardware of host 602 and/or UE 606. In some embodiments, sensors (not shown) through which the OTT connection 650 passes may be deployed in or associated with other devices, and these sensors may participate in the measurement procedures by supplying numerical values of the monitoring results exemplified above or values of other physical quantities, from which the monitored quantities may be calculated or estimated by software. Reconfiguration of the OTT connection 650 may include message formatting, retransmission settings, preferred routing, etc., and such reconfiguration does not need to directly change the operation of network node 604. Such procedures and functionality may be known or in practice in the art. In one embodiment, the measurement may include proprietary UE signaling that facilitates the measurement of throughput, propagation time, and latency by the host 602. The measurement may be implemented by the software monitoring propagation time, errors, etc., while sending messages that are specifically empty or "dummy" messages using the OTT connection 650.

Figure 10 is a flowchart illustrating an exemplary method in a wireless device according to several embodiments. In a specific embodiment, one or more steps in Figure 10 may be performed by the UE200 described with respect to Figure 5. The wireless device is capable of fallback operation of the ML model.

The above method begins in step 1012, in which the wireless device (e.g., UE200) sends a message to the network node indicating its ability to support a combination of at least one ML-based feature of functionality and at least one preliminary feature of said functionality.

In a specific embodiment, at least one ML-based feature is based on an ML model that is divided into two parts, one of which is located in a wireless device and the other in a network node.

In specific embodiments, at least one preliminary feature is a feature that satisfies functionality equivalent to that of an ML-based feature, but is not preferred over an ML-based feature. At least one preliminary feature may also be a feature with higher capabilities than an ML-based feature, but is not preferred. At least one preliminary feature may be based on a non-ML-based algorithm, or on another ML-based algorithm (e.g., a more general-purpose ML-based algorithm). Other examples of preliminary features are described in the embodiments and examples of UE.

In a specific embodiment, the above message indicates whether at least one preliminary feature and at least one ML-based feature can be executed simultaneously (for example, for performance comparison between the two).

In step 1014, the wireless device may receive a first configuration message that configures the wireless device to operate at least one ML-based feature. In a specific embodiment, the method further includes receiving a first configuration message that configures the wireless device to operate at least one ML-based feature and at least one auxiliary feature simultaneously. In another embodiment, the wireless device may autonomously determine whether at least one ML-based feature and/or at least one auxiliary feature should be operated and simultaneously.

In step 1016, the wireless device operates at least one ML-based feature relating to the above functionality.

In step 1018, the wireless device may receive a second configuration message that configures the wireless device to deactivate at least one ML-based feature and activate at least one auxiliary feature.

In another embodiment, in step 1020 , the wireless device autonomously determines that it should deactivate at least one ML-based feature and activate at least one preliminary feature.

In step 1022, the wireless device operates at least one preliminary feature relating to the above functionality.

Method 1000 in Figure 10 may be modified, added to, or omitted. In addition, one or more steps in Method 10 may be performed in parallel or in any suitable order.

Figure 11 is a flowchart illustrating an exemplary method in a network node according to one embodiment. In a specific embodiment, one or more steps in Figure 11 may be performed by the network node 300 described with respect to Figure 6. The network node can configure a wireless device for fallback operation of the ML model.

The above method begins in step 1112, where a network node (e.g., network node 300) receives a message from the wireless device indicating the wireless device's ability to support a combination of at least one ML-based feature of functionality and at least one preliminary feature of said functionality.

In a specific embodiment, at least one ML-based feature is based on an ML model that is divided into two parts, one of which is located in a wireless device and the other in a network node.

In a specific embodiment, the above message indicates whether at least one preliminary feature and at least one ML-based feature can be executed simultaneously.

In step 1114, the network node may send a configuration message to the wireless device that configures the wireless device to operate at least one ML-based feature. In a specific embodiment, the method further includes sending a configuration message (1114) that configures the wireless device to operate at least one ML-based feature and at least one auxiliary feature simultaneously.

In step 1116, the network node determines that at least one preliminary feature should be activated.

In step 1118, the network node sends a configuration message to the wireless device that configures the wireless device to deactivate at least one ML-based feature and activate at least one auxiliary feature.

In step 1120, the network node may deactivate the portion of at least one ML-based feature that operates on that network node.

Method 1100 in Figure 11 may be modified, added to, or omitted. In addition, one or more steps in the method in Figure 11 may be performed in parallel or in any suitable order.

Without departing from the scope of the present invention, modifications, additions, or omissions may be made to the methods disclosed herein. The methods may include more, fewer, or other steps. Additionally, the steps may be performed in any suitable order.

The above description details numerous specific details. However, it is understood that the embodiments can be implemented even without these specific details. In other examples, well-known circuits, structures, and techniques are not shown in detail so as not to obscure the understanding of the description. Those skilled in the art will be able to implement appropriate functionality from the included description without excessive experimentation.

References in this specification to "one embodiment," "one example," and "exemplary embodiment" indicate that while the described embodiment may include certain features, structures, or characteristics, not all embodiments may necessarily include such features, structures, or characteristics. Furthermore, such phrases do not necessarily refer to the same embodiment. Moreover, where certain features, structures, or characteristics are described in relation to one embodiment, it is considered that implementing such features, structures, or characteristics in relation to other embodiments, whether explicitly stated or not, would be within the scope of knowledge of those skilled in the art.

Although this disclosure has been described in terms of certain embodiments, modifications and substitutions of those embodiments will be apparent to those skilled in the art. Therefore, the above description of those embodiments does not limit this disclosure. Other modifications, substitutions, and variations are possible without departing from the scope of this disclosure as defined by the following claims.

Claims (21)

A method performed by a wireless device for preliminary testing of a machine learning (ML) model,
Sending a message to a network node indicating the wireless device's ability to support a combination of at least one ML-based feature relating to the functionality and at least one preliminary feature relating to the functionality (1012),
Activating the at least one ML-based feature with respect to the aforementioned functionality (1016),
This includes activating the at least one preliminary feature of the aforementioned functionality (1022),
The message indicates whether the at least one preliminary feature and the at least one ML-based feature can be executed simultaneously.
method. A method according to claim 1, wherein the at least one ML-based feature is based on an ML model that is divided into two parts, one part located in the wireless device and the other part located in the network node. A method according to claim 1, wherein the at least one preliminary feature is a feature that satisfies the same functionality as the ML-based feature, but is not preferred over the ML-based feature. A method according to claim 1, wherein the at least one preliminary feature is a feature having higher capabilities than the ML-based feature, provided that the preliminary feature is not preferred. A method according to claim 1, wherein at least one preliminary feature is based on a non-ML-based algorithm. A method according to claim 1, wherein at least one preliminary feature is an ML-based algorithm. A method according to claim 1, further comprising receiving a first configuration message (1014) that configures the wireless device to operate the at least one ML-based feature. A method according to claim 1, further comprising receiving a first configuration message (1014) that configures the wireless device to operate simultaneously with at least one ML-based feature and at least one auxiliary feature. A method according to claim 1, further comprising receiving a second configuration message (1018) that configures the wireless device to deactivate at least one ML-based feature and activate at least one auxiliary feature. A method according to claim 1, further comprising autonomously determining that at least one ML-based feature should be deactivated and at least one preliminary feature should be activated (1020). A wireless device (200) capable of preliminary operation of a machine learning (ML) model, wherein the wireless device comprises a processing circuit (202), and the processing circuit is
Sending a message to a network node indicating the wireless device's ability to support a combination of at least one ML-based feature relating to functionality and at least one preliminary feature relating to said functionality,
To operate the aforementioned ML-based feature for the aforementioned functionality,
Activating at least one of the preliminary features of the aforementioned functionality,
It is capable of performing the following actions:
The message indicates whether the at least one preliminary feature and the at least one ML-based feature can be executed simultaneously.
Wireless device. A method performed by a network node for configuring a wireless device for preliminary operation of a machine learning (ML) model,
Receiving a message from the wireless device indicating the wireless device's ability to support a combination of at least one ML-based feature of functionality and at least one preliminary feature of the functionality (1112),
Determining that at least one of the aforementioned preliminary features should be activated (1116),
(1118) includes sending a configuration message to the wireless device that configures the wireless device to deactivate at least one ML-based feature and activate at least one auxiliary feature ,
The message indicates whether the at least one preliminary feature and the at least one ML-based feature can be executed simultaneously.
method. A method according to claim 12 , wherein the at least one ML-based feature is based on an ML model that is divided into two parts, one part located in the wireless device and the other part located in the network node. A method according to claim 12 , wherein the at least one preliminary feature is a feature that satisfies the same functionality as the ML-based feature, but is not preferred over the ML-based feature. A method according to claim 12 , wherein the at least one preliminary feature is a feature having higher capabilities than the ML-based feature, provided that the preliminary feature is not preferred. A method according to claim 12 , wherein at least one preliminary feature is based on a non-ML-based algorithm. A method according to claim 12 , wherein at least one preliminary feature is an ML-based algorithm. A method according to claim 12 , further comprising sending a configuration message to the wireless device that configures the wireless device to operate the at least one ML-based feature (1114). A method according to claim 12 , further comprising transmitting a configuration message (1114) that configures the wireless device to operate simultaneously the at least one ML-based feature and the at least one auxiliary feature. A method according to claim 12 , further comprising deactivating the portion of the at least one ML-based feature that operates on the network node (1120). A network node (300) capable of configuring a wireless device (200) for the parallel operation of multiple machine learning (ML) models, wherein the network node comprises a processing circuit (302), and the processing circuit is
Receiving a message from the wireless device indicating the wireless device's ability to support a combination of at least one ML-based feature relating to functionality and at least one preliminary feature relating to said functionality,
To detect performance degradation of at least one ML-based feature,
Sending a configuration message to the wireless device that configures the wireless device to deactivate at least one ML-based feature and activate at least one auxiliary feature,
It is capable of performing the following actions:
The message indicates whether the at least one preliminary feature and the at least one ML-based feature can be executed simultaneously.
Network node.