Method for transmitting and receiving CSI report and apparatus therefor

Abstract

A method, according to one embodiment of the present specification, comprises the steps of: receiving configuration information related to channel state information (CSI); transmitting a first CSI report related to prediction; and transmitting a second CSI report related to prediction accuracy. The configuration information includes a first reporting configuration related to the prediction and a second reporting configuration related to the prediction accuracy. The second CSI report is transmitted only when a reception related to performance metric calculation is not later than a defined time point, and the second CSI report is dropped otherwise.

Description

Method and apparatus for transmitting and receiving CSI reports

[0001] This specification relates to a method and apparatus for transmitting and receiving CSI reports.

[0002] Mobile communication systems were developed to provide voice services while ensuring user mobility. However, mobile communication systems have expanded their scope to include data services as well as voice. Currently, due to the explosive increase in traffic leading to resource shortages and users demanding higher-speed services, more advanced mobile communication systems are required.

[0003] The requirements for next-generation mobile communication systems largely include the ability to accommodate explosive data traffic, a dramatic increase in transmission rates per user, a significantly increased number of connected devices, very low end-to-end latency, and high energy efficiency. To achieve this, various technologies are being researched, such as dual connectivity, massive multiple input multiple output (MMIMO), in-band full duplex, non-orthogonal multiple access (NOMA), super wideband support, and device networking.

[0004] Standardization discussions regarding the performance monitoring operation of UE-side AI / ML in the beam management field of the Rel-19 AI / ML WI have been conducted. Specifically, performance monitoring of CSI predictions (e.g., CSI including at least one of predicted RS (predicted CRI, predicted SSBRI), predicted L1-RSRP, and / or predicted PMI) may be performed. As an example, a terminal may transmit a report (e.g., CSI report) related to monitoring the accuracy of predicted information (e.g., predicted CRI, predicted SSBRI, and / or predicted L1-RSRP, etc.). As an example, the report may include a Prediction Accuracy Indicator (e.g., PAI).

[0005] In monitoring reports (e.g., transmission of CSI reports including prediction accuracy indicators), measurements of inference results (e.g., predicted information, predicted CRI, predicted SSBRI, etc.) and monitoring resource(s) are required for performance metric calculation. In this case, if monitoring reports are always performed based on the time point related to the monitoring report, the following problems may occur.

[0006] The terminal may not have received transmission occasion(s) for some monitoring resource(s) prior to the point in time associated with monitoring reporting (e.g., CSI reference resource), or the terminal may not have buffered inference results. Consequently, the terminal may fail to calculate performance metrics (i.e., prediction accuracy indicators, RS-PAI), or it may report performance metrics (e.g., PAI) calculated for fewer transmission occasion(s) than the number of resource-specific transmission occasion(s) expected by the base station. As a result, performance metrics are not reported or the accuracy of reported metrics is degraded, making it difficult to guarantee that subsequent actions based on performance monitoring results are performed at the appropriate timing.

[0007] As mentioned above, if the accuracy of performance metrics reported to monitor predictive performance in AI / ML model-based beam management operations deteriorates, the judgment regarding the reliability of beam prediction results may be distorted. Consequently, the network or terminal may mistakenly perceive predictive performance as superior or inferior to reality, leading to persistent inappropriate beam selection or a reversal to unnecessary beam measurements and legacy beam management operations. This issue increases the instability of beam management operations and can result in reduced energy efficiency by leading to increased measurement and reporting overhead, a rise in retransmission frequency, and increased terminal power consumption.

[0008] The purpose of this specification is to propose a method for solving the aforementioned problems.

[0009] The technical problems to be solved in this specification are not limited to those mentioned above, and other technical problems not mentioned will be clearly understood by those skilled in the art to which this specification belongs from the description below.

[0010] A method according to one embodiment of the present specification for solving the aforementioned problem comprises the steps of receiving configuration information related to Channel State Information (CSI), transmitting a first CSI report related to prediction, and transmitting a second CSI report related to prediction accuracy. The configuration information includes a first report configuration related to the prediction and a second report configuration related to the prediction accuracy. The second CSI report is transmitted only when the reception related to the performance metric calculation is not delayed beyond a defined time, and otherwise, the second CSI report is dropped.

[0011] Since a CSI report related to monitoring accuracy is transmitted only when reception related to performance metric calculation is performed based on a defined point in time, the accuracy of the performance metric can be guaranteed.

[0012] According to the embodiments of this specification, the accuracy of performance metrics can be ensured, thereby guaranteeing that subsequent actions suitable for the monitoring results are performed in a timely manner. Specifically, AI / ML-based beam prediction performance can be reliably evaluated, and the degradation of prediction performance can be accurately detected. This enables adaptive beam measurement and control based on prediction reliability, and reduces unnecessary beam measurements and signal overhead.

[0013] Furthermore, technical benefits such as network energy savings and improved terminal battery efficiency can be expected through enhanced beam management stability, reduced retransmissions, and lower terminal power consumption. Since performance degradation of AI / ML models can be reliably detected through the accurate evaluation of performance metrics, model maintenance, replacement, or calibration actions can be effectively controlled.

[0014] The effects obtainable in this specification are not limited to those mentioned above, and other unmentioned effects will be clearly understood by those skilled in the art to which this specification belongs from the description below.

[0015] Figure 1 is a diagram illustrating the overall functions from the perspective of an AI / ML model.

[0016] Figure 2 illustrates a general form of an AI / ML-related procedure performed between a network and a terminal.

[0017] Figure 3 illustrates an example of AI / ML-based beam management operation.

[0018] Figure 4 illustrates an example of an AI / ML-based CSI measurement / reporting operation.

[0019] Figure 5 illustrates an example of an AI / ML-based positioning operation.

[0020] Figure 6 is a flowchart showing an example of a CSI-related procedure.

[0021] FIG. 7 is a flowchart illustrating a method according to one embodiment of the present specification.

[0022] FIG. 8 is a flowchart illustrating a method according to another embodiment of the present specification.

[0023] FIG. 9 is a drawing showing the configuration of a first device and a second device according to an embodiment of the present specification.

[0024] In this specification, "A or B" may mean "only A," "only B," or "both A and B." Alternatively, in this specification, "A or B" may be interpreted as "A and / or B." For example, in this specification, "A, B or C" may mean "only A," "only B," "only C," or "any combination of A, B and C."

[0025] A slash ( / ) or a comma used in this specification may mean "and / or." For example, "A / B" may mean "A and / or B." Accordingly, "A / B" may mean "only A," "only B," or "both A and B." For example, "A, B, C" may mean "A, B or C."

[0026] In this specification, "at least one of A and B" may mean "only A," "only B," or "both A and B." Additionally, in this specification, the expressions "at least one of A or B" or "at least one of A and / or B" may be interpreted as synonymous with "at least one of A and B."

[0027] Additionally, in this specification, "at least one of A, B and C" may mean "only A," "only B," "only C," or "any combination of A, B and C." Also, "at least one of A, B or C" or "at least one of A, B and / or C" may mean "at least one of A, B and C."

[0028] Additionally, parentheses used in this specification may mean "for example." Specifically, when indicated as "control information (PDCCH)," "PDCCH" may be proposed as an example of "control information." In other words, "control information" in this specification is not limited to "PDCCH," and "PDCCH" may be proposed as an example of "control information." Furthermore, even when indicated as "control information (i.e., PDCCH)," "PDCCH" may be proposed as an example of "control information."

[0029] In the following explanation, 'when, if, in case of' can be replaced with 'based on'.

[0030] Technical features described individually within a single drawing in this specification may be implemented individually or simultaneously.

[0031] Hereinafter, preferred embodiments according to the present specification will be described in detail with reference to the accompanying drawings. The detailed description disclosed below, together with the accompanying drawings, is intended to describe exemplary embodiments of the present specification and is not intended to represent the only embodiment in which the present specification may be practiced. The following detailed description includes specific details to provide a complete understanding of the present specification.

[0032] In this specification, a terminal is a user-side device (user equipment, UE) or a consumer-side device, and may also be referred to as a first node that receives / transmits signals from / to a base station / second node / IAB node / Transmission-Reception Point (TRP). A terminal may correspond to a physical node or a logical node. A terminal may correspond to a user-side endpoint or an intermediate point between other endpoints. In communication between two points not limited to endpoints (including one-to-one / many-to-one / one-to-many / many-to-many communication), a terminal may correspond to a served node. A terminal may be a fixed-location node or a non-fixed-location (or mobile) node.

[0033] In this specification, a Base Station (BS) is a device on the network side and may also be referred to as a second node / IAB node / x-NodeB (x-NodeB, where x may be an abbreviation related to Radio Access Technology (RAT)) / Transmission-Reception Point (TRP). A Base Station may correspond to a physical node or a logical node. A Base Station may correspond to an endpoint on the network side or an intermediate point between other endpoints. In communication between two points not limited to endpoints (including one-to-one / many-to-one / one-to-many / many-to-many communication), a Base Station may correspond to a serving node. A Base Station may be a node with a fixed location or a node with an indefinite location.

[0034] In this specification, higher layer parameters may be set for the terminal, pre-set, or pre-defined. For example, a base station may transmit higher layer parameters to the terminal. For example, the terminal may transmit parameters such as capability to the base station as higher layer parameters. For example, higher layer parameters may be transmitted via RRC (radio resource control) signaling or MAC (medium access control) signaling.

[0035] In this specification, information / state / parameters being "configured" or "pre-configured" may be interpreted as the information / state / parameters being provided / pre-provided to the terminal through pre-defined signaling (e.g., SIB, MAC, RRC) from the base station. In this specification, information / state / parameters being "defined" or "pre-defined" may be interpreted as being known or stored in advance by the base station and the terminal without signaling between the base station and the terminal.

[0036] < AI / ML for Wireless Communication >

[0037] With the advancement of computing technology, artificial intelligence (AI) and machine learning (ML) are being adopted across various industries and technological fields. In the field of wireless communication, various discussions are underway regarding the application of AI models trained on ML; notably, the 3GPP standardization process refers to this as AI / ML. In this specification, we use the term "AI / ML" following the terminology currently in use during the 3GPP standardization discussions; however, "AI / ML" may be referred to by various other terms depending on the progress of standardization and implementation in the future. For example, it may be referred to as a "transmission / reception mode" or a "signal / channel / operation / transmission / reception configuration" set for AI / ML, but is not limited thereto. The meanings of the terms currently used in the 3GPP standardization process are briefly summarized as follows.

[0038] - AI / ML Model: Refers to a data-driven algorithm that applies AI / ML technology to generate a set of outputs containing predictive information and / or decision parameters based on a set of inputs.

[0039] - Data collection: This is the process of collecting data necessary for AI / ML model training, data analysis, and inference from network nodes, management entities, or terminals.

[0040] - AI / ML Training: An online or offline process of training an AI model by learning features and patterns that best represent data and acquire an AI / ML model trained for inference.

[0041] - AI / ML Inference: This is the process of making predictions or deriving decisions based on collected data and AI models using trained AI models. Meanwhile, depending on whether the AI / ML model is configured on both the transmitting and receiving devices or on only one, it can be classified into (i) two-sided models and (ii) one-sided models. In the case of (i) two-sided models, cooperative inference is performed through paired AI / ML models. Cooperative inference refers to cooperation between the network and the UE, where one side performs part of the inference and the other performs the remainder. (ii) One-sided models are divided into UE-side models and network-side models. In the case of one-sided models, inference is performed entirely by the UE / network-side models.

[0042] 1. Life Cycle Management (LCM) for AI / ML models

[0043] For AI / ML models, LCM is a concept that encompasses all overall procedures for the model, such as data collection, model training, model deployment, model inference, model monitoring, and model updates.

[0044] Figure 1 is a diagram illustrating the overall functions from the perspective of an AI / ML model.

[0045] Referring to FIG. 1, a general AI / ML functional framework can be configured to include a data collection function (10), a model training function (20), a management function (30), an inference function (40), and a model storage function (50).

[0046] The Data Collection function (10) is a function that provides input data to the Model Training function (20), Management function (30), and Inference function (40). The Data Collection function (10) performs data preparation and can provide input data processed through data preparation.

[0047] Here, training data (11) refers to data required as input for the AI / ML model training function (20). monitoring data (12) refers to data required as input for the management (30) of the AI / ML model or AI / ML function. inference data (13) refers to data required as input for the AI / ML inference function (30).

[0048] The Model Training function (20) is a function that performs AI / ML model training, validation, and testing, and can generate model performance metrics that can be used as part of the AI / ML model testing procedure. If necessary, the Model Training function (20) can perform data preparation (e.g., data pre-processing and cleaning, forming and transformation) based on the Training Data (11) delivered from the Data Collection function (10).

[0049] Trained / Updated Model (21): If there is a Model Storage function (50), it is used to transfer trained, validated, and tested AI / ML models to the Model Storage function (50) or to transfer updated versions of the models to the Model Storage function (50).

[0050] The Management function (30) is a function that monitors the operation of an AI / ML model or an AI / ML function.

[0051] Management Instruction (32) is information required as input to manage the Inference function (40). The relevant information may include the selection / (de)activation / switching of an AI / ML model or an AI / ML-based function, and may also include a fallback to a non-AI / ML operation (i.e., not relying on the inference process).

[0052] A Model Transfer / Delivery Request (33) can be used to request model(s) from Model Storage (50).

[0053] Performance Feedback / Retraining Request (31) refers to information required as input to Model Training function (20) (e.g., for the purpose of retraining or updating the model).

[0054] The inference function (40) is a function that provides output from the process of applying an AI / ML model or AI / ML function using data (i.e., inference data (13)) provided by the data collection (10) as input. Data preparation (e.g., data preprocessing and cleaning, formatting and transformation) may also be performed based on the inference data (13) delivered by the data collection (10). If necessary, the inference function (40) may also perform data preparation (e.g., data pre-processing and cleaning, forming and transformation) based on the inference data (13) provided by the data collection function (10).

[0055] Inference Output (41) is data used in the Management function (30) to monitor the performance of an AI / ML model or AI / ML function. Inference Output (41) may include the inference output of an AI / ML model generated by the Inference function (30), and the details of the inference output may vary depending on the use case.

[0056] The Model Storage function (50) is a function that stores a trained / updated model that can be used to perform the Inference function (40).

[0057] Model Transfer / Delivery (51) is used to transfer an AI / ML model to an inference function.

[0058] 2. General AI / ML related procedures between the network and the terminal

[0059] Figure 2 illustrates the general form of AI / ML-related procedures performed between a network and a terminal. While Figure 1 examined the LCM from the perspective of an AI / ML model, Figure 2 describes the general form of procedures performed between a terminal and a network from the perspective of signaling / protocols.

[0060] (1) AI / ML related setup procedure

[0061] Referring to FIG. 2, an AI / ML-related configuration procedure may be performed between the network and the terminal (B05). The AI / ML-related configuration procedure may include information exchange through at least one upper-layer signaling between the terminal and the network, and / or prior preparation / subsequent operations at the terminal / network respectively before / after the upper-layer signaling.

[0062] Specifically, the configuration procedure related to AI / ML may include, but is not limited to, at least one of the following: (i) reporting the capability of the AI / ML-related terminal, (ii) data collection, (iii) model training, (iv) model delivery / transmission, (v) selection of AI / ML functions / models, and (vi) configuration of various operations performed based on the AI / ML model (e.g., AI / ML-based CSI / Positioning / Beam Management).

[0063] (i) The terminal can inform the network of its capabilities, such as models and functions related to AI / ML, that it supports through UE Capability reporting. The network can provide AI / ML-related settings to the terminal based on the terminal's capabilities related to AI / ML reported by the terminal.

[0064] (ii) AI / ML-related configuration procedures may include data collection related to the training / inference of AI / ML models and / or the provision of configuration information regarding data collection. The configuration information regarding data collection may relate to how to configure the method / operation of data collection.

[0065] (iii) AI / ML-related configuration procedures may include training AI / ML models online or offline and / or providing configuration information for AI / ML model training. The configuration information for AI / ML model training may relate to how to configure the method / behavior, etc., of training the AI / ML model.

[0066] (iv) AI / ML-related configuration procedures may include transmitting / transmitting configuration information for a model. The configuration information for a model may include parameters that constitute the AI / ML model and / or an identifier (ID) for the AI / ML model.

[0067] The provided AI / ML model may be a model trained by the network or a model that requires self-training at the terminal. Even when a model trained by the network is provided, the terminal may perform fine-tuning or retraining as necessary. Meanwhile, if a model trained by the network is provided, the terminal may provide data for training to the network.

