Method for monitoring performance of model, and apparatus therefor

An event-based reporting method for AI/ML model performance monitoring in mobile communication systems addresses uplink overhead and power consumption issues by transmitting reports only when significant events occur, enhancing resource management and response efficiency.

WO2025174129A1PCT designated stage Publication Date: 2025-08-21LG ELECTRONICS INC
View PDF 3 Cites 0 Cited by

Patent Information

Application Number
PCT/KR2025/002217
Authority / Receiving Office
WO · WO
Patent Type
Applications
Current Assignee / Owner
Priority Date
2024-02-15
Filing Date
2025-02-14
Publication Date
2025-08-21

AI Technical Summary

Technical Problem

Existing mobile communication systems face challenges in managing resource shortages and user demands for faster services due to explosive data traffic growth, necessitating advanced technologies like AI/ML for beam management, where periodic performance monitoring reporting increases uplink overhead and power consumption.

Method used

Implement an event-based reporting method for AI/ML model performance monitoring, using events defined by differences in measured and predicted RSRP, confidence levels, and probability of RSRP, transmitted via PUCCH, MAC CE, PRACH, and PUSCH, to reduce uplink signaling overhead and enable timely reporting of significant performance changes.

Benefits of technology

Reduces uplink signaling overhead and minimizes delays in responding to significant model performance deterioration by allowing reports only when necessary events occur, ensuring efficient resource management and reduced power consumption.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure KR2025002217_21082025_PF_FP_ABST
    Figure KR2025002217_21082025_PF_FP_ABST
Patent Text Reader

Abstract

A method according to one embodiment of the present specification comprises the steps of: receiving configuration information; and transmitting a report on the basis of the configuration information. The report is transmitted on the basis of an event related to performance monitoring for a model.
Need to check novelty before this filing date? Find Prior Art

Description

Method and device for monitoring model performance

[0001] This specification relates to a method and device for monitoring the performance of a model.

[0002] Mobile communication systems were developed to provide voice services while ensuring user activity. However, they have expanded beyond voice to include data services. Currently, explosive growth in traffic is leading to resource shortages and users are demanding faster services, necessitating a more advanced mobile communication system.

[0003] Next-generation mobile communication systems must support explosive data traffic growth, dramatically increasing data rates per user, a vastly increased number of connected devices, ultra-low end-to-end latency, and high energy efficiency. To achieve these goals, various technologies are being studied, including dual connectivity, massive multiple input multiple output (MIMO), in-band full duplex, non-orthogonal multiple access (NOMA), super wideband support, and device networking.

[0004] In Rel-18 AI / ML SI, studies were conducted on how to utilize AI / ML technology in three topics: CSI prediction, beam prediction, and positioning. In Rel-19 AI / ML WI, standardization is being discussed in the fields of beam management and positioning. In particular, in the field of beam management, sub-use cases were defined for spatial domain DL Tx beam prediction and temporal DL Tx beam prediction. Both NW-side AI / ML and UE-side AI / ML are considered for each sub-use case. In particular, in the inference operation of NW-side AI / ML and UE-side AI / ML, the configuration method for Set B, which can be input data, and Set A, which is the target of prediction, must be defined so that related terminal reporting can be performed.

[0005] Additionally, standardization discussions will be conducted on performance monitoring operations of UE-side AI / ML.

[0006] Meanwhile, the terminal can perform performance monitoring reporting by comparing measured and predicted results. If such performance monitoring reporting is performed periodically, the terminal-side UL overhead increases.

[0007] The purpose of this specification is to propose a method to solve the above-mentioned problems.

[0008] The technical problems to be achieved in this specification are not limited to the technical problems mentioned above, and other technical problems not mentioned can be clearly understood by a person having ordinary skill in the technical field to which this specification pertains from the description below.

[0009] A method according to one embodiment of the present disclosure includes the steps of receiving configuration information and transmitting a report based on the configuration information. The report is characterized in that it is transmitted based on an event related to performance monitoring of a model.

[0010] The above events may include events defined based on the difference between i) measured Reference Signal Received Power (RSRP) and ii) predicted RSRP.

[0011] The above event may include an event defined based on a mismatch between i) a first RS resource index and ii) a second RS resource index. The first RS resource index may be associated with a highest measured Reference Signal Received Power (RSRP). The second RS resource index may be associated with a highest predicted RSRP.

[0012] The above event may include an event defined based on prediction accuracy. The prediction accuracy may be determined based on a comparison of i) at least one first RS resource index determined in order of highest measured Reference Signal Received Power (RSRP) and ii) at least one second RS resource index determined in order of highest predicted RSRP.

[0013] The above events may include events defined based on the confidence level or probability of the RS having the largest predicted Reference Signal Received Power (RSRP).

[0014] The above report may be transmitted based on a Physical Uplink Control Channel (PUCCH) associated with a Scheduling Request (SR).

[0015] Based on the codepoint associated with the above SR, i) beam set change, ii) model / functionality switching, iii) model / functionality stop, or iv) fallback request may be indicated.

[0016] The above report can be transmitted based on MAC CE (Medium Access Control Control Element).

[0017] The above MAC CE may include i) information indicating the type of the event and / or ii) information indicating the extent to which a reference value related to the event deviates from a threshold value.

[0018] The above report may be transmitted based on a physical random access channel (PRACH). Information related to the report may be determined based on a synchronization signal block index (SSB) associated with the PRACH.

[0019] The above MAC CE may be associated with a physical uplink shared channel (PUSCH) scheduled by a UL grant. The UL grant may be i) a RAR UL grant or ii) a UL grant other than the RAR UL grant.

[0020] The above report may include information about at least one performance metric associated with the event.

[0021] The above report may be transmitted based on a counter related to the number of occurrences of the above event.

[0022] A terminal according to another embodiment of the present disclosure includes one or more transceivers, one or more processors, and one or more memories connected to the one or more processors and storing instructions.

[0023] The above instructions are characterized in that they cause the terminal to perform all steps of any one of the above methods based on being executed by the one or more processors.

[0024] According to another embodiment of the present disclosure, a device comprises one or more memories and one or more processors connected to the one or more memories. The one or more memories are characterized in that they store instructions that cause the device to perform all steps of any one of the above methods based on instructions executed by the one or more processors.

[0025] A non-transitory computer-readable storage medium according to another embodiment of the present disclosure stores instructions. The instructions, executable by one or more processors, are characterized in that they cause a terminal to perform all steps of any one of the above methods.

[0026] A method according to another embodiment of the present disclosure comprises the steps of transmitting configuration information and receiving a report based on the configuration information. The report is characterized in that it is received based on an event related to performance monitoring of a model.

[0027] According to another embodiment of the present disclosure, a base station comprises one or more transceivers, one or more processors, and one or more memories connected to the one or more processors and storing instructions. The instructions are characterized in that, based on execution by the one or more processors, cause the base station to perform all steps of the method.

[0028] If the number of performance monitoring-related reports is reduced solely by considering UL signaling overhead without any specific criteria, the status of the model may not be reported in a timely manner when its performance deteriorates significantly. According to the embodiments of this specification, reports are transmitted based on events related to performance monitoring. Therefore, the UL signaling overhead required for performance monitoring-related reports can be reduced compared to existing methods.

[0029] Additionally, when a major event related to model performance occurs, reporting can be performed more quickly than when model performance monitoring-related reporting is simply performed on a periodic basis. Therefore, when a major event related to model performance occurs, the delay before required follow-up actions (e.g., model switching or fallback) are performed on the current model state can be minimized.

[0030] The effects that can be obtained from this specification are not limited to the effects mentioned above, and other effects that are not mentioned can be clearly understood by a person having ordinary skill in the technical field to which this specification belongs from the description below.

[0031] Figure 1 is a flowchart showing an example of a CSI-related procedure.

[0032] Figure 2 illustrates the functional framework of the AI / ML model.

[0033] FIG. 3 illustrates an example of a CSI reporting setting according to an embodiment of the present specification.

[0034] FIG. 4 illustrates another example of a CSI reporting configuration according to an embodiment of the present specification.

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

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

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

[0038] Hereinafter, preferred embodiments according to the present disclosure will be described in detail with reference to the accompanying drawings. The detailed description set forth below, together with the accompanying drawings, is intended to illustrate exemplary embodiments of the present disclosure and is not intended to represent the only embodiments in which the present disclosure may be implemented. The following detailed description includes specific details to provide a thorough understanding of the present disclosure.

