Machine learning fallback models for wireless devices

Abstract

According to some embodiments, a method is performed by a wireless device for fallback operation of a machine learning (ML) model. The method includes transmitting, to a network node, a message indicating the wireless device's ability to support a combination of at least one ML-based feature for functionality and at least one preliminary feature for the functionality, operating the at least one ML-based feature for the functionality, and operating the at least one preliminary feature for the functionality.

Description

Technical Field

[0001] Embodiments of the present disclosure are directed to wireless communication, more specifically, machine learning fallback models for wireless devices.

Background Art

[0002] Generally, all terms used herein should be interpreted according to their ordinary meanings in the relevant technical field, unless a different meaning is clearly given and / or suggested from the context in which they are used. All references to an element, apparatus, component, means, step, etc. should be construed openly as a reference to at least one instance of those elements, apparatus, components, means, steps, etc., unless otherwise explicitly stated. Any step of any method disclosed herein need not be performed in the exact order disclosed, unless explicitly described as following or preceding another step and / or unless it is implicitly understood that a step must follow or precede another step. Any feature of any embodiment disclosed herein may be applied to any other embodiment, if appropriate. Similarly, any advantage of any embodiment may apply to any other embodiment, and vice versa. Other objects, features, and advantages of the included embodiments will become apparent from the following description.

[0003] 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. Illustrative 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 line-of-sight (LOS) and non-line-of-sight (NLOS) condition classification 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.

[0004] 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 reduced 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 AI / ML technology for future air interface use cases.

[0005] 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 network nodes and UEs. 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).

[0006] Other use cases involve limited collaboration between network nodes and UEs. In this case, the ML model runs 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 the lifecycle of its AI model (e.g., for training / retraining the AI ​​model or updating the model).

[0007] 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. Thus, 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.

[0008] Building an AI model or any machine learning model involves numerous development steps, while the actual training of the AI ​​model is just one step in the training pipeline. A crucial part of AI development is managing the lifecycle of the ML model. An example is shown in Figure 1.

[0009] Figure 1 illustrates the training and inference pipelines, as well as their interactions in model lifecycle management procedures. 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, and a drift detection phase to notify about drift in model behavior.

[0010] A 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.

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

[0012] Model training refers to the actual model training stages outlined above.

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

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

[0015] The deployment phase involves integrating the trained (or retrained) AI model into the inference pipeline.

[0016] An 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.

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

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

[0019] 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.

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

[0021] 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.

[0022] The ML models deployed on the UE side are not generalizable to all scenarios, and 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, thereby negatively impacting the performance of wireless communication.

[0023] 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. Incorrect decisions can result in beam failures, radio link failures, poor throughput, and / or excessive signaling due to subsequent CSI measurement configuration / activation.

[0024] In other use case categories, ML models are 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 at the UE to compress estimated wireless channels, 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, ML models for this use case category require coupled operation between the network and the UE. If the UE-side portion of the ML model does not function well, the overall performance of the related functionality (e.g., CSI reporting) will be affected.

[0025] If the performance drift of the ML model is detected, it may be possible to start a new data set to maintain the ML model. However, maintaining such data sets and models may take a long time. Depending on the capabilities of the UE, online model maintenance may not be practical.

[0026] When an ML model is used for critical functionality, it is important to ensure that the robustness and resilience performance of that functionality are not affected if the ML model does not operate well. If performance issues with the active ML model(s) associated with that critical functionality are detected or predicted, prompt action needs to be taken.

[0027] Regarding the categories of ML use cases mentioned above, the current NR standard does not have a mechanism to guarantee / maintain the robustness and resilience of the functionality when the ML model operating for critical functionality does not operate well.

Summary of the Invention

[0028] As described above, there are currently issues with preliminary models of machine learning for wireless devices. Certain aspects of the present disclosure and their embodiments may provide solutions to these or other issues.

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