[0068] (v) The configuration procedure related to AI / ML may include the configuration of how to select AI / ML Functionality / models and / or the selection process for AI / ML Functionality / models. In UE-side AI / ML models or two-sided AI / ML models, the selection of the UE part may be performed through instructions / signaling from the network or the terminal may select it itself. The selection of AI / ML Functionality / models may be performed when multiple AI / ML Functionality / models are configured / provided.

[0069] (vi) The configuration procedure related to AI / ML may include configuration information for various inference operations performed based on AI / ML models, e.g., AI / ML-based CSI measurement / reporting, AI / ML-based positioning, and / or AI / ML-based beam management.

[0070] (2) Operation based on inference by AI / ML models

[0071] Referring again to FIG. 2, the network and / or terminal can perform inference of the AI / ML model through the trained AI / ML model and perform various operations based on the inference of the AI / ML model (B10). If the AI / ML model is a one-sided model, the inference of the AI / ML model can be performed at either the network or the terminal where the AI / ML model is configured. If the AI / ML model is a two-sided model, each part of the inference of the AI / ML model can be performed at the network and the terminal, and depending on the implementation, such inference can be performed cooperatively between the network and the terminal.

[0072] (i) Actions performed based on the inference of an AI / ML model may include AI / ML-based CSI measurement / reporting. AI / ML-based CSI measurement / reporting is intended to improve CSI feedback and may be related to overhead reduction / CSI compression, accuracy improvement, and / or CSI prediction.

[0073] (ii) Actions performed based on the inference of an AI / ML model may include AI / ML-based beam management. AI / ML-based beam management may be related to beam prediction in the time domain, reduction of overhead / latency in the spatial domain, and / or improvement of beam selection accuracy.

[0074] (iii) Actions performed based on the inference of an AI / ML model may include AI / ML-based positioning. AI / ML-based positioning may be relevant to improving positioning accuracy in various scenarios, for example, in non-line-of-sight environments.

[0075] (3) Procedures for AI / ML management

[0076] The network and / or terminal can perform procedures for the management of AI / ML Functionality / model or the settings therefor (B15).

[0077] The network and / or terminal may perform monitoring of AI / ML Functionality / model during the AI / ML model inference or operation based thereon (B10) for the management procedure (B15).

[0078] The management procedure may include, for example, at least one of activation / deactivation, switching, model update, and / or fallback operation for AI / ML Functionality / model. For the signaling of the management procedure, various 3GPP signaling schemes, such as RRC, MAC-CE, DCI, etc., may be used.

[0079] As an example of model switching, multiple model groups are configured, and switching between them can be performed based on models having a common model structure or partially common substructures, and models within the same group may be associated with different input / output formats or processing.

[0080] Model updating involves modifying the parameters used by the model to suit channel conditions that change over time, and fine-tuning is an example of model updating.

[0081] Fallback: In a wireless communication system using an AI / ML model, this may refer to the operation of not using the AI / ML model or operating in a pre-configured / defined default mode when the reliability of the AI / ML model decreases due to internal or external environmental factors.

[0082] For example, the decision on whether to perform a management procedure can be made by the network. For instance, the network may decide to perform the management procedure upon network initiation, or the network may decide to perform the management procedure upon terminal initiation and request.

[0083] As another example, the decision on whether to perform a management procedure can be made by the terminal. For instance, the terminal's decision on the management procedure may be triggered when an event condition set by the network is satisfied, performed by reporting the terminal's decision to the network, or performed autonomously by the terminal.

[0084] 3. Specific operation examples based on AI / ML model inference

[0085] (1) Beam management

[0086] Figure 3 illustrates an example of AI / ML-based beam management operation.

[0087] Referring to FIG. 3, the network / terminal can perform a configuration procedure related to AI / ML-based beam management (C05). The network / terminal can perform a configuration procedure for an AI / ML model to be used for AI / ML-based beam management, and an exchange of configuration information for upper-layer signaling for AI / ML-based beam management. For example, at least one of information related to model inference, configuration for a first set / second set beam, monitoring performance, and assistance information for data collection and beam measurement may be signaled.

[0088] The network / terminal can perform measurements on the first set of beams (C10). The beam measurements may be related to RSRP measurements.

[0089] A network / terminal can obtain information about a second set of beams based on measurement results for a first set of beams (C15). For example, the network / terminal can perform AI / ML inference by using the measurement results for the first set of beams as AI / ML input data. Beam ID information may also be additionally provided as AI / ML input data. Information about the second set of beams may correspond to AI / ML output data. The AI / ML output data may be related to, for example, the probability that each beam will become a top-N beam, the predicted RSRP, etc., for predicting future beam quality, but is not limited thereto.

[0090] According to an embodiment, the network / terminal can transmit and receive information about the acquired second set of beams.

[0091] Specifically, AI / ML-based beam management operations may include at least one of the following BM-Case 1 and BM-Case 2.

[0092] - BM-Case 1: Prediction of the second set of DL beams in the spatial domain through the first set of beam measurements

[0093] - BM-Case 2: Prediction of the second set of DL beams in the time domain through the first set of beam measurements

[0094] In BM-Case 1 and / or 2, both AI / ML model training and inference may be performed on the network or on the terminal. The first set of beams and the second set of beams may be different beams. Or the first set of beams may be a subset of the second set of beams. Or, particularly in BM-Case 2, the first set of beams and the second set of beams may be the same beam.

[0095] The report corresponding to the inference of the UE-side model for BM-Case 1 may relate to the RSRP for the predicted top N beams. The report may include, for example, the predicted RSRP values, and as an example, the predicted RSRP values ​​may be reported together with the actual measured RSRP.

[0096] UE-side AI / ML model inference for BM-Case 2 can report inference results for N future time points through a single report. The report for each time point can correspond to the report in BM-Case 1.

[0097] For performance monitoring of the UE-side model for BM-Case 1 / 2, (i) network-side performance monitoring and / or (ii) UE-assisted performance monitoring may be supported. (i) For network-side performance monitoring, the terminal may report information necessary for the network to calculate performance metrics, for example, by reporting measurement results (e.g., RSRP) and / or RS index for a set of resources for monitoring. (ii) For UE-assisted performance monitoring, the terminal may calculate performance metrics.

[0098] With respect to the NW-side model for BM-Case 1 / 2, quantization of the reported RSRP may be supported, for example, differential RSRP reporting may be supported along existing quantization steps and ranges. The reported content may include information on the RSRP and the corresponding upper N beam, where N can be set by the network.

[0099] With respect to the configuration of the first set of beams and the second set of beams of the UE-side model of BM Case-1, two resource sets may be configured separately for each of the first set and the second set, and the resource sets may be provided through CSI reporting settings. The terminal may perform inference / measurement on the resource set of the first set of beams. The terminal may not be expected to perform measurement / inference on the resource set of the second set of beams. The beam information in the inference report may include resource set information for the first set.

[0100] In relation to the UE-side model, the associated ID may be provided through the CSI framework. The terminal may assume identical / similar characteristics for DL ​​transmit beams / sets (lists) for the same associated ID.

[0101] Regarding UE-assisted performance monitoring for the UE-side models of BM-Case 1 and 2, the following methods may be considered.

[0102] i) Compare prediction results based on resources for monitoring and use the top 1 or top K beam prediction accuracy.

[0103] ii) Use RSRP difference information based on RSRP measurements of resources for monitoring and actual RSRP measurements for at least one of the top N prediction beams.

[0104] iii) Use the difference information between the measured RSRP and the predicted RSRP for the corresponding beam of the resources for monitoring.

[0105] iv) Probability information that the predicted beam will become one of the top 1 or N beams

[0106] For reporting inference results for the UE-side model, quantization of RSRP may be supported, and differential RSRP with existing quantization steps may be supported. The scope of RSRP reporting is such that differential RSRP among multiple beams is supported in the case of BM-case 1, and differential RSRP among multiple beams at multiple time points is supported in the case of BM-case 2.

[0107] For BM-Case 2 of the UE-side model, the network can be configured to report inferences about N future times to the terminal.

[0108] (2) CSI prediction and / or compression

[0109] Figure 4 illustrates an example of an AI / ML-based CSI measurement / reporting operation.

[0110] Referring to FIG. 4, the network / terminal can perform a configuration procedure related to AI / ML-based CSI (D05). The network / terminal can perform a configuration procedure for an AI / ML model to be used for AI / ML-based CSI, and for the exchange of configuration information for upper-layer signaling for AI / ML-based CSI measurement / reporting. For example, at least one of information related to model inference, settings for RS / resources to be used for CSI measurement, monitoring performance, data collection, and conditions / resources for CSI reporting may be signaled.

[0111] The terminal can perform CSI measurements based on AI / ML model inference (D10). The AI / ML model used by the terminal for CSI measurements may be a UE-side AI / ML model corresponding to a one-side AI / ML model, or an AI / ML model corresponding to the terminal part of a two-side AI / ML model.

[0112] The terminal may report CSI to the network based on the results of CSI measurements (D15). CSI reporting may be performed periodically or non-periodically depending on the configuration, and in the case of non-period CSI reporting, network instructions (not shown), such as DCI, that trigger it may be additionally signaled. CSI reporting may include AI / ML-based CSI content and may additionally include legacy CSI content (e.g., non-AI / ML-based RI, PMI, CQI, etc.) (depending on the configuration / scheduling). AI / ML-based CSI content may be related to at least one of 1) CSI compression to reduce the overhead of CSI reporting and 2) CSI prediction for future time points in the time domain.

[0113] The network can acquire CSI based on the terminal's CSI report.

[0114] If a two-sided AI / ML model is configured, the network can reconstruct the CSI by using the terminal's CSI report as input data to the AI / ML model configured in the network (D20). The inference (output) of the AI / ML model configured in the network may be the reconstructed CSI. In such a two-sided AI / ML model, the terminal-side AI / ML model part can be understood as a CSI encoder, and the network-side AI / ML model part can be understood as a concept similar to a CSI decoder.

[0115] CSI compression is CSI compression in the spatial-frequency domain and can primarily be based on two-sided AI / ML models. CSI prediction can primarily be based on one-sided, specifically UE-side AI / ML models.

[0116] In CSI compression based on a two-sided AI / ML model, AI / ML model training may include at least one of the following: (i) Type 1, in which the two-sided AI / ML model is jointly trained at either the terminal or the network; (ii) Type 2, in which the terminal and the network each jointly train the corresponding parts of the two-sided AI / ML model; and (iii) Type 3, in which the terminal and the network each separately train the corresponding parts of the two-sided AI / ML model, wherein the training of the terminal is mainly related to CSI generation and the training of the network is mainly related to CSI reconstruction. Joint training means that the CSI generation / reconstruction models are trained in the same loop for forward / backward delays, and separate training may mean a sequential method in which one of the terminals or the network starts training first, and then the other performs training.

[0117] (3) Positioning

[0118] Figure 5 illustrates an example of an AI / ML-based positioning operation.

[0119] Referring to FIG. 5, the network / terminal can perform a setup procedure related to AI / ML-based positioning (E05). The network / terminal can perform measurements for positioning (E10). The measurements for positioning may be related to PRS and / or SRS measurements. Based on the measurement results, the network / terminal can obtain information regarding terminal positioning (E15). For example, the network / terminal can perform AI / ML inference by using the measurement results for PRS / SRS as AI / ML input data. The information regarding terminal positioning may correspond to AI / ML output data. The AI / ML output data may be, for example, terminal location or assistance information that serves as the basis for determining terminal location, but is not limited thereto.

[0120] < CSI Related Actions >

[0121] Channel state information (CSI) may include at least one of a channel quality indicator (CQI), a precoding matrix indicator (PMI), a CSI-RS resource indicator (CRI), an SS / PBCH block resource indicator (SSBRI), a layer indicator (LI), a rank indicator (RI), Layer 1-RSRP (Layer 1-Reference Signal Received Power), and / or Layer 1-SINR (Layer 1-Signal-to-Interference-plus-Noise Ratio).

[0122] In the case of the CSI prediction described below, the CSI related to the prediction may include at least one of the predicted CQI (predicted CQI, P-CQI), predicted PMI (predicted PMI, P-PMI), predicted CRI (predicted CRI, P-CRI), predicted SSBRI (predicted SSBRI, P-SSBRI), predicted LI (predicted LI, P-LI), predicted RI (predicted RI, P-RI), predicted L1-RSRP (predicted L1-RSRP, P-L1-RSRP) and / or predicted L1-SINR (predicted L1-SINR, P-L1-SINR).

[0123] When monitoring the performance / accuracy of the CSI prediction described below, the CSI related to prediction accuracy may include a Prediction Accuracy Indicator (PAI). For example, the PAI may indicate the accuracy of predicted downlink reference signal(s) (e.g., predicted CRI(s) and / or predicted SSBRI(s)), and the PAI may be interpreted / replaced as a Reference Signal-Prediction Accuracy Indicator (RS-PAI). For example, the PAI may indicate the accuracy of predicted CSI (e.g., predicted PMI), and the PAI may be interpreted / replaced as a Channel State Information-Prediction Accuracy Indicator (CSI-PAI).

[0124] Figure 6 is a flowchart showing an example of a CSI-related procedure.

[0125] Referring to FIG. 6, to perform one of the uses of CSI-RS, a terminal (e.g., user equipment, UE) receives configuration information related to CSI from a base station (e.g., general Node B, gNB) via RRC (radio resource control) signaling (S610).

[0126] The configuration information related to the above CSI may include at least one of CSI-IM (interference management) resource information, CSI measurement configuration information, CSI resource configuration information, CSI-RS resource information (e.g., M≥1 CSI-ResourceConfig resource setting), or CSI report configuration information (e.g., N≥1 CSI-ReportConfig reporting setting). As an example, the configuration information may include at least one of one or more CSI resource settings and / or one or more CSI reporting settings.

[0127] For example, the configuration information may include a first CSI resource setting for measurement and a second CSI resource setting for prediction. As a specific example, the measurement related to the prediction of CSI described below may be performed based on the first CSI resource setting. The terminal may perform L1-RSRP measurements on CSI-RS resources or SS / PBCH block resources associated with the first CSI resource setting. As a specific example, the prediction of CSI described below may be performed based on the second CSI resource setting. Based on the L1-RSRP measurements, the terminal may perform predictions on CSI-RS resources or SS / PBCH block resources associated with the second CSI resource setting. In other words, using L1-RSRPs as measurement metrics, the best CRI / best SSBRI (e.g., P-CRI(s), P-SSBRI(s)) may be predicted.

[0128] For example, the above configuration information may include a first CSI reporting setting related to prediction and a second CSI reporting setting related to prediction accuracy.

[0129] Information related to CSI resource configuration can be expressed as CSI-ResourceConfig IE. Information related to CSI resource configuration defines a group including at least one of an NZP (non-zero power) CSI-RS resource set, a CSI-IM resource set, or a CSI-SSB resource set. That is, the information related to CSI resource configuration includes a CSI-RS resource set list, and the CSI-RS resource set list may include at least one of an NZP CSI-RS resource set list, a CSI-IM resource set list, or a CSI-SSB resource set list. A CSI-RS resource set is identified by a CSI-RS resource set ID, and one resource set includes at least one CSI-RS resource. Each CSI-RS resource is identified by a CSI-RS resource ID.

[0130] Information related to CSI report configuration (e.g., CSI-ReportConfig IE) includes a reportConfigType parameter representing time domain behavior and a reportQuantity parameter representing the CSI-related quantity to be reported. The time domain behavior may be periodic, aperiodic, or semi-persistent.

[0131] The above reportQuantity parameter includes the channel quality indicator (CQI), precoding matrix indicator (PMI), CSI-RS resource indicator (CRI), SS / PBCH block resource indicator (SSBRI), layer indicator (LI), rank indicator (RI), L1-RSRP (Layer 1-Reference Signal Received Power), L1-SINR (Layer 1-Signal-to-Interference-plus-Noise Ratio), predicted CQI (P-CQI), predicted PMI (P-PMI), predicted CRI (P-CRI), predicted SSBRI (P-SSBRI), predicted LI (P-LI), predicted RI (P-RI), predicted L1-RSRP (P-L1-RSRP), and / or predicted L1-SINR (predicted It can be set to a value representing at least one of L1-SINR, P-L1-SINR) and / or Prediction Accuracy Indicator (PAI) (or RS-PAI).