[0039] Hereinafter, downlink (DL) refers to communication from a base station to a terminal, and uplink (UL) refers to communication from a terminal to a base station. In downlink, a transmitter may be part of a base station, and a receiver may be part of a terminal. In uplink, a transmitter may be part of a terminal, and a receiver may be part of a base station. A base station may be expressed as a first communication device, and a terminal may be expressed as a second communication device. A base station (BS) may be replaced by terms such as a fixed station, Node B, eNB (evolved-NodeB), gNB (Next Generation NodeB), BTS (base transceiver system), access point (AP: Access Point), network (5G network), AI system, RSU (road side unit), vehicle, robot, drone (Unmanned Aerial Vehicle, UAV), AR (Augmented Reality) device, VR (Virtual Reality) device, etc. In addition, the terminal may be fixed or mobile, and may be replaced with terms such as UE (User Equipment), MS (Mobile Station), UT (user terminal), MSS (Mobile Subscriber Station), SS (Subscriber Station), AMS (Advanced Mobile Station), WT (Wireless terminal), MTC (Machine-Type Communication) device, M2M (Machine-to-Machine) device, D2D (Device-to-Device) device, vehicle, robot, AI module, drone (Unmanned Aerial Vehicle, UAV), AR (Augmented Reality) device, VR (Virtual Reality) device, etc.

[0040] < Beam Management (BM) >

[0041] 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 terminology.

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

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

[0044] - Beam sweeping: The operation of covering a spatial area using a transmit and / or receive beam over a predetermined time interval in a predetermined manner.

[0045] - Beam report: An operation in which a UE reports information about a beam-formed signal based on beam measurement.

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

[0047] Additionally, each BM procedure may include Tx beam sweeping to determine the Tx beam and Rx beam sweeping to determine the Rx beam.

[0048] DL BM

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

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

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

[0052] An example of beamforming using SSB and CSI-RS is described in detail below.

[0053] Both SSB 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, and CSI-RS can be used for fine beam measurement. SSB can be used for both Tx beam sweeping and Rx beam sweeping.

[0054] Rx beam sweeping using SSB can be performed by the UE changing the Rx beam for the same SSBRI across multiple SSB bursts, where one SS burst contains one or more SSBs, and one SS burst set contains one or more SSB bursts.

[0055] Below we will look at the DL BM procedure.

[0056] The configuration for beam report using SSB is performed during CSI / beam configuration in RRC connected state (or RRC connected mode).

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

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

[0059]

[0060] In Table 1, the csi-SSB-ResourceSetList parameter indicates 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.

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

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

[0063] That is, when 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.

[0064] And, if the terminal sets the CSI-RS resource 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 from the 'QCL-TypeD' perspective.

[0065] Here, the QCL TypeD may mean that the antenna ports are QCL-connected from a spatial Rx parameter perspective. When a terminal receives multiple DL antenna ports in a QCL Type D relationship, the same reception beam may be applied. In addition, the terminal does not expect the CSI-RS to be configured in an RE that overlaps with the SSB RE.

[0066] < CSI-related actions >

[0067] Figure 1 is a flowchart showing an example of a CSI-related procedure.

[0068] Referring to Fig. 1, in order to perform one of the purposes 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) through RRC (radio resource control) signaling (S110).

[0069] The configuration information related to the above CSI may include at least one of CSI-IM (interference management) resource related information, CSI measurement configuration related information, CSI resource configuration related information, CSI-RS resource related information, or CSI report configuration related information.

[0070] CSI resource configuration related information can be expressed as CSI-ResourceConfig IE. The CSI resource configuration related information defines a group including at least one of a non-zero power (NZP) CSI-RS resource set, a CSI-IM resource set, or a CSI-SSB resource set. That is, the CSI resource configuration related information includes a CSI-RS resource set list, and the CSI-RS resource set list can 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.

[0071] Information related to the CSI report configuration includes a reportConfigType parameter indicating a time domain behavior and a reportQuantity parameter indicating a CSI-related quantity to be reported. The time domain behavior may be periodic, aperiodic, or semi-persistent.

[0072] The above reportQuantity parameter may be related to at least one of a channel quality indicator (CQI), a precoding matrix indicator (PMI), a CSI-RS resource indicator (CRI), an SSB resource block indicator (SSBRI), a layer indicator (LI), a rank indicator (RI), and a layer 1-reference signal received strength (L1-Reference Signal Received Strength (RSRP).

[0073] Measurement resources may include configurations for downlink signals and / or downlink resources on which a terminal will perform measurements to determine feedback information. Measurement resources may be configured as ZP and / or NZP CSI-RS resource sets associated with CSI reporting configurations. The NZP CSI-RS resource set may include a CSI-RS set or an SSB set. For example, L1-RSRP may be measured for a CSI-RS set or an SSB set.

[0074] The terminal measures CSI based on configuration information related to the CSI (S120). The CSI measurement may include (1) a process of receiving a CSI-RS by the terminal (S121) and (2) a process of calculating CSI using the received CSI-RS (S122). The terminal reports the CSI to the base station (S130).

[0075] Resource setting

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

[0077] One or more CSI resource settings for channel measurement (CM) and interference measurement (IM) are configured via higher layer signaling.

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

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

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

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

[0082] Here, CSI-IM (or ZP CSI-RS for IM) is mainly used for inter-cell interference measurement.

[0083] And, NZP CSI-RS for IM is mainly used for intra-cell interference measurement from multi-user.

[0084] A UE may assume that the CSI-RS resource(s) configured for channel measurement 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) are in a QCL relationship with respect to 'QCL-TypeD' per resource.

[0085] As we have seen, resource setting can mean a resource set list.

[0086] 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 or semi-persistent or aperiodic resource setting.

[0087] One reporting setting can be linked to up to three resource settings.

[0088] < Description of Rel-17 / 18 beam management >

[0089] In Rel-17, both the DL TCI state and the UL TCI state can be indicated through DL DCI (e.g., DCI format 1-1 or 1-2), or only the UL TCI state can be indicated without indicating the DL TCI state. Therefore, the methods used for UL beam and power control (PC) configuration in the existing R15 / R16 are replaced in Rel-17 with the above UL TCI state indication method. More specifically, in R17, one UL TCI state can be indicated through the TCI field of DL DCI, and the UL TCI state is applied to all PUSCHs and all PUCCHs after a certain time called the beam application time, and can be applied to some or all of the indicated SRS resource sets. In addition, the base station can perform a terminal common beam update by using DCI and / or MAC-CE to perform indication / update with one beam in common (using a joint or separate TCI state) for specific DL / UL channel / RS combinations of multiple terminals. The target channels / RS of common beam update include UE-dedicated CORESET, UE-dedicated reception on PDSCH for DL, DG / CG-PUSCH, all or a subset of dedicated PUCCH for UL, and additionally, AP CSI-RS for tracking / BM, SRS can be set as target channels / 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 has been standardized, and the uplink / downlink resources to which multiple indicated TCIs are applied can be defined / configured depending on the S-DCI based M-TRP environment and the M-DCI based M-TRP environment.

[0090] < AIML related explanation >

[0091] Advances in AI / ML (Artificial intelligence / machine learning) technology are leading to the intelligence / advanced advancement of the nodes and terminals that make up wireless communication networks.

[0092] Below, a functional framework for AI operation is described with reference to FIG. 2.

[0093] Figure 2 illustrates the functional framework of the AI / ML model.

[0094] Below, to explain AI (or AI / ML) more specifically, the terms can be defined as follows.

[0095] - Data collection: Data collected from network nodes, management entities, or UEs as a basis for AI model training, data analysis, and inference.

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

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

[0098] - AI / ML Inference: The process of making predictions or inducing decisions based on collected data and the AI ​​model using a trained AI model.

[0099] Referring to FIG. 2, the data collection function (10) is a function that collects input data and provides processed input data to the model training function (20) and the model inference function (30).

[0100] Examples of input data may include measurements from UEs or other network entities, feedback from actors, and output from AI models.

[0101] The Data Collection function (10) performs data preparation based on input data and provides input data processed through data preparation. Here, the Data Collection function (10) does not perform data preparation specific to each AI algorithm (e.g., data pre-processing and cleaning, formatting, and transformation), but can perform data preparation common to AI algorithms.

[0102] After the data preparation process is performed, the Model Training function (10) provides training data (11) to the Model Training function (20) and provides inference data (Inference Data) (12) to the Model Inference function (30). Here, the Training Data (11) is data required as input for the AI ​​Model Training function (20). The Inference Data (12) is data required as input for the AI ​​Model Inference function (30).

