Network (NW)-side ai / ML data management

Abstract

Example embodiments of the present disclosure relate to network-side (NW-side) Artificial Intelligence and / or Machine Learning (AI / ML) data management. According to example embodiments, a system may include a network entity that may be configured to generate a Radio Resource Control (RRC) message that includes information associated with at least one of: a condition that triggers a data collection for collecting data associated with an AI / ML model, or a logging duration associated with the data collection. Accordingly, the network entity may be configured to transmit the RRC message to the UE.

Description

NETWORK (NW)-SIDE AI / ML DATA MANAGEMENTCROSS REFERENCE TO RELATED APPLICATION

[0001] This application claims priority to U.S. Provisional Patent Application No.63 / 754,788, filed with the U.S. Patent and Trademark Office on February 6, 2025, and U.S. Provisional Patent Application No. 63 / 755,255, filed with the U.S. Patent and Trademark Office on February 7, 2025 the entire contents of which are incorporated herein by reference.TECHNICAL FIELD

[0002] The present disclosure relates to network-side (NW-side) Artificial Intelligence and / or Machine Learning (AI / ML) data management.BACKGROUND

[0003] The information disclosed in this background section is only for the enhancement of understanding of the general background of the disclosure and should not be taken as an acknowledgement or any form of suggestion that this information forms the prior art already known to a person skilled in the art.

[0004] In modem wireless communication systems or networks (e.g., 5G New Radio (NR)-based networks, Open Radio Access Network (O-RAN)-based networks, etc.), Artificial Intelligence (Al) and / or Machine Learning (ML) are increasingly utilized to optimize network performance and operations. A specific configuration may involve the deployment (e.g., training, updating, executing, etc.) of Al / ML models for optimizing network operations. For instance, the AI / ML models may be deployed within one or more network components, such as a base station(e g., 5G gNodeB, etc.), a radio access network (RAN) node, a core network entity, or the like, to provide network-related operations or services (e.g., network optimization, network operation automation, etc.). For descriptive purposes, such a configuration may be referred to as the "NW-side AI / ML” herein.

[0005] The deployment and continuous operation of the NW-side AI / ML may involve the collection and processing of massive amounts of data characterized by a wide range of varieties and temporal dynamics. Effective and efficient management of this high-volume, heterogeneous data (“AI / ML data” herein) is critical to enable accurate and reliable AI / ML-driven operations, as the performance of the AI / ML models relies on the comprehensiveness, completeness, and timeliness of the AI / ML data utilized for training and inference.SUMMARY

[0006] Example embodiments of the present disclosure provide systems, methods, and the like, that effectively and efficiently implement NW-side AI / ML data management.

[0007] According to example embodiments, a system may include a network entity that may be configured to generate a Radio Resource Control (RRC) message that includes information associated with at least one of a condition that triggers a data collection for collecting data associated with an AI / ML model, or a logging duration associated with the data collection. Accordingly, the network entity may be configured to transmit the RRC message to the UE.

[0008] According to example embodiments, a method may include generating an RRC message that includes information associated with at least one of: a condition that triggers a data collection for collecting data associated with an AI / ML model, or a logging duration associated with the data collection. The method may further include transmitting the RRC message to a UE.

[0009] According to example embodiments, a non-transitory computer-readable recording medium having recorded thereon instructions executable by a network entity to cause the network entity to perform a method. The method may include generating an RRC message that includes information associated with at least one of: a condition that triggers a data collection for collecting data associated with an AI / ML model, or a logging duration associated with the data collection. The method may further include transmitting the RRC message to a UE.

[0010] Additional aspects will be set forth in part in the description that follows and, in part, will be apparent from the description, or may be realized by practice of the presented embodiments of the disclosure.BRIEF DESCRIPTION OF THE DRAWINGS

[0011] Features, aspects, and advantages of embodiments of the disclosure will be described below with reference to the accompanying drawings, in which like reference numerals denote like elements, and wherein:

[0012] FIG. 1 illustrates an example system configuration, according to one or more example embodiments;

[0013] FIG. 2 to FIG. 7 each illustrates an example method, according to one or more example embodiments;

[0014] FIG. 8A to FIG. 8C illustrate various example use cases, according to one or more example embodiments;

[0015] FIG. 9 illustrates an example device / apparatus that may implement one or more example embodiments; and

[0016] FIG. 10 illustrates an example environment in which systems, devices, and / or methods, according to one or more example embodiments, may be implemented.DETAILED DESCRIPTION

[0017] The following detailed description of example embodiments refers to the accompanying drawings. The foregoing disclosure provides illustration and description, but is not intended to be exhaustive or to limit the implementations to the precise forms disclosed. Modifications and variations are possible in light of the above disclosure or may be acquired from practice of the implementations. Further, one or more features or components of one embodiment may be incorporated into or combined with another embodiment (or one or more features of another embodiment). Additionally, the flowchart and description of operations provided below relate to one of the various embodiments. It should be noted that it is possible to make other embodiments that do not exactly match the flowchart and its description. It is understood that in other embodiments one or more operations may be omitted, one or more operations may be added, one or more operations may be performed simultaneously (at least in part).

[0018] It will be apparent that systems and / or methods, described herein, may be implemented in different forms of hardware, firmware, or a combination of hardware and software. The actual specialized control hardware or software code used to implement these systems and / or methods is not limited to the described implementations. Thus, the operation and behavior of the systems and / or methods are described herein without reference to specific software code. It is understood that software and hardware may be designed to implement the systems and / or methods based on the description herein.

[0019] Even though particular combinations of features are disclosed in the claims and / or in the specification, these combinations are not intended to limit the disclosure of implementations. In fact, many of these features may be combined in ways not specifically recited in the claims and / or disclosed in the specification. Although each dependent claim listed below may directly depend on only one claim, the disclosure of implementations includes each dependent claim in combination with every other claim in the claim set.

[0020] No element, act, or instruction used herein should be construed as critical or essential unless explicitly described as such. Also, as used herein, the articles “a” and “an” are intended to include one or more items, and may be used interchangeably with “one or more.” Also, as used herein, the terms “has,” “have,” “having,” “include,” “including,” or the like are intended to be open-ended terms. Further, the phrase “based on” is intended to mean “based, at least in part, on” unless explicitly stated otherwise. Furthermore, expressions such as “at least one of [A] and [B]”, “[A] and / or [B]”, or “at least one of [A] or [B]”, are to be understood as including only A, only B, or both A and B.

[0021] Expressions such as “at least one processor,” where configured to implement a plurality of operations, execute a plurality of instructions, etc., are to be understood as a single processor implementing the plurality of operations, etc., or each of plural processors implementing at least some (but not necessarily all) of the plurality of operations, etc.

[0022] Reference throughout this specification to “one embodiment,” “embodiment,” “non-limiting exemplary embodiment,” “example embodiment,” or similar language means that a particular feature, structure, or characteristic described in connection with the indicated embodiment is included in at least one embodiment of the present solution. Thus, the phrases “in one embodiment”, “in an embodiment,” “in one non-limiting exemplary embodiment,” and similarlanguage throughout this specification may, but do not necessarily, all refer to the same embodiment.

[0023] Further, the described features, advantages, and characteristics of the present disclosure may be combined in any suitable manner in one or more example embodiments. One skilled in the relevant art will recognize, in light of the description herein, that the present disclosure can be practiced without one or more of the specific features or advantages of a particular embodiment. In other instances, additional features and advantages may be recognized in certain embodiments that may not be present in all embodiments of the present disclosure.

[0024] It shall be noted that, descriptions of example embodiments of the present disclosure may include terms and names defined in one or more standard organizations, such as the Open Radio Access Network (0-RAN) Alliance, the 3rd Generation Partnership Project (3 GPP) standard organization, the European Telecommunications Standards Institute (ETSI) standard organization, and the like. For instance, the terms “RRC message,” “MAC CE,” “IE,” “L3,” “LI,” “MDT,” “CSI,” “SINR,” “RSRP,” “Handover Command,” and the like, as well as the associated features, operations, interfaces, and messages involved therein, are to be interpreted as consistent with those specified in one or more technical specifications, unless being described otherwise.

[0025] In the present disclosure, specific tasks may be performed using Artificial Intelligence and / or Machine Leaning (AI / ML) models. An AI / ML model is a model generated using one or more Al technologies, one or more ML algorithm or both, and generates output data based on input data. This output data is used to perform tasks. Tasks performed using AI / ML models include those generally referred to as intellectual tasks, such as classification, prediction, natural language processing, etc. In the following, terms like “the Al model” may refer to “one ormore Al models,” “one or more ML models,” “one or more Al models and ML models,” and the like.

[0026] Although Al and ML may be explained separately, ML is a technology included in Al. In ML, instead of being explicitly programmed for a specific task, systems can improve their performance over time by identifying patterns and making inferences from training data. Typically, the generation of ML models includes data collection, model training, and model inference. Data collection involves gathering and preprocessing data to be used for training and inference. Model training involves developing and validating models using the collected data. Model inference involves applying the trained models to new data to generate new output data and perform tasks.

[0027] Machine learning includes various types of learning methods such as supervised learning, unsupervised learning, reinforcement learning, semi-supervised learning, self-supervised learning, transductive learning, transfer learning, meta learning, and the like. These types of learning methods can be appropriately selected according to the embodiments. Unless otherwise specified, the application of types not mentioned in this description is not precluded. Additionally, the structure of ML models may vary depending on the embodiments and learning methods, and is not limited to the methods disclosed. Furthermore, ML includes deep learning, which uses models that include neural networks. Deep learning models may include, for example, deep neural networks (DNNs), convolutional neural networks (CNNs), etc.

[0028] It should be noted that the AI / ML models presented hereinafter are examples and are not limited to the illustrated AI / ML models. They can be modified or altered by using different Al or ML algorithms. The configuration of the neural network is not limited to the configuration disclosed in the present disclosure and can be modified.

[0029] As described above, in a network-side (NW-side) configuration, one or more network entities (e.g., base station, radio access network (RAN), core network, etc.) may act as the entity that implements or deploys (e.g., trains, updates, executes, etc.) one or more AI / ML models to provision network-related operations or services (e.g., network resource optimization, network automation, etc.). In this regard, the efficacy and accuracy of these AI / ML models may rely on the quality, timeliness, and completeness of the data utilized for implementing the AI / ML models. For example, when training an AI / ML model designed to optimize beam management, if the collected training data fails to capture critical or timely radio conditions (e.g., due to insufficient logging durations or delayed reporting, etc.), the resulting AI / ML model (trained based on the collected training data) may be unable to accurately predict dynamic channel changes, leading to suboptimal beam management when the AI / ML model is executed for beam management operations.

[0030] As also described above, the deployment and continuous operation of the NW-side AI / ML configuration may involve the collection and processing of massive amounts of data (“AI / ML data” herein). This AI / ML data may be characterized by a wide range of varieties and temporal dynamics. In this regard, a major portion of these high-volume, heterogeneous data may be collected or aggregated by one or more user equipment (UEs), such as customer devices (e.g., smartphones, tablets, wearables, etc.), specialized terminals (e.g., vehicles, industrial internet of things (loT) sensors, etc.), and the like. Further, the AI / ML data may include, for example, radio / network-related data (e.g., Channel State Information (CSI), Signal-to-Interference-plus-Noise Ratio (SINR), beam measurements, etc.), UE-related data (e.g., power consumption, supported features, operational states, etc.), user-related data (e.g., application usage statistics, traffic demand patterns, mobility routines, etc.), and the like.

[0031] In view of the above, the communication among the network component(s) and the UE is a critical aspect in managing AI / ML data for NW-side AI / ML deployment. For instance, the signaling between the network component(s) and the UE may affect how efficient and effective the network component(s) may inform the UE regarding the specific requirements for collecting AI / ML data for NW-side AI / ML deployment, such as the precise conditions under which data collection / logging should be initiated and the required duration of such data collection / logging. Similarly, the quality of this communication may determine the ability of the UE to accurately capture and timely report the targeted AI / ML data to the network component(s), ensuring that the collected datasets are sufficiently comprehensive for NW-side AI / ML deployment while minimizing the transmission of redundant information and reducing the signaling overhead on the radio interface.

[0032] Nevertheless, data management mechanisms in the related art, such as Minimization of Drive Tests (MDT) or standard periodic measurement reporting, have been used for general network optimization (coverage analysis, failure detection) and were not originally designed to meet the rigorous and dynamic requirements of AI / ML-related operations, such as AI / ML model training, AI / ML model inference, and the like. Rather, there are no standardized or specified mechanisms available in the related art that enable efficient and effective NW-side AI / ML data management. In the following, the shortcomings of the related art are described for the following four aspects:(1) Event-Based Data Collection and Periodic Data Collection;(2) MDT-Based Data Collection;(3) Standardization of NW-side Data Collection and UE-side Data Collection; and (4) Data Collection Across Mobility Events.

[0033] Regarding aspect (1), the use of event-based data collection (e.g., Layer 3 (L3) measurement-based data collection) and periodic data collection (e.g., Layer 1 (LI) measurementbased data collection) has been introduced in the related art. The periodic data collection / logging may enable consistent data collection over time, but may lead to excessive accumulation of redundant data, particularly in stable network conditions. The event-based data collection / logging, on the other hand, may enable the data collection to be activated under specific conditions (e.g., a specific change in the radio environment, a detection of a beam switching event, etc.), but may require specific frameworks and clear signaling mechanisms in order to be effectively and efficiently implemented, particularly in dynamic network environments.

[0034] In this regard, while there may be a broad support for L3-based event triggers (e.g., Al-like X1 / X2 events) in the related art, there is no standardized or specified details regarding the configurations of the event-based AI / ML data collection (e.g., what condition(s) should trigger or terminate the data collection for NW-side AI / ML purposes, how the configurations of the eventbased data collection can be signaled, etc.). Further, although the concept of the utilization of beam-based logging triggers is introduced in the related art, the utilization of beam-based data collection / logging is not widely adopted due to excessive fluctuations in LI measurements. Furthermore, although the data collection / logging duration remains a critical topic, there is no clear consensus in the related art on whether fixed data collection / logging periods (e.g., which may offer implementation simplicity) or dynamic data collection / logging periods (e.g., which may provide better efficiency with the cost of increased signaling complexity) should be adopted. In addition, there is no standardized or specified mechanisms that may ensure synchronization between eventbased AI / ML data collection and Al / ML-driven processes. In this regard, data collection / logging durations that are too short may cause AI / ML models to miss critical transitions in radio conditions,ultimately affecting AI / ML deployment (e.g., training, etc.) accuracy. Conversely, excessively long data collection / logging durations may generate unnecessary data and introduce additional signaling overhead.

[0035] Regarding aspect (2), Minimization of Drive Tests (MDT)-based data collection has been utilized for network optimization in the related art, and the potential use of MDT for NW-side Al / ML data management has been introduced. For example the following two MDT mechanisms may theoretically be utilized for NW-side AI / ML data collection: (a) a logged MDT mechanism, where the AI / ML data may be collected while the UE is in RRC IDLE state or RRC INACTIVE state and later reported to the network when the UE transitions to RRC CONNECTED state, and (b) an immediate MDT mechanism, where the AI / ML data may be collected and reported while the UE is in RRC CONNECTED state. The logged MDT mode has been widely used in network data collection but may lack real-time applicability, which may be critical for AI / ML dataset updates. On the other hand, the immediate MDT mode may enable real-time (or near real-time) collection of AI / ML-relevant network parameters and continuous AI / ML data generation, thereby enabling dynamic data like beam transitions, SINR variations, interference patterns, and the like, to be dynamically captured.

[0036] In this regard, although MDT may potentially provide a structured framework for NW-side AI / ML data management, the MDT mechanisms in the related art are suboptimal and not optimized for NW-side AI / ML data management. To begin with, one of the issues of aspect (2) is that the current structure of an MDT report does not inherently include AI / M L-relevant parameters or measurements (e.g., detailed SINR trend tracking across different beams, beam switching logs aligned with network-side training requirements, CS1 measurement trends that contribute to AI / ML model adaptation, etc.), which are critical for generating AI / ML datasets. Further, there areno standardized or specified mechanisms as to how the MDT-based data collection / logging can be initiated for NW-side AI / ML data collection purposes. For example, network-controlled MDT-based data collection may be preferable under certain situations, as it may ensure consistency across multiple UEs and avoid unnecessary data collection. Conversely, UE-initiated MDT-based data collection may be preferable under certain situations, as the UE may detect rapid radio frequency (RF) condition changes (e.g., deep fading, sudden interference, etc.) and anomalous conditions more effectively than the network, making the UE better suited for triggering localized data collection. Furthermore, although event-based MDT data collection / logging in the related art may theoretically enhance dataset efficiency (e.g., by ensuring logging occurs only when AI / ML-related conditions are met, etc.), there is no clarification on whether the existing MDT frameworks can be adapted for AI / ML-driven triggers, or any new signaling mechanism is needed for triggering the event-based MDT data collection / logging.