[0030] When a performance problem is detected for at least one ML-based feature, the UE can either be instructed by the network to switch to a preliminary feature for that functionality or autonomously switch to a preliminary feature and indicate the feature switch to the network.

[0031] According to some embodiments, a method in a UE operating with at least one ML-based feature associated with a functionality includes transmitting 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.

[0032] In a specific embodiment, the at least one ML-based feature is based on one or more ML models located in the UE. In a specific embodiment, the at least one ML-based feature is based on one ML model that is divided into two parts, one part located in the UE and the other part located in the network node. In a specific embodiment, the at least one ML-based feature is based on a plurality of ML models, some of those models located in the UE and the remainder of those models located in the network.

[0033] In specific embodiments, the preliminary feature is a feature that can satisfy the same functionality as the ML-based feature, but is not preferred over the ML alternative. In specific embodiments, the preliminary feature is a feature that has capabilities equal to or less than the ML-based feature. In specific embodiments, the preliminary feature is a feature that has higher capabilities than the ML-based feature, but is 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 status 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 location.

[0034] 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.

[0035] In specific embodiments, the 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 an 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 said 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.

[0036] 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.

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

[0038] 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 for the associated functionality and activate / switch on an associated auxiliary feature. The network may transmit the second configuration message if a performance failure of at least one ML-based feature for 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 in accordance with the information contained in the second configuration message.

[0039] 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 for 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 pointing to the network node about the feature switching information (e.g., the deactivated / stopped / switched-off ML-based feature).

[0040] 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 there is a failure, then switching to preliminary feature 2) is pre-configured by the network node or pre-defined in a standard.

[0041] 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 decision), location estimation, and link adaptation (e.g., MCS selection).

[0042] In a specific embodiment, the 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, or Type 2 codebook-based CSI reporting, or Type 1 single-panel-based CSI reporting).

[0043] 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.

[0044] 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.

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

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

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

[0048] In a specific embodiment, the method further includes the network node sending a reconciled configuration and / or scheduling message to the UE accordingly. The reconciliation by 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 the preliminary features.

[0049] According to some embodiments, a method is performed by a wireless device for fallback operation of an ML model. The 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.

[0050] In a specific embodiment, the above-mentioned 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 part is located in the network node.

[0051] In specific embodiments, 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. 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).

[0052] 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 comparison of the performance between the two).

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

[0054] In a specific embodiment, the method further includes receiving a first configuration message which configures the wireless device to operate simultaneously the at least one ML-based feature and the at least one preliminary feature.

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

[0056] 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.

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

[0058] Also disclosed is a computer program product including 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.

[0059] According to some embodiments, a method is performed by a network node to configure a wireless device for fallback operation of an ML model. The 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 that configures the wireless device to deactivate the at least one ML-based feature and activate the at least one preliminary feature.

[0060] In a specific embodiment, the above-mentioned 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 part is located in the network node.

[0061] 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.

[0062] 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.

[0063] 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 preliminary feature.

[0064] 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 any of the methods described above, which are performed by the network nodes described above.

[0065] A particular embodiment may provide one or more of the following technical advantages. For example, a specific embodiment ensures that a UE supporting an ML-based feature for a critical functionality also supports a backup feature for that functionality. By sharing the capability information of such UEs with network nodes, the UEs (and network nodes) can switch to the backup feature if a performance problem is detected / predicted for the ML-based feature. Thus, a specific embodiment ensures / maintains the robustness and resilience of a functionality when the ML model operating for that critical functionality is not functioning well. [Brief explanation of the drawing]