[0103] The Data Collection function (10) may be performed by a single entity (e.g., UE, RAN node, network node, etc.) or may be performed by multiple entities. In this case, Training Data (11) and Inference Data (12) may be provided to the Model Training function (20) and Model Inference function (30), respectively, from multiple entities.

[0104] The Model Training function (20) is a function that performs AI model training, validation, and testing, which can generate model performance metrics as part of the AI ​​model testing process. If necessary, the Model Training function (20) also handles data preparation (e.g., data pre-processing and cleaning, forming, and transformation) based on the Training Data (11) provided by the Data Collection function (10).

[0105] Here, Model Deployment / Update (13) is used to initially deploy the trained, verified, and tested AI model to the Model Inference function (30) or to provide the updated model to the Model Inference function (30).

[0106] The Model Inference function (30) is a function that provides AI model inference output (16) (e.g., prediction or decision). If applicable, the Model Inference function (30) may provide model performance feedback (14) to the Model Training function (20). In addition, the Model Inference function (30) is also responsible for data preparation (e.g., data pre-processing and cleaning, forming, and transformation) based on the Inference Data (12) provided by the Data Collection function (10), if necessary.

[0107] Here, Output (16) refers to the inference output of the AI ​​model generated by the Model Inference function (30), and the details of the inference output may vary depending on the use case.

[0108] Model Performance Feedback (14) can be used to monitor the performance of the AI ​​model if available, and this feedback may be omitted.

[0109] The actor function (40) is a function that receives the output (16) from the model inference function (30) and triggers or performs a corresponding task / action. The actor function (40) can trigger tasks / actions for other entities (e.g., one or more UEs, one or more RAN nodes, one or more network nodes, etc.) or for itself.

[0110] Feedback (15) can be used to derive training data (11), inference data (12), or to monitor the performance of the AI ​​model, its impact on the network, etc.

[0111] Meanwhile, the definitions of training / validation / test in the data set used in AI / ML can be distinguished as follows.

[0112] - Training data: This refers to the data set for learning the model.

[0113] - Validation data: This refers to a data set used to validate a model that has already completed training. In other words, it refers to a data set typically used to prevent overfitting of the training data set.

[0114] It also refers to a data set for selecting the best model among the various models learned during the learning process. Therefore, it can be viewed as a type of learning.

[0115] - Test data: This refers to the data set for final evaluation. This data is unrelated to learning.

[0116] In the case of the above data set, if the training set is generally divided, the training data and validation data can be divided and used in a ratio of 8:2 or 7:3 within the entire training set, and if the test is included, it can be divided and used in a ratio of 6:2:2 (training: validation: test).

[0117] The functions exemplified in FIG. 2 above may be implemented in a RAN node (e.g., a base station, a TRP, a central unit (CU) of a base station, etc.), a network node, an operation administration maintenance (OAM) of a network operator, or a UE.

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

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

[0120] For example, in this specification, 'beam' may mean 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 / replaced 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.).

[0121] For example, a beam associated with 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 transmit spatial filter (UL Tx spatial filter), or vi) an uplink receive spatial filter (UL Rx spatial filter).

[0122] 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 transmit spatial filter (DL Tx spatial filter) or vi) a downlink receive spatial filter (DL Rx spatial filter).

[0123] In the NR standard, QCL setting and spatialRelation setting by TCI state setting are utilized to set the UL / DL transmission / reception beam of the terminal. In the Rel-15 NR standard, RRC and MAC CE signaling are mainly used for UL / DL number / transmission beam. Dynamic signaling was allowed only for the reception beam of the PDSCH using the TCI state field of the DL grant DCI. The Rel-17 / 18 NR standard introduced a unified TCI framework. Specifically, a method was introduced to dynamically manage the common beam by indicating the reception / transmission beam using the indicated TCI using DCI. Meanwhile, in the Rel-18 AI / ML study item, a study was conducted on performance evaluation and specification impact in the spatial beam prediction and temporal beam prediction sub-use cases in the beam management field. The study discussed the NW / UE-side AI / ML operation that predicts the best beam of Set A based on Set B measurements. For UE-side AI / ML, the operation in which the terminal measures Set B and reports the predicted Set A beam can be discussed in the Rel-19 AI / ML work item. In this case, if the beam prediction performance of the terminal is poor, it is necessary to switch the AI / ML model / functionality on the terminal side or fallback to non-AI / ML-based conventional beam management rather than AI / ML-based beam management (measurement / reporting).

[0124] 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 the base station when a specific event occurs.

[0125] < UE initiated BM related background >

[0126] In existing LTE / NR systems, the reporting of CSI / beam information from a UE is determined / controlled by the base station / network (except in the case of BFR). These NW (network)-initiated / triggered reports have limitations in that they require UEs to be configured / instructed to frequently send CSI / beam information in environments where the wireless channel is likely to change rapidly. In such environments, the UL resource overhead for CSI / beam reporting and the related DL measurement RS overhead increase, and the UE's power consumption also increases due to frequent uplink transmission. Furthermore, the more UEs within cell / TRP coverage, the greater the UL resource overhead, as each UE must be allocated UL resources. To overcome these limitations of NW-initiated / triggered reports, recently emerging approaches are UE-initiated / triggered reports or event-based / triggered reports.

[0127] In the UE-initiated / triggered report method or event-based / triggered report method, the UE determines whether and when to report. By performing the report only when necessary (e.g., when a specific event occurs), UL resource overhead and UE power consumption can be reduced. With the above motivation, standardization of UE-initiated / triggered beam reports is expected in NR Rel-19. Furthermore, in 6G communication systems, UE-initiated / triggered or event-based transmission methods can be more actively expanded and adopted to efficiently manage uplink resources.

[0128] In the NR system, there are two representative reporting methods for event-based or UE-initiated / triggered information: SR (scheduling request) and BFR (beam failure recovery). SR reports whether PUSCH allocation is required for UL-SCH transmission, and BFR reports whether BF occurs and new beam-related information. This information is conveyed / transmitted to the base station in an explicit or implicit manner (e.g., conveying a new beam index as PRACH resource selection information). The above-mentioned SR / BFR-related information is conveyed simultaneously or separately through one or two UL resources (e.g., BFRQ on PUCCH + beam information via MAC-CE on PUSCH).

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

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

[0131] In the Rel-18 AI / ML study item, we conducted a study on performance analysis and potential specification impact through evaluation when NW and / or UE-side AI / ML models operate in three use cases: CSI compression / prediction, beam management, and positioning. In particular, in the beam management use case, we divided the sub-use cases into BM-case1 and BM-case2, and studied performance analysis and potential specification impact for spatial domain beam prediction and temporal beam prediction. The WID goals of AI / ML BM, BM-case1, and BM-case2 are summarized in Tables 2 to 4 below.

[0132] - AI / ML BM's WID goals

[0133]

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

[0135]

[0136] - BM-case2: Temporal downlink beam prediction for beam set A based on past measurement results for beam set B.

[0137]

[0138] Additionally, an example of the operation for data collection of AI / ML models in the Beam management use case is shown in Table 5 below.

[0139]

[0140] Additionally, an example of the operation for inference of AI / ML model in Beam management use case is as shown in Table 6 below.

[0141]

[0142] < Method for beam prediction >

[0143] As cited above, the NW / UE-side AI / ML operation that predicts the best beam of Set A based on Set B measurements was discussed. For UE-side AI / ML, the UE is required to measure Set B and report the predicted Set A beam. For NW-side AI / ML, the UE is required to report the Set B measurements.

[0144] Based on the above background, the following examines the beam measurement / reporting setup method for base station-side AI / ML and terminal-side AI / ML, as well as the subsequent base station / terminal operations.

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

[0146] Proposal 1

[0147] For beam prediction operation of the NW-side AI / ML model and / or the UE-side AI / ML model, a method of configuring one or more combinations associated with a specific CSI-ReportConfig may be considered. Each combination may include i) one or more Set As and ii) one or more Set Bs associated with each of the one or more Set As. The base station may configure the one or more combinations associated with the specific CSI-ReportConfig to the terminal.

[0148] For example, a specific CSI-ReportConfig may be related / connected to multiple CSI-ResourceConfigs. The multiple CSI-ResourceConfigs may include a CSI-ResourceConfig related to Set A and a CSI-ResourceConfig related to Set B. As a specific example, the specific CSI-ReportConfig may include information about the multiple CSI-ResourceConfigs (e.g., an ID of each of the multiple CSI-ResourceConfigs; CSI-ResourceConfigId). As a specific example, multiple CSI-ResourceConfigs related to the specific CSI-ReportConfig may be set.