[0132] For example, the reportQuantity parameter can be set to cri, ssb-Index, cri-RSRP, or ssb-Index-RSRP. cri represents the CSI-RS resource indicator (CRI). RSRP represents the L1-RSRP (Layer 1-Reference Signal Received Power). ssb-Index represents the SS / PBCH block resource indicator (SSBRI).

[0133] For example, the reportQuantity parameter can be set to p-cri, p-ssb-index, p-cri-RSRP, or p-ssb-index-RSRP. p-cri represents the predicted CRI (predicted CRI, P-CRI). p-ssb-index represents the predicted SSBRI (predicted SSBRI, P-SSBRI). p-cri-RSRP represents the predicted CRI (predicted CRI, P-CRI) and predicted L1-RSRP (predicted L1-RSRP, P-L1-RSRP). p-ssb-index-RSRP represents the predicted SSBRI (predicted SSBRI, P-SSBRI) and predicted L1-RSRP (predicted L1-RSRP, P-L1-RSRP).

[0134] For example, the reportQuantity parameter can be set to pai (or rs-pai). pai (or rs-pai) represents PA (or RS-PAI).

[0135] The measurement resource may include settings for downlink signals and / or downlink resources for which the terminal will perform measurements to determine feedback information. The measurement resource may be set as a set of ZP and / or NZP CSI-RS resources associated with a CSI reporting setting. The NZP CSI-RS resource set may include a CSI-RS set or an SSB set. For example, L1-RSRP may be measured against a CSI-RS set or against an SSB set.

[0136] The terminal measures the CSI based on configuration information related to the above CSI (S620). The CSI measurement may include (1) a process of receiving the terminal's CSI-RS (S621) and (2) a process of computing the CSI through the received CSI-RS (S622). The terminal reports the CSI to the base station (S630).

[0137] resource setting

[0138] Each CSI resource setting 'CSI-ResourceConfig' contains a configuration for S≥1 CSI resource sets (given by the higher layer parameter csi-RS-ResourceSetList). The CSI resource setting corresponds to the CSI-RS-resourcesetlist, where S represents the number of configured CSI-RS resource sets. Here, the list of S≥1 CSI resource sets includes either or both of the NZP CSI-RS resource set(s) and the SS / PBCH block (SSB) set(s) used for L1-RSRP computation, or includes CSI-IM resource set(s).

[0139] Next, one or more CSI resource settings for channel measurement (CM) and interference measurement (IM) are established through higher layer signaling.

[0140] - CSI-IM resource for interference measurement.

[0141] - NZP CSI-RS resources for interference measurement.

[0142] - NZP CSI-RS resources for channel measurement.

[0143] That is, the CMR (channel measurement resource) may be an NZP CSI-RS for CSI acquisition, and the IMR (Interference measurement resource) may be an NZP CSI-RS for CSI-IM and IM.

[0144] Here, CSI-IM (or ZP CSI-RS for IM) is primarily used for inter-cell interference measurements.

[0145] Also, the NZP CSI-RS for IM is mainly used for intra-cell interference measurement from multi-users.

[0146] A UE can assume that the CSI-RS resource(s) for channel measurement set for one CSI reporting and the CSI-IM / NZP CSI-RS resource(s) for interference measurement (when NZP CSI-RS resource(s) are used for interference measurement) have a QCL relationship with respect to 'QCL-TypeD' on a resource-by-resource basis.

[0147] As examined, resource setting can refer to a resource set list.

[0148] For aperiodic CSI, each trigger state set using the higher layer parameter CSI-AperiodicTriggerState is associated with one or more CSI-ReportConfigs, and each CSI-ReportConfig is linked to a periodic, semi-persistent, or aperiodic resource setting.

[0149] One reporting setting (e.g., CSI-ReportConfig) can be associated with up to three resource settings (e.g., CSI-ResourceConfig). For example, one CSI reporting setting may include the ID (e.g., CSI-ResourceConfigId) of at least one CSI resource setting. The at least one CSI resource setting may include a CSI resource setting associated with a measurement.

[0150] Beam Management (BM)

[0151] BM procedures are L1 (layer 1) / L2 (layer 2) procedures for acquiring and maintaining a set of base station (e.g., gNB, TRP, etc.) and / or terminal (e.g., UE) beams that can be used for downlink (DL) and uplink (UL) transmission / reception, and may include the following procedures and terms.

[0152] - Beam measurement: An operation in which a base station or UE measures the characteristics of a received beamforming signal.

[0153] - Beam determination: The operation in which a base station or UE selects its transmit beam (Tx beam) / receive beam (Rx beam).

[0154] - Beam sweeping: An operation that covers a spatial area using transmitting and / or receiving beams for a set time interval in a predetermined manner.

[0155] - Beam report: An operation in which the UE reports information about the beam-formed signal based on beam measurements.

[0156] The BM procedure can be divided into (1) a DL BM procedure using an SS (synchronization signal) / PBCH (physical broadcast channel) Block or CSI-RS, and (2) a UL BM procedure using an SRS (sounding reference signal).

[0157] In addition, each BM procedure may include Tx beam sweeping to determine the Tx beam and Rx beam sweeping to determine the Rx beam.

[0158] DL BM

[0159] The DL BM procedure may include (1) transmission to beamformed DL RS (reference signals) of the base station (e.g., CSI-RS or SS Block (SSB)) and (2) beam reporting of the terminal.

[0160] Here, beam reporting may include preferred DL RS ID(identifier)(s) and the corresponding L1-RSRP(Reference Signal Received Power).

[0161] The above DL RS ID may be SSBRI (SSB Resource Indicator) or CRI (CSI-RS Resource Indicator).

[0162] An example of beam forming using SSB and CSI-RS will be examined in detail below.

[0163] SSB beams and CSI-RS beams can be used for beam measurement. The measurement metric is L1-RSRP per resource / block. SSB is used for coarse beam measurement, while CSI-RS can be used for fine beam measurement. SSB can be used for both Tx beam sweeping and Rx beam sweeping.

[0164] Rx beam sweeping using SSBs can be performed as the UE changes the Rx beam across multiple SSB bursts for the same SSBRI. Here, one SS burst includes one or more SSBs, and one set of SS bursts includes one or more SSB bursts.

[0165] The DL BM procedure is examined below.

[0166] Configuration for beam reporting using SSB is performed during CSI / beam configuration in the RRC connected state (or RRC connected mode).

[0167] - The terminal receives configuration information from the base station. As a specific example, the terminal receives from the base station a CSI-ResourceConfig IE containing a CSI-SSB-ResourceSetList containing SSB resources used for BM.

[0168] Table 1 shows an example of CSI-ResourceConfig IE. As shown in Table 1, BM configuration using SSB is not defined separately, and SSB is configured like a CSI-RS resource.

[0169]

[0170] In Table 1, the csi-SSB-ResourceSetList parameter represents a list of SSB resources used for beam management and reporting in a single CSI-RS resource set. Here, the SSB resource set can be set to {SSBx1, SSBx2, SSBx3, SSBx4, …}. For example, the SSB index can be defined from 0 to 63.

[0171] - The terminal receives a DownLink Reference Signal (DL RS) from the base station. As a specific example, the terminal receives an SSB resource from the base station based on the CSI-SSB-ResourceSetList.

[0172] - The terminal transmits a beam report to the base station. As a specific example, if a CSI-ReportConfig related to reporting on SSBRI (SSB Resource Indicator) and L1-RSRP is configured, the terminal reports the best SSBRI and the corresponding L1-RSRP to the base station.

[0173] That is, if the reportQuantity of the above CSI-ReportConfig IE is set to 'ssb-Index-RSRP', the terminal reports the best SSBRI and the corresponding L1-RSRP to the base station.

[0174] And, if the terminal has a CSI-RS resource configured in the same OFDM symbol(s) as the SSB (SS / PBCH Block) and 'QCL-TypeD' is applicable, the terminal can assume that the CSI-RS and SSB are quasi-co-located in terms of 'QCL-TypeD'.

[0175] Here, the above QCL Type D may mean that the antenna ports are QCL-connected in terms of spatial Rx parameters. When a terminal receives multiple DL antenna ports that are in a QCL Type D relationship, it is acceptable to apply the same receiving beam. Additionally, the terminal does not expect CSI-RS to be established in an RE that overlaps with the RE of the SSB.

[0176] The configuration for beam reporting using CSI-RS is performed in the same manner as the configuration for beam reporting using SSB described above, so a redundant explanation is omitted. The operation of the beam reporting procedure using CSI is described below.

[0177] - The terminal receives configuration information from the base station. As a specific example, the terminal receives from the base station a CSI-ResourceConfig IE containing a CSI-SSB-ResourceSetList containing CSI resources used for BM (e.g., NZP CSI-RS resource set IE).

[0178] - The terminal receives CSI-RS resources within the NZP CSI-RS resource set through different Tx beams (DL spatial domain transmission filters) of the base station.

[0179] - The terminal selects (or determines) the best beam.

[0180] - The terminal reports the ID and associated quality information (e.g., L1-RSRP) for the selected beam to the base station. In this case, the reportQuantity of the CSI report config can be set to 'cri-RSRP'.

[0181] Explanation regarding Rel-17 / 18 beam management >

[0182] In Rel-17, DL DCI (e.g., DCI format 1-1 or 1-2) can indicate both the DL TCI state and the UL TCI state, or it can indicate only the UL TCI state without specifying the DL TCI state. Consequently, the methods used in the existing R15 / R16 for configuring UL beam and power control (PC) are replaced in Rel-17 by the aforementioned method of indicating the UL TCI state. More specifically, in R17, a single UL TCI state can be indicated through the TCI field of the DL DCI; this UL TCI state is applied to all PUSCHs and all PUCCHs after a certain period known as the beam application time, and can be applied to some or all of the indicated SRS resource sets. Additionally, the base station can utilize DCI and / or MAC-CE to perform a terminal common beam update, which performs indication / updates for multiple specific DL / UL channel / RS combinations using a single beam (utilizing joint or separate TCI states). For the target channel / RS of the common beam update, UE-dedicated CORESET and UE-dedicated reception on PDSCH are available for DL, and DG / CG-PUSCH and all or subset of dedicated PUCCH are available for UL, and additionally, AP CSI-RS for tracking / BM and SRS can be set as target channel / RS.In Rel-18, considering the M-TRP environment, the method of indicating multiple UL TCI states (and / or DL ​​TCI states) through the TCI field of DL DCI was standardized, and depending on the S-DCI based M-TRP environment and the M-DCI based M-TRP environment, uplink and downlink resources to which each indicated TCI is applied can be defined / configured.

[0183] In this document, ' / ' means 'and', 'or', or 'and / or' depending on the context.

[0184] In this specification, 'beam' may refer to a source RS for a 'spatial filter' or 'spatial relation', and may be interpreted as a QCL (type-D) RS, a TCI state, or (in the case of an uplink) a spatial relation RS.

[0185] For example, in this specification, 'beam' may refer to a spatial filter determined based on the reference RS or the source RS. The spatial filter may include a spatial domain filter, a spatial domain transmission filter, and a spatial domain receive filter. For example, in this specification, 'beam' may be interpreted or substituted with a reference signal index (RS index), a reference signal resource index (RS resource index), and / or a resource indicator (e.g., RS index, SSB index, CSI-RS resource index, SRS resource index, SSB Resource Indicator (SSBRI), CSI-RS Resource Indicator (CRI), etc.).

[0186] For example, a beam associated with a UL may be referred to as i) a spatial filter (for uplink transmission or uplink reception), ii) a spatial domain filter (for uplink transmission or uplink reception), iii) an uplink spatial domain transmission filter, iv) an uplink spatial domain receive filter, v) an uplink transmission spatial filter (UL Tx spatial filter) or vi) an uplink receive spatial filter (UL Rx spatial filter).

[0187] For example, a beam associated with DL may be referred to as i) a spatial filter (for downlink transmission or downlink reception), ii) a spatial domain filter (for downlink transmission or downlink reception), iii) a downlink spatial domain transmission filter, iv) a downlink spatial domain receive filter, v) a downlink transmission spatial filter (DL Tx spatial filter), or vi) a downlink receive spatial filter (DL Rx spatial filter).

[0188] In NR standards, QCL configuration via TCI state settings and spatial relation configuration are utilized to configure the UL / DL transmit / receive beams of a terminal. In the Rel-15 NR standard, RRC and MAC CE signaling are primarily used for uplink and downlink transmit / receive beams. Dynamic signaling has been permitted only for the PDSCH receive beam by utilizing the TCI state field of the DL grant DCI. A unified TCI framework was introduced through the Rel-17 / 18 NR standards. Specifically, a method was introduced to dynamically manage the common beam by using DCI to indicate the indicated TCI for the receive / transmit beams. Meanwhile, in the Rel-18 AI / ML study item, a study was conducted on performance evaluation and specification impact regarding spatial beam prediction and temporal beam prediction sub-use cases in the field of beam management. This study discussed NW / UE-side AI / ML operations that predict the best beam of Set A based on Set B measurements. In the case of UE-side AI / ML, the behavior of the terminal measuring Set B and reporting the predicted Set A beam can be discussed in the Rel-19 AI / ML work item. In this case, if the terminal's beam prediction performance is poor, actions such as switching the terminal-side AI / ML model / functionality or falling back to non-AI / ML-based conventional beam management instead of AI / ML-based beam management (measurement / reporting) are necessary.

[0189] This specification proposes a performance monitoring method for a terminal-side AI / ML model and proposes an operation in which the terminal reports performance monitoring results to a base station when a specific event occurs.

[0190] < Background related to UE-initiated BM >

[0191] In existing LTE / NR systems, the reporting of terminal CSI / beam information is determined / controlled by the base station / network (except in the case of BFR). This network-initiated / triggered reporting method has a limitation in that terminals must be configured / instructed to send CSI / beam information frequently in environments where the wireless channel is likely to change rapidly. In such environments, problems arise where the overhead of UL resources for CSI / beam reporting and the related DL measurement RS increase, and the terminal's power consumption also increases due to frequent uplink transmissions. Furthermore, the more terminals there are within the cell / TRP coverage area, the greater the UL resource overhead becomes, as UL resources must be allocated to each terminal. To overcome these limitations of the network-initiated / triggered reporting method, the UE-initiated / triggered reporting method or the event-based / triggered reporting method has recently emerged.

[0192] In UE-initiated / triggered reporting or event-based / triggered reporting methods, the terminal decides whether to report and when to report. By performing the report only when necessary (e.g., only when a specific event occurs), UL resource overhead and terminal power consumption can be reduced. Motivated by this, standardization for UE-initiated / triggered beam reporting is scheduled to proceed in NR Rel-19. Furthermore, in 6G communication systems, UE-initiated / triggered or event-based transmission methods may be more actively expanded and applied to ensure the efficient operation of uplink resources.

[0193] In NR systems, representative reporting methods for event-based or UE-initiated / triggered information include SR (scheduling request) and BFR (beam failure recovery). SR reports whether PUSCH allocation is required for UL-SCH transmission, while BFR reports whether a BF has occurred and information related to the new beam. This information is transmitted to the base station via explicit or implicit means (e.g., delivering the new beam index as PRACH resource selection information). The aforementioned SR / BFR information is transmitted either simultaneously or in installments through one or two UL resources (e.g., BFRQ on PUCCH + beam information via MAC-CE on PUSCH).

[0194] In this specification, information transmitted to a network based on the terminal's event and / or via UE-initiated / triggered transmission methods as described above (e.g., SR, BFRQ, new beam information, etc.) is referred to as "event information" for the sake of convenience of explanation. Event information consists of one or more information parts / blocks, and encoding / rate matching / RE mapping may be performed on each part / block unit. Each information part / unit may be transmitted via a different transmission method (e.g., BFRQ via UCI as L1 message, new beam information via MAC-CE as L2 message).

[0195] < Background related to AI / ML beam management >

[0196] In the Rel-18 AI / ML study item, performance analysis and potential specification impact were studied through evaluation when NW and / or UE-side AI / ML models were operating in three use cases: CSI compression / prediction, beam management, and positioning. In particular, for the beam management use case, the study was conducted by dividing the sub-use cases into BM-case1 and BM-case2 to analyze performance and potential specification impact regarding spatial domain beam prediction and temporal beam prediction. The WID objectives of the AI / ML BM, as well as BM-case1 and BM-case2, are summarized in Tables 2 through 4 below.

[0197] - WID goals for AI / ML BM

[0198]

[0199] - BM-case1: Spatial domain downlink beam prediction for beam set A based on measurement results of beam set B

[0200]