[0066] For a better understanding of the disclosed embodiments and their features and advantages, the following description is to be referred to together with the following accompanying drawings: [Figure 1] This shows the training and inference pipelines, as well as their interactions in model lifecycle management procedures. [Figure 2] This flowchart shows an example of a fallback for ML-based features supported by network nodes. [Figure 3] This flowchart shows an example of autonomous ML-based feature fallback by the UE and reporting of that action to network nodes. [Figure 4] An exemplary communication system according to one embodiment is shown. [Figure 5] An exemplary UE according to one embodiment is shown. [Figure 6] This shows an exemplary network node according to one embodiment. [Figure 7] This shows a block diagram of a host according to one embodiment. [Figure 8] This shows a virtualization environment in which a set of functions implemented by several embodiments according to one embodiment can be virtualized. [Figure 9] This describes a host communicating with a UE via a network node over a partially wireless connection according to one embodiment. [Figure 10] This describes a method performed by a wireless device according to one embodiment. [Figure 11] This describes a method executed by a network node according to one embodiment. [Modes for carrying out the invention]

[0067] 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.

[0068] 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 a preliminary feature for the functionality described above.

[0069] Specific embodiments will be described in more detail with reference to the attached drawings. However, other embodiments are also 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.

[0070] 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 a first node. The first node may receive messages from a 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.

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

[0072] An ML model can be 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 be a function that accepts a 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 be a function that accepts a measurement result of a reference signal X (e.g., transmitted on beam X), such as a synchronous signal block (SSB) with index 'x' as input 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.

[0073] Another example is an ML model that assists in the estimation of channel status information (CSI). In such a setup, the ML models are an intrinsic ML model at the UE and an ML model on the network side. Both ML models work together to provide coupled network functionality. The function of the ML model at the UE is to compress the channel input, and the function of the ML model on the network side is to decompress the output received from the UE.

[0074] Furthermore, ML models 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 them.

[0075] Other ML models are those that assist in channel estimation or interference estimation for channel estimation in the UE. Channel estimation may be, for example, 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. The future may be a number of slots after the UE made its last measurement, or it may target a specific slot at a future point in time.

[0076] 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 of the above-mentioned functionalities; a relay node; a core network node; a core network node that handles at least some of the operations of the above-mentioned functionalities; a device that supports device-to-device (D2D) communication; a location management function (LMF); or another type of location server.

[0077] In the use cases described here, the ML-based feature resides at least partially in the UE. In some use cases, the ML-based feature 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 feature is based on a single ML model that can be divided into two parts, one part located in the UE and the other part located in the network node (e.g., AE-based CSI feedback / reporting). In yet another use case, the ML-based feature is based on multiple ML models, some of which reside in the UE and the rest 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 its TX beam prediction, and another ML model is located in the UE for its RX beam prediction).

[0078] If performance drift is detected in an ML model, one option is to start a new dataset and retain the ML model. However, retaining such datasets and models can be time-consuming. Depending on the capabilities of the Unreal Engine (UE), online model retention may not be practical.

[0079] 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. Prompt action is necessary if performance issues with the active ML model associated with that critical functionality are detected or anticipated.

[0080] 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.

[0081] A preliminary feature may be a feature that has 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 above 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).

[0082] 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 the same functionality as the ML-based features, but are not preferred compared to ML alternatives.

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

[0084] 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.

[0085] In one example, the UE may support at least two ML models: a first ML model that is a generalized model usable in a wide range of deployments (e.g., indoors and outdoors, densely populated urban and rural areas, 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.

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

[0087] 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. Thus, 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 know) 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.

[0088] 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 functionality for that functionality.

[0089] 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.

[0090] 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 point to this capability information to network nodes using the various methods described below.

[0091] In some embodiments, the UE, in reporting its 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.

[0092] 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.

[0093] In some embodiments, the above 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 above functionality.

[0094] 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.

[0095] 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 features 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. Also, all UEs may implement legacy non-ML channel estimation, and its use may be required by the network.

[0096] 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 the UE supports complex codebook combinations, as shown in the table below. [Table 1]

[0097] For CSI feedback / reporting use cases, a message indicating the UE's ability to support a combination of an ML-based feature (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 signifies the ML-based CSI feedback feature. For more advanced UEs, new entries may be added to represent combinations of more than two codebook types, e.g., {Type 1 Single Panel, Type 2, Type 3}.