[0149] For example, multiple CSI resource sets may be configured / connected to a CSI-ResourceConfig for a specific CSI-ReportConfig. The multiple CSI resource sets may include a CSI resource set related to Set A and a CSI resource set related to Set B. As a specific example, the specific CSI-ReportConfig may include information about the CSI-ResourceConfig (e.g., CSI-ResourceConfigId). The CSI-ResourceConfig may include multiple CSI resource sets.

[0150] In the above examples, CSI-ResourceConfig may be related to channel measurement.

[0151] The methods for setting / connecting one or more of the above combinations (Set A / Set B combinations) are described in more detail in the examples below.

[0152] Example 1 of Proposal 1)

[0153] A base station can configure / connect one Set A and one or more Set Bs for a specific CSI-ReportConfig for beam prediction purposes. CSI-ReportConfig based on Embodiment 1) below is described with reference to FIG. 3.

[0154] Fig. 3 illustrates an example of a CSI reporting configuration according to an embodiment of the present specification. Specifically, Fig. 3 illustrates Set A / Set B based on CSI-ReportConfig. Referring to Fig. 3, CSI-ReportConfig#1 may be associated with Set A and three Set Bs. The three Set Bs include i) Set B configured based on 1 / 8 of the beams (e.g., RS indices or RS resources) in Set A, ii) Set B configured based on 1 / 16 of the beams in Set A, and iii) Set B configured based on beams other than the beams in Set A.

[0155] Subsequently, information may be indicated as to which Set B the terminal will utilize for beam measurement / reporting purposes for the specific CSI-ReportConfig. For example, one of the Set Bs associated with the specific CSI-ReportConfig may be activated. As a specific example, the base station may transmit information (e.g., an activation message) to the terminal for activating one of the Set Bs associated with the specific CSI-ReportConfig. The information may be transmitted based on MAC CE or DCI.

[0156] Example 2 of Proposal 1)

[0157] A base station can set / connect i) multiple Set As and ii) multiple Set Bs associated / related with each of the multiple Set As for a specific CSI-ReportConfig for beam prediction purposes. CSI-ReportConfig based on embodiment 2) is described below with reference to FIG. 4.

[0158] FIG. 4 illustrates another example of a CSI reporting configuration according to an embodiment of the present disclosure. Specifically, FIG. 3 illustrates combinations of Set A / Set B based on CSI-ReportConfig. Referring to FIG. 4, CSI-ReportConfig#1 may be associated with three combinations.

[0159] Set A / B combination #1 may include Set A (Set A #1) and two Set Bs. The two Set Bs include i) Set B configured based on 1 / 4 of the beams (e.g., RS indices or RS resources) in Set A #1, and ii) Set B configured based on 1 / 8 of the beams in Set A #1.

[0160] Set A / B combination #2 may include Set A (Set A #2) and three Set Bs. The three Set Bs include i) Set B configured based on 1 / 8 of the beams (e.g., RS indices or RS resources) in Set A #2, ii) Set B configured based on 1 / 16 of the beams in Set A #2, and iii) Set B configured based on beams other than the beams in Set A #2.

[0161] Set A / B combination #3 may include Set A (Set A #3) and two Set Bs. The two Set Bs include i) Set B configured based on 1 / 4 of the beams (e.g., RS indices or RS resources) in Set A #3, and ii) Set B configured based on beams other than the beams in Set A #3.

[0162] Subsequently, information may be indicated as to which Set A and which Set B (associated / related with the Set A) for the specific CSI-ReportConfig is to be utilized by the terminal for beam measurement / reporting purposes. For example, i) a specific Set A among a plurality of Set As associated with the specific CSI-ReportConfig and ii) a specific Set B among a plurality of Set Bs associated with the specific Set A may be activated. As a specific example, the base station may transmit information (e.g., an activation message) for activating the specific Set A and the specific Set B associated with the specific CSI-ReportConfig to the terminal. The information may be transmitted based on MAC CE or DCI.

[0163] For example, in the embodiment of the above proposal 1, Set B may be set / linked to a specific CSI-ReportConfig in the form of a separate CSI resource set from Set A.

[0164] For example, in the embodiment of the proposal 1, Set B may be configured to include some resources among a plurality of CSI resources in a CSI resource set set as Set A. Base station signaling related to the configuration of Set B may be performed. For example, beams corresponding to 64 CSI resources may exist in Set A. In this case, a specific Set B may be configured based on a 64-bitmap. Specifically, the 64-bitmap indicates CSI resources belonging to the specific Set B among the 64 CSI resources in Set A.

[0165] Additionally, for environments where Set A and Set B do not intersect (e.g., when Set A and Set B are different), Set B can be defined / set as follows.

[0166] For example, Set B may be defined / configured based on i) CSI resource(s) within Set A and ii) coefficient value(s) applied to the CSI resource(s). As a specific example, one or more beams of Set B may be configured based on a linear combination. The linear combination may be based on CSI resources and coefficient values ​​associated with the resources.

[0167] For example, one or more beams of Set B can be set based on a 2D-bitmap for a beamforming range (e.g., horizontal angle, vertical angle).

[0168] Specifically, when the embodiment of Proposal 1 is utilized for UE-side AI / ML, the terminal can report information indicating preferred Set A and / or Set B for terminal-side beam prediction operation to the base station. As a specific example, among the Set As and Set Bs based on Embodiments 1 and 2 described above, the terminal can report preferred Set A and / or preferred Set B to the base station. Subsequently, the base station can activate (using MAC CE signaling, etc.) the combination of Set A and Set B preferred by the terminal for the specific CSI-ReportConfig.

[0169] Effect of the above suggestion 1

[0170] When the terminal performs a report for the Set B beam through the Set A / B beam set setting operation of the above proposal 1, the base station can perform a beam prediction operation for Set A using the NW sided AI / ML, and the terminal can derive the predicted Set A beam using the Set B beam measurement (as input data of the UE sided AI / ML).

[0171] In addition, NW / UE-side AI / ML models / functionality may vary, and even the size of input data may vary for a specific model / functionality. In this case, based on the present embodiment, various combinations of Set A and Set B may be preset in the terminal by the base station. The combination of Set A and Set B suitable for the AI / ML model / functionality of the NW / UE may be adaptively activated / indicated (via MAC CE or DCI) in response to changes in the input data size. This operation may result in effects such as delay reduction and improved beam prediction performance.

[0172] Proposal 2

[0173] The base station may set reportQuantity related to reports of Alt 1) to Alt 5) below for beam measurement / reporting of the terminal for the CSI-ReportConfig of the above proposal 1. For example, reportQuantity may be set to a value indicating a report based on at least one of Alt 1) to Alt 5) / information included in the report.

[0174] Alt 1)

[0175] Based on the reportQuantity set by the base station, the terminal can report the L1-RSRP value for one or more CMRs (Channel Measurement Resources) related to Set B for the CSI-ReportConfig of Proposal 1. The one or more CMRs related to Set B can be i) all CMRs in Set B, ii) N CMRs (where N is a natural number) having the highest L1-RSRP value in Set B, or iii) specific N CMRs in Set B set / instructed by the base station.

[0176] Alt 2)

[0177] Based on the reportQuantity set by the base station, the terminal can perform reporting as follows. For the CSI-ReportConfig of Proposal 1, the terminal can report i) L1-RSRP value for one or more CMRs associated with Set B and ii) L1-RSRP value for one or more CMRs associated with Set A.

[0178] One or more CMRs associated with the above Set A may be i) specific N CMRs in Set A that have a connection relationship (by base station presetting) with CMRs in Set B reported by the terminal, ii) N CMRs with the highest L1-RSRP value in Set A, or iii) specific N CMRs in Set A configured / instructed by the base station.

[0179] Specifically, in addition to the report related to Set B, the report related to Set A can be performed only for a portion of the total reporting instances of the CSI-ReportConfig (e.g., 1 / X of the total reporting instances, where X is a natural number). In order to match the reporting payload when performing reports related to both Set B and Set A and when performing reports related to only Set B, the following embodiments may be considered when Set A is also reported.

[0180] i) A step size of 2 dB or more may be applied when reporting L1-RSRP of the best CMR in Set B. For example, the legacy step size may be 1 dB.

[0181] ii) A larger step size may be applied for differential reporting when reporting L1-RSRP of non-best CMRs within Set B (while utilizing a step size of 2 dB or more when reporting L1-RSRP of best CMRs). For example, according to the legacy standard, the step size for differential reporting is 2 dB, but according to this embodiment, a step size such as 4 dB, 6 dB, or 8 dB may be applied.