[0201] - BM-case2: Temporal downlink beam prediction for Beam Set A based on historical measurement results of Beam Set B

[0202]

[0203] In addition, an example of the operation for data collection of an AI / ML model in a beam management use case is shown in Table 5 below.

[0204]

[0205] In addition, an example of the operation for inference of an AI / ML model in a beam management use case is shown in Table 6 below.

[0206]

[0207] Meanwhile, the Rel-18 AI / ML study discussed NW / UE-sided AI / ML operations that predict the best beam of Set A based on Set B measurements. In the case of UE-sided AI / ML, the terminal needs to measure Set B and report the predicted Set A beam, whereas in the case of NW-sided AI / ML, the terminal needs to report the Set B measurements.

[0208] The standardization agreements for UE-sided AI / ML to date are as follows.

[0209] Agreement

[0210] For UE-side models, at least for BM-Case1, the following is supported regarding the content of the inference result report.

[0211] Option 1: Beam information for the predicted Top K beams within the beam set

[0212] Option 2: Beam information for the predicted Top K beams within the beam set, and the RSRP of the predicted Top K beams

[0213] At least K=1, and for the maximum value, use FFS

[0214] For beam information, FFS

[0215] For the definition of the predicted Top K beam, FFS

[0216] For the definition of the reported RSRP where applicable, FFS

[0217] For other information within the report along with potential down selections among the following options, FFS

[0218] Option 3: Beam information for the predicted Top K beams within the beam set, and probability information for the predicted Top K beams

[0219] Regarding the quantization method of probability information, FFS

[0220] The probability information is the probability that the beam will become the Top 1 or Top K beam.

[0221] Option 4: Beam information for the predicted Top K beams within the beam set, the RSRP of the predicted Top K beams, and the reliability information of the corresponding RSRPs

[0222] Regarding the definition of the reported RSRP, FFS

[0223] Regarding the definition of reliability information and quantization methods, FFS

[0224] Other options are not excluded either.

[0225] Here, the beam set is Set A, which refers to the beams for UE prediction.

[0226] Conclusion

[0227] For the UE-side model, at least during inference, the configuration of Set B (Set B) for measurement is taken from the current CSI framework.

[0228] Agreement

[0229] Regarding UE-side AI / ML model inference, in the case of BM-Case2, one report supports reporting inference results for N (N≥1, FFS for N) future time points.

[0230] The inference result information for a given point in time is identical to one report in BM-Case1.

[0231] Note: Overhead reduction is not excluded.

[0232] Details are on FFS.

[0233] Agreement

[0234] Regarding the RSRP of the predicted Top K beam among the inference result reports for the UE-side model of BM-Case1, if applicable, the following options are additionally investigated.

[0235] Option A: Predicted RSRP

[0236] Option B: Predicted RSRP if the beam is not configured for the corresponding measurement, measured L1-RSRP if the beam is configured for the corresponding measurement

[0237] The predicted RSRP is based on AI / ML output.

[0238] Note: Supporting both Option A and Option B is not excluded.

[0239] Agreement

[0240] For the UE-side model, at least for BM Case-1, CSI-ReportConfig is used for the inference result reporting configuration.

[0241] For details within CSI-ReportConfig, consider FFS, at a minimum, the following:

[0242] Alternative 1: One CSI-ResourceConfigId is configured for Set B.

[0243] FFS: How can the UE determine information about Set A?

[0244] Alternative 2: A single CSI-ResourceConfigId is configured for both Set A and Set B

[0245] FFS: How to configure resource sets of Set A and Set B in CSI-ResourceConfig

[0246] Alternative 3: Separate CSI-ResourceConfigIds are configured for Set A and Set B, respectively.

[0247] Alternative 4: A single CSI-ResourceConfigId is configured for Set B, and Set A is configured using a separate set of resources not represented by the CSI-ResourceConfigId.

[0248] FFS: How to configure / direct a separate set of resources for Set A

[0249] Note: Using separate CSI-ReportConfigs for Set A and Set B is also not excluded.

[0250] Note: Measurements are not performed on Set A, and are performed only on Set B according to CSI-ReportConfig.

[0251] Regarding the association between Set A and Set B, regardless of the presence or absence of additional IE, FFS.

[0252] Other necessary components are not excluded.

[0253] Agreement

[0254] For UE-side AI / ML models in BM-Case1 and BM-Case2:

[0255] Support Type 1 Performance Monitoring, includes the following two options:

[0256] Option 1 (NW-side performance monitoring):

[0257] UE sends reports to NW (to calculate performance metrics in NW)

[0258] Measurement results from resource sets for monitoring (e.g., L1-RSRP and / or RS index) are supported as report content.

[0259] Other content is FFS

[0260] The report is set / triggered by at least NW

[0261] Note: This may or may not have an additional spec impact.

[0262] Option 2 (UE-supported performance monitoring):

[0263] UE calculates performance metrics

[0264] Regarding how to report and what to report, FFS

[0265] Whether to trigger reporting based on events for Option 1 and / or Option 2 is FFS

[0266] FFS Type 2 Performance Monitoring

[0267] Agreement

[0268] The following working assumptions have been established.

[0269] Working Assumption

[0270] In the inference result report for the UE-side model of BM-Case 2, the predicted RSRP of the beam is the predicted RSRP, and this predicted RSRP is based on the AI / ML output.

[0271] Agreement

[0272] For UE-side models, at least for the quantization of RSRP values ​​in inference result reports, the following is supported:

[0273] Support for differential RSRP reporting using existing quantization steps and ranges for L1-RSRP reporting

[0274] For BM-Case1, differential RSRP reporting between multiple beams is supported.

[0275] For BM-Case2, support for differential RSRP reporting between multiple beams across multiple time points.

[0276] Details are FFS

[0277] Agreement

[0278] For the UE-side model, at least in the case of BM Case-1, in the inference result report

[0279] In the CSI report configuration, two resource sets can be configured separately for Set A and Set B.

[0280] Whether to support configuring a resource set solely for Set B is FFS.

[0281] The UE performs measurements on the resource set of Set B for inference, and the UE is not expected to measure the resource set of Set A for inference.

[0282] The beam information in the inference report refers to the resource set of Set A.

[0283] Agreement

[0284] With respect to the UE-side AI / ML models in BM-Case1 and BM-Case2, for Option 2 (UE-supported performance monitoring), further review is conducted, including at least the following alternatives:

[0285] Alternative 1: Compare the Top 1 or Top K beams based on prediction results and measurements from resource sets / resources for monitoring, along with the presence or absence of margins for Top 1 or Top K beam prediction accuracy.

[0286] Alternative 2: Resource set for actual L1-RSRP measurements of one or more predicted Top K beams and monitoring / L1-RSRP difference information based on L1-RSRP measurements from resources

[0287] Alternative 3: RSRP difference information between the predicted RSRP and the measured L1-RSRP of the resource set / corresponding beam(s) of the resource for monitoring

[0288] Note: Resources of Set B for monitoring are not excluded and can be studied.

[0289] Note: This applies only if the model can predict RSRP.

[0290] Alternative 4: Probability information that the predicted beam(s) will become the Top 1 or Top K beams

[0291] Note: This applies only when the model can generate probability information.

[0292] FFS: For Alternatives 1 / 2 / 3, further review the details regarding how to configure resource sets / resources for monitoring.

[0293] Example: Whether / method to use the entire set of Set A for measurement. If not used, how to acquire measurements from the predicted Top 1 or Top K beams to calculate prediction accuracy or RSRP difference.

[0294] For all alternatives, we investigate whether performance information is calculated on a sample-by-sample basis (one-shot) or on a sample set basis (window).

[0295] Agreement

[0296] For the UE-side model of BM-Case 2, to report inference results, NW supports configuring the UE for N future points in time where applicable.

[0297] FFS: How to determine the reference time for those points in time

[0298] FFS: Predictable duration value at time N

[0299] Agreement

[0300] For UE-side AI / ML models in BM-Case1 and BM-Case2, in the case of Option 2 (UE-supported performance monitoring),

[0301] Support at least the following alternatives: Determine Top 1 or Top K beam prediction accuracy (with or without margins) by comparing the prediction results with the Top 1 or Top K beams based on measurements from the resource set / resources.

[0302] FFS: Detailed definition of the metric, including whether to configure or define a window for calculation

[0303] FFS: Includes other details related to how to configure resource sets / resources for monitoring, e.g.

[0304] Example: Whether / how to use the entire set of Set A for measurement. If the entire Set A is not configured, whether / how to define a metric.

[0305] FFS: Other Alternatives

[0306] Agreement

[0307] In BM-Case 2 of the UE-side model, the reference time of the earliest time instance for the prediction result considers at least the following potential down-selection alternatives:

[0308] Option 1: Based on the UL slot for reporting

[0309] Option 2: Based on CSI reference resources corresponding to the report

[0310] Option 3: Based on the latest transmission time of the CSI-RS / SSB resource within Set B for measurement for reporting, and this transmission time is not later than the CSI reference resource

[0311] Agreement

[0312] For UE-side AI / ML models, for BM-Case1, at least for inference, and for at least Set B, the following CSI-RS resource types for CMR are supported:

[0313] Periodic (P) CSI-RS

[0314] Semi-persistent (SP) CSI-RS

[0315] Aperiodic (AP) CSI-RS

[0316] For UE-side AI / ML models, for BM-Case 2, at least for inference, and for at least Set B, the following CSI-RS resource types for CMR are supported:

[0317] Periodic (P) CSI-RS

[0318] Semi-persistent (SP) CSI-RS

[0319] FFS: Aperiodic (AP) CSI-RS

[0320] Note: The above CSI-RS resources refer to resources used for beam management.

[0321] Agreement

[0322] For at least UE-side model monitoring of Monitoring Type 1 Option 2 (if applicable), consider at least the following options and include potential down-selection for monitoring configuration:

[0323] Option 1: Resource set(s) for monitoring and reporting configuration are configured within the CSI reporting configuration used for inference (if applicable).

[0324] FFS: Resource set(s) for monitoring

[0325] The UE measures resource set(s) for monitoring

[0326] FFS: When / how to report monitoring results

[0327] Option 2: Dedicated resource set(s) and reporting configuration for monitoring are configured within the dedicated CSI reporting configuration used for monitoring.

[0328] The dedicated reporting configuration used for monitoring is linked to the inference reporting configuration.

[0329] FFS: A method to check connectivity between RSs within resource set(s) for monitoring and Set A beams.

[0330] The UE measures resource set(s) for monitoring

[0331] FFS: When to report monitoring results

[0332] As mentioned above, in NR standards, QCL configuration via TCI state settings and spatialRelation configuration are utilized to configure the uplink and downlink receiver and transmitter beams of a terminal. In the Rel-15 NR standard, RRC and MAC CE signaling were primarily used for uplink and downlink receiver and transmitter beams, and dynamic signaling was permitted only for the PDSCH receiver beam by utilizing the TCI state field of the DL grant DCI. With the introduction of the unified TCI framework through the Rel-17 / 18 NR standards, a method was introduced to dynamically manage the common beam by indicating the TCI using DCI for receiver and transmitter beams. Meanwhile, in the Rel-18 AI / ML study item, a study was conducted on performance evaluation and specification impact regarding spatial beam prediction and temporal beam prediction sub-use cases in the field of beam management.

[0333] This study discussed NW / UE-sided AI / ML operations that predict the best beam of Set A based on Set B measurements. In the case of UE-sided AI / ML, the terminal needs to measure Set B and report the predicted Set A beam, while in the case of NW-sided AI / ML, the terminal needs to report the Set B measurements.

[0334] Additionally, BM-case1 and BM-case2 are supported for UE-sided AI / ML operations. BM-case1 is an operation for spatial domain DL Tx beam prediction (e.g., operation when the upper layer parameter nroftimeinstance is not set), and BM-case2 is an operation for temporal DL Tx beam prediction (e.g., operation when the upper layer parameter nroftimeinstance is set). Meanwhile, in Rel-19, Set A and Set B can be configured for the CSI report configuration for the inference result report (e.g., a CSI report containing predicted information (P-CRI, P-SSBRI, P-L1-RSRP)) in the BM-case1 and BM-case2 scenarios. In other words, two resource configurations connected to the CSI report configuration can be configured. The two resource configurations may include a first resource configuration for measurement (e.g., Set B configuration) and a second resource configuration for prediction (e.g., Set A configuration). Consensus was reached regarding the time domain behavior of CSI-RS that can be set as Set B.

[0335] In addition, discussions are underway regarding how to configure reports for performance monitoring during the DL Tx beam prediction operation of UE-sided AI / ML, and how to define metrics for performance monitoring.

[0336] Specifically, performance monitoring of AI / ML models / functionalities on the terminal side can be divided based on the monitoring results into whether the base station or the terminal makes the Life Cycle Management (LCM) decision for the said AI / ML model / functionality. In Rel-18 / 19, if the base station makes the LCM decision, it is defined as Type 1 performance monitoring, and if the terminal makes the LCM decision, it is defined as Type 2 performance monitoring. Type 1 monitoring can be further subdivided as follows.

[0337] Type 1 monitoring can be divided into i) Type 1 - Option 1 performance monitoring, which is an operation in which the base station side performs performance monitoring (by receiving the answer sheet for Set A from the terminal), and ii) Type 1 - Option 2 performance monitoring, in which the base station side performs performance monitoring but the terminal calculates and reports a performance metric (by verifying the answer sheet for Set A).

[0338] In addition, referring to the last agreement above, in Type 1 Option 2 of UE-side model monitoring where the terminal calculates and reports performance metrics, Option 1 and Option 2 are considered as methods for the report configuration for performance monitoring. Option 1 is a method in which the resource set for monitoring is also configured in the report configuration for inference. Option 2 is a method in which monitoring is performed by configuring a dedicated resource set in a separate report configuration (for performance monitoring purposes) independently of the report configuration for inference.

[0339] In the case of Option 1, Set A and Set B are configured in the report configuration for inference. The base station may set the pre-configured Set A (or a subset of Set A) as the resource set for monitoring, or configure a separate resource set other than Set A and Set B in the report configuration for inference. Based on this configuration, the terminal can perform performance monitoring of the AI / ML model while performing inference.

[0340] In the case of Option 2, a dedicated report configuration and a dedicated resource set are utilized for performance monitoring. Based on these settings, the terminal can perform performance monitoring of an AI / ML model. In this case, signaling is required to connect the dedicated report configuration with the corresponding report configuration for inference. Additionally, additional information regarding the relationship between the dedicated resource set and the beams of Set A, which serve as the ground truth, and related signaling are additionally required.

[0341] In this specification, a method for setting a performance monitoring related report when a terminal performs DL Tx beam prediction of BM-case1 / BM-case2 using UE-sided AI / ML is proposed, and a subsequent terminal operation is proposed.

[0342] In this specification, ' / ' may be interpreted as 'and', 'or', or 'and / or' depending on the context.

[0343] Proposal 1

[0344] The base station can set the resource set(s) for monitoring in the report configuration for inference (similar to Option 1 among the methods for report configuration for performance monitoring described above). The terminal can report the inference result using the report configuration, and the terminal can also report the performance monitoring result.

[0345] For example, the resource set(s) for monitoring may be i) Set A set in the report configuration for the inference or ii) a subset of Set A.

[0346] For example, the above performance monitoring result may be information based on a performance monitoring reporting method. As a specific example, the above reporting method may be a) or b) below.

[0347] a) A method in which the terminal reports measurement results for Set A and the base station calculates the metric (e.g., Option 1 of Type 1 performance monitoring)

[0348] b) A method in which the terminal performs measurements on Set A and calculates and reports performance metrics (e.g., Option 2 of Type 1 performance monitoring)

[0349] According to the reporting method described above, the performance monitoring result may include at least one of the following 1) to 5).

[0350] 1) Actual measurement results for Set A or a subset of Set A (e.g., actual measured Top-K beam (+ corresponding L1-RSRP value))

[0351] 2) Calculated performance metric value

[0352] 3) Information on whether the calculated performance metric value passes a predefined threshold (e.g., whether an event occurred)

[0353] 4) (Regarding Type 2 performance monitoring) Recommendation of LCM actions for the AI / ML model / functionality related to the inference based on the corresponding metric value (e.g., continue the model, switch the model, deactivate the model, or fallback to legacy beam report, etc.)

[0354] 5) LCM Decision Details (Regarding Type 2 Performance Monitoring)

[0355] In the following, Proposal 1-1 describes a method for reporting inference results (e.g., prediction-related information, P-CRI, P-SSBRI, P-L1-RSRP) and performance monitoring results (e.g., prediction accuracy indicator, PAI) together by utilizing the above-mentioned report configuration for inference (e.g., prediction-related reporting settings).