[0098] 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.

[0099] 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.

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

[0101] The message containing information about an ML-based feature and the message containing preliminary features associated with that ML-based feature may be the same message or different messages.

[0102] The UE may activate / switch on / register an 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 above instructions may be made 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 another UE).

[0103] 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.

[0104] 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.

[0105] 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.

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

[0107] In some embodiments, if the UE reports its ability to perform simultaneous executions, upon receiving the UE's capability information, the network node may send a first configuration message instructing the UE to execute / operate the ML-based feature and its associated preliminary feature simultaneously. 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.

[0108] 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 once for the preliminary features. Alternatively, the reporting may be configured such 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 low duty cycles, such as 5% of the total operation time, during which time the ML features may be initiated independently for the majority of the time.

[0109] In some embodiments, if the UE indicates a lack of ability to perform concurrent 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.

[0110] In response to the detection / 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.

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

[0112] Step 1: The UE (for example, UE200, which is described in more detail below with respect to Figure 4) sends a message to a network node (for example, network node 300, which is 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.

[0113] 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 above message, the UE simultaneously executes / operates the configured ML-based features and preliminary features for the associated functionality.

[0114] 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.

[0115] Step 4: The network node detects or predicts a performance failure of at least one ML-based feature for the associated functionality described above.

[0116] 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 indicated ML-based feature with performance issues and activates / switches on the associated backup feature.

[0117] 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 features are 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 features are based on multiple ML models, one part of which is located in the UE and the rest of which is located in the network.

[0118] Step 6 [Optional]: The network node sends the adjusted configuration and / or scheduling message to the UE. For example, the adjusted 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.

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

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

[0121] Step 1: The UE (for example, UE200, which is described in more detail below with respect to Figure 4) sends a message to a network node (for example, network node 300, which is 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.

[0122] Step 2: The network consists of at least one ML-based feature.

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

[0124] Step 4: The UE detects or predicts a performance failure 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 low duty cycles, for example, 5% of the total operation time. Concurrent execution does not necessarily mean that they occur exactly simultaneously, but rather 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.

[0125] 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 ML-based and preliminary features, but the actual data processing processes for both features do not need to occur simultaneously. Rather, they can be spread out over time for later comparison of results or reporting to gNB.

[0126] 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 comparing the two operating modes over a longer 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, 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.

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

[0128] Step 6: The UE points to the network nodes the fallback / switching information for the above features (e.g., ML-based features that have been deactivated / stopped / switched off).

[0129] 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 features are 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 features are based on multiple ML models, one part of which is located in the UE and the rest of which is located in the network.

[0130] Step 8 [Optional]: The network node sends the adjusted configuration and / or scheduling message to the UE. For example, the adjusted 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.

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

[0132] 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 radio 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 connectivity 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.

[0133] 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, whether 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.

[0134] UE112 may be any of a broad range of communication devices, including wireless devices that are arranged, configured, and / or operable to communicate wirelessly with network node 110 and other communication devices. Similarly, network node 110 is arranged, can be arranged, configured, and / or operable to communicate directly or indirectly with UE112 and / or other network nodes or devices in 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.

[0135] 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, mediated by 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).

[0136] 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 acquisition and editing of data on a variety of 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.

[0137] 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 (WiFi), 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.

[0138] 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 communication (URLLC) services to some UEs while providing extended mobile broadband (eMBB) services to other UEs, and may also provide massive machine type communication (mMTC) / massive IoT services to further UEs.

[0139] In some examples, UE112 is configured to transmit and / or receive information without direct human interaction. For example, the UE may be designed to transmit information to access network 104 on a predetermined schedule, triggered by internal or external events, or in response to a request from access network 104. Additionally, the UE may be configured to operate in single or multi-RAT, or multi-standards mode. For example, the UE may be configured to operate in 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).