[0182] iii) The number of CMRs reported in Set B may be reduced or some CMRs in Set B may be omitted from reporting (e.g., N CMRs with the lowest L1-RSRP values ​​may be omitted).

[0183] Additionally, the reporting granularity for expressing L1-RSRP may be different for reports on Set B and reports on Set A.

[0184] Alt 3)

[0185] Based on the reportQuantity set by the base station, the terminal may report one or more predicted best CMRs related to Set A (based on Set B beam measurement) and the predicted L1-RSRP values ​​for the same for the CSI-ReportConfig of Proposal 1.

[0186] One or more predicted best CMRs associated with the above Set A may be specific K CMRs (where K is a natural number) set / instructed by the base station (corresponding to the highest predicted L1-RSRP value of Top-K).

[0187] Alt 4)

[0188] Based on the reportQuantity set by the base station, the terminal can perform reporting as follows. For the CSI-ReportConfig of the above proposal 1, the terminal can report i) one or more predicted best CMRs related to Set A (based on Set B beam measurement) and their predicted L1-RSRP values, and ii) (actually measured) L1-RSRP values ​​for one or more CMRs related to Set A.

[0189] The one or more CMRs associated with the above Set A may be i) specific N CMRs within Set A that have a connection relationship (by base station presetting) with the predicted best CMR associated with Set A reported by the terminal, ii) N CMRs with the highest L1-RSRP value within Set A, or iii) specific N CMRs within Set A configured / instructed by the base station.

[0190] Characteristically, in addition to the predicted CMR-related report related to Set A, the report related to Set A can be performed only for a portion of the total reporting instances of the CSI-ReportConfig (e.g., 1 / X of the total reporting instances, where X is a natural number). In order to match the reporting payload to be identical / similar when performing reports related to both the predicted CMR of Set A and Set A, and when performing reports related only to the predicted CMR of Set A, the following embodiments may be considered when Set A is also reported.

[0191] i) A step size of 2 dB or more may be applied when reporting the predicted L1-RSRP of the predicted best CMR within Set A. For example, the legacy step size may be 1 dB.

[0192] ii) A larger step size may be applied for differential reporting when reporting predicted L1-RSRP of predicted non-best CMR (while utilizing a step size of 2 dB or more when reporting predicted L1-RSRP of predicted best CMR within Set A). For example, the step size for differential reporting is 2 dB according to the legacy standard, but a step size such as 4 dB, 6 dB, or 8 dB may be applied according to this embodiment.

[0193] iii) The number of predicted CMRs reported in Set A may be reduced, or some CMRs in Set A may be omitted from reporting (e.g., the N CMRs with the lowest L1-RSRP values ​​may be omitted).

[0194] Additionally, the reporting granularity for expressing the (predicted) L1-RSRP in the report on Set A may be different from that in the report on Set A for predicted CMR.

[0195] Alt 5)

[0196] Based on the reportQuantity set by the base station, the terminal can perform reporting as follows. The terminal reports based on Alt 3 to Alt 4, but can also report based on Alt 1 if certain conditions are met. This will be described in detail below.

[0197] Based on the UE-side AI / ML, the predicted best beam performance of Set A is determined / judged to be below the reference value, and the UE may revert to Alt 1 and perform reporting. The UE may report the L1-RSRP value for one or more CMRs associated with Set B.

[0198] The reporting of the above proposal 2 can be performed using P / SP / A CSI on PUSCH / PUCCH.

[0199] The effect of Proposal 2

[0200] In Proposal 2 above, Alt 1 and Alt 2 can be utilized to secure input data for NW-side AI / ML (by having the terminal report the actually measured results of Set A / B). In particular, Alt 2 can be helpful in performing AI / ML performance monitoring by comparing the quality of Set A beam predicted by the base station with the actual quality of Set A beam.

[0201] Additionally, Alt 3 to Alt 5 in Proposal 2 can be utilized for UE-side AI / ML. In particular, Alt 4 can be helpful for the base station to perform performance monitoring of UE-side AI / ML, as the terminal compares and reports the predicted Set A beam with the measured Set A beam. Alt 5 can have the effect of returning to legacy beam management (based on the terminal's decision) by having the terminal perform performance monitoring of UE-side AI / ML.

[0202] The operations of Proposals 1 and 2 above are applicable to both spatial domain beam prediction and temporal domain beam prediction. For example, if the operations of Alt 1 to Alt 5 of Proposal 2 are applied to temporal domain beam prediction, when performing reports for specific CMRs of Set A and Set B, reports / information for multiple time instances can be included in the report of Proposal 2.

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

[0204] < Method for UE report on AI / ML model performance monitoring>

[0205] As described above, the Rel-18 AI / ML study item discussed the NW / UE sided AI / ML operation that predicts the best beam of Set A based on Set B measurements. In the case of UE sided AI / ML, the operation in which the terminal measures Set B and reports the predicted Set A beam can be discussed in the Rel-19 AI / ML work item. Methods for such operations are proposed in Proposals 1 and 2. In the UE sided AI / ML beam prediction operation including the above examples, if the beam prediction performance of the terminal is poor, operations such as switching the AI / ML model / functionality on the terminal side or falling back to non-AI / ML based conventional beam management rather than AI / ML based beam management may be required.

[0206] Performance monitoring for these AI / ML models is also required for NW-side AI / ML. In this case, the terminal measures and reports the Set A beam. The actual Set A best beam is then compared to the predicted Set A best beam on the NW side. If performance falls below a certain standard, UE-transparent model / functionality switching or fallback to conventional beam management is performed.

[0207] For UE-side AI / ML, the base station simply configures the terminal to measure Set A beam, allowing the terminal to monitor model performance. However, considering the traditional slave node role of the terminal, hybrid monitoring, in which the terminal reports performance monitoring results to the base station and the base station (taking into account system-level / cell-level circumstances) makes decisions such as model / functionality switching or fallback to conventional beam management, can be considered to improve wireless communication reliability. For example, for hybrid monitoring, the terminal can periodically report performance monitoring results to the base station. In addition to the periodic reporting described above, event-triggered reporting can be considered to save resource overhead. For example, the terminal can report only when an event occurs that affects the prediction performance of the UE-side AI / ML model.

[0208] Based on the above background, the following examines the performance monitoring method of the terminal-side AI / ML model and the operation of the terminal reporting performance monitoring results to the base station when a specific event occurs.

[0209] Proposal 3

[0210] When the terminal performs beam prediction operation using UE-side AI / ML, the terminal can report to the base station the performance monitoring results indicating that the performance of the AI / ML model has fallen below the standard when an event such as the options below occurs for performance monitoring of the AI / ML model.

[0211] For example, actions and agreements related to performance monitoring can be based on Table 7 below.

[0212]

[0213] Option 1)

[0214] An event can be defined based on the difference in RSRP values.

[0215] For example, the condition related to the event may be defined as being satisfied based on the difference between the RSRP value of the actually measured Top-K best beam related to Set A and the RSRP value of the predicted Top-K best beam (based on the output result of the UE-sided AI / ML model) related to Set A exceeding a certain threshold. In this specification, the satisfaction of the condition related to the event may be interpreted / replaced as the occurrence of the event.

[0216] For example, if the difference in RSRP value between the Top-1 beam among the actually measured Top-K best beams and the Top-1 beam among the predicted Top-K best beams exceeds a specific threshold, the event may be defined to occur (a condition related to the event may be defined to be satisfied).

[0217] For example, if the sum of the RSRP value differences (K RSRP value differences) between the actually measured Top-K best beams and the predicted Top-K best beams exceeds a specific threshold, the event may be defined as occurring (the condition related to the event may be defined as being satisfied).

[0218] In the above, the base station can set an error (RSRP) margin value to compensate for temporary measurement errors and prediction errors. Even if the RSRP difference value (or the sum of the RSRP difference values) exceeds the specific threshold, the terminal may not determine it as a prediction error if the exceeding value is within the margin value. As a specific example, it may be assumed that the RSRP difference value (or the sum of the RSRP difference values) is greater than the specific threshold by X. If X is less than or equal to the margin value, the terminal may determine that the event according to the present embodiment has not occurred.

[0219] Option 2)

[0220] An event can be defined based on a mismatch of the best beam (Top-1 beam).

[0221] For example, when comparing the actual measured Top-K best beam related to Set A with the predicted Top-K best beam (based on the output result of the UE sided AI / ML model) related to Set A, the condition related to the event can be defined as being satisfied based on the occurrence of a mismatch in the best beam (Top-1 beam).