[0356] Proposal 1-1

[0357] Based on the report configuration for the inference in Proposal 1 above, the inference result and the performance monitoring result may be reported together. In this case, the transmission period of the resource set corresponding to Set A (or / and the terminal's reception period) may be longer than the transmission period of the resource set corresponding to Set B (or / and the terminal's reception period) (e.g., transmission period related to Set A > transmission period related to Set B). This takes into account the following technical considerations. When the terminal performs only inference, it is sufficient to measure only Set B without needing to measure Set A and report the predicted Set A Top-K beam corresponding to the AI / ML output. To prevent unnecessary base station transmission and terminal reception of the resource set corresponding to Set A, the transmission period related to Set A may be set / defined to be longer than the transmission period related to Set B.

[0358] However, when the terminal measures Set A corresponding to a longer period, ambiguity arises regarding the terminal's operation regarding at which reporting point the performance monitoring result should be reported. Additionally, if the inference result and the performance monitoring result are always reported together without defined criteria, the UL resource utilization and the accuracy of the monitoring results may be degraded. Embodiments for solving this problem 1 are described below. In this specification, the expression 'resource set (or resource) is transmitted / received' may be interpreted / replaced with 'Reference Signal (RS)(s) are transmitted / received (by the base station / terminal) based on the resource set (or resource).

[0359] Example 1 for solving Problem 1

[0360] The base station may set a specific valid period for reporting performance monitoring results in the terminal in the report configuration for the above-mentioned inference. If a resource set related to Set A is transmitted or received within the said valid period, the terminal may report the inference result and the performance monitoring result together. For example, a terminal (configured / defined to transmit a report containing the inference result at each reporting time) may transmit a report including the inference result and a performance monitoring report (based on the inference result and the reception of Set A) in addition to the inference result report at the first (valid) reporting time (in the time domain) after the time of receiving Set A.

[0361] Example 2 for solving Problem 1

[0362] The base station may set a specific valid period for reporting performance monitoring results in the report configuration for the above inference. If the reporting cycle of the above report configuration arrives within the said valid period, the terminal may report the inference result and the performance monitoring result together. For example, a terminal (configured / defined to transmit a report containing the inference result at each reporting cycle) may transmit a report that includes the inference result based on the Set A measurement immediately prior to the above reporting cycle (time domain), in addition to the performance monitoring report (based on the inference result and the reception of the said Set A).

[0363] Example 3 for solving Problem 1

[0364] The base station may set a specific valid period for reporting a performance monitoring result in the report configuration for the above inference. i) If a resource set related to Set A is transmitted / received within the said valid period, and ii) if the reporting cycle of the said report configuration arrives within the said period (condition: arrival of the reporting cycle after receiving Set A), the terminal may report the inference result and the performance monitoring result together. For example, a terminal (configured / defined to transmit a report containing the inference result at every reporting cycle) may transmit a report that includes the inference result report and a performance monitoring report (based on the inference result and the reception of Set A) in addition to the inference result report at the time of reporting after receiving the said Set A.

[0365] As a specific example of the above embodiments 1 / 2 / 3, it may be assumed that the transmission period of the resource set associated with Set A is 100 ms, and the transmission period of the resource set associated with Set B and the reporting period of the report configuration are 20 ms. In this case, for every transmission period (100 ms) of the resource set associated with Set A, the specific valid period may be set / defined with a length of 10 ms near the time of transmission / reception of the resource set associated with Set A. Depending on the conditions of each of the above embodiments, the terminal may perform inference result reporting and performance monitoring reporting together.

[0366] Example 4 for solving Problem 1

[0367] In the report configuration for the above inference, after a certain period of time (e.g., X symbols / slots) from the Set A transmission / reception time (e.g., symbol / slot), the terminal may report the inference result and the performance monitoring result together. For example, in the report configuration for the above inference, the performance monitoring result may be reported together by reporting the earliest (valid) inference result after X = 0, 1, 2, ... (symbol / slot) time from the Set A transmission / reception time (e.g., symbol / slot). For example, the X value may be set / instructed by the base station. For example, the X value may be predefined between the terminal and the base station.

[0368] Example 5 for solving Problem 1

[0369] In the report configuration for the above inference, S slots (where S is a natural number) can be determined, defined, or set as a valid period starting from the time of transmission / reception of Set A (e.g., slot). If the terminal performs an (inference) report related to the report configuration within the above valid period, the terminal may send a performance monitoring result (based on the reception of Set A) along with the inference result report. If the terminal does not perform an (inference) report within the above valid period, the terminal may not send the performance monitoring result. In other words, if the reporting time falls outside the above valid period, the terminal may report only the inference result.

[0370] Example 6 for solving Problem 1

[0371] In the report configuration for the above inference, whenever the inference result reporting cycle reaches B times, the terminal may report the inference result and the performance monitoring result together (B is a natural number).

[0372] For example, whenever the above reporting cycle reaches its Bth, the terminal may transmit a performance monitoring result (based on the reception of Set A) along with the inference result related to the report configuration.

[0373] For example, the above B value may be set to a terminal by a base station. For example, the B value may be determined / defined according to the transmission period of Set A (and Set B). For example, the B value may be defined / determined as ceil(transmission period of Set A / transmission period of Set B). For example, the B value may be defined / determined as floor(transmission period of Set A / transmission period of Set B). For example, the B value may be defined / determined based on ceil(transmission period of Set A / transmission period of Set B) and floor(transmission period of Set A / transmission period of Set B).

[0374] For example, in the above embodiments 1 to 6, the time of transmission / reception of Set A (e.g., symbol / slot) may be the time when the resource located first in time among the resources in the resource set associated with Set A is transmitted / received.

[0375] For example, in the above embodiments 1 to 6, the time of transmission / reception of Set A (e.g., symbol / slot) may be the time when the resource located last in time among the resources in the resource set associated with Set A is transmitted / received.

[0376] For example, in the above embodiments, whether to additionally report performance monitoring in the report configuration for inference can be turned on / off by base station settings (e.g., RRC / MAC CE / DCI).

[0377] For example, in the above embodiments, Set A can be replaced with a subset of Set A.

[0378] For example, in the above embodiments, the performance monitoring report may not be performed at every valid period. As a specific example, a single performance monitoring report within a single valid period may be an excessively instantaneous metric value, as it may be related to a metric for a single inference result at that point in time. Therefore, whenever N valid periods arrive (N is a natural number), the performance monitoring result of the above embodiments may be reported by the terminal (as a metric calculated value for N inference results). In other words, whenever N valid periods (accompanying the reporting cycle of the inference result) arrive, the terminal may report the performance monitoring result together with the inference result. The performance monitoring result may be based on metric(s) calculated / determined based on N inference results.

[0379] Since the valid period and the N value are set by the base station in the above operations, the base station can determine whether only the inference result is reported at a given reporting time and whether the performance monitoring result is also reported at a given reporting time. Therefore, regarding changes in the reporting payload size or / and changes in PUSCH / PUCCH resources based on whether the performance monitoring result is included, the base station can adaptively receive the corresponding report.

[0380] For example, an event regarding the performance monitoring result report can be configured on the terminal by the base station. For example, the event regarding the performance monitoring result report can be predefined. The terminal can perform the performance monitoring result report within a valid period only when the event configured / defined as above occurs (only when the conditions related to the event are satisfied).

[0381] As a specific example, if the metric calculated in each of the N valid periods is summed (the metric value for the N inference results) and is below or above a predefined threshold, the terminal can perform a report including the performance monitoring result when the N valid periods arrive. At this time, since the base station cannot know whether an event has occurred on the terminal side for each of the N valid periods, the base station can perform blind detection / decoding on the terminal report during valid periods when there is a possibility that the event report will be performed, on two types of reports: one reporting payload size in which only the inference result is reported, and another reporting payload size in which the performance monitoring result is also included.

[0382] Problem 2

[0383] In the above proposal 1, regarding the report configuration for inference, there are the following two reporting instances.

[0384] i) A reporting instance where the terminal performs only inference result reporting

[0385] ii) A reporting instance where the terminal performs performance monitoring result reporting in addition to inference result reporting

[0386] Accordingly, the reporting payload size may vary for each reporting instance of the report configuration. In this case, Problem 2 may occur, where the reported contents (e.g., inference result & performance monitoring result) exceed the maximum payload size of the PUCCH / PUSCH set for reporting related to the report configuration. Proposal 2 below describes a method to resolve Problem 2.

[0387] Proposal 2

[0388] When a terminal reports inference results and performance monitoring results together using an inference-related report configuration, the payload size associated with the report may exceed the maximum payload size of the PUCCH / PUSCH set for the report. The terminal may drop or omit specific reporting contents based on the following priority rule.

[0389] For example, the priority of reporting contents may be monitoring result > inference result. (Partial)drop / omission of the above inference result may be performed based on the following examples.

[0390] For example, in the case of inference results related to Top-K predicted results, the priority can be defined as Top-K < Top-(K-1) < .. < Top-1. The terminal can omit reporting information related to Top-K beams starting with the lowest priority. Specifically, the terminal can perform omissions in order of lowest priority (e.g., omission of reporting information related to Top-K, Top-(K-1..).

[0391] For example, in the relevant reporting instance, the terminal can drop / omission all inference result reports and perform only monitoring result reports.

[0392] Additionally, it can be assumed that the inference result and the measurement result related to Set A are the same. For example, it can be assumed that the predicted Top-K beams and the actual measured Top-K beams are all the same (i.e., the predicted beam accuracy is perfect) (the performance metric score is perfect). In such a case, in a reporting instance where monitoring reporting is also performed, the terminal may perform the report as follows. For example, the terminal may report only the information that it is perfect (e.g., O / X 1 bit) as the content of the performance monitoring result report. In other words, the terminal may report the inference result and the aforementioned 1 bit. For example, the terminal may omit the monitoring report itself. In this case, even if the report is omitted, since the base station recognizes that the time is a reporting instance where monitoring reporting is also performed, it may interpret / consider the terminal's intention of the report as the metric being perfect and operate accordingly.

[0393] The embodiments of the above proposals 1 and 2 may be operated by a combination of specific embodiments.

[0394] The embodiments of the above proposals 1 and 2 are applicable to Option 2 as a method for a report configuration for performance monitoring in Type 1 Option 2 of UE-side model monitoring. According to Option 2, a dedicated resource set is set as the resource set for monitoring, and a dedicated report configuration separate from the inference-related report configuration is set as the report configuration for performance monitoring.

[0395] Below, we examine examples for troubleshooting when Option 2 is supported among the report configuration methods for performance monitoring.

[0396] As described in the background above, when supporting Option 2 among the report configuration methods for performance monitoring, the following problem (Problem 3 / 4) may occur.

[0397] Problem 3

[0398] In the above Option 2, a report configuration for monitoring is set separately from the report configuration related to inference. In this case, issues related to time domain behavior may arise. Specifically, if the time domain behavior (i.e., P / SP / AP-reporting) for reporting based on a report configuration for monitoring linked to a specific inference report configuration differs from the time domain behavior for reporting based on that inference report configuration, ambiguity may occur in terminal operation. For example, it can be assumed that for a specific terminal, the time domain behavior for reporting based on the report configuration related to inference is set to aperiodic reporting, while the time domain behavior for reporting based on the report configuration for monitoring linked to that inference report configuration is set to periodic. In such a case, a problem may arise where there may be no inference result report for which a metric needs to be calculated at the time of the (periodic) monitoring report (a problem where aperiodic triggering may not be performed).

[0399] As a more specific example, the reporting of an inference result may be performed non-periodically and only once due to the time domain behavior setting (aperiodic) of the report configuration for inference. In this case, it may be ambiguous whether the terminal must continue to periodically report monitoring results according to the time domain behavior setting (periodic) of the report configuration for monitoring, even though there are no subsequent reports of inference results following the reporting of the aforementioned inference result. Reporting monitoring results multiple times for the same inference result is inefficient from the perspective of signaling overhead. Furthermore, since the same monitoring result may be reported after a significant amount of time has elapsed since the inference related to the inference result was performed, it is difficult to guarantee that necessary actions based on performance monitoring are performed in a timely manner.

[0400] A method to solve this problem 3 is described in Proposal 3 below.

[0401] Problem 4

[0402] In the above Option 2, the timing of the inference result report based on the reporting cycle of the inference-related report configuration and the timing of the monitoring result report based on the reporting cycle of the monitoring report configuration connected to / related to the inference report configuration may differ. If the monitoring report is located far in time from the inference report, the terminal may need to buffer the inference result (i.e., output of UE-side AI / ML model inference) for a long period of time to calculate the metric for the monitoring result report, and then calculate the metric for the buffered inference result and perform the monitoring report when the time for the monitoring result report arrives. Since such long-term buffering of the inference result can be a significant burden on the terminal implementation, a method to resolve this problem is described in Proposal 4 below.

[0403] Proposal 3

[0404] The terminal may configure a report configuration for monitoring result reporting separately from the inference-related report configuration through the method of option 2 among the configuration methods related to monitoring result reporting, and may establish a linkage related to the two report configurations. The terminal may expect the time domain behavior (configured via reportConfigType IE) of the two report configurations to be configured based on one of the following combinations [1] to [3] (the base station may configure the time domain behavior (reportConfigType) in the terminal based on one of the following combinations [1] to [3]). In other words, the terminal may not expect the time domain behavior to be configured with a combination other than the combinations below (the base station may not configure the time domain behavior in the terminal with a combination other than the combinations below).

[0405] [1] When the time domain behavior of a report configuration related to inference is periodic, the time domain behavior of a report configuration for reporting monitoring results linked to / related to the inference report configuration may be periodic, semi-persistent, or aperiodic.

[0406] [2] When the time domain behavior of a report configuration related to inference is semi-persistent, the time domain behavior of a report configuration for reporting monitoring results connected to / related to the inference report configuration may be semi-persistent or aperiodic.

[0407] [3] If the time domain behavior of the inference-related report configuration is aperiodic, the time domain behavior of the report configuration for reporting monitoring results connected to / related to the inference report configuration may also be aperiodic.

[0408] For example, combinations other than those based on [1] to [3] above may be as follows.

[0409] [2] In the case of the time domain behavior of the report configuration related to inference, if the time domain behavior of the report configuration for reporting monitoring results is semi-persistent, the terminal may not expect the time domain behavior of the report configuration for reporting monitoring results to be set to periodic.

[0410] [3] In the case of the time domain behavior of the report configuration related to inference, if the time domain behavior of the report configuration for reporting monitoring results is aperiodic, the terminal may not expect the time domain behavior of the report configuration for reporting monitoring results to be set to periodic or semi-persistent.

[0411] Proposal 3 can resolve problem 3, where the inference result report, which serves as material for metric calculation, may be absent when reporting monitoring results.

[0412] Proposal 4

[0413] Among the configuration methods related to monitoring result reporting, the terminal can set up a report configuration for monitoring result reporting separately from the inference-related report configuration through the method of option 2, and a linkage related to the two report configurations can be set up.

[0414] According to Proposal 4, the linkage (or linking) can be determined / defined based on the difference between points in time related to the monitoring report / inference report (e.g., minimum offset or minimum interval).

[0415] For example, the inference report may be determined to be a linked report to the monitoring report based on the fact that the interval between the time point associated with the inference report (e.g., first slot) and the time point associated with the monitoring report (e.g., second slot) is less than or equal to a defined value (e.g., X or T). Alternatively, the linkage (or linking) may be determined based on the fact that the time point associated with the inference report (e.g., first slot) has a minimum offset / minimum interval from the time point associated with the monitoring report (e.g., second slot). The minimum offset / minimum interval may be less than or equal to the defined value (e.g., X or T).

[0416] For example, the above points in time may be defined based on at least one of i) a point in time associated with each report (e.g., CSI reference resource) and / or ii) a point in time associated with a resource set for each report. As a specific example, the linking between the inference report and the monitoring report may be determined based on a point in time associated with the reporting of the inference report and a point in time associated with the reporting of the monitoring report. As a specific example, the point in time associated with the resource set may be based on the Set A transmission / reception point described above. The point in time associated with the resource set may be based on i) the resource located first in time among the resources based on the resource set or ii) the resource located last in time among the resources based on the resource set. In other words, the point in time associated with the resource set may be based on i) the first slot of the transmission occasion based on the resource set or ii) the last slot of the transmission occasion based on the resource set.