[0037] Regarding aspect (3), conversely to NW-side AI / ML, UE-side AI / ML may refer to the deployment (e.g., training, updating, execution, etc.) of AI / ML models at the UE, and / or the deployment of the AI / ML models at the network for UE-related purposes (e.g., for optimizing the operations of the UE, for sharing the AI / ML models or associated data with other devices, for providing a specific service such as content generation or data storage to the UE, etc.). In this regard, although both of the NW-side AI / ML and the UE-side AI / ML may rely on similar type of data (e.g., radio measurement data, etc.), their scope, granularity, and objectives may be different, particularly in terms of data collection mechanisms, dataset requirements, and standardization needs. For instance, for the training of an AI / ML model for NW-side AI / ML purposes, the primary requirement is aggregated, multi-UE data that may enable network-wide AI / ML optimizations (e.g., the essential dataset components may include multi-UE aggregated CSI measurements thatcapture spatial diversity, interference maps across multiple network sectors, mobility patterns to optimize resource allocation and handover strategies, etc.). Conversely, for the training of an Al / ML model for UE-related operations (e.g., UE optimization, etc.), localized / per-device data may be preferred to enhance individual performance (e g., the essential dataset components may include motion trajectory logs to model mobility effects, per-device power consumption patterns to optimize energy efficiency, beam selection metrics to refine UE-specific inference models, etc.).

[0038] In this regard, one of the issues in the related art is the absence of standardized and specified signaling mechanisms and classification mechanisms to differentiate NW-side and UE-side datasets. While the utilization of CSI reporting structures for signaling AI / ML data is introduced in the related art, without specifying and standardizing the mechanisms for classifying and differentiating the datasets for NW-side AI / ML purposes and UE-side AI / ML purposes, the CSI-based reporting may not sufficiently differentiate data collected for NW-side AI / ML purposes and UE-side AI / ML purposes, creating ambiguities in dataset utilization. Accordingly, the lack of standardized dataset classification may lead to inconsistencies in AI / ML-related operations under the NW-side AI / ML configuration, particularly in network-wide optimizations. Without a defined dataset framework, the AI / ML models may be trained using mixed and inconsistent datasets and may struggle to generalize across different deployment scenarios, leading to inefficiencies in the trained AI / ML models since the AI / ML models may fail to dynamically adapt to real-world conditions.

[0039] Regarding aspect (4), mobility events (e.g., handover events, etc.) may introduce challenges in maintaining AI / ML dataset continuity, as the AI / ML-related operations (e.g., AI / ML model training, AI / ML-based network optimization / automation, etc.) may rely on a consistent flow of training and inference data to sustain accuracy and reliability. Namely, if the continuity ofthe dataset is disrupted (e.g., dataset transfer is disrupted due to mobility events, etc.), the deployment consistency (e.g., training, executing, etc.) of the AI / ML models may be compromised, leading to potential suboptimal NW-side AI / ML deployment (e.g., inaccurate inference results, non-optimal decision outputs, etc.).

[0040] In this regard, there are no standardized or specified mechanisms in the related art for managing the continuity of the AI / ML data. For instance, it is not clear whether the AI / ML dataset continuity should be managed via radio resource control (RRC) signaling or handled at the media access control (MAC) layer. In this regard, it is not specified whether RRC messages (e.g., Handover Command, etc.) should be extended to include parameters associated with AI / ML dataset continuity, or the AI / ML dataset transfer should be triggered at the target cell upon handover completion (e.g., conditional retrieval of AI / ML data at the target cell when the data is desired, etc.). In addition, there are no standardized or specified mechanisms in the related art for managing the prioritization and expiration of the AI / ML data. For instance, assuming that an AI / ML data is only partially collected at the source cell, it is not clear whether the target cell should continue collect the AI / ML data (e.g., to ensure data completion before training / updating the AI / ML model) or treat the partial AI / ML data as a new dataset instance (e.g., discard any partially collected data).

[0041] Example embodiments of the present disclosure provide systems, methods, mechanisms, and the like, that efficiently and effectively manage data associated with NW-side AI / ML, thereby addressing one or more of the problems described above with respect to aspects (l) to (4).

[0042] Specifically, with respect to aspect (1), example embodiments of the present disclosure introduce and exemplify various triggers (e.g., event-based triggers, etc.) that may bestandardized to ensure consistency across network deployments and vendor implementations. These triggers may include, for example, a Layer 3 (L3) measurement-based event (e.g., X1 / X2 similar to A1 / A2) that may act as a stable baseline for activating the data collection / logging, a beam-level measurement-based event (e.g., a beam transition event), a Layer 1 (Ll)-based event (e.g., a LI degradation event), and the like. Further, example embodiments of the present disclosure also introduce a new Information Element (IE) to provide control over data collection or logging durations. For instance, including this IE into an RRC message may allow the data collection / logging to persist while one or more event conditions are fulfilled and automatically terminate when the event conditions are no longer met, provide short-term (e.g., approximately 100 ms) data collection / logging for transient radio condition changes while avoiding unnecessary data accumulation, provide ext ended / 1 ong-term (e.g., approximately Is) data collection / logging for major beam transitions where capturing longer-term data is desired for AI / ML model training, and the like, thereby optimizing the balance between dataset completeness and signaling overhead. In view of the above, example embodiments of the present disclosure also exemplify systems and mechanisms that may be implemented by a network entity (e.g., a base station) to provide, to a UE, an RRC message that includes information associated with a condition(s) that triggers the data collection / logging, and / or a duration that indicates a time window of the data collection / logging. By leveraging example embodiments of the present disclosure, the network entity may effectively and efficiently configure or guide the UE to implement appropriate data collection for NW-side AI / ML purposes and provide clear and standardized data collection triggers tailored to specific radio environment dynamics, thereby achieving a balance between ensuring dataset completeness for NW-side AI / ML purposes and minimizing signaling overhead and / or redundant data accumulation.

[0043] With respect to aspect (2), example embodiments of the present disclosure introduce and exemplify enhancements to the MDT framework to support real-time (or near realtime) and Al / ML-related data collection requirements. These enhancements include: enabling MDT logging while the UE is in RRC CONNECTED state to facilitate real-time (or near realtime) AI / ML dataset generation, and incorporating AI / ML-related measurements / parameters (e.g., SINR trends, beam transitions, etc.) into MDT reports. Furthermore, example embodiments of the present disclosure introduce and exemplify a hybrid control mechanism for MDT data collection / logging. In this hybrid control mechanism, network-controlled MDT may be utilized as a baseline MDT mode for dataset consistency, while UE-initiated MDT may be allowed or utilized under conditions (e g., predefined by the network entity or associated users) to enable responsive data collection in dynamic environments. To support the hybrid control mechanism, example embodiments of the present disclosure introduce a Medium Access Control (MAC) Control Element (CE) signaling mechanism that enables the UE to request additional MDT data collection / logging upon detecting one or more specific conditions (e.g., rapid network condition changes, anomalous conditions, etc.). Furthermore, example embodiments of the present disclosure also introduce and exemplify an event-based MDT mechanism that may align data collection / logging triggers with AI / ML data collection / logging requirements. For instance, example embodiments may configure MDT to activate upon detection of a specific event (e.g., beam switches, SINR fluctuation, mobility event, etc.) to ensure only relevant data is collected / logged. Further, example embodiments also introduce and exemplify an RRC singling mechanism to dynamically manage event-based MDT activation and deactivation, thereby ensuring Al / ML-related datasets capture meaningful / useful transitions while minimizing network overhead. In view of the above, example embodiments of the present disclosure also exemplifysystems and mechanisms that may be implemented by a network entity (e.g., a base station) to transmit, to a UE, information for initiating an MDT logging session for collecting measurement data associated with an Al / ML model (e.g., an Al / ML model for NW-side purposes), and then receive an MDT report from the UE. The MDT report may include the measurement data collected by the UE during the MDT logging session, which is initiated based on the information provided by the network entity. By leveraging example embodiments of the present disclosure, the network entity may effectively and efficiently configure the UE with AI / ML-optimized MDT parameters and triggers, thereby ensuring the data collected during the associated MDT logging can capture appropriate AVML data for NW-side purposes.

[0044] With respect to aspect (3), example embodiments of the present disclosure introduce and exemplify mechanisms to explicitly classify and manage data based on the associated intent or purposes (e.g., data for NW-side Al / ML model training, data for UE-side Al / ML model training, etc.). Specifically, example embodiments of the present disclosure introduce and exemplify a new IE (e.g., in an RRC message, etc.) to provide a clear classification for the data collected for different purposes (e.g., data for NW-side Al / ML purposes, data for UE-side Al / ML purposes, etc.). By leveraging example embodiments, the classification of the collected Al / ML data may provide a clear differentiation between datasets aggregated or collected for different purposes and may thereby maintain dataset integrity, ensure consistency across Al / ML models by defining data categorization rules that align with Al / ML purposes and requirements (e.g., training requirements, etc.), and avoid unnecessary signaling overhead by integrating dataset classification into existing measurement reports where feasible. Furthermore, example embodiments of the present disclosure also introduce and exemplify enhancements to MAC CE signaling to enhance dataset classification and adaptation and support real-time (or nearreal-time) dataset classification, optimization, and filtering. For instance, the network entity may provide one or more MAC CEs to the UE to dynamically classify and manage (e.g., filter, etc.) datasets based on real-time (or near real-time) conditions or requirements while minimizing unnecessary signaling overhead. By leveraging example embodiments, the network entity may provide real-time (or near real-time) dataset differentiations at the AI / ML model level, while adjusting dataset classification and priority levels based on real-time (or near real-time) conditions / requirements and providing filtering preferences to ensure that the AI / ML data is filtered at the UE before transmission. Additionally, the UE may also utilize the MAC CE signaling to request adaptation based on internal conditions, such as low storage availability or power constraints, ensuring energy-efficient data handling. In view of the above, example embodiments of the present disclosure also exemplify systems and mechanisms that may be implemented by a network entity (e.g., a base station) to generate a message (e.g., RRC message, MAC CE message, etc.) that includes one or more IES that indicates a classification of the data, and transmit the message to the UE. In this way, the network entity may provide the UE with standardized categorization rules and dynamic signaling configurations that ensure dataset integrity and consistency. Accordingly, the network entity and UE may effectively distinguish and prioritize diverse AI / ML dataset types, thereby ensuring that the collected data remains relevant to the specific AI / ML purposes (e.g., inference scope, etc.) and resource constraints of both the network entity and the UE.

[0045] With respect to aspect (4), example embodiments of the present disclosure introduce and exemplify solutions to maintain AI / ML dataset continuity and reliability during mobility events (e.g., handover, etc.). Specifically, to address the disruption of training and inference data flows during mobility, example embodiments extend the Handover Commandmessage to include various AI / ML-related parameters and tracking indicators. For instance, the Handover Command message, according to one or more example embodiments, may include at least one of: (a) an identifier (ID) that identifies the ongoing data collection session and maintain tracking across cells, enabling the target cell to recognize the ongoing data collection session, avoid redundant AI / ML dataset resets, and request for missing portions from the source cell if dataset gaps exist (thereby preventing loss of critical AI / ML data), (b) a flag that indicates whether a collected dataset is valid for use in the target cell after the handover, thereby enabling the target cell to adjust the dataset handling to maintain inference accuracy and consistency when needed, (c) an indicator that indicates an un-transferred portion of a dataset of the ongoing data collection session, thereby enabling the target cell to identify the un-transferred portion (if available) and device whether to retrieve missing data or proceed with AI / ML model training without retrieving the un-transferred portion, and (d) information associated with a dataset expiration rule and / or a dataset prioritization rule, thereby ensuring the collected data is relevant to the AI / ML purposes (e.g., AI / ML model training, etc.), preventing data inconsistencies, and reducing unnecessary signaling. In view of the above, example embodiments of the present disclosure also exemplify systems and mechanisms that may be implemented by a network entity (e.g., a base station) to determine that a handover of a UE to a target cell is required and transmit a Handover Command that includes one or more of the above-mentioned parameters / information to the UE and / or a target base station associated with the target cell. Accordingly, the network entity may effectively manage the seamless transfer of AI / ML context and data during mobility event (e.g., handover), allowing a target cell to recognize ongoing collection efforts and request incomplete or missing data portions to prevent the loss of critical training information. By leveraging example embodiments of the present disclosure, the network entity may maintain a consistent anduninterrupted flow of AI / ML data during a mobility event, thereby ensuring that the accuracy and reliability of AI / ML-related operations are not compromised by the mobility event (e.g., cell transitions or handover-induced data gaps).

[0046] It is contemplated that features, advantages, and significances of example embodiments described hereinabove are merely a portion of the present disclosure, and are not intended to be exhaustive or to limit the scope of the present disclosure. Further descriptions of the features, components, configuration, operations, and implementations of the example embodiments of the present disclosure are provided in the following.Example System Architecture and Configurations

[0047] FIG. 1 illustrates a generic system configuration 100, according to one or more example embodiments. As illustrated in FIG. 1, the system configuration 100 includes a network entity 110 and a user equipment UE 120. The network entity 110 may be communicatively coupled to the UE 120 via one or more networks and / or interfaces, and may be configured to exchange information or messages for network-side (NW-side) AVML purposes.

[0048] As described above, in a network-side (NW-side) configuration, one or more network entities may implement or deploy (e.g., train, update, execute, etc.) one or more AI / ML models to provide network-related operations or services. In this regard, “NW-side AI / ML purposes,” “AI / ML-related operations,” and similar descriptions as used herein may include, but are not limited to: the training of AI / ML model(s) at one or more network entities (e.g., using aggregated or filtered data received the UE 120, etc.), the execution or inference of AI / ML model(s) at the network entity(s) for network automations (e.g., automated fault recovery, automated load balancing, etc.) and / or network optimizations (e.g., beam management, radio resource allocation, etc ), the provisioning and management of AI / ML-driven services, the continuous lifecyclemanagement of AI / ML model(s) (e.g., performance monitoring, model retraining / fine-tuning, model switching to adapt to dynamic radio environments, etc.), and any other suitable type of activities or utilization of AI / ML model(s) at the network entity(s).

[0049] Further, the “NW-side AI / ML data” described herein may include data associated with the network, the UE, or any other suitable data, that may be utilized by the network entity 110 for NW-side AI / ML purposes. For instance, as further described below with reference to FIG.2 to FIG. 7, the NW-side AI / ML data may include, but not limited to: radio measurement data (e.g., signal strength, interference trends, etc.), beam-related data (e.g., beam transitions, beamlevel metrics, etc.), Channel State Information (CSI)-related data (e.g., CSI measurement trends, CSI feedback, etc ), mobility-related data (e.g., handover parameters, trajectory logs, mobility patterns, etc.), UE-internal status data (e.g., power consumption, storage availability, motion trajectory, beam selection metric, etc.), network-related operational data (e.g., network traffic / load, resource block utilization, etc.), AI / ML-related metadata (e g., dataset classification / categorization information, model identifiers, performance feedback, etc.), and the like.

[0050] The network entity 110 may include one or more physical or logical network nodes within a network (e.g., 4G LTE network, 5G network, Open Radio Access Network (O-RAN)-based network, etc.) that may be configured to perform management, control, and / or data processing for NW-side AI / ML data. For instance, the network entity 110 may include, but is not limited to: a base station (e g., a 4G eNodeB, a 5G gNodeB, etc.), a RAN node (e.g., Next Generation RAN (NG-RAN), Open RAN (0-RAN), etc.) or an associated component (e.g., a Radio Intelligent Controller (RIC), a Centralized Unit (CU), etc.), a core network function or entity (e.g., an Access and Mobility Management Function (AMF), a User Plane Function (UPF), a Network Data Analytics Function (NWDAF), etc.), an AI / ML management or orchestration node,a cloud-based server, or any other suitable network node that may be configured to manage or deploy AI / ML model(s) for NW-side AI / ML purposes.