[0222] As a concrete example, the event may be defined as having occurred (or a condition related to the event may be defined as being satisfied) based on the fact that the actual measured Top-1 best beam associated with Set A is different from the predicted Top-1 best beam (based on the output result of the UE-sided AI / ML model).

[0223] Option 3)

[0224] Events can be defined based on prediction accuracy.

[0225] For example, when comparing the actual measured Top-K best beam related to Set A and the predicted Top-K best beam related to Set A (based on the output of the UE sided AI / ML model), the condition related to the event can be defined as being satisfied based on the presence of more than K_threshold incorrect answers.

[0226] As a concrete example, it can be assumed that among predicted Top-K best beams, M predicted best beams match M actually measured best beams (corresponding to RSRP order), and KM predicted best beams are different from KM actually measured best beams. (When KM exceeds K_threshold), whether an event occurs can be determined based on the prediction accuracy set by the base station. The base station can transmit to the terminal information about specific beam combinations for which the prediction accuracy must be guaranteed (e.g., the match between the measured Top-X best beam and the predicted Top-X best beam).

[0227] For example, the information may indicate that the measured Top-1 best beam and the predicted Top-1 best beam should match. In other words, the predicted accuracy indicated based on the information may indicate the match of one beam (the Top-1 best beam).

[0228] For example, the information may indicate that the measured Top-2 best beams and the predicted Top-2 best beams should match. In other words, the predicted accuracy indicated based on the information may indicate the agreement between the two beams (the Top-2 best beams).

[0229] For example, the information may indicate that the measured Top-3 best beams and the predicted Top-3 best beams should be consistent. In other words, the predicted accuracy indicated based on the information may indicate the consistency of the three beams (Top-3 best beams).

[0230] It can be assumed that the base station sets K_threshold to 2, and the terminal compares the predicted Top-K best beams with the measured Top-K best beams and detects three mismatches (e.g., KM (3) > K_threshold (2)). In this case, whether an event based on this embodiment occurs can be determined as follows.

[0231] For example, if the predicted Top-2 best beams match the measured Top-2 best beams, the terminal may not judge it as a prediction error (it may judge that the conditions related to the event are not met).

[0232] For example, if at least one of the predicted Top-2 best beams does not match at least one of the measured Top-2 best beams, the terminal may determine that a prediction error has occurred (a condition related to the event may be determined to be satisfied). As a specific example, if a first predicted beam among the predicted Top-2 best beams does not match a first measured beam among the measured Top-2 best beams, the condition related to the event may be determined to be satisfied. As a specific example, if a second predicted beam among the predicted Top-2 best beams does not match a second measured beam among the measured Top-2 best beams, the condition related to the event may be determined to be satisfied. As a specific example, if the predicted Top-2 best beams do not match the measured Top-2 best beams, the condition related to the event may be determined to be satisfied.

[0233] The operation of option 3 above can also be utilized when comparing the actual measured best beam and the predicted best beam for N instances during temporal domain beam prediction. For example, whether an event of option 3 occurs can be determined based on a (set / defined) N_threshold.

[0234] Option 4)

[0235] Events can be defined based on confidence level and / or probability.

[0236] For example, a condition related to an event may be defined as being satisfied based on the confidence level or / and probability of the terminal AI / ML model for the predicted best beam (based on the output result of the UE-side AI / ML model) related to Set A being below a certain threshold.

[0237] An event may be defined based on a combination of one or more of the options in Proposal 3 above. For example, an event may be defined as occurring based on the conditions associated with Option 1 and Option 2 being met together.

[0238] In addition, for each of the above options, the terminal can report the performance monitoring result when an event occurs instantaneously in a single instance performing Set A actual measured beam measurement / reporting (which is shorter than the period for reporting Set A predicted beam). Considering the occurrence of temporary errors, the terminal can perform the performance monitoring result report based on a counter. Specifically, a counter (=I) related to the number of event occurrences can be defined. The terminal can report the performance monitoring result based on the occurrence of each of the above events I or more times (within a specific time window). This operation can ensure the reliability of the performance monitoring result report.

[0239] Additionally, with respect to the method of reporting the predicted beam associated with Set A and the actual measured beam associated with Set A together, as in Alt 4 of Proposal 2, a method of reporting the number of incorrect answers (the number of mismatched beams) rather than reporting the actual measured beam associated with Set A beams together may be considered. As a specific example, the terminal may report i) the predicted Top-K best beam associated with Set A, and ii) the number of predicted beams that are mismatched when comparing the actual measured Top-K best beam with the predicted Top-K best beam.

[0240] For example, in relation to reporting the number of incorrect answers, the number of incorrect answers itself may be reported based on ceil(log2(K)) bits.

[0241] For example, in relation to the reporting of the number of incorrect answers, whether each beam among the Top-K predicted beams is incorrect / mismatched may be reported based on the K-bitmap. As a specific example, if the bit value (the 3rd bit value) of the K-bitmap is 1, it may mean that the predicted beam and the measured beam according to the corresponding order (3) match. As a specific example, if the bit value (the 3rd bit value) of the K-bitmap is 0, it may mean that the predicted beam and the measured beam according to the corresponding order (3) do not match.

[0242] In one embodiment, the base station can perform performance monitoring of UE-sided AI / ML based on these terminal reports and determine terminal-side AI / ML model / functionality switching or fallback to conventional beam management.

[0243] In one embodiment, the operation of Alt 5 of Proposal 2 may be performed in combination with Proposal 3. For example, based on the satisfaction of at least one of the options of Proposal 3, the terminal may revert to the reporting operation of Alt 1. If at least one event of the options of Proposal 3 occurs, the terminal may revert to the operation according to conventional beam management.

[0244] Proposal 4

[0245] When an event described in Proposal 3 occurs, the terminal can report the terminal AI / ML performance monitoring results to the base station using the signaling method / medium below.

[0246] Option 1) dedicated SR-PUCCH

[0247] In one embodiment, an environment may be assumed in which the NW controls UE-side AI / ML model / functionality switching / refinement. The UE may report one of the following i) to iv) to the base station based on the 2-bit codepoint (e.g., 00, 01, 10, 11) of the SR-PUCCH.

[0248] i) Set A / B beam set change request

[0249] ii) model / functionality switching request

[0250] iii) model / functionality stop / hold request

[0251] iv) Fallback request (to conventional beam management)

[0252] In one embodiment, an environment may be assumed in which the UE independently performs switching / refinement of the UE-side AI / ML model / functionality. The UE may independently switch / stop the model / functionality or stop AI / ML-based beam prediction.

[0253] The terminal may report one of the following i) to iv) to the base station based on the 2-bit codepoint of the SR-PUCCH (e.g., 00, 01, 10, 11).

[0254] i) model / functionality switching report

[0255] ii) model / functionality stop report

[0256] iii) Hold request / report on prediction or model / functionality

[0257] iv) Report hold notification

[0258] The above "model / functionality stop report" may mean that the terminal will no longer perform prediction and will not perform reports (related to the prediction) due to beam prediction performance issues.

[0259] In the case of the above "hold request / report for prediction or model / functionality" or "report hold notification", it can be interpreted that the terminal reports to the base station that "prediction will not be performed for the time being." After a certain period of time (as agreed upon / agreed upon between the base station and the terminal), the terminal can resume prediction operations (after applying a new model or performing maintenance). In addition, the above "hold request / report for prediction or model / functionality" or "report hold notification" can also be interpreted that the terminal reports to the base station that "report will not be performed for the time being." The terminal and the base station can perform actions such as releasing the corresponding CSI reporting resources (e.g., PUCCH, PUSCH) for a certain period of time (as agreed upon / agreed upon between the base station and the terminal). During this period of time, the base station can flexibly utilize the corresponding time / frequency resources (e.g., allocate the corresponding time / frequency resources to other terminals). After the certain period of time, the terminal can resume beam prediction reporting again.

[0260] The terminal can report monitoring results only by transmitting the SR-PUCCH of option 1. Therefore, the base station may not allocate the UL grant to the terminal after receiving the SR-PUCCH.

[0261] Option 2) dedicated SR-PUCCH + PUSCH MAC CE (via subsequent UL grant)

[0262] The terminal can transmit a PUSCH based on the UL grant allocated via SR-PUCCH. The terminal can perform performance monitoring reporting using the MAC CE message associated with the PUSCH. Specifically, the MAC CE message can include performance monitoring results of options 1 to 4 of Proposal 1 (e.g., which event occurred and which threshold value was exceeded by the event).

[0263] For example, an environment in which the NW controls UE-side AI / ML model / functionality switching / refine, similar to the above option 1, may be assumed. The terminal may transmit the MAC CE message including information indicating one or more of the following i) to v) to the base station.