[0417] As a specific example, the linking between the inference report and the monitoring report can be determined based on the time point related to the reporting of the inference report and the time point related to the resource set for the monitoring report.

[0418] As a specific example, the linking between the inference report and the monitoring report can be determined based on the time point related to the resource set for the inference report and the time point related to the reporting of the monitoring report.

[0419] As a specific example, the linking of the inference report and the monitoring report can be determined based on the time point associated with the resource set for the inference report and the time point associated with the resource set for the monitoring report.

[0420] According to one embodiment, the terminal may expect that an inference result report of an inference report configuration (linked / related to the monitoring report configuration) will be performed within X [ms] and / or T [slot(s)] in the past (or future) from the time point (e.g., slot) at which the monitoring report is performed, by means of a time domain behavior set in the report configuration for reporting monitoring results. In other words, based on the fact that the time point associated with the inference result report is within X [ms] and / or T [slot(s)] from the time point associated with the monitoring report, the inference result report may be determined as a report linked to the monitoring report. In other words, based on the fact that the time point associated with the inference result report has a minimum offset from the time point associated with the monitoring report, the terminal may determine the linkage / linking.

[0421] According to one embodiment, the base station may schedule the reporting times of the two report configurations to the terminal such that the time difference between the reporting time of the mutually connected / related monitoring report configuration and the reporting time of the inference report configuration is within X [ms] and / or T [slot(s)]. For the above operation, a linkage between the reporting time of the monitoring report configuration and the reporting time of the inference report configuration for calculating the metric of the report may be established by the base station.

[0422] More specifically, when one or more inference result reports are performed within an interval of X [ms] and / or T [slot(s)] prior to the reporting time of the monitoring report configuration (e.g., a time interval prior to the reporting time, the length of which is Xms or T slot(s)), the terminal may operate as follows i) or ii).

[0423] i) The terminal can perform monitoring result reporting by calculating a metric only for the latest (or first) inference result report.

[0424] ii) The terminal can perform monitoring result reporting by calculating a metric for all multiple inference result reports within the interval of X [ms] and / or T [slot(s)].

[0425] In addition, when the terminal performs a result report by summing the metrics for multiple inference result reports, the multiple inference result reports may be performed within X [ms] and / or T [slot(s)] prior to the reporting time of the monitoring report configuration.

[0426] In the above, X and T may be natural numbers. For example, the values ​​of X and T may be reported to the base station by the terminal as a UE capability. For example, the values ​​of X and T may be set to the terminal by the base station. For example, the values ​​of X and T may be predefined.

[0427] According to one embodiment, an operation is proposed in which the interval between the time point related to the reporting of the monitoring report configuration and the time point of transmission / reception of the resource set(s) for monitoring related to the monitoring report configuration is scheduled within X [ms] and / or T [slot(s)]. In other words, the time point related to the resource set(s) for monitoring (e.g., the first slot of the transmission occasion of the resource set for monitoring) may have a minimum offset from the time point related to the reporting of the monitoring report configuration (e.g., the slot (CSI reference resource) related to the monitoring report). The minimum offset may not be greater than a defined value. Specifically, the minimum offset may be less than or equal to X [ms] and / or T [slot(s)].

[0428] According to one embodiment, the interval between the time point associated with the inference result reporting of the inference report configuration and the time point of transmission / reception of the resource set(s) for monitoring associated with the monitoring report configuration may also be scheduled within X [ms] and / or T [slot(s)]. In other words, the time point associated with the inference result reporting (e.g., the slot associated with the inference report (CSI reference resource)) may have a minimum offset from the time point associated with the resource set(s) for monitoring (e.g., the first slot of the transmission occasion of the resource set for monitoring). The minimum offset may not be greater than a defined value. Specifically, the minimum offset may be less than or equal to X [ms] and / or T [slot(s)].

[0429] For example, the operation of the above proposal 4 may also be applied when a terminal calculates a metric for a set of samples of multiple inference reporting points or inference results and performs a monitoring report. For example, the operation of the above proposal 4 may also be applied when a metric from multiple monitoring reporting points is summed to perform a monitoring result report for multiple samples at a specific point in time (a period longer than the reporting point).

[0430] Through Proposal 4, the buffering maintenance period for terminal-side inference results caused by the long time difference between the time point related to the monitoring report (e.g., the first slot of the transmission occasion of the resource set for monitoring) and the time point related to the inference report (e.g., the slot related to the inference report (CSI reference resource)) can be shortened, and the complexity of the terminal-side implementation can be reduced.

[0431] The embodiments of proposals 1 to 4 above may be operated by a combination of specific embodiments.

[0432] < Reinforcement Examples >

[0433] The linkage between the monitoring result report instance and the transmission occasion of the resource set for monitoring must be considered. According to the agreement, the ID of the inference report configuration can be set in the monitoring CSI report configuration, thereby enabling a linkage between the inference report and the performance monitoring report. One of the critical issues regarding this linkage is that the UE cannot predict when the network (NW) will activate / trigger the monitoring RS / report. Therefore, the UE must buffer inference results to prepare for situations where the 'unknown time' can become very long depending on the network's decision (linkage between a monitoring result report instance and a transmission occasion of resource set for monitoring should be considered. According to the agreement, the ID of an inference report configuration can be configured in the CSI report configuration for monitoring, in order to have linkage between an inference report and a performance monitoring report. One important issue of this linkage is that the UE cannot expect when the network will activate / trigger the monitoring RS / report.Therefore, UE has to buffer inference results until the 'unknown time' that could be very long time depending on NW's decision).

[0434] Observation #x: Once a UE starts the CSI measurement / report for inference, the UE has to buffer the inference results until NW activates / triggers associated CSI measurement / report for monitoring.

[0435] Given that in legacy systems, UEs do not need to buffer CSI when it is reported to the network, this feature could become a serious issue for UE vendors if the aforementioned issue is not resolved. Therefore, when an inference report is activated or triggered, and if that report is linked to a monitoring report, the monitoring report must also be activated or triggered within a certain time limit to limit the UE's maximum buffering window size. Here, the time limit may be specified as a fixed value in the specification or defined as a UE capability.

[0436] Proposal #x: When an inference report is activated / triggered, and if the report is linked to a monitoring report, the monitoring report should be activated / triggered within a certain time limit.

[0437] Below, we examine embodiments related to the aforementioned proposal #x.

[0438] As described above, the UE has a burden of buffering the inference result until the time of performance monitoring metric calculation. As described above, the terminal can expect the performance monitoring report to be (configured / )activated / triggered within X [ms] and / or T [slot(s)] from the time related to the inference result report (the base station must make such a configuration). That is, the time related to the inference result report and the activation / triggering time of the performance monitoring report may be located within X [ms] and / or T [slot(s)].

[0439] For example, the point in time related to the inference result report in this specification may be based on at least one of i) a point in time corresponding to / corresponding to the reference resource in the CSI report setting related to the inference result report, ii) a point in time when Set B is received / measured (e.g., a point in time when transmission occasion(s) for each resource based on Set B [e.g., each of CSI-RS resources or each of SS / PBCH Block resources] are received / measured), and / or iii) a point in time when the inference result report is performed.

[0440] Through the above operation, the terminal can buffer the inference result only for a certain period of time (e.g., bufferable time), and if the monitoring report is activated / triggered within that time, utilize it for calculating monitoring metrics, or flush it if it is not activated / triggered within that time, thereby minimizing the burden of buffering. As an example, the aforementioned certain period related to the monitoring report may be defined based on slots. Specifically, the aforementioned certain period related to the monitoring report may be based on the time point related to the monitoring report described below. As a specific example, the aforementioned certain period related to the monitoring report may be based on a reference resource related to the monitoring report.

[0441] According to one embodiment, the terminal may expect to be configured by the base station such that the time related to the performance monitoring report exists within X [ms] and / or T [slot(s)] from the time related to the inference result report (the base station may be required to make such a configuration).

[0442] For example, in this specification, the point in time related to the performance monitoring report may be based on at least one of i) the point in time when the CSI report is activated / triggered in the CSI report setting related to the performance monitoring report, ii) the point in time corresponding to / corresponding to the reference resource, iii) the point in time when the resource set(s) for monitoring are received / measured (e.g., the point in time when the latest transmission occasion(s) for each resource [e.g., each of CSI-RS resources or each of SS / PBCH Block resources] based on the monitoring set (resource set for channel measurement) are received / measured), and / or iv) the point in time when the performance monitoring report is performed.

[0443] The above operation also has the effect of reducing the buffering burden on the terminal's inference result.

[0444] According to one embodiment, an operation to drop / skip a performance monitoring report based on a point in time related to the above-described performance monitoring report (e.g., a point in time when transmission occasion(s) for each resource [e.g., each of CSI-RS resources or each of SS / PBCH Block resources] based on a monitoring set (resource set for channel measurement) is received / measured). The following describes in detail the cases in which the terminal drops / skips the monitoring report.

[0445] It can be assumed that a time point related to a performance monitoring report is located after a certain period has passed since the time point related to the inference result report. For example, if the reportConfigType of the performance monitoring report is semi-persistent, it can be assumed that a time point related to the performance monitoring report is located after a certain period has passed since the activation of the performance monitoring report. In other words, the time point related to the performance monitoring report may be located beyond the aforementioned certain period (bufferable time). To put it differently, the time point related to the performance monitoring report may be later than the aforementioned certain period (bufferable time). In such cases, the terminal may drop or skip the monitoring report.

[0446] The timing related to the above performance monitoring report may be based on the time at which transmission occasion(s) for each resource [e.g., each of CSI-RS resources or each of SS / PBCH Block resources] based on the monitoring set (resource set for channel measurement) is received / measured. Considering this, the cases described above can be expressed as follows: Reception related to performance metric calculation (reception of transmission occasion(s) for each resource based on the monitoring set (resource set for channel measurement)) may be performed after exceeding a certain time (bufferable time). Reception related to performance metric calculation (reception of transmission occasion(s) for each resource based on the monitoring set (resource set for channel measurement)) may be delayed compared to a certain time (bufferable time).

[0447] In cases according to the examples described above, the terminal does not buffer the inference result report value associated with the corresponding performance monitoring report and therefore does not have an inference result available for performance monitoring and metric calculation. Consequently, the terminal drops / skips the performance monitoring report.

[0448] On the other hand, if there is a buffered inference result, the terminal can perform performance monitoring reporting normally. To put it differently by referring to the example described above, the terminal transmits the monitoring report only if the time point related to the performance monitoring report does not occur more than a certain amount of time after the time point related to the inference result report; otherwise, the terminal drops the monitoring report. To put it differently, (after the activation of the semi-persistent performance monitoring report) the terminal transmits the monitoring report only if the time point related to the performance monitoring report is not later than the aforementioned certain amount of time (bufferable time); otherwise, the terminal drops the monitoring report. To put it differently, (after the activation of the semi-persistent performance monitoring report) the terminal transmits the monitoring report only if the reception related to performance metric calculation (e.g., reception of transmission occasion(s) for each resource based on the monitoring set (resource set for channel measurement)) is not later than a certain amount of time (bufferable time) (e.g., reference resource related to the monitoring report); otherwise, the terminal drops the monitoring report.

[0449] According to the above-described embodiment, the following effects are derived. When a terminal does not possess the inference result and measurement result required for calculating a performance metric, the problem of ambiguity in the terminal's performance monitoring reporting operation and a decrease in the accuracy of the performance metric can be resolved.

[0450] < Operation between base station terminals at the time of reporting when multiple inference results are used for performance monitoring >

[0451] According to the Rel-19 AI / ML beam management standardization discussions, it was agreed to monitor UE-side AI / ML performance in BM-case 1 / 2 by separately configuring the inference result report configuration and the monitoring result report configuration, and linking / relationalizing the two reporting settings. Here, transmission based on resource set(s) for monitoring for performance monitoring is transmission to the beam set corresponding to the ground truth (related to Set A, which is the target of the prediction). Therefore, to reduce overhead, the cycle of resource set(s) for monitoring may be longer than the cycle of Set B or the inference result report. Based on this background, the following two methods can be considered as performance monitoring approaches.

[0452] Method 1

[0453] The period of a resource set(s) for monitoring can be set / defined to be longer than the period of Set B or the inference result report. The terminal can calculate a metric (e.g., Prediction Accuracy Indicator, PAI) by comparing multiple inference result reports existing within a specific time unit in the past or / and future relative to the transmission / measurement point of the resource set(s) for monitoring at a specific point in time with ground-truth information of the resource set(s) for monitoring at that specific point in time. The terminal can report the monitoring result including the metric to the base station.

[0454] For example, the transmission period of an inference result report may be 10 ms, and the transmission period of a resource set(s) for monitoring may be 50 ms. The terminal may calculate a metric by comparing each of the predicted top-K beams of five inference result report instances existing within a 50 ms time unit prior to the transmission time of the resource set(s) for monitoring with the ground-truth top-K beam at the transmission time of the resource set(s) for monitoring. The terminal may transmit a monitoring report containing the metric to the base station. In this case, the transmission period of the resource set(s) for monitoring and the reporting period of performance monitoring may coincide.

[0455] Method 2

[0456] The period of the resource set(s) for monitoring can be set / defined to be longer than the period of the Set B or inference result report. The terminal compares one (or multiple) inference result reports existing within a specific time unit in the past or / and future relative to the transmission / measurement point of the resource set(s) for monitoring at a specific point in time with the ground-truth information of the resource set(s) for monitoring at that specific point in time. The terminal may perform M comparisons while the resource set(s) for monitoring is transmitted M times. The terminal may transmit a monitoring report to the base station that includes a metric calculated based on the M comparisons.

[0457] For example, the cycle of the inference result report may be 10 ms, and the transmission cycle of the resource set(s) for monitoring may be 50 ms. The terminal calculates a metric by comparing the predicted top-K beam of one inference result report instance existing within a 10 ms time unit prior to and / or after the transmission time of the resource set(s) for monitoring with the ground-truth top-K beam at the transmission time of the resource set(s) for monitoring, or performs counting of values ​​for metric calculation (e.g., whether the predicted top-K beam matches the ground-truth top-K beam). When such comparisons accumulate 10 times, the terminal may perform a monitoring report by summing the metric or counter values. In other words, the terminal may transmit a monitoring report containing information (e.g., PAI) calculated / determined by summing the metric or counter values.

[0458] In this case, the reporting period of performance monitoring can be set / defined to be longer than the transmission period of resource set(s) for monitoring (in the example above, the reporting period of performance monitoring can be 10 times the transmission period of resource set(s) for monitoring).

[0459] Against this backdrop, the time domain behavior (reportConfigType) of inference result reporting and performance monitoring reporting may differ. For example, the inference result report might be a periodic CSI report, while the monitoring result report might be a semi-persistent (SP) or aperiodic (AP) CSI report. In such cases, with existing legacy CSI reporting, there is no issue if the terminal deletes, removes, or flushes the calculated CSI after calculating and reporting it, without the need for buffering. However, if there is a monitoring result report configuration linked to an inference result report, the terminal cannot know at what point the base station will activate or trigger the SP / AP CSI report for the monitoring result. Consequently, even after deriving the inference result from an AI / ML model and performing a report on it, the terminal faces the burden of buffering and terminal complexity.

[0460] In particular, this issue can place an even greater burden on the terminal when inference result reports corresponding to multiple instances are utilized in performance monitoring reports. A method to resolve this problem is described below.

[0461] Proposal 5

[0462] When the base station (configuration / )activation / triggers a performance monitoring report to the terminal, it may (configuration / )activation / trigger the performance monitoring report to be executed within a specific time limit from the terminal's first report time of the inference result report that is the target of the performance monitoring (after the previous relevant performance monitoring report time) (the terminal can be expected to configure / instruct the performance monitoring report as described above). For example, the time limit may be based on the aforementioned fixed time (buffering time). As a specific example, the time limit may be a predefined value or a value reported through the terminal capability report (such as the terminal's max buffering window size).

[0463] For example, in Method 1 described above, it may be assumed that the time limit is 30 ms. The terminal can expect the performance monitoring report to be (configured / )activated / triggered within 30 ms from the first reporting time of the inference result report (after the previous relevant performance monitoring report time). For this operation to occur, the (first) time related to the inference result report and the time related to the performance monitoring report may need to be located within 30 ms. Through this, the terminal can always perform monitoring reporting by utilizing the inference results reported for performance monitoring without any omission of inference results reported to the base station (due to the UE max buffer window size) in the activated / triggered performance monitoring report.