[0051] The UE 120 may include any suitable device, terminal, apparatus, or system that may communicate with the network entity 110 via a wireless connection, a wired connection, or a combination thereof. The UE 120 may also communicate with the network entity 110 via any suitable interfaces, such as those defined in one or more technical documents of one or more standard organizations (e.g., 3GPP, O-RAN Alliance, etc.). By way of example, the UE 120 may include, but is not limited to: a mobile device (e.g., a mobile phone / smartphone, a tablet, a laptop, a wearable device smartwatches and smartglasses, a portable hotspot, a wireless sensor, etc.), a static device (e.g., an Internet of Things (loT) device like sensors and smart home / office devices, an internet router, etc.), a vehicle to everything (V2X) communication terminal, a drone or unmanned aerial vehicle (UAV), or any other suitable terminal or device that may be configured to provide a request and / or report data to the network entity 110 for NW-side AI / ML purposes.

[0052] As illustrated in FIG. 1, the network entity 110 and UE 120 may communicate and interoperate with each other to facilitate the management of AI / ML data or datasets involved in or associated with NW-side AI / ML purposes. Generally, the communication between the network entity 110 and UE 120 may involve the exchange of management configuration and / or signaling in the downlink and the transmission of AI / ML data, reports, and / or requests in the uplink.

[0053] The NW-side AI / ML data management configuration and / or signaling provided by the network entity 110 to the UE 120 may include various control-plane messages and / or lower-layer signals that may include configurations or parameters that instruct or guide the UE 120 to perform one or more operations to appropriately collect and manage the AI / ML data, such as (but not limited to): data collection / logging activation and deactivation, data collection / loggingduration, data filtering, data prioritization, configuration for an MDT logging session, data collection / logging requirement, data collection / logging session information, and the like. The network entity 110 may provide the NW-side AI / ML data management configuration and / or signaling to the UE 120 via various methods, such as (but not limited to): including the desired configurations or parameters into one or more Information Elements (IES) of a Radio Resource Control (RRC) message or a Medium Access Control (MAC) Control Element (CE). In this way, the network entity 110 may effectively and efficiently instruct or guide the UE 120 on what kind of AI / ML data should be collected, how the AI / ML data should be collected, under what condition the data collection / logging can be activated / deactivated, how the AI / ML data can be prioritized or categorized, how the AI / ML data can be filtered, and the like.

[0054] On the other hand, the NW-side AI / ML data, report, and / or request provided by the UE 120 to the network entity 110 may include the information required for the network entity 110 to deploy (e.g., train, manage, execute, etc.) one or more AI / ML models for NW-side AI / ML purposes. In addition to or in alternative to the above-mentioned NW-side AI / ME data, the UE 120 may provide a measurement report (e.g., MDT report, RRC measurement report, etc.) that contains the collected or logged NW-side AI / ML data, a request (e.g., a request for additional data collection / logging, a request for dataset adaptation based on internal conditions of the UE, etc.), or the like.

[0055] According to example embodiments, the communication between the network entity 110 and UE 120 may involve a coordinated or hybrid interaction. Specifically, while the network entity 110 may provide the foundational configuration and oversight, the UE 120 may actively participate in the management of the NW-side AI / ML data by, for example, providing real-time (or near real-time) reports and data collection / logging triggering requests based on itslocalized observations of the radio environment and / or its internal operational status. Accordingly, this bidirectional information exchange may ensure that the NW-side AI / ML data is collected and managed in an efficient, responsive, and standardized manner.

[0056] It is contemplated that the configuration in FIG. 1, as well as the described features and mechanisms, are merely examples and the scope of the present disclosure should not be limited thereto. Specifically, in some example implementations, the network entity 110 may communicate with multiple UEs, the UE 120 may communicate with multiple network entities, the network entity 110 and UE 120 may communicate with each other via an intermediate node / terminal, and the like, without departing from the scope of the present disclosure. Descriptions of an example environment that may implement the network entity 110 and UE 120 are provided below with reference to FIG. 10.

[0057] Further, it is contemplated that the network entity 110 and UE 120 may communicate and interoperate with each other to implement various methods and operations, in addition to those described above. For instance, as further described below with reference to FIG.2 to FIG. 7 (and as exemplified in the example use cases in FIG. 8A to FIG. 8C), the network entity 110 and UE 120 may communicate and interoperate with each other to implement various methods and operations for addressing the shortcomings of the related art in each of the above-mentioned aspects (1) to (4).

[0058] Furthermore, it is contemplated that the network entity 110 and UE 120 may further include components that may be configured to implement the associated functionalities or operations. Descriptions of various example components that may be included in (or may be configured to implement) the network entity 110 and / or UE 120 are provided below with reference to FIG. 9.Example Methods and Operations

[0059] Several example methods and operations, according to one or more example embodiments, are described below with reference to FIG. 2 to FIG. 7. One or more features, parameters, messages, and operations associated with FIG. 2 to FIG. 7 may be similar to those described above with reference to FIG. 1, and redundant descriptions associated therewith may be omitted below for conciseness.

[0060] For descriptive purposes, the example methods and operations may be mainly described herein as being performed by one or more specific network entities, although it can be understood that, in actual implementations, another related network entity(s) and / or the UE may perform similar / related operations, without departing from the scope of the present disclosure. For instance, an operation of a network entity (e.g., network entity 110) receiving a data / message from a UE (e.g., UE 120) may suggest or indicate an operation of the UE providing the data / message to the network entity, an operation of the network entity providing a data / message that includes data / information that enables the UE to implement an operation / function may suggest or indicate an operation of the UE receiving the data / message and utilize the data / information included therein to implement the operation / function, and the like.

[0061] According to example embodiments, one or more operations of the network entity (e.g., base station, RAN, core network, etc.) may be implemented in one or more apparatuses or hardware components. For instance, the network entity (or one or more associated operations) may be implemented in an apparatus / device that includes a processor and a memory storage (or any other suitable storage mediums), wherein the memory storage may include computer-executable instructions which, when executed by the processor, cause the processor to perform one or moreoperations thereof. An example device / apparatus that may implement the network entity (or one or more associated operations) is further described below with reference to FIG. 9.

[0062] The example methods and operations in FIG. 2 to FIG. 7 may be implemented by the network entity to effectively and efficiently manage NW-side AI / ML data, thereby addressing the above-mentioned shortcomings of aspects (1) to (4). Generally, the example methods and operations in FIG. 2 to FIG. 3 may be associated with aspect (1) (Event-Based Data Collection and Periodic Data Collection), the example method and operations in FIG. 4 may be associated with aspect (2) (MDT-Based Data Collection), the example methods and operations in FIG. 5 to FIG. 6 may be associated with aspect (3) (Standardization of NW-side Data Collection and UE-side Data Collection), and the example methods and operations in FIG. 7 may be associated with aspect (4) (Data Collection Across Mobility Events).

[0063] In this regard, although some of the methods and operations may be described separately from one another, it is contemplated that, in some example implementations, the methods and operations in two or more of FIG. 2 to FIG. 7 may be implemented by the same network entity. In this regard, it can be understood that the network entity may perform multiple methods and operations in two or more of FIG. 2 to FIG. 7 in any suitable manner (e.g., simultaneously, sequentially, etc.) and may achieve the associated technical advantages in combination. By way of a non-limiting example, although the methods and operations in FIG. 2 and FIG. 4 are associated with different aspects (and thus, are described independently from each other herein), it can be understood that the network entity may be configured to implement the methods / operations in FIG. 2 and FIG. 4 in any suitable manner (e.g., simultaneously, sequentially, etc.) to thereby addressing the shortcomings of both aspect (1) and aspect (2) and achieve the technical advantages of addressing the shortcomings of both aspect (1) and aspect (2).

[0064] Further, the methods and operations in two or more of FIG. 2 to FIG. 7 may involve the collection of data associated with one or more AI / ML models. In this regard, it can be understood that the collected data may be utilized by the network entity for NW-side AI / ML purposes (e.g., training / fine-tuning one or more AI / ML models, inputting to one or more AI / ML models for inference purpose, providing AI / ML-related services, etc.), and the contents, characteristics, and intents of the collected data may be similar to the “AI / ML data,” “data collected for NW-side AI / ML purposes,” and the like, described above. Thus, it can also be understood that the characteristic and content of the data collected via the method and operations in one of FIG. 2 to FIG. 7 may be applicable to the data collected via the method and operations in another one of FIG. 2 to FIG. 7, and redundant descriptions associated therewith may be omitted for conciseness. Similarly, it can be understood that the characteristic and content of the messages or signals (e.g., RRC message, MAC CE, request message, etc.) involved in the method and operations of one of FIG. 2 to FIG. 7 may be applicable to the messages or signals involved operations in the method and operations of another one of FIG. 2 to FIG. 7, and redundant descriptions associated therewith may be omitted for conciseness.> > Example Methods and Operations associated with Aspect (1)

[0065] FIG. 2 illustrates an example method 200, according to one or more example embodiments. The operations in method 200 may be performed by a network entity (e.g., network entity 110) to communicate with a UE (e.g., UE 120) to manage or control at least one of an eventbased data collection / logging session or a periodic data collection / logging session for NW-side AI / ML purposes.

[0066] As illustrated in FIG. 2, at operation S210, the network entity may be configured to generate a Radio Resource Control (RRC) message that includes information associated with atleast one of (i) a condition that triggers a data collection for collecting data associated with an Artificial Intelligence or Machine Learning (AI / ML) model, or (ii) a logging duration associated with the data collection. Subsequently, at operation S220, the network entity may be configured to transmit the RRC message to the UE. For instance, the network entity may transmit the RRC message to the UE during initial network access, when resuming / reestablishing a connection from an inactive state, or when reconfiguring a connection during an active session to adapt the data collection / logging parameters to the real-time (or near real-time) network conditions. In this way, the network entity may provide the UE with the associated information to autonomously activate, manage, or terminate data collection / logging sessions in alignment with the network-controlled configurations.

[0067] According to example embodiments, the network entity may generate the RRC message based on one or more predefined network policies, one or more Service Level Agreements (SLAs), one or more real-time (or near real-time) network conditions, one or more AI / ML requirements (e.g., training requirements, etc.), and / or the like. As described above with reference to the NW-side AI / ML data, the AI / ML data that may be collected by the UE may include data associated with the network (e.g., radio measurement data like signal strength and interference trends, beam-related data like beam transitions and beam-level metrics, CSLrelated data like CIS measurement trends and CIS feedback, mobility-related data like handover parameters, etc.), data associated with the UE (e.g., power consumption, storage availability, motion trajectory, beam selection metrics, etc.), or any other suitable data that may be collected by the UE for NW-side AI / ML purposes.

[0068] According to example embodiments, the RRC message may include an RRC Configuration / Reconfiguration message, such as: an RRC Connection Setup message, an RRCConnection Reconfiguration message, an RRC Connection Reestablishment message, and the like. As described above, the RRC message may include information associated with one or more of: (a) a condition that triggers the data collection, such as an event to be monitored for activating the data collection, or (b) a logging duration associated with the data collection, such as a time window that indicates when the data collection may be activated, how long the data collection may persist, and when the data collection may be deactivated.

[0069] According to example embodiments, the information associated with the condition that triggers the data collection may be included in one or more Information Elements (IES) of the RRC message. For descriptive purposes, it may be assumed that this information may be included in a new IE “EventBasedLoggingConfig IE”, although it can be understood that the labeling or terminology of the new IE may be different, or said information may be included in any suitable IE of the existing RRC message, without departing from the scope of the present disclosure.

[0070] According to example embodiments, the information associated with the condition that triggers the data collection may include: an event type indicator that indicates an event that the UE may monitor, a threshold parameter that indicates a threshold that triggers the data collection, and a time hysteresis parameter that delays the data collection upon detection of an event.

[0071] In this regard, the event type indicator may indicate which event the UE may monitor, such as at least one of: a Layer 3 (L3) event (e.g., an L3 measurement-based event such as X1 / X2 similar to A1 / A2, etc.), a beam-level event (e.g., an event based on a beam-level measurement-based logging, a beam transition, etc.), or a Layer 1 (LI) event (e.g., an LI SINR degradation, etc.). The threshold parameter may define the numerical value or boundary beyond which the data collection / logging may be activated / triggered (e.g., a threshold of the L3 event thatmay activate / trigger the data collection / logging, etc.). The time hysteresis parameter may specify a time duration for which the UE may wait upon detection of an event (e.g., upon the detection of the event indicated by the event type indicator and / or upon the fulfillment of the threshold defined by the threshold parameter), thereby preventing redundant event triggers (e g., due to minor fluctuations).

[0072] According to example embodiments, the information associated with the logging duration of the data collection may include a parameter (e.g., an indicator, etc.) that indicates that the data collection / logging is to persist while the condition that triggers the data collection is fulfilled and is to terminate when the condition is no longer fulfilled. Further, the information associated with the logging duration of the data collection may include a parameter (e.g., an indicator) that indicates whether a periodicity of the data collection should match with a periodicity of a Channel State Information Reference Signal (CSI-RS).

[0073] According to example embodiments, the information associated with the logging duration of the data collection may be included in one or more Information Elements (IES) of the RRC message. For descriptive purposes, it may be assumed that this information may be included in a new IE “RRCDataLoggingDuration IE” or “LoggingDurationConfig IE”, although it can be understood that the labeling or terminology of the new IE may be different, or said information may be included in any suitable IE of the existing RRC message, without departing from the scope of the present disclosure.

[0074] According to example embodiments, the information associated with the logging duration of the data collection may include at least one of: a short-term logging duration, an extended logging duration, or a network-adjusted logging duration. In this regard, the short-term logging duration may be associated with a transient radio condition change and may include a timewindow of approximately 100 milliseconds (ms), which may be useful for the data collect! on / logging of transient radio condition changes or fluctuations, while avoiding unnecessary data accumulation. On the other hand, the extended logging duration may include a time window of approximately 1 second (s) or more, which may be useful for the data collection / logging of persistent radio changes (e.g., changes in beam / SINR conditions, etc.). Thus, the extended logging duration may be associated with a beam transition event. Further, the network-adjusted logging duration may include a time window dynamically adjusted by the network entity (e.g., when congestion control is activated, etc.). For instance, the network-adjusted logging duration may be determined by the network entity based on at least one of: a current network congestion status, or a dataset requirement of the AT / ML model.

[0075] In view of the above, by implementing the method and operations in FIG. 2, the network entity may configure the activation and / or deactivation of data collection / logging by including information of one or more standardized conditions that may trigger / terminate the data collection / logging in an RRC message and provide the RRC message to the UE, thereby ensuring consistent activation / termination of data collection / logging across different network deployments and vendor implementations. In addition, the network entity may also configure how long the data collection / logging session may last after the data collection / logging session is triggered / activated by including information of one or more logging durations in the RRC message, and then provide the RRC message to the UE. Upon receiving the RRC message from the network entity, the UE may monitor the radio conditions based on the configuration information included in the RRC message, and then activate / terminate the data collection / logging session accordingly. For instance, the UE may monitor the radio conditions and activate / terminate the data collection / logging session upon detecting that a condition defined in the RRC message (e.g., an event that fulfills a conditiondefined by a threshold, etc.), collect the data during the logging duration defined in the RRC message (if applicable) or for a predefined time duration, and provide the collected data to the network entity for NW-side AI / ML purposes.

[0076] Advantageously, by implementing the method and operations in FIG. 2, the network entity may optimize the trade-off between dataset completeness and signaling overhead, while ensuring standardized and consistent data collection for NW-side AI / ML purposes across diverse network deployments and vendor implementations.

[0077] By way of a non-limiting example, assuming that the network entity is a gNodeB (gNB) and the RRC message is an RRC Reconfiguration message. The gNB may include information for configuring an event-based data collection in an IE of the RRC Reconfiguration message (e.g., an “EventBasedLoggingConfig IE”, etc.), thereby specifying one or more event conditions that may trigger data collection / logging for NW-side AI / ML purposes. Said information may include an event type indicator (“EventTriggerType”) that indicates an event (e.g., an L3 measurement, a beam transition, an Ll-SINR degradation, etc.) the UE may monitor, a threshold parameter (“TriggerThreshold”) that indicates a threshold beyond which the data collection may be activated, and a time hysteresis parameter (“TimeHysteresis”) that delays the data collection upon detection of the event to prevent redundant event triggers (e.g., due to minor fluctuations, etc.).