[0264] i) Set A / B beam set change request

[0265] ii) model / functionality switching / stop request

[0266] iii) fallback request (to conventional beam management)

[0267] iv) Preferred combination of Set A / B

[0268] v) Preferred model / functionality

[0269] For example, it may be assumed that the UE independently performs switching / refinement of the UE-side AI / ML model / functionality. (Similar to option 1 above), the UE may independently switch / stop the model / functionality or stop AI / ML-based beam prediction. The UE may transmit the MAC CE message containing information indicating one of the following i) to iv) to the base station.

[0270] i) model / functionality switching report

[0271] ii) model / functionality stop report

[0272] iii) Hold request / report on prediction or model / functionality

[0273] iv) Report hold notification

[0274] Option 3) UE-initiated CFRA

[0275] Similar to the above option 1, the SSB indices related to the following i) to vii) can be defined / set in advance by the base station to the terminal.

[0276] i) Set A / B beam set change request

[0277] ii) model / functionality switching / stop request

[0278] iii) fallback request (to conventional beam management)

[0279] iv) model / functionality switching report

[0280] v) model / functionality stop report

[0281] vi) Hold request / report on prediction or model / functionality

[0282] vii) Report hold notification

[0283] When a terminal transmits a PRACH based on a specific SSB index among the above SSB indices, a performance monitoring report content (e.g., one of i) to vii) defined between the base station and the terminal may be transmitted to the base station. A base station that receives a PRACH based on a specific SSB index among the above SSB indices may determine that a report (e.g., one of i) to vii) related to the specific SSB index has been performed, and may perform subsequent operations related thereto.

[0284] A terminal can report monitoring results solely through PRACH transmission. For example, the base station may not transmit an RAR to the terminal after receiving the corresponding PRACH (omitting RAR transmission). For example, the base station may transmit a RAR scheduling DCI and an RAR PDSCH. The RAR MAC CE of the RAR PDSCH may not include a UL grant.

[0285] Option 4) PRACH + Msg 3 PUSCH MAC CE (by UL grant of subsequent RAR MAC CE)

[0286] Similar to option 2, the UE can transmit a PUSCH based on the UL grant allocated via (CBRA / CFRA) PRACH transmission. The UE can perform performance monitoring reporting using the MAC CE message associated with the PUSCH. Specific embodiments of the MAC CE message configuration method may be identical to option 2.

[0287] The effects of the above suggestions 3 and 4

[0288] The terminal can report the performance monitoring results of the terminal AI / ML model / functionality of Proposal 4 to the base station only when the event of Proposal 3 occurs. This can reduce resource overhead. Based on the AI / ML monitoring results of the terminal, the base station can decide to stop / switch the model / functionality or fallback to the legacy BM (if the base station manages the terminal's AI / ML model / functionality). In particular, if there is a problem with beam prediction performance in the case where the terminal manages its own AI / ML model / functionality as in Option 1 of Proposal 4, the terminal can temporarily suspend prediction and reorganize. While the terminal's prediction is suspended, reporting resources can be released and allocated to other terminals, which can increase the flexibility of resource utilization.

[0289] The performance monitoring reporting method of the above proposal 4 can also be used for performance monitoring reporting using periodic / static resources rather than event-triggered operations.

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

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

[0292] 1) The terminal (base station) receives (transmits) settings related to event-triggered AI / ML model / functionality performance monitoring reports. These settings may include information related to at least one of Proposals 1 to 4.

[0293] 2) The terminal (base station) receives (transmits) a message scheduling the transmission of the performance monitoring report. The transmission of the performance monitoring report may be performed based on a UE-triggered operation. In this case, this step (step 2)) may be omitted.

[0294] 3) The terminal (base station) transmits (receives) the above performance monitoring report.

[0295] The transmission of the above report may be performed based on the occurrence of the event of Proposal 3. Specifically, the report may be transmitted based on the fulfillment of a condition related to the event of Proposal 3. The report may be transmitted (received) based on the embodiment of Proposal 4.

[0296] The above terminal / base station operations are only an example, and each operation (or step) is not necessarily required, and depending on the terminal / base station implementation method, the terminal's AI / ML model / functionality performance monitoring reporting operation according to the above-described embodiments may be omitted or added.

[0297] 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) can be processed by the device of FIG. 7 (e.g., the processor (110, 210) of FIG. 7).

[0298] 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) may be stored in a memory (e.g., 140, 240 of FIG. 7) in the form of commands / programs (e.g., instructions, executable codes) for driving at least one processor (e.g., 110, 210 of FIG. 7).

[0299] The embodiments described below are specifically described with reference to FIGS. 5 and 6 in terms of the operation of the terminal and base station. The methods described below are distinguished for convenience of explanation, and it is understood that some components of one method may be substituted for or combined with some components of another method.

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

[0301] Referring to FIG. 5, a method according to one embodiment of the present specification includes a step of receiving setting information (S510) and a step of transmitting a report based on the setting information (S520).

[0302] In S510, the terminal receives configuration information from the base station.

[0303] For example, the configuration information may be received based on higher layer signaling (e.g., RRC signaling).

[0304] For example, the configuration information may include configuration(s) related to performance monitoring. Specifically, the configuration information may include information based on at least one of Proposals 1 to 4.

[0305] As a specific example, the above configuration information may include a CSI reporting configuration (CSI-reportConfig) based on Proposal 1.

[0306] As a specific example, the configuration information may include a report quantity based on Proposal 2. The report quantity may be related to information reported by the terminal. The report quantity may be based on at least one of Alt 1 to Alt 5 of Proposal 2.

[0307] As a specific example, the configuration information may include information related to an event based on Proposal 3. For example, the information related to the event may include i) information indicating at least one of Option 1 to Option 4 and / or ii) K_threshold.

[0308] As a specific example, the configuration information may include a configuration based on Proposal 4. For example, the configuration may include i) information indicating one of option 1 to option 4 and / or ii) information about SSB indices associated with option 3 / 4.

[0309] In S520, the terminal transmits a report to the base station based on the above setting information.

[0310] In one embodiment, the report may be transmitted based on an event related to performance monitoring of the model. This embodiment may be based on Proposal 3 and / or Proposal 4.

[0311] The following describes in detail the embodiments of Proposals 3 and 4.

[0312] The above event may include an event based on at least one of Option 1 to Option 4 of Proposal 3, as described in detail below.

[0313] In one embodiment, the event may include an event defined based on the difference between i) measured Reference Signal Received Power (RSRP) and ii) predicted RSRP. This embodiment may be based on Option 1 of Proposal 3.

[0314] In one embodiment, the event may include an event defined based on a mismatch between i) a first RS resource index and ii) a second RS resource index. The first RS resource index may be associated with the largest measured Reference Signal Received Power (RSRP). The second RS resource index may be associated with the largest predicted RSRP. This embodiment may be based on Option 2 of Proposal 3.

[0315] In one embodiment, the event may include an event defined based on prediction accuracy.

[0316] The above prediction accuracy may be determined based on a comparison of i) at least one first RS resource index determined in order of highest measured Reference Signal Received Power (RSRP) and ii) at least one second RS resource index determined in order of highest predicted RSRP. The present embodiment may be based on Option 3 of Proposal 3. The above prediction accuracy may be determined by comparing prediction results (e.g., predicted Top-K best beams) with measurement results (e.g., measured Top-K best beams).

[0317] For example, the prediction accuracy may be based on a comparison result between the prediction results and the measurement results. The comparison result may be based on i) the number of beams among the predicted Top-K best beams that match the measured Top-K best beams and / or ii) the number of beams among the predicted Top-K best beams that do not match the measured Top-K best beams. In other words, the comparison result may include i) the number of second RS resource indices that match at least one first RS resource index among the at least one second RS resource indices and / or i) the number of second RS resource indices that do not match at least one first RS resource index among the at least one second RS resource indices.

[0318] In one embodiment, the event may include an event defined based on the confidence level or probability of the RS having the highest predicted Reference Signal Received Power (RSRP). This embodiment may be based on Option 4 of Proposal 3.

[0319] The above report can be transmitted based on one of Option 1 to Option 4 of Proposal 4, which is described in detail below.

[0320] In one embodiment, the report may be transmitted based on a Physical Uplink Control Channel (PUCCH) associated with a Scheduling Request (SR). This embodiment may be based on Option 1 of Proposal 4.

[0321] For example, based on the codepoint associated with the SR, i) beam set change, ii) model / functionality switching, iii) model / functionality stop, or iv) fallback request may be indicated.