[0140] In the above example, the hub 114 communicates with the access network 104 to facilitate indirect communication between one or more UEs (e.g., UE112c 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 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 performing 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, in particular when one or more of the UEs are low-energy IoT devices.

[0141] 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 another example, 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.

[0142] Figure 5 shows UE200 according to several embodiments. As used herein, UE refers to a device that is 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 equipment (LEE), laptop-mounted equipment (LME), smart devices, wireless customer premises equipment (CPE), 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.

[0143] 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 to be sold to or operated 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 to be sold to or operated by an end user, but may be associated with or operated for the benefit of a user.

[0144] The UE200 includes a processing circuit 202 operably connected to an input / output interface 206 via a bus 204, a power supply 208, memory 210, a communication interface 212, and / or any other components, or any combination thereof. 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 a component, such as multiple processors, memory, transceivers, transmitters, receivers, etc.

[0145] The processing circuit 202 is configured to process instruction sets and data, and may be configured to implement some sequential state machine capable of operating to execute 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).

[0146] 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.

[0147] 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 power circuits for transmitting power from the power supply 208 itself and / or an external power source to various parts of the UE200 via interfaces such as input circuits or power cables. Power transmission may, for example, be for charging the power supply 208. The power circuits may perform some shaping, conversion, or other modification on the power from the power supply 208 to suit the power of each component of the UE200 to which it is being powered.

[0148] Memory 210 may be random access memory (RAM), read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electroerasable 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.

[0149] Memory 210 may be configured to include multiple physical drive units such as RAID (Redundant Array of Independent Disks), flash memory, USB flash drives, external hard disk drives, thumb drives, pen drives, key drives, HD-DVD (High-Density Digital Versatile Disc), optical disc drives, internal hard disk drives, Blu-ray optical disc drives, HDDS (Holographic Digital Data Storage) optical disc drives, external mini DI MM (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". Memory 210 may enable UE200 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 defined as memory 210 which is or may include a device-readable storage medium or such memory 210 It can be materialized in a tangible form within.

[0150] 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 to communicate, for example, by communicating with one or more remote transceivers of other wirelessly communicable devices (e.g., other UEs or network nodes in the access network). 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.

[0151] 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. The 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, HTTP (Hypertext Transfer Protocol), etc.

[0152] Regardless of the sensor type, the 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 via 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).

[0153] Other examples 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.

[0154] 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. An IoT device-type UE 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.

[0155] 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 may be referred to as an MTC device in the context of 3GPP. 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.

[0156] 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 and provide speed information of the drone (obtained through a speed sensor) to a second UE, which is a remote controller operating the drone. When the user makes a change from the remote controller, the first UE may adjust the drone's throttle (for example, by controlling an actuator) to increase or decrease the drone's speed. The first and / or second UE 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 actuator.

[0157] Figure 6 shows network nodes 300 according to several embodiments. As used herein, a network node is a device that is capable of communicating directly or indirectly with the UE and / or other network nodes or devices in the 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 Bs, evolved node Bs (eNBs), and NR node Bs (gNBs)).

[0158] 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 of the 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 of the distributed radio base stations may be referred to as nodes in a distributed antenna system (DAS).

[0159] 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 (including, for example, evolved serving mobile location centers (E-SMLCs) and / or drive test minimization (MDTs)).

[0160] The network node 300 includes a processing circuit 302, memory 304, a communication interface 306, and a power supply 308. The network node 300 may consist of multiple physically separate 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 separate components (e.g., BTS and BSC components), one or more of these separate 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 separate 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 exemplary components for various wireless technologies to be integrated into the network node 300, such as GSM, WCDMA, LTE, NR, WiFi, 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.

[0161] 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, which can operate independently or in conjunction with other network node 300 components such as memory 304 to provide the functionality of the network node 300.

[0162] 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 be 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 be on the same chip or set of chips, substrate, or unit.

