RAN1 /
Meeting 124bis /
NR_AIML_air
AI/ML for NR Air Interface
NR_AIML_air · 27 contributions
Meeting outcomes
From the official RAN1#124bis chairman's report
Maintenance on Artificial Intelligence (AI)/Machine Learning (ML) for NR Air Interface
agreement
The following TP for TS 38.212 Clause 6.3.1.1.2 is endorsed.
Reason for change: For P/SP CSI reporting on PUCCH for performance monitoring, it is possible that the number of information bits of RS-PAI becomes less than 3 bits. However, NR specifications do not support PUCCH carrying 1 or 2 information bits other than HARQ-ACK/SR.
Summary of change: For P/SP CSI reporting on PUCCH for performance monitoring, the number of information bits of related CSI is zero padded to 3 bits.
Consequences if not approved: For P/SP CSI reporting on PUCCH for performance monitoring, 1-bit or 2-bit payload size of RS-PAI is not supported.
The corresponding final CR in:
(Rel-19, 38.212, NR_AIML_air-Core, CR0246, Cat F) is agreed.
agreement
The following TP for TS 38.214 Clause 5.2.1.6 is endorsed.
Reason for change: CPU duration for beam management related UE-side data collection is not captured correctly. In current specification, periodic CSI report for UE-side data collection for beam management is not supported.
Summary of change: Reflect the RAN1 agreements accurately in Section 5.2.1.6 of TS 38.214. Include periodic CSI report for UE-side data collection for beam management.
Consequence if not approved: Incorrect UE behaviour for CPU duration for UE-side data collection for training.
The corresponding final CR in:
(Rel-19, 38.214, NR_AIML_air-Core, CR0751, Cat F) is agreed.
conclusion
There is no RAN1 consensus on the following:
For virtual resource blocks mapping of PDSCH in TS38.211, rate matching of the resource elements in the corresponding physical resource blocks are not performed around the NZP CSI-RS only configured in Set A for CSI report for inference.
Final summary in R1-2603261.
CSI spatial/frequency compression without temporal aspects (“Case 0”)
agreement
For the standardized SQ codebook when NW does not exchange a codebook, support [1/8, 3/8, 5/8, 7/8] for Q=2 and [1/4, 3/4] for Q=1.
agreement
For precoding matrix feedback via two-sided model, support upto 128 ports, upto rank 4 and upto 19 subbands.
agreement
Support two-part UCI for CSI feedback via two-sided model, where
UCI part 1 contains CQI, RI and CRI.
UCI part 2 contains the PMI (i.e., CSI feedback of all layers).
Layer 1 to are mapped to Group 1, Layer to layer are mapped to Group 2.
Note: The bits sequence is mapped based on their indices inside each layer, followed by the bit sequence of the next layer. The layers are ordered from the strongest to the weakest.
agreement
For NW side data collection, support target CSI quantization
Down-selection between 1a (real-imaginary) and 1b (amplitude-phase), i.e., {1a-33, 1b-34}.
Presented in Thursday session.
Potential agreement from session notes in R1-2603273:
For performance monitoring:
Support using paired CSI feedback and target CSI samples for performance monitoring
Support using L3 signaling framework to collect at least target CSI samples.
Detailed signaling upto RAN2
FFS how to associate target CSI sample with CSI feedback sample.
Support using L1 signalling
FFS: Details of L1 signalling
UE assisted monitoring
Target CSI reporting via L1 signaling with legacy PMI codebook
Target CSI reporting using L1 signaling with high resolution quantization of partial target CSI
Strong concern from Nokia and CATT
Nokia and CATT state that Network sides performance monitoring can be supported by implementation means which makes this proposal or any specification impact is not needed.
Other companies claim based on WID, we have to specify performance monitoring.
CSI feedback enhancement, encompassing (two-sided model) [RAN1, RAN2]:
CSI spatial/frequency compression without temporal aspects (“Case 0”),
Specify necessary signalling/mechanism(s) as per the identified potential specification impacts in FS_NR_AIML_Air , including:
Model pairing procedure including ID and applicability reporting
Inference aspects including target CSI type, measurement and report configuration, CQI RI determination, payload determination, quantization configuration codebook, UCI mapping, CSI processing criteria and timeline, priority rules for CSI reports
NW and UE side data collection for training,
Target CSI format
Note The framework defined in BM and CSI prediction use cases could be reused
Specify performance monitoring
agreement
For performance monitoring:
Support using paired CSI feedback and target CSI samples for performance monitoring, and further investigate the feasibility of following options and downselect one,
Option 1: Support using L3 signaling framework to collect target CSI samples.
Companies to report details about how to associate target CSI sample with CSI feedback sample.
Option 2: Support using L1 signalling, considering
UE assisted monitoring
CSI reporting via L1 signaling with legacy PMI codebook
CSI reporting using L1 signaling with high resolution quantization of partial target CSI
Inter-vendor training collaboration for two-sided AI/ML models
agreement
For Option 4-1 under Direction A in AI/ML based CSI compression, when the target CSI is precoding matrix with port-subband domain representation and the target CSI set k is associated with set of CSI feedback set,
Support per-layer CSI feedback payload parameter pair
For layer 1/2/3, support {32, 2}, {64, 2}, {96,2}, {128, 2}, {192, 2}, {32,1}
For layer 4, support {32, 2}, {64, 2}, {96,2}, {32,1}
FFS: The number of layers in the CSI feedback set is <= the number of layers in the target CSI set.
Note: NW may only exchange a subset of the CSI feedback payload from the list.
agreement
For Option 4-1 under Direction A in AI/ML based CSI compression, the performance targets are exchanged per layer per CSI feedback set (), where the CSI feedback set () is the mth out of Mk CSI feedbacks set corresponding to the kth target CSI set.
Presented in Wednesday session.
agreement
For Option 4-1 under Direction A in AI/ML based CSI compression,
One-to-one mapping between pairing ID and exchanged dataset. There is no linkage between different data sets.
Final summary in R1-2602693.
Waveform
agreement
Prioritize the following cases in the RAN1 study on UL coverage improvements through low UL PAPR enhancement for DFT-s-OFDM, based on Table in 5.3.1 of R1-2603312:
FDSS [for π/2 BPSK, QPSK, 16QAM]
Opt1: Transparent filter
Filter defined through transmitter requirement such as spectrum flatness by RAN4
Opt2: non-transparent filter
Filter coefficients specified in RAN1
Note: This includes all the listed FDSS filtering variants
FDSS for [π/2 BPSK, QPSK, 16QAM] with spectral extension
For FDSS part,
Opt1: Transparent filter
Filter defined through transmitter requirement such as spectrum flatness by RAN4
Opt2: non-transparent filter
Filter coefficients specified in RAN1
Note: This includes all the listed variants of the spectrum extension
FDSS for π/2 BPSK with spectral truncation
For FDSS part,
Opt1: Transparent filter
Filter defined through transmitter requirement such as spectrum flatness by RAN4
Opt2: non-transparent filter
Filter coefficients specified in RAN1
Note: This includes all the listed variants of the spectrum truncation
Note: At least one variant of spectral extension, offset-QPSK with smaller DFT size can result in the same signal as the FDSS for π/2 BPSK-ST
Note: companies are encouraged to report whether transparent CFR is used or not
conclusion
The study on the following listed proposals is noted. Further discussion on these is not planned under the waveform agenda item in RAN1 unless tasked by RAN at or after RAN#112.
Observations (with references added on Friday):
Max-rank = 2 for UL DFT-s-OFDM
Companies report negligible SNR loss from DFT-s-OFDM with larger number of aNB Rx antenna elements, such as at least 16 or 32. Link level loss with 4 layers has not been studied. A lower number of aNB antenna elements may result with SNR loss at the receiver
All companies acknowledge that when the UE is Tx power limited, there is a Tx power gain from DFT-s-OFDM, highest reported gain of around 2.5dB.
The system level impact depends on scenario and scheduling strategy due to vastly differing probabilities for UE to be power limited and use rank=2, as well as the used traffic model and the assumed number of aNB Rx antenna elements. The reference setup to compare with varied and had also an impact to the findings, including also system loading, link adaptation, scheduling strategy, the used UE antenna model and the number of aNB Rx antenna elements.
Two companies reported cases with average system level throughput loss [R1-2601827, R1-2602177], of which one company indicated cell edge throughput loss [R1-2602177]. One company reported no average and cell-edge system level throughput gain [R1-2602254], while 6 companies reported cases with average system level throughput gains and/or cell edge throughput gains [R1-2602004, R1-2603056, R1-2602468, R1-2603008, R1-2603286 , R1-2601921].
Codebook for multi-layer UL DFT-s-OFDM
The lower PAPR property of DFT-s-OFDM is diminished with coherent precoders due to mixing of two (or more) layers for each power amplifier.
RAN1#124 agreed to focus the DFT-s-OFDM studies to non-coherent CB only (with the exception of lower number of layers than Tx antennas) for 2Tx UE for waveform evaluation purposes.
Four companies report moderate system level gains for DFT-s-OFDM non-coherent codebook only relative to CP-OFDM non-coherent codebook [R1-2603056, R1-2602468, R1-2603008, R1-2603286], while two companies report system level loss for DFT-s-OFDM non-coherent codebook only relative to CP-OFDM non-coherent codebook [R1-2601827, R1-2602177].
One company reports system level gains also for DFT-s-OFDM with coherent codebook relative to CP-OFDM with coherent codebook [R1-2602468].
Six companies report system level gains for DFT-s-OFDM with non-coherent multi-layer codebook and coherent single-layer codebook relative to CP-OFDM with coherent single/multi-layer codebook [R1-2602426, R1-2602468, R1-2602004, R1-2603008, R1-2603286, R1-2601921], while one company reports no system level gain for DFT-s-OFDM with non-coherent multi-layer codebook and coherent single-layer codebook relative to CP-OFDM with coherent single/multi-layer codebook [R1-2602254].
Dynamic waveform switching
One company observes comparable system level performance for DWS among DFT-s-OFDM for both 1- and 2-layer and CP-OFDM with both 1-layer and 2-layer compared to DWS among DFT-s-OFDM for only 1-layer and CP-OFDM for both 1- and 2-layer for full buffer traffic only and observes gain for non-full buffer traffic [R1-2603286].
One company observes system level loss of DFT-s-OFDM for both 1- and 2-layer compared to DFT-s-OFDM for only 1-layer and CP-OFDM for both 1- and 2-layer with waveform switching [R1-2601827].
One company observes comparable system level performance for DWS among DFT-s-OFDM for both 1- and 2-layer and CP-OFDM with both 1-layer and 2-layer compared to DWS among DFT-s-OFDM for only 1-layer and CP-OFDM for both 1- and 2-layer. [R1-2602254].
One company observes system level performance loss of DFT-s-OFDM for 1-layer and DFT-s-OFDM/CP-OFDM for 2-layer compared to DFT-s-OFDM for only 1-layer and CP-OFDM for both 1-layer and 2-layer with waveform switching [R1-2602177].
Note: this observation is not intended to be captured as it is in TR.
Presented in Friday session
Position changes since RAN1#124
AI-synthesized from contributions · all text is paraphrased
8.1
Maintenance on Artificial Intelligence (AI)/Machine Learning (ML) for NR Air Interface
0 evolved · 9 new
New contributors this meeting
-
Supports zero-padding RS-PAI to 3 bits on PUCCH when nroftransmissionOccasion-r19 results in 1-bit or 2-bit payloads, opposing configuration restrictions that would prohibit values of 1 or 3 because such restrictions hinder the network's ability to detect inaccuracies in specific monitoring occasions. Argues that limiting the network to supporting at least seven occasions reduces visibility into error instances, whereas zero-padding preserves granular monitoring capabilities. Presents a technical case that equivalent information can be obtained via UE-reported measurements on Set A beams, but emphasizes that if RS-PAI is used, zero-padding is preferred. Endorses updating TS 38.214 Clause 5.2.1.6 to include periodic CSI reports for UE-side data collection in CPU duration calculations, reusing existing CPU occupation time definitions for CSI-ReportConfig with reportQuantity none and no TRS-info. Confirms that for UE-sided models, data collection resources are restricted to always-on SSB and P/SP CSI-RS. Notes the absence of consensus on PDSCH rate matching around NZP CSI-RS in Set A for inference.
-
Proposes relaxing legacy PDSCH rate-matching rules in TS 38.211 to exclude NZP CSI-RS resources that are only configured in Set A (for inference or applicability check) or Set B (for applicability check Option B), arguing these virtual resources are not actually transmitted and thus should not waste PDSCH resources. Prefers zero-padding for 1-bit or 2-bit RS-PAI payloads on PUCCH over restricting the number of transmission occasions M, citing simplicity and alignment with existing CSI part 2 padding mechanisms. Requires aligning RRC parameter notations across TS 38.214 and TS 38.212 with TS 38.331, specifically standardizing terms like resourcesForChannelPrediction-r19' and csi-PAI-r19'. Argues that for Option B applicability checks, resources configured for prediction and measurement are only for applicability verification and do not trigger actual measurement or rate-matching behaviors.
-
Opposes the current framework where PDSCH rate matching is tied to the configuration of Set A, arguing it introduces unintended restrictions and negates the fundamental benefit of AI/ML beam management by wasting resources on virtual CSI-RS. Proposes that rate matching behavior should depend on the presence of the CSI-ResourcePeriodicityAndOffset parameter: if configured, rate matching is performed; if absent, rate matching is not performed. Argues that treating virtual CSI-RS resources identically to transmitted ones causes unnecessary performance degradation and constrains UE implementation flexibility.
-
Prefers applying zero-padding to UCI bit sequences for RS-PAI reports on PUCCH when the length is 1 or 2 bits, arguing that restricting monitoring occasions to ensure 3 or 4 bits causes unnecessary resource overhead and constrains gNB configuration flexibility. Proposes adding a separate paragraph in TS 38.214 for the CPU occupation timeline of CSI reports with reportQuantity set to none-bm-r19' to correctly capture existing agreements and maintain consistency with the separate paragraph for none-csi-r19'. This clarification aims to resolve ambiguous UE behavior regarding CPU occupation for UE-side data collection for beam management.
-
Proposes that for monitoring reports, the UE shall drop the report if the linked inference report is deactivated, ensuring no wrong RS-PAI is reported. Requires that P/SP NZP-CSI-RS resources configured for Set A (virtual beams) be available for PDSCH transmission during model inference to prevent unnecessary resource waste from rate-matching. Argues that if a CSI-ReportConfig becomes inapplicable due to UE-side model unavailability, the UE shall transmit a CSI report with an invalid value rather than attempting inference. Supports zero-padding for RS-PAI payloads on PUCCH to handle cases where the payload size is 1 or 2 bits, avoiding restrictions on the number of transmission occasions.
-
Requires relaxing configuration restrictions for Set A resources to allow mixed periodicities and different time domain behaviors, arguing the current restriction that all resources share the same periodicity is too constraining. Proposes clarifying that NZP CSI-RS resources configured only in Set A (or Set B for applicability checks) are not used for PDSCH rate-matching, asserting that rate-matching around virtual CSI-RS causes unnecessary resource waste and should be excluded. Supports zero-padding for RS-PAI payloads smaller than 3 bits on PUCCH, arguing this aligns with NR design principles and avoids restricting nroftransmissionOccasion-r19 values. Requires correcting CPU occupation time definitions in TS 38.214 to include periodic CSI reports for UE-side data collection in beam management, specifying occupation windows based on CSI-RS/SSB resource symbols and PDCCH triggering for semi-persistent, aperiodic, and none-csi-r19' report quantities. Submits a joint CR with NEC and LG to correct TS 38.212 for unsupported PUCCH payload sizes by zero-padding to 3 bits.
-
Requires that configurations resulting in 1 or 2-bit RS-PAI payloads be prevented for P-CSI and SP-CSI on PUCCH to avoid unspecified UE behavior, preferring network-side configuration restrictions over UE-side zero padding to alleviate UE burden. Proposes that the determination of Zref and Z'ref timelines must consider the maximum computation time among both M and Mx updated CSI reports, ensuring AI/ML-based reports are not excluded from timing constraints. Clarifies that for CSI reports with non-zero CPU and APU requirements, if the report is not considered within the available processing units, the UE is not required to update it, thereby preventing inconsistent priority handling where lower-priority reports are updated while higher-priority AI/ML reports are dropped. Proposes reusing the legacy beam management CSI computation time for RS-PAI model monitoring reports to fill the current specification gap.
-
Proposes clarifying TS 38.211 to exclude virtual CSI-RS resources configured only in Set A from PDSCH rate-matching, arguing that these resources are for inference only and do not require measurement, thus preventing resource waste. Requires restricting the configuration of nroftransmissionOccasion-r19 for periodic and semi-persistent CSI reporting on PUCCH, specifically prohibiting values of 1 or 3. This restriction is mandated because NR specifications do not support PUCCH carrying 1 or 2 information bits for RS-PAI reporting, and allowing such configurations would lead to unspecified UE and base station behaviors.
-
Proposes updating TS 38.214 section 5.2.1.6 to correctly capture CPU occupation duration for UE-side data collection for beam management, specifically addressing the omission of periodic CSI reports. Requires that for UE-sided models, only always-on SSB and P/SP CSI-RS are supported as resource types for data collection. Proposes reusing the existing CPU occupation time definition for CSI-ReportConfig with reportQuantity set to none and TRS-info not configured, extending this to the new none-bm-r19' reportQuantity. Specifies that CPU occupation for semi-persistent and aperiodic CSI reports must align with the transmission occasions of CSI-RS/SSB resources for L1-RSRP computation.
Sub-topics
1 agenda items · grouped by 3GPP agenda numbering
8.1
Maintenance on Artificial Intelligence (AI)/Machine Learning (ML) for NR Air Interface
14 contributions
This sub-topic addresses specification maintenance for Rel-19 AI/ML-based beam management, focusing on resolving ambiguities and gaps in PUCCH reporting of RS-Prediction Accuracy Indicator (RS-PAI), PDSCH rate-matching around virtual CSI-RS resources configured only in inference sets, and CPU occupation timeline definitions for UE-side data collection. Companies are discussing whether to zero-pad small RS-PAI payloads to 3 bits or restrict network configurations to avoid 1-bit/2-bit payloads, whether to relax legacy rate-matching rules to prevent resource waste on non-transmitted NZP CSI-RS in Set A and Set B, and how to correctly capture periodic CSI reports within CPU duration calculations for model training data collection.
Company positions
- Samsung ×5 — Requires relaxing configuration restrictions for Set A resources to allow mixed periodicities and different time domain behaviors, arguing the current restriction that all resources share the same periodicity is too constraining. Proposes clarifying that NZP CSI-RS resources configured only in Set A (or Set B for applicability checks) are not used for PDSCH rate-matching, asserting that rate-matching around virtual CSI-RS causes unnecessary resource waste and should be excluded. Supports zero-padding for RS-PAI payloads smaller than 3 bits on PUCCH, arguing this aligns with NR design principles and avoids restricting nroftransmissionOccasion-r19 values. Requires correcting CPU occupation time definitions in TS 38.214 to include periodic CSI reports for UE-side data collection in beam management, specifying occupation windows based on CSI-RS/SSB resource symbols and PDCCH triggering for semi-persistent, aperiodic, and 'none-csi-r19' report quantities. Submits a joint CR with NEC and LG to correct TS 38.212 for unsupported PUCCH payload sizes by zero-padding to 3 bits.
- Ericsson ×2 — Supports zero-padding RS-PAI to 3 bits on PUCCH when nroftransmissionOccasion-r19 results in 1-bit or 2-bit payloads, opposing configuration restrictions that would prohibit values of 1 or 3 because such restrictions hinder the network's ability to detect inaccuracies in specific monitoring occasions. Argues that limiting the network to supporting at least seven occasions reduces visibility into error instances, whereas zero-padding preserves granular monitoring capabilities. Presents a technical case that equivalent information can be obtained via UE-reported measurements on Set A beams, but emphasizes that if RS-PAI is used, zero-padding is preferred. Endorses updating TS 38.214 Clause 5.2.1.6 to include periodic CSI reports for UE-side data collection in CPU duration calculations, reusing existing CPU occupation time definitions for CSI-ReportConfig with reportQuantity 'none' and no TRS-info. Confirms that for UE-sided models, data collection resources are restricted to always-on SSB and P/SP CSI-RS. Notes the absence of consensus on PDSCH rate matching around NZP CSI-RS in Set A for inference.
- Huawei — Proposes relaxing legacy PDSCH rate-matching rules in TS 38.211 to exclude NZP CSI-RS resources that are only configured in Set A (for inference or applicability check) or Set B (for applicability check Option B), arguing these virtual resources are not actually transmitted and thus should not waste PDSCH resources. Prefers zero-padding for 1-bit or 2-bit RS-PAI payloads on PUCCH over restricting the number of transmission occasions M, citing simplicity and alignment with existing CSI part 2 padding mechanisms. Requires aligning RRC parameter notations across TS 38.214 and TS 38.212 with TS 38.331, specifically standardizing terms like 'resourcesForChannelPrediction-r19' and 'csi-PAI-r19'. Argues that for Option B applicability checks, resources configured for prediction and measurement are only for applicability verification and do not trigger actual measurement or rate-matching behaviors.
- InterDigital — Opposes the current framework where PDSCH rate matching is tied to the configuration of Set A, arguing it introduces unintended restrictions and negates the fundamental benefit of AI/ML beam management by wasting resources on virtual CSI-RS. Proposes that rate matching behavior should depend on the presence of the CSI-ResourcePeriodicityAndOffset parameter: if configured, rate matching is performed; if absent, rate matching is not performed. Argues that treating virtual CSI-RS resources identically to transmitted ones causes unnecessary performance degradation and constrains UE implementation flexibility.
- LG Electronics — Prefers applying zero-padding to UCI bit sequences for RS-PAI reports on PUCCH when the length is 1 or 2 bits, arguing that restricting monitoring occasions to ensure 3 or 4 bits causes unnecessary resource overhead and constrains gNB configuration flexibility. Proposes adding a separate paragraph in TS 38.214 for the CPU occupation timeline of CSI reports with reportQuantity set to 'none-bm-r19' to correctly capture existing agreements and maintain consistency with the separate paragraph for 'none-csi-r19'. This clarification aims to resolve ambiguous UE behavior regarding CPU occupation for UE-side data collection for beam management.
- NEC — Proposes that for monitoring reports, the UE shall drop the report if the linked inference report is deactivated, ensuring no wrong RS-PAI is reported. Requires that P/SP NZP-CSI-RS resources configured for Set A (virtual beams) be available for PDSCH transmission during model inference to prevent unnecessary resource waste from rate-matching. Argues that if a CSI-ReportConfig becomes inapplicable due to UE-side model unavailability, the UE shall transmit a CSI report with an invalid value rather than attempting inference. Supports zero-padding for RS-PAI payloads on PUCCH to handle cases where the payload size is 1 or 2 bits, avoiding restrictions on the number of transmission occasions.
- Sharp — Requires that configurations resulting in 1 or 2-bit RS-PAI payloads be prevented for P-CSI and SP-CSI on PUCCH to avoid unspecified UE behavior, preferring network-side configuration restrictions over UE-side zero padding to alleviate UE burden. Proposes that the determination of Zref and Z'ref timelines must consider the maximum computation time among both M and Mx updated CSI reports, ensuring AI/ML-based reports are not excluded from timing constraints. Clarifies that for CSI reports with non-zero CPU and APU requirements, if the report is not considered within the available processing units, the UE is not required to update it, thereby preventing inconsistent priority handling where lower-priority reports are updated while higher-priority AI/ML reports are dropped. Proposes reusing the legacy beam management CSI computation time for RS-PAI model monitoring reports to fill the current specification gap.
- vivo — Proposes clarifying TS 38.211 to exclude virtual CSI-RS resources configured only in Set A from PDSCH rate-matching, arguing that these resources are for inference only and do not require measurement, thus preventing resource waste. Requires restricting the configuration of nroftransmissionOccasion-r19 for periodic and semi-persistent CSI reporting on PUCCH, specifically prohibiting values of 1 or 3. This restriction is mandated because NR specifications do not support PUCCH carrying 1 or 2 information bits for RS-PAI reporting, and allowing such configurations would lead to unspecified UE and base station behaviors.
- ZTE — Proposes updating TS 38.214 section 5.2.1.6 to correctly capture CPU occupation duration for UE-side data collection for beam management, specifically addressing the omission of periodic CSI reports. Requires that for UE-sided models, only always-on SSB and P/SP CSI-RS are supported as resource types for data collection. Proposes reusing the existing CPU occupation time definition for CSI-ReportConfig with reportQuantity set to 'none' and TRS-info not configured, extending this to the new 'none-bm-r19' reportQuantity. Specifies that CPU occupation for semi-persistent and aperiodic CSI reports must align with the transmission occasions of CSI-RS/SSB resources for L1-RSRP computation.
Open issues
- Whether to resolve the 1-bit/2-bit RS-PAI PUCCH payload incompatibility via zero-padding at the UE or via network-side configuration restrictions prohibiting certain nroftransmissionOccasion-r19 values.
- Whether and how to exclude virtual NZP CSI-RS resources configured only in Set A (for inference) or Set B (for applicability checks) from PDSCH rate-matching, with competing proposals ranging from unconditional exclusion to conditional exclusion based on the presence of CSI-ResourcePeriodicityAndOffset.
Contributions
Summary for LS R1-2601764 on capability reporting for PRS Processing Window
This document summarizes the RAN1 discussion regarding LS R1-2601764 on capability reporting for PRS Processing Window (PPW) in the context of AI/ML-based positioning. It captures divergent views from vendors on whether capabilities 58-2-9, 58-2-10, and 58-2-11 should be reported to the gNB, the LMF, or both, with a…
AT&T, acting as the moderator, presents FL Proposal 4-1 stating that FG 58-2-9, 58-2-10, and 58-2-11 should not be reported to the gNB. This position aligns with the architectural principle cited by Huawei and Qualcomm that the gNB should not be aware of the specific UE-based…
Draft reply LS on capability reporting for PRS processing window
CATT clarifies RAN1's stance on capability reporting for PRS Processing Window (PPW) in AI-based positioning to ensure alignment with legacy non-AI positioning mechanisms. The document contains one primary technical clarification regarding which network entities (gNB vs LMF) should receive specific UE capabilities. It…
CATT clarifies that RAN1 does not intend to create misalignment between AI-based and non-AI based positioning regarding PRS measurement or processing. They recommend aligning AI-based and non-AI-based positioning UE features by taking non-AI-based positioning as the basis.…
LS on capability reporting for PRS Processing Window
Ericsson submits a Letter of Submission from RAN2 to RAN1 regarding Release 19 NR_AIML_air capability reporting for Positioning Reference Signal (PRS) Processing Windows. The document contains two primary questions seeking RAN1 feedback on whether specific UE capabilities (58-2-11, 58-2-9, and 58-2-10) should be known…
Ericsson questions whether capability 58-2-11 (Support of more than one activated PRS processing windows across all active DL BWPs) should be known only to the gNB or both the gNB and LMF, citing that legacy capability 27-23 is sent only to the gNB. They further question whether…
Remaining Issues of Rel-19 AIML
This Ericsson contribution addresses remaining specification issues for Rel-19 AI/ML beam management, specifically focusing on the reporting of the RS-Prediction Accuracy Indicator (RS-PAI) on PUCCH. It identifies a conflict where certain configurations result in 1-bit or 2-bit RS-PAI payloads, which are unsupported…
Ericsson supports zero-padding the RS-PAI to 3 bits when nroftransmissionOccasion-r19 results in 1-bit or 2-bit payloads, ensuring compliance with PUCCH constraints that prohibit 1 or 2 information bits apart from HARQ-ACK/SR. They oppose restricting the network configuration by…
Discussion on LS on capability reporting for PRS Processing Window
Ericsson responds to RAN2's inquiry regarding the reporting targets for specific UE capabilities related to PRS Processing Windows (PPW) in NR AIML positioning. The document contains two distinct proposals addressing whether capabilities 58-2-11, 58-2-9, and 58-2-10 should be known by the gNB, the LMF, or both, based…
Ericsson proposes that capability 58-2-11 should be known only to the gNB, arguing that this mirrors the legacy Rel-17 feature which is sent only to the gNB since it impacts the enabling of PPWs via RRC signaling. They further propose that capabilities 58-2-9 and 58-2-10 should…
Draft reply LS on capability reporting for PRS processing window
Ericsson responds to RAN2 regarding capability reporting for Positioning Reference Signal (PRS) Processing Window (PPW) in Rel-19 NR AIML. The document provides definitive answers to two questions, specifying that capability 58-2-11 is known only to the gNB, while capabilities 58-2-9 and 58-2-10 are known to both the…
Ericsson clarifies the visibility of specific UE capabilities for PRS Processing Window (PPW) in the context of NR AIML air interface. They state that capability 58-2-11, which relates to support for more than one activated PRS processing window across all active DL BWPs, should…
Session Notes of AI 8.1
This document serves as the session notes for AI 8.1 at TSG RAN WG1 #124bis, documenting agreements on specification maintenance for AI/ML in the NR air interface. It records the endorsement of two Technical Proposals (TPs) regarding zero-padding for PUCCH CSI reporting and CPU duration definitions for UE-side data…
Ericsson, as the Ad-Hoc Chair, facilitates the endorsement of specification corrections for Rel-19 AI/ML features. They support zero-padding UCI bit sequences to 3 bits in TS 38.212 to ensure PUCCH compatibility when RS-PAI payload is small. They endorse updating TS 38.214…
Maintenance of Rel-19 AI/ML for air interface
This Huawei contribution addresses remaining issues for Rel-19 AI/ML-based beam management, specifically focusing on resource handling for virtual CSI-RS and PUCCH reporting constraints. The document presents four text proposals to relax legacy rate-matching rules for non-transmitted resources in Set A/B, support…
Huawei proposes relaxing legacy PDSCH rate-matching rules in TS 38.211 to exclude NZP CSI-RS resources that are only configured in Set A (for inference or applicability check) or Set B (for applicability check Option B), arguing these virtual resources are not actually…
Discussion on LS reply to RAN2 on capability reporting for PRS Processing Window
This document addresses a Letter of Agreement from RAN2 regarding whether specific UE positioning capabilities (FG 58-2-9, 58-2-10, 58-2-11) for PRS Processing Windows should be reported to the gNB. Huawei argues that reporting these capabilities violates the architectural assumption that the gNB should not be aware…
Huawei opposes reporting FG 58-2-9, FG 58-2-10, and FG 58-2-11 to the gNB, arguing that this violates the general architectural assumption that the gNB should not be aware of the UE-based positioning method selected by the LMF. They present a technical case against duplicate…
Maintenance on Rel-19 AI/ML
InterDigital argues that mandatory PDSCH rate matching for Set A CSI-RS resources in Rel-19 AI/ML beam management negates the efficiency benefits of the feature and wastes resources when transmissions are virtual. The document presents three observations regarding these inefficiencies and two proposals to condition…
InterDigital opposes the current framework where PDSCH rate matching is tied to the configuration of Set A, arguing it introduces unintended restrictions and negates the fundamental benefit of AI/ML beam management by wasting resources on virtual CSI-RS. They propose that rate…
Maintenance on AI/ML for NR air interface
LG Electronics submits two proposals for maintenance on AI/ML for NR air interface, specifically addressing beam management specifications. The document proposes zero-padding for short RS-PAI reports on PUCCH to ensure support for 1 or 2 bit reports and clarifies CPU occupation timelines for UE-side data collection in…
LG Electronics prefers applying zero-padding to UCI bit sequences for RS-PAI reports on PUCCH when the length is 1 or 2 bits, arguing that restricting monitoring occasions to ensure 3 or 4 bits causes unnecessary resource overhead and constrains gNB configuration flexibility.…
Remaining Issues on AIML for NR Air Interface
NEC presents four technical proposals addressing remaining issues in AI/ML-based beam management for the NR air interface, specifically focusing on monitoring report behavior, resource availability, and payload formatting. The document aims to resolve ambiguities regarding linked inference report deactivation, PDSCH…
NEC proposes that for monitoring reports, the UE shall drop the report if the linked inference report is deactivated, ensuring no wrong RS-PAI is reported. They require that P/SP NZP-CSI-RS resources configured for Set A (virtual beams) be available for PDSCH transmission during…
Discussion on Reply LS on capability reporting for PRS Processing Window
This document from Ofinno addresses RAN2's inquiry regarding the visibility of specific UE capabilities (58-2-9, 58-2-10, and 58-2-11) related to PRS processing windows for NR AIML-based positioning. It contains one observation and three proposals, primarily arguing that capability 58-2-11 should only be known to the…
Ofinno argues that UE capability 58-2-11 (support of more than one activated PRS processing window) does not need to be known to the LMF, drawing a parallel to legacy capability 27-23 which is sent only to the gNB. They contend that the LMF's role is limited to requesting the…
Discussion on LS on capability reporting for PRS Processing Window
OPPO provides responses to RAN2 questions regarding capability reporting for PRS Processing Window in the context of AI/ML positioning Case 1. The document contains one main proposal addressing the visibility of specific UE capabilities to the gNB and LMF, aiming to align with legacy positioning procedures.
OPPO proposes that capability 58-2-11, regarding the support of multiple activated PRS processing windows, should be known only to the gNB to maintain alignment with legacy positioning procedures where similar capabilities are gNB-specific. Conversely, OPPO proposes that…
Draft reply on LS on capability reporting for PRS Processing Window
This document is a Liaison Statement reply from RAN1 to RAN2 regarding capability reporting for Positioning Reference Signal (PRS) Processing Window in Release 19. It contains two specific technical determinations clarifying which network entities must receive specific UE capabilities. The document addresses the…
Samsung, representing RAN1, clarifies the distribution requirements for PRS Processing Window capabilities in Release 19. They specify that capability 58-2-11 needs to be informed to the gNB and can be informed to the LMF, establishing a mandatory path to the base station with…
Discussion on capability reporting for PRS Processing Window
Samsung addresses RAN2 inquiries regarding the reporting of UE capabilities for Positioning Reference Signal (PRS) Processing Window (PPW) in the context of AI/ML for NR Air Interface. The document analyzes whether specific capability indications (58-2-9, 58-2-10, and 58-2-11) should be known by the gNB, the LMF, or…
Samsung proposes that capability 58-2-11, which relates to the number of PPWs a UE can handle, must be informed to the gNB to enable accurate configuration, while also allowing it to be informed to the LMF to facilitate better PRS transmission coordination across multiple cells.…
Remaining issue on AI/ML for NR Air Interface
Samsung addresses remaining issues for AI/ML in the NR Air Interface, specifically focusing on beam management configuration restrictions and PUCCH reporting constraints. The document contains three proposals aimed at relaxing periodicity restrictions for Set A resources, clarifying PDSCH rate-matching behavior for…
Samsung argues that the current restriction requiring all resources in Set A to share the same periodicity is too restrictive and proposes relaxing this constraint to allow mixed periodicities. They contend that PDSCH rate-matching around virtual CSI-RS in Set A causes…
FL summary #0 for AI/ML in beam management
This document summarizes the remaining issues for UE-side AI/ML models in beam management, specifically focusing on CSI reporting for performance monitoring, model inference, and processing timelines. It presents approximately 15 distinct proposals and observations across three main technical areas, aiming to resolve…
Samsung proposes adopting zero-padding for RS-PAI payloads on PUCCH to resolve the incompatibility of 1-bit or 2-bit payloads with NR specifications. They support relaxing configuration restrictions for Set A resources, specifically allowing mixed time domain behaviors and…
FL summary #1 for AI/ML in beam management
This document summarizes the remaining issues and proposals for AI/ML-based beam management in NR Rel-19, specifically focusing on UE-side model performance monitoring, inference reporting, and processing timelines. It addresses critical specification gaps regarding PUCCH payload sizes for RS-PAI, PDSCH rate-matching…
Samsung supports the majority view on zero-padding RS-PAI payloads to 3 bits for PUCCH transmission, arguing that padding after CSI multiplexing reduces overhead compared to per-report padding. They propose relaxing the configuration restriction for Set A resources to allow…
Correction on AI/ML for beam management in TS38212
This document contains a single Change Request (CR-0246) submitted by Samsung, NEC, and LG to correct a specification gap in TS 38.212 regarding AI/ML beam management. The proposal addresses the issue where P/SP CSI reporting on PUCCH for performance monitoring may result in an RS-PAI payload of 1 or 2 bits, which is…
Samsung, NEC, and LG propose a correction to TS 38.212 to resolve an unsupported payload size issue for AI/ML beam management. They identify that for P/SP CSI reporting on PUCCH for performance monitoring, the RS-PAI information bit count may fall below 3 bits. Since NR…
Correction on AI/ML for beam management in TS38214
This document presents a single Change Request (CR 0751) to correct the CPU processing duration specifications for UE-side data collection in AI/ML beam management within TS 38.214. It addresses an omission in the current Release 19 specification regarding periodic CSI reports for beam management, ensuring accurate…
Samsung, as moderator, proposes a correction to TS 38.214 Section 5.2.1.6 to accurately reflect RAN1 agreements on CPU processing criteria for AI/ML beam management. They require the inclusion of periodic CSI reports for UE-side data collection, which are currently missing from…
Maintenance on AI/ML for NR Air Interface
Sharp presents four technical proposals to resolve specification maintenance issues for AI/ML-based beam management in NR Rel-19, specifically focusing on RS-PAI reporting constraints, CSI computation timelines, and processing unit allocation. The document addresses gaps in TS 38.214 regarding PUCCH payload sizes for…
Sharp requires that configurations resulting in 1 or 2-bit RS-PAI payloads be prevented for P-CSI and SP-CSI on PUCCH to avoid unspecified UE behavior, preferring network-side configuration restrictions over UE-side zero padding to alleviate UE burden. They propose that the…
Draft reply LS on capability reporting for PRS Processing Window
Spreadtrum argues that for AI/ML-based positioning Case 1, capability 58-2-11 (maximum number of activated PRS Processing Windows) should be signaled only to the gNB, not the LMF, because the gNB solely handles PPW configuration and activation. The document presents two main technical observations: one regarding the…
Spreadtrum proposes that capability 58-2-11 (maximum number of activated PRS Processing Windows) be signaled exclusively to the gNB, arguing that the gNB is the sole entity responsible for mapping PPW requests into actual configurations via RRC signaling and MAC CE activation.…
Maintenance on AI/ML for NR air interface
This document from vivo addresses remaining issues for AI/ML-based beam management in NR Release 19, specifically focusing on PDSCH rate-matching and PUCCH reporting configurations. It contains two technical proposals: one to exclude virtual CSI-RS in Set A from PDSCH rate-matching to save resources, and another to…
vivo proposes clarifying TS 38.211 to exclude virtual CSI-RS resources configured only in Set A from PDSCH rate-matching, arguing that these resources are for inference only and do not require measurement, thus preventing resource waste. They require restricting the…
[Draft] Reply LS on capability reporting for PRS Processing Window
This document is a Liaison Statement reply from RAN1 to RAN2 regarding capability reporting for Positioning Reference Signal (PRS) processing windows in Release 19. It contains one specific technical response addressing RAN2's inquiry about capabilities 58-2-9 and 58-2-10, stating that these capabilities must be known…
ZTE, representing RAN1, responds to RAN2's inquiry regarding UE-based positioning Case 1 capabilities. They assert that the specific capabilities defined in items 58-2-9 and 58-2-10, which relate to the number of activated PRS processing windows and DL PRS buffering capabilities…
Discussion on capability reporting for PRS Processing Window
ZTE addresses RAN2 questions regarding the visibility of UE capabilities for PRS Processing Window (PPW) in NR positioning, specifically for Rel-19 AI/ML features. The document contains two main proposals arguing that specific Feature Groups (FGs) related to multiple activated PPWs and buffering capabilities should be…
ZTE proposes that Feature Groups 27-23 and 58-2-11, which define support for more than one activated PRS processing window across all active DL BWPs, must be known to both the gNB and the LMF. This stance is driven by the NRPPa Measurement Preconfiguration and Activation…
Discussion on maintenance of AI for Air Interface
This document from ZTE addresses maintenance issues for Rel-19 AI use cases, specifically focusing on the CPU occupation duration for UE-side data collection in beam management. It identifies a gap in the current specification where periodic CSI reports for this purpose are not correctly supported, leading to…
ZTE proposes updating TS 38.214 section 5.2.1.6 to correctly capture CPU occupation duration for UE-side data collection for beam management, specifically addressing the omission of periodic CSI reports. They require that for UE-sided models, only always-on SSB and P/SP CSI-RS…