[0322] In one embodiment, the report may be transmitted based on a Medium Access Control Control Element (MAC CE). The MAC CE may include i) information indicating the type of the event and / or ii) information indicating the extent to which a reference value associated with the event deviates from a threshold value. This embodiment may be based on Option 2 / Option 4 of Proposal 4.

[0323] For example, the MAC CE may be associated with a Physical Uplink Shared Channel (PUSCH) scheduled by a UL grant. The UL grant may be based on i) a RAR UL grant (e.g., Option 2) or ii) a UL grant other than the RAR UL grant (e.g., Option 4).

[0324] In one embodiment, the report may be transmitted based on a Physical Random Access Channel (PRACH). Information related to the report may be determined based on a Synchronization Signal Block (SSB) index associated with the PRACH. This embodiment may be based on Option 3 of Proposal 4.

[0325] In one embodiment, the report may include information about at least one performance metric associated with the event. The at least one performance metric may be based on at least one of Option 1 to Option 4 of Proposal 3.

[0326] For example, the at least one performance indicator may be based on a difference between i) measured Reference Signal Received Power (RSRP) and ii) predicted RSRP.

[0327] For example, the at least one performance metric may be based on i) a first RS resource index associated with the largest measured Reference Signal Received Power (RSRP) and ii) a second RS resource index associated with the largest predicted RSRP.

[0328] For example, the at least one performance indicator may be based on prediction accuracy.

[0329] For example, the at least one performance indicator may be based on a confidence level or probability of the RS having the largest predicted Reference Signal Received Power (RSRP).

[0330] If a temporary error occurs, a report may not need to be sent. In one embodiment, the report may be sent based on a counter (e.g., a max counter) related to the number of occurrences of the event. For example, the report may be sent based on the number of occurrences of the event (within a defined window / time interval) being greater than or equal to a value based on the counter (e.g., I).

[0331] The operations based on S510 to S520 described above can be implemented by the device of FIG. 7. For example, referring to FIG. 7, the terminal (200) can control one or more transceivers (230) and / or one or more memories (240) to perform the operations based on S510 to S520.

[0332] The embodiments described below are specifically described in terms of base station operation.

[0333] S610 to S620 described below correspond to S510 to S520 described in FIG. 5. Considering the above correspondence, redundant descriptions are omitted. That is, the specific description of the base station operation described below may be replaced with the description / example of FIG. 5 corresponding to the corresponding operation.

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

[0335] Referring to FIG. 6, a method according to another embodiment of the present specification includes a setting information transmission step (S610) and a report reception step (S620) based on the setting information.

[0336] In S610, the base station transmits configuration information to the terminal.

[0337] In S620, the base station receives a report from the terminal based on the above setting information.

[0338] In one embodiment, the report may be received based on an event related to performance monitoring of the model.

[0339] The operations based on S610 to S620 described above can be implemented by the device of FIG. 7. For example, referring to FIG. 7, the base station (100) can control one or more transceivers (130) and / or one or more memories (140) to perform the operations based on S610 to S620.

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

[0341] Hereinafter, a device to which an embodiment of the present specification can be applied (a device that implements a method / operation according to an embodiment of the present specification) is described with reference to FIG. 7.

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

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

[0344] The processor (110) performs baseband-related signal processing and may include a higher layer processing unit (111) and a physical layer processing unit (115). The higher layer processing unit (111) may process operations of a MAC layer, an RRC layer, or higher layers. The physical layer processing unit (115) may process operations of a PHY layer. For example, when 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, when the first device (100) is a first terminal device in terminal-to-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).

[0345] The antenna unit (120) may include one or more physical antennas, and when 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, an operating system, applications, etc. related to the operation of the first device (100), and may also include components such as a buffer.

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

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

[0348] The processor (210) performs baseband-related signal processing and may include a higher layer processing unit (211) and a physical layer processing unit (215). The higher layer processing unit (211) may process operations of a MAC layer, an RRC layer, or higher layers. The physical layer processing unit (215) may process operations of a PHY layer. For example, when 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, when the second device (200) is a second terminal device in terminal-to-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).

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

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

[0351] In the operation of the first device (100) and the second device (200), the same explanations given for the base station and the terminal (or the first terminal and the second terminal in the terminal-to-terminal communication) in the examples of the present disclosure may be applied, and redundant explanations are omitted.

[0352] 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 LPWAN (Low Power Wide Area Network) technology and may be implemented in standards such as LTE Cat NB1 and / or LTE Cat NB2, and is not limited to the above-described names.

[0353] 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 called by various names such as eMTC (enhanced Machine Type Communication). For example, LTE-M technology may be implemented by 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 above-described names.

[0354] Additionally or alternatively, the wireless communication technology implemented in the device of the present disclosure may include at least one of ZigBee, Bluetooth, and Low Power Wide Area Network (LPWAN), which take low-power communication into account, and is not limited to the above-described names. 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 called by various names.

Claims

1. In the method, Step of receiving setup information; and A step of transmitting a report based on the above setting information; including: A method characterized in that the above report is transmitted based on an event related to performance monitoring of the model.

2. In paragraph 1, A method characterized in that the above event includes an event defined based on a difference between i) measured Reference Signal Received Power (RSRP) and ii) predicted RSRP.

3. In paragraph 1, The above event includes an event defined based on a mismatch of i) a first RS resource index and ii) a second RS resource index, The above first RS resource index is related to the largest measured Reference Signal Received Power (RSRP), A method characterized in that the second RS resource index is associated with the largest predicted RSRP.

4. In paragraph 1, The above events include events defined based on prediction accuracy, A method characterized in that the above prediction accuracy is determined based on a comparison of i) at least one first RS resource index determined in order of highest measured Reference Signal Received Power (RSRP) and ii) at least one second RS resource index determined in order of highest predicted RSRP.

5. In paragraph 1, A method characterized in that the above event includes an event defined based on a confidence level or probability of an RS having the largest predicted Reference Signal Received Power (RSRP).

6. In paragraph 1, A method characterized in that the above report is transmitted based on a physical uplink control channel (PUCCH) related to a scheduling request (SR).

7. In paragraph 6, A method characterized in that i) beam set change, ii) model / functionality switching, iii) model / functionality stop, or iv) fallback request is indicated based on a code point associated with the above SR.

8. In paragraph 1, The above report is transmitted based on MAC CE (Medium Access Control Control Element), A method characterized in that the MAC CE includes i) information indicating the type of the event and / or ii) information indicating the extent to which a reference value related to the event deviates from a threshold value.

9. In paragraph 1, The above report is transmitted based on the Physical Random Access Channel (PRACH), A method characterized in that information related to the report is determined based on a synchronization signal block index (Synchronization Signal Block, SSB, index) related to the PRACH.

10. In paragraph 8, The above MAC CE is related to the physical uplink shared channel (PUSCH) scheduled by the UL grant, A method characterized in that the above UL grant is i) a RAR UL grant or ii) a UL grant other than the RAR UL grant.

11. In paragraph 1, A method characterized in that the report includes information on at least one performance metric related to the event.

12. In paragraph 1, A method characterized in that the above report is transmitted based on a counter related to the number of occurrences of the above event.

13. At the terminal, One or more transmitters and receivers; one or more processors; and One or more memories connected to said one or more processors and storing instructions, A terminal characterized in that the instructions, based on being executed by the one or more processors, cause the terminal to perform all steps of the method according to any one of claims 1 to 12.

14. In a device comprising one or more memories and one or more processors connected to the one or more memories, A device characterized in that said one or more memories store instructions that cause said device to perform all steps of a method according to any one of claims 1 to 12, based on being executed by said one or more processors.

15. In a non-transitory computer-readable storage medium storing instructions, A non-transitory computer-readable storage medium characterized in that the instructions executable by one or more processors cause a terminal to perform all steps of a method according to any one of claims 1 to 12.

16. In the method, Step of transmitting setup information; and A step of receiving a report based on the above setting information; including: A method characterized in that the above report is received based on an event related to performance monitoring of the model.

17. At the base station, One or more transmitters and receivers; one or more processors; and One or more memories connected to said one or more processors and storing instructions, A base station characterized in that the instructions, based on being executed by the one or more processors, cause the base station to perform all steps of the method according to claim 16.

Citation Information

Patent Citations

  • User equipment report of machine learning model performance

    WO2023192409A1

  • Machine learning model performance monitoring reporting

    WO2023206249A1

  • Methods and apparatus of monitoring artificial intelligence model in radio access network

    WO2024000559A1