[0163] 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 interface 306. In some embodiments, the processing circuit 302 and the memory 304 are integrated.

[0164] The communication interface 306 is used in wired or wireless signaling and / or data 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 radio signal can then be transmitted via the antenna 310. Similarly, when data is received, the antenna 310 collects the radio signal, which can then be converted into digital data by the radio 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.

[0165] In one alternative embodiment, the network node 300 does not have 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 an RF transceiver circuit 312, and the communication interface 306 communicates with a baseband processing circuit 314, which is part of a digital unit (not shown).

[0166] 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 a 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 can be connected to the network node 300 through an interface or port.

[0167] 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.

[0168] Power supply 308 provides power to the various components of network node 300 in a format suitable for each component (for example, at the voltage and current levels required for each component). Power supply 308 may include, or be connected to, a power management circuit for supplying power to the components of network node 300 to perform the functions described herein. For example, 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 power supply 308. As a further example, 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.

[0169] 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 input of information to and output of information from the network node 300. This may enable a user to perform diagnostic, maintenance, repair, and other management functions on the network node 300.

[0170] 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, hardware-aware and / or software in various combinations, including standalone servers, blade servers, cloud-implemented servers, distributed servers, virtual machines, containers, or processing resources within a server farm. Host 400 may provide one or more services to one or more UEs.

[0171] 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. In other embodiments, other components may be included. 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 thus those descriptions are generally applicable to the corresponding components of the host 400.

[0172] 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 the UE for the host 400 or data generated by the host 400 for the 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. Thus, 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, such as HLS (HTTP Live Streaming), RTMP (Real-Time Messaging Protocol), RTSP (Real-Time Streaming Protocol), and MPEG-DASH (Dynamic Adaptive Streaming over HTTP).

[0173] Figure 8 is a block diagram showing a virtualization environment 500 in which functions implemented by several embodiments can be virtualized. In this context, 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 a portion 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 a host), the node as a whole may be virtualized.

