3GPP TSG RAN WG1 #122 R1-250xxx Bengaluru, India, Aug 25th ¨C 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 * 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. 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. 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. 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 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. 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 is 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. 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. 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} (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. 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). 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 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,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) (17) 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 31 contributions proposed to study DMRS overhead reduction in general, wherein 16 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. 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. 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¡­ 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 (7) Spreadtrum/UNISOC*, 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 basis NW-sided model (2) Samsung, ZTE/Sanechips (1) Qualcomm *£¿ Linear compression matrix NW-sided model (1) Samsung, * without simulation results 16 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. 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. 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 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 (4)Vivo, xiaomi, ZTE/Sanechips, Lenovo *OPPO, MediaTek (without RS) with receiver side model (8){Tejas Network Limited, CEWiT, IIT Madras, IISC Bangalore, IIT Kanpur}*,Lenovo *, OPPO *, Fujitsu*, Spreadtrum/UNISOC *, NEC*, Honor*?, Rakuten* *without simulation results AI/ML for modulation/demodulation are widely proposed by 12 contributions. 4 contributions (Vivo, xiaomi, ZTE/Sanechips, MediaTek) provided some evaluation results, wherein 3 companies used non-AI receiver with constellation design with AI shaping, 2 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. 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 2.3.6 Others use cases with evaluation results Index Use cases Model Location Supported companies 1) Joint modulation and precoding 2-sided model (2)ZTE/Sanechips, OPPO, (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 (2)ZTE/Sanechips, OPPO, (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 [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 ¨C 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 ? (1)Huawei/Hisi 10£© AI-based PRACH receiver NW-sided model (1) Ofinno 11£© LLM-Based Prediction of Measurement Events ? (1)BJTU 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. 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. 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 Yuhua Cao Yi Zheng caoyuhua@chinamobile.com zhengyi@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 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