[0464] For example, the point in time related to the inference result report in this specification may be based on at least one of i) a point in time corresponding to / corresponding to the reference resource in the CSI report setting related to the inference result report, ii) a point in time when Set B is received / measured (e.g., a point in time when transmission occasion(s) for each resource based on Set B [e.g., each of CSI-RS resources or each of SS / PBCH Block resources] are received / measured), and / or iii) a point in time when the inference result report is performed.

[0465] For example, in this specification, the timing of a performance monitoring report may be based on at least one of: i) the time when the CSI report is activated / triggered in the CSI report setting related to the performance monitoring report; ii) the time when the reference resource corresponds / corresponds to; iii) the time when the resource set(s) for monitoring are received / measured (e.g., the time when the latest transmission occasion(s) for each resource [e.g., each of CSI-RS resources or each of SS / PBCH Block resources] based on the monitoring set (resource set for channel measurement) are received / measured); and / or iv) the time when the performance monitoring report is performed.

[0466] The following embodiment may be considered in the case where the time domain behavior of the inference result report and the time domain behavior of the performance monitoring report are the same, rather than different. In this case, the base station may set the period of the performance monitoring report to be shorter than or equal to the time limit of the above proposal (the terminal can be expected to set / instruct the performance monitoring report as above). According to this embodiment, the following effect is derived. Even if the time domain behavior of the inference result report and the performance monitoring report is the same, all inference result values ​​previously reported by the terminal can be utilized in the performance monitoring report at every performance monitoring period without omission (due to the UE max buffer window size).

[0467] According to one embodiment, a time period (window) for UE buffering or performance monitoring of inference results may be set in the terminal. For example, the time period may be set in units of 40 ms. Within a specific 40 ms window, the terminal performs buffering on inference result reports within that window, and when (configuration / )activation / triggering for a performance monitoring report is performed within that window, the terminal may calculate a metric by comparing the buffered (multiple) inference results with resource set(s) for monitoring (e.g., beam(s) / RS(s) / CRI(s) / SSBRI(s) determined by measurements (L1-RSRP measurements) based on said resource set(s) for monitoring). The terminal may transmit a monitoring report containing the metric.

[0468] If the start or end time of an inference result report is included within the relevant window, one or more inference result instances may be omitted. In this case, the terminal may act as follows. For example, the terminal may drop / skip the performance monitoring result report associated with the relevant window. For example, the terminal may perform a performance monitoring report (by calculating metrics) on the inference result report(s) excluding the omitted inference result instances.

[0469] The operation of the above proposal 5 ensures that the base station (configuration / )activation / triggers the monitoring report within the max window size in which the terminal buffers the inference result, thereby having the advantage that the terminal does not need to worry about multiple inference results being flushed without being used for performance monitoring.

[0470] As mentioned above, the reportQuantity parameter of the CSI report setting used for performance monitoring can be set as 'rs-pai-r19', in which case the payload size (O) that the terminal must report for the corresponding report setting UCI) can be 1 to 4 bits (based on the 'nrofTransmissionOccasion-r19' setting). Here, the upper layer parameter nrofTransmissionOccasion-r19 may mean the number for performance metric calculation (e.g., N=1, 3, 7, 15, etc.). More specifically, nrofTransmissionOccasion-r19 indicates the number of (N) latest transmission occasion(s) of monitoring resources for performance metric calculation. In this case, if 'nrofTransmissionOccasion-r19' is set to a value of 1 or 3 and reports a payload size of 1 to 2 bits, the terminal may be allocated a PUCCH resource of the PUCCH resource set corresponding to pucch-ResourceSetId= 0, which consists of PUCCH resources with a PUCCH payload size of less than 2. However, in this case, a problem arises where a PUCCH format (i.e., PUCCH format 0 / 1) that supports a payload size of 1 to 2 bits is assigned, which cannot perform CSI reporting other than HARQ Ack / Nack or Scheduling Request.To resolve this issue, in the CSI report settings used for performance monitoring, regardless of the 'nrofTransmissionOccasion-r19' value set (i.e., even if 'nrofTransmissionOccasion-r19' is set to a value of 1 to 3 and the payload size for reporting becomes 1 to 2 bits), the terminal determines the payload size (O. for PUCCH resource (set) for the corresponding CSI report. UCI We propose an operation that defines / assumes ) as 4 bits. The effect of this operation is payload size(O UCI Since ) is 4 bits, a PUCCH resource from a PUCCH resource set composed of PUCCH resources exceeding 2 bits is allocated during the corresponding CSI report, thereby enabling performance monitoring reporting to be performed without terminal operation ambiguity such as the aforementioned problem. At this time, more specifically, for determining the PUCCH resource (set), the payload size (O UCIAssuming that ) is defined / assumed to be 4 bits, even if the payload for the performance monitoring report to be actually reported is smaller than 4 bits, we propose determining 4 bits as the payload size for the actual report, including the actual report content in the MSB or LSB of the 4 bits, and performing zero padding or one padding, or padding with known bits, for the remaining bit fields. For example, if 'nrofTransmissionOccasion-r19' in the performance monitoring report settings is set to a value of 3, 2 bits of performance metric information can be reported. This can be placed in the MSB within the 4-bit payload, and the remainder can be zero-padded to perform CSI reporting as 'xx00' (xx is the metric report).

[0471] As another example, in the CSI reporting settings used for performance monitoring, when the configured 'nrofTransmissionOccasion-r19' value is 1, 3, or 7, the payload size (O) for determining the PUCCH resource (set) UCI Defined / assumed as ) 3 bits, if the value of 'nrofTransmissionOccasion-r19' is 15, the payload size (O) for determining the PUCCH resource (set) UCIA method is proposed to define / assume ) as 4 bits. In this case, when the value of 'nrofTransmissionOccasion-r19' is 7 or 15, the payload size to be transmitted for the actual report is 3 to 4 bits, so the report is performed using all 3 to 4 bits. When the value of 'nrofTransmissionOccasion-r19' is 1 or 3, only 1 to 2 bits of the 3 bits contain the actual report content, and the remaining bits can be padded with zero padding or one padding, or padded with known bits, similar to the embodiment described above.

[0472] The above embodiments may be operated by a combination of specific embodiments.

[0473] The above embodiments may also be utilized in CSI prediction operations using UE-side AI / ML. For example, if there exists a CSI reporting setting related to reporting an inference result for predicting a terminal's future point-in-time CSI, and a reporting setting for performance monitoring connected to said reporting setting, the operations / constraints according to the above embodiments may be applied between the two reporting settings.

[0474] An example of a terminal (or base station) operation based on at least one of the aforementioned embodiments (e.g., at least one of the embodiments of Proposals 1 to 5) is as follows.

[0475] 1) The terminal (base station) receives (transmits) settings related to beam measurement / reporting.

[0476] The above settings may include reporting settings related to Set A and Set B.

[0477] The report settings may include inference result reporting settings and / or monitoring result reporting settings.

[0478] 2) The terminal (base station) receives (transmits) a message scheduling the transmission of a beam measurement report.

[0479] The transmission of reports scheduled by the base station described above may have periodic / semi-persistent / aperiodic time domain behavior. For example, the report configuration type associated with the report may be set to periodic, semi-persistent, or aperiodic.

[0480] The above report may be a report of inference results and monitoring results utilizing UE-sided AI / ML.

[0481] 3) The terminal (base station) transmits (receives) a beam measurement report based on the above message.

[0482] The above report may include a performance monitoring result based on the embodiments of proposals 1 to 5.

[0483] The above terminal / base station operation is merely an example, and each operation (or step) is not necessarily essential; depending on the terminal / base station implementation method, the beam measurement / reporting operation of the terminal according to the aforementioned embodiments may be omitted or added.

[0484] The above embodiments may be operated by a combination of specific embodiments.

[0485] In terms of implementation, the operations of the base station / terminal according to the embodiments described above (e.g., operations based on at least one of proposals 1 to 4, an enhanced embodiment, and proposal 5) can be processed by the device of FIG. 9 (e.g., the processor (110, 210) of FIG. 9).

[0486] In addition, the operations of the base station / terminal according to the above-described embodiment (e.g., operations based on at least one of proposals 1 to 4, reinforced embodiment, and proposal 5) may be stored in memory (e.g., 140, 240 in FIG. 9) in the form of instructions / programs (e.g., instruction, executable code) for driving at least one processor (e.g., 110, 210 in FIG. 9).

[0487] The embodiments described above will be explained in detail below with reference to FIGS. 7 and FIGS. 8 regarding the operation of the terminal and base station. The methods described below are distinguished only for convenience of explanation, and it is understood that a part of one method may be substituted with a part of another method or combined with one another and applied.

[0488] FIG. 7 is a flowchart illustrating a method according to one embodiment of the present specification.

[0489] Referring to FIG. 7, a method according to one embodiment of the present specification includes a step of receiving setting information related to CSI (S710), a step of transmitting a first CSI report (S720), and a step of transmitting a second CSI report (S730).

[0490] In S710, the terminal receives configuration information related to Channel State Information (CSI) from the base station.

[0491] For example, the above configuration information may include information based on at least one of the above-described CSI-related operations and proposals 1 to 5. As a specific example, the above configuration information may include i) one or more reporting settings (e.g., N≥1 CSI-ReportConfig reporting setting) and / or ii) one or more resource settings (e.g., M≥1 CSI-ResourceConfig resource setting).

[0492] Each of the above one or more reporting configurations may be associated with up to three resource configurations. In other words, each reporting configuration may include the IDs (e.g., CSI-ResourceConfigId) of up to three resource configurations.

[0493] For example, the above-mentioned setting information may include i) a first reporting setting related to prediction and ii) a second reporting setting related to prediction accuracy. Specifically, the one or more reporting settings may include i) a first reporting setting related to prediction and ii) a second reporting setting related to prediction accuracy.

[0494] For example, the report quantity of the first report setting above may be set to p-cri, p-cri-RSRP, p-ssb-index, or p-ssb-index-RSRP. p-cri represents the predicted CSI-RS Resource Indicator (P-CRI). p-ssb-index represents the predicted SSB Resource Indicator (P-SSBRI). In p-cri-RSRP or p-ssb-index-RSRP, RSRP represents the predicted Layer1-Reference Signal Received Power (P-L1-RSRP).

[0495] For example, the above prediction may be performed based on a measurement. The measurement may be performed based on a first resource configuration (e.g., CSI-ResourceConfig) associated with the first reporting configuration. For example, the first reporting configuration may be linked to a first resource configuration associated with the measurement and a second resource configuration associated with the prediction. The first reporting configuration may include the ID of the first resource configuration and the ID of the second resource configuration. Each ID may be based on the CSI-ResourceConfigId.

[0496] For example, the above measurements may include Layer1-Reference Signal Received Power (L1-RSRP) measurements. Based on the L1-RSRP measurements, i) at least one predicted CSI-RS Resource Indicator (P-CRI), ii) at least one predicted SSB Resource Indicator (P-SSBRI), and / or iii) at least one predicted Layer1-Reference Signal Received Power (P-L1-RSRP) may be determined.

[0497] More specifically, predictions for CSI-RS resources or SSB resources associated with the second resource configuration may be performed based on the L1-RSRP measurements. Specifically, predicted L1-RSRPs of CSI-RS resources or SSB resources associated with the second resource configuration may be determined. For example, best CRI(s) or best SSBRI(s) may be determined based on the order or ranking of the predicted L1-RSRPs. For example, at least one P-CRI or at least one P-SSBRI included in the first CSI report described below may be based on the best CRI(s) or best SSBRI(s).

[0498] For example, the report quantity of the second report setting above can be set to pai (or rs-pai).

[0499] The above one or more resource settings may include i) a first resource setting and a second resource setting related to the first reporting setting and ii) a third resource setting related to the second reporting setting.

[0500] Each resource configuration (e.g., CSI-ResourceConfig) may include information about a resource set (e.g., csi-SSB-ResourceSetList or nzp-CSI-RS-ResourceSetList based on csi-RS-ResourceSetList). For example, the resources within the resource set may be SSB resources or CSI-RS resources based on csi-RS-ResourceSetList. csi-SSB-ResourceSetList may include information for referencing the SSB resources (e.g., CSI-SSB-ResourceSetIds). nzp-CSI-RS-ResourceSetList may include information for referencing the CSI-RS resources (e.g., NZP-CSI-RS-ResourceSetIds).

[0501] For example, the first resource setting may include information about a first resource set for measurement (e.g., Set B described above). As a specific example, the first resource setting may include a list of SSB resources or CSI-RS resources for measurement.

[0502] For example, the second resource setting may include information regarding a second resource set for the prediction (e.g., Set A described above). As a specific example, the second resource setting may include a list of SSB resources or CSI-RS resources for the prediction.

[0503] For example, the third resource setting may include information regarding a third resource set(s) for measurement (e.g., the resource set(s) described above for monitoring). As a specific example, the third resource setting may include a list of SSB resources or CSI-RS resources for measurement.

[0504] In S720, the terminal transmits a first CSI report related to the above prediction to the base station.

[0505] In S730, the terminal transmits a second CSI report related to the prediction accuracy to the base station.

[0506] According to one embodiment, the first CSI report may be based on an inference report. The first CSI report may include predicted information (predicted CSI parameter(s)). The first CSI report may include predicted CSI parameter(s) (e.g., P-CRI(s), P-SSBRI(s), and / or P-L1-RSRP(s)) based on the report quantity of the first report setting. Specifically, the first CSI report may include at least one of i) at least one predicted CSI-RS Resource Indicator (P-CRI), ii) at least one predicted SSB Resource Indicator (P-SSBRI), and / or iii) at least one predicted Layer1-Reference Signal Received Power (P-L1-RSRP).

[0507] According to one embodiment, the second CSI report may be based on a monitoring report. The second CSI report may include information related to monitoring the performance / accuracy of CSI prediction. The second CSI report may include CSI parameters (e.g., PAI or RS-PAI) based on the report quantity (e.g., pai or rs-pai) of the second report setting. Specifically, the second CSI report may include a Reference Signal-Prediction Accuracy Indicator (RS-PAI).

[0508] For example, the 1st / 2nd CSI report can be interpreted / substituted with the 1st / 2nd CSI.

[0509] According to one embodiment, the first CSI report may be a linked report determined for a transmission occasion of a resource set associated with the second reporting setting. This embodiment may be based on Proposal 4. The resource set associated with the second reporting setting may mean a third resource set for measurement based on a third resource setting associated with the second reporting setting described above (e.g., resource set(s) for monitoring of Proposal 1, Proposal 4, Enhanced Embodiment and / or Proposal 5).

[0510] Specifically, the linking can be determined based on the fact that the slot associated with the first CSI report has a minimal slot offset from the slot of the transmission occasion.

[0511] For example, the minimum slot offset may not be greater than a defined number of slots. In other words, the minimum slot offset may be less than or equal to a defined number of slots. As a specific example, the minimum slot offset may be less than or equal to T slots. T is a natural number.

[0512] For example, the slot associated with the first CSI report may be a CSI reference resource of the first CSI report.

[0513] For example, the slot of the transmission occasion may be the first slot of the transmission occasion.

[0514] According to one embodiment, a second time domain behavior related to the second reporting setting may be set based on a first time domain behavior related to the first reporting setting. This embodiment may be based on Proposal 3.

[0515] For example, based on the fact that the first time domain operation is set to aperioditic, the second time domain operation may be set to aperioditic. This embodiment may be based on [3] of Proposal 3. In other words, for the first report configuration that is aperioditic, the terminal may not expect the second report configuration that is semi-persistent or periodic to be set. In other words, for the first report configuration in which the report configuration type is set to 'aperiodic', the terminal may not expect the report configuration type of the second report configuration to be set to 'semi-persistent' or 'periodic'. In other words, based on the fact that the report config type of the first report setting is set to 'aperiodic', the report config type of the second report setting can be set to 'aperiodic'.

[0516] For example, based on the fact that the first time domain operation is set to semi-persistent, the second time domain operation may be set to either aperioditic or semi-persistent. This embodiment may be based on [2] of Proposal 3. In other words, for a first report configuration that is semi-persistent, the terminal may not expect a second report configuration that is periodic to be set. In other words, for a first report configuration in which the report configuration type is set to 'semi-persistent', the terminal may not expect the report configuration type of the second report configuration to be set to 'perioditic'. In other words, based on the fact that the report config type of the first report setting is set to 'semi-persistent', the report config type of the second report setting can be set to 'aperiodic' or 'semi-persistent'.