[0174] Application 502 (which may alternatively be called 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.

[0175] Hardware 504 includes a processing circuit, 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 VM508a and VM508b (one or more of which may be referred to collectively as VM508), 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.

[0176] VM508 includes virtual processing, virtual memory, virtual networking or interfaces, and virtual storage, and may be run 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 in data centers and customer premises equipment.

[0177] In the context of NFV, VM508 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 VM508, and the portion of hardware 504 running the VM, forms a separate virtual network element, whether the hardware is dedicated to the VM and / or shared by the 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 VM508s at the top level of hardware 504 and corresponds to application 502.

[0178] Hardware 504 may be implemented in a standalone network node with common or specific components. Hardware 504 may implement some functions through virtualization. Alternatively, hardware 504 may be part of a larger hardware cluster (e.g., one in a data center or CPE) in which multiple hardware nodes cooperate and are managed via management and orchestration 510, which oversees, among other things, 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.

[0179] 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 (UE112a in Figure 4 and / or UE200 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.

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

[0181] Network node 604 includes hardware that enables communication with host 602 and UE606. Connection 660 may be direct or pass through 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.

[0182] UE606 includes software stored within or accessible by UE606, which is executable by the UE's processing circuitry. This software may include a client application, such as a web browser or a service provider-specific "app," which may operate to provide services to human or non-human users via UE606, with the support of host 602. On host 602, the host application to be executed may communicate with the client application to be executed via an OTT connection 650 that terminates at UE606 and host 602. While providing services 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 the request data and the 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.

[0183] 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, and may provide connectivity between host 602 and UE 606. The connections 660 and wireless connection 670, which may be provided by the OTT connection 650, are abstractly depicted to illustrate communication between host 602 and UE 606 via network node 604 without any explicit reference to any intermediate devices and the precise routing of messages through those devices.

[0184] As an example of transmitting data via 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 that carries 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, 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, UE606 receives the user data carried in the above transmission, which may be done by a client application running on UE606 associated with a host application running on host 602.

[0185] In some examples, UE606 runs a client application, thereby providing user data destined for host 602. User data may be provided in reaction to or in response to receiving data from host 602. Accordingly, in step 616, UE606 may provide user data, which may be done by running 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 way 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.

[0186] One or more of the various embodiments improve the performance of the OTT service provided to the UE606 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 the SCell by the RRC, and the power consumption of the user equipment, thereby providing benefits such as reduced user latency and extended battery life.

[0187] In an exemplary scenario, Host 602 may collect and analyze factory status information. In another example, Host 602 may process audio and video data, which may be acquired from the UE, for use in generating maps. In yet another example, Host 602 may collect and analyze real-time data to assist in controlling vehicle congestion (e.g., traffic light control). In yet another example, Host 602 may store surveillance video uploaded by the UE. In 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. In 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.

[0188] 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 above 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 values ​​of the monitored quantities 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.

[0189] 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.

[0190] The above method begins in step 1012, in which the wireless device (e.g., UE200) sends a message to the network node 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.

[0191] 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.

[0192] In specific embodiments, at least one preliminary feature is a feature that satisfies equivalent functionality to an ML-based feature, but is not preferred over an ML-based feature. At least one preliminary feature may 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 the UE.

[0193] 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 a comparison of the performance between the two).

[0194] 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.

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

[0196] In step 1018, the wireless device may receive a second configuration message which configures the wireless device to deactivate at least one ML-based feature and activate at least one preliminary feature.

[0197] In another embodiment, step 1020 The wireless device then autonomously determines that it should deactivate at least one ML-based feature and activate at least one preliminary feature.

[0198] In step 1022, the wireless device operates at least one preliminary feature of the above functionality.

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

[0200] 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.

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

[0202] 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.

[0203] 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.

[0204] 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 that configures the wireless device to operate at least one ML-based feature and at least one auxiliary feature simultaneously (1114).

[0205] In step 1116, the network node determines that it should activate at least one preliminary feature.

[0206] 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.

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

[0208] 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.

[0209] Without departing from the scope of the present invention, the methods disclosed herein may be modified, added to, or omitted. The methods may include more, fewer, or other steps. Additionally, the steps may be performed in any suitable order.

[0210] 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 description provided without excessive experimentation.

[0211] References in this specification to “one embodiment,” “one example,” and “exemplary embodiment” indicate that while the embodiments described 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, if 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.

[0212] Although this disclosure has been described in terms of certain embodiments, modifications and substitutions of those embodiments will be obvious 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

1. 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.

2. 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 of which is located in the wireless device and the other part is located in the network node.

3. 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.

4. 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.

5. A method according to claim 1, wherein at least one preliminary feature is based on a non-ML-based algorithm.

6. A method according to claim 1, wherein the at least one preliminary feature is an ML-based algorithm.

7. A method according to claim 1, further comprising receiving a first configuration message (1014) which configures the wireless device to operate the at least one ML-based feature.

8. A method according to claim 1, further comprising receiving a first configuration message (1014) which configures the wireless device to operate simultaneously the at least one ML-based feature and the at least one auxiliary feature.

9. A method according to claim 1, further comprising receiving a second configuration message (1018) which configures the wireless device to deactivate the at least one ML-based feature and activate the at least one auxiliary feature.

10. 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).

11. 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 the functionality and at least one preliminary feature relating to the 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.

12. 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.

13. 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.

14. 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.

15. 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.

16. A method according to claim 12, wherein at least one preliminary feature is based on a non-ML-based algorithm.

17. A method according to claim 12, wherein the at least one preliminary feature is an ML-based algorithm.

18. A method according to claim 12, further comprising sending a configuration message to the wireless device (1114) that configures the wireless device to operate the at least one ML-based feature.

19. 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.

20. 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).

21. 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.

Images