[0078] Additionally or alternatively, the gNB may include information for configuring a logging duration of the data collection (e.g., event-based data collection, periodic data collection, etc.) in an IE of the RRC Reconfiguration message (e.g., a “LoggingDurationConfig IE”, etc.). Said information may indicate at least one of a short-term logging (approximately 100 ms) for transient fluctuations, an extended logging (approximately Is or more) for persistent changes inbeam / SINR conditions, or a network-adjusted logging duration (if congestion control is activated). In this example, it is assumed that the RRC Reconfiguration message includes the information for configuring the event-based data collection / logging, as well as the information for configuring the logging duration. Thus, the information for configuring the logging duration included in the RRC Reconfiguration message may configure the logging duration of the event-based data collection / logging.

[0079] Upon generating the RRC Reconfiguration message, the gNB may provide the RRC Reconfiguration message to the UE (e.g., during an active connection session, etc.) to configure the data collection / logging at the UE. Upon receiving the RRC Reconfiguration message, the UE may continuously (or periodically) monitor one or more radio conditions based on the associated IE in the RRC Reconfiguration message (e.g., “EventBasedLoggingConfig IE”, etc.), and then activate the data collection / logging upon detecting one or more events that fulfill one or more conditions defined in the associated IE in the RRC Reconfiguration message.

[0080] For instance, if the UE detects an L3-based event (e.g., X1 / X2 threshold exceeded, etc.), the UE may activate or initiate the data collection / logging. As another example, if the UE detects that a beam transition occurs, the UE may cross-check the last reported beam index and initiate the data collection / logging only if the change is significant (e.g., the change exceeds a predefined threshold, etc.). As yet another example, if the UE detects an Ll-SINR drop, the UE may initiate the data collection / logging but delay activation according to time hysteresis parameter (“TimeHysteresis”) to avoid the activation of the data collection / logging due to minor Ll-SINR variations.

[0081] Upon triggering or activating the data collection / logging, the UE may start collecting / logging relevant data (e.g., measurements, etc.) and buffer the collected / logged data,according to the associated IE in the RRC Reconfiguration message (e.g., “LoggingDurationConfig IE”, etc.). For instance, the UE may perform short-term logging (e.g., approximately 100 ms) to collect / log data associated with transient fluctuations, may perform extended logging (e.g., approximately Is or above) to collect / log data associated with persistent changes (e.g., changes in beam / SINR conditions, etc.), and / or may perform the data logging according to the network- adjusted logging duration to collect / log the data according to the realtime (or near real-time) conditions (e.g., network congestion levels, AI / ML model requirements, etc.).

[0082] Upon collecting the data, the UE may transmit the collected data to the network entity. For instance, the UE may transmit the collected data to the network entity after the data collection / logging session is completed or terminated. Accordingly, the network entity may utilize the data collected by the UE for the NW-side AI / ML purposes. In some example embodiments, the network entity may further utilize the data collected by the UE to adjust a logging duration for a subsequent data collection / logging session. Descriptions of an example method and operations associated therewith are provided below with reference to FIG. 3.

[0083] FIG. 3 illustrates an example method 300, according to one or more example embodiments. The operations in method 300 may be performed by a network entity (e.g., network entity 110) to communicate with a UE (e.g., UE 120) to adjust a logging duration for a subsequent data collection / logging session, based on data collected by the UE in a data collection / logging session. It is contemplated that the network entity and UE that may be involved in method 300 may be similar to those involved in method 200, and one or more operations in method 300 may be performed subsequent to operation S220 of method 200.

[0084] As illustrated in FIG. 3, at operation S310, the network entity may be configured to receive a measurement report from the UE. The measurement report may include data collected by the UE in accordance with the RRC message (provided by the network entity to the UE at operation S220 in method 200). For instance, the measurement report may include measurement data (e.g., signal strength and quality of the serving cell and potential neighbor cell, etc.) and / or internal data of the UE (e.g., power consumption, storage capability, etc.) that may be utilized by the network entity for NW-side AI / ML purposes, the event triggers (e.g., information indicating which event(s) trigger the data collection and / or transmission of the measurement report, etc.) that may be utilized by the network entity to distinguish the AI / ML-related measurement report from non-AI / ML-related measurement report, identification information (e.g., UE-related identifiers such as International Mobile Subscriber Identity (IMSI), timestamps, location information, etc.) that may be utilized by the network entity to identify the UE, and the like. In some example embodiments, the measurement report may include an RRC measurement report, an MDT measurement report, and the like.

[0085] Upon receiving the measurement report, at operation S320, the network entity may evaluate the measurement report to determine an adjustment to a logging duration for a subsequent data collection / logging session. According to example embodiments, the network entity may process the data in the measurement report and determine whether the current logging duration is insufficient or excessive. For instance, if the network entity detects that the measurement data in the measurement report were still fluctuating significantly at the end of the logging duration (e.g., the signal had not yet stabilized after a beam transition event, etc.), the network entity may determine that the current logging duration is insufficient to capture the complete data (e.g., a full beam transition, etc.) and may thus decide to increase the logging duration of the subsequent datacollection / logging session to ensure that the UE may capture the complete data in the subsequent data collection / logging session. Conversely, if the network entity detects a prolonged period of static or stable measurement data at the end of the logging duration (e.g., the last X ms of the logging duration shows not variation, etc.), the network entity may determine that the current logging duration is excessive and may thus decide to decrease the logging duration of the subsequent data collection / logging session to reduce unnecessary signaling overhead and data accumulation.

[0086] In addition to or in alternative to the data in the measurement report, the network entity may also determine the adjustment to a logging duration for a subsequent data collection / logging based on the uplink radio conditions and / or UE internal status, which may (but not necessarily) be utilized for the NW-side AI / ML purposes. For instance, the network entity may determine an uplink signal quality (e.g., uplink Signal-to-Interference-plus-Noise Ratio (SINK) or Reference Signal Received Power (RSRP), etc.) based on the data included in the measurement report, and then determine an appropriate adjustment to the subsequent logging duration according to the uplink signal quality. By way of a non-limiting example, if the network entity determines that the uplink signal quality is poor (e.g., transmitting long, data-heavy measurement reports is suboptimal and may result in transmission failures or excessive latency, etc.), the network entity may decide to decrease the logging duration to reduce the payload size of the subsequent measurement report, thereby ensuring successful transmission even under poor uplink radio conditions. As another example, if the network entity determines (e.g., based on the power consumption of the UE) that the UE is having a low battery status or operating in a power-saving mode, the network entity may decides to decrease the logging duration to minimize the activeprocessing time (and thus the power consumption) required by the UE for data collection and transmission.

[0087] Referring still to FIG. 3, at operation S330, the network entity may be configured to transmit, to the UE, a medium access control (MAC) control element (CE) that indicates the adjustment. For instance, assuming that the network entity would like to adjust the logging duration from a first configuration to a second configuration (e.g., increasing the logging duration, decreasing the logging duration, change the logging duration from short-logging to extended logging, etc.), the network entity may include a payload that defines the intended adjustment into the MAC CE (e.g., X bits payload indicates adjustment X, etc.).

[0088] According to example embodiments, the network entity may transmit the MAC CE to the UE as a part of a downlink data stream. For instance, when the network entity transmits downlink data packets to the UE (e.g., via Physical Downlink Shared Channel (PDSCH), etc.), the network entity may send the MAC CE along with the downlink data packets to the UE. On the other hand, the network entity may transmit the MAC CE to the UE as a standalone downlink data packet (e.g., when there is no downlink user data, etc. ). Further, the network entity may transmit the MAC CE to the UE as soon as the adjustment to the logging duration is determined (e.g., transmit the MAC CE into the next available downlink slot allocated to the UE), or after a period of time from the determination of the adjustment to the logging duration (e.g., X ms after the determination of the adjustment, etc.).

[0089] In view of the above, by implementing the method and operations in FIG. 3, the network entity may provide an adaptive control on the data collection / logging session by dynamically adjusting the logging / data collection duration based on the actual, real-time / near realtime conditions or requirements. Specifically, by implementing the method and operations in FIG.3, the network entity may establish a dynamic feedback loop for adjusting the logging duration of the data collection / logging session, according to the measurement report received from the UE. For instance, by implementing the method and operations in FIG. 3, the network entity may perform adaptive control on logging duration, allowing the logging window to be dynamically expanded or reduced in response to the actual characteristics of the radio environment observed by the UE, the current UE operational status, and the like.

[0090] Advantageously, by implementing the method and operations in FIG. 3, the network entity may enable real-time (or near real-time) optimization of the data collection process without the latency associated with higher-layer signaling (e.g., RRC signaling, etc.). This adaptive mechanism allows the system to maintain high-fidelity datasets for NW-side AT / ML purposes by ensuring critical event transitions are fully captured, while simultaneously minimizing uplink signaling overhead and UE power consumption by preventing excessive logging during periods of stable radio conditions.

[0091] In view of the above, the methods and operations described hereinabove may provide a robust and efficient mechanism for AI / ML data collection for NW-side AI / ML purposes, ensuring operational consistency while optimizing radio resource utilization. Specifically, by leveraging the methods and operations in FIG. 2 and FIG. 3, the shortcomings of aspect (1) as described above may be effectively addressed, since the network entity may utilize standardized event-based triggers to ensure consistent data collection / logging activation across diverse implementations, and employ flexible logging duration controls (via RRC signaling and adaptive MAC CE signaling) to dynamically optimize the balance between capturing complete AI / ML data and minimizing network signaling overhead.> > Example Methods and Operations associated with Aspect (2)

[0092] FIG. 4 illustrates an example method 400, according to one or more example embodiments. The operations in method 400 may be performed by a network entity (e.g., network entity 110) to communicate with a UE (e.g., UE 120) to manage and provide an MDT-based data collection / logging session forNW-side AI / ML purposes.

[0093] As illustrated in FIG. 4, at operation S410, the network entity may be configured to transmit, to the UE, a message that includes information for initiating a Minimization of Drive Tests (MDT) logging session at the UE for collecting data associated with an AI / ML model. The collected data may be utilized by the network entity for NW-side AI / ML purposes, in a similar manner as described above with reference to FIG. 1 to FIG. 3. Accordingly, at operation S420, the network entity may be configured to receive, from the UE, an MDT report that includes data collected by the UE during the MDT logging session (which is initiated by the UE based on the information of the message provided by the network entity).

[0094] According to example embodiments, the message that includes the information for initiating the MDT logging session may include an RRC message. In this regard, the RRC message may include an RRC Configuration / Reconfiguration message, such as: an RRC Connection Setup message, an RRC Connection Reconfiguration message, an RRC Connection Reestablishment message, and the like.

[0095] According to example embodiments, the information for initiating the MDT logging session may include at least one of: (a) an MDT mode indicator (may be labelled as “MDTMode” herein) that indicates whether the MDT logging session is an immediate MDT or a logged MDT. The immediate MDT may refer to an MDT logging mode in which the data may be collected and reported by the UE in real-time / near real-time while the UE is in an RRC CONNECTED state, while the logged MDT may refer to an MDT logging mode in whichthe data may be collected while the UE in an RRC IDLE state and / or RRC INACTIVE state, and the collected data may be stored / buffered at the UE for a predefined time period and later reported by the UE when the UE transitions to the RRC CONNECTED state; (b) a data type parameter (may be labelled as “DataTypes” herein) that indicates one or more types of data (e.g., Signal-to-Interference-plus-Noise Ratio (SINR) trends, beam transitions, Channel State Information (CSI) feedback, etc.) to be collected (by the UE) during the MDT logging session; and (c) a storage duration parameter (may be labelled as “StorageDuration” herein) that indicates a time period for which the data collected during the MDT logging session may be buffered at the UE before being transmitted to the network entity. The aforesaid information may be utilized by the UE to configure the MDT logging session, and may be labelled as “MDTLoggingConfig” herein.

[0096] According to example embodiments, the MDT report may include data collected by the UE via the MDT logging session in an RRC Connected (RRC CONNECTED) state, an RRC Idle (RRC IDLE) state, and / or an RRC Inactive (RRC INACTIVE) state. In this regard, the data may include at least one of: a SINR trend, a beam switching log, or a CSI measurement trend. The collected data may be consistent with the data type parameter (“DataTypes”) included in the message provided by the network entity.

[0097] In view of the above, by implementing the example embodiments, the network entity may extend the MDT to support AI / ML-specific data collection. Specifically, the network entity may guide or instruct the UE to configure the MDT to initiate an MDT logging session in RRC CONNECTED state to facilitate real-time AI / ML data collection and dataset generation, in addition to or in alternative to initiating an MDT logging session in RRC IDLE state and / or RRC INACTIVE state. Further, the network entity may guide or instruct the UE to collect and incorporate AI / ML-related data (e g., SINR trends, beam transitions, etc.) into the MDT reports.

[0098] According to example embodiments, the network entity may be configured to implement a hybrid control mechanism for MDT logging. This hybrid control mechanism may enable the network entity to provide a network-controlled MDT logging session as the baseline MDT logging (for ensuring dataset consistency), while also enabling the UE to initiate or request additional MDT logging session(s) under predefined network-configured conditions (for enabling responsive data collection in dynamic environments).

[0099] In this regard, the network entity may provide the message to the UE (at operation S410) under two main scenarios: (a) for configuring an initial MDT logging session, and (b) for configuring an additional MDT logging session after the previous MDT logging session (e.g., the initial MDT logging session, an MDT logging session after the initial MDT logging session, etc.). The contents of the message that may be provided to the UE may vary according to the specific scenario or may be similar for both scenarios.

[0100] According to example embodiments where the network entity provides the message to the UE to configure an initial MDT logging session, the message (e g., RRC message) may include an event-based MDT trigger configuration that configures the UE to activate the MDT logging session upon an occurrence of an event, in addition to or in alternative to one or more of the information for initiating the MDT logging session as described above (e.g., MDTLoggingConfig such as the MDTMode, Data Type, and StorageDuration).

[0101] For instance, similar to the data collection triggering condition described above with reference to FIG. 2, the event-based MDT trigger configuration may include a combination of an event type parameter that indicates a specific event that may initiate the MDT logging session (e.g., any suitable type of network-related events, such as a beam transition, an S1NR fluctuation / degradation, a mobility event, etc.), a threshold parameter associated with the eventabove which the MDT logging session may be initiated (e.g., initiate MDT logging session when the SINR fluctuation is above X threshold, etc.), a time hysteresis that delays the initiation of the MDT logging session upon detection of the event (e.g., delay the initiation of MDT logging session by Y ms when the threshold parameter is satisfied, etc ), and the like. The event-based MDT trigger configuration may be controlled or decided by the network entity based on, for example, one or more network policies, one or more SLAs, one or more network conditions, and the like.

[0102] In view of the above, by implementing example embodiments of the present disclosure, the network entity may leverage an event-based MDT mechanism to initiate and align the MDT logging session triggers with real-time / near real-time requirements (e.g., AI / ML data collection requirements, network conditions, etc.). Specifically, the network entity may dynamically manage the activation and deactivation of the event-based MDT logging sessions by adjusting the event-based MDT trigger configuration based on one or more real-time / near realtime requirements, and then provide the adjusted configuration to the UE (e g., via RRC signaling, etc.). Accordingly, the UE may configure and initiate the MDT logging session(s) to activate upon detecting the network-specified event(s) and configurations, thereby ensuring that only relevant data is collected during the MDT logging session(s), effectively increasing the integrity of the collected data while minimizing network overhead.

[0103] According to example embodiments where the network entity provides the message to the UE to configure an additional MDT logging session after the previous MDT logging session (e g., the initial MDT logging session, an MDT logging session after the initial MDT logging session, etc.), the network entity may provide the message upon receiving, from the UE, a request for an additional MDT logging session.

