User equipment (UE)-side ai / ML data management

Abstract

Example embodiments of the present disclosure relate to user equipment-side (UE-side) Artificial Intelligence and / or Machine Learning (AI / ML) data management. According to example embodiments, a system may include a network entity. The network entity may be configured to determine, based on a network condition and a request for an uplink resource of a user equipment (UE) for transmission of data associated with an Artificial Intelligence or Machine Learning (AI / ML) model, a configuration of the transmission of the data. Subsequently, the network entity may be configured to transmit, to the UE, a message that includes the configuration of the transmission of the data.

Description

USER EQUIPMENT (UE)-SIDE AI / ML DATA MANAGEMENTCROSS REFERENCE TO RELATED APPLICATIONS

[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 user equipment-side (UE-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 modern 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 via the telecommunication systems or networks. A specific configuration may involve the deployment (e.g., training, updating, executing, etc.) of AI / ML models for the benefit, optimization, or service provisioning of an individual User Equipment (UE). For instance, the UE may communicate withone or more network entities (e.g., a base station, a Radio Access Network (RAN) node, a core network entity, etc.) for the purposes of, for example, storing the AI / ML models and / or associated data (e.g., in a server, etc.), sharing the AI / ML models and / or associated data with other devices (e g., sending the AI / ML models / data to another devices via the one or more network entities, etc.), utilizing the AI / ML models and / or the associated data for UE-specific purposes (e.g., executing the AI / ML models for providing individual AI / ML inference, optimizing the performance of a specific UE based on its unique environment, etc.), and the like.

[0005] In the aforesaid configuration, the AI / ML models may be implemented locally at the UE, implemented in one or more external devices (e.g., cloud servers, edge servers, etc.) with which the UE communicates via the one or more network entities, implemented within the one or more network entities themselves as a UE-specific instance, or a combination thereof. For descriptive purposes, such a configuration may be referred to as the "UE-side AI / ML” herein.

[0006] The deployment and continuous operation of the UE-side AI / L 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 AEML-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

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

[0008] According to example embodiments, a system may include a network entity that may be configured to determine, based on a network condition and a request for an uplink resource of a user equipment (UE) for transmission of data associated with an Artificial Intelligence or Machine Learning (AI / ML) model, a configuration of the transmission of the data. Subsequently, the network entity may be configured to transmit, to the UE, a message that includes the configuration of the transmission of the data.

[0009] According to example embodiments, a method may include determining, based on a network condition and a request for an uplink resource of a user equipment (UE) for transmission of data associated with an Artificial Intelligence or Machine Learning (AI / ML) model, a configuration of the transmission of the data; and transmitting, to the UE, a message that includes the configuration of the transmission of the data.

[0010] 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 determining, based on a network condition and a request for an uplink resource of a user equipment (UE) for transmission of data associated with an Artificial Intelligence or Machine Learning (AI / ML) model, a configuration of the transmission of the data; and transmitting, to the UE, a message that includes the configuration of the transmission of the data.

[0011] 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

[0012] 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:

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

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

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

[0016] FIG. 13 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 otherembodiments 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 similar language 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) standardorganization, and the like. For instance, the terms “RRC message,” “MAC CE,” “IE,” “SDAP,” “PDCP,” “CN,” “UPF,” “OAM,” 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 or more 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 otherwisespecified, 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 user equipment-side (UE-side) AI / ML configuration, a UE may communicate with one or more network entities (e.g., base station, radio access network (RAN), core network, etc.) to implement or deploys (e.g., trains, updates, executes, etc.) one or more AI / ML models to utilize UE-related operations or services (e.g., storing / sharing the AI / ML models or the associated data with other devices, training the AI / ML models online, enabling network optimization for the specific UE, 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.

[0030] As also described above, the deployment and continuous operation of the UE-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 ofthings (ToT) 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.), AI / ML-related data (e.g., model training parameters, AI / ML model weight, etc.), and the like.

[0031] In view of the above, the communication among UE and the network entity(s) is a critical aspect in managing AI / ML data for UE-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 UE-side AI / ML deployment, such as the precise conditions under which data collection / logging should be initiated, when the UE may transmit the collected AI / ML data, and the like. 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 UE-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 UE-side AI / MLdata management. In the following, the shortcomings of the related art are described for the following seven aspects:(1) AI / ML Data Transfer Over User Plane (UP): Network Adaptability and Traffic Optimization;(2) Handling AI / ML Data Aggregation and Compression for UP Transfer;(3) AI / ML Data Transmission Timing and Synchronization Over UP;(4) AI / ML Data Differentiation for UP Traffic Prioritization;(5) Network Entity’s Role in the Control and Configuration of UE-Side Data Collection;(6) Network Entity’s Role in AI / ML Data Transfer and Visibility; and (7) AI / ML Data Transfer to Core Network (CN) or Operations, Administration, and Maintenance (0AM).

[0033] Regarding aspect (1), AI / ML data transfer over the User Plane (UP) may introduce a different set of challenges compared to traditional broadband services, due to the unique characteristics of AI / ML data traffic patterns. For instance, AI / ML traffic patterns may be dynamic, workload-dependent, and highly asynchronous, leading to the challenges in managing AI / ML data transfer using conventional Quality of Service (QoS) scheduling mechanisms. Unlike voice or video services that maintain a continuous flow of packets, AI / ML data transmissions are often triggered by event-driven processes (such as model training / retraining, network anomaly detection, or inference updates), resulting in unpredictable traffic spikes. The unpredictable characteristic of AI / ML traffic does not align with standard scheduling models (e.g., 5G Quality of Service Identifier (5QI)-based scheduling models, etc.) in the related art, resulting in the need for new,AI / ML-specific traffic management mechanisms at the network entities (e.g., Next Generation Radio Access Network (NG-RAN), etc.).

[0034] In this regard, one of the issues of aspect (1) is that unregulated AI / ML data flows could saturate uplink resources, particularly in scenarios where multiple UEs upload large volumes of AI / ML data (e.g., AI / ML training data, etc.) simultaneously. While UP may allow for scalable AI / ML data transfer, the related art lacks mechanisms to prioritize and regulate transmission dynamically at the network level (e.g., RAN level, etc.). If AI / ML data traffic is not managed properly, it may overload uplink resources and may interfere with more latency-sensitive traffic such as Voice over New Radio (VoNR), real-time streaming or gaming, or even essential controlplane signaling.

[0035] A possible approach to mitigating the aforesaid issue(s) of aspect (1) is implementing AI / ML-specific dynamic scheduling, where the network entity (e.g., NG-RAN, etc.) can identify and allocate resources for AI / ML workloads based on network conditions. However, there are no standardized or clarified mechanisms in the related art to implement such an approach. Specifically, implementing AI / ML-specific dynamic scheduling would require defining AI / ML traffic classes distinct from traditional Guarantee Bit Rate (GBR) / non-GBR services (to ensure AI / ML data does not degrade Quality of Service (QoS) for other traffic types), which is not suggested or specified in the related art. Further, scheduling AI / ML traffic in real-time (or near real-time) at the network entity requires a careful balance between minimizing control-plane overhead and maintaining flexibility for UE-initiated transmissions, the details of which are not introduced or suggested in the related art.

[0036] Another issue of aspect (Qis how to preemptively manage AI / ML data bursts rather than react to congestion once it occurs. Predictive scheduling, based on historical AI / ML trafficloads and workload anticipation, may allow the network entity to allocate resources before congestion occurs rather than after. However, this requires additional intelligence at the scheduler level, which may not be straightforward to implement within the system architectures in the related art.

[0037] Regarding aspect (2), one of the inefficiencies of AI / ML data transfer in the related art is redundancy in data reporting. Unlike general application data, AI / ML data may be repetitive and contain large volumes of correlated measurements, causing the network to process multiple versions of the same or similar data unnecessarily. For instance, AI / ML data (e.g., AI / ML model updates, etc.) may contain minor changes between iterations (which may be compressed before transmission without loss of usefulness), leading to inefficient uplink resource utilization. As another example, unlike conventional application data, AI / ML data often includes metadata that doesn’t need to be fully transmitted every time. However, current mechanisms in the related art (e.g., User Plane Function (UPF) mechanism, RAN mechanism, etc.) do not account for the nature of AI / ML data, causing redundant AI / ML data (particularly, in the case of transmission of incremental AI / ML model updates and metadata) to be transmitted as full payloads, leading to unnecessary bandwidth consumption and inefficient uplink resource utilization.

[0038] Although the transmission of the redundant AI / ML data may incur unnecessary burdens on the air interface, there are no defined or clarified mechanisms in the related art for addressing such an issue. Specifically, there are no defined or clarified mechanisms in the existing UP mechanisms for aggregating AI / ML data at the UE level before transmission, let alone supporting AI / ML-specific data compression or filtering.

[0039] Regarding aspect (3), unlike conventional user traffic, AI / ML data collection and transmission often occur asynchronously and are often uncoordinated across UEs, leading tosimultaneous uplink bursts that may congest network resources. For instance, unlike conventional user traffic, which follows scheduled resource allocations, AI / ML transmission may be dependent on external triggers such as model retraining events, network anomaly detection, or inference feedback requirements. Further, AI / ML data collection and transmission may also be triggered at unpredictable intervals, such as after inference cycles or model retraining. The unpredictability of the timing of AI / ML data collection and transmission in the related art introduce challenges for network-level (e.g., RAN-level) synchronization, leading to a situation where the AI / ML data transmission may compete with real-time traffic, causing resource contention, network congestion, and inefficient spectrum utilization.

[0040] Regarding aspect (4), in the related art, AI / ML data is treated as generic, best-effort UP traffic, i.e., it competes with generic uplink traffics (e.g., latency-sensitive traffics, etc.) for network resources without explicit prioritization mechanisms. Since, the AI / ML data is highly diverse (e.g., the AI / ML data may encompass real-time inference data, periodic training model updates, batch-processing workloads, etc.), the lack of prioritization mechanisms for the AI / ML data may lead to the following problems: (a) inference data delays, impacting real-time (or near real-time) AI / ML-operations (e.g., real-time AI / ML inference updates require lower latency but are not prioritized over background AI / ML model training data or generic non-AI / ML data, etc.); (b) AI / ML data may be scheduled inefficiently and compete with real-time / near real-time services, leading to inefficient network resource utilizations, AI / ML performance degradations, and potential QoS conflicts and inefficiencies (e.g., AI / ML training data uploads could be deprioritized by existing QoS mechanisms, leading to excessive delays in scenarios where rapid AI / ML model updates are required for adaptive network optimizations, etc.); and (c) there is no defined mechanism in current QoS frameworks that may enable the network entity to differentiate betweenhigh-priority and low-priority UP traffics (e.g., high-priority AI / ML traffic, low-priority AI / ML traffic, high-priority generic traffic, etc.) or dynamically reassign AI / ML traffic priority based on network conditions.

[0041] Regarding aspect (5), to begin with, the network entity (e.g., NG-RAN) in the related art has no defined role in actively managing AI / ML data collection timing, leading to potential network congestion risks. Specifically, in the related art, the AI / ML data collection process typically follows either UE autonomy (e.g., UE decides when to collect and report data) or network-controller scheduling (e.g., via CN or 0AM, where higher-layer functions define when data collection should occur). In this regard, the extent of the role of the network entity (e.g., NG-RAN) in initiating, regulating, and terminating data collection remains unclear (e.g., it is unclear if the network entity should have a more direct role in managing when and how AI / ML data is collected at the UE, etc.).

[0042] In view of the above, although it may be possible to allow the network entity to introduce AI / ML-aware measurement control parameters (e.g., in RRC signaling, etc.) to ensure that the AI / ML data collection aligns with network resources availability, if the network entity takes full control of AI / ML data collection scheduling, it may introduce excessive control-plane signaling (e.g., RRC signaling) overhead, particularly in high-density networks (e.g., where a significant number of UEs may need collection adjustments, etc.). Thus, without specifying or clarifying the role of the network entity in providing the control of AI / ML data collection scheduling, the implementation of the network entity to address the aforesaid issue(s) of aspect (5) may not be feasible. In addition, although a hybrid approach (where the network entity provides collection recommendations while UEs maintain autonomy or flexibility in determining when AI / ML data is collected within those constraints) may be a theoretically possible solution, such anapproach is not specified or clarified in the related art, and it is unclear how specifically such an approach can be implemented in existing network architecture or frameworks.

[0043] Regarding aspect (6), one of the most critical challenges with AI / ML data transfer over UP in the related art is that the network entity (e.g., NG-RAN) has little to no visibility into these transfers and the AI / ML data transmissions over UP may occur without explicit network awareness, resulting in difficulty for enforcing policies, managing congestion, or applying prioritybased traffic handling

[0044] Unlike Control Plane (CP) transfers (e.g., where the network entity can monitor / track session parameters and enforce policies), UP-based AI / ML transfers may bypass traditional monitoring mechanisms, i.e., AI / ML data (which is typically uploaded in bursts, often triggered by external application-level events, etc.) may be uploaded without explicit network awareness, and the network entity may not anticipate / predict the AI / ML traffic surges or preemptively manage uplink scheduling. Rather, since the AI / ML data transfers occur without explicit signaling interactions with the network, the network may not know when the AI / ML data is being uploaded by the UE unless specific mechanisms are introduced. Accordingly, the network may not effectively and dynamically prioritize, shape, or schedule AI / ML traffic, and it is difficult for the network to monitor, prioritize, or manage AI / ML traffic dynamically, leading to unregulated AI / ML data bursts, uplink congestion, and an inability to enforce priority-based scheduling mechanisms.

[0045] In this regard, while metadata tagging (where UE may insert network-recognizable identifiers into AI / ML data packets) may be a potential approach in classifying UP traffic and allowing the network entities (e.g., NG-RAN, UPF, etc.) to differentiate AI / ML traffic from other non-AI / ML UP flows, the technical feasibility of such an approach remains uncertain andunspecified. Unlike CP-based services (where metadata is typically embedded in Non-Access Stratum (NAS) messages or RRC messages and allows the network to track session parameters and enforce policies), UP packets are not processed directly by the network entities, making it unclear how the network entity would use metadata tagging (e.g., which of the Packet Data Convergence Protocol (PDCP) level, Service Data Adaptation Protocol (SDAP) level, or UPF level should apply the metadata tagging, etc.) without excessive overhead.

[0046] Another challenge is that the AI / ML traffic is unpredictable and may generate unpredictable traffic bursts, leading to network congestion in uplink-heavy scenarios (e.g., the unpredictable AI / ML traffic may cause uplink congestion when multiple UEs attempt to transfer large AI / ML datasets at the same time, etc.). While the network entities (e.g., NG-RAN, etc.) in the related art may manage congestion for traditional uplink traffic, there is no defined mechanism that enables the network to regulate AI / ML-related traffic dynamically based on real-time (or near real-time) conditions.

[0047] A potential solution for solving the aforesaid issue(s) of aspect (6) is allowing the network to issue congestion indicators dynamically to the UE, instructing UEs to adjust their AI / ML data transfer rates or delay non-urgent uploads based on real-time (or near real-time) network load conditions. Nevertheless, there are no specified or clarified mechanisms in the related art for implementing the congestion signaling (e.g., it is not clear how frequently the network should send congestion updates to the UE, etc.). In this regard, excessive congestion signaling could introduce unnecessary control-plane overhead (e g., especially in dense network deployments), while infrequent updates might not provide enough control to prevent congestion events beforehand.

[0048] Another possible solution for solving the aforesaid issue of aspect (6) is providing a periodic AI / ML data transfer status reporting mechanism, where the UE may be allowed to periodically (or continuously) provide the network (e.g., NG-RAN) with status updates about ongoing AI / ML data transfers, providing the network with better forecasting capabilities and allowing the network to track trends and apply preemptive congestion management techniques, thereby ensuring that AI / ML data bursts may be managed more proactively instead of reactively. However, such an approach remains unspecified and non-standardized in the related art, and it is unclear how the current network mechanisms (e.g., RAN mechanisms, etc.) may be utilized to support AI / ML -related transfer status reporting.

[0049] Regarding aspect (7), one of the key challenges in AI / ML data transfer is the complexity in determining how AI / ML data should be classified and routed within the network. While the network entity (e.g., UPF, etc.) in the related art may handle traffic classification based on service types (e.g., IMS voice, video streaming, best-effort browsing, etc.), there is no standardized mechanism that enables the network (e.g., RAN, UPF, etc.) to differentiate AI / ML data from regular user traffic, creating an ambiguity in whether AI / ML data should be treated as application-layer content (requiring aggregation in core network (CN)) or network-optimization telemetry (better suited for 0AM processing), and ultimately leading to inefficient management of AI / ML data (e.g., AI / ML model updates, inference data, etc.).

[0050] Further, the data transport formats in the related art do not account for AI / ML-specific processing needs, resulting in potential delays in various AI / ML-operations such as model updates and inference optimizations. Specifically, the lack of clear routing policies for managing AI / ML data and the lack of standardized traffic classification mechanisms for AI / ML data at the network (e.g., RAN, UPF, etc.) may be a significant issue, as it can lead to inefficient managementof inference updates and training model transfers. AI / ML workloads vary (e.g., some datasets are critical for real-time UE / network performance optimization, while others are long-term model training updates that do not require immediate processing, etc.), and thus, if all AI / ML data is treated the same way, networks risk either introducing delays in critical inference operations or over-prioritizing low-priority model updates that could have been scheduled more efficiently.

[0051] A potential solution for addressing the aforesaid issues of aspect (7) is implementing AI / ML-specific traffic classification at the network (e.g., at RAN level), enabling the network to pre-classify AI / ML data before it reaches UPF, rather than expecting UPF alone to handle differentiation. Nevertheless, in the related art, there are no standardized mechanisms for indicating AI / ML data to the network. There is a need to standardize AI / ML data formatting indicators, ensuring that the network (e.g., CN and 0AM functions) can efficiently parse and process AI / ML datasets without unnecessary conversions or delays.

[0052] Another uncertainty of the potential solution of the aforesaid issues of aspect (7) is it remains unclear as to whether AI / ML data routing policies should be static or adaptive. A static routing model may define fixed rules on whether a particular AI / ML dataset should be sent to the network (e.g., CN or 0AM functions), ensuring consistency across deployments. In contrast, an adaptive model may allow dynamic rerouting of AI / ML data based on network congestion, available processing capacity, or other real-time factors. While adaptive routing introduces flexibility, it also requires additional network intelligence and coordination between RAN and core functions. In this regard, it is unclear in the related art as to whether AI / ML routing should follow predefined (static) policies or adaptive mechanisms based on network conditions.

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

[0054] Firstly, with respect to aspect (1), example embodiments of the present disclosure introduce and exemplify a dynamic AI / ML-related uplink transmission management that may be implemented by a network entity (e.g., NG-RAN, etc.) to efficiently and effectively manage AI / ML traffic (which may be inherently unpredictable and bursty), thereby addressing the shortcomings of aspect (1) as described above.

[0055] By implementing the example embodiments, the network entity can identify and differentiate the transmission of AI / ML data from other user-plane (UP) traffic, thereby optimizing the allocation of uplink resources for AI / ML data transmission based on one or more real-time (or near real-time) network conditions. Specifically, the network may prioritize and regulate the transmissions dynamically based on the network condition(s), ensuring that the network traffic associated with the transmission of the AI / ML data does not interfere with or degrade the QoS of other UP traffic. Accordingly, the network entity may effectively reduce the risk of AI / ML traffic congesting uplink resources and minimize interference of the AI / ML traffic with more latencysensitive traffic types (e.g., VoNR, real-time gaming, essential control-plane signaling, etc.).

[0056] Furthermore, by implementing the example embodiments, the network entity can deprioritize the transmission of AI / ML data in favor of high-priority traffic (e.g., GBR traffic) when needed, while also preemptively managing the AI / ML data bursts. Specifically, the network entity may perform predictive scheduling (e g., based on historical AI / ML traffic loads and workload predictions) to allocate uplink resources before the network congestion occurs (or before the network congestion reaches a critical level), rather than merely reacting after the network congestion occurs (or after the network congestion reaches the critical level). In this way, thenetwork entity may preemptively schedule AI / ML traffic when network conditions are favorable, thereby smoothing traffic spikes and reducing network congestion risk. Furthermore, the UE is enabled to explicitly request AI / ML-specific uplink resource allocations, thereby ensuring that the network entity is aware of the specific nature and requirements of the transmission of the AI / ML data.

[0057] In addition, the example embodiments also introduce and exemplify an AI / ML-specific congestion mitigation mechanism. Specifically, in scenarios where network load is high, the network-driven congestion control may allow the network entity to provide control signaling (e.g., RRC signaling, etc.) to instruct the UE to adjust the transmission rate or to adjust the transmission timing (e.g., delay or reschedule AI / ML data transmissions) dynamically based on real-time (or near real-time) congestion levels. By providing these specific adjustment instructions, the network entity may effectively balance the need for robust traffic management with the need for efficiency, minimizing control-plane signaling overhead.

[0058] With respect to aspect (2), the example embodiments introduce and exemplify a data aggregation optimization mechanism that may be implemented by the network entity (e.g., NG-RAN) to mitigate the transmission of redundant AI / ML data and optimize uplink resource (e.g., bandwidth, etc.) consumption, thereby addressing the shortcomings of aspect (2) as described above.

[0059] By implementing the example embodiments, the network entity may instruct or guide the UE to aggregate the AI / ML data in a manner that may effective suppress data redundancy and streamline data delivery. For instance, the network entity may instruct the UE to batch model updates prior to transmission rather than sending them as frequent, individual reports. Furthermore, the network entity may instruct the UE to filter redundant data to ensure that only data associatedwith meaningful changes is transmitted. By utilizing network-defined filtering thresholds, the UE can evaluate aggregated AI / ML data to detect and filter redundant AI / ML data. Accordingly, the UE may suppress the uplink transmission of redundant (or less meaningful) AI / ML data, effectively preventing the wastage of air interface resources on highly correlated or repetitive AI / ML data that do not improve the UE-side AI / ML operations. In addition, the network entity may instruct the UE to perform header compression at the PDCP layer, thereby enabling the UE to selectively identify and remove redundant metadata from the AI / ML data before transmission and effectively reducing the size of the transmitted AI / ML data without loss of usefulness. Advantageously, by implementing the example embodiments, the aggregation (e.g., collection, batching, compression, filtering, etc.) of the AI / ML data at the UE level may effectively and efficiently minimize signaling overhead and ensure that the uplink transmission consists of consolidated, bandwidth-efficient payloads, thereby transforming AI / ML data transmission into an efficient process that reduces unnecessary bandwidth consumption while maintaining the integrity and timeliness of critical AI / ML for UE-side AI / ML purposes.

[0060] With respect to aspect (3), example embodiments introduce and exemplify an a data transmission timing optimization mechanism that may be implemented by the network entity (e.g., NG-RAN) to optimize the scheduling operation for multiple data transmissions and ensure the data transmissions requested by multiple UEs may be synchronized and aligned with the real-time (or near real-time) network conditions, thereby addressing the shortcomings of aspect (3) as described above.

[0061] By implementing the example embodiments, multiple UEs may be enabled to request the network entity for uplink resources (e.g., time slot, etc.) for data transmission before actually sending the AI / ML to the data, and the network entity may control the precise timing ofthe data transmission, efficiently and effectively preventing unregulated and asynchronous data transmissions from multiple UEs. For instance, the network entity may provide adaptive, network condition-aware (e.g., congestion-aware) transmission scheduling for the AI / ML data transmissions, where the network entity may dynamically assign or adjust specific time slot(s) for AI / ML data transmissions according to one or more real-time (or near real-time) network conditions (e.g., network congestion, etc.), thereby ensuring that the AI / ML data transmissions are coordinated across the UEs, minimizing interference of the AI / ML data transmission with non-AI / ML traffics, and maximizing the efficiency of available uplink resources.

[0062] With respect to aspect (4), example embodiments of the present disclosure introduce and exemplify an AI / ML traffic differentiation mechanism that may be implemented by the network entity (e.g., NG-RAN) to optimize the User Plane traffic prioritization and enhance the handling of AI / ML data, thereby addressing the shortcomings of aspect (4) as described above.

[0063] By implementing the example embodiments, the network entity may efficiently and dynamically differentiate different types of network traffics (e.g., differentiate AI / ML traffic from other User Plane traffic (e.g., AI / ML-related traffic vs non-AI / ML traffic, etc.), differentiate different type of AI / ML traffics (e.g., inference data traffic vs model training data traffic, etc.), or the like), thereby effectively prioritizing the network traffics according to the real-time (or near real-time) conditions and requirements and preventing QoS conflicts among different type of network traffics. Further, the network entity may dynamically reassign and reclassify AI / ML traffic priority in real-time (or near real-time) based on fluctuating network conditions. This adaptability ensures that AI / ML data is always assigned priority levels that align with current network loads and data utilization requirements. For instance, the network entity can enforce policies where background AI / ML traffic is deprioritized when needed (e.g., during periods ofnetwork congestion or other critical events, etc ), while retaining the flexibility to upgrade priority levels when resources become available. This dynamic adjustment mechanism ensures optimal network stability while meeting the diverse performance requirements of AI / ML workloads.

[0064] With respect to aspect (5), example embodiments introduce and exemplify an AI / ML data collection management mechanism that may be implemented by the network entity (e.g., NG-RAN) to effectively and efficiently control, configure, and regulate AI / ML data collection at the UE, thereby addressing the shortcomings of aspect (5) as described above.

[0065] By implementing the example embodiments, the network entity may proactively manage network resources by controlling the collection and generation of AI / ML data at the source (i.e., the UE) rather than merely managing its subsequent transmission. Accordingly, the network entity may effectively and efficiently reduce potential network congestion risks by dynamically managing the amount of data collected at the UE (and therefore the amount of data transmitted by the UE) according to one or more real-time (or near real-time) conditions, thereby preventing the network congestion before it occurs.

[0066] Additionally, by implementing the method and operations described herein, the network entity may act as a policy enforcer rather than a scheduler. By checking high-level requirements provided by higher-layer functions (e g., CN, 0AM, etc.) against real-time (or near real-time) network conditions, the network entity may determine optimal configuration for collecting the AI / ML data, thereby translating the high-level data collection requirements provided by the higher-layer functions into concrete data collection rules / policies, without requiring the network entity to incur additional data collection scheduling. Furthermore, the network entity may also guide the UE to collect the AI / ML data in an optimal manner. For instance, by implementing the hybrid control mechanism of example embodiments, the network may define data collectionrules / policies while permitting the UE to autonomously adjust the specific data collection configuration (e.g., timing, frequency, etc.), thereby optimizing the resources at both the UE side and the network side. For instance, the UE may effectively avoid resources (e.g., power consumption, computing power, etc.) on collecting and processing data that cannot be successfully and timely transmitted to the network entity, while the network entity may effectively reduce control-plane signaling overhead (particularly in high-density networks where micromanaging the data collection configurations of a significant number of UEs is not feasible).

[0067] With respect to aspect (6), example embodiments introduce and exemplify an AI / ML data transmission management mechanism that may provide visibility of the AI / ML data transmission to the network entity, thereby enabling the network entity to proactively enforce policies, manage congestion, and apply priority -based traffic handling, effectively addressing the shortcomings of aspect (6) as described above.

[0068] Specifically, the example embodiments exemplify how the network entity may instruct and guide the UE in performing metadata tagging on AI / ML traffic at the SDAP level. Advantageously, by implementing the example embodiments, the network entity may effectively and efficiently instruct or guide the UE to perform AI / ML metadata tagging at the SDAP layer, thereby allowing the network entity to effectively and efficiently identify and differentiate AI / ML traffic from generic UP traffic by processing only the header information, without modifying UP data packet handling or requiring deep packet inspection. Accordingly, the network entity may dynamically apply differentiated scheduling rules and congestion-aware traffic management for AI / ML workloads with minimal processing resources and latency.

[0069] Furthermore, the example embodiments also exemplify an AI / ML data transmission status reporting mechanism, where the UE is enabled to update (e.g., periodically,upon detecting a specific event, etc.) the network entity on the AI / ML data upload / preparation progress to optimize uplink resource scheduling. Specifically, by receiving the AI / ML data transmission status report from the UE before the AI / ML data is ready for transmission, the network entity may predict or anticipate the uplink resources required for accommodating the AI / ML traffic, and then perform uplink resource pre-allocation and / or proactively adjust one or more scheduling policies according to one or more real-time / near real-time conditions (e.g., network congestion, AI / ML data requirements, etc.). In this way, the network entity may ensure that large-scale AI / ML data bursts are managed smoothly without disrupting parallel, latencysensitive services (if any).

[0070] In addition, the example embodiments also exemplify a mechanism that enables the UE to request network assistance in the scheduling of AI / ML data transmissions. For instance, after receiving the uplink scheduling resources pre-allocated by the network entity (based on the information in the UE-provided status report), if the UE determines that the pre-allocated uplink resources are not sufficient (e.g., the actual AI / ML data is larger than predicted, etc.) and additional uplink resources are required, the UE may transmit an explicit request to the network entity to request for extended uplink capacity or additional uplink resources. In this way, the uplink scheduling operation may be transformed from a reactive procedure (e.g., based solely on instantaneous AI / ML data pending in the local buffer of the UE) to a proactive procedure, effectively reducing the amount of signaling overhead for uplink resource request (when the preallocated uplink resources are sufficient) while ensuring that the UE may be allocated with sufficient uplink resources (when the pre-allocated uplink resources are insufficient) for successfully transmitting the AI / ML data.

[0071] With respect to aspect (7), example embodiments introduce and exemplify an AI / ML data transfer management mechanism that enables the network entity to handle the AI / ML traffic classification procedure, thereby addressing the shortcomings of aspect (7) as described above.

[0072] By implementing the example embodiments, the network entity may appropriately classify the AI / ML data before transferring the AI / ML data to the high-layer, target network entity (e.g., CN, UPF, 0AM). For instance, the network entity may classify the AI / ML data based on the associated urgency / priority level, processing availability of the target network entity, real-time / near real-time network conditions, impact of the transmission of the AI / ML data on other network operations, and the like. Further, the network entity may include one or more standardized AI / ML data formatting indicators in the AI / ML data, thereby ensuring that the target network entity can efficiently parse and process the AI / ML data without unnecessary conversions or delays. Furthermore, the network entity may implement an adaptive AI / ML routing mechanism, thereby enabling real-time / near real-time adjustment of AI / ML data flows and dynamic rerouting of the AI / ML data based on one or more real-time / near real-time conditions (e.g., network congestion, processing resource availability, etc.).

[0073] In view of the above, example embodiments of the present disclosure introduce and exemplify various mechanisms that may address the shortcomings of the above-described aspects ( l)-(7), thereby enabling effective and efficient UE-side AI / ML data management, particularly on the collection and transmission of the associated AI / ML data.

[0074] 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 ofthe features, components, configuration, operations, and implementations of the example embodiments of the present disclosure are provided in the following.Example System Architecture and Configurations

[0075] 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 UE-side AI / ML purposes.

[0076] As described above, in a UE-side AI / ML configuration, one or more UEs may communicate with one or more network entities for the communication of data associated with one or more AI / ML models and / or AI / ML-related operations (“AI / ML data” herein). For descriptive purposes, it may be assumed that the UE 120 communicates with the network entity 110 (and / or one or more devices via the network entity 110).

[0077] In the UE-side AI / ML configuration, the AI / ML model(s) may be implemented or deployed (e.g., trained, updated, executed, etc.) in one or more of : (a) the UE 120, which acts as the entity that collects and provides the AI / ML data; (b) one or more devices (e.g., another UE, a server, an edge node / terminal, etc.) with which the UE 120 is communicating via the network entity 110; and (c) the network entity 110 (in this configuration, the UE 120 may, but not necessarily, communicate with the one or more devices (e.g., the another UE, etc.) via the network entity 110).

[0078] In this regard, “UE-side AI / ML purposes,” “AI / ML-related operations,” and similar descriptions as used herein may include any suitable type of operations associated with the lifecycle or utilization of at least one AI / ML model for the UE 120, such as, but not limited to, oneor more of: (a) general model and / or data management (e.g., storing the AI / ML model or associated data, sharing the model / data with other devices or the network, updating the model / data, etc.), (b) collaborative learning and / or inference (e.g., implementing distributed training architectures such as federated learning that computes local data at the UE 120 and transmitting them to a global device / server, performing split inference such as executing a portion of inference at the UE 120 and offloading the subsequent portions of inference to an edge device or network entity, etc.), (c) UE-specific service provisioning (e.g., executing the AI / ML model to provide application-level enhancements or automations, such as contents generation, gaming rendering, security threat detection and responding, etc.), and (d) UE-specific network optimization (e.g., utilizing the AI / ML data or model inference outputs to optimize the specific radio link or performance of the UE 120, optimizing UE power-saving opportunity by predicting UE traffic and optimizing Discontinuous Reception (DRX) configurations, facilitating seamless handovers by performing mobility prediction, etc.).

[0079] Further, the “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, the UE 120, and / or other devices, for UE-side AI / ML purposes. For instance, the AI / ML data may include, but not limited to, one or more of: radio measurement data (e.g., signal strength, interference trends, etc.), beam-related data (e.g., beam transitions, beam-level 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-intemal status data (e.g., power consumption, storage availability, battery level, thermal status, computing load, motion trajectory, beam selection metric, application requirements, etc.), AI / ML-related metadata(e g., dataset classification / categorization information, model identifiers, performance feedback, model weights or gradients, intermediate layer activations, loss function values, etc.), and the like.

[0080] 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 (e.g., Next Generation (NG)-RAN, O-RAN, etc.) node or RAN 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 UE-side AI / ML purposes.

[0081] 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, a personal computer (PC), etc.), a combination of mobile devices and / or a static devices (e.g., a high-performance computing (HPC) system, a cloud cluster, etc.), a vehicle toeverything (V2X) communication terminal, a drone or unmanned aerial vehicle (UAV), or any other suitable terminal or device that may be configured to provide or report data to the network entity 110 for UE-side AI / ML purposes. In some example embodiments, the UE 120 may communicate with one or more devices (e.g., another UE, an edge node, etc.).

[0082] 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 UE-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.

[0083] The UE-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 appropriately collect, process, and transmit the AI / ML data, such as (but not limited to): data collection activation, data tagging and classification, data compression, data batching, data filtering, data transmission rate adjustment, data transmission suspension and resume, and the like. The network entity 110 may provide the UE-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 to collect, process, and transmit the AI / ML data.

[0084] On the other hand, the UE-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 110to determine the UE-side AT / ML data management configuration and / or deploy (e.g., train, manage, execute, etc.) one or more AI / ML models for UE-side AI / ML purposes. In addition to or in alternative to the above-mentioned AI / ML data, the UE 120 may provide a measurement report (e g., MDT report, RRC measurement report, etc.) that contains the collected or logged AI / ML data, a request (e.g., a request for an uplink resource, a request for additional uplink resources, etc.), a status report that indicates the process of the data collection and the preparation of the data transmission, or the like.

[0085] 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 UE-side AI / ML data by, for example, providing realtime (or near real-time) reports and data collection / logging triggering requests based on its localized observations of the radio environment and / or its internal operational status. Accordingly, this bidirectional information exchange may ensure that the UE-side AI / ML data is collected and managed in an efficient, responsive, and standardized manner.

[0086] 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. 13.

[0087] 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 with reference to FIG. 1. For instance, as further described below with reference to FIG. 2 to FIG. 11, 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 (7).

[0088] 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. 12.Example Methods and Operations

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

[0090] 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 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 thenetwork 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.

[0091] According to example embodiments, one or more operations of the network entity (e.g., base station, NG-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 computerexecutable instructions which, when executed by the processor, cause the processor to perform one or more operations 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. 12.

[0092] The example methods and operations in FIG. 2 to FIG. 11 may be implemented by the network entity to effectively and efficiently manage UE-side AI / ML data, thereby addressing the above-mentioned shortcomings of aspects (1) to (7). Generally, the example methods and operations in FIG. 2 to FIG. 4 may be associated with aspect (1), the example method and operations in FIG. 5 may be associated with aspect (2), the example method and operations in FIG.6 may be associated with aspect (3), the example method and operations in FIG. 7 may be associated with aspect (4), the example method and operations in FIG. 8 may be associated with aspect (5), the example methods and operations in FIG. 9 and FIG. 10 may be associated with aspect (6), and the example method and operations in FIG. 11 may be associated with aspect (7).

[0093] 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, themethods and operations in two or more of FIG. 2 to FIG. 11 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. 11 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. 5 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. 5 in any suitable manner (e.g., simultaneously, sequentially, etc.) to address 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). Further, it can be understood that one or more operations in one of the FIG. 2 to FIG. 11 may be similar to or be part of one or more operations in another one of the FIG. 2 to FIG. 11. By way of a non-limiting example, the operations in one or more of FIG. 2 to FIG. 4 (e.g., operations associated with AI / ML uplink scheduling and traffic optimization, etc.) may involve one or more operations in FIG. 6 (e.g., operations associated with AI / ML data transmission timing and synchronization control, etc.), one or more operations in FIG. 9 (e.g., operations associated with AI / ML data visibility control, etc.), and the like. Thus, it can be understood that the descriptions of an operation with reference to one of the FIG. 2 to FIG. 11 may be applicable to another operation of another one of the FIG.2 to FIG. 11 without departing from the scope of the present disclosure, and redundant descriptions associated therewith may be omitted below for conciseness.

[0094] Further, the methods and operations in two or more of FIG. 2 to FIG. 11 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 for UE-side AI / ML purposes, and the contents,characteristics, and intents of the collected data may be similar to the “AI / ML data,” “data collected for UE-side AI / ML purposes,” and the like, described herein. 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. 11 may be applicable to the data collected via the method and operations in another one of FIG. 2 to FIG. 11, 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. 11 may be applicable to the messages or signals involved operations in the method and operations of another one of FIG. 2 to FIG. 11, and redundant descriptions associated therewith may be omitted below for conciseness.> > Example Methods and Operations associated with Aspect (1)

[0095] 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 a transmission of AI / ML data for UE-side AI / ML purposes.

[0096] As illustrated in FIG. 2, at operation S210, the network entity may be configured to determine, based on a network condition and a request for an uplink resource of the UE for transmission of data associated with an AI / ML model (“AI / ML data” herein), a configuration of the transmission of the data.

[0097] According to example embodiments, the network entity may be configured to receive, from the UE, a message that includes the request (“AI / ML_Resource_Request” herein) for an uplink resource (e.g., a dedicated uplink grant, a time slot, a frequency range, etc.) for thetransmission of the data. The transmission of the data may be performed via the User Plane (UP), based on the uplink resource allocated by the network entity.

[0098] According to example embodiments, the message received by the network entity from the UE may include parameters that characterize the uplink traffic for the data transmission. For instance, the request may include one or more of: a parameter that indicates the volume of the AI / ML data (e.g., a buffer size, etc.), a parameter that indicates the classification of the Al / ML data (e.g., a priority tag distinguishing latency-sensitive / high-priority data like inference data from delay-tolerant / low-priority data like training data, etc.), a parameter that indicates the Quality of Service (QoS) flow or a Service Data Adaptation Protocol (SDAP) header that may carry AI / ML-specific metadata, and a parameter that indicates the characteristics of the AI / ML data (e.g., bursty, requires a specific periodicity, etc.).

[0099] According to example embodiments, the UE may provide the message that includes the request when the UE detects that Al / ML data is ready for uplink transmission, thereby explicitly requesting the network entity for an uplink grant dedicated for the transmission of AI / ML data rather than relying on generic buffer status reports. According to example embodiments, the message provided by the UE may include a Radio Resource Control (RRC) message, and the RRC message may include an Information Element (IE) that indicates that the RRC message is associated with AI / ML-related signaling. For instance, the message may include an RRC Connection Setup Request message, an RRC Connection Resume Request message, and the like.

[0100] Upon receiving the message (that include the request) from the UE, the network entity may be configured to determine the configuration of the transmission of the data based on one or more network conditions. Generally, the network entity may assess one or more currentnetwork conditions (e.g., congestion levels, active traffics, etc.) and resource availability, thereby deciding whether to grant the requested uplink resource for the transmission of the AI / ML data or adjust the transmission of the AI / ML data (e.g., adjust a transmission rate, adjust a transmission timing or delay the transmission, etc.). Further descriptions associated with example operations for determining the configuration of the transmission is provided below with reference to FIG. 3. Accordingly, the network entity may evaluates the network condition(s) to decide whether to allocate and how to allocate uplink resources for the transmission of the AI / ML data.

[0101] At operation S220, the network entity may be configured to transmit, to the UE, a message that includes the configuration of the transmission of the data. This message may serve as an instruction or guidance that inform the UE on how and when to perform the transmission of the AI / ML data. According to example embodiments, the message may include an RRC message that includes one or more lEs that indicates the configuration of the transmission of the data. For instance, 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.

[0102] According to example embodiments where the network entity decides to grant the requested uplink resource at operation S210, the RRC message may include information of a scheduling opportunity (e.g., time and frequency slots) that allows the UE to perform the data transmission. In this way, the network entity may transmit the RRC message to the UE to assign scheduling opportunities for AI / ML-related traffic. On the other hand, according to example embodiments where the network entity decides to adjust the data transmission (e.g., the network entity detects a network congestion, etc.) at operation S210, the RRC message may include information of the network-optimized adjustment to the data transmission (e.g., a timinginstruction indicating how long the UE is required to wait before retying the data transmission, a reduced bit-rate indicating the feasible data transmission rate, etc.). In this way, the network entity may transmit the RRC message to the UE to dynamically instruct the UE to adjust the data transmission (e.g., reduce data transmission rate, delay the data transmission, etc.).

[0103] FIG. 3 illustrates an example method 300, according to one or more example embodiments. One or more operations in method 300 may be part of operation S210 in method 200 and may be performed by the network entity (that may be configured to perform one or more operations in method 200). Specifically, the network entity may be configured to perform one or more operations in method 300 to determine whether any adjustment to a transmission of AI / ML data (requested by the UE) is required, before allocating the uplink resources to the UE for the transmission of the AI / ML data.

[0104] Referring to FIG. 3, at operation S310, the network entity may be configured to determine, based on one or more network conditions, whether an adjustment to the transmission of the AI / ML data is required. Generally, the network entity may process the request (e.g., received from the UE) against current network condition(s) and / or radio resource availability to compute a data transmission configuration that balances the requested AI / ML traffic with existing condition(s).

[0105] According to example embodiments, the network entity may be configured to implement a congestion mitigation mechanism when determining whether an adjustment to the transmission of the AI / ML data is required. For instance, the network entity may map the network traffic required for the transmission of the AI / ML data (“AI / ML traffic” herein) to a Logical Channel Prioritization (LCP) category. Accordingly, the network entity may determine, based on the LCP category of the AI / ML traffic, whether the transmission of the AI / ML data is feasible orshould be preempted in favor of higher-priority traffic (e.g., GBR traffic for VoNR, etc.). Accordingly, the network entity may be configured to compare a network load (e.g., current uplink traffic, etc.) against at least one threshold (“congestion threshold” herein) that indicates a congestion level. Subsequently, the network entity may determine, based on the comparison of the network load to the congestion threshold, whether an adjustment to the transmission of the AI / ML data is required. By way of non-limiting example, based on determining that the network load is equal to or higher than the congestion threshold, the network entity may determine that a network congestion occurs and the adjustment to the transmission of the AI / ML data is required. On the other hand, based on determining that the network load is lower than the congestion threshold, the network entity may determine that a network congestion does not occur and the adjustment to the transmission of the AI / ML data is not required.

[0106] Referring still to FIG. 3, based on determining that the adjustment to the transmission of the AI / ML data is not required, method 300 may proceed to operation S320, at which the network entity may be configured to determine a scheduling opportunity that allows the UE to perform the transmission of the data. The scheduling opportunity may include, for example, one or more time-frequency parameters (e.g., time slot, time duration, transmission window, periodicity, frequency resource block, bandwidth, etc.), one or more transmission parameters (e.g., modulation and coding scheme, transmit power control, etc.), one or more prioritization parameters (e.g., LCP mapping, preemption flag, etc.), and / or the like. According to example embodiments, the network entity may be configured to implement or configure a scheduler (internal or external to the network entity) to determine the scheduling opportunity. For instance, the network entity may configure / implement the scheduler to determine a time / frequency slot where low / no high-priority traffics (e.g., high-priority traffics like VoNR, etc.) are transmitting,determine whether the time / frequency slot is sufficient for carrying the volume of AI / ML data requested by the UE, and assign the time / frequency slot to the UE for the transmission of the AI / ML data if the time / frequency slot is sufficient for carrying the AI / ML data.

[0107] On the other hand, based on determining that the adjustment to the transmission of the AI / ML data is required, method 300 may proceed to operation S330, at which the network entity may be configured to determine the adjustment to the transmission of the AI / ML data. For instance, as described above with reference to FIG. 2, the adjustment to the transmission of the AI / ML data may include at least one of an adjustment to a transmission rate or an adjustment to a transmission timing. According to example embodiments, the network entity may compare one or more network conditions (e.g., current network load, current resource availability, etc.) to one or more thresholds, thereby dynamically determining an appropriate adjustment to the transmission of the Al / AIL data according to the network condition(s) in real-time (or near realtime). Descriptions of an example method associated therewith are provided below with reference to FIG. 4.

[0108] FIG. 4 illustrates an example method 400, according to one or more example embodiments. One or more operations in method 400 may be part of operation S210 in method 200 and / or operation S310 in method 300. Thus, it may be understood that one or more operations in method 400 may also be performed by the network entity (that may be configured to performed one or more operations in method 200 or method 300).

[0109] Specifically, the network entity may be configured to perform one or more operations in method 400 to compare a network condition to one or more thresholds, thereby determining whether any adjustment to a transmission of AI / ML data (requested by the UE at operation S210) is required and determining appropriate adjustment to the transmission of theAI / ML data (if required). For descriptive purposes, it may be assumed that, in example method 400, a current network load is being compared to one or more congestion thresholds to determine the current congestion level, although it is contemplated that the network entity may compare any other suitable network condition(s), such as the current network resource availability, current QoS requirements, and the like, to any suitable thresholds, without departing from the scope of the present disclosure.

[0110] Referring to FIG. 4, at operation S410, the network entity may be configured to compare a network load to a first threshold. This operation may be part of operation S310 in method 300, in which the network load compares a current network condition (i.e., the last known network load in this example) to a first congestion threshold, thereby determining whether an adjustment to the transmission of the AI / ML data is required. Specifically, in this example use case, the network entity may determine whether a network congestion occurs by comparing the network load to the first threshold.[oni] Based on determining that the network load is lower than the first threshold, the network entity may determine that the network congestion does not occur, and thus, method 400 may proceed to operation S420, at which the network entity may be configured to determine that the adjustment to the transmission of the AI / ML data is not required. Subsequently, the network entity may determine a scheduling opportunity that allows the UE to perform the transmission of the AI / ML data (in a similar manner as described above with reference to operation S320 in method 300).

[0112] On the other hand, based on determining that the network load is equal to or higher than the first threshold, the network entity may determine that the network congestion occurs (or has a high possibility of occurring). Accordingly, method 400 may proceed to operation S430, atwhich the network entity may be configured to compare the network load to a second threshold. This second threshold may act as a baseline parameter that defines whether the network congestion reaches / exceeds a critical level or is within an acceptable / operational level.

[0113] Referring still to FIG. 4, based on determining that the network load is lower than the second threshold, method 400 may proceed to operation S440. At this operation, the network entity may determine that the network congestion is within an acceptable / operational level, and the UE can perform the AI / ML data transmission with an adjusted transmission rate (without adjusting the transmission timing by deferring / suspending the AI / ML data transmission). Thus, the network entity may determine that an adjustment to a transmission rate of the AI / ML data transmission is required. The adjustment to the transmission rate may include one or more of: reducing the transmission rate, reducing the resource blocks, utilizing a lower Modulation and Coding Scheme (MCS), and the like.

[0114] On the other hand, based on determining that the network load is equal to or higher than the second threshold, method 400 may proceed to operation S450. At this operation, the network entity may determine that the network congestion reaches or exceeds a critical level, and thus, the transmission timing of the AI / ML data transmission should be adjusted since the AI / ML data transmission is not feasible at the current time (due to the critical network congestion). Thus, the network entity may determine that an adjustment to a transmission timing of the AI / ML data transmission is required. The adjustment to the transmission timing may include, for example, delaying the transmission of the AI / ML data (e.g., the UE is prohibited from performing the AI / ML data transmission and is required to re-attempt the request after a predefined period of time, etc.), temporarily suspending the AI / ML data transmission (e.g., the UE is required to wait for further instructions from the network entity regarding the AI / ML data transmission, etc.), reschedulingthe transmission of the AI / ML data (e.g., instructing the UE to perform the transmission after a period of time, etc.), and the like. In this way, the network entity may implement a network-controlled congestion mitigation operation when the network congestion reaches or exceeds the critical level.

[0115] Upon performing operations S440 or S450, the network entity may be configured to determine the associated adjustment to the transmission of the AI / ML data (e.g., similar to operation S330 in method 300). Upon determining the configuration of the transmission of the AI / ML data (e.g., scheduling opportunity if no adjustment to the transmission is required, an adjustment to the transmission when required, etc.), the network entity may be configured to transmit a message that includes the configuration to the UE (e.g., similar to operation S330 in method 300).

[0116] According to example embodiments, the network entity may be configured to provide an RRC message that includes one or more lEs, each of which may indicate a specific configuration parameter associated with the transmission of the AI / ML data. For instance, assuming that the adjustment to the transmission of the AI / ML data is not required, the RRC message may include a first IE (“AI / ML_Resource_Grant” herein) that indicates the scheduling opportunity for the transmission of the AI / ML data. On the other hand, if the adjustment to the transmission of the AI / ML data is required, the RRC message may include a second IE (“AI / ML_Resource_Adjustment” herein) that indicates the adjustment to the transmission of the data. In this regard, in some example implementations, the RRC message (or the second IE) may further include one or more lEs that are associated with a specific adjustment. For instance, the RRC message (or the second IE) may include a third IE (“AI / ML_Congestion_Indicator” herein) that instructs the UE to implement the adjustment to the transmission rate, a fourth IE(“AI / ML_Deferred_Transmission” or “AI / ML_Timing_Adjustmenf ’ herein) that instructs the UE to implement the adjustment to the transmission timing, and the like.

[0117] According to example embodiments, after sending the message (e.g., RRC message) to the UE to implement the adjustment to the transmission of the AI / ML data, the network entity may be configured to continuously (or periodically) monitor the one or more network conditions and then communicate with the UE for further adjustments to the transmission. For instance, assuming that the network entity provides an RRC message that includes the fourth IE to instruct the UE to temporarily suspend the transmission of the AI / ML data, upon transmitting the RRC message, the network entity may again compare the network load to the second threshold, thereby continuously (or periodically) monitoring the network congestion. Accordingly, based on determining that the network load is lower than the second threshold (e.g., the network congestion is within the acceptable / operational level, the network congestion is ended, etc.), the network entity may provide, to the UE, another RRC message that includes a fifth IE (“AI / ML_Transmission_Resumption” herein) that instructs the UE to resume the transmission of the data. In the case where the adjustment of transmission rate is required, the RRC message may include both the third IE (that instructs the UE to implement the adjustment to the transmission rate) and the fifth IE (that instructs the UE to resume the transmission of the AI / ML data.

[0118] In view of the above, the method and operations described herein introduce and exemplify a dynamic AI / ML-related uplink transmission management that may be implemented by a network entity (e.g., NG-RAN, etc.) to efficiently and effectively manage AI / ML traffic (which may be inherently unpredictable and bursty), thereby addressing the shortcomings of aspect (1) as described above.

[0119] Advantageously, by implementing the method and operations described herein, the network entity may can identify and differentiate the transmission of AI / ML data from other userplane (UP) traffic, thereby optimizing the allocation of uplink resources for AI / ML data transmission based on one or more real-time (or near real-time) network conditions. Specifically, the network may prioritize and regulate the transmissions dynamically based on the network condition(s), ensuring that the network traffic associated with the transmission of the AI / ML data does not interfere or degrade the QoS of other UP traffic. Accordingly, the network entity may effectively reduce the risk of AI / ML traffic congesting uplink resources and minimize interference of the AI / ML traffic with more latency-sensitive traffic types (e.g., VoNR, real-time gaming, essential control-plane signaling, etc.).

[0120] Furthermore, by implementing the method and operations described herein, the network entity can deprioritize the transmission of AI / ML data in favor a high-priority traffic (e.g., GBR traffic) when needed, while also preemptively manage the AI / ML data bursts. Specifically, the network entity may perform predictive scheduling (e.g., based on historical AI / ML traffic loads and workload predictions) to allocate uplink resources before the network congestion occurs (or before the network congestion reaches a critical level), rather than merely reacting after the network congestion occurred (or after the network congestion reaches the critical level). In this way, the network entity may preemptively schedule AI / ML traffic when network conditions are favorable, thereby smoothing traffic spikes and reducing network congestion risk. Furthermore, the UE is enabled to explicitly request AI / ML-specific uplink resource allocations, thereby ensuring that the network entity is aware of the specific nature and requirements of the transmission of the AI / ML data.

[0121] In addition, the methods and operations described herein also introduce and exemplify an AI / ML-specific congestion mitigation mechanism. Specifically, in scenarios where network load is high, the network-driven congestion control may allow the network entity to provide control signaling (e.g., RRC signaling, MAC CE signaling, etc.) to instruct the UE to adjust the transmission rate or to adjust the transmission timing (e.g., delay or reschedule AI / ML data transmissions) dynamically based on real-time (or near real-time) congestion levels. By providing these specific adjustment instructions, the network entity may effectively balance the need for robust traffic management with the need for efficiency, minimizing control-plane signaling overhead while maintaining flexibility for UE-initiated transmissions.>> Example Methods and Operations associated with Aspect (2)

[0122] 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 or control a data aggregation of AI / ML data for UE-side AI / ML purposes.

[0123] As illustrated in FIG. 5, at operation S510, the network entity may be configured to provide, to the UE, a message that includes an information indicating a configuration for aggregating the AI / ML data (i.e., data associated with an AI / ML model). Specifically, the information indicating the configuration for aggregating the AI / ML data may include one or more of: information for applying a batching process (e.g., a batching time, a maximum buffer size, an aggregation window, etc.) to the AI / ML data to reduce control-plane overhead and prevent data fragmentation, information for applying a PDCP-based header compression process (e.g., a profile ID, a compression scope, a metadata stripping configuration, etc.) to the AI / ML data to reduce metadata redundancy and improve spectral efficiency, and information for applying a filteringprocess (e g., a change threshold, a delta value that indicates the differences between the data, a preference determined or configured by the network entity based on an SLA, etc.) to the AI / ML data to remove redundant or low-priority data at the LEE before transmission and ensure only meaningful data (e.g., data associated with model update, etc.) are transmitted by the UE.

[0124] According to example embodiments, the message may include an RRC message (e.g., RRC configuration / reconfiguration message, etc.) that includes one or more IES that indicate the configuration for aggregating the AI / ML data. For instance, the RRC message may include a first IE (“AI / ML_Aggregation_Config” or “AEML_Batching_Config” herein) that indicates a configuration of the batching process, a second IE (“AI / ML_Aggregation_Config” or “AEML PDCP Header Compression Config” herein) that indicates a configuration of the PDCP -based header compression process, a third IE (“AI / ML_Data_Filtering” herein) that indicates a configuration of the filtering process, and the like. According to example embodiments, the configuration of the filtering process may indicates which data attributes are the most relevant to an ongoing AI / ML operation (e.g., ongoing training process, ongoing inference operation, etc.), thereby instructing the UE to filter low-priority, redundant, outdated, and / or unnecessary data (e.g., redundant / correlated AI / ML model updates, etc.) before transmission and transmit only the relevant / high-priority data and reducing redundant uplink signaling.

[0125] At operation S520, the network entity may be configured to receive, from the UE, AI / ML data aggregated by the UE according to the configuration defined in the message (provided by the network entity at operation S510). According to example embodiments, the AI / ML data may be associated with an update of the AI / ML model. In this regard, the AI / ML data may be associated with an incremental model updates or metadata thereof, which contains minor changes between iterations (e.g., a huge portion of the AI / ML data may be similar to previously receivedAI / ML data). Thus, in some example embodiments, upon receiving the AT / ML data from the UE, the network entity may be configured to determine whether the received AI / ML data includes any redundant data (e.g., by comparing the checksum of the newly received AI / ML data with the checksum of the previously received AI / ML data, etc.). Accordingly, based on determining that the received AI / ML data includes redundant data, the network entity may send another message (e.g., another RRC message in addition to the message sent at operation S510, etc.) that includes the information that indicates the configuration for applying the data filtering process to the AI / ML data aggregated in the future, thereby avoiding the transmission of the redundant AI / ML data in future transmissions.

[0126] In view of the above, the method and operations described herein introduce and exemplify an a data aggregation optimization mechanism that may be implemented by a network entity (e.g., NG-RAN) to mitigate the transmission of redundant AI / ML data and optimizing uplink resource (e.g., bandwidth, etc.) consumption, thereby addressing the shortcomings of aspect (2) as described above.

[0127] Advantageously, by implementing the method and operations described herein, the network entity may instruct or guide the UE to aggregate the AI / ML data to suppress redundancy and streamline data delivery. For instance, the network entity may instruct the UE to batch model updates prior to transmission rather than sending them as frequent, individual reports. Furthermore, the network entity may instruct the UE to filter redundant data to ensure that only data associated with meaningful changes is transmitted. By utilizing network-defined filtering preferences or thresholds, the UE can evaluate the aggregated AI / ML data to detect and filter redundant AI / ML data. Accordingly, the UE may suppress the uplink transmission of redundant (or less meaningful) AI / ML data, effectively preventing the wastage of air interface resources on highly correlated orrepetitive AT / ML data that do not improve the UE-side AI / ML operations. Tn addition, the network entity may instruct the UE to perform header compression at the PDCP layer, thereby enabling the UE to selectively identify and remove redundant metadata from the AI / ML data before transmission and effectively reducing the size of the transmitted AI / ML data without loss of usefulness.

[0128] Ultimately, by implementing the method and operations described herein, the aggregation (e.g., collection, batching, compression, filtering, etc.) of the AI / ML data at the UE level may effectively and efficiently minimize signaling overhead and ensure that the uplink transmission consists of consolidated, bandwidth-efficient payloads, thereby transforming AI / ML data transmission into an efficient process that reduces unnecessary bandwidth consumption while maintaining the integrity and timeliness of critical AI / ML for UE-side AI / ML purposes.> > Example Methods and Operations associated with Aspect (3)

[0129] FIG. 6 illustrates an example method 600, according to one or more example embodiments. The operations in method 600 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 a transmission timing and synchronization of an AI / ML data transmission for UE-side AI / ML purposes.

[0130] As illustrated in FIG. 6, at operation S610, the network entity may be configured to receive multiple messages from multiple UEs, each of the messages may include a request for a time slot for transmission of AI / ML data (“AEML Sync Request” herein). In some example embodiments, the messages may be transmitted by the UEs when the AI / ML data is ready for transmission at the respective UEs. In this regard, the network entity may simultaneously receive the messages from all of the UEs, or may receive the messages from the UEs in a sequential manner(e g., receive a first message from a first UE before receiving a second message from a second UE, etc.).

[0131] According to example embodiments, the messages provided by UEs may include RRC messages. For instance, the RRC messages may include a combination of RRC Connection Setup Request messages, a combination of RRC Resume Request messages, a combination of at least one RRC Connection Setup Request message and at least one RRC Resume Request message, and the like. In this regard, the information associated with the request for the time slot for AI / ML data transmission (e.g., size of the AI / ML data, classification / priority level of the AI / ML data, etc.) may be included in or indicated by one or more IES of the respective RRC message.

[0132] Upon receiving the messages from the UEs, method 600 may proceed to operation S620, at which the network entity may be configured to assign time slots for one or more of the UEs. According to example embodiments, the network entity may execute a congestion-aware scheduling assessment based on the real-time (or near real-time) network conditions, thereby granting congestion-aware time slots (or time windows). For descriptive purposes, it is assumed that in the example of FIG. 6, the network entity may execute the congestion-aware scheduling assessment based on a network congestion level, and all of the UEs are being assigned with a respective time slot for performing an AI / ML data transmission. In actual implementations, the network entity may assign a time slot to a UE and request another UE to adjust the AI / ML data transmission (e.g., adjust the transmission rate, adjust the transmission timing, etc.), may request all of the UEs to adjust the AI / ML data transmissions, and the like, without departing from the scope of the present disclosure. The mechanisms and operations for the adjustment of the AI / ML data transmission may be similar to those described above with reference to FIG. 2 to FIG. 4.

[0133] According to example embodiments, at operation S620, the network entity may be configured to dynamically assign one or more time slots to the one or more UEs. For instance, the network entity may determine the congestion-aware time slots / time windows (“AI / ML_Transmission_Window” or “AI / ML_Transmission_Time_Slof ’ herein) according to the real-time (or near real-time) network conditions. Alternatively or additionally, the network entity may be configured to assign one or more predefined, congestion-aware time slots / time windows to the one or more UEs. In this regard, the one or more congestion-aware time slots / time windows may be predefined by, for example, a network policy, a QoS requirement, a Service Layer Agreement (SLA), and the like. Thus, the assignment or grant of the time slots / time windows may be constrained by network-defined congestion-aware time slots / time windows.

[0134] According to example embodiments, the network entity may be configured to identify, based on information included in the received messages (e.g., data volume, traffic class / priority, latency requirements, etc.), whether the current network conditions (e.g., current network congestion levels, etc.) allow for the simultaneous accommodation of the transmissions requested by all of the associated UEs. For instance, the network entity may compare the aggregate bandwidth demand indicated by the UEs against the currently available uplink radio resources (e.g., physical resource blocks, time slots, etc.), interference margins, and / or the like, to determine a current network load. Under favorable network conditions (e.g., the network load is low and network congestion does not occur, the available uplink resources exceed or satisfy the aggregate demand of the requesting UEs, etc.), the network entity may proceed to assign time slots for each of the plurality of UEs to simultaneously perform their respective data transmissions.

[0135] Conversely, under unfavorable network conditions (e.g., the network load is high and a network congestion has occurred, the available uplink resources are low or do not satisfy theaggregate demand of the requesting UEs, etc.), the network entity may determine that the network conditions do not allow all requesting UEs to perform the transmissions simultaneously. In this case, if the network entity determines that the network conditions do not allow any of the UEs to perform any of the requested transmissions, the network entity may determine an adjustment to the transmission for each of the UEs (e.g., instruct all UEs to delay / temporarily suspend the transmission, instruct a portion of the UEs to adjust the transmission rate and another portion of the UEs to adjust the transmission timing, etc.). On the other hand, if the network entity determines that the network conditions allow a portion of the UEs to perform the requested transmission, the network entity may perform a data transmission prioritization operation to appropriately assign the time slots for the associated UEs. The network entity evaluates the specific AI / ML metadata associated with each request to determine a priority level for the respective data transmissions. For example, the network entity may prioritize a first data transmission requested by a first UE (e.g., a transmission for high priority AVME data such as data for "Real-Time AEML Inference") over a second data transmission (e.g., a transmission for low priority AEML data such as data for "Background Model Training"), and the like. Based on this determination, the network entity may dynamically allocate the available time slots to the UE(s) associated with the higher-priority transmission, and then instruct the remaining UE(s) to appropriately adjust the data transmission (e g., adjust transmission rate, transmission timing, etc.).

[0136] Assuming that the network conditions are favorable (i.e., the data transmissions requested by all UEs are feasible) and the network entity has appropriately assigned a time slot for each of the UEs for performing the respective data transmission, method 600 may proceed to operation S630, at which the network entity may be configured to transmit, to each of the UEs, a respective message that includes information associated with the assignment time slot. For instance,the network entity may transmit an RRC message that includes one or more IES that indicate the assigned time slot.

[0137] In view of the above, the method and operations described herein introduce and exemplify a data transmission timing optimization mechanism that may be implemented by a network entity (e.g., NG-RAN) to optimize the scheduling operation for multiple data transmissions and ensure the data transmissions requested by multiple UEs may be synchronized and aligned with the real-time (or near real-time) network conditions, thereby addressing the shortcomings of aspect (3) as described above.

[0138] Advantageously, by implementing the method and operations described herein, multiple UEs may be enabled to request the network entity for uplink resources (e g., time slot, etc.) for data transmission before actually sending the AI / ML to the data, and the network entity may control the precise timing of the data transmission, efficiently and effectively preventing unregulated and asynchronous data transmissions from multiple UEs. For instance, the network entity may provide adaptive, network condition-aware (e.g., congestion-aware) transmission scheduling for the AI / ML data transmissions, where the network entity may dynamically assign or adjust specific time slot(s) for AI / ML data transmissions according to one or more real-time (or near real-time) network conditions (e.g., network congestion, etc.), thereby ensuring that the AI / ML data transmissions are coordinated across the UEs, minimizing interference of the AI / ML data transmission with non-AI / ML traffics, and maximizing the efficiency of available uplink resources.> > Example Methods and Operations associated with Aspect (4)

[0139] 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., networkentity 110) to communicate with a UE (e.g., UE 120) to provide AT / ML data differentiation for user plane (UP) traffic prioritization.

[0140] As illustrated in FIG. 7, at operation S710, the network entity may be configured to receive, from the UE, a message that includes a parameter indicating a type of network traffic associated with AI / ML data (“AI / ML traffic” herein). For instance, the parameter (“AI / ML_Traffic_Type_Indicator” herein) may include a flag, a string indicator, or any suitable type of parameter that specifies whether the AI / ML data is associated with an AI / ML inference operation or an AI / ML model training. In some example embodiments, the type of the network traffic may represent different AI / ML workloads with different priority needs, different urgencies, and / or different impacts. According to example embodiments, the message may further include a request for an uplink resource (e.g., a time slot, etc.) for the transmission of the AI / ML data, as described above with reference to the example use cases in FIG. 2 and FIG. 6.

[0141] According to example embodiments, prior to receiving the message from the UE, the network entity may be configured to communicate with the UE to implement Service Data Adaptation Protocol (SDAP) layer enhancements. For instance, the network entity may define or manage one or more classification rules (e.g., which QoS class an AI / ML data belongs to, etc.), and provide the one or more classification rules to the UE. By way of non-limiting examples, the classification rule may instruct the UE to mark “Inference Data” with a first QoS Flow ID (QFI) and mark “Training Data” with a second QFI. Upon receiving the classification rule(s) from the network entity, whenever the UE collects / generates data packets associated with the AI / ML data (including the message provided to the network entity at operation S710), the UE may determine an associated class of the AI / ML data based on the classification rule(s) and then include the associated information into the data packets. In some example implementations, the UE’s SDAPlayer may insert the QFI associated with the AT / ML data into the SDAP header of the data packet, before transmitting the data packet to the network entity. In this way, the AI / ML data may be assigned with the associated SDAP QoS class according to the network-controlled classification rules, thereby enabling the network entity to efficiently differentiate the AI / ML data and provide differentiated handling without modifying UP headers.

[0142] Referring still to FIG. 7, upon receiving the message from the UE, method 700 may proceed to operation S720, at which the network entity may be configured to reassign a priority level to the AI / ML traffic. For instance, the network entity may evaluate one or more network conditions (e.g., network congestion, resource availability, potential issues, presence of high priority traffics, etc.), determine a default priority level associated with the AI / ML traffic based on the information of the type of the AI / ML traffic (e.g., QoS class, QFI, etc.), and then determine whether the default priority level associated with the AI / ML traffic (which may be pre-assigned to the AI / ML traffic) is optimal or requires an adjustment. Based on determining that the default priority level associated with the AI / ML traffic is optimal, the network entity may allocate the uplink resources for the AI / ML traffic according to the default priority level. On the other hand, based on determining that an adjustment to the default priority level is required, the network entity may determine an optimal priority level (e.g., increase the priority level to optimize the transmission of the AI / ML data, reduce the priority level to avoid negatively impacting other high priority traffic, etc.).

[0143] For instance, assuming that the AI / ML traffic is associated with the transmission of model training data, the AI / ML traffic may be pre-assigned with a high priority level during a previous transmission since there was no high priority traffic (e.g., VoNR, etc.) during the previous transmission. As another example, the AI / ML traffic may be pre-assigned with a high priority levelduring the previous AI / ML data transmission since there was no high priority AI / ML traffic (e.g., no transmission of inference data). In both of the example scenarios, the AI / ML traffic may need to be reassigned with a low priority level in the next AI / ML data transmission, since a high priority traffic (e.g., non-AI / ML traffic such as VoNR, AI / ML traffic such as transmission of inference data, etc.) is existing and the pre-assigned priority level of the AI / ML traffic for the transmission of model training may cause network congestions and impact the high priority traffic.

[0144] In the example use case of FIG. 7, it may be assumed that, at operation S710, the network entity determines that an adjustment to the priority level of the AI / ML traffic is required and subsequently reassigns a new, optimal priority level to the AI / ML traffic based on one or more real-time (or near real-time) conditions (e.g., network conditions such as network congestion, AI / ML-related requirements such as the data required for the ongoing AI / ML-operations, etc.).

[0145] Accordingly, at operation S730, the network entity may be configured to transmit the reassigned AI / ML traffic priority level (“Al / ML_Traffic_Priority_Update” herein) to the UE. For instance, the network entity may include the reassigned AI / ML traffic priority level into an IE of an RRC message when transmitting the RRC message to the UE for the allocation of uplink resource (similar to those described above with reference to at least FIG. 2 and FIG. 6). This message may instructs the UE to modify the QoS handling for the specific AI / ML traffic. For instance, this message may include configuration parameters that redefine the classification rules, such as associating the AI / ML traffic with a different QFI, and the like. According to example embodiments, the message may also guide the UE in applying prioritized handling in the UP according to the reassigned priority level. For instance, the message may instruct or guide the UE to reconfigure the associated SDAP layer with the new classification rules, such that the SDAP layer may apply AI / ML-aware traffic scheduling (e.g., by including an updated QFI according tothe reassigned priority level, etc.) into the SDAP header of the associated data packets. By way of a non-limiting example, if the message instructs the UE to prioritize AI / ML data for model training purposes, the UE may implement the SDAP layer to map the associated AI / ML data to a high priority Data Radio Bearer (DRB). Conversely, if the message instructs the UE to deprioritize the AI / ML data for model training, the UE may implement the SDAP layer to map the associated AI / ML data to a lower priority (or a best effort) DRB. This SDAP layer enhancement may ensure that the underlying Medium Access Control (MAC) scheduler may manage the AI / ML data according to the dynamically network-assigned priority, thereby ensuring that the transmission of the AI / ML data may be prioritized according to the real-time / near real-time conditions or requirements (e.g., transmission of AI / ML data for inference updates may be prioritized over transmission of AI / ML data forbackground model training, etc.).

[0146] In view of the above, the method and operations described herein introduce and exemplify an AI / ML traffic differentiation mechanism that may be implemented by a network entity (e g., NG-RAN) to optimize the User Plane traffic prioritization and enhance the handling of AI / ML data, thereby addressing the shortcomings of aspect (4) as described above.

[0147] Advantageously, by implementing the method and operations described herein, the network entity may efficiently and dynamically differentiate different types of network traffics (e g., differentiate AI / ML traffic from other User Plane traffic (e.g., AI / ML-related traffic vs non-AI / ML traffic, etc.), differentiate different type of AI / ML traffics (e.g., inference data traffic vs model training data traffic, etc.), or the like), thereby effectively prioritizing the network traffics according to the real-time (or near real-time) conditions and requirements and preventing QoS conflicts among different type of network traffics.

[0148] Further, the network entity may dynamically reassign and reclassify AI / ML traffic priority in real-time (or near real-time) based on fluctuating network conditions. This adaptability ensures that AI / ML data is always assigned priority levels that align with current network loads and data utilization requirements. For instance, the network entity can enforce policies where background AI / ML traffic is deprioritized when needed (e.g., during periods of network congestion or other critical events, etc.), while retaining the flexibility to upgrade priority levels when resources become available. This dynamic adjustment mechanism ensures optimal network stability while meeting the diverse performance requirements of AI / ML workloads. For instance, under low network load scenario, the network entity may implement the method and operations described herein to prioritize the AI / ML traffic that has a higher latency requirement (e.g., prioritize transmission of time-critical inference data over bandwidth-intensive model training data, etc.), thereby optimizing the AI / ML-related operations (e.g., AI / ML model inference, etc.), maintaining the responsiveness required for adaptive network optimizations, and ensuring that the QoS mechanisms implemented for managing non-AI / ML traffic unnecessarily deprioritize the AI / ML traffic. As another non-limiting example, under a high network load (e.g., network congestion, etc.) scenario, the network entity may implement the method and operations described herein to prioritize more critical non-AI / ML traffic (e.g., GBR traffic like VoNR), thereby ensuring that the QoS of the non-AI / ML-related operations is not degraded due to AI / ML traffic.> > Example Methods and Operations associated with Aspect (5)

[0149] FIG. 8 illustrates an example method 800, according to one or more example embodiments. The operations in method 800 may be performed by a network entity (e.g., network entity 110) to communicate with a UE (e.g., UE 120) to manage and control data collections at the UE.

[0150] As illustrated in FIG. 8, at operation S810, the network entity may be configured to transmit a message that includes a configuration for collecting AI / ML data (“AI / ML data collection configuration” herein) to the UE. Specifically, the message may include one or more AI / ML-related measurement control parameters that regulate and control the AI / ML data collection at the UE (e.g., when the UE may collect a specific type of AI / ML data, how frequently the UE may collect the specific type of AI / ML data, how much data the UE may collect during each data collection session, etc.). As further described below, in some example embodiments, the contents of the message may contain a policy and the provisioning of the message may function as the initiation of a policy enforcement operation rather than a direct scheduling operation.

[0151] According to example embodiments, the message may include an RRC message (e g., RRC configuration / reconfiguration message described herein with reference to other example embodiments), and the configuration for collecting the AI / ML data may be included in one or more lEs of the RRC message. It is contemplated that the message (e g., RRC message, etc.) may (but not necessarily) further include other suitable information (e.g., configuration for adjusting AI / ML data transmission, information of assigned uplink resources, etc.) described herein with reference to other example embodiments, without departing from the scope of the present disclosure.

[0152] According to example embodiments, the data collection configuration includes one or more of: (a) a data collection rule / policy, and (b) an instruction / guidance to implement a hybrid data collection mechanism.

[0153] The data collection rule / policy may define one or more conditions or constraints that regulate when and how the UE is permitted to collect the associated AI / ML data. For instance, the data collection rule / policy may include one or more of: a triggering event that initiates the datacollection session (e.g., “start data collection session when a radio condition is above threshold X”, “start data collection session upon detection a beam transition with a pattern Z”, etc.), a data collection frequency that indicates how frequently the UE may collect the associated data (e.g., “collect the data every N milliseconds”, etc.), a network-defined constraint that prohibit the initiation of the data collection session and / or terminate the data collection session (e.g., “terminate data collection session if uplink interference exceed threshold Y”, “do not perform data collection during active VoNR session”, etc.).

[0154] According to example embodiment, the data collection rule / policy may be defined by the network entity based on high-level requirements provided by higher-layer network functions (e.g., CoreNetwork (CN), an Operation, Administration, and Maintenance (0AM) entity, etc.). For instance, the higher-layer network functions (e.g., CN, 0AM, etc.) may determine the high-level requirements (e.g., “model training data associated with AI / ML model Z is required for the next 4 hours”, etc.), and the network entity may translate the high-level requirements into network constraints of the data collection rule / policy (e.g., “initiate the collection of model training data associated with AI / ML model Z for the next 4 hours, when condition X is satisfied”, etc.). In this way, the network entity may act as a policy enforcer rather than a scheduler, since the network entity may simply define the data collection rule / policy and offload the scheduling operation to the higher-level scheduling requirements (e.g., CN, 0AM, etc.).

[0155] On the other hand, the instruction / guidance to implement the hybrid data collection mechanism may instruct or guide the UE to operate under a hybrid data collection mode. Specifically, in the hybrid collection data collection mode, the UE is allowed to adjust the data collection configuration (e.g., data collection timing, data collection frequency, data collection time window, etc.) within the network-defined rules or constraints. For instance, instead ofrequiring a communication with the network (e.g., via a handshaking operation, etc.) for every data collection session (which may cause excessive signaling and is undesirable particularly under network congestion scenarios), the UE may evaluate the rules or constrains defined in the message provided by the network entity, and may automatically adjust the data collection configuration (e.g., downscale the data collection process, pause / delay the data collection session, etc.) without requiring explicit reconfiguration from the network entity. This hybrid data collection mechanism may enable the network entity to act as a policy enforcer to enforce high-level policies, while shifting the load of granular, real-time / near real-time decision making to the UE, thereby balancing network control with device flexibility.

[0156] Referring still to FIG. 8, at operation S820, the network entity may be configured to receive, from the UE, AI / ML data collected according to the AI / ML data collection configuration included in the message (provided by the network entity to the UE at operation S810). Specifically, upon receiving the AI / ML data collection configuration from the network entity, the UE may monitor the real-time (or near real-time) conditions (e.g., network / radio conditions, etc.), and then initiate the data collection session for collecting the AI / ML data according to the condition(s) or constraint(s) defined by the AI / ML data collection configuration (e.g., the data collection rule / policy, etc ). In some example embodiments, the UE may dynamically adjust the configuration for collecting the AI / ML data (e.g., collection timing, etc.) within the network-defined data collection rule / policy (e.g., adjust the data collection timing when the battery level of the UE is low, pause the data collection when the UE is performing VoNR operation, etc.). Accordingly, the UE may transmit the collected AI / ML data to the network entity. In this regard, the UE may implement one or more example embodiments associated with data transmission management as described herein (e.g., sending a request for uplink resource for AI / ML datatransmission, batch / compress / filter / tag the collected AI / ML data, including the collected data in a measurement report, etc.) to transmit the collected AI / ML data to the network entity. Since the data collection operation was regulated by the network-defined policy / rule, the likelihood of the UE transmitting the collected AI / ML data (as well as the associated request message) during a network congestion may be effectively reduced, as the data collection operation itself would have been minimized (if not avoided).

[0157] In view of the above, the method and operations described herein introduce and exemplify an AI / ML data collection management mechanism that may be implemented by a network entity (e.g., NG-RAN) to effectively and efficiently control, configure, and regulate AI / ML data collection at the UE, thereby addressing the shortcomings of aspect (5) as described above.

[0158] Advantageously, by implementing the method and operations described herein, the network entity may proactively manage network resources by controlling the collection and generation of AI / ML data at the source (the UE) rather than merely managing its subsequent transmission. Accordingly, the network entity may effectively and efficiently reduce potential network congestion risks by dynamically managing the amount of data collected at the UE (and therefore the amount of data transmitted by the UE) according to one or more real-time (or near real-time) conditions, thereby preventing the network congestion before it occurs. For instance, the network entity may dynamically regulate when and how frequently the UE may initiate the AI / ML data collection, thereby avoiding excessive AI / ML data collection at the UE when the network load is high, effectively preventing the accumulation of bulky data buffered at the UE and reducing the subsequent burden on uplink scheduling and data transmission procedures.

[0159] Additionally, by implementing the method and operations described herein, the network entity may act as a policy enforcer rather than a scheduler. By checking high-level requirements provided by higher-layer functions (e.g., CN, 0AM, etc.) against real-time (or near real-time) network conditions, the network entity may determine optimal configuration for collecting the AI / ML data, thereby translating the high-level data collection requirements provided by the higher-layer functions into concrete data collection rules / policies, without requiring the network entity to incur additional data collection scheduling. Furthermore, the network entity may also guide the UE to collect the AI / ML data in an optimal manner. For instance, by implementing the hybrid control mechanism of example embodiments, the network may define data collection rules / policies while permitting the UE to autonomously adjust the specific data collection configuration (e.g., timing, frequency, etc.), thereby optimizing the resources at both the UE side and the network side. For instance, the UE may effectively avoid resources (e.g., power consumption, computing power, etc.) on collecting and processing data that cannot be successfully and timely transmitted to the network entity, while the network entity may effectively reduce control-plane signaling overhead (particularly in high-density networks where micromanaging the data collection configurations of a significant number of UEs is not feasible).Example Methods and Operations associated with Aspect (6)

[0160] FIG. 9 illustrates an example method 900, according to one or more example embodiments. The operations in method 900 may be performed by a network entity (e.g., network entity 110) to communicate with a UE (e.g., UE 120) to provide network visibility on the AI / ML data transmission.

[0161] As illustrated in FIG. 9, at operation S910, the network entity may be configured to transmit, to the UE, a message that includes a configuration for marking an AI / ML traffic.According to example embodiments, the message may include a tagging rule that instructs the UE to appropriately tag the AI / ML traffic. For instance, the tagging rule may indicate how specifically the UE may tag a specific type of AI / ML data (e.g., “Data generated by application X shall be tagged as ‘AI / ML Inference Data’”, “Data collected via operation Y shall be tagged as ‘AI / ML Model Training Data’”, etc.), the type of identifier that the UE may utilize for tagging the AI / ML data (e.g., “AI / ML Inference Data”, “AI / ML Training Data”, “GBR Data”, “Non-GBR Data”, etc.), and the like. In addition to the tagging rule, the message may also include any other suitable information, such as the data aggregation configuration (e.g., described above with reference to FIG. 5), the data collection configuration (described above with reference to FIG. 8), and the like.

[0162] According to example embodiments, the message may include an instruction or guidance that may configure the UE to implement an SDAP layer enhancement (e.g., instructing the UE to tag or mark AI / ML data with the associated identifier at the SDAP header, etc.), in a similar manner as described above with reference to method 700. Further, the message may include one or more policies defined by the network entity (e.g., based on high-level requirements provided by high-layer functions like CN or 0AM, etc.). In this regard, the one or more policies may guide or instruct the UE to tag or mark the AI / ML data with an associated QoS parameter (e.g., QFI, etc.).

[0163] Referring still to FIG. 9, at operation S920, the network entity may be configured to receive, from the UE, a message that includes AI / ML data collected / aggregated by the UE and an identifier (“AI / ML_Traffic_Identifier” herein) associated with the type of the AI / ML traffic for transmitting the AI / ML data. The identifier may be similar to the parameter indicating the type of AI / ML traffic as described above with reference to method 700. For instance, the identifier may include a flag, a string indicator, or any suitable type of parameter that specifies whether the AI / MLdata is associated with an AT / ML inference operation or an AI / ML model training. The identifier may be included by the UE in the SDAP header of the message (or the AI / ML data therein), according to the tagging rule provided by the network entity (at operation S910). In addition, similar to the message received by the network entity at operation S710 in method 700, the message received by the network entity at operation S910 may further include a request for an uplink resource (e.g., a time slot, etc.) for the transmission of the AI / ML data, as described above with reference to the example use cases in FIG. 2 and FIG. 6.

[0164] Accordingly, at step S930, the network entity may be configured to apply one or more adaptive scheduling policies. For instance, the network entity may determine the type of the AI / ML traffic based on the identifier associated therewith (which is included in the message provided by the UE at operation S920), evaluate the real-time / near real-time network condition(s), and appropriately configure the scheduling of the subsequent AI / ML data transmission based on the type of the AI / ML traffic, the network condition(s), and the scheduling policy(s). By way of a non-limiting example, based on determining that the AI / ML traffic is a low priority traffic (e.g., the AI / ML data is tagged as “AI / ML Model Training Data”, etc.) and a network congestion has occurred and exceeded a threshold defined in a scheduling policy, the network entity may provide a message to the UE to implement an adjustment (“AI / ML_Traffic_Adjustment” herein) to the subsequent transmission of AI / ML data (e.g., reduce transmission rate, delay / temporarily suspend transmission of AI / ML data, etc.), thereby dynamically adjusting the priority of AI / ML data transmission and avoiding the AI / ML data transmission from negatively impacting the network performance (e.g., increasing the network congestion, degrading high priority traffic that has low latency requirements, etc.).

[0165] FIG. 10 illustrates an example method 1000, according to one or more example embodiments. The operations in method 1000 may be performed by a network entity (e.g., network entity 110) to communicate with a UE (e.g., UE 120) that may update the network entity regarding an upload progress of AI / ML data. One or more operations in method 100 may be implemented by the network entity, along with one or more operations of other methods described herein, to further optimize scheduling of the AI / ML data transmission.

[0166] As illustrated in FIG. 10, at operation S 1010, the network entity may be configured to receive, from the UE, a report message (“AI / ML_Transfer_Status_Report” herein) that indicates a status of an AI / ML data transmission. The status report may include an MDT report, an RRC-based status report, such as a measurement report, a UE capability information report, a connection status report, or any other suitable type of message. According to example embodiments, the UE may periodically provide the report message to the network entity, and / or may provide the report message to the network entity upon detecting that the size of the AI / ML data exceeds a pre-defined threshold (which indicates that the size of the AI / ML data is huge and the transmission of such data may consume a significant number of uplink resources), before the AI / ML data is ready for transmission (e.g., the collection of the AI / ML data is still in progress, the UE is still processing the collected AI / ML data, etc.). In this regard, the report message may include information of the AI / ML data, such as the total volume of the AI / ML data, the priority / classification of the AI / ML data, the expected duration for transmitting the data, and the like.

[0167] At operation SI 020, the network entity may be configured to evaluate the report message and pre-allocate uplink scheduling resources for the AI / ML traffic. For instance, by evaluating the total volume of data and the expected duration for transmitting the data (provided in the report message), the network entity may predict the uplink resources required for thetransmission of the AI / ML data and pre-allocate uplink resources or adjusts its scheduling algorithm to accommodate the incoming AI / ML data, before the AI / ML data transmission is actually requested and performed by the UE. In some example embodiments, the network entity may dynamically adjust the scheduling policies to control the priority of the AI / ML data transmission based on real-time / near real-time network condition(s) or AI / ML operational requirements (e.g., if the AI / ML data is a high priority AI / ML data but a network congestion has occurred and a GBR traffic is existing, the network entity may deprioritize the transmission of the high priority AI / ML data to avoid the AI / ML traffic from interfering the GBR traffic, etc.), thereby reducing the impact of the AI / ML data transmission on other uplink traffic while ensuring that latency-sensitive AI / ML can be timely transmitted.

[0168] Subsequently, at operation S1030, the network entity may provide, to the UE, a message (e.g., RRC message, etc.) that includes information of the pre-allocated uplink resources. Upon receiving the message from the network entity, the UE may utilize the pre-allocated uplink resources to perform the AI / ML data transmission once the AI / ML data is ready for transmission (e.g., the collection of the AI / ML data is completed, the processing / batching / compressing / filtering of the AI / ML data is completed, etc.). In this regard, if the pre-allocated uplink resources are sufficient, the UE may perform the AI / ML data transmission without requiring further signaling with the network entity. Conversely, if the pre-allocated uplink resources are insufficient and additional uplink resources are required, the UE may send a message (e.g., RRC message) (“AI / ML_Uplink_Resource_Requesf ’ herein) to request additional uplink resources or extended uplink capacity. The process of the UE requesting additional uplink resources may be similar to the operation S210, S610, and the like, described above with other Figures.

[0169] In view of the above, the methods and operations described herein introduce and exemplify an AI / ML data transmission management mechanism that may provide visibility of the AI / ML data transmission to the network entity, enabling the network entity to proactively enforce policies, manage congestion, and apply priority-based traffic handling, thereby addressing the shortcomings of aspect (6) as described above. Specifically, by enabling the UE to perform the status reporting before performing the transmission of the AI / ML data, the network entity may optimize the scheduling (e.g., by performing proactive scheduling) based on AI / ML data preparation and upload progress

[0170] Further, the methods and operations described exemplify how the network entity may instruct and guide the UE in performing metadata tagging on AI / ML traffic at the SDAP level. Advantageously, by implementing the method and operations described herein, the network entity may effectively and efficiently instruct or guide the UE to perform AI / ML metadata tagging at the SDAP layer, thereby allowing the network entity to effectively and efficiently identify and differentiate AI / ML traffic from generic UP traffic by processing only the header information, without modifying UP data packet handling or requiring deep packet inspection. Accordingly, the network entity may dynamically apply differentiated scheduling rules and congestion-aware traffic management for AI / ML workloads with minimal processing resources and latency.

[0171] Furthermore, the methods and operations described herein also exemplify an AI / ML data transmission status reporting mechanism, where the UE is enabled to update (e.g., periodically, upon detecting a specific event, etc.) the network entity on the AI / ML data upload / preparation progress to optimize uplink resource scheduling. Specifically, by receiving the AI / ML data transmission status report from the UE before the AI / ML data is ready for transmission, the network entity may predict or anticipate the uplink resources required for accommodating theAI / ML traffic, and then perform uplink resource pre-allocation and / or proactively adjust one or more scheduling policies according to one or more real-time / near real-time conditions (e.g., network congestion, AI / ML data requirements, etc.). In this way, the network entity may ensure that large-scale AI / ML data bursts are managed smoothly without disrupting parallel, latencysensitive services (if any).

[0172] In addition, the methods and operations described herein also exemplify a mechanism that enables the UE to request network assistance in the scheduling of AI / ML data transmissions. For instance, after receiving the uplink scheduling resources pre-allocated by the network entity (based on the information in the UE-provided status report), if the UE determines that the pre-allocated uplink resources are not sufficient (e.g., the actual AI / ML data is larger than predicted, etc.) and additional uplink resources are required, the UE may transmit an explicit request to the network entity to request for extended uplink capacity or additional uplink resources. In this way, the uplink scheduling operation may be transformed from a reactive procedure (e.g., based solely on instantaneous AI / ML data pending in the local buffer of the UE) to a proactive procedure, effectively reducing the amount of signaling overhead for uplink resource request (when the pre-allocated uplink resources are sufficient) while ensuring that the UE may be allocated with sufficient uplink resources (when the pre-allocated uplink resources are insufficient) for successfully transmitting the AI / ML data.> > Example Methods and Operations associated with Aspect (7)

[0173] FIG. 11 illustrates an example method 1100, according to one or more example embodiments. The operations in method 1100 may be performed by a network entity (e.g., network entity 110) to communicate with one or more network entities (e.g., CN, 0AM, UPF, etc.) and optimize the AI / ML data transmission thereto. Thus, it may be assumed that one or moreoperations in FIG. 11 may be implemented or initiated by the network entity after receiving the AI / ML data from a UE (e.g., UE 120).

[0174] As illustrated in FIG. 11, at operation SI 110, the network entity may be configured to process the AI / ML data (received from one or more UEs prior to operation SI 110). According to example embodiments, the network entity may determine a type of the AI / ML data (e.g., based on a tag included in the metadata of the AI / ML data, etc.), determine a target network entity (e.g., CN, UPF, 0AM, etc.) to which the AI / ML data will be transferred, and then include one or more parameters that indicates a classification of the AI / ML traffic associated with the AI / ML data (e.g., “AI / ML traffic classification parameter” herein). According to example embodiments, the network entity may modify or encapsulate the AI / ML data with a network-side classification parameter, such as a QFI value, and the like. For instance, based on determining that the target network entity is the CN or an associated network function (e.g., UPF, etc.), the network entity may insert the AI / ML traffic classification parameter as an extension to the GPRS Tunneling Protocol-User Plane (GTP-U) header.

[0175] In addition to or in alternative to the AI / ML traffic classification parameter, at operation SI 110, the network entity may also include a parameter that indicates the formatting of the AI / ML data (“AI / ML data formatting indicator” herein) to the AI / ML data. The AI / ML data formatting indicator may indicate the information (e.g., internal data structure) of the AI / ML data (e.g., a specific tensor shape, a binary quantization level, a serialization protocol, etc.). Further, the AI / ML data formatting indicator may function as a protocol -level compatibility parameter that may be standardized and mutually readable between the network entity and the target network entity (e.g., CN, UPF, 0AM, etc.). For instance, upon determining the target network entity, the network entity may select a specific formatting indicator structures / templates from a set ofindicator structures / templates that are compatible with the functionalities or processing pipelines of the target network entity, generate the AI / ML data formatting indicator according to the selected indicator structures / templates, and then include the generated AI / ML data formatting indicator to the AI / ML data.

[0176] It is contemplated that, at operation SI 110, the network entity may also be configured to perform any other suitable operations to process the AI / ML data, before transferring the AI / ML data to the target network entity. For instance, the network entity may remove one or more metadata of the AI / ML data (e.g., to reduce the AI / ML payload, to remove privacy-sensitive data, etc.), aggregate or compile multiple AI / ML data into an AI / ML dataset, perform lightweight edge processing on the AI / ML data to obtain a pre-calculated / inferenced result, and the like, without departing from the scope of the present disclosure.

[0177] Referring still to FIG. 11, upon processing the AI / ML data, method 1100 may proceed to operation SI 120, at which the network entity may be configured to determine a configuration for routing or transferring the processed AI / ML data (“data routing configuration” herein) to the target network entity (e.g., CN, UPF, 0AM, etc.). In this operation, the network entity may function as a data router that dynamically and adaptively determines an optimal transport path for transferring the AI / ML data to the target network entity. For instance, the network entity may evaluate one or more real-time / near real-time conditions (e.g., network load, processing resource availability, etc.) and select a transport path (e.g., a specific GTP-U Tunnel, etc.) based thereon. Subsequently, at operation SI 130, the network entity may be configured to transfer the AI / ML data to the target network entity according to the data routing configuration.

[0178] According to example embodiments, the network entity may be configured to implement an adaptive AI / ML routing mechanism, thereby enabling real-time / near real-timeadjustment of AI / ML data flows based on one or more real-time / near real-time conditions. For instance, the network entity may dynamically adjust the flow of AI / ML data in response to a network event (e.g., a network congestion, etc.), a AI / ML-operation requirement (e.g., AI / ML data is required to reach the target network entity within X milliseconds for the implementation of AI / ML inference, etc.), a processing resource availability, and the like. Assuming that the target network entity is the CN and the default transport path is a standard User Plane path, based on determining that the backhaul link (that communicatively coupling the network entity to the CN) is uncongested and the target network entity has sufficient processing availability, the network entity may select the default transport path for transferring the AI / ML data to the target network entity. On the other hand, if the network entity detects a network congestion on the default path / backhaul link, the network entity may perform a path switch operation to redirect the AI / ML data to the target network entity via an alternative transport path. As another non-limiting example, if the network entity detects a processing resource limitation at the target network entity, the network entity may determine an alternative target network entity to which the AI / ML data may be transferred, determine a transport path for transferring the AI / ML data to the alternative target network entity, and transfer the AI / ML data to the alternative target network entity via the transport path.

[0179] In view of the above, the methods and operations described herein introduce and exemplify an AI / ML data transfer management mechanism that enables the network entity to handle the AI / ML traffic classification procedure, thereby addressing the shortcomings of aspect (7) as described above.

[0180] Advantageously, by implementing the method and operations described herein, the network entity may appropriately classify the AI / ML data before transferring the AI / ML data tothe high-layer target network entity (e.g., CN, UPF, OAM). For instance, the network entity may classify the AI / ML data based on the associated urgency / priority level, processing availability of the target network entity, real-time / near real-time network conditions, impact of the transmission of the AI / ML data on other network operations, and the like. Further, the network entity may include one or more standardized AI / ML data formatting indicators in the AI / ML data, thereby ensuring that the target network entity may efficiently parse and process the AI / ML data without unnecessary conversions or delays. Furthermore, the network entity may implement an adaptive AI / ML routing mechanism, thereby enabling real-time / near real-time adjustment of AI / ML data flows and dynamic rerouting of the AI / ML data based on one or more real-time / near real-time conditions (e g., network congestion, processing resource availability, etc.).>> Summary

[0181] In view of the above, FIG. 2 to FIG. 11 illustrate various example methods and operations that may be implemented to address the shortcomings of the above-described aspects (1 )-(7), thereby enabling effective and efficient UE-side AI / ML data management, particularly on the collection and transmission of the associated AI / ML data.

[0182] It is contemplated that the methods, operations, advantages, and significances described above with reference to FIG. 2 to FIG. 11 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. 11 may be performed differently, less or additional operations may be involved, the messages or commands involved therein may include less or additional parameters, additional 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 additionalparameters, attributes, and mechanisms supplemented thereto (when required). Further, multiple methods and operations in FIG. 2 to FIG. 11 may be performed in combination with each other, without departing from the scope of the present disclosure.Examples of Device

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

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

[0185] FIG. 12 illustrates an embodiment of a device 1200. As shown in FIG. 12, the device 1200 may include a processor 1210, a memory 1220, a storage component 1230, an input component 1240, an output component 1250, a communication interface 1260, and a bus 1270.

[0186] The processor 1210, as used herein, means any type of computational circuit that may comprise hardware elements and software elements. The processor 1210 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 1210 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.

[0187] Memory 1220 includes a non-transitory computer readable medium. Memory 1220 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 1210. The memory 1220 comprises machine-readable instructions which are executable by the processor 1210. These machine-readable instructions when executed by the processor 1210 cause the processor 1210 to perform one or more method steps of an embodiment described above.

[0188] Storage component 1230 stores information and / or software related to the operation and use of the device 1200. For example, storage component 1230 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.

[0189] Input component 1240 is configured to receive information, such as user input. For example, the input component 1240 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, or alternatively, the input component 1240 may include a sensor for sensing information (e.g., a global positioning system (GPS), an accelerometer, a gyroscope, and / or an actuator).

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

[0191] Communication interface 1260 is an interface that provides a communication connection to other devices, such as external devices and internal devices. The connection by the communication interface 1260 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 1200 and other devices. In other words, the standard of the communication interface 1260 is not limited.

[0192] The bus 1270 acts as an interconnect between the processor 1210, the memory 1220, the storage component 1230, the input component 1240, the output component 1250, and the communication interface 1260 of the device 1200. The bus 1270 may include a wired interconnection or a wireless interconnection.

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

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

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

[0196] The UE 1310 is connected to the network 1330, and the network 1330 is connected to the service environment 1320. The connections may be wired, wireless, or a combination of both wired and wireless. The UE 1310 and the service environment 1320 are connected via the network 1330.

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

[0198] The example FIG. 13 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.”

[0199] For example, the UE 1310 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.

[0200] The service environment 1320 is an environment that communicates with the UE 1310 to provide one or more services. The service environment 1320 receives information fromthe UE 1310 and / or sends information to the UE 1310. Also, the service environment 1320 may generate and / or store information to be transmitted, as necessary. Also, the service environment 1320 may store and / or process information that is received, as necessary. For example, the service environment 1320 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.

[0201] The example FIG. 13 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."

[0202] The one or more services provided by the service environment 1320 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 1310, a service that stores information from the UE 1310, or a service that performs processing based on information from the UE 1310 and returns the results of the processing.

[0203] In an embodiment, the Service Environments 1320 may also provide computing resources as the service. The computing resources can be hardware resources and / or softwareresources. 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.

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

[0205] The service environment 1320 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 1320 can be determined as appropriate. Additionally, if the service environment 1320 includes one or more sub-environments 1321, the placement of devices can be determined based on predetermined policies for each sub-environment 1321. For example, devices related to the first service may be placed in the 1st sub -environment 1321-1, and devices related to the second service may be placed in the 2nd sub-environment 1321-2. In another example, devices expected to have a higher load than a predetermined threshold may be placed in the 1stsub-environment 1321-1, while devices expected to have a lower load than the predetermined threshold may be placed in the 2nd sub-environment 1321-2. In this way, specific devices can be placed in specific sub-environments 1321. Conversely, each sub-environment 1321 can be specialized for a particular purpose.

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

[0207] The network 1330 is a network that exchanges information between the UE 1310 and the service environment 1320. The network 1330 includes one or more wired and / or wireless networks.

[0208] For example, the network 1330 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, an ad 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.

[0209] The network 1330 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 1330 can be at least one of the RAN, the transport network, or the core network. For example, the service environment 1320 could be in the core network, in which case the network 1330 could correspond to a network that is a combination of a RAN and a transport network and is part of the 5G network.

[0210] In this regard, the UE 1310 in FIG.13 may be similar to the UE 120 in FIG. 1, while the network entity 110 in FIG. 1 may be implemented in the network 1330. Further, the AI / ML-related operations described herein (e.g., AI / ML model training, AI / ML inference, etc.) may be implemented in the service environment 1320.

[0211] The number and arrangement of devices and networks shown in FIG. 13 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

[0212] 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 the example embodiments of the present disclosure during the 3GPP TSG-RAN WG2 Meeting #129:

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

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

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

[0216] 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-transitorystorage medium (or media) having computer-readable program instructions thereon for causing a processor to carry out operations.

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

[0218] 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 each computing / 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.

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

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

[0221] These computer-readable program instructions may be provided to a processor of ageneral -purpose computer, special -purpose computer, or other programmable data processing apparatus 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.

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

[0223] 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 inthe Figures. For example, two blocks shown in succession may, in fact, be executed concurrently or 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.

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

[0225] 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: determine, based on a network condition and a request for an uplink resource of a user equipment (UE) for transmission of data associated with an Artificial Intelligence or Machine Learning (AI / ML) model, a configuration of the transmission of the data; and transmit, to the UE, a message that includes the configuration of the transmission of the data.Item [2]: The system according to item [1], wherein the network entity is configured to determine the configuration of the transmission of the data by: determining, based onthe network condition, whether an adjustment to the transmission of the data is required; based on determining that the adjustment to the transmission of the data is not required, determining a scheduling opportunity that allows the UE to perform the transmission of the data; and based on determining that the adjustment to the transmission of the data is required, determining the adjustment to the transmission of the data.Item [3]: The system according to item [2], wherein the adjustment to the transmission of the data comprises one of: an adjustment to a transmission rate or an adjustment to a transmission timing.Item [4]: The system according to item [3], wherein the network entity is configured to determine whether the adjustment to the transmission of the data is required by: comparing a network load to a first threshold; based on determining that the network load is lower than the first threshold, determining that the adjustment to the transmission of the data is not required; based on determining that the network load is equal to or higher than a first threshold, comparing the network load to a second threshold; based on determining that the network load is lower than the second threshold, determining that the adjustment to the transmission rate is required; and based on determining that the network load is equal to or higher than the second threshold, determining that the adjustment to the transmission timing is required.Item [5]: The system according to one or more of items [2]-[4], wherein the network entity is configured to transmit the message to the UE by: based on determining that the adjustment to the transmission of the data is not required, transmitting, to the UE, a Radio Resource Control (RRC) message that comprises a first Information Element (IE) that indicates the scheduling opportunity for the transmission of the data.Item [6]: The system according to one or more of items [2]-[5], wherein the network entity is configured to transmit the message to the UE by: based on determining that the adjustment to the transmission of the data is required, transmitting, to the UE, an RRC message that comprises a second IE that indicates the adjustment to the transmission of the data.Item [7]: The system according to item [4], wherein the network entity is configured to transmit the message to the UE by: based on determining that the adjustment to the transmission rate is required, transmitting, to the UE, an RRC message that comprises a third IE that instructs the UE to implement the adjustment to the transmission rate; and based on determining that the adjustment to the transmission timing is required, transmitting, to the UE, an RRC message that comprises a fourth IE that instructs the UE to implement the adjustment to the transmission timing.Item [8]: The system according to item [7], wherein the adjustment to the transmission timing comprises temporarily suspending the transmission of the data, and wherein the network entity is further configured to: upon transmitting the RRC message that comprises the fourth IE, compare the network load to the second threshold; and based on determining that the network load is lower than the second threshold, transmitting, to the UE, an RRC message that comprises a fifth IE that instructs the UE to resume the transmission of the data.Item [9]: A method comprising: determining, based on a network condition and a request for an uplink resource of a user equipment (UE) for transmission of data associated with an Artificial Intelligence or Machine Learning (AI / ML) model, a configuration of thetransmission of the data; and transmitting, to the UE, a message that includes the configuration of the transmission of the data.Item

[0010] : The method according to item [9], wherein the determining the configuration of the transmission of the data comprises: determining, based on the network condition, whether an adjustment to the transmission of the data is required; based on determining that the adjustment to the transmission of the data is not required, determining a scheduling opportunity that allows the UE to perform the transmission of the data; and based on determining that the adjustment to the transmission of the data is required, determining the adjustment to the transmission of the data.Item

[0011] : The method according to item

[0010] , wherein the adjustment to the transmission of the data comprises one of: an adjustment to a transmission rate or an adjustment to a transmission timing.Item

[0012] : The method according to item

[0011] , wherein the determining whether the adjustment to the transmission of the data is required comprises: comparing a network load to a first threshold; based on determining that the network load is lower than the first threshold, determining that the adjustment to the transmission of the data is not required; based on determining that the network load is equal to or higher than a first threshold, comparing the network load to a second threshold; based on determining that the network load is lower than the second threshold, determining that the adjustment to the transmission rate is required; and based on determining that the network load is equal to or higher than the second threshold, determining that the adjustment to the transmission timing is required.Item

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

[0010] -

[0012] , wherein the transmitting the message to the UE comprises: based on determining that the adjustment tothe transmission of the data is not required, transmitting, to the UE, a Radio Resource Control (RRC) message that comprises a first Information Element (IE) that indicates the scheduling opportunity for the transmission of the data.Item

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

[0010] -

[0013] , wherein the transmitting the message to the UE comprises: based on determining that the adjustment to the transmission of the data is not required, transmitting, to the UE, an RRC message that comprises a second IE that indicates the adjustment to the transmission of the data.Item

[0015] : The method according to item

[0012] , wherein the transmitting the message to the UE comprises: based on determining that the adjustment to the transmission rate is required, transmitting, to the UE, an RRC message that comprises a third IE that instructs the UE to implement the adjustment to the transmission rate; and based on determining that the adjustment to the transmission timing is required, transmitting, to the UE, an RRC message that comprises a fourth IE that instructs the UE to implement the adjustment to the transmission timing.Item

[0016] : The method according to item

[0015] , wherein the adjustment to the transmission timing comprises temporarily suspending the transmission of the data, and wherein the network entity is further configured to: upon transmitting the RRC message that comprises the fourth IE, compare the network load to the second threshold; and based on determining that the network load is lower than the second threshold, transmitting, to the UE, an RRC message that comprises a fifth IE that instructs the UE to resume the transmission of the data.Item

[0017] : A non -transitory computer-readable recording medium having recorded thereon instructions executable by a network entity to cause the network entity to performa method comprising: determining, based on a network condition and a request for an uplink resource of a user equipment (UE) for transmission of data associated with an Artificial Intelligence or Machine Learning (AI / ML) model, a configuration of the transmission of the data; and transmitting, to the UE, a message that includes the configuration of the transmission of the data.Item

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

[0017] , wherein the determining the configuration of the transmission of the data comprises: determining, based on the network condition, whether an adjustment to the transmission of the data is required; based on determining that the adjustment to the transmission of the data is not required, determining a scheduling opportunity that allows the UE to perform the transmission of the data; and based on determining that the adjustment to the transmission of the data is required, determining the adjustment to the transmission of the data.Item

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

[0018] , wherein the adjustment to the transmission of the data comprises one of: an adjustment to a transmission rate or an adjustment to a transmission timing.Item

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

[0019] , wherein the determining whether the adjustment to the transmission of the data is required comprises: comparing a network load to a first threshold; based on determining that the network load is lower than the first threshold, determining that the adjustment to the transmission of the data is not required; based on determining that the network load is equal to or higher than a first threshold, comparing the network load to a second threshold; based on determining that the network load is lower than the second threshold, determiningthat the adjustment to the transmission rate is required; and based on determining that the network load is equal to or higher than the second threshold, determining that the adjustment to the transmission timing is required.

[0226] 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:determine, based on a network condition and a request for an uplink resource of a user equipment (UE) for transmission of data associated with an Artificial Intelligence or Machine Learning (AI / ML) model, a configuration of the transmission of the data; and transmit, to the UE, a message that includes the configuration of the transmission of the data.

2. The system according to claim 1, wherein the network entity is configured to determine the configuration of the transmission of the data by:determining, based on the network condition, whether an adjustment to the transmission of the data is required;based on determining that the adjustment to the transmission of the data is not required, determining a scheduling opportunity that allows the UE to perform the transmission of the data; andbased on determining that the adjustment to the transmission of the data is required, determining the adjustment to the transmission of the data.

3. The system according to claim 2, wherein the adjustment to the transmission of the data comprises one of: an adjustment to a transmission rate or an adjustment to a transmission timing.

4. The system according to claim 3, wherein the network entity is configured to determine whether the adjustment to the transmission of the data is required by:comparing a network load to a first threshold;based on determining that the network load is lower than the first threshold, determining that the adjustment to the transmission of the data is not required;based on determining that the network load is equal to or higher than a first threshold, comparing the network load to a second threshold;based on determining that the network load is lower than the second threshold, determining that the adjustment to the transmission rate is required; andbased on determining that the network load is equal to or higher than the second threshold, determining that the adjustment to the transmission timing is required.

5. The system according to claim 2, wherein the network entity is configured to transmit the message to the UE by:based on determining that the adjustment to the transmission of the data is not required, transmitting, to the UE, a Radio Resource Control (RRC) message that comprises a first Information Element (IE) that indicates the scheduling opportunity for the transmission of the data.

6. The system according to claim 2, wherein the network entity is configured to transmit the message to the UE by:based on determining that the adjustment to the transmission of the data is required, transmitting, to the UE, an RRC message that comprises a second IE that indicates the adjustment to the transmission of the data.

7. The system according to claim 4, wherein the network entity is configured to transmit the message to the UE by:based on determining that the adjustment to the transmission rate is required, transmitting, to the UE, an RRC message that comprises a third IE that instructs the UE to implement the adjustment to the transmission rate; andbased on determining that the adjustment to the transmission timing is required, transmitting, to the UE, an RRC message that comprises a fourth IE that instructs the UE to implement the adjustment to the transmission timing.

8. The system according to claim 7, wherein the adjustment to the transmission timing comprises temporarily suspending the transmission of the data, and wherein the network entity is further configured to:upon transmitting the RRC message that comprises the fourth IE, compare the network load to the second threshold; andbased on determining that the network load is lower than the second threshold, transmitting, to the UE, an RRC message that comprises a fifth IE that instructs the UE to resume the transmission of the data.

9. A method comprising:determining, based on a network condition and a request for an uplink resource of a user equipment (UE) for transmission of data associated with an Artificial Intelligence or Machine Learning (AI / ML) model, a configuration of the transmission of the data; andtransmitting, to the UE, a message that includes the configuration of the transmission of the data.

10. The method according to claim 9, wherein the determining the configuration of the transmission of the data comprises:determining, based on the network condition, whether an adjustment to the transmission of the data is required;based on determining that the adjustment to the transmission of the data is not required, determining a scheduling opportunity that allows the UE to perform the transmission of the data; andbased on determining that the adjustment to the transmission of the data is required, determining the adjustment to the transmission of the data.

11. The method according to claim 10, wherein the adjustment to the transmission of the data comprises one of an adjustment to a transmission rate or an adjustment to a transmission timing.

12. The method according to claim 11, wherein the determining whether the adjustment to the transmission of the data is required comprises:comparing a network load to a first threshold;based on determining that the network load is lower than the first threshold, determining that the adjustment to the transmission of the data is not required;based on determining that the network load is equal to or higher than a first threshold, comparing the network load to a second threshold;based on determining that the network load is lower than the second threshold, determining that the adjustment to the transmission rate is required; andbased on determining that the network load is equal to or higher than the second threshold, determining that the adjustment to the transmission timing is required.

13. The method according to claim 10, wherein the transmitting the message to the UE comprises:based on determining that the adjustment to the transmission of the data is not required, transmitting, to the UE, a Radio Resource Control (RRC) message that comprises a first Information Element (IE) that indicates the scheduling opportunity for the transmission of the data.

14. The method according to claim 10, wherein the transmitting the message to the UE comprises:based on determining that the adjustment to the transmission of the data is required, transmitting, to the UE, an RRC message that comprises a second IE that indicates the adjustment to the transmission of the data.

15. The method according to claim 12, wherein the transmitting the message to the UE comprises:based on determining that the adjustment to the transmission rate is required, transmitting, to the UE, an RRC message that comprises a third IE that instructs the UE to implement the adjustment to the transmission rate; andbased on determining that the adjustment to the transmission timing is required, transmitting, to the UE, an RRC message that comprises a fourth IE that instructs the UE to implement the adjustment to the transmission timing.

16. The system according to claim 15, whereintheadjustmentto the transmission timing comprises temporarily suspending the transmission of the data, and wherein the network entity is further configured to:upon transmitting the RRC message that comprises the fourth IE, compare the network load to the second threshold; andbased on determining that the network load is lower than the second threshold, transmitting, to the UE, an RRC message that comprises a fifth IE that instructs the UE to resume the transmission of the data.

17. 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: determining, based on a network condition and a request for an uplink resource of a user equipment (UE) for transmission of data associated with an Artificial Intelligence or Machine Learning (AI / ML) model, a configuration of the transmission of the data; andtransmitting, to the UE, a message that includes the configuration of the transmission of the data.

18. The non-transitory computer-readable recording medium according to claim 17, wherein the determining the configuration of the transmission of the data comprises:determining, based on the network condition, whether an adjustment to the transmission of the data is required;based on determining that the adjustment to the transmission of the data is not required, determining a scheduling opportunity that allows the UE to perform the transmission of the data; andbased on determining that the adjustment to the transmission of the data is required, determining the adjustment to the transmission of the data.

19. The non-transitory computer-readable recording medium according to claim 18, wherein the adjustment to the transmission of the data comprises one of: an adjustment to a transmission rate or an adjustment to a transmission timing.

20. The non-transitory computer-readable recording medium according to claim 19, wherein the determining whether the adjustment to the transmission of the data is required comprises:comparing a network load to a first threshold;based on determining that the network load is lower than the first threshold, determining that the adjustment to the transmission of the data is not required;based on determining that the network load is equal to or higher than a first threshold, comparing the network load to a second threshold;based on determining that the network load is lower than the second threshold, determining that the adjustment to the transmission rate is required; andbased on determining that the network load is equal to or higher than the second threshold, determining that the adjustment to the transmission timing is required.

Images