[0517] For example, based on the fact that the first time domain operation is set to periodic, the second time domain operation may be set to periodic, semi-persistent, or aperioditic. This embodiment may be based on [1] of Proposal 3. Alternatively, based on the fact that the report config type of the first report setting is set to 'perioditic', the report config type of the second report setting may be set to 'aperiodic', 'semi-persistent', or 'perioditic'.

[0518] For example, the first time domain operation may be based on the report config type of the first report setting. The second time domain operation may be based on the report config type of the second report setting.

[0519] According to one embodiment, the second CSI report is transmitted only when the reception related to the performance metric calculation is not delayed beyond a defined time, and otherwise, the second CSI report may be dropped. This embodiment may be based on the above-described reinforcement embodiment and / or Proposal 5.

[0520] For example, the second CSI report may be based on semi-persistent CSI (semi-persistent, SP, CSI). The reception associated with the calculation of the performance metric may include the reception of one or more latest transmission occasions for each of the resources (e.g., each of the CSI-RS resources or SS / PBCH Block resources) based on the resource set associated with the second report setting after the activation of the SP CSI.

[0521] To be more specific, for the second report setting in which the report quantity is set to rs-pai, after the activation of the SP-CSI, the terminal transmits the second CSI report only when it receives at least one or more latest transmission occasions for each of the CSI-RS resources or SS / PBCH Block resources within the resource set for channel measurement (the resource set associated with the second report setting) without being delayed compared to the CSI reference resource, and otherwise drops the second CSI report.

[0522] The above description indicates that the terminal must possess information necessary to perform performance metric calculation (e.g., recent transmission occasions and inference results (the first CSI report)) prior to a defined time point (e.g., the CSI reference resource). In this regard, the description of the above operation (transmission or drop of the second CSI report) may be expressed based on whether the terminal has acquired / secured / possessed information enabling performance metric calculation prior to the defined time point. For example, the reception may be associated with one or more latest transmission occasions for each of the resources based on the resource set associated with the second report setting. The second CSI report may be transmitted based on the number of the one or more latest transmission occasions being greater than or equal to the number required for performance metric calculation. The second CSI report may be dropped based on the number of the one or more latest transmission occasions being less than the number required for performance metric calculation.

[0523] For example, the time point defined above may be based on the aforementioned fixed time limit. As a specific example, the time point defined above may be based on a slot associated with the second CSI report. The slot associated with the second CSI report may be a CSI reference resource associated with the second CSI report.

[0524] For example, the time interval prior to the point defined above may be related to the buffering of the first CSI report.

[0525] For example, the size of the above time interval may be based on terminal performance (UE capability).

[0526] According to one embodiment, the first time domain behavior associated with the first reporting setting may differ from the second time domain behavior associated with the second reporting setting. This embodiment may be based on Proposal 5 (or Proposals 3 and 5).

[0527] For example, the first time-domain operation may be periodic, and the second time-domain operation may be semi-persistent or aperiodic.

[0528] For example, the first time-domain operation may be semi-persistent, and the second time-domain operation may be aperioditic.

[0529] According to one embodiment, the first time domain behavior associated with the first reporting setting may be identical to the second time domain behavior associated with the second reporting setting. This embodiment may be based on Proposal 5 (or Proposal 3 and Proposal 5). The first time domain behavior may be semi-persistent, and the second time domain behavior may be semi-persistent. The periodicity associated with the second CSI report may be less than or equal to the length of the time interval prior to the defined point in time.

[0530] According to one embodiment, the second report configuration includes a report configuration ID, and the second report configuration may be connected to the first report configuration among the report configurations in the configuration information by the report configuration ID. This embodiment may be based on Proposal 4 and an enhanced embodiment.

[0531] For example, the first CSI report may be a linked report determined for a transmission occasion of a resource set associated with the second report setting. The linking may be determined based on the fact that a slot associated with the first CSI report (e.g., a CSI reference resource) has a minimal slot offset (e.g., a minimal slot offset not greater than T slots) from the slot of the transmission occasion.

[0532] According to one embodiment, the second CSI report may be transmitted based on a PUCCH resource. The PUCCH resource may be based on a PUCCH resource set. The number of bits of UCI information (O) for determining the PUCCH resource set of the second CSI report UCI ) can be determined to be 3 or 4. This embodiment describes the number of UCI bits (e.g., O) according to the number of values ​​(e.g., values ​​indicated by nrofTransmissionOccasion-r19 (N=1, 3, 7, 15, etc.) for calculating performance metrics during the performance monitoring described above. UCI This is based on an example to solve the problem where a PUCCH format is assigned that cannot perform CSI reporting other than HARQ Ack / Nack or Scheduling Request when the PUCCH resource set is determined based on =1 or 2).

[0533] For example, regardless of the number for calculating the above performance metric, the number of bits (O UCI ) can be determined to be 4.

[0534] For example, based on the number for calculating the above performance metric being set to 1, 3, or 7, the number of bits (O UCI ) can be determined to be 3. Based on the fact that the number for the above performance metric calculation is set to 15, the number of bits (O UCI ) can be determined to be 4.

[0535] Operations based on S710 to S730 described above can be implemented by the device of FIG. 9. For example, referring to FIG. 9, the terminal (200) can control one or more transceivers (230) and / or one or more memories (240) to perform operations based on S710 to S730.

[0536] The embodiments described above will be explained in detail below in terms of base station operation.

[0537] S810 to S830 described below correspond to operations based on S710 to S730 described in FIG. 7. Considering the above correspondence, redundant descriptions are omitted. That is, the specific description of the base station operation described below can be replaced by the description / embodiment of FIG. 7 corresponding to the operation.

[0538] FIG. 8 is a flowchart illustrating a method according to another embodiment of the present specification.

[0539] Referring to FIG. 8, a method according to another embodiment of the present specification includes a step of transmitting setting information related to CSI (S810), a step of receiving a first CSI report (S820), and a step of receiving a second CSI report (S830).

[0540] In S810, the base station transmits configuration information related to Channel State Information (CSI) to the terminal. For example, the configuration information may include i) a first reporting configuration related to prediction and ii) a second reporting configuration related to prediction accuracy.

[0541] In S820, the base station receives a first CSI report related to the above prediction from the terminal.

[0542] In S820, the base station receives a second CSI report related to the prediction accuracy from the terminal.

[0543] According to one embodiment, the second CSI report is received only when the reception of the terminal related to the performance metric calculation is not delayed beyond a defined time, and otherwise, the second CSI report may be dropped.

[0544] Operations based on S810 to S830 described above can be implemented by the device of FIG. 9. For example, referring to FIG. 9, a base station (100) can control one or more transceivers (130) and / or one or more memories (140) to perform operations based on S810 to S830.

[0545] The operations / terms based on the embodiments described above are described under the assumption of an existing system (e.g., a 5G system). However, this is for the convenience of explanation and is not intended to limit the scope of application of the technical problems and means for solving problems that are to be solved by this specification to a specific system. That is, the technical problems / technical issues / problems mentioned in this specification may exist in other systems (e.g., a 6G system). It is evident that the embodiments of this specification can be extended to solve problems that exist in other systems as well. Therefore, for the extended application of the embodiments of this specification to other systems, terms defined / described based on a 5G system may be replaced / changed with terms defined in said other systems (or generalized terms not specific to one system). For example, PRACH, PUSCH, PUCCH, or SRS may be replaced / changed to uplink signals (or uplink channels). For example, SSB, CSI-RS, PDSCH, and PDCCH may be replaced / changed to downlink signals (or downlink channels).

[0546] Hereinafter, an apparatus to which the embodiments of the present specification can be applied (an apparatus implementing the method / operation according to the embodiments of the present specification) will be described with reference to FIG. 9.

[0547] FIG. 9 is a drawing showing the configuration of a first device and a second device according to an embodiment of the present specification.

[0548] The first device (100) may include a processor (110), an antenna unit (120), a transceiver (130), and a memory (140).

[0549] The processor (110) performs baseband-related signal processing and may include an upper layer processing unit (111) and a physical layer processing unit (115). The upper layer processing unit (111) may process operations of the MAC layer, RRC layer, or higher upper layers. The physical layer processing unit (115) may process operations of the PHY layer. For example, if the first device (100) is a base station device in base station-terminal communication, the physical layer processing unit (115) may perform uplink reception signal processing, downlink transmission signal processing, etc. For example, if the first device (100) is a first terminal device in terminal-terminal communication, the physical layer processing unit (115) may perform downlink reception signal processing, uplink transmission signal processing, sidelink transmission signal processing, etc. In addition to performing baseband-related signal processing, the processor (110) may also control the overall operation of the first device (100).

[0550] The antenna section (120) may include one or more physical antennas, and if it includes multiple antennas, it may support MIMO transmission and reception. The transceiver (130) may include an RF (Radio Frequency) transmitter and an RF receiver. The memory (140) may store information processed by the processor (110) and software, operating systems, applications, etc. related to the operation of the first device (100), and may include components such as a buffer.

[0551] The processor (110) of the first device (100) may be configured to implement the operation of the base station in base station-terminal communication (or the operation of the first terminal device in terminal-terminal communication) in the embodiments described in this disclosure.

[0552] The second device (200) may include a processor (210), an antenna unit (220), a transceiver (230), and a memory (240).

[0553] The processor (210) performs baseband-related signal processing and may include an upper layer processing unit (211) and a physical layer processing unit (215). The upper layer processing unit (211) may process operations of the MAC layer, RRC layer, or higher upper layers. The physical layer processing unit (215) may process operations of the PHY layer. For example, if the second device (200) is a terminal device in base station-terminal communication, the physical layer processing unit (215) may perform downlink reception signal processing, uplink transmission signal processing, etc. For example, if the second device (200) is a second terminal device in terminal-terminal communication, the physical layer processing unit (215) may perform downlink reception signal processing, uplink transmission signal processing, sidelink reception signal processing, etc. In addition to performing baseband-related signal processing, the processor (210) may also control the overall operation of the second device (210).

[0554] The antenna section (220) may include one or more physical antennas, and may support MIMO transmission and reception if it includes multiple antennas. The transceiver (230) may include an RF transmitter and an RF receiver. The memory (240) may store information processed by the processor (210) and software, operating systems, applications, etc. related to the operation of the second device (200), and may include components such as a buffer.

[0555] The processor (210) of the second device (200) may be configured to implement the operation of the terminal in base station-terminal communication (or the operation of the second terminal device in terminal-terminal communication) in the embodiments described in this disclosure.

[0556] In the operation of the first device (100) and the second device (200), the details described in the examples of the present disclosure regarding the base station and terminal (or the first terminal and the second terminal in terminal-to-terminal communication) in base station-to-terminal communication may be applied in the same way, and redundant descriptions are omitted.

[0557] Here, the wireless communication technology implemented in the device of the present disclosure may include LTE, NR, and 6G, as well as Narrowband Internet of Things (NB-IoT) for low-power communication. For example, NB-IoT technology may be an example of Low Power Wide Area Network (LPWAN) technology and may be implemented according to standards such as LTE Cat NB1 and / or LTE Cat NB2, but is not limited to the names mentioned above.

[0558] Additionally or alternatively, the wireless communication technology implemented in the device of the present disclosure may perform communication based on LTE-M technology. For example, LTE-M technology may be an example of LPWAN technology and may be referred to by various names such as eMTC (enhanced Machine Type Communication). For example, LTE-M technology may be implemented in at least one of various standards such as 1) LTE CAT 0, 2) LTE Cat M1, 3) LTE Cat M2, 4) LTE non-BL (non-Bandwidth Limited), 5) LTE-MTC, 6) LTE Machine Type Communication, and / or 7) LTE M, and is not limited to the names mentioned above.

[0559] Additionally or generally, the wireless communication technology implemented in the device of the present disclosure may include at least one of ZigBee, Bluetooth, and a Low Power Wide Area Network (LPWAN) for low-power communication, but is not limited to the names mentioned above. For example, ZigBee technology can create personal area networks (PANs) related to small / low-power digital communication based on various standards such as IEEE 802.15.4 and may be referred to by various names.

Claims

1. Regarding the method, A step of receiving configuration information related to Channel State Information (CSI) from a base station by a terminal, wherein the configuration information includes a first reporting configuration related to prediction and a second reporting configuration related to prediction accuracy; A step of transmitting a first CSI report related to the prediction to the base station by the terminal; and The method includes the step of transmitting a second CSI report related to the prediction accuracy to the base station by the terminal; A method characterized by transmitting the second CSI report only when the reception related to the performance metric calculation is not delayed beyond a defined time, and dropping the second CSI report otherwise.

2. In Paragraph 1, The above second CSI report is based on semi-persistent CSI (semi-persistent, SP, CSI), and A method characterized in that the reception related to the calculation of the above performance metric includes the reception of one or more latest transmission occasions for each of the resources based on the resource set related to the second reporting setting after the activation of the SP CSI.

3. In Paragraph 1, The above reception is associated with one or more latest transmission occasions for each of the resources based on the resource set associated with the second reporting setting, and The second CSI report is transmitted based on the fact that the number of the above one or more recent transmission opportunities is greater than or equal to the number for calculating the performance metric, and A method characterized by dropping the second CSI report based on the fact that the number of the above one or more latest transmission opportunities is smaller than the number for calculating the performance metric.

4. In Paragraph 1, A method characterized in that the above-defined point in time is based on the slot associated with the above-described second CSI report.

5. In Paragraph 4, A method characterized in that the slot associated with the second CSI report is a CSI reference resource associated with the second CSI report.

6. In Paragraph 4, A method characterized in that the time interval prior to the point defined above is related to the buffering of the first CSI report.

7. In Paragraph 6, A method characterized in that the size of the above time interval is based on terminal performance (UE capability).

8. In Paragraph 1, A method characterized in that the first time domain behavior associated with the first reporting setting is different from the second time domain behavior associated with the second reporting setting.

9. In Paragraph 8, A method characterized in that the first time domain operation is periodic, and the second time domain operation is semi-persistent or aperioditic.

10. In Paragraph 8, A method characterized in that the first time domain operation is semi-persistent and the second time domain operation is aperioditic.

11. In Paragraph 1, A method characterized in that the first time domain behavior associated with the first reporting setting is identical to the second time domain behavior associated with the second reporting setting.

12. In Paragraph 11, A method characterized in that the first time domain operation is semi-persistent and the second time domain operation is semi-persistent.

13. In Paragraph 12, A method characterized in that the periodicity associated with the second CSI report is less than or equal to the length of the time interval prior to the defined point in time.

14. In Paragraph 1, A method characterized in that the second report setting includes a report config ID, and the second report setting is connected to the first report setting among the report settings in the setting information by the report config ID.

15. In Paragraph 14, The above first CSI report is a linked report determined for the transmission occasion of the resource set associated with the above second report setting, and A method characterized by determining the linking based on the fact that the CSI reference resource associated with the first CSI report has a minimal slot offset from the slot of the transmission occasion.

16. In Paragraph 1, Number of bits of UCI information for determining the PUCCH resource set of the above 2nd CSI report (O UCI A method characterized by ) being determined to be 3 or 4.

17. In the terminal, One or more transmitters / receivers; One or more processors; and It includes one or more memories connected to the above one or more processors and storing instructions, A terminal characterized by the above instructions enabling the terminal to perform all steps of the method according to any one of claims 1 to 16, based on execution by the one or more processors.

18. A device comprising one or more memories and one or more processors connected to the one or more memories, An apparatus characterized in that the above one or more memories store instructions that cause the apparatus to perform all steps of the method according to any one of claims 1 to 16, based on execution by the above one or more processors.

19. In a non-transitory computer-readable storage medium for storing instructions, A non-transitory computer-readable storage medium characterized by instructions executable by one or more processors such that the terminal performs all steps of the method according to any one of claims 1 to 16.

20. Regarding the method, A step of transmitting configuration information related to Channel State Information (CSI) to a terminal by a base station, wherein the configuration information includes a first reporting configuration related to prediction and a second reporting configuration related to prediction accuracy; A step of receiving a first CSI report related to the prediction from the terminal by the base station; and The method includes the step of receiving a second CSI report related to the prediction accuracy from the terminal by the base station; A method characterized in that the second CSI report is received only when the reception of the terminal related to the performance metric calculation is not delayed beyond a defined time, and the second CSI report is dropped otherwise.

21. Regarding base stations, One or more transmitters / receivers; One or more processors; and It includes one or more memories connected to the above one or more processors and storing instructions, A base station characterized by the above instructions, based on execution by one or more processors, having the base station perform all steps of the method according to claim 20.

Images