[0104] Specifically, in addition to the event-based MDT mechanism that enables the UE to initiate an initial MDT logging session, example embodiments of the present disclosure also introduce a mechanism that allows the UE to request additional MDT logging when desired. For example, when the UE detects rapid radio frequency changes or anomalous conditions (e.g., deep fading, interference, beam failure, rapid SINR drop, etc.), the UE may be allowed to trigger the request for one or more additional MDT loggings. As further described below, the network entity may evaluate the request for additional MDT logging(s), and may then approve / deny the request. This mechanism may be referred to the “MDTRequestMACCE mechanism” or any other suitable terminologies. An example use case associated therewith are described below with reference to FIG. 8A. Tn this regard, in addition to or in alternative to one or more of the information for initiating the MDT logging session as described above (e.g., MDTLoggingConfig, event-based MDT trigger configuration, etc.), the message (e.g., RRC message) provided by the network entity to the UE (at operation S410) may include at least one of: a baseline MDT mode indicator (may be labelled as “BaselineMDTMode” herein) that indicates whether the MDT logging session should start with an immediate MDT or a logged MDT under a hybrid MDT logging mode, or a request configuration parameter (may be labelled as “UEMDTRequestConfig” herein) that indicates whether the UE is allowed to request additional logging under a predefined condition.

[0105] Thus, upon receiving the message (e.g., RRC message) from the network entity, the UE may collect the associated data for NW-side AI / ML purposes according to the configurations in the message. For instance, if the network entity has selected immediate MDT as the network-controlled MDT mode (e.g., as defined in the MDTMode / BaselineMDTMode of the message), the UE may initiate the MDT logging session and collect / log the associated data while in RRC CONNECTED state, and then continuously / periodically provide the collected data in theMDT report (may be labelled as “MDTMeasurementReport” herein) to the network entity. Conversely, if the network entity has selected logged MDT as the network-controlled MDT mode, the UE may initiate the MDT logging session, collect / log the associated data, buffer / store the collected data locally while in RRC IDLE state and / or RRC INACTIVE state, and then provide the stored / buffered data in the MDT report to the network entity when the UE enters RRC CONNECTED state.

[0106] In this regard, if the UEMDTRequestConfig in the message provided by the network entity (e.g., the RRC message) indicates that the UE is allowed to request additional logging under a predefined condition, the UE may determine whether any additional MDT logging session is desired (e.g., whether the predefined condition is satisfied, etc.). For instance, the UE may determine whether the changes in network or radio frequency conditions exceed a predefined threshold, whether the UE’ s internal operational status (e.g., battery level, storage availability, etc.) is sufficient to collect, buffer, and transmit the network-intended data, and the like. Accordingly, based on determining that an additional MDT logging session(s) is desired, the UE may send, to the network entity, a MAC CE (may be labelled as “AIDataLoggingRequest MAC CE” herein) that includes a request for activating an additional MDT logging session. The request may include information indicating a reason for requesting the additional MDT logging session, a desired configuration of the additional MDT logging session, or the like. Further, the UE may transmit the MAC CE along with the MDT report to the network entity, or may transmit the MAC CE after / before transmitting the MDT report to the network entity.

[0107] Upon receiving the MAC CE, the network entity may evaluate the request for additional MDT logging session(s) and approve / deny the request accordingly. Assuming that the network entity approves the request, the network entity may send an acknowledgement (ACK)message to the UE to approve the UE to initiate the additional MDT logging session(s) according to the previously configured MDT settings, or may send another message (e.g., another RRC message) to the UE to configure the additional MDT logging session(s).

[0108] According to example embodiments, the network entity may periodically, continuously, or dynamically adjust one or more parameters of the MDT logging session, based on real-time / near real-time requirements or conditions. For instance, the network entity may dynamically adjust a logging frequency (e.g., how often the MDT logging session may be initiated) based on the changes in dataset requirements or conditions (e.g., increase the logging frequency when more dataset is desired, etc.), modify a logging duration (e.g., how long each MDT logging session may persist) based on the quality or characteristic of the data collected during the MDT logging session (e.g., increase logging duration if the collected data shows that longer logging duration is desired, etc.), modify a data type to be collected or prioritized based on network congestion, and the like. Accordingly, the network entity may provide a MAC CE (may be labelled as “MDTLoggingAdjustMACCE” herein) that includes information associated with the determined adjustment(s) to the UE, such that the UE may appropriately implement the adjustment(s) on the associated MDT settings.

[0109] According to example embodiments, the network entity may also communicate with the UE to optimize the resources of the UE. For instance, if the network entity determines changes in AI / ML dataset requirements, the network entity may send a message (may be labelled as “MDTDataClearRequest” herein) to request the UE to clear or discard the outdated data from its local storage. The message may include an RRC message, a MAC CE, or any suitable type of message that may include the requested information.

[0110] In view of the above, by implementing the method and operations described herein, the network entity may effectively and efficiently utilize the MDT framework to collect / log data for NW-side AI / ML purposes. Specifically, by implementing the method and operations in FIG.4, the network entity may configure or guide the UE to extend the MDT mechanisms to support AI / ML-related data collection (e.g., by enabling the activation of MDT logging session when the UE is in RRC CONNECTED state to facilitate real-time / near real-time AUML dataset generation, incorporating AI / ML-related data into MDT reports, etc ). Further, by implementing the method and operations in FIG. 4, the network entity may also implement a hybrid control mechanism that combines robust network-controlled MDT logging sessions as the baselines with dynamic UE-initiated MDT logging sessions, allowing the UE to follow network-defined MDT settings while allowing selective UE-driven logging. For instance, the network entity may configure the UE to perform an initial MDT logging session, while allowing the UE to autonomously request additional logging (e.g., via a MAC CE signaling) when needed. Furthermore, by implementing the method and operations in FIG. 4, the network entity may also implement an event-based MDT mechanism to align MDT logging triggers with AI / ML data collection requirements, thereby increasing the data integrity (since only relevant data may be collected) and minimizing network signaling overhead.

[0111] Advantageously, the methods and operations of the example embodiments may provide a flexible and intelligent MDT framework for NW-side AI / ML purposes, effectively bridging the gap between the existing MDT framework and the specific AI / ML requirements. Specifically, by leveraging the methods and operations of the example embodiments, the shortcomings of aspect (2) as described above may be effectively addressed, since the network entity may extend MDT capabilities to support real-time applicability in the connected state andincorporate AI / ML-related data into MDT reports, utilize a hybrid control mechanism to ensure that the MDT logging sessions are sufficient to capture comprehensive data in dynamic environments, and implement event-based MDT mechanisms to ensure that the integrity of the collected data while minimizing the storage and uplink transmission of redundant or non-informative data.>> Example Methods and Operations associated with Aspect (3)

[0112] FIG. 5 illustrates an example method 500, according to one or more example embodiments. The operations in method 500 may be performed by a network entity (e.g., network entity 110) to communicate with a UE (e.g., UE 120) to manage classification of data collected (or to be collected) by the UE for AI / ME purposes (e.g., NW-side AI / ME purposes, UE-side AT / ML purposes such as deployment of an AI / ML model at the UE, etc.).

[0113] As illustrated in FIG. 5, at operation S510, the network entity may be configured to generate a message that includes information that indicates a classification of data to be collected by the UE. The data may be associated with an AI / ML model, and the classification of the data may include one of: an NW-side AI / ML data or a UE-side AI / ML data. According to example embodiments, the network entity may be configured to generate the message based on one or more network policies. Further, it can be understood that, in some example embodiments, the message may further include information associated with the configurations for initiating a data collection / logging session, and the like, as described above with reference to FIG. 2 to FIG. 4.

[0114] The NW-side AI / ML data may be utilized by the network entity for NW-side AI / ML purposes (e.g., for deploying the AI / ML model to optimize network performance, for training the AI / ML model, etc.). In this regard, in addition to or in alternative to the NW-side AI / ML data described above with reference to other example embodiments, the NW-side AI / MLdata may include at least one of: a CSI measurement, an interference map, or a mobility pattern. One or more of these data may be useful for the AI / ML model to capture spatial diversity and optimize resource allocation and handover strategies.

[0115] According to example embodiments, the network entity may communicate with multiple UEs. In this regard, the NW-side AI / ML data may include data aggregated from multiple UEs, where such multi-UE aggregated data may enable network-wide AI / ML operations (e.g., AI / ML inference for network-level optimization, etc.). For instance, the NW-side AI / ML data may include at least one of: CSI measurements aggregated from multiple UEs, interference maps across multiple network sectors (or network cells), mobility patterns, and the like.

[0116] On the other hand, the UE-side AI / ML data may be utilized by another UE for local deployment of the AI / ML model (e.g., local, UE-based training on the AI / ML model, etc.) and / or by the network entity for deployment of the AI / ML model to provide UE-related services (e.g., customized network optimizations, online AI / ML model training services, etc.). In this regard, the UE-side AI / ML data may include localized, per-device data that may enhance individual performance. For instance, the UE-side AI / ML data may include at least one of: a motion trajectory log, a power consumption pattern, or a beam selection metric. One or more of these data may be useful for the AI / ML model to model mobility effects, optimize energy efficiency, and refine UE-specific inference parameters.

[0117] According to example embodiments, the message (which may be generated by the network entity at operation S510) may include at least one of: an RRC message (e.g., RRC Configuration / Reconfiguration message, etc.) or a MAC CE. In the case of the RRC message, the information that indicates the classification of the data to be collected may be included in an IE of the RRC message (e.g., the IE may be implemented as an enumerated or descriptive field thatindicates the classification). This IE may be a new IE (introduced by the example embodiments) and may be labelled as “RRCDataCollectionType IE” herein. In the case of the MAC CE (which may be labelled as “Al DatasetCategorylndication MAC CE” herein), the information that indicates the classification of the data to be collected may be included as a MAC CE payload that defines the intended classification (e.g., X bits payload indicates “NW-side AI / ML data”, Y bits payload indicates “UE-side AI / ML data”, etc.).

[0118] Referring still to FIG. 5, at operation S520, the network entity may be configured to transmit the message to the UE. Accordingly, at operation S530, the network entity may be configured to receive, from the UE, a measurement report that includes data collected by the UE and the classification of the data. Tn this regard, the measurement report may include any suitable or existing measurement reports (e.g., an RRC measurement report, an MDT report, a CSI report, a Radio Link Failure (RLF) report, a Connection Establishment Failure (CEF) report, etc.). This data may be associated with one or more AI / ML models, while the classification may indicates which type or category the data belongs to (e.g., NW-side AI / ML data, UE-side AI / ML data, etc.). In some example embodiments, the classification may further indicates one or more sub-categories, such as NW-side AI / ML model training data, NW-side AI / ML inference data, UE-side AI / ML model training data, UE-side AI / ML inference data, and the like.

[0119] In view of the above, by implementing the method and operations in FIG. 5, the network entity may effectively instruct or guide the UE to explicitly classify data collected (or to be collected) for NW-side AI / ML purposes and UE-side AI / ML purposes. Specifically, by implementing the method and operations in FIG. 5, the network entity may establish the rules for classifying the data and communicate the same to the UE.

[0120] By way of a non-limiting example, the network entity may leverage the RRCDataCollectionType IE to inform the UE the intended classification for each data to be collected (e.g., "Measurement / Data A is NW-side AI / ML data”, “Measurement / Data B is UE-side AI / ML data", etc.), thereby creating the data classification framework. Accordingly, the network entity may include the RRCDataCollectionType IE in an RRC message to instruct the UE on how to categorize the data it is about to collect (e.g., "Configure data associated with Measurement / Data A as 'NW-side AI / ML Data'", etc.).

[0121] Upon receiving the message (e g., RRC message, MAC CE, etc.) from the network entity, the UE may configure its internal logging configurations and collect the associated data accordingly (if the data has not yet been collected). Upon collecting the data, the UE may process the data (e.g., label or tag the data, etc.) to include the information associated with the respective classification, thereby providing clear differentiation between data collected for NW-side AI / ML purposes and for UE-side AI / ML purposes. Accordingly, the UE may send the collected data, along with the associated classification, to the network entity via one or more measurement reports where feasible.

[0122] Since the provided data is explicitly classified at the UE (according to the rules and settings provided by the network entity), the integrity of the data provided by the UE may be maintained, and the consistency of the data across AI / ML models (as well as different deployment scenarios) may be optimized. Further, since the UE is enabled to integrate information associated with data classification into existing measurement reports where feasible, additional or unnecessary signaling overhead for transmitting said information may be avoided.

[0123] According to example embodiments, the network entity may provide the RRC message for classification of data to be collected during an initial data collection / logging session,and periodically (or continuously) provide the MAC CE to the UE to support efficient and realtime dataset classification for Al / ML-driven optimizations. The signaling of MAC CE may enhance dataset classification and adaptation, allowing the network and UE to dynamically classify and manage datasets based on real-time (or near real-time) AI / ML model requirements and AI-driven optimizations while minimizing unnecessary signaling overhead.

[0124] According to example embodiments, the MAC CE signaling performed by the network entity may enable explicit dataset categorization at the AUML model level. As described above, the MAC CE (e.g., AI DatasetCategory Indication MAC CE) may include information that indicates the classification of the data to be collected. Since this MAC CE may be continuously (or periodically) provided by the network entity in an active communication session, the provisioning of the MAC CE may enable real-time (or near real-time) differentiation between NW-side AI / AIL data (e.g., data aggregated from multiple UEs for macro-level optimizations, etc.) and UE-side AI / ML data (e.g., device- specific data or logs for per-device inference enhancements, etc.). By enabling real-time (or near real-time) data differentiation at the AI / ML model level, it can be ensured that the AI / ML models may be trained on data categories relevant to the associated inference scope.

[0125] According to example embodiments, the MAC CE signaling performed by the network entity may also enable dynamic dataset adaptation based on one or more real-time (or near real-time) conditions. Specifically, in addition to the MAC CE (e.g., AI_DatasetCategoryIndication MAC CE) that includes information associated with data classification, example embodiments of the present disclosure also introduce another MAC CE (may be labelled as “Al DatasetAdaptationRequest MAC CE”). By leveraging this AI_DatasetAdaptationRequest MAC CE, the network entity may adjust the classification ofAI / ML data dynamically, ensuring that datasets remain relevant to real-time (or near real-time) conditions, such as a network condition (e.g., network congestion, etc.), a UE operational status (e.g., storage availability, power constraint, etc.), a requirement for deploying the Al / ML model (e g., inference scope, training requirement, etc.), and / or the like.

[0126] By way of a non-limiting example, the network entity may provide the message (e.g., RRC message, AI DatasetCategorylndication MAC CE, etc.) that includes the information of data classification to define the data classification rules / fram ework at the UE (e.g., Measurement / Data X = NW-side AVML data, Measurement / Data Y = UE-side AVML data, etc.). Accordingly, the network entity may leverage the AI_DatasetAdaptationRequest MAC CE to adjust the classification and / or prioritization of the data on a transmi ssi on-by-transmission basis.

[0127] FIG. 6 illustrates an example method 600, according to one or more example embodiments. Method 600 and the associated operations may be performed by the network entity to transmit a MAC CE (e.g., AI_DatasetAdaptationRequest MAC CE) for dynamic dataset adaptation based on one or more real-time (or near real-time) conditions.

[0128] As illustrated in FIG. 6, at operation S610, the network entity may be configured to determine a condition associated with a requirement for deploying an AI / ML model (e.g., dataset / training requirement, etc.), a network condition (e.g., congestion level, etc.), and / or a UE operational status (e.g., storage availability, power constraint, etc.). Accordingly, at operation S620, the network entity may be configured to determine an adjustment to the classification / prioritization of the data based on the determined condition. Next, at operation S630, the network entity may be configured to generate a MAC CE (e.g., Al DatasetAdaptationRequest MAC CE) that includes information indicating the adjustment. Subsequently, at operation S640, the network entity may be configured to transmit the MAC CE to the UE. According to example embodiments, theadjustment may include adjusting a priority level of the data (e.g., assigning a new priority level to the NW-side AI / ML data or the UE-side AI / ML data, etc.), such that the UE may prioritize the data collection of the NW-side AI / ML data over the UE-side AI / ML data when the priority level of the NW-side AI / ML data is indicated as high, and prioritize the data collection of the UE-side AI / ML data over the NW-side AI / ML data when the priority level of the NW-side AI / ML data is indicated as low. Assuming that the network entity determines a network congestion, the network entity may send the AI_DatasetAdaptationRequest MAC CE to the UE to instruct the UE to deprioritize NW-side AI / ML data and send only UE-side AI / ML data, or vice versa.

[0129] In view of the above, by implementing the method and operation of FIG. 6, the network entity may dynamically adjust the classification of the AI / ML data to adapt to real-time (or near real-time) conditions, allowing real-time / near real-time data differentiation at the AI / ML model level to ensure that the collected data is relevant to the AI / ML operations (e.g., ensuring that data collected for training an AI / ML model is relevant to the inference scope of the AI / ML model, etc.) and enabling dynamic network-driven data prioritization.

