3GPP TSG RAN WG1 #122 R1-250xxx Bengaluru, India, Aug 25th – 29th, 2025 Agenda item: 11.6 Source: Samsung (Moderator) Title: Moderator summary #1 on AI/ML for 6GR Document for: Decision 1 Framework and evaluation 1.1 Evaluation and KPIs Several companies discussed aspect on EVM and KPIs. Several companies proposed for comprehensive evaluation of AI/ML use cases by considering KPIs including system performance, system and model complexity, inter-vendor collaboration complexity, power consumption. In addition to intermediate and system KPIs that were adopted in 5G NR, companies proposed new KPIs such power consumption and inference latency to be considered in 6GR. Proposal 1.1-1: For evaluation of AI/ML use cases in 6GR, consider * Performance related metrics, including intermediate (model) performance KPIs and system KPIs, e.g., throughput, overhead * AI/ML Model related metrics, including model complexity, inter-vendor collaboration when applicable o FFS: whether/how to measure power consumption, inference latency and training latency (when applicable) Company Comment Google Probably we can consider adding a note as follows. Different use case may choose different types of KPIs. Note: Whether to use intermediate KPI and/or system KPI is discussed per use case. Lenovo At least for use cases, link level KPI can be considered, e.g., BLER for AI based channel estimation. CATT, CICTCI Support in general. For the FFS, we think training latency is not a critical issue for offline training. Is it only applicable for online training or continuous learning? CMCC Generally OK except for the inter-vendor collaboration part. For two-sided model, there is inter-vendor collaboration training complexity, but to quantify the complexity with specific metrics, we think it is not an easy way from the expertise in 5G-A AI study. And for training latency, we think it only occurs when online training is involved. Fujitsu Agree with CMCC regarding the inter-vendor collaboration part. Also clarification is needed on training latency. Nokia OK with the direction. Compared to 5G-Adv, more emphasis on power consumption, inference delay, and the system level performance over more realistic assumptions shall be considered in the study. Please find some updates. Updated Proposal 1.1-1: For evaluation of AI/ML use cases in 6GR, consider * Performance related metrics, including intermediate (model) performance KPIs and system level KPIs ( e.g., throughput, overhead) * AI/ML Model related metrics, including model complexity, power consumption, inference latency, and inter-vendor collaboration complexity (when applicable) o FFS: how to measure power consumption, inference latency o Consider robustness under a wide range of conditions, including realistic deployment scenarios. ZTE We propose the following updates. ZTE Proposal: For evaluation of AI/ML use cases in 6GR, consider * Performance related metrics, including intermediate (model) performance KPIs and system KPIs o Examples of intermediate performance KPIs: SGCS, etc o Examples of system KPIs: throughput, overhead, etc * AI/ML Model related metrics, including model complexity, inter-vendor collaboration when applicable o Note: power consumption can be reflected by the model complexity o FFS: whether/how to measure power consumption, inference latency and training latency (when applicable) Note: Detailed metric for each AI/ML use case is discussed per AI/ML use case Ericsson * For complexity, computational complexity needs to be included together with model complexity * Add generalizability * Add a note to first bullet: “Note: for each use case, to draw accurate conclusions on performance benefits, non-intermediate performance KPIs should always be complemented with link/system KPIs (BLER, throughputs).” NTT DOCOMO We are generally fine with the principle of the proposal. But whether both kinds of performance metrics are needed can be discussed on a case-by-case basis. Some proposed use cases consider issues related to fundamental signal design or RF impairment. For those cases, we can further discuss whether system-level evaluations are necessary and the corresponding EVM. Xiaomi 1. For the AI/ML related metrics, it is unclear how to measure the inter-vendor collaboration 2. For the power consumption, with the increase of AI use cases, the power consumption will be increased accordingly. From that sense, guranteeing the power efficiency is critical to the user throughput. Thus, power consumption should be one criteria for the use case evaluation. As for the how to measure the power consumption, we don’t think it could be simply reflected by the model complexity, it also affected by the inference frequency. Even when there is no task, certain base electronic current is also needed to maintain the AI engine on, that would also cause some energy consumption 3. As for the training latency, we share similar view with CATT QC We can take the following list captured in 38.843 as the starting point. In addition, we’re open to studying other complexity-related KPIs such as power consumption and inference latency if there is a good way to capture them. --- from 38.843 (section 6.1) --- Common KPIs (if applicable): - Performance - Intermediate KPIs - Link and system level performance - Generalization performance - Over-the-air Overhead - Overhead of assistance information - Overhead of data collection - Overhead of model delivery/transfer - Overhead of other AI/ML-related signalling - Inference complexity, including complexity for pre- and post-processing - Computational complexity of model inference: TOPs, FLOPs, MACs - there may be a disconnect between the actual complexity and the complexity evaluated as captured in clause 6 using these KPIs due to the platform-dependency and implementation (hardware and software) optimization solutions - Computational complexity for pre- and post-processing - Model complexity: e.g., the number of parameters and/or size (e.g., Mbyte) - Complexity shall be reported in terms of "number of real-value model parameters" and "number of real-value operations" regardless of underlying model arithmetic - Training complexity - LCM related complexity and storage overhead - Storage/computation for training data collection - Storage/computation for training and model update - Storage/computation for model monitoring - Storage/computation for other LCM procedures, e.g., model activation, deactivation, selection, switching, fallback operation For evaluation of performance monitoring approaches, the following model monitoring KPIs are considered as general guidance: - Accuracy and relevance (i.e., how well does the given monitoring metric/methods reflect the model and system performance) - Overhead (e.g., signalling overhead associated with model monitoring) - Complexity (e.g., computation and memory cost for model monitoring) - Latency (i.e., timeliness of monitoring result, from model failure to action, given the purpose of model monitoring) Note: Other KPIs are not precluded. Relevant KPIs may vary across different model monitoring approaches. LGE Generally ok but it is questionable how to evaluate interference/training latency. Prefer to remove FFS. OPPO Obviously, RAN1 will have to carry out evaluations for selected use cases. We are fine with this direction. However, it seems too early to decide the performance metrics, which depends on each of selected use case. ETRI Support Spreadtrum Generally fine with the proposal. And also agree with the modification for KPI part. Regarding training latency, it should be clarified that it is only taken into account during online training. InterDigital We are ok to remove the FFS bullet. It is not clear whether where or when consumed power is used. The KPI in the first bullet should also include complexity. In the study, we should also identify the baseline to compare the performance against. CEWiT We are ok with the proposal Futurewei This is the beginning of 6GR SI, everything listed in this proposal is for study. We should remove FFS, especially for power consumption as this aspect is critical. vivo Share comments with Xiaomi. * Inter-vendor collaboration if considered may not be at the same level as the other bullets. The whole training complexity can be further studied if companies want to raise these points. * Power consumption as a metric is needed. Our proposal is to relate power consumption to FLOPS or OPS. We prefer to capture the wording in a more general way. Proposal 1.1-1: For evaluation of AI/ML use cases in 6GR, consider * Performance related metrics, including intermediate (model) performance KPIs and system KPIs, e.g., throughput, overhead * AI/ML Model related metrics, including number of operations per second (FLOPS/OPS for measuring model inference complexity, model inference power consumption, etc.)., inter-vendor collaboration when applicable o FFS: whether/how to measure power consumption, inference latency and training latency (when applicable) , training complexity etc AT&T Agree with the comment from Qualcomm, system and link performance, generalization aspects, different kinds of overhead, complexity, power consumption should be considered IIT Madras We support this proposal. The study should include at least inference latency. We are ok with FFS on whether power consumption and training latency should be considered. Samsung Ok. Company Proposal Ericsson Proposal 2 6GR AI/ML use cases should be selected considering their potential as per the following criteria: performance gain, implementation complexity, inter-vendor interoperability, AI/ML model training complexity, signalling overhead, and specification impact. Huawei Proposal 3: Comprehensive comparison between non-AI and AI/ML-based air-interface enhancement solutions is necessary to justify the advantages, at least in terms of system performance, system overhead, computational complexity, and power consumption. * Fallback from AI/ML-based solution to the corresponding non-AI solution should be supported. Proposal 4: For the study of a use case with both one-sided and two-sided model solutions, comprehensive comparison between one-sided and two-sided models should be considered at least on system performance, system overhead, computational complexity, and power consumption. AT&T Proposal 6: For 6GR design, final performance metrics (e.g. throughput) are used for performance evaluation of AI/ML use cases Proposal 7: For 6GR design, consider complexity and performance tradeoffs for evaluating AI/ML use cases Xiaomi Proposal 1: * Selected use cases should achieve an optimal trade-off among performance gain, complexity, and power consumption. * Candidate use cases for selection can be categorized as: 5GA-supported use cases, extensions of 5GA use cases, and new use cases. Distinct approaches should be applied to handle each type. Proposal 2: The following principles should guide framework extension studies: * Control UE Complexity and Cost: - Mitigate the requirement for UEs to maintain excessive models or parameters. - Minimize unnecessary on-device training. * Maintain Excellent User Experience: - Prioritize high energy efficiency. - Ensure robust user privacy protection. * Support Extended Enablers for Identified Use Cases: - Extend the data collection framework to enable the acquisition of new data sample types (e.g., transmission data bits/symbols). HONOR Proposal 3: During the study on potential use cases of AI/ML in 6GR interface, three critical dimensions should be considered: performance improvements, sustainability initiatives, and the creation of new services. vivo Proposal 1: 6G AIML evaluation methodology need to be established for evaluating use case performance, complexity and power consumption. Proposal 3: Number of operations per second (OPS) and inference frequency are used as metric for evaluation of power consumption and complexity. Proposal 4: A magnitude level upper bound for complexity/power consumption can be set up/considered for feasibility observation of use cases, e.g., [1T] Ops as an upper bound for 6G AIML operations, with understanding that it corresponds to 100mw power consumption and 1% of total on device computation power. Proposal 5: For each use case companies are expected to report and cross check performance gain, number of operations per second for inference (OPS) and inference frequency per second. Samsung Proposal 5: For 6GR use-case studies, adopt intermediate and ultimate (eventual/system) KPIs as in the NR. - Intermediate KPIs to evaluate model-specific performance, e.g., model performance-complexity trade-off, generalization performance, monitoring accuracy, training and dataset aspects. - Ultimate KPIs to assess overall performance benefits of AI/ML use cases. Proposal 6: Adopt NR’s AI/ML evaluation methodology for model generalization performance evaluation for 6GR. The following cases for verifying the generalization performance of an AI/ML model over various scenarios/configurations: - Case 1: The AI/ML model is trained based on training dataset from one Scenario#A/Configuration#A, and then the AI/ML model performs inference/test on a dataset from the same Scenario#A/Configuration#A - Case 2: The AI/ML model is trained based on training dataset from one Scenario#A/Configuration#A, and then the AI/ML model performs inference/test on a different dataset than Scenario#A/Configuration#A, e.g., Scenario#B/Configuration#B, Scenario#A/Configuration#B - Case 3: The AI/ML model is trained based on training dataset constructed by mixing datasets from multiple scenarios/configurations including Scenario#A/Configuration#A and a different dataset than Scenario#A/Configuration#A, e.g., Scenario#B/Configuration#B, Scenario#A/Configuration#B, and then the AI/ML model performs inference/test on a dataset from a single Scenario/Configuration from the multiple scenarios/configurations, e.g., Scenario#A/Configuration#A, Scenario#B/Configuration#B, Scenario#A/Configuration#B. SK Telecom Proposal 2. For 6G system with AI/ML, performance gain with complexity/cost should be assessed/evaluated by comparing with that without AI/ML. FFS on details (e.g., metric). OPPO Proposal 1: Consider the following principles to select AI/ML use cases for 6GR study * Prioritization of AI/ML-Intrinsic design that significantly enhances the basic components of the transceiver chain of 6GR * Significant performance benefits for intermediate metrics (e.g. SGCS, NMSE, or predication accuracy) and final metrics (e.g. BLER or throughput) over legacy non-AI schemes * Well-balanced tradeoff among performance benefits, computation complexity and power consumption Kyocera Proposal 1: Companies should provide system-level simulation results to quantify the performance gains achievable using Neural Receivers. These evaluations should also assess the feasibility and practical considerations of implementing Neural Receivers on the UE side, considering computational complexity, power consumption, and real-time processing constraints. Proposal 2: During the study item phase, in addition to presenting performance gains for any considered use case, it is proposed that inference latency results also be reported. This will ensure a comprehensive evaluation of AI/ML-based solutions, particularly in scenarios where real-time responsiveness is critical. 1.2 Enhancement on LCM framework Many companies proposed enhancement on NR’s LCM, encompassing aspects such as data and model management, including model transfer, applicability of the associated ID, support for localized models, advanced training methods, e.g., online and federated learning, meta-learning for handling network-side additional conditions. Moreover, a number of companies proposed to 5G NR’s LCM framework including functionality-based LCM as a starting point. Enhancement on AI/ML processing unit framework was proposed by a few companies, e.g., 1 company (Samsung) proposed to introduce AI/ML memory unit (MU) on the concurrently activated AI/ML feature/models Proposal 1.2-1: Consider the 5G NR LCM framework as a starting point. Strive to minimize changes by updating or revising the framework only when justified. * Study potential enhancements for LCM at least including the following o Data and model management, including model transfer o Handling of network-side additional conditions, e.g., applicability of associated ID o Advanced model training, e.g., online training/finetuning, federated learning, meta-learning o Enhancement on the framework for AI/ML processing unit and memory Company Comment Google We suggest removing the sentence “Strive to minimize changes by updating or revising the framework only when justified.” The 5G LCM framework includes CSI framework. It is too early to say 6G will reuse 5G’s CSI framework. In addition, we failed to see the necessity to study “advanced model training”. Ofinno Generally fine. Regarding advanced model training, the aspect related to at least online training needs to be studied. Fainity Fine with the proposal.   Lenovo We are generally fine with this proposal. For the last bullet, we want to clarify whether the computation/processing time issue for AI/ML operation is included? CATT, CICTCI Fine with the listed enhancement points. We also think ‘Continuity of AI/ML features’ can be studied since UE-side model may or may not fail when moving across cells. Nonetheless, we think the sentence ‘Strive to minimize changes by updating or revising the framework only when justified’ looks quite negative view on 6G study. 5G LCM is studied and established only in 2 releases. Unlike waveform/modulation, we cannot say 5G LCM is perfect, the golden rule and mature enough for future 10~15 years. Suggest removing this sentence. SK Telecom Generally fine but we also think ‘Strive to minimize changes by updating or revising the framework only when justified’ would be too conservative. Better to remove it. The editorial suggestion for the main bullet would be “For 6G LCM framework for AI/ML for air interface, consider the 5G NR LCM framework as a starting point.” CMCC OK to take 5G NR AI LCM framework as starting point and study some 6G enhancements. For the last bullet, we suggest modifying to a more general wording, “Enhancement on the framework for AI/ML processing unit and memory criteria ”. Fujitsu The LCM framework specified in Rel-19 is for one-sided model. The normative work for two-sided model is ongoing. The LCM in Rel-19 should be taken as starting point. In addition, in 6GR, the data collection and performance monitoring may be enhanced for different use case. The following update is suggested. Consider the 5G NR LCM framework in Rel-19 as a starting point. Strive to minimize changes by updating or revising the framework only when justified. * Study potential enhancements for LCM at least including the following o Data and model management, including data collection, performance monitoring, and model transfer o Handling of network-side additional conditions, e.g., applicability of associated ID o Advanced model training, e.g., online training/finetuning, federated learning, meta-learning Enhancement on the framework for AI/ML processing unit and memory Nokia Overall direction is OK. We are not sure about most of the study points. Some of these points were well studied in Rel-18 and Rel-19. In our view, main focus of the extra study on the framework shall be build around continuous learning. Updated version is suggested as below, Proposal 1.2-1: Consider the 5G NR model management framework as a starting point. * Study potential enhancements for model management at least including the following o Enablers for continuous (online) on-device model training o ZTE Although we support to study the LCM for AI in 6G. But it seems to us too early to start the discussion, since the LCM discussion should be based on concrete AI/ML use case. From this perspective, we propose to focus on the AI/ML use cases at least in this meeting. In any case, we propose one additional study aspect for the potential enhancement for LCM, i.e., model state management. In addition, can the proponents clarify whether there are any RAN1 spec impacts for federated learning, meta-learning. Huawei, HiSilicon It is too early to say “Strive to minimize changes by updating or revising the framework only when justified”. 6G is a new generation, why do we limit the study on framework should be “minimized”? BTW, UE side additional condition can also be discussed? Consider the 5G NR LCM framework as a starting point. Strive to minimize changes by updating or revising the framework only when justified. * Study potential enhancements for LCM at least including the following o Data and model management, including model transfer o Handling of network/UE-side additional conditions, e.g., applicability of associated ID o Advanced model training, e.g., online training/finetuning, federated learning, meta-learning o Enhancement on the framework for AI/ML processing unit and memory Ericsson * It needs to be defined first what “5G NR LCM framework” refers to exactly. High-level steps (training data collection, inference, monitoring) or more details (e.g., the options for training data collection, model delivery/transfer cases, functionality-based LCM,…). * It is too restrictive to say “Strive to minimize changes …” as 6G is allowed to be designed from scratch, after learning the lessons in 5GR use cases. Suggest to delete this sentence. * How 5G CSI framework will be used for the Rel-20 5G AI/ML CSI compression feature is not finalized yet. This should not stop us from studying 6G CSI framework aspects from scratch for 6G non-AI/ML and/or AI/ML use cases. In our view 6G CSI framework should be discussed in 6G MIMO agenda while accommodating both non-AI/ML and AI/ML use cases. * Also, the First release of 6G should prioritize one-sided use cases. Suggested revision: Proposal 1.2-1A: Consider the 5G NR LCM framework as a starting point. Strive to minimize changes by updating or revising the framework only when justified. * Study the necessity of potential enhancements for LCM, and if justified, the enhancement details. The examples to study include: o Data and model management, including model transfer o Handling of network-side additional conditions, e.g., applicability of associated ID o Advanced model training, e.g., online training/finetuning, federated learning, meta-learning o Enhancement on the framework for AI/ML processing unit and memory NEC 5G NR LCM framework is heavily relied on CSI framework and cannot accommodate any non-CSI new use case in 6G. We need LCM framework more general and unified and we have to avoid to design new framework for each use case. Therefore, we need to be careful about ‘5G NR LCM framework as a starting point’ With that said, we support the third and fourth sub-bullets in this proposal including studying Advanced model training and studying enhancements for AI/ML processing unit and memory. Panasonic We are fine with first sentence in main bullet point. - The 2nd sentence is dependent on sub-bullet points For sublet-points, there might be other enhancement, such as depending on new use case. Hence, we think it is better to replace them by a general FFS point such as “FFS: Study potential enhancement for LCM” Having said that, we propose as follows: Proposal 1.2-1: Consider the 5G NR LCM framework as a starting point. - FFS: Potential enhancements for LCM if any NTT DOCOMO Generally fine that 5G LCM framework should be a baseline and changes should be minimized in terms of the smooth introduction to commercial. Since the 5G CSI compression is under discussion, need to consider avoiding duplication of framework discussion of 5G and 6G. Xiaomi 1. Since the data management and model management are two separate issues, the first subbullet should be split into data management subbullet and model management subbullet 2. As commented in proposal 1.1-1, AI power effciency is one important factor affecting user experience. Thus studying the approaches to improve the AI power effiency should be a part of LCM framework. 3. As for ” Strive to minimize changes by updating or revising the framework only when justified”, we share similar view with some companies that it should be removed The following is our suggestion Proposal 1.2-1: Consider the 5G NR LCM framework as a starting point. Strive to minimize changes by updating or revising the framework only when justified. * Study potential enhancements for LCM at least including the following o Data management o Model management, including model transfer o Handling of network-side additional conditions, e.g., applicability of associated ID o Advanced model training, e.g., online training/finetuning, federated learning, meta-learning o Enhancement on the framework for AI/ML processing unit and memory o Approaches to guarantee the power efficiency of AI operation QC Suggest the following updates: Updated Proposal 1.2-1: Consider the 5G NR LCM framework as a starting point. Strive to minimize changes by updating or revising the framework only when justified. * Study potential enhancements for LCM at least including the following o Data and model management, including model transfer/delivery o Handling of network-side additional conditions, e.g., applicability of associated ID o Advanced model training, e.g., online training/finetuning, federated learning, meta-learning o Enhancement/redesign on the framework for AI/ML processing unit and memory LGE Main message should be the sub-bullet. Re AI/ML memory unit, we are not convinced whether any new methodology is needed. Proposed revision: Consider the 5G NR LCM framework as a starting point. Strive to minimize changes by updating or revising the framework only when justified. * Study potential enhancements for LCM at least including the following o Data and model management, including model transfer o Handling of network-side additional conditions, e.g., applicability of associated ID o Advanced model training, e.g., online training/finetuning, federated learning, meta-learning o Enhancement on the framework for AI/ML processing unit and memory o Reduction of LCM signaling/configuration overhead o Extendibility to new AI/ML use cases Note: Consider the 5G NR LCM framework as a starting point. Strive to minimize changes. OPPO The 5G use cases are basically CSI-related ones (except positioning), and the LCM framework is actually established on CSI framework. For 6GR, there could be some promising use cases other than CSI, such as DMRS overhead reduction, it seems not applicable to reuse the CSI framework for non-CSI use cases. Furthermore, the CSI framework of 6GR is not yet studied under MIMO, hence it seems premature to set a starting point. To avoid duplicated LCM discussion for all use cases, unified LCM procedure should be strived and that’s once-in-a-decade chance to make a fundamental change. With above being said, we suggest the following change Proposal 1.2-1: Consider the 5G NR LCM framework as a starting point and strive for unified LCM framework for all selected use cases. Strive to minimize changes by updating or revising the framework only when justified. * Study potential enhancements for LCM at least including the following o Data and model management, including model transfer o Handling of network-side additional conditions, e.g., applicability of associated ID o Advanced model training, e.g., online training/finetuning, federated learning, meta-learning Enhancement on the framework for AI/ML processing unit and memory ETRI Support. Advanced model training such as online training may also be studied in some use cases. Spreadtrum We agree to take the 5G NR LCM framework as the starting point. However, in line with the majority of companies' view, can we "Strive to minimize changes..." requires careful consideration. InterDigital “Strive to minimize changes by updating or revising the framework only when justified. “ can be removed. 5G LCM framework was optimized for each use case. As 6G AI will have different use cases, unified 6G LCM may have a completely different framework. We are ok to use the 5G LCM as the reference. * Study potential enhancements for LCM at least including the following Can be changed to “Study at least the following aspects for LCM” CEWiT We believe adaptation of the 5G LCM framework has its limitations especially considering some of the new use cases discussed here. So it is very strong to say “Strive to minimize changes by updating or revising the framework only when justified”. We agree to have 5G LCM framework as starting point but propose to remove the above text. Futurewei This is the beginning of 6GR SI, everything listed in this proposal is for study. We should remove FFS, especially for power consumption as this aspect is critical. Vivo Share similar comments as Google. It is too restrictive to directly state “to minimize changes”. Prefer to delete it. For advanced model training, we would like to add on device training/finetuning, which is different from online training. On line training implies stringent timeline while on device training provides additional benefits of less user privacy concern without constraint on stringent timeline restirctions. Proposal 1.2-1: Consider the 5G NR LCM framework as a starting point. Strive to minimize changes by updating or revising the framework only when justified. * Study potential enhancements for LCM at least including the following o Data and model management, including model transfer o Handling of network-side additional conditions, e.g., applicability of associated ID o Advanced model training, e.g., online/on device training/finetuning, federated learning, meta-learning o Enhancement on the framework for AI/ML processing unit and memory AT&T Agree with the above comments that strive to minimize changes by updating or revising the framework from 5GNR is too restrictive and should be removed. Support the order change of the bullet and subbullet proposed by LG. IIT Madras In general, we agree that 5G LCM can be used as a baseline. But it is too early to say that changes should be minimized. Samsung Thanks FL. This is a good list of items to initiate study on 6GR framework (potential enhancements from NR’s framework). We strongly suggest to minimize the discussion on what 5G NR has sufficiently addressed. 6G framework should be built taking the 5G framework as a foundation. Company Proposal Huawei Proposal 6: The framework should be enhanced based on the legacy framework for AI/ML for air-interface at least in the following aspects: * Data collection and management, e.g., considering new data types. * Model management, e.g., considering new UE capability of online fine-tuning, or management across multiple AI/ML enabled functions. * UE management, e.g., scheduling of UEs for distributed model solutions. AT&T Proposal 1: The following core principles are followed to design an AI/ML framework for 6GR air interface: * A unified flexible LCM framework for model management, model transfer, model training, and model testing * A unified data collection framework to enhance management efficiency * Network visibility to drive innovation while proactively addressing security and privacy concerns * Network control over data collection to ensure network performance is not impacted while providing potential new value opportunities via hosting/routing/augmenting the data * Scalability to accommodate various emerging and future use cases. Xiaomi Proposal 14: Consider the AI/ML framework defined in 5GA as baseline for 6GR AI/ML Proposal 15: Unique associated ID among multiple cells should be supported to ensure more efficient network condition check Apple Proposal 7: For the 6G SI on AI/ML Lifecycle Management (LCM) framework, use the 5G AI/ML LCM framework as the starting point for both one-sided and two-sided model architectures. Additional enhancements to be considered include: * Extending the Association ID to support multi-cell scenarios, applicable to both one-sided and two-sided models * Study a simplified and scalable APU framework applicable to a wide range of AI/ML use cases other than AI based CSI report. LGE Proposal#12: Study 6GR LCM framework in a dedicated agenda considering at least the following aspects: - Training data reduction for NW/UE-side data collection - Reduced signaling/configuration overhead for LCM operation - Support of fast and dynamic LCM operation considering localized model implementation - New PU framework to support various AI/ML use cases Sharp Proposal 6: RAN1 assumes Rel-19 functionality-based AI/ML LCM could be reusable as baseline for designing 6G AI/ML framework. Samsung Proposal 1:Take NR AI/ML framework as a starting point and support/adopt the following in 6GR AI/ML framework - Terminologies in TR 38.843 - UE-side and NW-side data collection - Applicability report - Associated ID to indicate additional conditions that may not be explicitly configured - Fully specified reference two-side models to address interoperability - Performance monitoring - Dedicated AI/ML processing unit (APU) and timeline Proposal 2: Consider the following approaches to support site/scenario-specific models - Non-linear approaches: Parameter transfer for input/output adaptation layers of specified model structure - Linear approaches: downloadable projection/basis matrices for input/output processing Proposal 3: Considering online training/fine-tuning in 6GR AI/ML study, at least for the use case that only requires lightweight model. Proposal 4: Study the potential impact of AI/ML memory on the concurrently activated AI/ML features/models, including whether to introduce AI/ML memory unit (MU) taking the NR’s active CSI-RS resource and ports counting as a starting point OPPO Proposal 3: Strive for unified LCM framework for 6GR, including at least the following aspects * Data collection for model training and fine-tuning * UE-side and/or NW-side model monitoring * Model paring (for two-sided model) and model identification * LCM-related operation, e.g. model switch, fallback, activation/deactivation CATT, CICTCI Proposal 1: For 6G AI/ML framework, develop an enhanced LCM framework to enable future-proof framework applicable to emerging use cases, incorporating: * Advanced training techniques, e.g. online training, federated learning * Unified management of AI/ML features * Continuity of AI/ML features Kyocera Proposal: RAN1 should further investigate the feasibility of implementing more robust solutions to address the network-side additional conditions problem. The study may include the technology enablers of advanced AI/ML methodologies, such as meta-learning, which enable models to dynamically adapt to varying data distributions encountered during inference. NEC Proposal 7: Study 6G AI/ML framework by coordinating with SA from the beginning. Proposal 8: Study unified framework for AI/ML for 6GR, ensuring high performance, security, and adaptability to all use cases in 6G, including ? Unified data collection framework ? Unified LCM framework Proposal 9: Study a unified AI processing capability among multiple AI/ML functionalities, including: ? Mechanisms to manage processing resources for multiple, concurrently running 3GPP-defined AI/ML functionalities, considering their non-continuous activity. ? Methods to account for the dynamic impact of non-3GPP applications on the UE's available processing capability for 3GPP-defined functionalities. 1.3 Data collection framework A number of companies discussed data collection framework in their contribution. The following summarizes the discussion points 1. Enhancement in the data collection framework for future-proof and unified (across working groups) design. 2. Scope and restrictions, e.g., whether to restrict data collection to use cases or to support generic purpose data collection. 3. Whether to introduces a new AI/ML data management plane Some of the proposals may not be under the realm of RAN1. However, RAN1 may identify requirements which may consequently suggest enhancement in the relevant working group. With this in mind, the RAN1 study may focus in identifying requirements that may lead to data collection framework enhancement. Conclusion 1.3-1: For AI/ML study in 6GR, RAN1 to study on the content and format for data collection for each use case. Company Comment Google OK in principle. We also want to clarify the measurement related aspects, e.g., DL-RS, CPU and so on should also be studied in RAN1. Ofinno Support Sharp Support Fainity Support. Most use cases correspond to channel conditions measured by the UE and it may be transmitted via L1 signalling. So, the content and format should be studied by RAN1.  Lenovo Support CATT, CICTCI OK. But just remind, RAN1 may participate in relevant LCM discussion, e.g. whether the CSI related data is collected in RAN1 CSI framework, or a dedicated AI/ML framework. BTW, this should be proposed as an agreement rather than conclusion? SK Telecom Support. CMCC Support. Also, the latency of data collection should be studied if some advanced model training, e.g., online training/finetuning, federated learning, meta-learning are involved. NVIDIA Support Fujitsu Generally fine. Should we let other WGs know this conclusion? Nokia This is not a critical proposal for RAN1. Data content is use-case dependent, but that can be clarified when RAN2 has some study on general framework on data collection. ZTE Ok to study Ericsson Not sure about the purpose of the conclusion. It’s more useful to have a proposal (which is turned into an agreement) on what to be studied. “data collection” refers to training data collection only, or also include data collection for inference and monitoring? Clearly detailed content and format of data to be collected depends on use case. But it is more useful to discuss a common framework or guideline to support training data collection (a) for all UE-side models; (b) for network-side models. NEC We share the similar view that data collection may be more a higher layer or SA related mechanism. Also, we believe a unified framework across use cases for data collection is beneficial for data management and storage, and also easy to be compatible with other use cases in subsequent releases of 6GR. Panasonic Ok NTT DOCOMO Support. Study on other than the content and format for data collection for each use case are up to other WGs or at least need a synchronization to other WGs. Xiaomi Support in principle We share similar view with CATT. Besides the format and content, associated procedure may also need to be studied in RAN1 scope. QC Additionally, data collection for on-device adaptation/fine-tuning should be considered for study. LGE Data content and format can be discussed per use case but data collection framework needs be considered in use-case-common way. OPPO Generally fine. In our thinking, data collection can be discussed in other WG, but the content and format of data set for RAN1 selected AI/ML use cases should be discussed in RAN1. ETRI Support Spreadtrum Support InterDigital Support CEWiT Support vivo Fine for RAN1 to study content. Formatting issues might be more of signalling design. AT&T The purpose of the conclusion is not clear and suggest removing it. There is a need for a general framework for data collection, that may not be within the scope of RAN1, and of course the content will be use case dependent, but the conclusion implies discussing data collection on a use case by use case basis which is the very problem with the 5G-A methodology, so the conclusion can be removed and is not needed. IIT Madras Support. Samsung Support. Companies’ proposals are captured below: Company Proposal AT&T Proposal 2: AI/ML framework in 6GR should support multiple termination points for AI/ML data within the network with MNO visibility Proposal 3: 6GR is designed to differentiate AI/ML data management traffic from user plane traffic and control plane traffic Proposal 4: for the AI/ML framework in 6GR, study the introduction of an AI/ML data management plane to manage data collection, model transfer/delivery and LCM aspects of different AI/ML use cases on 6GR interface Xiaomi Proposal 17: Consider data collection extension from the following aspects * Define dedicated data bit/symbol sequence for training data collection * Establish the procedure for the dedicated data sample collection HONOR Proposal 4?Data collection framework in 6GR interface should be designed with forward compatibility, at least including * Capable of supporting diverse AI/ML use cases in 6GR. * Support of a data collection framework that is open, standardized and accessible to OEMs and network operators. * Strive for a common data collection framework across RAN and SA. Proposal 5: AI/ML in 6GR interface should strive for a unified framework for LCM, including: * The LCM framework defined within the 5G specifications for AI/ML can serve as a valuable foundation for 6GR. * Offline model training is at least supported in 6G day one. * 6GR works towards establishing a unified framework for model exchange across both RAN and SA. * It’s proposed to achieve a unified functionality management framework to support broader use cases. * Non-AI solutions are always supported as fallback mechanisms. * It is recommended to explore a more flexible UE capability and functionality reporting in the context of 6GR. Kyocera RAN1 should study enhancements to data collection and data management tailored to the specific new use cases. NEC Proposal 8: Study unified framework for AI/ML for 6GR, ensuring high performance, security, and adaptability to all use cases in 6G, including ? Unified data collection framework ? Unified LCM framework 1.4 Others Other proposals on various topics were raised. SK telecom proposed to include fallback mechanism for AI/ML solutions to non-AI/ML which was also supported by a number of companies. The monitoring mechanism defined in 5G NR serves as starting point to discuss this fallback mechanism. Companies may propose additional enhancement for 6GR, if any. Other proposals discuss on the expectations, requirements of 6GR for AI/ML service. InterDigital proposed to initially focus the discussion on AI/ML framework before potential use case identification. Company Proposals InterDigital, Inc. Proposal 1: For 6GR AI/ML, RAN1 should initially focus on AI/ML framework. Proposal 2: For 6GR AI/ML, RAN1 can start work on identification of use cases for selected use cases and enhancements once the work on the conventional baseline has progressed sufficiently. Xiaomi Proposal 16: Define Standardized Power States within the AI/ML Framework * Define mechanisms to synchronize power states between the network and UE. * Define mechanisms to achieve an optimal balance between energy efficiency and service response delay. HONOR Proposal 1: For AI/ML in 6G Radio, two aspects should be considered: AI for 6G Radio and 6G Radio for AI. * AI for 6G Radio pertains to the application of AI technologies to assist networks and devices in delivering services defined by 3GPP. * 6G Radio for AI emphasizes how the system can facilitate and empower AI applications by utilizing the functionalities of 6G to offer various services. Proposal 2?For AI/ML in 6GR interface, study how to integrate the AI agent in the 6GR system at both UE and network, to improve network performance and user experience. SK Telecom Proposal 1. For 6G system with AI/ML, the unified fallback mechanism to non-AI/ML should be considered. 2 Use cases 2.1 Principle for use case selection Several companies mentioned to extend 5GA use case without duplicated evaluation, and selected new 6G use cases for both UE/NW side model, and shall considering the performance gain and complexity. Some companies want to prioritize one-sided use cases. No need to have special conclusion for this. Company Proposal Nokia [1] Proposal 2: RAN1 studies should focus on identifying promising new AI/ML-enabled use cases related to the physical layer for both UEs and the network, and on assessing the performance and complexity trade-offs of these use cases. * RAN1 shall coordinate with other WGs from the early stages of the study item to avoid misalignment of study outcomes across different WGs. Ericsson [5] Proposal 7 6GR Rel-20 study item should prioritize one-sided use cases which are easier to deploy and maintain in real life. Huawei/Hisi [6] As some selected use cases about AI/ML for air interface and NG-RAN have been studied in 5G NR, the following aspects can be considered for the study of use cases in 6GR to improve the performance of RAN at both NW side and UE side. * Time varying channel acquisition and prediction * Burst interference prediction and handling * Site-specific radio transmission optimization * Low complex and high performance receiver * Joint transceiver design across multiple L1 functions Proposal 3: Comprehensive comparison between non-AI and AI/ML-based air-interface enhancement solutions is necessary to justify the advantages, at least in terms of system performance, system overhead, computational complexity, and power consumption. * Fallback from AI/ML-based solution to the corresponding non-AI solution should be supported. * Proposal 4: For the study of a use case with both one-sided and two-sided model solutions, comprehensive comparison between one-sided and two-sided models should be considered at least on system performance, system overhead, computational complexity, and power consumption. Proposal 5: AI/ML for air-interface enhancement in 6G should consider directions including AI/ML based CSI acquisition enhancement and data transmission enhancement. * Use case categorization can be considered for the use cases, e.g., from the perspective of one-sided model and two-sided model solutions, or the perspective of single function and multiple functions solutions. Google [7] Proposal 1: The following principles should be considered for AI/ML use case selection * The AI/ML use case should provide clear benefit compared to existing mechanisms in terms of the performance improvement, overhead reduction, power saving, and latency reduction * The AI/ML use case does not rely on time-variance property * The evaluation for the AI/ML use case is based on multiple types of channels from the system level simulation or channels from the field * One-side model is prioritized with regard to the possibility for deployment Vivo [9] Proposal 1: 6G AIML evaluation methodology need to be established for evaluating use case performance, complexity and power consumption. Proposal 6: The first three meetings in RAN1 for AIML study should target for use case clarification and categorization. Proposal 24: Use cases already studied in 5G-A era do not need further study in Rel-20 6G SI, but can be directly considered during scoping of 6G WI. Xiaomi [10] Proposal 1: * Selected use cases should achieve an optimal trade-off among performance gain, complexity, and power consumption. * Candidate use cases for selection can be categorized as: 5GA-supported use cases, extensions of 5GA use cases, and new use cases. Distinct approaches should be applied to handle each type. ZTE, Sanechips [12] Proposal 1: 6G is envisioned as a Smart Radio capable of supporting native AI with the following design principles: * 6GR is designed with flexibility to accommodate both AI-based solution and non-AI-based solution * 6GR prioritizes the AI/ML use cases with compelling trade-off between performance and complexity Proposal. 2. RAN1 strives to deliver an AI enhanced Efficient, Green and Autonomous 6G air interface. Samsung [14] Proposal 7: Leverage the NR’s study outcome for 6GR study on AI/ML for the air interface with potential extensions for some of the use cases. Proposal 8: For the study on AI based CSI compression, the following should be considered: • UE complexity handling: e.g., NW-sided model, compatibility to non-AI/ML capable UEs • New UCI structure: e.g., for JSCM • Explicit channel feedback: e.g., full channel matrices, or eigenvectors and eigenvalues Proposal 9: Study CSI-RS overhead reduction with AI/ML based CSI prediction over the time/frequency/spatial and beam domains, including wide frequency range prediction. Proposal 10: AI/ML for PA nonlinearity handling can be studied as one use case which benefits from online training/finetuning. Proposal 11: Explore more use cases, e.g., PAPR reduction with two-sided model, especially with standardized (reference) model. Lenovo [19] Proposal 1: 6G PHY, from Day 1, should support the “possibility” of substituting/replacing conventional modules in the transmit-receive chain with AI models/modules (either with single-sided or two-sided AI modules). The substitution/standardization of different AI modules, however, can happen gradually during different releases. OPPO[20] Proposal 1: Consider the following principles to select AI/ML use cases for 6GR study • Prioritization of AI/ML-Intrinsic design that significantly enhances the basic components of the transceiver chain of 6GR • Significant performance benefits for intermediate metrics (e.g. SGCS, NMSE, or predication accuracy) and final metrics (e.g. BLER or throughput) over legacy non-AI schemes • Well-balanced tradeoff among performance benefits, computation complexity and power consumption Interdigital [25] Proposal 3: For R20 6GR AI/ML, focus on AI/ML use cases that show compelling benefits using a clear performance baseline including a 6GR non-AI/ML baseline when applicable. Proposal 8: RAN1 to determine a subset of AI/ML use cases for further study, based on potential performance/complexity trade-off and on the timing for defining a baseline. Proposal 9: RAN1 will down-select to a set of AI/ML use cases for study in Rel-20 based on the results of a full performance/complexity analysis using their respectively identified baseline. Fujitsu [29] Proposal 1: * For AI/ML in 6GR, the use cases supported in 5G-Adv should also be supported in 6G and the design in 5G-Advanced could be baseline for 6G o If enhancement for certain use case is needed on top of the design in 5G-Adv, then it could be studied in 6G o If enhancement is not needed on top of the design in 5G-Adv, then it could be specified in 6G * For AI/ML in 6GR, new use cases on physical layer processing could be considered by RAN1 o Both one-sided model and two-sided model could be considered in 6G design AT&T Proposal 5: For 6GR design, consider use cases that provide high impact practical relevance to the operators DCM [41] Proposal 1 - For the initial phase of 6G, prioritize the study of use cases with the one-sided model, considering the easy commercial deployment and commercial demands. > New use cases for 6G and the use cases enhanced from 5GA can be studied based on the potential benefits of transmission efficiency, sustainability, and user experiences. Proposal 2 - Avoid duplicated work between 6G and 5GA AI/ML on the two-sided model. > The complexity of practical deployments of the two-sided model should be investigated after the completeness of the Rel-20 5GA AI/ML work item. The study on use cases with the two-sided model can be deprioritized in this SI. {Indian Institute of Tech (M), IIT Kanpur}*[42] Proposal 4: For all use cases considered for 6G study, parallel comparison with legacy non-AI/ML approaches should be included. Proposal 5: For all use cases considered for 6G study, appropriate signaling and configurations for fallback to non-AI/ML approaches should be included. NEC [28] In 6GR air interface, AI/ML can be integrated seamlessly across all components of the communication system. As a starting point, RAN1 can select use cases by ? Identifying existing 5GA use cases and their extensions to be supported in 6G, such as AI/ML BM for MTRP, CSI compression with time-domain aspects ? Studying new use cases on performance and cost, such as AI/ML based RS overhead reduction ? Studying new use cases with which the traditional communication block can be enhanced or replaced by AI/ML models, such as AI/ML based channel estimation ? Studying new use cases by considering joint AI/ML processing of multiple functionalities, such as joint modulation and precoding, joint channel estimation and demodulation 2.2 5GA use cases and extension Most of companies suggest to consider 5GA use case with some extensions and avoid re-study. Conclusion 2.2-1: 5GA use cases and the corresponding study outcome can be directly considered for 6GR system design, including: beam management, positioning, CSI prediction, and CSI compression. Company Comment FL Please note that, only “study outcome”, which means observations/conclusions in SI phase, not 5GNR spec Google We do not see the need to consider positioning and CSI compression for 6G. Ofinno Fine MTK Suggest including “as baseline” in the wording as follows: “5GA use cases and the corresponding study outcome can be directly considered as baseline for 6GR system design, including beam management, positioning, CSI prediction, and CSI compression.” Sharp We wonder whether the conclusion would be applied for RAN2 use case, e.g. mobility. That is to say, does this conclusion preclude RAN2 use case? Furthermore, does “study outcome” refer to TR(38.843)? Fainity For the positioning use case, it may have more impact on RAN2 and RAN3. We don’t think this use case needs to be discussed in RAN1.  Lenovo Support CATT, CICTCI We notice that the current wording is soft, and hence no harm. Possibly, 6G non-AI/ML baseline will be improved so the value of each 5G-A use cases may be different. However, the proposal just mention ‘considered’, not ‘supported’. Perhaps the supplementary information from FL can also be captured in the conclusion: 5GA use cases and the corresponding study outcome (e.g. observations, conclusions, etc. in TR 38.843) can be directly considered for 6GR system design, including: beam management, positioning, CSI prediction, and CSI compression. SK Telecom Since we do not see the huge need on some of 5GA use cases, we are not sure about the conclusion. I guess we need to make a decision on whether all 5GA use cases will be the scope of 6G AI/ML. If not, then the conclusion 2.2-1 needs to be somewhat revised. CMCC We think whether to adopt these 5G-A use cases is also related to whether the corresponding non-AI technology is introduced in 6G. NVIDIA We support considering 5GA use cases for 6GR system including beam management, positioning, CSI prediction, and CSI compression. Fujitsu Regarding the “study outcome”, during work item phase, some options/solutions in study phase may be down-selected. With the current formulation, does it mean those down-selected options still could be considered in 6G study? If so, it may take extra efforts and additional work load. Nokia Proposal is not fully clear, especially the mentioning of the use-cases. We do not think positioning is a 6GR use-case. We suggest the following update, Updated Conclusion 2.2-1: 5GA use cases and the corresponding study outcome can be directly considered for 6GR AI/ML discussions. Adopt 5GA use cases : beam management, CSI prediction, and CSI compression also for 6GR. ZTE We are supportive of this general principle. However, we are not sure whether AI-based positioning enhancement will be included in 6G. Huawei, HiSilicon CSI and BM are fine. Not sure whether positioning should be 6G day one feature. Ericsson Updated version on top of CATT/CICTCI version: Proposal 2.2-1A: If the configurations and evaluation assumptions are applicable and valid in the context of 6GR, 5GA use cases and the corresponding study outcome (i.e., observations, conclusions, etc. in TR 38.843) can be directly considered for 6GR system design without repeating the evaluations, including: beam management, positioning, and CSI prediction, and CSI compression. Note that the first release of 6G should focus on one sided use cases. NEC Support this direction Panasonic Fine. NTT DOCOMO Fine Xiaomi We share similar view with CMCC that whether support these 5G-A use cases depends on relted non-AI counterpart is introduced in 6G. For positioning, now it is not clear whether to support it in 6G Day 1. Thus, whether consider AI-based positioning in 6G should be FFS QC It is sensible that for aspects that have been already studied (but not specified) in 5GA, the study outcome can be leveraged in 6GR, and a duplicate study is not needed. With regards to 5GA use cases that have been or will be specified in 5GA, it should be clarified whether they should be Day-1 6G features, which is not clear from the above wording of “can be directly considered for 6GR system design”. LGE Generally OK, but for positioning, we are not sure that this feature can be supported in 6G Day 1. So, Nokia’s revision seems fine for us. OPPO First, we would better mention the study outcome is according to TR 38.843. Second, along with a few other companies, we don’t think positioning should be the 6GR day one feature. ETRI Support, 6G may support 5GA use cases, but re-studying of 5GA use cases should be avoided. Spreadtrum It should be clarified that "directly considered for 6GR system design" means that we can skip the simulation stage and directly proceed with the standardization work. InterDigital We do not support this conclusion as observations made in 5G study are based on the 5G framework and baseline used in the 5G study. We may have different baseline in 6G and observations may potentially be different. CEWiT Our understanding of the proposal is that the use cases from 5GA are mature enough to be taken up without a study in 6GR, considering the use cases are adapted in 6GR. In that sense, positioning has already been agreed as a part of the existing services from NR to 6GR. So it is obvious for us to consider positioning as a part of the use cases to be considered as a part of 6GR Since the conclusion is not limited to the use cases adapted as a part of 6GR - Day1, it simple conveys the use cases to be taken up in 6GR, not necessarily as a Day1 feature. Considering the comments of most of the companies, we propose to add a note saying “Note : Positioning use case may not be considered as a day1 feature” TCL support Futurewei 5G related study outcome can be considered to save some efforts. However, it does not mean these 5G use cases will automatically be included for 6G normative work. vivo Support Tejas Support AT&T Not sure that all 5GA use cases should be considered for 6GR but some use cases along with the learnings from these use cases from 5GA, given the evaluation assumptions, and the system design, can be reconsidered for 6GR IIT Madras 5GA use cases can be extended with the flexibility to reconsider if the non AI/ML baseline is changed with 6G assumptions. Samsung Fine with the proposal from FL. 2.2.1 Extension on AI/ML for beam management New sub-use cases Proposed companies inter-cell beam prediction/M-TRP or LTM (5) Nokia, xiaomi, BJTU, ZTE/Sanechips, Qualcomm, (5) CATT/CICTCI *, Samsung *, NEC*?Honor*, DoCoMo*(RAN 2-led), LGE Tx-Rx beam pair prediction (1) Nokia (1) NEC* RL-based beam prediction (1) Nokia Cross-frequency beam prediction (3) Futurewei, xiaomi, Apple? (4) CATT/CICTCI *, China Telecom *?LGE*, Honor* Beam selection during initial access (9) CATT/CICTCI *, vivo *, ZTE/SANECHIPS*, Samsung*, LGE*? , NEC*,Qualcomm*, DoCoMo*, Ofinno BFR (5) CATT/CICTCI *LGE*, Fujitsu * NEC*?Honor* Beam prediction with UEI (1) Samsung * Fast TCI (1) NEC* Beam management for HST (1) BJTU * Beam management in hybrid beamforming and distributed MIMO (1) NVIDIA* Beam steering based BM (1) Fujitsu* * without simulation results Some extension on beam management were proposed, as summarized in above table. Some of them were specification design and no need to have additional evaluation, e.g., UEI, Fast TCI, while some of them may need some additional evaluations. Conclusion 2.2.1-1: In related study (e.g., MIMO, Initial access), AI/ML based beam management with DL Tx beam spatial/time domain prediction can be assumed as feasible. Company Comment Google OK, we think we should clarify this also includes AI/ML based RSRP prediction. Ofinno Fine Sharp Generally support. In our understanding, we don’t think “In related study” is needed in the conclusion, since anyway if feasible, the use case would be incorporated in related aspect of 6GR. Fainity Support Lenovo It is too vague saying the related study. In Rel-18/19, RAN studied AI/ML based BM in connected mode only. At least the extension to initial access needs to be further studied with evaluation before we assume it is feasible. CATT, CICTCI Maybe not wrong, but we should be more careful on the assumption, for example, the conclusion is only hold when considering 6G in the same FR (FR2-1) as in 5G-A? Otherwise, performance evaluation may still be needed, such as in ~7 GHz. CMCC At least for AI/ML based beam management in initial access, the feasibility of it is much related with non-AI deign of 6G initial access. We suggest to discuss AI and non-AI methods together in initial access agenda. Here is suggested revised version: Conclusion 2.2.1-1: In related study (e.g., MIMO, Initial access), AI/ML based beam management with DL Tx beam spatial/time domain prediction can be considered. Fujitsu Generally fine. Nokia The proposal is not clear. Also, it is too early to declare feasibility of new use-cases. ZTE Supportive of this proposal. Huawei, HiSilicon Study these BM related extension is fine, but draw the conclusion of “feasible” is too early without knowing what are the exact study case. Ericsson Prefer CMCC version. We don’t believe the feasibility can be assumed without careful study. NEC Support this direction Panasonic Fine NTT DOCOMO Fine. If the outcomes of Rel-19 AI4Mobility are considered, the frequency domain prediction can also be assumed as feasible. Xiaomi Share same view as google that suggest to include both DL Tx beam and L1-RSRP prediction. QC A few comments below: * We believe the focus of Section 2.2 should be on what can be leveraged from 5GA, and Extensions of 5GA use cases should be discussed in Section 2.3, along with new use cases. o The current formulation of 5GA use cases is not consistent. For instance, BM extensions are included in Section 2.2.1 while CSI compression extensions are discussed in Section 2.3.3. o Why do we not have a similar conclusion for the other 5GA use cases, i.e., CSI prediction, CSI compression, positioning? LGE We are generally fine with this direction. But, as mentioned by other companies, it is too early to say feasibility. In that sense, CMCC’s revision looks better. ETRI Support, 5GA use cases may be supported in 6GR. Spreadtrum We believe that it is OK to further study the cases related to BM, but we cannot simply assume that these cases are feasible. InterDigital We would like to know the intention of this conclusion. We have a similar view as HW. CEWiT We also prefer CMCC’s proposal. TCL support Futurewei We do not see the need to conclude on this now. The beam management and initial access itself is under study. vivo Directly stating feasible might be too early. AT&T Feasibility assumption is too early to determine. Samsung Fine with the proposal from FL and it should be ok to add L1-RSRP prediction. Conclusion 2.2.1-2: Discussion on whether to support study on additional subcases/scenarios for beam management or directly extend the observations/conclusions from DL TX beam prediction, at least including: * Inter-cell beam prediction/M-TRP beam prediction * LTM * BFR * Inter-frequency beam prediction * Tx-Rx pair prediction * Beam management in hybrid beamforming and distributed MIMO Company Comment Google We do not see the necessity for the last bullet. The technical aspect is also unclear. Suggest removing it for now. In addition, we think the beam prediction with UEI can be added. FL I didn’t add UEI is because that is related to specification design other than the application of the study outcome to a certain scenarios. Whether 6GR will support UEI or not can be decided up to MIMO, but of course, with previous proposed conclusion, MIMO design can take into consider of predicted results. Sharp Support Vodafone We propose to study beam management for NES. Specifically for spatial domain adaptation, by activating/deactivating antenna ports it will impact the shape of the beams that are transmitted by the base station, and beam selection optimized for network energy saving may benefit from the AI/ML framework Fainity Agree with this conclusion. In 6G, AI/ML based beam management/beam prediction should be applied for more corresponding use cases.  Lenovo Seems some of the cases only supported by a single company. It is better to agree on the case with majority support and further study the case with less support so far. At least the inter-cell beam prediction/M-TRP beam prediction and the inter-frequency beam prediction needs to be studied as they are based on different conditions than what we have in Rel-18/19. CATT, CICTCI For the last bullet, can we clarify how AI/ML is used for beam management under this assumptions (hybrid BF and distributed MIMO)? Intuitively, the first one is the same as R19 AI/ML BM, and the second one is the same as ‘Inter-cell beam prediction/M-TRP beam prediction’, the first bullet? CMCC Open to study these extensions for beam management in 6G except Tx-Rx pair prediction. We have studied it in Rel-18 AI BM study with fruitful evaluations, but finally we only specified Tx beam prediction with Rx beam left to UE implementation. We think reconsidering it in 6G is not needed. Fujitsu We propose to study beam steering based BM in 6G. The legacy BM is based on beam sweeping, which require multiple steps from signalling perspective. With beam steering based BM, the DL Tx beam could be derived by the gNB with AI/ML based on measurement on uplink signal. Correspondingly, there is no need to perform beam sweeping and beam reporting which could further reduce signalling overhead. Nokia This looks like listing all company proposals. We do not agree with such an approach. We shall only list one or two use-cases based on some sort of criteria. For BM, it would be good to list use-cases that supported/evaluated by many companies and solving a unique problem (especially if the problem is not or cannot be handled by Rel-19 AI BM). Updated Conclusion 2.2.1-2: Further evaluate and discuss the following use-cases before considering them as potential 6GR AI/ML use-cases: * Inter-cell beam prediction/M-TRP beam prediction * Beam prediction during initial access * Beam selection with continuous learning ZTE Regarding the Tx-Rx pair prediction, it has been discussed in Rel-18 and was ruled out due to the huge controversy. If companies haven’t changed their minds, we propose to remove this one. Regarding the last bullet, can the proponents clarify the detailed use case for “Beam management in hybrid beamforming and distributed MIMO”. Ericsson Suggest the updated version below: Proposal 2.2.1-2A: For new beam management related use cases, RAN1 discuss whether to support perform fresh study (i.e., make new observations/conclusions) on the subcases/scenarios for beam management or directly extend the existing observations/conclusions from 5G DL TX beam prediction in 38.843. The candidate list of new beam management related use cases include : * Inter-cell beam prediction/M-TRP beam prediction * LTM * BFR * Inter-frequency beam prediction * Tx-Rx pair prediction * Beam management in hybrid beamforming and distributed MIMO * UE initiated BM NEC Support this direction Panasonic Support NTT DOCOMO Fine to study. LTM may be an RAN2-led topic considering the framework of 5G AI/ML for mobility. Xiaomi We suggest to divide ‘Inter-cell beam prediction/M-TRP beam prediction’ into two separate two sub-bullets like below, since M-TRP beam prediction means group-based beam prediction. * Inter-cell beam prediction * M-TRP beam prediction In addition, regarding the last sub-bullet, we don’t think it is needed since there is no difference compared to R19 AI based beam management. QC * As mentioned above, we believe this conclusion and related discussions should be placed in Section 2.3, not here. * The last bullet and AI/ML role in it need to be clarified. LGE Support OPPO To make the study list more inclusive, could we add two additional sub-use cases for the group to consider? Conclusion 2.2.1-2: Discussion on whether to support study on additional subcases/scenarios for beam management or directly extend the observations/conclusions from DL TX beam prediction, at least including: * Inter-cell beam prediction/M-TRP beam prediction * LTM * BFR * Inter-frequency beam prediction * Tx-Rx pair prediction * Beam management in hybrid beamforming and distributed MIMO * Group-based beam reporting * L1-SINR based beam reporting ETRI Support the direction of studying additional subcases/scenarios for beam management, though further refinement of the details may be needed. Spreadtrum For the prediction of Tx-Rx pairs, we believe that there is no need to have the same repetitive discussion as that of R18. Following the rule of not disclosing the Rx beam, this use case should not be discussed in 6G either. For Beam management in hybrid beamforming and distributed MIMO, we are not very clear about the approach of this use case. If we need to consider this use case, further clarification is required. InterDigital We would like to propose the following change. It is not clear about the observations we are trying to extend. Discussion on whether to support study on additional subcases/scenarios for beam management or directly extend the observations/conclusions from DL TX beam prediction, at least including: CEWiT We are generally ok with the motivation. But for LTM, we believe the framework in not yet defined in 6GR and it is too early to assume we will adapt the same as in 5G. Especially with proposals to have unified BM and mobility, it is too early to include LTM in the list. TCL support Futurewei General direction is ok but not all sub use cases should be considered for study. vivo Fine to study. Better to clarify each sub-use cases, e.g., what is difference between distributed MIMO and M-TRP beam prediction Samsung Fine with FL conclusion in principle. Ok to remove Tx-Rx pair prediction based on 5G NR study outcome 2.2.2 CSI enhancement New sub-use cases Proposed companies spatial-frequency-temporal CSI compression. NVIDIA * for network-side CSI prediction with SRS. NVIDIA * Joint CSI prediction and compression Panasonic *, NEC* SRS + CSI compression LGE* Some use cases are proposed. However, I feel that all of them can be covered by general conclusion 2.2-1. I don’t see the point to re-study it again, any different view? Question 2.2.2-1: What is additional use case that hasn’t been studied in 5GA for CSI prediction and CSI compression with separate source and channel coding with 2-sided model? Company Comment FL Please share your view. Google Based on what we studied in 5G, AI/ML is feasible for CSI prediction. We propose to consider AI/ML based CSI dwelling time prediction, which is based on the capability of CSI prediction. MTK Since CSI prediction and CSI compression are listed under “New use cases” in 2.3.1 and 2.3.3, we wish to clarify the reason for question 2.2.2-1. Is 2.3.1 and 2.3.3 not meant to include use cases with separate source and channel coding with 2-sided model? Lenovo For the first and the third one, we think they may correspond to case 2/3 in 5GA study. Not sure the combination of SRS for the second and the fourth one have a solid study in 5GA. NVIDIA Only UE-side CSI prediction is studied in 5GA. We propose to consider network-side CSI prediction in 6G, based on SRS (e.g., with SRS overhead reduction) Nokia We do not see any need of discussing any of above use-cases on CSI enhancement. Ericsson Not clear why emphasizing “with separate source and channel coding with 2-sided model” NEC Combination with SRS may not be treated as a studied use case. Panasonic We think one of use cases that hasn’t been studied in 5GA is NW-side model for CSI prediction. We think NW-side model for CSI prediction would be more useful than UE-side model. This is because NW is more powerful than UE and NW may deploy a high-complexity model to predict CSI. UE is not required to deploy AI/ML processing. In addition, there is no need for disclose NW side additional conditions. QC Spatial-frequency-temporal CSI compression and Joint CSI prediction and compression have already been studied and conclusions have been captured in the TR. They can be directly specified in 6GR without further study. For CSI prediction: CSI prediction only considers predicting the channel characteristics. What is missing from 5GA is prediction of interference, which can be helpful as it is eventually both the channel and interference that matter for the predicted instances, not the channel alone. LGE CSI prediction based on NW sided model, or CSI compression applied in TDD scenario can be considered. Futurewei 2.2.3 Positioning New sub-use cases Proposed companies joint sensing and positioning, channel charting, and speed/doppler estimation. NVIDIA * Based on AI/ML-based mobility/positioning or non-AI/ML-based positioning, NW may predict/determine location of UE and map it into sensing map. Panasonic * Positioning and sensing Qualcomm * Some use cases are proposed without any evaluation result. If some particular use case as positioning extension, companies are encouraged to provide use case description, evaluation assumptions and results, as well as the impact on LCM and other spec impact. 2.3 New use cases 2.3.1 CSI prediction and CSI-RS overhead reduction Use case definition Sub-use case Model location Views (a) Spatial and/or frequency domain (b) Cross-frequency 1,2,4,5 (c) Cross-beam CSI prediction for FR3 1,2,3 (d) Spatial/freq/time 6,7 (e) RS pattern design 1 Samsung 2 NTU* 3 NVIDIA, 4 LGE 5 Apple* 6 Honor* 7 MediaTek 8. Huawei/HiSi * (a)UE-sided model (b) NW-sided model 1,2 1 Qualcomm 2 {CEWiT, IITM, Tejas Network, IITK} 3. ZTE (c) Two-sided model 3 3 Huawei/HiSi*; Joint RS pattern and channel estimation (17) Nokia, Spreadtrum/UNISOC, Ericsson, Google, CATT/CICTCI, vivo, xiaomi, ZTE/Sanechips, Samsung, BJTU, Fujitsu, Lenovo, OPPO, LGE, NVIDIA, Qualcomm, DoCoMo (17) Huawei/HiSi *, TCL*, CT*, {Tejas Network Limited, CEWiT, IIT Madras, IISC Bangalore, IIT Kanpur}*, Panasonic*?NTU*, Apple*, NEC*, Honor*, MediaTek *, ETRI*, CMCC*, Sony*,SKT*,AT&T*, {Indian Institute of Tech (M), IIT Kanpur}*, Rakuten* * without simulation results 34 contributions proposed to study CSI-RS overhead reduction, wherein 17 of them provided preliminary simulation results. Most of companies assume CSI-RS overhead reduction is a UE-sided model. Three contributions (Qualcomm, {CEWiT, IITM, Tejas Network, IITK }, ZTE) mentioned NW-sided model can be considered. One contribution (Huawei/HiSi) mentioned 2-sided model for joint CSI-RS pattern and channel estimation. All companies support spatial and/or frequency domain CSI-RS overhead reduction. With AI at UE-sided model, there is minor/no SGCS/NMSE loss of predicted CSI compared with high CSI-RS overhead, and SGCS/NMSE gain can be observed comparing with non-AI based channel estimation for CSI calculation. In addition, 2 companies (Honor and MediaTek) mentioned spatial/frequency and time domain prediction. 4 companies (Samsung, NTU, LGE, Apple) proposed to support cross- frequency CSI prediction. One company provide some preliminary results, that shows decent results in terms of SCGS for wideband CSI. 3 companies (Samsung, NTU, NVIDIA) proposed to support cross-beam CSI prediction for FR3 (analog beam and digital precoding). One company provided some preliminary results, that shows decent results in terms of SCGS for CSI prediction cross-beams. 1 contribution (Huawei/HiSi) mentioned RS pattern design or RS pattern design and channel estimation with 2-sided model. However, one contribution (Qualcomm) mentioned CSI-RS pattern/schemes allow lower complexity are preferred: Main KPI The following KPI were proposed/used for the evaluation: - SGCS/NMSE - Spectrum efficiency - Throughput - Model complexity Proposal 3.3.1-1: For 6GR AI/ML, support the study on CSI prediction and CSI-RS pattern design at least with UE-sided model, at least including the following with potential down selection: - sparse CSI-RS design with less overhead in spatial and/or frequency domain, - cross-frequency range CSI prediction, - cross-beam domain CSI prediction for FR3, if applicable Time domain CSI prediction can be additionally considered in the study. Company Comment Google We think the time-domain overhead reduction can also be included. This should be a low-hanging fruit with regard to the feasibility of CSI prediction proved in 5G. FL @google, I haven’t see much results from companies to show the results with larger periodicity than the max values supported by NR, as the measurement input, if this is what you mean. With current formulation, nothing is precluded. I think we will study and design those parameters later in future study. If your intention is time domain prediction in the future, that can be covered by the last bullets. MTK We wish to add “cross-antenna ports and/or antenna panels” and “use of multiple RS types for CSI-RS overhead reduction” as sub-use cases for CSI prediction. Fainity Support. Lenovo Generally, we are fine with this proposal. For first sub-bullet, the less CSI-RS overhead would not be represented in spatial domain, rather than in time-frequency resource, e.g., OFDM symbol and/or RE. Suggest to revise: For 6GR AI/ML, support the study on CSI prediction and CSI-RS pattern design at least with UE-sided model, at least including the following with potential down selection: - sparse CSI-RS design to support spatial and/or frequency domain CSI prediction with less overhead in spatial and/or frequency domain, - cross-frequency range CSI prediction, - cross-beam domain CSI prediction for FR3, if applicable Time domain CSI prediction can be additionally considered in the study. CATT, CICTCI Support. SK Telecom Support the proposal. We are interested in CSI prediction and CSI-RS overhead reduction with AI/ML. Regarding the second sub-bullet, it would be better to remove ‘range’. One question to FL would be: is there any reason to prioritize spatial/frequency domain over time domain for sparse CSI-RS design? CMCC Support. But not sure why only FR3 is considered for cross-beam domain CSI prediction. NVIDIA We support study on CSI prediction and CSI-RS pattern design, covering spatial, frequency, and time domain with same priority. Network-sided model can be additionally considered in the study. Fujitsu We also think sparse CSI-RS design in time domain should be considered as well. In Rel-19, the 128-port CSI-RS could be aggregated by 4 32-port CSI-RS over two slots. Considering larger number of ports for CSI-RS, e.g., 256 ports, sparse CSI-RS design in frequency domain and time domain could be considered jointly. The cross-frequency range prediction and cross-beam domain prediction should be separate use case from sparse CSI-RS design. The legacy pattern may be used for the cross-frequency range prediction and cross-beam domain prediction. Nokia We can simplify the wording to be clear with the message. Also, similar to what is mentioned before under BM, RAN1 shall not focus much on solving the same problems (that already resolved in Rel19/20 CSI use-cases). We do not see much support on CSI prediction in F domain, and it is not in the same level as CSI-RS overhead reduction use-case. Updated Proposal 3.3.1-1: For 6GR AI/ML, support the study on CSI-RS pattern design (overhead reduction) at least with UE-sided model- , ZTE We are also supportive of NW-sided model for CSI prediction and two-sided model for CSI prediction. * NW-sided model: e.g., UE reports the channel matrix for 32 ports to the base station, then AI model at the base station can predict the CSI for 64 ports. * Two-sided model: UE reports the compressed CSI for 32 ports to the base station, then the AI model at the base station can perform the decompression and prediction for 64 ports. Regarding the “cross-beam domain CSI prediction for FR3”, we suggest to delete “for FR3” to make the solution more general. Huawei, HiSilicon Firstly, we do not think we should jump into the detailed per use case discussion in the first meeting. 6G is AI native; after three meetings, there should be plenty of AI driven use cases (rather than down selected to a limited use cases of CSI, DMRS, etc.) assigning to other agendas (modulation, MIMO, data channel, etc.) Therefore, the first step we should do is to perform appropriate categorization of the potential use cases, so that it helps us to understand which potential use case should be assigned to which agenda. Thus, we provide a generic proposal for use case categorization: For 6GR AI/ML, support the study on the following directions: 1. CSI prediction and CSI-RS/SRS overhead reduction 2. DMRS design with AI receiver/transceiver 3. AI compression for CSI/HARQ/DCI/TPMI 4. AI for modulation and demodulation 5. AI for PA non-linearity handling 6. AI for ISAC 7. NET4AI related use case, e.g., token communication 8. AI for NES 9. AI for prediction other than CSI: interference prediction, LLM-Based Prediction of Measurement Events, Anomaly detection and fault prediction, traffic prediction and DRX, 10. AI for control (decision): power control, AI for link adaptation /MCS selection, AI-powered adaptive frame structure, Spectrum Sensing For this single use case (CSI prediction/pattern design), we think we do not need to limit the model side at this stage. For 6GR AI/ML, support the study on CSI prediction and CSI-RS pattern design at least with UE-sided model, at least including the following with potential down selection: - sparse CSI-RS design with less overhead in spatial and/or frequency domain, - cross-frequency range CSI prediction, - cross-beam domain CSI prediction for FR3, if applicable Time domain CSI prediction can be additionally considered in the study. Ericsson We suggest to start with the first bullet only: “sparse CSI-RS design with less overhead in spatial and/or frequency domain” We think ‘CSI-RS pattern design’ in the main bullet should be replaced by ‘CSI-RS overhead reduction’. Note that CSI-RS pattern design will be a fundamental discussion in the RS agenda items later on. Suggested revision: Proposal 3.3.1-1A: For 6GR AI/ML, support the study on CSI prediction and CSI-RS overhead reduction at least with UE-sided model. The starting point for the study is: - sparse CSI-RS design with less overhead in spatial and/or frequency domain, - cross-frequency range CSI prediction, - cross-beam domain CSI prediction for FR3, if applicable Time domain CSI prediction can be additionally considered in the study. NEC To our understanding, time domain CSI prediction needs no further study, which is part of 5G NR AI/ML. NTT DOCOMO Suggest changing cross-frequency range to cross-frequency band/range. The cross-frequency range prediction means things like using FR1 measurements to predict FR2 ones, which is too narrow. Xiaomi * Regarding the 2nd sub-bullet, we are not clear why to restrict to different frequency range? Why to preclude the case that predict CSI on CC2 based on measurement of CC1 in the same frequency range? * Regarding the 3rd sub-bullet, why to restrict to FR3 only? We suggest to delete ‘FR3’ and open to any frequency range. So, we suggest the following the update: Proposal 3.3.1-1: For 6GR AI/ML, support the study on CSI prediction and CSI-RS pattern design at least with UE-sided model, at least including the following with potential down selection: - sparse CSI-RS with less overhead in spatial and/or frequency domain, - cross-frequency CSI prediction, - cross-beam domain CSI prediction, if applicable Finally, for the last sentence, please clarify the difference of ‘Time domain CSI prediction’ compared to R19 AI based CSI prediction. QC * At this stage, we should not prioritize/recommend use cases for study. Rather, we should identify and summarize aspects that can be studied for each use case. * We should not restrict to UE-sided models in the main bullet and rather keep options open at this stage. * Second bullet is updated below to make it inclusive by removing “range” from frequency range. * Third bullet needs more discussion, and why is it applicable to only FR3? Suggest the following updates: Updated Proposal 3.3.1-1: For 6GR AI/ML, support the study on consider the following aspects for CSI prediction and CSI-RS pattern design at least with UE-sided model, at least including the following with potential down selection: - sparse CSI-RS design with less overhead in spatial and/or frequency domain, - cross-frequency range CSI prediction, - cross-beam domain CSI prediction for FR3, if applicable Time domain CSI prediction can be additionally considered in the study. Note: UE-sided model, NW-sided model, and/or two-sided models can be considered in study. LGE We are generally fine with this direction. For 2nd bullet, we don’t think it is necessary to limit the granularity of cross-frequency CSI prediction to FR and we support to study on which frequency levels (e.g. CC, BWP, etc.) can be supported. For 3rd bullet, what is the meaning of cross-beam domain prediction? Does it include inter-cell prediction? Based on above, our suggestion can be as follows: Proposal 3.3.1-1: For 6GR AI/ML, support the study on CSI prediction and CSI-RS pattern design at least with UE-sided model, at least including the following with potential down selection: - sparse CSI-RS design with less overhead in spatial and/or frequency domain, - cross-frequency CSI prediction, - cross-beam domain CSI prediction for FR3, if applicable Time domain CSI prediction can be additionally considered in the study. OPPO First, we think the motivation targets for the CSI-RS overhead reduction, rather than CSI-RS pattern design which belongs to MIMO scope (to be started later on). Hence, we suggest the following change. Proposal 3.3.1-1: For 6GR AI/ML, support the study on CSI prediction and CSI-RS overhead reduction pattern design at least with UE-sided model, at least including the following with potential down selection: - sparse CSI-RS design with less overhead in spatial and/or frequency domain, - cross-frequency range CSI prediction, - cross-beam domain CSI prediction for FR3, if applicable Time domain CSI prediction can be additionally considered in the study. Regarding HW’s comments, we think that’s quite inclusive, and we sympathize the direction in the very first meeting of 6GR to be widely open. Perhaps we don’t have to mention any potential down selection at all. ETRI Support to study above mentioned cases Spreadtrum We prefer to divide CSI prediction and CSI-RS pattern design into two use cases and it is not necessary to discuss the details in this meeting. And we also think the ‘CSI-RS pattern design’ should be replaced by ‘CSI-RS overhead reduction’ in main bullet. There is no need to limit the study scope listed in the sub-bullets. Suggested revision: 2.3.0 CSI prediction Proposal 3.3.0-1: For 6GR AI/ML, support the study on CSI prediction at least with UE-sided mode. 2.3.1 CSI prediction and CSI-RS overhead reduction CSI-RS pattern design Updated Proposal 3.3.1-1: For 6GR AI/ML, support the study on CSI prediction and CSI-RS pattern design at least with UE-sided model. , at least including the following with potential down selection: - sparse CSI-RS design with less overhead in spatial and/or frequency domain, - cross-frequency range CSI prediction, - cross-beam domain CSI prediction for FR3, if applicable Time domain CSI prediction can be additionally considered in the study. CEWiT Ok with the proposal TCL support Futurewei Though we support CSI-RS related use case, we don’t think it should be combined with CSI prediction use case. In addition, it is too early to narrow down into specific (sub-)use case without proper study. vivo Support Huawei’s general comments. Directly categorizing use cases as major use cases and as others is too hasty based on counting number of proponents. Observation on gains and complexity of use cases should be firstly conducted across companies, before categorizing use cases to major use cases and other use cases. We are also fine with Huawei’s categorization of the AIML for RAN1 study directions. Specifically for this proposal. We would like to CSI prediction for different shut down patterns for NES. Proposal 3.3.1-1: For 6GR AI/ML, support the study on CSI prediction and CSI-RS pattern design at least with UE-sided model, at least including the following with potential down selection: - sparse CSI-RS design with less overhead in spatial and/or frequency domain, - cross-frequency range CSI prediction, - cross-beam domain CSI prediction for FR3, if applicable - cross NES shut-down pattern CSI prediction - inter-UE/inter-cell interference prediction Time domain CSI prediction can be additionally considered in the study. IITK We are fine with the proposal. CMCC2 We agree with Huawei that it is premature to label use cases as 'major' based only on proponent count. Cross-checking among companies for the benefits and complexities of use cases could be performed firstly. We also support Huawei's suggested study directions for AIML in RAN1. About use case categorization, some update based on Huawei’s version: For 6GR AI/ML, support the study on the following directions: 1. CSI prediction and CSI-RS/SRS overhead reduction 2. DMRS design with AI receiver/transceiver 3. AI compression for CSI/HARQ/DCI/TPMI 4. AI for modulation and demodulation 5. AI for PA non-linearity handling 6. AI for ISAC 7. NET4AI related use case, e.g., token communication 8. AI for NES 9. AI for prediction other than CSI: interference prediction, LLM-Based Prediction of Measurement Events, Anomaly detection and fault prediction, traffic prediction and DRX, DCI prediction 10. AI for control (decision): power control, AI for link adaptation /MCS selection, AI-powered adaptive frame structure, Spectrum Sensing Samsung Support. We are fine to replace CSI pattern design with CSI-RS overhead reduction. Conclusion 3.3.1-2: For CSI prediction and CSI-RS pattern design at least with UE-sided model, study on * Definition of each sub-use case * AI receiver specific evaluation assumption, methodology and KPIs * Whether/what is the specification impact on LCM (data collection, performance monitoring, inference) Company Comment FL Conclusion is for out study in future meeting. Google Support Fainity Support Lenovo Fine with this proposal. CATT, CICTCI Support. But this should be agreement rather than conclusion. SK Telecom Support CMCC Not sure why AI specific receiver is needed for AI CSI prediction. UE can use traditional receiver for CSI-RS measurement and use the measurement result as model input to predict CSI. Fujitsu Regarding the evaluation assumption, what would be the benchmark CSI-RS pattern? Nokia We do not see a value on this proposal at this stage. ZTE One important aspect that is missing is the baseline for performance comparison. Regarding the second bullet, it may not be an AI receiver for this use case. It may just be a AI model for CSI prediction. Ericsson Clarification: “AI receiver” = “UE-sided model”? Also: we think ‘CSI-RS pattern design’ should be replaced by ‘CSI-RS overhead reduction’. Note that CSI-RS pattern design will be a fundamental discussion in the RS agenda items later on. NEC For the last sub-bullet, suggest to only keep LCM and remove (data collection, performance monitoring, inference) because LCM may also involve other aspects like model switching, model activation/deactivation, fallback, etc. NTT DOCOMO NW-sided model should be included. We have no conclusion about whether the NW-sided model is totally transparent or has specification impacts (e.g., for data collection). Xiaomi Regarding evaluation assumption, we are not clear why only focus on ‘AI receiver specific’. We suggest to delete it to include all kinds of evaluation assumptions. Thus, we suggest the following update: Conclusion 3.3.1-2: For CSI prediction and CSI-RS pattern design at least with UE-sided model, study on * Definition of each sub-use case * Evaluation assumption, methodology and KPIs * Whether/what is the specification impact on LCM (data collection, performance monitoring, inference) QC Suggest the following updates: For CSI prediction and CSI-RS pattern design at least with UE-sided model, study on consider * Definition of each sub-use case * AI receiver specific eEvaluation assumption, methodology, and KPIs, and respective baselines as benchmark. * Whether/what is the specification impact on LCM (data collection, performance monitoring, inference) Note: UE-sided model, NW-sided model, and/or two-sided models can be considered in study. LGE We are generally fine with this direction. But, regarding 2nd bullet, what is the motivation of emphasizing evaluation of AI receiver? All sub use case may need to discuss evaluation assumption/baseline/KPI, etc. ETRI Support Spreadtrum We prefer to divide CSI prediction and CSI-RS pattern design into two use cases, and the details of each use case can be discussed in the future meeting CEWiT Ok with the proposal TCL support Futurewei Though we support CSI-RS related use case, we don’t think it should be combined with CSI prediction use case. In addition, it is too early to narrow down into specific (sub-)use case without proper study. vivo Support Samsung Support. But, as many companies have argued, it is okay to remove “AI receiver specifics” from the 2nd bullet. Proposal 3.3.1-3: (low priority) For CSI prediction and CSI-RS pattern design at least with UE-sided model, at least the following KPIs can be considered: - SGCS/NMSE - Spectrum efficiency - Throughput - Overhead - Inference complexity Company Comment Google Support. Probably we can re-organize it a bit by merging SE and Tput in one bullet. Lenovo Inference latency will affect the CSI reporting timeline, which should be also considered. For CSI prediction and CSI-RS pattern design at least with UE-sided model, at least the following KPIs can be considered: - SGCS/NMSE - Spectrum efficiency - Throughput - Overhead - Inference complexity - Inference latency CATT, CICTCI Support. SK Telecom OK with the proposal. CMCC Support. Fujitsu Ok. Ericsson Support Lenovo addition Xiaomi Support QC Similar comment as above that we should not restrict to UE-side models. LGE Support ETRI Support Spreadtrum OK CEWiT Ok Samsung Support 2.3.2 DMRS design with AI receiver Use cases definition Sub-use case Model location Views DMRS design or AI receiver (a) AI for channel estimation [interpretation?] (b) AI for channel estimation & interpretation & equalization 1, 2 (c) Data aided channel estimation 3,6, 7 (d) AI Receiver with multiple functions 1, 4, 5, 6 1 NVIDIA, 2 Boost* 3 Qualcomm 4 MediaTek 5 Futurewei 6 Lenovo 7 Panasonic Low overhead DMRS in general One-sided model (Receiver side) (18) Nokia, Futurewei, Kyocera, ZTE/Sanechips, DeepSig Spreadtrum/UNISOC, Ericsson, NVIDIA, OPPO, CATT/CICTCI, vivo, xiaomi, Fujitsu, InterDigital, Apple, Qualcomm, Ofinno (17) Huawei/HiSi *, TCL*, CT*, {Tejas Network Limited, CEWiT, IIT Madras, IISC Bangalore, IIT Kanpur}*, Lenovo *, Panasonic*, NTU*, LGE*, Boost*, NEC*, Honor*, ETRI*, CMCC*, Sony*, SKT*, Sharp*, {CEWiT, Tejas Network}* Sparse orthogonal DMRS One-sided model (Receiver side) (14) Nokia, Futurewei, Kyocera, Spreadtrum/UNISOC, Ericsson, CATT/CICTCI, vivo, xiaomi, ZTE/Sanechips, Qualcomm, NVIDIA, Apple, Fujitsu, Ofinno (5) Huawei/HiSi *, CT*, NTU*, LGE*, CMCC* Non-Orthogonal DMRS and Superimposed with data One-sided model (Receiver side) (4) Xiaomi, ZTE/Sanechips, OPPO, Lenovo, Qualcomm (9) Huawei/HiSi *, CT*, NVIDIA*, NTU*, LGE*, Fujitsu*, NEC*, Honor*, CMCC* DMRS-Less (a) with special modulation design 1,2,3, 5 (b) with special data pattern 4 One-sided model 1,2,3,4, 5 Or Two-sided model 1,2,3, 5 1 NVIDA 2 MediaTek 3 Lenovo 4 Interdigital 5 DeepSig (6) NVIDIA, Lenovo, InterDigital, Qualcomm, MediaTek, DeepSig (1) Huawei/HiSi * Joint RS pattern and channel estimation Two-sided model (1) Huawei/HiSi * * without simulation results 35 contributions proposed to study DMRS overhead reduction in general, wherein 18 of them provided preliminary simulation results. Most of companies assume DMRS overhead reduction is one-sided model (receiver side). Some contributions two-sided model for DMRS-less scheme with transmitter sided for bit to constellation mapping, with AI trained constellation. And one contribution (Huawei/HiSi) mentioned 2-sided model for joint CSI-RS pattern and channel estimation. 18 contributions explicitly proposed sparse orthogonal DMRS, and 13 contributions provided preliminary simulation results. With AI receiver, BLER/throughput gain can be observed comparing with conventional receiver. 13 companies proposed to study the sub-use case for non-orthogonal DMRS superimposed with data. 4 company provide some preliminary results, wherein BLER/throughput gain can be observed comparing with conventional receiver. 7 companies proposed to study DMRS-less scheme with AI/ML receiver, and 6 contributions provided preliminary simulation results with decent BLER/throughput performance. 4 companies (NVIDA, MediaTek, Lenovo, DeepSig) explicitly mentioned the use of special modulation design at the transmitter, which may or may not require transmitter-sided model (two-sided model). 1 company (InterDigital) proposed special data pattern to facilitate the AI receiver with receiver-sided model. 1 contribution (Huawei/HiSi) mentioned RS pattern design or RS pattern design and channel estimation with 2-sided model. 1 contribution (Qualcomm) mentioned DMRS pattern/schemes allow lower complexity are preferred. Assumption of Al/ML receiver Different AI/ML receiver assumptions were proposed/used in the evaluations: - AI/ML receiver for channel estimation directly with conventional Rx - AI/ML receiver for channel filter coefficient generation for legacy CE - AI/ML receiver replacing multiple blocks including CE+EQ+ demodulation - AI/ML receiver replacing multiple blocks with join-block processing, including CE+EQ+ demodulation - AI/ML receiver replacing whole Rx chains Main KPI The following KPI were proposed/used for the evaluation: - raw BER/BLER/ Tput at given SNR or given TBS - Inference complexity - Inference time Proposal 3.3.2-1: For 6GR AI/ML, support the study on DMRS design at least with AI receiver (i.e., UE-sided model or NW-sided model) for both uplink and downlink, at least including the following with potential down selection: - Sparse orthogonal DMRS - Non-Orthogonal DMRS and Superimposed with data - DMRS-less FFS on whether to support study on DMRS design with two-sided model (i.e., paired AI receiver and AI transmitter) Company Comment Google For DMRS-less, shall we change it into “no DMRS”? DMRS-less may be similar to sparse orthogonal DMRS. Ofinno Support MTK We support study of AI receiver (replacement of one block or multiple blocks) only for uplink, as training and inference complexity/latency is high for implementation of an AI receiver at the UE. Hence, only NW-sided model needs to be studied, so suggest the following change: “For 6GR AI/ML, support the study on DMRS design at least with AI receiver (i.e., UE-sided model or NW-sided model) for both uplink and downlink, at least including the following with potential down selection:…” Sharp Support. Can we directly say “For 6GR AI/ML, study DMRS design…”? Fainity Support Lenovo Fine with the proposal. As we probably will have SI on AI-based CSI-RS reduction which is primarily a one-sided use case, we suggest to support two-sided design for DMRS-overhear reduction as well. We note that it is better that 6G AI study items are selected to cover different flavors. CATT, CICTCI Support in general. One question: we think most companies have PDSCH/PUSCH channels in mind, should we make it clear? Or is it really intended to cover more, e.g. PDCCH/PUCCH? SK Telecom Although we see no huge necessity on two-sided model, the proposal is fine for us. CMCC Support. NVIDIA This is an important use case. We support the study on DM-RS overhead reduction with AI-receiver in 6GR. Fujitsu We think one-sided model is sufficient for this case and no need to consider two-sided model. Nokia Ok with the direction. For now, let’s only agree with the variant that is supported by majority and deemed feasible. Proposal 3.3.2-1: For 6GR AI/ML, support the study on DMRS design at least with AI receiver (i.e., UE-sided model or NW-sided model) for both uplink and downlink, where DMRS design at least including - Sparse orthogonal DMRS. ZTE Regarding the “Assumption of Al/ML receiver”, it is better if we can first align the understanding of AI/ML receiver. In our understanding, the AI/ML receiver refers to the receiver that is totally implemented by AI. Similarly, we also need to consider the baseline for the simulation. Huawei, HiSilicon OK with studying DMRS OH reduction. But there is no need to limit only AI receiver. To our understanding, AI transceiver should also be studied. In addition, we found the joint operation of AI receiver with SIP and other Tx functions (modulation, precoding, etc.) can also provide promising performance. Joint operation of multiple transmitter modules should also be considered as a sub-use case. For 6GR AI/ML, support the study on DMRS design with AI receiver or AI transceiver at least with AI receiver (i.e., UE-sided model or NW-sided model) for both uplink and downlink, at least including the following with potential down selection: - Sparse orthogonal DMRS - Non-Orthogonal DMRS and Superimposed with data - DMRS-less - Joint operation with other functions such as modulation, precoding. FFS on whether to support study on DMRS design with two-sided model (i.e., paired AI receiver and AI transmitter) Ericsson Do not support the FFS. Please delete NEC Assumption of ‘AI receiver’ above is needed here for this proposal. Panasonic Support the direction. NTT DOCOMO Support. We are fine to have FFS since nothing should be precluded in the current stage. However, we can share our view that UE/NW-sided model should be prioritized for 6G day 1, and two-sided model should be deprioritized for day 1 considering the difficulty of commercial introduction and avoiding the duplication with 5GA discussion. Xiaomi We support the proposal in general. In our view, the one-sided model is preferred, as it offers lower implementation complexity, less impact on specifications, and is much more friendly for deployment compared to the two-sided model. In addition, regarding the second bullet, we suggest that the wording "Non-Orthogonal DMRS superimposed with data" may be more appropriate. QC Regarding the FFS, it is important to have a common understanding among companies in terms of how to categorize the following case: If a certain DMRS pattern is derived as an outcome of offline engineering using two-sided models, but then deployed directly without the involvement of two-sided models, it should not be deemed same as scenarios for which there is an actual two-sided model being run during inference and/or requiring two-sided inter-vendor training collaboration. The implications for these two scenarios are quite different. Suggest the following updates: For 6GR AI/ML, consider the following aspects for DMRS design at least with AI receiver advanced receiver, potentially based on AI/ML (i.e., UE-sided model or NW-sided model) for both uplink and downlink, at least including the following with potential down selection: - Sparse orthogonal DMRS - Non-Orthogonal DMRS and Superimposed with data - DMRS-less Note: AI/ML algorithm is up to implementation and shall not be specified. It is up to implementation whether to use AI/ML or non-AI/ML. FFS on whether to support study on DMRS design with two-sided model (i.e., paired AI receiver and AI transmitter) LGE Support, Each DMRS design scenario should clearly specify whether it relies on a UE-sided model, an NW-sided model. OPPO Support the study in principle. First, we think this study can be applied to both UL and DL. Second, we don’t know what data channel and control channel will be designed for 6GR, it would be good to keep it open, i.e. no need to differentiate which channel. For the very 1st meeting, we should not rush to make any down selection. All three different ways for OH reduction deserve to be comprehensively studied. Since this study (if supported) is about DMRS design with AI receiver, we suggest a tiny editorial change on the 2nd bullet to focus on DMRS - Non-Orthogonal DMRS and Ssuperimposed with data ETRI Support, Open to study above mentioned DMRS cases. Spreadtrum Generally support. We prefer to delete the FFS part. Almost all the analysis and simulations provided by companies are based on one-sided model. We have not seen the necessity of studying two-sided model. InterDigital Support the principle of the proposal CEWiT We are generally ok with the proposal. But considering the understanding that 6GR strives to have a single solution for most of the features, inclusion of Non-orthogonal DMRS means we are having two types of DMRS (Orthogonal and Non-orthogonal). Also inclusion of Non-orthogonal DMRS should be considered just for AIML. So we propose to not consider Non-Orthogonal DMRS at this stage considering the impact on 6GR design. TCL support Futurewei We are ok to study the DM-RS use case for AI/ML and also for non-AI/ML approach. Specific (sub-) use case should be narrow down later after more discussion. vivo Support Tejas Support IITK We are fine with the proposal. IIT Madras We are fine with the proposal with emphasis on sparse orthogonal DMRS. Samsung OK with the proposal in general. For the detail use case, we should start with sparse orthogonal DMRS. For the other two use cases, we are concerned on how to trade-off between UE complexity and performance. Also, from MU-MIMO perspective, how the other two use cases can be co-existence with non-AI UEs should be considered. Conclusion 3.3.2-2: For DMRS design with AI receiver, further study on * Definition of each sub-use case * Assumptions of AI receiver * AI receiver specific evaluation assumption, methodology and KPIs * Whether/what is the specification impact on LCM (data collection, performance monitoring, inference) Company Comment FL How to obtain noise-free channel for labelling? May related to assumptions of AI receiver Google We think we can add another study point: CQI calculation based on DMRS design with AI receiver. The new DMRS pattern and AI receiver would have some impact on the CQI accuracy. Ofinno For further consideration on various aspects, the following change seems better as: Conclusion 3.3.2-2: For DMRS design with AI receiver, further study at least on * Definition of each sub-use case * Assumptions of AI receiver * AI receiver specific evaluation assumption, methodology and KPIs Whether/what is the specification impact on LCM (data collection, performance monitoring, inference) Sharp Fine with Ofinno’s updated version Lenovo As the guideline of 6GR AI is that the non-AI solutions would not be affected. The DMRS is critical for guaranteeing data transmission performance. It is unreasonable that the DMRS transmission of non-AI receiver is restricted by the DMRS for AI receiver. For example, the DMRS for AI-receiver is designed too uniquely so that the DMRS for non-AI receiver cannot be transmitted multiplexed with it. This goes against our original intention of improving system performance. Therefore, the coexistence with DMRS for non-AI receiver should be considered. For example, how to support multiplexing transmission of UE with AI capability and UE without AI capability in downlink. For DMRS design with AI receiver, further study on * Definition of each sub-use case * Assumptions of AI receiver * AI receiver specific evaluation assumption, methodology and KPIs * Whether/what is the specification impact on LCM (data collection, performance monitoring, inference) * Coexistence with DMRS for non-AI receiver. CATT, CICTCI Support FL’s proposal. But this should be agreement rather than conclusion. SK Telecom Fine with Ofinno’s updated version CMCC Generally OK, but if it is UE side model, the applicable functionality report should also be included in the LCM aspects. Fujitsu For the second bullet, it should be “Evaluation assumption of AI receiver”? Also the benchmark DMRS pattern should be clarified. Nokia Need adjust depending on our suggestion in the earlier proposal. Ericsson Suggest update to: For DMRS design with one-sided model (i.e., AI receiver), further study on… NTT DOCOMO Prefer Ericsson’s version. Also fine with FL/Ofinno version at this stage. Xiaomi Support. And we think we should further study the specification impacts on DMRS for each sub-use case as well. QC Not clear what the second bullet in the conclusion means. Suggest the following updates: For DMRS design with advanced receiver * Definition of each sub-use case * Assumptions of AI receiver * AI receiver specific eEvaluation assumption, methodology, and KPIs, and benchmarks * Whether/what is the specification impact on LCM (data collection, performance monitoring, inference) LGE Support OPPO Support in principle. ETRI Support Spreadtrum OK with Ofinno’s updated version. CEWiT Support TCL support Futurewei We are ok to study the DM-RS use case for AI/ML and also for non-AI/ML approach. Specific (sub-) use case should be narrow down later after more discussion. vivo Support IIT Madras Support. Samsung Fine with the conclusion. For the receiver assumption, we also need to clarify the label generation for each type of receiver. Proposal 3.3.2-3: (low priority) For DMRS overhead reduction with AI receiver, at least the following KPIs can be considered: - raw BER/BLER/ Tput at given SNR or given TBS - Overhead - Inference complexity - Inference latency Company Comment Google Probably we can add channel MSE as a KPI? Lenovo Fine with this proposal. CATT, CICTCI Support. Fujitsu Generally fine. Ericsson Suggest update to: For DMRS design with one-sided model (i.e., AI receiver), at least… Xiaomi We agree with the proposal in principle, but we have several questions as follows: 1. Definition of raw BER/BLER/Tput: The term “raw” is not clear to us. We suggest using KPIs with a more commonly understood definition, such as BER, BLER, and Tput (without the “raw” prefix). In addition, we suggest removing “at given SNR or given TBS” from the first bullet. This seems to refer to evaluation assumptions or methodology rather than being a KPI. 2. Overhead: The definition of overhead is not yet clear. Does it refer to DMRS overhead? Additionally, what unit should be used for overhead? Is it the average number of REs used for DMRS per RB per slot? We also believe that overhead might be considered an optional KPI, since it is already reflected in the Tput. 3. Inference complexity: The inference complexity should be measured over a time duration, not just once. This is important as different AI receivers might have different inference frequencies. 4. Inference latency: We agree that inference latency should be a KPI. But the method for calculating inference latency still requires further study. Therefore, we suggest that this be marked as an FFS. QC OK with the following wording change: For DMRS overhead reduction with advanced receiver LGE Support, but we are ok with inference complexity which can be measured by FLOPs, but for inference latency, how to define and measure the latency can be questionable. ETRI Since DMRS use cases were not studied in last releases, it seems early to discuss in this stage, however, channel SGCS/NMSE may also be considered. Spreadtrum Support. CEWiT Support IIT Madras Support Samsung Fine with the proposal, We are fine to the clarification for removing the “raw”, If it is common understanding about the KPI for BER and BLER. 2.3.3 CSI compression Use case definition (sub)-use cases Model location Supported companies CSI compression (a) Joint CE/with low RS density +CSI compression 2, 4, 6,7, 8 (b) CSI with SRS 1,2,5,9 (c) Low UE complexity 1,3,9 (d) Joint time prediction 4,10 (e) Eigenvector vs explicit channel 1,2 (f) for HBF 1 1 vivo 2 ZTE 3 Samsung 4 BJTU 5 LGE* 6 NVIDIA * 7 Panasonic * 8 NEC* 9 Qualcomm 10 BUPT * based on 5GA separate coding only Joint source/channel coding (JSCC) Two-sided model (9) vivo, ZTE, Samsung, BJTU, Lenovo, OPPO, Fujitsu, BUPT, Pengcheng (6) CATT/CICTCI*, TCL*, CT*, CMCC* Qualcomm?*, NVIDIA* Joint source-channel coding and modulation (JSCM) Two-sided model (7) vivo, ZTE, Samsung, BJTU, Lenovo, OPPO, Fujitsu, BUPT (6) CATT/CICTCI*, Sony*?, Qualcomm?*, Lenovo*,{Indian Institute of Tech (M), IIT Kanpur}* , NVIDIA* Codebook based CSI feedback with downloadable basiscodebook NW-sided model (2) Samsung, ZTE/Sanechips (1) Qualcomm *? Linear compression matrix NW-sided model (1) Samsung, * without simulation results 15 contributions proposed to study joint source/channel coding (JSCC) and 13 contributions proposed to study joint source/channel coding and modulation (JSCM) with two-sided model. 9 and 8 contributions provided preliminary simulation results, which showed better SGCS/NMSE than 5GA study with separated source and channel coding (SSCC) with same overhead for UCI transmission and same/similar complexity for most of or all the SNR range. 3 contributions (Samsung, ZTE/Sanechips, Qualcomm) proposed codebook-based CSI feedback with downloadable (DLable) basis/codebook, and CSI reconstruction with NW-sided model. 2 contributions (Samsung, ZTE/Sanechips) provided preliminary simulation results, which showed better SGCS/NMSE, and/or higher UPT than eType II codebook. 1 company (Samsung) proposed to study CSI compression with linear compression matrix at UE side and CSI reconstruction with NW-sided model. The simulation results showed better SGCS and SE than eTypeII codebook with same overhead for UCI transmission for all SNR range, and slightly lower performance than JSCM with 2-sided model, wherein, the same complexity as the NW-part model for decoder but much lower complexity at UE side than UE-part model or for eTypeII. Other considerations 5 contributions proposed to consider joint channel estimation with low RS density and CSI compression, 4 contributions proposed to support SRS assisted CSI feedback, 2 companies proposed to support CSI compression and time domain prediction, 2 companies support to study on both eigenvector and explicit channel, and 1 company mentioned CSI compression for hybrid beam forming. Besides, 3 companies mentioned low UE complexity for CSI compression. Proposal 3.3.3-1: For 6GR AI/ML, support the study on AI based CSI compression (in addition to the study in 5GA), at least including the following with potential down selection: - for two-sided model, o Joint source/channel coding (JSCC) o Joint source-channel coding and modulation (JSCM) - for NW-sided model o Codebook based CSI feedback with downloadable basis/codebook o Linear compression matrix - in the study, at least the following can be considered with potential down selection: o both precoder matrix and channel matrix o joint channel reconstruction of CSI with SRS at NW side o joint channel estimation and CSI compression at UE side o time domain prediction o with sparse CSI-RS o hybrid beamforming, if applicable o low UE complexity Note: 5GA CSI compression (separated source/channel coding, SSCC) with 2-sided model can be considered as one of benchmark for evaluation. Company Comment Google We failed to see the necessity for the study. We cannot study so many use cases in one release. According to the experience in 5G, such two-sided model based use case is hard to be deployed, and it requires quite a lot of time for study. FL @ google, there are two subuse case for NW-sided model. And I think it is hard to do down selection in this meeting. This direction got large support. In addition, this direction allows further study with potential down selection, either within first 3 meetings or in the future. Vodafone We would like to extend the study of CSI compression to consider the work done in Rel-18 for NES spatial/power domain adaptation, specifically for CSI sub-configuration reports for different antenna port patterns, as it can facilitate the adoption of such NES techniques. Lenovo We are generally fine with the proposal. However, on ‘low UE complexity’, seems it is a metric for evaluate benefit of a scheme and it is not of same type as other bullets. We prefer to remove it. CATT, CICTCI OK to study this use case. However, two-sided model use case is experiencing a baby-step forward and just start normative in R20 5G-A. We suggest to put more focus on most interested sub-use cases JSCC/JSCM with limited variants, not to be very spreading, thus: - in the study, at least the following can be considered with potential down selection: o both precoder matrix and channel matrix o joint channel reconstruction of CSI with SRS at NW side o joint channel estimation and CSI compression at UE side o time domain prediction o with sparse CSI-RS o hybrid beamforming, if applicable o low UE complexity SK Telecom We are quite sceptical about the necessity on two-sided model. Fine with the study on CSI compression for one-sided model. CMCC OK to further study CSI compression in 6G, but we should focus on the essential part, there are many controversial consideration points put here, it may be hard to coverage finally. We propose to delete the third bullet. And for “linear compression matrix”, it has been studied in 5G-A and also discussed in the Rel-20 CSI compression simultaneously. We can wait for more progress on Rel-20 5G-A CSI compression. So, we suggest to modify as below: Proposal 3.3.3-1: For 6GR AI/ML, support the study on AI based CSI compression (in addition to the study in 5GA), at least including the following with potential down selection: - for two-sided model, o Joint source/channel coding (JSCC) o Joint source-channel coding and modulation (JSCM) - for NW-sided model o Codebook based CSI feedback with downloadable basis/codebook o Linear compression matrix - in the study, at least the following can be considered with potential down selection: o both precoder matrix and channel matrix o joint channel reconstruction of CSI with SRS at NW side o joint channel estimation and CSI compression at UE side o time domain prediction o with sparse CSI-RS o hybrid beamforming, if applicable o low UE complexity Note: 5GA CSI compression (separated source/channel coding, SSCC) with 2-sided model can be considered as one of benchmark for evaluation. Fujitsu We also think the scope should be limited. Generally fine with the update from CMCC. Regarding the note, we think CSI compression Case-0 should be the benchmark. Nokia This use-case is not solving a new problem compared to 5GA AI use-cases. We do not a reason to support this study at this stage. ZTE Support to study Huawei, HiSilicon 1, There have been plenty of 5GA CSI compression studies (channel matrix, temporal domain CSI compression, etc.). They should be part of 6G study at least working as benchmark. 2, CSI compression with improved input types such as timing/path information should be also considered 3, We are discussing use cases. No need to distinguish with one side model or two-side model. We notice other use cases do not highlight the model side either. BTW, JSCC and JSCCM, to our understanding they are the same use case with different approaches. For 6GR AI/ML, support the study on AI based CSI compression (in addition to the study in 5GA), at least including the following with potential down selection: - for two-sided model, o Joint source/channel coding (JSCC)/Joint source-channel coding and modulation (JSCM) o CSI compression with improved input types, e.g., channel matrix, timing/path information, etc. o Joint CSI compression and prediction o Temporal domain CSI compression - for NW-sided model o Codebook based CSI feedback with downloadable basis/codebook o Linear compression matrix Ericsson Prefer CMCC version We have strong concern on the practicality of two-sided model, but we can accept studying them before use case down-selection. NEC In general, we are supporting to joint processing with CSI compression for better performance improvement. Panasonic Fine. NTT DOCOMO We are fine to preclude nothing in the current stage. However, we can share the same view with google as a comment for the next step that UE/NW-sided model should be prioritized for 6G day 1, and two-sided model should be deprioritized for day 1 considering the difficulty of commercial introduction and avoiding the duplication with 5GA discussion. Xiaomi For this direction, we are open for further study. But we share similar concern with some other company that there are so many variants. Our suggestion is just to focus with one or two essential options. For example only focus on the JSCC(M) QC * Should not recommend for study at this stage. Only aspects for potential study can be identified. * The following two bullets should be removed. Similar to what we commented earlier, the categorization of two-sided vs NW-sided model is unclear yet. o for two-sided model, o for NW- sided model, LGE We are fine to study this use case. OPPO We are general fine to this proposal, the AI based CSI compression should be studied in 6GR AI/ML. Regarding two-sided model and NW-sided model, we are more supportive of two-sided model with JSCC/JSCCM, since it is capable of achieving larger performance gain compared to 5GA. In our understanding, JSCC and JSCCM provide a new angle of view to handle the CSI compression as a source coding module together with channel coding and modulation part. This is a totally new framework compared to 5GA and would be a quite attractive use case. Therefore, we think that JSCC/JSCCM should be studied in 6GR day 1 feature. For the third bullet, we are fine to study these aspects. But in our view, these aspects are not independent use cases, which can be considered combined with both of 5GA, JSCC and JSCCM framework. For example, we can consider channel matrix as the input of encoder in both of 5GA and JSCC/JSCCM. The SRS fusion in the second case can be added on both of 5GA and JSCC/JSCCM CSI report. It would be better to clarify this condition in the proposal. ETRI Support Spreadtrum We believe it is premature to conduct a study on JSCC/JSCM at this time. Because the two-side model has only recently undergone standardization work in 5G-A R20, so there is still uncertainty. The study on two-side model can be postponed until the standardization process is completed. CEWiT We also believe at this stage, the details provided on this proposal is too extensive considering the justification on extending the study beyond what was studied in 5GA is unclear. So we propose to reduce the scope of this proposal. TCL support Futurewei We prefer to not duplication the 5G work in 6G SI though this use case can be considered for normative work based on 5G outcome vivo Support Samsung @CMCC linear compression matrix is not studied anywhere in 5GA, which should not be deleted. Conclusion 3.3.3-2: For AI-based CSI compression, further study on * Definition of each sub-use case * For the evaluation assumption, methodology and KPIs, take 5GA study as the starting point and further study on necessary change * For specification impact on LCM (data collection, performance monitoring, inference) o for NW-sided model, study on whether/what is the specification impact on LCM for each corresponding sub-use case o for two-sided model, take 5GA study outcome as the starting point, and study on necessary change for each corresponding sub-use case Company Comment FL LCM may be quite clear for 2-sided model, but whether LCM is needed for NW-sided model can be further clarified. Google We failed to see the necessity for the study. We cannot study so many use cases in one release. According to the experience in 5G, such two-sided model based use case is hard to be deployed, and it requires quite a lot of time for study. Lenovo Agree. CATT, CICTCI Support. But this should be agreement rather than conclusion. CMCC Support. But if for two-sided model, the model pairing and inter-vendor collaboration should also be included in the LCM aspects. Fujitsu Generally fine. Nokia Not needed. Ericsson Need to add performance vs complexity tradeoff as the most important aspect to study. NTT DOCOMO We are fine to preclude nothing in the current stage. However, we can share the same view with google as a comment for the next step that study on two-sided model should be deprioritized for day 1 considering the difficulty of commercial introduction and avoiding the duplication with 5GA discussion. Xiaomi Generally support QC The LCM specification impact can be studied further but similar to the other use cases, it should be broad at this stage, and further details can be discussed later, so suggest removing the following sub-bullets. o for NW-sided model, study on whether/what is the specification impact on LCM for each corresponding sub-use case o for two-sided model, take 5GA study outcome as the starting point, and study on necessary change for each corresponding sub-use case LGE In Rel-19, The RAN1 spec impact of NW-sided model is data collection part. So, we are not sure which part we can more study. OPPO We are okay to study these aspects. 5GA would be a good starting point for both of EVM and spec impacts. Regarding to the EVM, different use cases should be aligned on the same EVM, so that the performance evaluation is comparable. ETRI Support Spreadtrum Further study on two-side model is not needed. CEWiT We are generally ok. But we need to re-visit this based on the conclusion made on Proposal 3.3.3-1 TCL support Futurewei We prefer to not duplication the 5G work in 6G SI though this use case can be considered for normative work based on 5G outcome vivo Support 2.3.4 (de-)Modulation Use case definition (sub)-use cases Model location Supported companies (a) Constellation design with legacy receiver 1, 2, 3,5,6 (b) Constellation design with AI demodulation 1,2, 5,6 (c) Constellation design with end-to-end AI receiver 4, 5, 6 1 ZTE/Sanechips 2 vivo 3 xiaomi 4 Mediatek 5 OPPO 6 Lenovo offline 1, 2, 3,5,6 or receiver-sided model1,2,5 or two-sided model4,5,6 (6)Vivo, xiaomi, ZTE/Sanechips, Lenovo, OPPO, MediaTek (without RS) with receiver side model (6){Tejas Network Limited, CEWiT, IIT Madras, IISC Bangalore, IIT Kanpur}*, OPPO *, Fujitsu*, NEC*, Honor*?, Rakuten* *without simulation results AI/ML for modulation/demodulation are widely proposed by 12 contributions. 6 contributions (Vivo, xiaomi, ZTE/Sanechips, MediaTek) provided some evaluation results, wherein 3 companies used non-AI receiver with constellation design with AI shaping, 3 companies also submit results with AI receiver (one-sided model), 1 company showed performance with trained constellation without DMRS. Conclusion 3.3.4-2: For modulation constellation design, AI/ML can be used as a design tool, where AI/ML based receiver can be an implementation choice. Company Comment FL Constellation design with the help of AI/ML can be 3GPP engineering. AI receiver may be implementation choice. Unless LCM is needed, no need to define this as one 6GR AI use case. Please indicate if you have any additional view. Google OK MTK We believe constellation design is not restricted to 3GPP engineering, as the NW could re-train the constellation based on a change in scenario and/or monitor the performance of the uplink AI transceiver and e.g., choose to fall back to non-AI transceiver. Thus, LCM is needed, and this should be classified as a 6GR AI use case. Lenovo We believe there will be spec impact especially for two-sided model. Also, if probability shaping is adopted as a valid use case, there could be some spec impact. We suggest having a proposal on study of AI-based modulation similar to the previous sections. Proposal: For 6GR AI/ML, support the study on modulation design, at least including the following with potential down selection: - For legacy receiver - For AI-demodulator - AI-based modulator/demodulator Conclusion: For AI-based modulation, further study on * Definition of each sub-use case * For the evaluation assumption, methodology and KPIs, take 5GA study as the starting point and further study on necessary change * For specification impact on LCM (data collection, performance monitoring, inference) CATT, CICTCI OK for the case when ‘fixed constellation map is derived based on AI/ML’. NVIDIA In our contribution, we also propose constellation learning with simulation results: Study AI/ML for pilotless communication with constellation learning, including (1) constellation-only learning and (2) end-to-end learning of transmitter constellations and receiver algorithms These two sub-use cases correspond to (a) Constellation design with legacy receiver and (c) Constellation design with end-to-end AI receiver in the FL summary table. Would appreciate FL to update your summary to include our proposal. Fujitsu Similar view as MTK. Nokia Only few companies proposed this use-case. We do not see a need of having a proposal around this. We can come back to this in the next meeting. ZTE There are two different directions of the AI/ML-based constellation design: * Direction#1: Fixed constellation mapping in the specification, where the fixed constellation mapping may be derived by the AI. * Direction#2: the AI-generated constellation mapping can be downloaded to the UE. Both of the above two directions can apply either the AI enhanced receiver or legacy receiver. Performance comparison between these two directions is required to identify the final solution. Huawei, HiSilicon AI/ML for modulation can be used not only for geometry/probability shaping, but also for PAPR reduction or interference cancellation. For these purposes, constellation is not off-line designed and need LCM to support online inference. Ericsson Suggest to start with a more generic proposal. If the constellation points are provided (via AI), a legacy receiver can be used also. Proposal: RAN1 study AI/ML-based modulation constellation design, where the constellation is generated by an AI/ML model. * RAN1 discuss further the set of relevant modulation orders (e.g., 64-QAM, 256-QAM). NEC We need to further discuss whether AI/ML based modulation constellation designs are predefined in specification or whether AI/ML constellation design is performed during actual cell operation (e.g. based on current channel conditions). In the latter case, we may need to consider interaction between UE and network for support of such dynamic modulation constellation/scheme selection and may also involve study of two-sided model for modulation/demodulation. Hence, we think that this should be kept open for the moment. Panasonic We share same view with Lenovo. Xiaomi We share similar view with MTK and Lenovo that LCM impact is needed including the data collection, performance monitoring, switch among different constellation maps. Thus this use case should be considered as one 6GR AI use case QC * The learned constellation has not been shown to outperform geometric shaping or probabilistic shaping. Motivation for study needs to be clarified. * With regards to placement of the use cases in different sections, not clear what makes this use case not be included within Section 2.3.6 or 2.3.7? * It would be very useful if the FL performs a polling in a table in which companies designate which use cases they support and have concerns for, out of all the candidate use cases. Even though some proposals are not explicitly mentioned in some companies’ contributions, the companies may support or be open to study the use case. This table would help in categorizing use cases for discussion and organizing them in this document as well. Table 2 seems to only summarize Tdocs. LGE Share similar view with MTK. OPPO We also provide simulation results to AI-based modulation. For two-sided model (modulator and demodulator), it is clearly not implementing choice. Possibly there is impact over the transceiver chain. Given its popularity among many companies, it should be considered as a use case for 6GR. Spreadtrum We would like to clarify that the current conclusion implies that AI is merely one implementation method of modulation/demodulation, and there is no corresponding spec impact? Futurewei We are open to study this use case vivo Similar understanding as MTK. Based on the supporting level, the conclusion can be stated the other way around. Conclusion 3.3.4-2: For modulation constellation design, constellation can optimized with AIML and AI/ML or non-AIML based receiver can be assumed. Further study details of LCM procedure. 2.3.5 AI for PA non-linearity handling Use case definition (sub)-use cases Model location Supported companies AI based digital post-distortion (DPoD) Receiver-sided model (3) Ericsson, vivo, Samsung (3) Kyocera *, CATT/CICTCI*, Huawei/Hisi AI based-DPD Transmiter-sided model (1)Vivo (1)Huawei/HiSi *, * without simulation results 6 companies proposed to study on AI/ML for PA non-linearity handling, where all of the companies proposed AI based digital post-distortion (DPoD) and 2 companies proposed AI based-DPD. 3 companies provided preliminary simulation results and show the gain in BLER/throughput gain. Conclusion 3.3.5-1: For AI/ML for PA non-linearity handling, study on the following * Definition of each sub-use case * Whether/what is the specification impact especially on LCM for AI/ML (data collection, performance monitoring, inference) * Evaluation assumption, methodology and KPIs, if applicable Company Comment FL Some clarification is needed to have better understanding on spec impact on, especially whether AI LCM is needed. Then we can further conclude whether this can be treated as RAN 1 led use case. Google In our view, this should be studied by RAN4 instead of RAN1. FL The intentions is to let’s check whether something RAN 1 needs to do, before agreeing the study. Vodafone Support to study, but it is not clear if this enhancement is to be done at the UE or the base station or both. If it is to be done at the base station, studying the impacts from not having all UEs in coverage of the base supporting this feature is necessary. Lenovo Better to study whether this case is led by RAN1 and RAN4. CATT, CICTCI OK. This should be agreement rather than conclusion. Also, ‘metric’ seems missing from the last bullet: * Evaluation assumption, methodology, metric and KPIs, if applicable One last question is that, why ‘if applicable’ is added? Is there anything in this bullet not applicable in any case? Nokia We can come back to this if other companies show interest in the next meeting. ZTE We are open to study this AI/ML use case, but it seems more like a RAN4 topic. RAN1 may not have the corresponding expertise. Ericsson Support. Suggest to make it proposal=>agreement Xiaomi We share similar view with Google and ZTE, since the PA is more related to RAN4, RAN4 is more expertized in the modelling of PA, PA evaluation methodology and KPI. we consider the study and decision should be performed by RAN4. There may be some LCM impact in RAN1, RAN1 could be involved in the LCM discussion if needed. QC * With regards to placement of the use cases in different sections, not clear what makes this use case not be included within Section 2.3.6 or 2.3.7? * It would be very useful if the FL performs a polling in a table in which companies designate which use cases they support and have concerns for, out of all the candidate use cases. Even though some proposals are not explicitly mentioned in some companies’ contributions, they companies may support or be open to study the use case. This table would help in categorizing use cases for discussion and organizing them in this document as well. Table 2 seems to only summarize Tdocs. LGE Agree with Nokia OPPO The PA non-linearity is a good use case to be addressed by AI/ML, but it seems fall into the scope of RAN4 study. We tend to think it should be up to RAN4 to recommend it as an AI/ML use case in RAN4, rather than RAN1. Spreadtrum We think it should be studied in RAN4. CEWiT We believe this needs to be taken up by RAN4 vivo LCM procedure is needed for this use case, especially on data collection part. RAN1 should conduct the overall study on LCM before directly throw the discussion to RAN4. Moreover, we would like to clarify that the use cases also include AIML waveform in the others part for reducing PAPR which is also to better handle PA non-linearity. Samsung Although we also think RAN4 will be involved in such discussion, it should not prevent RAN1 to study it. And we share the view of CATT, this should be proposal (agreement) rather than conclusion. 2.3.6 Others use cases with evaluation results Index Use cases Model Location Supported companies 1) Joint modulation and precoding 2-sided model (3)ZTE/Sanechips, OPPO, Lenovo, (1)NEC* 2? AI for waveform Transmitter-sided (1)Vivo, (1)Boost* 2-sided model (2)Vivo, Samsung 3? SRS overhead reduction NW-sided model (1) vivo, (7) Spreadtrum/UNISOC *, LGE*, NEC*, Sony*, SKT*, AT&T*, Fujitsu* 4? JSCCM for HARQ 2-sided model [NW-sided model?] (1) Qualcomm (3){Indian Institute of Tech (M), IIT Kanpur}*, Honor*?Sony*?, 5? AI based UL precoding 2-sided model (1)Vivo, (3)ZTE/Sanechips *, LGE*, Fujistu* 6? Power control/Path loss production NW-sided model? (1)Nokia, (4)Google *, Sharp*, Fujitsu*(support UE-side model), Panasonic* 7? AI/ML-based interference prediction UE-sided model (1)Vivo, (2)NVIDIA *, Boost* 8? AI for DCI (a)prior information aided DCI decoding (b)DCI information lossless compression (a)UE-sided model (b)2-sided model (1)CMCC (1)Rakuten* 9? Token Communication ? (1) Huawei/Hisi 10? AI-based PRACH receiver NW-sided model (1) Ofinno 11? LLM-Based Prediction of Measurement Events ? (1)BJTU Questions 3.3.6: 1) For proponent, please update some clarification, especially on the assumptions on the model location in Table 1 2) Please provide your support/concern into the following table 1. (if any of your view in the Tdoc missed, please update both Table 1 and previous Table) 3) Any additional comment, please fill in table 2. Table 1 Index Use cases Model Location Supported companies Concerns? 1) Joint modulation and precoding 2-sided model (3)ZTE/Sanechips, Lenovo, OPPO, (1)NEC* 2? AI for waveform Transmitter-sided (1)Vivo, (1)Boost* 2-sided model (3)Vivo, Samsung, Huawei/HiSilicon 3? SRS overhead reduction NW-sided model (1) vivo, (7) Spreadtrum/UNISOC *, LGE*, NEC*, Sony*, SKT*, AT&T*, Fujitsu [NVIDIA] We support study SRS overhead reduction 4? JSCCM for HARQ 2-sided model [NW-sided model?] (1)Qualcomm (3){Indian Institute of Tech (M), IIT Kanpur}*, Honor*?Sony*?, 5? AI based UL precoding 2-sided model (1)Vivo, (3)ZTE/Sanechips *, LGE*, Fujistu* 6? Power control/Path loss production Pathloss prediction – UE sided. CLPC with AI/ML - NW-sided model (1)Nokia, (3)Google *, Sharp*, Fujitsu*(support UE-side model) [Sharp]: for OLPC, we understand UE-sided model to obtain the pathloss/parameters in calculation of uplink power is needed. 7? AI/ML-based interference prediction UE-sided model (1)Vivo, (2)NVIDIA *, Boost* 8? AI for DCI (a)prior information aided DCI decoding (b)DCI information lossless compression (a)UE-sided model (b)2-sided model (1)CMCC (1)Rakuten* 9? Token Communication ?Not AI/ML at RAN (Net4AI) (1)Huawei/Hisi 10? AI-based PRACH receiver NW-sided model (1) Ofinno 11? LLM-Based Prediction of Measurement Events ? (1)BJTU 12? AI/ML-enabled RAN Digital Twin Distributed model at UEs ant NW (1)Huawei/Hisi Table 2 for additional comments, if any Company Comment CMCC 1) For AI/ML-based DCI enhancement (a)prior information aided DCI decoding at UE side: The AI/ML-based DCI prediction model could be used to provide the decoder with more prior information and improve the decoding performance. Simulation results show the AI/ML DCI decoder can achieve >5 dB improvement at BLER@1% and ~1.5 dB at BLER@0.1% compared to the baseline 2) For AI/ML-based DCI enhancement (b)DCI information lossless compression: A same DCI prediction model is used in NW and UE, which can be achieved by model transfer. Simulation results using field data show significant DCI overhead reduction benefits: 88.7% of cases achieve 87.5% overhead reduction by compressing the original 48-bit payload with 24-bit CRC to a 3-bit Error Pattern Index with 6-bit CRC. The aggregate overhead reduction is 77.6%. Nokia On 6) we suggest checking our detailed reasoning and simulations in the Tdoc R1-2505132. Power control is another direction that AI/ML can help, and we suggest companies to check further on the potential benefits until the next meeting. ZTE In the first meeting, we believe it will be meaningful to collect a complete list of the AI/ML use cases mentioned by all companies, with potential categorization as the feature lead has already done. This should be reflected in the final 6G TR as well. Based on the complete list, we can further discuss the potential down-selection. Secondly, the simulation result should not be a triggering state for the discussion of new AI/ML use cases. RAN1 even hasn’t aligned the simulation assumptions. We suggest to list all the AI/ML use cases first, including these are not with simulation results currently. Thirdly, we think some AI/ML use cases in section 2.3.6 can be promoted or merged, e.g., * Joint modulation and precoding, AI based UL precoding, can be merged as AI-based precoding enhancement. * SRS overhead reduction is supported by multiple companies, which deserves some further study. Finally, for AI/ML use cases in section 2.3.7, since there is no comment table below, we will directly comment here. At least traffic prediction is supported by multiple companies, which deserves further study. QC * With regards to row 4, the AI-optimized codebook for HARQ-ACK can be derived based on offline engineering, and the result can be captured in a Table in specifications, as an example, which means during inference there is no 2-sided model. * As mentioned earlier, this issue (how to categorize such use cases-one-sided versus two-sided) needs common understanding among companies, Otherwise, referring to such use cases as “two-sided” may be misleading, and give some companies the impression that there’s actually a two-sided AI/ML model for inference. * It would be very useful if the FL performs a polling in a separate table in which companies designate which use cases they support and have concerns for, out of all the candidate use cases. Even though some proposals are not explicitly mentioned in some companies’ contributions, they companies may support or be open to study the use case. This table would help in categorizing use cases for discussion and organizing them in this document as well. Table 2 seems to only summarize Tdocs. ETRI First of all, we appreciate the effort of collecting the use cases. As there is no comment table below, we provide our comments here on other new use cases, including those in Section 2.3.7. In line with ZTE’s view, we also believe that it is important to first collect all possible use cases, which will serve as the basis for potential down-selection. In this regard, since the evaluation assumptions have not yet been determined, it seems necessary at this stage to list new AI/ML use cases supported by multiple companies and requiring further study, regardless of simulation results. Spreadtrum For SRS overhead reduction, it is a simple NW-side model and has a relatively small impact on spec. We believe this can be selected as a new 6G use case vivo First of all, we would like to comment that directly categorizing use cases as others is too hasty based on counting number of proponents. Observation on gains and complexity of use cases should be firstly conducted across companies, before categorizing use cases to others . Secondly, we would like to specifically provide comments on some of the use cases categorized as others: * The intention of proponents of “AI for waveform” (vivo, Samsung and Boost) is for low PAPR and better handle PA non-linearity. Thus this use case should be merged to PA non-linearity use case. * SRS overhead reduction provides better gain with small complexity. It should be a major use case and supported by 7 companies. * UL precoding should be a major use case. The performance gain is as high as 5dB for the simulated scenarios compared with the baseline. * Interference prediction can be considered together with CSI prediction, and should be merged into the CSI prediction use case. * AI/ML sequence generation was missed in the FL summary. We provide evaluation results. Thirdly, the following use cases in the next table should also be considered. AI/ML based traffic prediction should be supported. We see the potential to use AIML based traffic prediction to reduce latency and power consumption. Tejas Ok with the proposal CMCC2 We think it is premature to label use cases as 'major' based only on proponent count. Cross-checking among companies for the benefits and complexities of use cases could be performed firstly. All the valuable use cases should be listed here and will be reflected in the final 6G TR as well. About use case categorization, some update based on Huawei’s version: For 6GR AI/ML, support the study on the following directions: 1. CSI prediction and CSI-RS/SRS overhead reduction 2. DMRS design with AI receiver/transceiver 3. AI compression for CSI/HARQ/DCI/TPMI 4. AI for modulation and demodulation 5. AI for PA non-linearity handling 6. AI for ISAC 7. NET4AI related use case, e.g., token communication 8. AI for NES 9. AI for prediction other than CSI: interference prediction, LLM-Based Prediction of Measurement Events, Anomaly detection and fault prediction, traffic prediction and DRX, DCI prediction 10. AI for control (decision): power control, AI for link adaptation /MCS selection, AI-powered adaptive frame structure, Spectrum Sensing Samsung It seems that companies want to study various use cases. But it is difficult to study all use cases due to limited time. We suggest identifying potential spec impacts and benefits first, and then deciding whether to study them. Huawei, HiSilicon To clarify, our simulation results for the RAN Digital Twin case are provided as follows. For AI/ML-enabled RAN Digital Twin use case proposed in R1-2505188, Figure 2 copied as follows is based on simulation (the sensing scatters at each UE and the environmental information as BS). To give more insight on this, we’d like to add quantitative results here: for a target building in Figure 2, the girth is 90.2m from top-view. Through local sensing, UE1 and UE2 can construct part of the building, i.e., 31.2m (about 34.6%) for UE1 and 48.7m (about 54.0%). With the help of distributed models, environmental information aggregated at BS is 79.8m (about 88.5%), which is clearly better than the local ones. Figure 2 AI/ML-based environment construction Moreover, as mentioned in R1-2505188, the complete radio frequency information such as channel multi-path information can also be obtained at BS for communication performance improvement. For example, for CSI prediction with sparse CSI-RS, with the help of such radio frequency information, the prediction accuracy (such as SGCS) can be improved as show in the following table, where 256x8 MIMO Uma channel at 6.75GHz carrier frequency, 30kHz SCS are assumed. Solutions Non-AI (interpolation) RAN DT-based Layer1 mean SGCS 0.480 0.936 Layer1~8 mean SGCS 0.313 0.796 As mentioned in R1-2505188, with UE moving, the data distribution may be changing. Continuous learning based on real-time collected data from help with guaranteeing the performance. Compared with the fixed local model, fine-tuned local model provides 2.43%~11.27% average throughput gain and 29.05%~124.99% through gain for 5-percentile UE. If a global model is used as the base for continuous learning, the gain can be even larger, i.e., 3.41%~16.93% average throughput and 19.28%~194.92% for 5-percentile UE throughput. 21 cells with totally 210 UEs (10UE per cell), 256T8R DL, Uma channel, SU or MU scheduling, Los-only/NLos-only/Los-Nlos-mixed are assumed. 2.3.7 Other proposed use cases without simulation results Index (sub)-use cases Model location Proposed by companies 1) AI for link adaptation /MCS selection NW-sided model NVIDIA * Lekha * Sharp* 2) AI for NES ? CATT/CICTCI*, LGE*, ETRI *, Vodafone* {CEWiT, Tejas Network}*, Panasonic 3) AI based ISAC ? Spreadtrum/UNISOC *, Panasonic *. Boost*, Deepsig*, {CEWiT, Tejas Network}* 4) AI/ML-enabled RAN Digital Twin ? Huawei/Hisi * 5) Anomaly detection and fault prediction ? NVIDIA * 6) AI based traffic prediction AI based DRX?DRX One-sided? Vivo*, ZTE/Sanechips*?Honor*, AT&T*, {CEWiT, Tejas Network}* 7) AI/ML based channel coding Receiver-sided model, implementation based 2-sided model? {Tejas Network Limited, CEWiT, IIT Madras, IISC Bangalore, IIT Kanpur}*, Boost * 8) Scrambler/ descrambler or interleaver, de-interleaver auto-decoder or a joint two-sided model, {Tejas Network Limited, CEWiT, IIT Madras, IISC Bangalore, IIT Kanpur}* 9) AI-powered adaptive frame structure NW-sided model? 2-sided model? Lekha * 10) AI based HARQ ? Boost* 11) Spectrum Sensing ? Deepsig* Comments from FL: Please provide evaluation results to tigger the discussion on the above use cases. No discussion in this meeting. If anything missed, please let me know offline. 3 2nd round discussion 3.1 Evaluation and KPIs Proposal 1.1A (KPI): For evaluation of AI/ML use cases in 6GR, consider * Performance related metrics, including intermediate (model) performance KPIs, link level KPIs (e.g., BLER) and system level KPIs (e.g., throughput, overhead) * AI/ML Model related metrics, including model/computational complexity, inference latency, training latency (when applicable), o FFS on whether/how to measure power consumption * Inter-vendor collaboration when applicable * Generalization performance under a wide range of conditions o FFS on whether and how to consider realistic deployment scenarios Note: Detailed metrics to be discussed per use case. Company Comment FL - some adjustment according to companies’ input - the power consumption in FFS considering some companies think it may be able to be represented by model complexity - add generalization performance but keep realistic deployment scenarios as FFS InterDigital We would like to suggest the following modifications. We would like to insert sentences to clarify overhead that’s required in training or performance monitoring. In addition, we shall consider frequency of inference, the number of inference instances per unit time, as part of complexity analysis. Proposal 1.1A mod (KPI): For evaluation of AI/ML use cases in 6GR, consider * Performance related metrics, including intermediate (model) performance KPIs, link level KPIs (e.g., BLER) and system level KPIs (e.g., throughput, overhead) o For overhead, in addition to overhead associated with inferencing, overhead associated with performance monitoring and (re-)training should be considered. * AI/ML Model related metrics, including model/computational complexity, inference latency, training latency (when applicable), o FFS on whether/how to measure power consumption o FFS how to incorporate inference frequency into computational complexity metric * Inter-vendor collaboration when applicable * Generalization performance under a wide range of conditions o FFS on whether and how to consider realistic deployment scenarios Note: Detailed metrics to be discussed per use case. Proposal 1.2A (LCM framework): For 6G LCM framework for AI/ML for air interface, consider the 5G NR AI/ML LCM framework as a starting point. * Study the necessity of potential enhancements for LCM, and if justified, the enhancement details. The examples to study include: o Data and model management o Handling of additional conditions o Enablers for continuous (online) on-device model training/finetuning o framework for AI/ML processing and memory Company Comment FL -Some modification on main bullet, according to companies’ suggestion - keep LCM since that has been widely used in 5G NR SI/WI - delete third level details and make second level details as examples. Ericsson Definition of “5G NR AI/ML LCM framework” is unclear. Does it mean section 4 “General AI/ML framework” of TR 38.843 v18.0.0? If so, suggest the following update. Proposal 1.2B (LCM framework): For 6G LCM framework for AI/ML for air interface, consider the 5G NR AI/ML LCM framework (see section 4 “General AI/ML framework” of TR 38.843 v18.0.0) as a starting point. LG In our understanding, 5G NR AI/ML LCM framework is referring to the LCM framework for R19/R20 AI/ML use cases. Also, we are wondering that whether this LCM framework can be studied in the dedicated agenda or in the related agenda (e.g., MIMO). We think dedicated agenda is more efficient for discussion. InterDigital We are ok to consider 5G NR AIML LCM framework as a starting point but we would like to avoid using words “enhancements” as the 6G LCM framework may be quite different from 5G LCM. We suggest the following changes. Proposal 1.2C (LCM framework): For 6G LCM framework for AI/ML for air interface, consider the 5G NR AI/ML LCM framework as a starting point. Target unified LCM across use cases (at least within RAN1) as one of the design principles. * Study the necessity of potential enhancements for LCM, and if justified, the enhancement details. The examples to study include: o Data and model management o Handling of additional conditions o Enablers for continuous (online) on-device model training/finetuning o framework for AI/ML processing and memory 3.2 Use cases Conclusion 3.2-1 (use case identification) For 6GR AI/ML use cases identification, companies are encouraged to study and report the following: * Definition of each (sub-)use case, including o AI/ML model input/output/label (if applicable) * The evaluation assumption, methodology, KPIs, and preliminary simulation results * Assumption on model location, and training types, e.g., o UE-sided model, NW-sided model, and two-sided model o offline training, online training/finetuning * Collaboration between UE and NW, e.g., o no collaboration o UE/Network collaboration targeting at separate or joint ML operation * Potential specification impact including LCM (e.g., data collection, performance monitoring, inference) Company Comment FL For companies to clarify the proposed use cases, and assumptions. Also, strongly encourage companies to provide preliminary results. I may only summarize the one with evaluation results in next meeting for new 6G use cases. For DMRS overhead reduction, companies are encouraged to clarify AI receiver assumptions. Ericsson Regarding “model input/output/label (if applicable)”, label is collected true value of model output. Label should not be listed together with output. Can change it to how to obtain label data. Suggested update: Conclusion 3.2-1 (use case identification) For 6GR AI/ML use cases identification, for each (sub-)use case proposed, proponent companies are encouraged to study and report the following: * Definition of each (sub-)use case, including o AI/ML model input/output/label (if applicable) * The evaluation assumption, methodology, KPIs, and preliminary simulation results * Assumption on model location, and training types, e.g., o UE-sided model, NW-sided model, and two-sided model o offline training, online training/finetuning * Construction of training dataset, e.g. how to obtain label data corresponding to measurement of model input * Collaboration between UE and NW, e.g., o no collaboration o UE/Network collaboration targeting at separate or joint ML operation * Potential specification impact including LCM (e.g., training data collection, performance monitoring, inference) LG We are generally fine with this conclusion. Also, fine with Ericsson’s modification. For 3rd sub bullet, model location is somewhat confusing. Does it mean for inference? InterDigital What does “collaboration” mean in the proposal? If there is no collaboration, does it mean it’s one sided training? In addition, we would like to encourage companies to report the baseline used for performance comparison. We would like to suggest the following changes. Conclusion 3.2-1 mod (use case identification) For 6GR AI/ML use cases identification, companies are encouraged to study and report the following: * Definition of each (sub-)use case, including o AI/ML model input/output/label (if applicable) * The evaluation assumption, methodology, KPIs, baseline used for performance comparison and preliminary simulation results * Assumption on model location, and training types, e.g., o UE-sided model, NW-sided model, and two-sided model o offline training, online training/finetuning * Collaboration between UE and NW, e.g., o no collaboration o If applicable, UE/Network collaboration targeting at separate or joint ML operation * Potential specification impact including LCM (e.g., data collection, performance monitoring, inference) Conclusion 2.2-1A (handling of 5G NR use case): If the evaluation assumptions are applicable and valid for 6GR, 5GA use cases and the corresponding study outcome (e.g., observations, conclusions, etc. in TR 38.843) can be considered for 6GR AI/ML discussion without duplicated evaluation. Company Comment InterDigital We would like to propose the following change. Conclusion 2.2-1A mod (handling of 5G NR use case): If the non-AIML 6GR performance is the same as non-AIML 5GA and the evaluation assumptions are applicable and valid for 6GR, 5GA use cases and the corresponding study outcome (e.g., observations, conclusions, etc. in TR 38.843) can be considered for 6GR AI/ML discussion without duplicated evaluation. Conclusion 2.2.1-2A (handling on extension of AI for BM): For new beam management related use cases, RAN1 considers to make observations/conclusions with potential additional study based on the existing observations/conclusions from AI/ML for beam management in TR38.843. Company Comment FL For some guidance on how to handle beam management related use cases. In next meeting, we can try to identify the new beam management related use cases, with analysis and necessary simulation results. InterDigital We do not support this conclusion and we do not think this conclusion will bring benefits to the study. We made a similar comment in the previous round. 6G BM may have a different procedure. Therefore, the observations and conclusions made during the 5G AIML study may not be applicable to 6G AIML study. This conclusion also implies that 6G BM will be similar to 5G BM which may not be true. Contact information Company Delegate(s) Email address Moderator Feifei Feifei.sun@samsung.com Google Yushu Zhang yushuzhang@google.com Ofinno Jaehoon Chung jchung@ofinno.com Sharp Yinan Zhao Yinan.zhao@cn.sharp-world.com Fainity Chia-Hung Lin chlin@fainnov.com Lenovo Bingchao Liu Vahid Pourahmadi Srinivas Kothapalli liubc2@lenovo.com vpourahmadi@lenovo.com vkothapalli@lenovo.com CATT Yongqiang FEI feiyongqiang@catt.cn SK Telecom Hyunho Lee hho.lee@sk.com CMCC Xiaodong Shen Yi Zheng Yuhua Cao shenxiaodong@chinamobile.com zhengyi@chinamobile.com caoyuhua@chinamobile.com NVIDIA Xingqin Lin xingqinl@nvidia.com Fujitsu WANG Guotong (David) wangguotong@fujitsu.com Nokia Keeth Jayasinghe keeth.jayasinghe@nokia.com ZTE Xingguang, Wenfeng, Yunqi wei.xingguang@zte.com.cn liu.wenfeng@zte.com.cn sun.yunqi@zte.com.cn Huawei, HiSilicon Yuan Li liyuan3@huawei.com Ericsson Yufei Blankenship Jingya Li Siva Muruganathan yufei.blankenship@ericsson.com jingya.li@ericsson.com siva.muruganathan@ericsson.com NEC Peng Guan Pravjyot Deogun Yi Jiang Guan_peng@nec.cn pravjyot.deogun@EMEA.NEC.COM y-jiang_ct@nec.com Panasonic Henry Tran Tetsuya Yamamoto Hidetoshi Suzuki xuantuong.tran@sg.panasonic.com yamamoto.tetsuya001@jp.panasonic.com suzuki.hidetoshi@jp.panasonic.com NTT DOCOMO Kosuke Shima Wang Xin Zhang Zhibo kousuke.shima.nr@nttdocomo.com wangx@docomolabs-beijing.com.cn zhangzb@docomolabs-beijing.com.cn Xiaomi Qin MU muqin@xiaomi.com Qualcomm Hamed Pezeshki hamedp@qti.qualcomm.com OPPO Jeffrey Cao Wendong Liu caojianfei@oppo.com liuwendong1@oppo.com ETRI Youngjoon Yoon Minhyun Kim youngjoon.yoon@etri.re.kr minhyun.kim@etri.re.kr Spreadtrum Shijia shao Zhe yu Mimi chen Shijia.shao@unisoc.com Zhe.yu@unisoc.com Mimi.chen@unisoc.com CEWiT Dhivagar Baskaran Shiv Shankar dhivagar.b@cewit.org.in shivshankar@cewit.org.in TCL Pu Yuan Tianqi Wu pu.yuan@tcl.com tianqi1.wu@tcl.com IITK Chethan Ranganatha chethanr@iitk.ac.in Tejas Networks Pavan Kalyan D pavankalyand@tejasnetworks.com IIT Madras Anil Kumar Yerrapragada Jeeva Keshav S anilkumar@5gtbiitm.in jeevak@5gtbiitm.in LGE Haewook Park haewook.park@lge.com InterDigital Fumihiro Hasegawa fumihiro.hasegawa@interdigital.com Reference [1] R1-2505132 Views on AI/ML Operation and Use Cases for 6G Radio Air Interface Nokia [2] R1-2505147 Discussion on AI/ML in 6GR interface FUTUREWEI [3] R1-2505157 AI/ML in 6GR interface Kyocera [4] R1-2505177 Discussion on AIML in 6GR interface Spreadtrum, UNISOC [5] R1-2505180 AI/ML Use Cases for 6GR Air Interface Ericsson Telecom S.A. de C.V. [6] R1-2505188 Views on AI/ML in 6GR air interface Huawei, HiSilicon [7] R1-2505266 AI/ML in 6GR Air Interface Google [8] R1-2505298 Discussion on AI/ML in 6GR interface CATT, CICTCI [9] R1-2505421 Discussion on AI/ML in 6GR interface vivo [10] R1-2505468 Initial consideration on AI/ML in 6GR interface Xiaomi [11] R1-2505482 Discussion on AI/ML in 6GR air interface TCL [12] R1-2505495 Discussion on AI-based Smart Radio for 6G Air Interface ZTE Corporation, Sanechips [13] R1-2505518 Discussion on AI/ML in 6GR interface China Telecom [14] R1-2505588 AI/ML use cases and framework for 6GR Samsung [15] R1-2505591 Discussion on AI/ML-driven use cases for 6GA BJTU [16] R1-2505592 AI and ML in 6GR air interface NVIDIA [17] R1-2505678 Initial Views on AI/ML in 6GR interface Ofinno [18] R1-2505686 Discussion on AI/ML in 6GR air interface Tejas Network Limited, CEWiT, IIT Madras, IISC Bangalore, IIT Kanpur [19] R1-2505690 AI/ML in 6GR Lenovo [20] R1-2505762 AIML use cases for 6GR air interface OPPO [21] R1-2505782 AI/ML in 6GR Interface Lekha Wireless Solutions [22] R1-2505786 Discussion on AI/ML in 6GR interface Panasonic [23] R1-2505805 AI/ML Use Cases for 6G NTU [24] R1-2505823 Discussion on AI/ML in 6GR interface LG Electronics [25] R1-2505828 AI/ML for 6G Air Interface InterDigital, Inc. [26] R1-2505918 On AI/ML for 6G air interface Apple [27] R1-2505920 On AI-ML Use Cases for 6G Air-Interface Boost Mobile Network [28] R1-2505932 Discussion on AIML in 6GR interface NEC [29] R1-2505970 Discussion on AI/ML in 6GR Fujitsu [30] R1-2506004 Views on AI/ML in 6GR interface HONOR [31] R1-2506025 AI/ML for 6GR Air Interface MediaTek Inc. [32] R1-2506070 Discussion on AI/ML in 6GR interface ETRI [33] R1-2506102 Discussion on AI/ML in 6GR interface CMCC [34] R1-2506120 Discussion on the potential AI/ML use cases for 6GR interface Sony [35] R1-2506136 On new use cases for AI-ML in 6GR Vodafone [36] R1-2506153 Views on AI/ML in 6GR air interface SK Telecom [37] R1-2506223 AI/ML in 6GR air interface Qualcomm Incorporated [38] R1-2506233 Views on AI/ML for 6GR Air Interface AT&T [39] R1-2506243 Views on AI/ML in 6GR Air Interface DeepSig Inc [40] R1-2506250 Discussions on AI/ML in 6GR interface Sharp [41] R1-2506311 Discussion on AI/ML in 6GR interface NTT DOCOMO, INC. [42] R1-2506314 Discussion on AI/ML in 6GR Interface Indian Institute of Tech (M), IIT Kanpur [43] R1-2506329 Discussion on AI/ML-enabled use cases for 6GR BUPT [44] R1-2506345 Discussion on AI/ML in 6GR -Physical Layer Rakuten Mobile, Inc [45] R1-2506364 AIML in 6G Air Interface - Scenarios and Use cases CEWiT, IITM, Tejas, IITK [46] R1-2506384 New use case for AI/ML in 6GR interface Pengcheng Laboratory