[0130] According to example embodiments, the UE may also be allowed to request dataset adaptation based on internal conditions, such as: low storage availability (which requires a shift in dataset collection priorities, power constraints (which require energy-efficient dataset handling), and the like. In this regard, the UE may send a request for the data adaptation (e.g., a request for adjusting the data classification and / or prioritization, etc.), while the request may include the internal conditions or operational status of the UE. Accordingly, the network entity may determine the data adaptation / adjustment and send the Al DatasetAdaptationRequest MAC CE that indicates the data adaptation / adjustment to the UE.

[0131] According to example embodiments, the network entity may be configured to implement a mechanism to minimize redundant data collection / logging at the UE. For instance, the network entity may signal data filtering preference to the UE (e.g., via RRC signaling, MAC CE signaling, etc ), thereby ensuring that low-priority, redundant, outdated, and / or unnecessary data may be filtered at the UE before transmission. As a non-limiting example, the network entity may send, to the UE, a RRC message with an IE (and / or a MAC CE with a field) that indicates which data attributes are the most relevant to an ongoing AVML operation (e.g., ongoing training process, etc.), thereby instructing the UE to transmit only the relevant / high-priority data and reducing redundant uplink signaling. This IE may be labeled as “DatasetRelevancelndicator” or any other suitable terminologies. An example use case associated therewith are described below with reference to FIG. 8B.

[0132] In view of the above, by implementing the methods and operations described hereinabove, the shortcomings of aspect (3) as described above may be effectively addressed. To begin with, the network entity may establish a standardized and structured framework for AI / ML dataset management by explicitly classifying the data via RRC signaling and dynamically managing the data classification via MAC CE signaling. Specifically, the network entity may provide a standardized signaling mechanism that clearly differentiates between NW-side AI / ML data and UE-side AI / ML data, thereby avoiding ambiguities in dataset utilization and ensuring consistency in AI / ML -related operations (e.g., AI / ML model training, AI / ML inference, etc.), particularly for network-wide optimizations. For instance, with a defined data classification framework, the network entity may train AI / ML models using mixed data sources without struggling to generalize across different deployment scenarios, ensuring model effectiveness even in dynamic network environments.

[0133] Furthermore, by implementing the above-described methods and operations, the network entity may support efficient and real-time (or near real-time) dataset classification for AI / ML-driven optimizations through enhancements to MAC CE signaling. These enhancements allow the network entity and the UE to dynamically classify and manage (e.g., filter, etc.) datasets based on the real-time / near real-time conditions (e.g., AI / ML model requirements, network conditions, UE constraints, etc.), while minimizing unnecessary signaling overhead. This enables a dynamic control mechanism where the classification is configurable based on network policies, allowing the network entity to request or prioritize specific dataset types based on training needs (e.g., prioritizing NW-side data during stable conditions), and allowing the UE to request data adaptation based on internal constraints (e g., power or storage limitations). Namely, implementing the above-described methods and operations may ensure that data collection is not only classified correctly at the UE but is also responsive to real-time (or near real-time) conditions, allowing the network and UE to maintain a balance between collecting high-quality, relevant AI / ML data and preserving radio and device resources.>> Example Methods and Operations associated with Aspect (4)

[0134] FIG. 7 illustrates an example method 700, according to one or more example embodiments. The operations in method 700 may be performed by a network entity (e.g., network entity 110) to communicate with a UE (e.g., UE 120) to manage the data for NW-side AI / ML purposes, when a mobility event (e.g., a handover, etc.) is detected and may occur during a data collection / logging session.

[0135] As illustrated in FIG. 7, at operation S710, the network entity may be configured to determine whether a handover of the UE from a source cell to a target cell is required. In this regard, it may be assumed that the network entity is a source base station that manages the sourcecell, and the target cell is a neighboring cell of the UE that may be managed by another base station (i.e., a target base station). The network entity may receive a measurement report (which may, but not necessarily, contain the AI / ML data) from the UE, which includes parameters that indicate the signal strength and quality of both the source cell (which is currently serving the UE) and one or more neighboring cells (which includes the target cell). Accordingly, the network entity may determine whether a handover is required by, for example, determining whether the signal strength / quality of a neighboring cell exceeds the signal strength / quality of the source cell by a predefined threshold. In this case, based on determining that the signal strength / quality of a neighboring cell exceeds the signal strength / quality of the source cell by the predefined threshold, the network entity may determine that a handover is required and select the neighboring cell as the target cell. It is contemplated that the network entity may perform any additional or alternative operations in determining whether a handover is required, without departing from the scope of the present disclosure.

[0136] Assuming that the network entity determines that a handover of the UE from a source cell to a target cell is required, method 700 may proceed to operation S720, at which the network entity may generate a Handover Command to initiate the handover. In this regard, in addition to general parameters that are associated with the initiation of handover (e.g., target Physical Cell Identity (PCI), new Cell Radio Network Temporary Identifier (C-RNTI), etc.), the Handover Command may include information associated with an ongoing data collection session for collecting data associated with an AI / ML model prior to the handover.

[0137] According to example embodiments, the Handover Command may include an identity / identifier (ID) (may be labelled as “Dataset Continuity ID” herein) that identifies the ongoing data collection session to the target cell. This ID may allow the UE and / or target cell torecognize the ongoing data collection as well as the process and ongoing data collection efforts (e.g., which data has been collected and which data has not been collected in the ongoing data collection, etc.), thereby avoiding redundant data resets. In this regard, if dataset gaps exist (e.g., the data collected by the UE after the handover is incomplete, etc ), the target cell may request the missing portion(s) of the data from the source cell based on said ID, thereby preventing loss of critical data and maintaining data continuity and tracking across cells.

[0138] Additionally or alternatively, the Handover Command may include a flag (may be labelled as “AI / ML Model Compatibility Flag” herein) that indicates whether data collected during the ongoing data collection session is valid after the handover. This flag enables the UE and / or target cell to detect whether the data collected before the handover is compatible / incompatible after the handover. In this regard, if incompatibility is detected, the UE and / or target cell may adjust the data handling to maintain the performance of the AI / ML -related operations (e.g., accuracy and consistency of AI / ML inference, etc.).

[0139] Additionally or alternatively, the Handover Command may include an indicator (may be labelled as “Pending Data Transfer Indicator” herein) that indicates an un-transferred portion of data in the ongoing data collection session. This indicator enables the target cell to identify un-transferred data portions (if any) and decide whether to retrieve the un-transferred data portions (if any) or proceed with the AI / ML-related operations (e.g., AI / ML model training, etc.) without retrieving the un-transferred data portions.

[0140] Additionally or alternatively, the Handover Command may include a dataset expiration rule that indicates a validity time period for the data collected in the ongoing data collection session. This rule enables the UE and / or target cell to determine whether the collected data remains valid or has expired after the handover. Further, the Handover Command may alsoinclude a dataset prioritization rule that indicates a priority preference for the data collected in the ongoing data collection session. This rule enables the UE and / or target cell to determine whether to prioritize the transmission of the collected data over the initiation of a new data collection session. Including these rules in the Handover Command may ensure that the AI / ML-related operations (e.g., AI / ML model training, etc.) are performed on relevant data, thereby preventing inconsistencies and reducing unnecessary signaling.

[0141] Referring still to FIG. 7, at operation S730, the network entity may be configured to transmit the Handover Command to at least one of the UE or a target base station associated with the target cell. By way of example, the network entity may transmit the Handover Command to the UE via RRC signaling (e g., including the Handover Command in an RRC Reconfiguration message, etc.), and / or transmit the Handover Command to the target base station via inter-base station signaling (e.g., Next Generation Application Protocol (NGAP) signaling, etc.). According to example embodiments, the Handover Commands transmitted to the UE and target base station may include one or more similar parameters (e.g., both the Handover Commands may include the Dataset Continuity ID, etc.), and / or may include one or more parameters that are different from one another (e.g., the Handover Command transmitted to the UE may include the Pending Data Transfer Indicator, while the Handover Command transmitted to the target base station may include the AI / ML Model Compatibility Flag, etc.).

[0142] Upon receiving the Handover Command, the UE may communicate with the target base station to initiate the handover. Upon completion of the handover, the UE may communicate with the target base station for NW-side AI / ML purposes. In this regard, the target base station may utilize the information in the Handover Command (e.g., the Dataset Continuity ID, etc.) to track the data collection session before the handover. On the other hand, the UE may continue theongoing data collection using dataset continuity mechanisms, without restarting the data collection. If valid pending data transfer exists, the target base station may decide whether the UE shall transfer the pending data. On the other hand, if the target base station detects dataset gaps (e.g., the data received after the handover is incomplete), the target base station may communicate with the network entity (i.e., the source base station) to request the missing data. An example use case associated therewith are discussed below with reference to FIG. 8C.

[0143] In view of the above, by implementing the methods and operations described hereinabove, the shortcomings of aspect (4) as described above may be effectively addressed. To begin with, the network entity may maintain AI / ML dataset continuity and reliability during mobility events (e g., a handover) by extending handover signaling to include specific tracking and compatibility indicators. Specifically, by leveraging parameters introduced by the example embodiments (e.g., Dataset Continuity ID, AI / ML Model Compatibility Flag, etc.) within the Handover Command, the network entity may ensure that the data collection efforts prior to the mobility events are tracked across cells and that the target cell can verify the validity of the dataset post-handover. For instance, this mechanism effectively reduces the disruption caused by mobility events, maintaining data continuity and preventing inconsistencies in AI / ML-related operations (e.g., AI / ML model training), thereby avoiding situations where the AI / ML-related operations suffer from data gaps or incompatible input distributions after a mobility event.

[0144] Furthermore, by implementing the above-described methods and operations, the network entity may provide a clear and standardized framework for managing dataset prioritization and expiration during the mobility event. These mechanisms allow the UE and the target base station to determine whether partially collected data should be prioritized for completion, retrieved by the target cell (e.g., via a Pending Data Transfer Indicator), or discarded based on definedvalidity limits. Namely, implementing the above-described methods and operations eliminates the ambiguities often observed when implementing AI / ML-related operations (e.g., AI / ML model training, etc.) across different cells, thereby improving the reliability and predictability of the AI / ML model behavior while simultaneously reducing unnecessary signaling (e.g., by preventing the transfer of expired data or avoiding redundant data resets).> > Summary

[0145] In view of the above, FIG. 2 to FIG. 7 illustrate various example methods and operations that may be implemented to address the shortcomings of the above-described aspects (l)-(4), thereby enabling effective and efficient NW-side AI / ML data management.

[0146] It is contemplated that the methods, operations, advantages, and significances described above with reference to FIG. 2 to FIG. 7 are merely examples, and the scope of the present disclosure should not be limited thereto. Specifically, one or more operations in FIG. 2 to FIG. 7 may be performed differently, less or additional operations may be involved, the messages or commands involved therein may include less or additional parameters, additional technical advantages may be achieved, and the like, without departing from the scope of the present disclosure. Further, it is contemplated that one or more of the above-described parameters, messages, and the like, may be consistent with those specified in one or more standard specifications, with additional parameters, attributes, and mechanisms supplemented thereto (when required). Further, multiple methods and operations in FIG. 2 to FIG. 7 may be performed in combination with each other, without departing from the scope of the present disclosure.Example Use Cases

[0147] Various example use cases, in which one or more of example embodiments may be implemented or utilized, are described below with reference to FIG. 8A to FIG. 8C. It is contemplated that the example use cases in FIG. 8A to FIG. 8C may involve or implement one or more features, configurations, operations, messages, and parameters described above with reference to FIG. 1 to FIG. 7, and redundant descriptions associated therewith may be omitted below for conciseness.

[0148] As illustrated in FIG. 8A to FIG. 8C, the example use cases may involve a network entity 810 and a UE 820, each of which may be similar to the network entity 110 and UE 120 in FIG. 1, respectively. Further, the example use case in FIG. 8C further involves a second network entity 830, which may also be similar to the network entity 110 in FIG. 1. In the example use cases, the “gNB” is used as the example of the network entity(s), although it is contemplated that any other suitable network entity (e.g., RAN node, core network function, etc.) may be utilized in a similar manner, without departing from the scope of the present disclosure.

[0149] FIG. 8A illustrates a first example use case 801, according to one or more example embodiments. Example use case 801 may exemplify the implementation of the example embodiments to provide an MDT Request MAC CE mechanism (which allows the UE to request additional MDT logging session(s) when it detects rapid radio frequency changes and / or anomalous conditions). Example use case 801 may involve one or more operations described above with reference to FIG. 4.

[0150] As illustrated in FIG. 8A, at step 1, the network entity 810 (e.g., gNB) may be configured to provide an RRC Reconfiguration message to the UE 820. This RRC Reconfiguration message may include a request configuration parameter (labelled as “UEMDTRequestConfig” inFIG. 8A) that indicates whether the UE 820 is allowed to request additional MDT logging session, information associated with one or more conditions that trigger or initiate the MDT logging session (similar to the “MDTLoggingConfig” described above with reference to FIG. 4), information associated with one or more configurations for providing the MDT reporting, and the like.

[0151] Upon receiving the RRC Reconfiguration message, at step 2, the UE 820 may perform the MDT logging according to the configurations indicated in the RRC Reconfiguration message. In this regard, assuming that the RRC Reconfiguration message indicates that the UE 820 is allowed to request additional MDT logging session(s), the UE 820 may determine whether additional MDT logging session(s) are required. For instance, the UE 820 may detect whether there is any rapid radio frequency changes or signal anomalies, such as deep fading, sudden interference, beam failure, rapid SINR drop, and the like.

[0152] Assuming that the UE 820 detects a rapid RF change / anomaly at step 2, the UE 820 may determine that additional MDT logging session(s) is required. Accordingly, at step 3, the UE 820 may send a MAC CE (labelled as one of the “MDTRequestMACCE” and “AIDataLoggingRequest” in FIG. 8 A) to the network entity 810 to request additional MDT logging session(s). As described above with reference to FIG. 4, the MAC CE may include information indicating a reason for requesting the additional MDT logging session(s), a desired configuration of the additional MDT logging session(s), and the like

[0153] At step 4, the network entity 810 may be configured to evaluate the MAC CE (provided by the UE 820 at step 3) and determine whether the request for the additional MDT logging session(s) can be approved or shall be denied. For instance, the network entity 810 may determine whether the network condition (e.g., network load, etc.) allows the signaling of the additional MDT logging session(s), whether the detected RF change / anomaly may affect the NW-side AI / ML operations, whether the requested configuration (e.g., transmission rate, transmission timing, etc.) of the additional MDT logging session(s) is feasible, and the like.

[0154] Based on determining that the request for the additional MDT logging session(s) can be approved, example use case 801 may proceed to step 5, at which the network entity 810 may be configured to provide another MAC CE to the UE 820 to grant the requested additional MDT logging session(s). This MAC CE may include the logging parameters (e.g., transmission rate, logging duration, logging configuration, etc.) granted to the additional MDT logging session(s). Accordingly, at step 6, the UE 820 may be configured to perform the additional MDT logging session(s) according to the configurations and parameters in the MAC CE (provided by the network entity at step 5). Subsequently, at step 7, the UE 820 may provide an MDT measurement report to the network 810. The MDT measurement report may include the AI / ML data collected during the MDT logging session(s).

[0155] On the other hand, based on determining that the request for the additional MDT logging session(s) shall be denied, example use case 801 may proceed to step 8, at which the network entity 810 may be configured to provide another MAC CE to the UE 820 to deny the request for additional MDT logging session(s). This MAC CE may include information or reasoning regarding the rejection of the request.

[0156] FIG. 8B illustrates a second example use case 802, according to one or more example embodiments. Example use case 802 may exemplify the implementation of the example embodiments to provide AI / ML data adaptation with filtering preferences. Example use case 802 may involve one or more operations described above with reference to FIG. 5 and FIG. 6.

[0157] As illustrated in FIG. 8B, at step 1, the network entity 810 may be configured to receive, from the UE 820, a measurement report (e.g., an MDT measurement report similar to theone in example use case 801, a CSI report, etc.) that includes collected AI / ML data and information indicating the category or classification associated with the collected AI / ML data (e.g., NW-side AI / ML data, UE-side AI / ML data, etc.). This operation may be similar to operation S53O in FIG.5.

[0158] At step 2, the network entity 810 may be configured to evaluate the measurement report and determine dataset adaptation and / or filtering preferences based thereon. For instance, the network entity 810 may perform operations S610-S620 in FIG. 6 to determine the adjustment to the classification of the AI / ML data based on one or more real-time / near real-time conditions, thereby dynamically determining or implementing dataset adaptation. As described above with reference to FIG. 6, the dataset adaptation may include adjusting a priority level of the data (e.g., prioritize NW-side AI / ML data over UE-side AI / ML data, etc.). Accordingly, at step 3, the network entity 810 may provide a message (e.g., an RRC message, an MAC CE, etc.) to the UE 820 to request the UE 820 to apply the data set adaptation (said message is labelled as “AI DatasetAdapatationRequest” in FIG. 8B). This message may include information or instructions to change dataset category and / or parameters, reflect UE constraints (e.g., storage, power, etc.), and the like.

[0159] In addition to the dataset adaptation, at step 2, the network entity 810 may also determine the filtering preferences. For instance, if the network entity 810 determines that a portion of the collected AI / ML data is redundant, outdated, low-priority, and / or unrelated to the ongoing AI / ML operations, the network entity may determine that such a portion of data should be filtered out before the subsequent transmissions / signaling, thereby ensuring that the UE 820 may transmit only the relevant / high-priority data and optimizing uplink signaling. Accordingly, at step 4, the network entity 810 may provide a MAC CE message (or an RRC message) to the UE 820, therebyinforming the UE 820 regarding the filtering preferences determined by the network entity 810. The MAC CE message may include a field (labelled as “DatasetRelevancelndicator” in FIG. 8B) to indicate dataset filtering preference and the relevant dataset attributes.

[0160] Accordingly, at step 6, the UE 820 may collect the AI / ML data according to the dataset adaptation request (e.g., collect the prioritized AI / ML data, etc.), and filter the AI / ML data according to the filtering preferences (e.g., remove portions of data that is redundant, outdated, low-priority, and / or unrelated to the ongoing AI / ML operations). Subsequently, at step 7, the UE 820 may provide, to the network entity 810, another measurement report that includes the filtered AI / ML dataset.

[0161] FIG. 8C illustrates a third example use case 803, according to one or more example embodiments. Example use case 803 may exemplify the implementation of the example embodiments to manage AI / ML data when a mobility event (e.g., a handover) is detected. Example use case 803 may involve one or more operations described above with reference to FIG. 7.

[0162] In this example use case 803, the network entity 810 (in the example use cases of FIG. 8A and FIG. 8B) may be described as the first network entity and may include a gNB that is associated with a source cell serving the UE 820 (“source gNB” herein), while the network entity 830 may be described as the second network entity and may include a gNB that is associated with a target cell to which the UE 820 switches upon completion of the handover.

[0163] It may be assumed that, in example use case 803, the first network entity 810 has implemented the operations in FIG. 7 and the handover preparation stage is completed (e.g., the first network entity 810 has detected that a handover of the UE to the target cell associated with the second network entity 830 is required, has generated and provided a Handover Command (that includes one or more of: Dataset Continuity ID, AI / ML Model Compatibility Flag, Pending DataTransfer Indicator, dataset expiration rule, dataset prioritization rule, etc.) to the UE 820 and / or second network entity 830, etc.). Thus, example use case 803 may begin from the handover execution stage.

[0164] At step 1, the UE 820 may provide an RRC Reconfiguration Complete message (that implicitly attaches continuity context) to the second network entity 830. The RRC Reconfiguration Complete message may also include at least a portion of AI / ML data collected by the UE 820 prior to the handover completion. Assuming that the handover execution is successful and completed after step 1, the second network entity 830 may be configured to handle various types of operations to ensure seamless transition and continuity of the AEML data collection.

[0165] For instance, the second network entity 830 may determine whether there is any pending data transfer. In this regard, the second network entity 830 may determine whether any portion of the AI / ML data is missing and requires retransmission / correction. For instance, the second network entity 830 may determine, based on the Pending Data Transfer Indicator and / or Dataset Continuity ID (which may be provided by the first network entity 810 and / or the UE 820 prior to step 2), whether there is any un-transferred portion of data in the previous data collection session. If there is no pending data transfer or the AI / ML data provided by the UE 820 after the handover completion is complete and does not have any missing portion, example use case 803 may proceed to step 6, at which the second network entity 830 will act as the new source gNB and continue the local dataset handling based on the associated compatibility and expiration / prioritization rules. Conversely, based on determining that a pending data transfer is indicated, at step 2, the second network entity 830 may provide a request message to the first network entity 810 to request the pending data or missing portion of the AEML data. The message may include the DatasetContinuity ID, which enables the second network entity 830 to clearlyindicate, to the first network entity 810, which AI / ML data and the associated portion are required. In this case, if the first network entity 810 is able to provide the missing data portion (e.g., the first network entity 810 has the missing data portion), at step 3, the first network entity 810 may transfer the missing data portion (along with the DatasetContinuity ID) to the second network entity 830. Accordingly, at step 4, the second network entity 830 may merge the missing data portion with the AI / ML data provided by the UE 820 and then validate the merged dataset for completeness. On the other hand, if partial dataset exists but the first network entity 810 is not able to provide the missing data portion (e.g., the first network entity 810 does not have the missing data portion), the first network entity 810 may reply with a message (e.g., a negative acknowledgement, etc.) to inform the second network entity 830 regarding the same. Accordingly, at step 5, the second network entity 830 may provide a message (e.g., RRC message, MAC CE, etc.) to the UE 820 to issue a dataset correction request.

[0166] In addition to or in alternative to handling the pending data transfer / partial dataset, the second network entity 830 may also validate the compatibility of the dataset. Specifically, the second network entity 830 may determine, based on the AI / ML Model Compatibility Flag, whether the data collected before the handover is compatible / incompatible with an AI / ML model associated with the second network entity 830. Based on determining that the data is compatible, example use case 803 may proceed to step 7, at which the second network entity 830 may provide a message (e g., RRC message, MAC CE, etc.) to the UE 820 to inform the UE 820 to continue the AI / ML data logging and reporting under the existing configuration. On the other hand, based on determining that the data is not compatible, example use case 803 may proceed to step 8, at which the second network entity 830 may be configured to provide a message (e.g., RRC message, MAC CE, etc.) to the UE 820 to instruct the UE 820 to reconfigure the AI / ML data logging and / orreporting, or instruct the UE 820 to treat the previously collected dataset as invalid after the handover. Accordingly, the UE 820 may discard the previously collected dataset to optimize the resources (e.g., storage, etc.).

[0167] In view of the above, FIG. 8A to FIG. 8C provide various example use cases on how the example embodiments of the present disclosure may be implemented to effectively and efficiently manage AI / ML data under various scenarios. It is contemplated that the features, mechanisms, and operations in example use cases 801 to 803 are merely examples, and the scope of the present disclosure should not be limited thereto.Examples of Device

[0168] One or more components of the example embodiments (e.g., network entity, UE, etc.), as well as the operations associated therewith, may be implemented in one or more devices or hardware components. For instance, one or more components / operations of the network entity may be implemented in one or more devices like a server(s), and the like.

[0169] In the following, descriptions of a device in which the example embodiments may be implemented are provided. It is contemplated that one or more features, operations, and methods described above may be performed by the device. For instance, the one or more operations or methods associated with the network entity may be performed by at least one processor of the device upon executing machine-readable instructions or computer-readable instructions stored in a memory or a storage component of the device.

[0170] FIG. 9 illustrates an embodiment of a device 900. As shown in FIG. 9, the device 900 may include a processor 910, a memory 920, a storage component 930, an input component 940, an output component 950, a communication interface 960, and a bus 970.

[0171] The processor 910, as used herein, means any type of computational circuit that may comprise hardware elements and software elements. The processor 910 may be embodied as a multi-core processor, a single core processor, or a combination of one or more multi-core processors and / or one or more single core processors, a distributed processing system, or the like. The processor 910 may be a Central Processing Unit (CPU), a graphics processing unit (GPU), an accelerated processing unit (APU), an application-specific integrated circuit (ASIC), or another type of processing component.

[0172] Memory 920 includes a non-transitory computer readable medium. Memory 920 includes a random-access memory (RAM), a read only memory (ROM), and / or another type of dynamic or static storage device (e.g., a flash memory, a magnetic memory, and / or an optical memory) that stores information and / or instructions for use by processor 910. The memory 920 comprises machine-readable instructions which are executable by the processor 910. These machine-readable instructions when executed by the processor 910 cause the processor 910 to perform one or more method steps of an embodiment described above.

[0173] Storage component 930 stores information and / or software related to the operation and use of the device 900. For example, storage component 930 may include a hard disk (e.g., a magnetic disk, an optical disk, a magneto-optic disk, and / or a solid-state disk), a compact disc (CD), a digital versatile disc (DVD), a floppy disk, a cartridge, a magnetic tape, and / or another type of non-transitory computer-readable medium, along with a corresponding drive.

[0174] Input component 940 is configured to receive information, such as user input. For example, the input component 940 may include, but not be limited to, a touch screen display, a keyboard, a keypad, a mouse, a button, a switch, and / or a microphone. Additionally, oralternatively, the input component 940 may include a sensor for sensing information (e.g., a global positioning system (GPS), an accelerometer, a gyroscope, and / or an actuator).

[0175] Output component 950 is configured to provide output information from the device 900. For example, the output component 950 may be, but not limited to, a display, a speaker, instructions to an external device, and / or one or more light-emitting diodes (LEDs).

[0176] Communication interface 960 is an interface that provides a communication connection to other devices, such as external devices and internal devices. The connection by the communication interface 960 can be a wired connection, a wireless connection, or a combination of wired and wireless connections, and can be a direct connection or an indirect connection via a communication network that exists between the device 900 and other devices. In other words, the standard of the communication interface 960 is not limited.

[0177] The bus 970 acts as an interconnect between the processor 910, the memory 920, the storage component 930, the input component 940, the output component 950, and the communication interface 960 of the device 900. The bus 970 may include a wired interconnection or a wireless interconnection.

[0178] The number and arrangement of components shown in FIG. 9 are provided as an example. In practice, device 900 may include additional components, fewer components, different components, or differently arranged components than those shown in FIG. 9. Additionally, or alternatively, a set of components (e.g., one or more components) of device 900 may perform one or more functions described as being performed by another set of components of device 900. Further, one or more method steps described in any of the embodiments may be performed utilizing a plurality of devices 900 in communication with one another.Example Implementation Environment

[0179] Example embodiments of the present disclosure may be implemented in any suitable type of environment. In the following, an example environment (in which the example embodiments may be implemented) is described.

[0180] FIG. 10 illustrates a diagram of an example environment 1000 in which systems and / or methods, described herein, may be implemented. The implementation environment 1000 includes a UE (User equipment) 1010, a service environment 1020, and a network 1030. The service environment 1020 includes one or more sub-environments 1021. To illustrate this, FIG. 10 shows, for convenience, examples of a 1st sub-environment 1021-1, a 2nd sub-environment 1021-2, and an N-th sub-environment 1021-N (where N is any natural number).

[0181] The UE 1010 is connected to the network 1030, and the network 1030 is connected to the service environment 1020. The connections may be wired, wireless, or a combination of both wired and wireless. The UE 1010 and the service environment 1020 are connected via the network 1030.

[0182] The UE 1010 is a device that communicates with the service environment 1020. The UE 1010 receives information from the service environment 1020 and / or sends information to the service environment 1020. Also, the UE 1010 may generate and / or store information to be transmitted, as necessary. Also, the UE 1010 may store and / or process information that is received, as necessary.

[0183] The example FIG. 10 refers to the “UE”. However, it should be understood by those skilled in the art that general terms such as “user device,” “terminal,” “terminal device,” “communication device,” and “communication terminal” can be used interchangeably with the term “UE.

[0184] For example, the UE 1010 may include a computing device (e.g., a desktop computer, a laptop computer, a tablet computer, a handheld computer, a smart speaker, a server, etc.), a mobile phone (e.g., a smart phone, a radiotelephone, etc.), a wearable device (e.g., a pair of smart glasses or a smart watch), or a similar device.

[0185] The service environment 1020 is an environment that communicates with the UE 1010 to provide one or more services. The service environment 1020 receives information from the UE 1010 and / or sends information to the UE 1010. Also, the service environment 1020 may generate and / or store information to be transmitted, as necessary. Also, the service environment 1020 may store and / or process information that is received, as necessary. For example, the service environment 1020 may provide computing resources as one of the services. It should be noted that the service is not limited to being provided to the UE; it may also be provided to devices other than the UE. For example, based on communication from the UE, the service may perform processes such as anomaly detection or traffic analysis and notify the results to a predetermined destination.

[0186] The example FIG. 10 refers to the “service environment”. The term "service environment" is used to refer to the broader context within which services operate. For example, cloud environments, platforms, computing systems, network systems, and cloud systems generally represent the environments in which services are conducted, and these are included within the "service environment." However, the "service environment" is not limited to these examples. Additionally, the specific types of environments within the "service environment" are not restricted. For instance, cloud environments and cloud systems can be categorized as private cloud, public cloud, hybrid cloud, or multi-cloud, all of which are included within the "service environment.

[0187] The one or more services provided by the service environment 1020 is not specifically limited and can be adjusted according to the embodiments. For example, the services may include a service that provides information to the UE 1010, a service that stores information from the UE 1010, or a service that performs processing based on information from the UE 1010 and returns the results of the processing.

[0188] In an embodiment, the Service Environments 1020 may also provide computing resources as the service. The computing resources can be hardware resources and / or software resources. For example, applications, processors, memory, and storage can be included in the provided computing resources. Each computing resource can communicate with other computing resources via wired connections, wireless connections, or a combination of wired and wireless connections.

[0189] The provided computing resources can be actual resources (also referred to as physical resources) and / or virtual resources. Furthermore, means of virtualization for virtual resources can be selected as appropriate. That is, in this disclosure, the use of adjectives such as "Virtual" or "Virtualized" to describe names does not imply that they are virtualized by a specific means of virtualization. For example, “virtual machine” refers to software that operates like an actual computer, realized through means of virtualization, and it is not intended to exclude those realized by specific means of virtualization such as Hypervisors or Containers. Conversely, when means of virtualization such as Hypervisors or containers are mentioned in this disclosure, it is merely cited as a general method of implementation. It should also be interpreted that embodiments implemented with other virtualization means are also disclosed. Also, the services may also be provided using resources virtualized by different means.

[0190] The service environment 1020 includes one or more devices, such as servers and network devices, which provide services or perform processes. The placement of these devices within the service environment 1020 can be determined as appropriate. Additionally, if the service environment 1020 includes one or more sub-environments 1021, the placement of devices can be determined based on predetermined policies for each sub-environment 1021. For example, devices related to the first service may be placed in the 1st sub -environment 1021-1, and devices related to the second service may be placed in the 2nd sub-environment 1021-2. In another example, devices expected to have a higher load than a predetermined threshold may be placed in the 1st sub-environment 1021-1, while devices expected to have a lower load than the predetermined threshold may be placed in the 2nd sub-environment 1021-2. In this way, specific devices can be placed in specific sub-environments 1021. Conversely, each sub-environment 1021 can be specialized for a particular purpose.

[0191] In an embodiment, all processes executed in a single service may run within a single service environment, or in multiple service environments. Multiple processes executed in a single service could be provided by different service environments.

[0192] The network 1030 is a network that exchanges information between the UE 1010 and the service environment 1020. The network 1030 includes one or more wired and / or wireless networks.

[0193] For example, the network 1030 may include a cellular network (e.g., a fifth generation (5G) network, a long-term evolution (LTE) network, a third generation (3G) network, a code division multiple access (CDMA) network, etc.), a public land mobile network (PLMN), a local area network (LAN), a wide area network (WAN), a metropolitan area network (MAN), a telephone network (e g., the Public Switched Telephone Network (PSTN)), a private network, anad hoc network, an intranet, the Internet, a fiber optic-based network, or the like, a non-terrestrial network (NTN), and / or a combination of these or other types of networks.

[0194] The network 1030 can be a part of a network. For example, in a 5G network that includes a RAN, a transport network, and a core network, the network 1030 can be at least one of the RAN, the transport network, or the core network. For example, the service environment 1020 could be in the core network, in which case the network 1030 could correspond to a network that is a combination of a RAN and a transport network and is part of the 5G network.

[0195] In this regard, the UE 1010 in FIG. 10 may be similar to the UE 120 in FIG. 1, while the network entity 110 in FIG. 1 may be implemented in the network 1030. Further, the AI / ML-related operations described herein (e.g., AI / ME model training, AI / ME inference, etc.) may be implemented in the service environment 1020.

[0196] The number and arrangement of devices and networks shown in FIG. 10 are provided as an example. It should be understood that any changes that may be implemented by those skilled in the art, such as the addition or rearrangement of well-known devices or networks at the time of implementation, are included in this disclosure.Various Aspects of Embodiments

[0197] Example embodiments introduces new parameters, attributes, mechanisms, and features that supplement and enhance the disclosures of one or more standard specifications. As a non-limiting example, example embodiments supplement and enhance at least one technical documents associated with 3GPP Technical Specification Group-Radio Access Network (TSG- RAN) Working Group 2 (WG2). Specifically, the following disclosures where introduced by theexample embodiments of the present disclosure during the 3GPP TSG-RAN WG2 Meeting #129:

[0198] In view of the above, example embodiments introduce clarified, specified, and standardized approaches for implementing the management of NW-side AI / ML data in the 3 GPPbased network architecture. Specifically, example embodiments clarify how specifically the 3 GPP defined frameworks and architectures (e.g., MDT, RRC signaling, MAC CE signaling, etc.) can be utilized to manage NW-side AI / ML data. Accordingly, the example embodiments may be implemented in the 3 GPP-based networks in a clear and standardized manner.

[0199] It is contemplated that features, advantages, and significances of example embodiments described hereinabove are merely examples of the present disclosure, and are not intended to be exhaustive or to limit the scope of the present disclosure.

[0200] Specifically, the foregoing disclosure provides illustration and description, but is not intended to be exhaustive or to limit the implementations to the precise form disclosed. Modifications and variations are possible in light of the above disclosure or may be acquired from practice of the implementations.

[0201] Some embodiments may relate to a device, a system, a method, and / or a computer-readable medium at any possible technical detail level of integration. Further, one or more of the above components described above may be implemented as instructions stored on a computer-readable medium and executable by at least one processor (and / or may include at least one processor). The computer-readable medium may include a computer-readable non-transitory storage medium (or media) having computer-readable program instructions thereon for causing aprocessor to carry out operations.

[0202] The computer-readable storage medium can be a tangible device that can retain and store instructions for use by an instruction execution device. The computer-readable storage medium may be, for example, but is not limited to, an electronic storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any suitable combination of the foregoing. A non-exhaustive list of more specific examples of the computer-readable storage medium includes the following: a portable computer diskette, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or Flash memory), electrically erasable programmable read-only memory (EEPROM), a static random access memory (SRAM), a portable compact disc read-only memory (CD-ROM), a digital versatile disk (DVD), a memory stick, a floppy disk, a mechanically encoded device such as punch-cards or raised structures in a groove having instructions recorded thereon, and any suitable combination of the foregoing. A computer-readable storage medium, as used herein, is not to be construed as being transitory signals per se, such as radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagating through a waveguide or other transmission media (e.g., light pulses passing through a fiber-optic cable), or electrical signals transmitted through a wire.

[0203] Computer-readable program instructions described herein can be downloaded to respective computing / processing devices from a computer-readable storage medium or to an external computer or external storage device via a network, for example, the Internet, a local area network, a wide area network and / or a wireless network. The network may comprise copper transmission cables, optical transmission fibers, wireless transmission, routers, firewalls, switches, gateway computers, and / or edge servers. A network adapter card or network interface in eachcomputing / processing device receives computer-readable program instructions from the network and forwards the computer-readable program instructions for storage in a computer-readable storage medium within the respective computing / processing device.

[0204] Computer-readable program code / instructions for carrying out operations may be assembler instructions, instruction-set-architecture (ISA) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, state-setting data, configuration data for integrated circuitry, or either source code or object code written in any combination of one or more programming languages, including an object-oriented programming language such as Smalltalk, C++, or the like, and procedural programming languages, such as the "C" programming language or similar programming languages.

[0205] The computer-readable program instructions may execute entirely on the user's computer, partly on the user's computer, as a stand-alone software package, partly on the user's computer and partly on a remote computer or entirely on the remote computer or server. In the latter scenario, the remote computer may be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or the connection may be made to an external computer (for example, through the Internet using an Internet Service Provider). In some embodiments, electronic circuitry including, for example, programmable logic circuitry, field-programmable gate arrays (FPGA), or programmable logic arrays (PLA) may execute the computer-readable program instructions by utilizing state information of the computer-readable program instructions to personalize the electronic circuitry, in order to perform aspects or operations.

[0206] These computer-readable program instructions may be provided to a processor of a general -purpose computer, special-purpose computer, or other programmable data processingapparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions / acts specified in the flowchart and / or block diagram block or blocks. These computer-readable program instructions may also be stored in a computer-readable storage medium that can direct a computer, a programmable data processing apparatus, and / or other devices to function in a particular manner, such that the computer-readable storage medium having instructions stored therein comprises an article of manufacture including instructions which implement aspects of the function / act specified in the flowchart and / or block diagram block or blocks.

[0207] The computer-readable program instructions may also be loaded onto a computer, other programmable data processing apparatus, or other devices to cause a series of operational steps to be performed on the computer, other programmable apparatus or other devices to produce a computer-implemented process, such that the instructions which execute on the computer, other programmable apparatus, or other device implement the functions / acts specified in the flowchart and / or block diagram block or blocks.

[0208] The flowchart and block diagrams in the Figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer-readable media according to various embodiments. In this regard, each block in the flowchart or block diagrams may represent a module, segment, or portion of instructions, which comprises one or more executable instructions for implementing the specified logical function(s). The method, computer system, and computer-readable medium may include additional blocks, fewer blocks, different blocks, or differently arranged blocks than those depicted in the Figures. In some alternative implementations, the functions noted in the blocks may occur out of the order noted in the Figures. For example, two blocks shown in succession may, in fact, be executed concurrentlyor substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the block diagrams and / or flowchart illustration, and combinations of blocks in the block diagrams and / or flowchart illustration, can be implemented by special purpose hardware-based systems that perform the specified functions or acts or carry out combinations of special purpose hardware and computer instructions.

[0209] It will be apparent that systems and / or methods, described herein, may be implemented in different forms of hardware, firmware, or a combination of hardware and software. The actual specialized control hardware or software code used to implement these systems and / or methods is not limited to the implementations. Thus, the operation and behavior of the systems and / or methods were described herein without reference to specific software code — it is understood that software and hardware may be designed to implement the systems and / or methods based on the description herein.

[0210] In view of the above, various further respective aspects and features of embodiments of the present disclosure may be defined by the following items:Item [1]: A system comprising: a network entity configured to: generate a Radio Resource Control (RRC) message that comprises information associated with at least one of: a condition that triggers a data collection for collecting data associated with an Artificial Intelligence or Machine Learning (AI / ML) model, or a logging duration associated with the data collection; and transmit the RRC message to a user equipment (UE).Item [2]: The system according to item [1], wherein the information associated with the condition that triggers the data collection comprises: an event type indicator that indicates an event the UE monitors, a threshold parameter that indicates a threshold thattriggers the data collection based on the detection of the event, and a time hysteresis parameter that delays the data collection upon detection of the event.Item [3]: The system according to item [2], wherein the event type indicator indicates at least one of: a Layer 3 (L3) event, a beam-level event, or a Layer 1 (LI) event.Item [4]: The system according to one or more of items [l]-[3], wherein the information associated with the logging duration indicates at least one of: a short-term logging duration, an extended logging duration, or a network-adjusted logging duration.Item [5]: The system according to item [4], wherein the short-term logging duration is associated with a transient radio condition change, and wherein the extended logging duration is associated with a beam transition event.Item [6]: The system according to one or more of items [l]-[5], wherein the information associated with the logging duration comprises an indicator that indicates whether a periodicity of the data collection should match with a periodicity of a Channel State Information Reference Signal (CSLRS).Item [7]: The system according to one or more of items

[0001] -[6], wherein the network entity is further configured to: receive, from the UE, a measurement report comprising data collected in accordance with the RRC message; evaluate the measurement report to determine an adjustment to a logging duration for a subsequent data collection; and transmit, to the UE, a medium access control (MAC) control element (CE) that indicates the adjustment.Item [8]: The system according to one or more of items [l]-[7], wherein the information associated with the logging duration comprises an indicator that indicates thatthe data collection is to persist while the condition that triggers the data collection is fulfilled and is to terminate when the condition is no longer fulfilled.Item [9]: The system according to item [4], wherein the network-adjusted logging duration is determined by the network entity based on at least one of: a current network congestion status, or a dataset requirement of the AI / ML model.Item

[0010] : A method comprising: generating a Radio Resource Control (RRC) message that comprises information associated with at least one of: a condition that triggers a data collection for collecting data associated with an Artificial Intelligence or Machine Learning (AI / ML) model, or a logging duration associated with the data collection; and transmitting the RRC message to a user equipment (UE).Item

[0011] : The method according to item

[0010] , wherein the information associated with the condition that triggers the data collection comprises: an event type indicator that indicates an event the UE monitors, a threshold parameter that indicates a threshold that triggers the data collection based on the detection of the event, and a time hysteresis parameter that delays the data collection upon detection of the event.Item

[0012] : The method according to item

[0011] , wherein the event type indicator indicates at least one of: a Layer 3 (L3) event, a beam-level event, or a Layer 1 (LI) event.Item

[0013] : The method according to one or more of items

[0010] -

[0012] , wherein the information associated with the logging duration comprises at least one of: a short-term logging duration, an extended logging duration, or a network-adjusted logging duration.Item

[0014] : The method according to item

[0013] , wherein the short-term logging duration is associated with a transient radio condition change, and wherein the extended logging duration is associated with abeam transition event.Item

[0015] : The method according to one or more of items

[0010] -

[0014] , wherein the information associated with the logging duration comprises an indicator that indicates whether a periodicity of the data collection should match with a periodicity of a Channel State Information Reference Signal (CSI-RS).Item

[0016] : The method according to one or more of items

[0010] -

[0015] , further comprising: receiving, from the UE, a measurement report that comprises data collected in accordance with the RRC message; evaluating the measurement report to determine an adjustment to a logging duration for a subsequent data collection; and transmitting, to the UE, a medium access control (MAC) control element (CE) that indicates the adjustment.Item

[0017] : The method according to one or more of items

[0010] -[l 6], wherein the information associated with the logging duration comprises an indicator that indicates that the data collection is to persist while the condition that triggers the data collection is fulfilled and is to terminate when the condition is no longer fulfilled.Item

[0018] : The method according to item

[0013] , wherein the network-adjusted logging duration is determined based on at least one of: a current network congestion status, or a dataset requirement of the AI / ML model.Item

[0019] : A non -transitory computer-readable recording medium having recorded thereon instructions executable by a network entity to cause the network entity to perform a method comprising: generating a Radio Resource Control (RRC) message that comprises information associated with at least one of: a condition that triggers a data collection for collecting data associated with an Artificial Intelligence or Machine Learning (AI / ML) model, or a logging duration associated with the data collection; and transmitting the RRC message to a user equipment (UE).Item

[0020] : The non-transitory computer-readable recording medium according to item

[0019] , wherein the information associated with the condition that triggers the data collection comprises: an event type indicator that indicates an event the UE monitors, a threshold parameter that indicates a threshold that triggers the data collection based on the detection of the event, and a time hysteresis parameter that delays the data collection upon detection of the event.

[0211] It can be understood that numerous modifications and variations of the present disclosure are possible in light of the above teachings. It will be apparent that within the scope of the appended clauses, the present disclosures may be practiced otherwise than as specifically described herein.

Claims

What is claimed is:

1. A system comprising:a network entity configured to:generate a Radio Resource Control (RRC) message that comprises information associated with at least one of: a condition that triggers a data collection for collecting data associated with an Artificial Intelligence or Machine Learning (AI / ML) model, or a logging duration associated with the data collection; andtransmit the RRC message to a user equipment (UE).

2. The system according to claim 1, wherein the information associated with the condition that triggers the data collection comprises: an event type indicator that indicates an event the UE monitors, a threshold parameter that indicates a threshold that triggers the data collection based on the detection of the event, and a time hysteresis parameter that delays the data collection upon detection of the event.

3. The system according to claim 2, wherein the event type indicator indicates at least one of: a Layer 3 (L3) event, a beam-level event, or a Layer 1 (LI) event.

4. The system according to claim 1, wherein the information associated with the logging duration comprises at least one of: a short-term logging duration, an extended logging duration, or a network-adjusted logging duration.

5. The system according to claim 4, wherein the short-term logging duration is associated with a transient radio condition change, and wherein the extended logging duration is associated with a beam transition event.

6. The system according to claim 1, wherein the information associated with the logging duration comprises an indicator that indicates whether a periodicity of the data collection should match with a periodicity of a Channel State Information Reference Signal (CSI-RS).

7. The system according to claim 1, wherein the network entity is further configured to:receive, from the UE, a measurement report comprising data collected in accordance with the RRC message;evaluate the measurement report to determine an adjustment to a logging duration for a subsequent data collection; andtransmit, to the UE, a medium access control (MAC) control element (CE) that indicates the adjustment.

8. The system according to claim 1, wherein the information associated with the logging duration comprises an indicator that indicates that the data collection is to persist while the condition that triggers the data collection is fulfilled and is to terminate when the condition is no longer fulfilled.

9. The system according to claim 4, wherein the network-adjusted logging duration is determined by the network entity based on at least one of a current network congestion status, or a dataset requirement of the A 1 / M I. model.

10. A method comprising:generating a Radio Resource Control (RRC) message that comprises information associated with at least one of: a condition that triggers a data collection for collecting data associated with an Artificial Intelligence or Machine Learning (AI / ML) model, or a logging duration associated with the data collection; andtransmitting the RRC message to a user equipment (UE).

11. The method according to claim 10, wherein the information associated with the condition that triggers the data collection comprises: an event type indicator that indicates an event the UE monitors, a threshold parameter that indicates a threshold that triggers the data collection based on the detection of the event, and a time hysteresis parameter that delays the data collection upon detection of the event.

12. The method according to claim 11, wherein the event type indicator indicates at least one of: a Layer 3 (L3) event, a beam-level event, or a Layer 1 (LI) event.

13. The method according to claim 10, wherein the information associated with the logging duration comprises at least one of: a short-term logging duration, an extended logging duration, or a network-adjusted logging duration.

14. The method according to claim 13, wherein the short-term logging duration is associated with a transient radio condition change, and wherein the extended logging duration is associated with a beam transition event.

15. The method according to claim 10, wherein the information associated with the logging duration comprises an indicator that indicates whether a periodicity of the data collection should match with a periodicity of a Channel State Information Reference Signal (CSI-RS).

16. The method according to claim 10, wherein further comprising:receiving, from the UE, a measurement report that comprises data collected in accordance with the RRC message;evaluating the measurement report to determine an adjustment to a logging duration for a subsequent data collection; andtransmitting, to the UE, a medium access control (MAC) control element (CE) that indicates the adjustment.

17. The method according to claim 10, wherein the information associated with the logging duration comprises an indicator that indicates that the data collection is to persist while the condition that triggers the data collection is fulfilled and is to terminate when the condition is no longer fulfilled.

18. The method according to claim 13, wherein the network-adjusted logging duration is determined based on at least one of: a current network congestion status, or a dataset requirement of the Al / ML model.

19. A non-transitory computer-readable recording medium having recorded thereon instructions executable by a network entity to cause the network entity to perform a method comprising: generating a Radio Resource Control (RRC) message that comprises information associated with at least one of: a condition that triggers a data collection for collecting data associated with an Artificial Intelligence or Machine Learning (AI / ML) model, or a logging duration associated with the data collection; andtransmitting the RRC message to a user equipment (UE).

20. The non-transitory computer-readable recording medium according to claim 19, wherein the information associated with the condition that triggers the data collection comprises: an event type indicator that indicates an event the UE monitors, a threshold parameter that indicates a threshold that triggers the data collection based on the detection of the event, and a time hysteresis parameter that delays the data collection upon detection of the event.

Images