WO2024157643A1

WO2024157643A1 - Terminal, base station, and communication method

Info

Publication number: WO2024157643A1
Application number: PCT/JP2023/044891
Authority: WO
Inventors: 智寛井上; 知也布目; 秀俊鈴木; 哲矢山本
Original assignee: パナソニックインテレクチュアルプロパティコーポレーションオブアメリカ
Priority date: 2023-01-23
Filing date: 2023-12-14
Publication date: 2024-08-02

Abstract

This terminal is equipped with: a control circuit that determines report information on the basis of measured values of the reception quality of each of a plurality of blocks for which measurement resources in a frequency region were divided; and a transmission circuit that transmits the report information.

Description

Terminal, base station, and communication method

This disclosure relates to a terminal, a base station, and a communication method.

The 3rd Generation Partnership Project (3GPP) has completed the formulation of the physical layer specifications for Release 17 NR (New Radio access technology) as a functional extension of 5th generation mobile communication systems (5G). NR will support enhanced mobile broadband (eMBB) to meet the requirements of high speed and large capacity, as well as functions that realize ultra-reliable and low latency communication (URLLC) (see, for example, non-patent literature 1-6).

However, there is room for improvement in how to report interference between devices.

Non-limiting examples of the present disclosure contribute to providing a terminal, a base station, and a communication method that can appropriately report interference between terminals.

A terminal according to one embodiment of the present disclosure includes a control circuit that determines report information based on measurement values of reception quality for each of a number of blocks into which a measurement resource in the frequency domain is divided, and a transmission circuit that transmits the report information.

These comprehensive or specific aspects may be realized as a system, device, method, integrated circuit, computer program, or recording medium, or as any combination of a system, device, method, integrated circuit, computer program, and recording medium.

According to one embodiment of the present disclosure, interference between terminals can be appropriately reported.

Further advantages and benefits of an embodiment of the present disclosure will become apparent from the specification and drawings. Such advantages and/or benefits may be provided by some of the embodiments and features described in the specification and drawings, respectively, but not necessarily all of them need be provided to obtain one or more identical features.

Diagram showing an example of subband non-overlapping full duplex (SBFD) Diagram showing an example of Dynamic/flexible time division duplex (TDD) Diagram showing an example of layer 3 (L3) based cross-link interference - Received Signal Strength Indicator (CLI-RSSI) measurement and reporting Diagram showing an example of an end-to-end CLI in an SBFD scenario Diagram showing an example of end-to-end CLI in a dynamic/flexible TDD scenario A diagram showing an example of the Report field for Layer 1 (L1)-Reference Signal Received Power (RSRP) Diagram showing an example of CLI-RSSI measurement A block diagram showing an example of the configuration of a portion of a base station. Block diagram showing a partial configuration example of a terminal Block diagram showing a configuration example of a base station Block diagram showing an example of a terminal configuration A sequence diagram showing an example of the operation of a base station and a terminal. Diagram showing an example of a CLI-RSSI report based on a Channel State Information (CSI) report A diagram showing an example of how to configure a report field A diagram showing an example of how to configure a report field A diagram showing an example of how to configure a report field A diagram showing an example of how to configure a report field Diagram of an example architecture for a 3GPP NR system Schematic diagram showing functional separation between NG-RAN (Next Generation - Radio Access Network) and 5GC (5th Generation Core) Sequence diagram of Radio Resource Control (RRC) connection setup/reconfiguration procedure Schematic diagram showing usage scenarios for enhanced Mobile BroadBand (eMBB), massive Machine Type Communications (mMTC), and Ultra Reliable and Low Latency Communications (URLLC). Block diagram illustrating an example 5G system architecture for a non-roaming scenario

The following describes in detail the embodiments of this disclosure with reference to the drawings.

[Subband non-overlapping full duplex (SBFD) and dynamic/flexible time division duplex (TDD)]
Subband non-overlapping full duplex (SBFD) and Dynamic/flexible TDD are discussed in Release 18. Figure 1 shows an example of SBFD, and Figure 2 shows an example of Dynamic/flexible TDD.

Figure 1(a) shows an example of the operation of a base station (also called gNB) and terminals (UE: User Equipment) (e.g., UE#1 and UE#2) in the same cell in an SBFD scenario. In the SBFD scenario, the base station performs SBFD operation and the terminals perform half-duplex operation.

Figure 1(b) shows an example of subband allocation in SBFD. In Figure 1(b), the vertical axis represents frequency, and the horizontal axis represents time. Also, in Figure 1(b), "UL" represents uplink transmission, and "DL" represents downlink transmission. Also, resources that are not used in each device (e.g., gNB, UE#1, and UE#2) are shown with dotted lines.

As shown in Figure 1(b), in SBFD, a frequency resource (frequency band) is divided into multiple subbands (also called bands, RB sets, subbands, or sub-BWPs (Bandwidth parts)), and transmission in different directions is supported on a subband-by-subband basis. As shown in Figure 1(b), a base station can transmit and receive simultaneously on the uplink and downlink (e.g., SBFD operation), and a terminal can transmit and receive on either the uplink or downlink in a given time resource (e.g., half-duplex operation). For example, in the example of Figure 1(b), in the same time resource (e.g., slot or symbol), UE#1 communicates with the base station on the uplink, and UE#2 communicates with the base station on the downlink.

Figure 2(a) shows an example of the operation of different base stations (e.g., gNB1 and gNB2) and terminals (e.g., UE#1 and UE#2) in a dynamic/flexible TDD scenario. In the dynamic/flexible TDD scenario, the base stations and terminals perform half-duplex operation, and the transmission directions may be different for different base stations.

Figure 2(b) shows an example of resource allocation in dynamic/flexible TDD. In the example of Figure 2(b), in the same time resource (e.g., slot or symbol at the same time), UE#1 performs DL reception from gNB1, and UE#2 performs UL transmission to gNB2.

[Regarding interference]
In the case of the SBFD scenario or the Dynamic/flexible TDD scenario, various interferences may occur. For example, self-interference at the base station or cross-link interference (CLI) between terminals (UE-to-UE) may occur. Self-interference at the base station and CLI between terminals greatly deteriorate reception characteristics, so countermeasures are required. One of the countermeasures is, for example, a method of avoiding allocation of terminals with strong interference by scheduling at the base station. Here, since the base station cannot directly measure the CLI between terminals, a method is expected in which the terminal measures the CLI between terminals and reports it to the base station.

One of the methods for measuring CLI between terminals in existing standards is SRS-RSRP (SRS: Sounding Reference Signal, RSRP: Reference Signal Received Power)/CLI-RSSI (RSSI: Received Signal Strength Indicator). SRS-RSRP/CLI-RSSI is a Layer 3 (L3) based measurement and reporting of CLI between terminals, and will be supported in Release 16.

SRS-RSRP is a measurement of the received power of SRS transmitted by a terminal from other terminals.

CLI-RSSI is a measurement of the linear average of the total received power on the resources (e.g., also called "measurement resources") that the terminal is configured to measure. The measurement resource may also be called, for example, the measurement time resource or the measurement bandwidth (or measurement frequency bandwidth).

Figure 3 shows an example of Layer 3-based CLI-RSSI. The terminal measuring Layer 3-based CLI-RSSI (UE#1 in Figure 3) measures the total received power of the CLI-RSSI resource (or measurement resource) specified by the base station, and reports the CLI-RSSI based on the measured total received power. For example, one terminal (UE#2 in Figure 3) transmits a UL signal, and the other terminal (UE#1 in Figure 3) measures the CLI-RSSI and reports it to the base station (gNB1 in Figure 3). Here, "Victim UE" refers to the UE that receives interference, and "Aggressor UE" refers to the terminal that causes interference.

In an SBFD scenario, a base station can transmit and receive simultaneously on the uplink and downlink, so CLI between terminals can occur. Figure 4 shows an example of CLI between terminals in an SBFD scenario. As shown in Figure 4(a), CLI between terminals can occur when different terminals (e.g., UE#1 and UE#2) communicate with a base station in different directions. In the example of Figure 4(a), UE#1 communicates with a gNB in downlink (DL) communication, and UE#2 communicates with a gNB in the same time resource (e.g., symbol or slot). In this case, CLI from UE#2 to UE#1 can occur between UE#1 and UE#2.

For example, as shown in FIG. 4(a), when DL and UL are assigned to adjacent subbands (e.g., subband#0 and subband#1, or subband#2 and subband#1), the reception characteristics of DL may be degraded due to non-uniform interference leakage from UL (e.g., non-uniform CLI leakage). FIG. 4(b) shows an example of non-uniform CLI leakage in subbands where DL and UL are adjacent (e.g., subband#0 and subband#1). Non-uniform CLI leakage may be classified into three parts of in-band emission, for example, "general", "carrier leakage", and "IQ image". In this way, CLI (CLI leakage) between terminals may be non-uniformly distributed in the frequency domain (hereinafter also referred to as "CLI distribution").

Similarly, SRS-RSRP or CLI-RSSI is also effective in a dynamic/flexible TDD scenario. Figure 5 shows an example of CLI between terminals in a dynamic/flexible TDD scenario. As shown in Figure 5(a), CLI between terminals can occur when different base stations (e.g., gNB1 and gNB2) communicate with terminals (e.g., UE#1 and UE#2) connected to each base station in different directions. In the example of Figure 5(a), UE#1 performs downlink (DL) communication with gNB1 and UE#2 performs uplink (UL) communication with gNB2 in the same time resource (e.g., symbol or slot). In this case, CLI from UE#2 to UE#1 can occur between UE#1 and UE#2. For example, as shown in Figure 5(a), when different directions (DL and UL) are assigned to UE#1 and UE#2 in the same time resource, the reception characteristics of DL can be degraded due to uneven interference leakage from UL. Figure 5(b) shows an example of non-uniform CLI leakage in a dynamic/flexible TDD scenario.

For example, the CLI between terminals depends on the transmission power of the interfering terminal, or the positional relationship between the interfered terminal and the interfering terminal. Here, it is difficult for the base station to grasp the detailed location of the terminal, and therefore it is difficult for the base station alone to estimate the CLI between terminals. Therefore, SRS-RSRP or CLI-RSSI are measurement values of interference between terminals measured by the terminal, and are therefore effective for SBFD scenarios and Dynamic/flexible TDD scenarios.

When terminals measure the CLI between terminals and report it to a base station, the reported CLI measurement value (or observed value) is useful for scheduling in the base station. For example, the base station can perform scheduling that does not assign terminals with large reported CLI measurement values (e.g., terminals with large interference) to the same time. Also, for example, the base station can perform scheduling that does not assign terminals with small reported CLI measurement values (e.g., terminals with small interference) to the same time.

Here, methods for reporting uneven CLI distribution among terminals have not been fully considered. In one non-limiting example of the present disclosure, a method for reporting uneven CLI distribution among terminals is described.

[About CSI reports and report fields]
An example of the "Report field" constituting the measurement value reported by the terminal will be described below.

For example, Release 16 supports Layer 3-based terminal-to-terminal CLI measurement and reporting, but Layer 1 (L1) or Layer 2 (L2)-based terminal-to-terminal CLI measurement and reporting is also under consideration. Here, an existing Layer 1 (L1)-based reporting method is the Channel State Information (CSI) report.

In a CSI report, for example, a terminal measures values such as channel quality information (e.g., CQI: Channel Quality Information), transmission rank, and L1-RSRP using at least one of the CSI-Reference Signal (CSI-RS) and Synchronization Signal Block (SSB) transmitted from the base station to the terminal, and reports a report including the measured values to the base station.

In a CSI report, the base station configures the time domain behavior of the report (e.g., reporting periodically, quasi-periodically, or aperiodically), the report configuration that sets the values to be reported, and the resource configuration that includes information on the resources to be measured (e.g., measurement resources) for the terminal that is making the measurements.

The terminal, for example, quantizes the measurement value and configures (or stores or places) it in the Report field. Each report number that identifies multiple reports to be reported is linked to a Report field. For example, an Uplink Control Information (UCI) bit string corresponds to multiple report numbers reported by the terminal.

Figure 6 shows an example of the configuration of the Report field of L1-RSRP. The Report field may include a "resource ID (e.g., Resource (CSI-RS or SSB) ID)" that identifies the resource to be measured, a "quantized measurement value (e.g., quantized RSRP or quantized differential RSRP)" that corresponds to the resource to be measured, and a "Capability Index" that identifies the capability corresponding to the resource to be measured. In the example shown in Figure 6, the number of measurements (or resources) reported in each Report field is up to four, and they may be arranged in descending order in the Report field. In addition, in the quantized measurement value, the quantized differential RSRP indicates a quantized value of the difference between the RSRP of each resource and the maximum RSRP. For example, 7 bits may be assigned to the quantized RSRP and 4 bits to the quantized differential RSRP as the quantization bit number of the L1-RSRP measurement value.

[CLI-RSSI measurement and reporting method considering non-uniform CLI leakage distribution]
In the following, we will explain CLI-RSSI measurement and reporting considering non-uniform CLI leakage distribution using the SBFD scenario as an example. Note that the contents explained below can be similarly applied to dynamic/flexible TDD scenarios.

FIG. 7 illustrates an example of measuring and reporting CLI-RSSI according to one non-limiting embodiment of the present disclosure.

In one non-limiting embodiment of the present disclosure, the terminal performs CLI-RSSI measurement and reporting using multiple measurement blocks obtained by dividing a measurement resource in the frequency domain (e.g., a CLI measurement band, also referred to as measurement bandwidth).

For example, FIG. 7(a) shows an example of existing CLI-RSSI measurement and reporting without using measurement blocks (e.g., CLI reporting and measurement supported in Release 16), FIG. 7(b) shows an example of CLI-RSSI measurement and reporting when using measurement blocks according to one non-limiting embodiment of the present disclosure, and FIG. 7(c) shows an example of non-uniform CLI spillover (or CLI distribution) and its relationship to measurement blocks.

In the existing CLI-RSSI measurement and reporting as shown in Figure 7(a), one CLI-RSSI is measured in the CLI measurement band in the frequency direction (e.g., a subband area) and reported to the base station. Therefore, in the CLI-RSSI measurement and reporting as shown in Figure 7(a), it is difficult to report to the base station, for example, the detailed distribution of non-uniform CLI leakage in the CLI measurement band as shown in Figure 7(c).

In contrast, as shown in Figures 7(b) and 7(c), in CLI-RSSI measurement and reporting using multiple measurement blocks, the base station, for example, sets multiple measurement blocks in the terminal, which are obtained by dividing the CLI measurement band into multiple blocks in the frequency direction. The terminal, for example, measures the CLI-RSSI for each measurement block. Then, the terminal, for example, determines a CLI-RSSI report based on the CLI-RSSI for each measurement block, and reports it to the base station.

This enables CLI measurement and reporting of bands corresponding to each measurement block within the CLI measurement band. For example, in FIG. 7(c), a CLI-RSSI relating to general in-band emission can be reported in one measurement block, and a CLI-RSSI relating to carrier leakage or IQ image can be reported in another measurement block. Thus, the terminal can report a detailed distribution of non-uniform CLI leakage to the base station. The base station can perform scheduling, such as modulation and coding scheme (MCS) or resource allocation (e.g., DL allocation), depending on the distribution of non-uniform CLI leakage.

An example of the Report field settings for the UCI bit string generation function in a CLI-RSSI report using a measurement block will be described later.

[Communication System Overview]
A communication system according to an embodiment of the present disclosure may include, for example, a base station 100 (e.g., gNB) shown in Fig. 8 and Fig. 10, and a terminal 200 (e.g., UE) shown in Fig. 9 and Fig. 11. A plurality of base stations 100 and a plurality of terminals 200 may exist in the communication system.

FIG. 8 is a block diagram showing an example configuration of a portion of a base station 100 according to one embodiment of the present disclosure. In the base station 100 shown in FIG. 8, a receiving unit (e.g., corresponding to a receiving circuit) receives report information (e.g., corresponding to report information) based on a CLI-RSSI value (e.g., corresponding to a measurement value of reception quality) for each of a plurality of measurement blocks (e.g., corresponding to blocks) into which a measurement resource in the frequency domain is divided. A control unit (e.g., corresponding to a control circuit) estimates a CLI-RSSI value for each of the plurality of measurement blocks based on the received report information.

FIG. 9 is a block diagram showing an example configuration of a portion of a terminal 200 according to one aspect of the present disclosure. In the terminal 200 shown in FIG. 9, a control unit (e.g., corresponding to a control circuit) determines report information (e.g., corresponding to report information) based on CLI-RSSI values (e.g., corresponding to measured values of reception quality) for each of a plurality of measurement blocks obtained by dividing a measurement resource in the frequency domain. A transmission unit (e.g., corresponding to a transmission circuit) transmits the report information.

[Base station configuration]
Fig. 10 is a block diagram showing a configuration example of a base station 100 according to an embodiment of the present disclosure. In Fig. 10, the base station 100 includes a receiving unit 101, a demodulating/decoding unit 102, a CLI distribution estimating unit 103, a scheduling unit 104, a control information holding unit 105, a data/control information generating unit 106, an encoding/modulating unit 107, and a transmitting unit 108.

Note that, for example, at least one of the demodulation/decoding unit 102, the CLI distribution estimation unit 103, the scheduling unit 104, the control information storage unit 105, the data/control information generation unit 106, and the encoding/modulation unit 107 may be included in the control unit shown in FIG. 8, and the receiving unit 101 may be included in the receiving unit shown in FIG. 8.

The receiving unit 101 performs reception processing, such as down-conversion or A/D conversion, on a received signal received via an antenna, and outputs the received signal after reception processing to the demodulation and decoding unit 102.

The demodulation and decoding unit 102, for example, demodulates and decodes the received signal input from the receiving unit 101, and outputs the decoded result to the scheduling unit 104. In addition, for example, when the decoded result includes CLI-RSSI report information (also called a CLI-RSSI report), the demodulation and decoding unit 102 outputs the report information to the CLI distribution estimation unit 103.

The CLI distribution estimation unit 103 estimates the CLI distribution in the frequency domain (e.g., the CLI measurement band) based on, for example, the CLI-RSSI report information input from the demodulation and decoding unit 102 and the control information input from the control information storage unit 105. The CLI distribution estimation unit 103 outputs information on the estimated CLI distribution to the scheduling unit 104.

The scheduling unit 104 may, for example, perform scheduling for the terminals 200. The scheduling unit 104 schedules transmission and reception for each terminal 200 based on at least one of the decoding results input from the demodulation and decoding unit 102, the information on the CLI distribution input from the CLI distribution estimation unit 103, and the control information input from the control information storage unit 105, and instructs the data and control information generation unit 106 to generate at least one of data and control information.

The control information holding unit 105 holds, for example, control information set in each terminal 200. The control information may include, for example, information such as the configuration of CLI-RSSI resources (for example, measurement resources) (for example, information on CLI-RSSI resources allocated to the terminal 200), the configuration of a CLI-RSSI report, or past measurement values of CLI-RSSI. The control information holding unit 105 may output the held information to each component of the base station 100 (for example, the CLI distribution estimation unit 103 and the scheduling unit 104) as necessary.

The data and control information generating unit 106 generates at least one of data and control information, for example, according to instructions from the scheduling unit 104, and outputs a signal including the generated data or control information to the coding and modulation unit 107. Note that the generated data and control information may include at least one of upper layer signaling information and downlink control information, for example.

The encoding and modulation unit 107, for example, encodes and modulates the signal input from the data and control information generation unit 106, and outputs the modulated signal to the transmission unit 108.

The transmitting unit 108 performs transmission processing such as D/A conversion, up-conversion, or amplification on the signal input from the encoding/modulation unit 107, and transmits the radio signal obtained by the transmission processing from the antenna to the terminal 200.

[Device configuration]
Fig. 11 is a block diagram showing a configuration example of a terminal 200 according to an embodiment of the present disclosure. In Fig. 11, the terminal 200 includes a receiving unit 201, a demodulating and decoding unit 202, a CLI measuring unit 203, a transmission control unit 204, a control information holding unit 205, a data and control information generating unit 206, an encoding and modulating unit 207, and a transmitting unit 208.

Note that, for example, at least one of the demodulation/decoding unit 202, CLI measurement unit 203, transmission control unit 204, control information storage unit 205, data/control information generation unit 206, and encoding/modulation unit 207 may be included in the control unit shown in FIG. 9, and the transmission unit 208 may be included in the transmission unit shown in FIG. 9.

The receiving unit 201 performs reception processing, such as down-conversion or A/D conversion, on a received signal received via an antenna, and outputs the received signal after reception processing to the demodulation and decoding unit 202.

The demodulation/decoding unit 202, for example, demodulates and decodes the received signal input from the receiving unit 201, and outputs the decoded result to the transmission control unit 204. The decoded result may include, for example, upper layer signaling information and downlink control information. In addition, when the decoded result includes information on the CLI-RSSI report (for example, information on the resource configuration or report configuration of the CLI-RSSI to be measured), the demodulation/decoding unit 202 outputs the decoded result to the CLI measurement unit 203.

The CLI measurement unit 203 measures the CLI-RSSI based on control information (e.g., information on the resource configuration or report configuration of the CLI-RSSI report) input from the control information storage unit 205 and information on the CLI-RSSI resource (measurement resource) input from the demodulation and decoding unit 202. For example, the CLI measurement unit 203 may measure the CLI-RSSI for each measurement block. The CLI measurement unit 203 outputs, for example, a quantized measurement value to the transmission control unit 204.

The transmission control unit 204 outputs signaling information (e.g., information on the resource configuration or report configuration of the CLI-RSSI report) included in the decoding result input from the demodulation and decoding unit 202 to the control information holding unit 205. Furthermore, the transmission control unit 204 may instruct the data and control information generating unit 206 to generate at least one of data and control information, for example, based on the control information (e.g., information on the resource configuration or report configuration of the CLI-RSSI report) input from the control information holding unit 205 or the decoding result input from the demodulation and decoding unit 202 (e.g., downlink control information). Furthermore, the transmission control unit 204 outputs the measured value of CLI-RSSI to the data and control information generating unit 206 based on the information input from the CLI measurement unit 203.

The control information holding unit 205 holds, for example, control information (for example, information related to the resource configuration or report configuration of the CLI-RSSI report) input from the transmission control unit 204, and outputs the held information to each component (for example, the CLI measurement unit 203 and the transmission control unit 204) as necessary.

The data and control information generating unit 206 generates data or control information, for example, according to instructions from the transmission control unit 204. For example, the data and control information generating unit 206 may generate a CLI-RSSI report based on the measured value of CLI-RSSI (an example will be described later). The data and control information generating unit 206 outputs a signal including the generated data or control information to the encoding and modulation unit 207.

The encoding and modulation unit 207, for example, encodes and modulates the signal input from the data and control information generation unit 206, and outputs the modulated transmission signal to the transmission unit 208.

The transmitting unit 208 performs transmission processing such as D/A conversion, up-conversion, or amplification on the signal input from the encoding/modulation unit 207, and transmits the radio signal obtained by the transmission processing from the antenna to the base station 100.

[Operations of base station 100 and terminal 200]
An example of the operation of base station 100 and terminal 200 having the above configuration will be described.

FIG. 12 is a sequence diagram showing an example of the operation of the base station 100 and the terminal 200.

In FIG. 12, the base station 100 determines the settings (configuration) related to the CLI-RSSI measurement (S101). The base station 100 transmits upper layer signaling information including the determined setting information related to the CLI-RSSI measurement to the terminal 200 (S102).

The terminal 200 configures the CLI-RSSI report (e.g., configures the resource configuration and the report configuration) based on the configuration information from the base station 100 (S103).

The terminal 200 measures the CLI-RSSI based on the configured CLI-RSSI resource configuration (e.g., including information about the measurement block) (S104). For example, the terminal 200 may measure the CLI-RSSI for each measurement block within the CLI-RSSI measurement resource.

The terminal 200 generates a CLI-RSSI report field (e.g., a UCI bit string) based on the configured CLI-RSSI report configuration (S105) and transmits the CLI-RSSI report to the base station 100 (S106).

The base station 100 may perform scheduling for the terminal 200 based on, for example, a CLI-RSSI report transmitted from the terminal 200 (not shown).

The above describes an example of operation of the base station 100 and the terminal 200.

Next, an example of a CLI-RSSI report (e.g., a reporting method or configuration method) according to one non-limiting embodiment of the present disclosure is described.

[CLI-RSSI report based on CSI report]
As an example, a CLI-RSSI report based on a CSI report in an SBFD scenario will be described. Note that the following description is also applicable to a dynamic/flexible TDD scenario.

Figure 13 shows an example of a CLI-RSSI report based on a CSI report.

FIG. 13(a) shows the status of terminal 200 (e.g., UE#1 and UE#2) and base station 100 (e.g., gNB), and FIG. 13(b) shows an example of resource allocation in SBFD. In FIG. 13(b), subband#0 and subband#2 are downlink (DL) subbands, and subband#1 is an uplink (UL) subband.

In the example of FIG. 13, UE#2 transmits a UL signal in subband#1. UE#1 also measures the CLI (e.g., CLI-RSSI) between the terminals. For example, UE#1 may measure the CLI leakage in the DL subband (subband#0) due to UL transmission of UE#2 in the UL subband (subband#1) by CLI-RSSI.

As shown in FIG. 13(a), UE#1 reports a CLI-RSSI report based on the CLI-RSSI measurement results to the base station. For example, as shown in FIG. 13(b), UE#1 may report a CLI-RSSI report based on the CLI-RSSI measurement results measured in subband#0 (DL subband) to base station 100 in subband#1 (UL subband).

In a CLI-RSSI report based on a CSI report, the report configuration and resource configuration in the CLI-RSSI report can be reused as is. For example, the report configuration is a setting related to the report of the terminal 200 that measures the CLI-RSSI, and the resource configuration is a setting related to the CLI-RSSI resource to be measured (e.g., the symbol or resource block to be measured).

On the other hand, the report field of the uplink control information (UCI) bit string generation function in the CLI-RSSI report needs to be modified. For example, a report field that takes into account uneven CLI leakage distribution can be a useful report for scheduling to the base station 100.

[How to configure the report field]
Next, an example of a method for configuring a report field in terminal 200 (for example, CLI measurement section 203 and transmission control section 204) will be described. Also, an example of the operation of base station 100 (for example, scheduling section 104) will be described.

　Below, report field configuration methods 1 to 3 are explained.

<Configuration method 1>
In configuration method 1, the Report field may be configured by the CLI-RSSI (measured values) of a prescribed number (e.g., m) of measurement blocks among a plurality (e.g., k) of measurement blocks obtained by dividing the CLI measurement band. For example, the Report field may be configured by the CLI-RSSI of the upper (or lower) m measurement blocks.

Figure 14 shows an example of the Report field configuration for configuration method 1.

The terminal 200, for example, measures the CLI-RSSI for each of multiple (e.g., k) measurement blocks, quantizes the m CLI-RSSIs arranged in descending (or ascending) order, and configures them in the Report field. The Report field may store the CLI-RSSIs (e.g., quantized values) of a specified number m of measurement blocks in descending or ascending order.

In addition, the CLI-RSSI does not have to be sorted in ascending or descending order, and the top (or bottom) m CLI-RSSIs may be sorted in the order of the measurement blocks in the frequency direction and stored in the Report field.

For example, if the CLI-RSSI report reports the CLI-RSSI values of the top m measurement blocks, the top m CLI-RSSI values with the strongest interference and the measurement blocks corresponding to each CLI-RSSI value may be configured in descending order in the Report field.

Also, for example, when reporting the CLI-RSSI values of the bottom m measurement blocks using a CLI-RSSI report, the bottom m CLI-RSSI values with weak interference and the measurement blocks corresponding to each CLI-RSSI value may be arranged in ascending order in the Report field. When reporting the bottom m CLI-RSSI values, the Report field may also include at least the CLI values of the measurement blocks corresponding to the DL/UL subbands or the edges of the DL/UL.

Quantization may also define, for example, an n1-bit quantization table (n1: the number of bits in the table obtained from the range and step size) and an n2-bit quantization difference table (n2: the number of bits in the table obtained from the range and step size). The terminal 200 may convert from the measurement value to the quantization value, for example, using the quantization table and the quantization difference table.

Furthermore, "m", which indicates the number of CLI-RSSIs reported in the Report field, may be defined in a specification (e.g., a standard), may be set in the terminal 200 by higher layer signaling (e.g., Radio Resource Control (RRC) signaling), or may be set (or notified) to the terminal 200 by downlink control information (e.g., downlink control information (DCI)).

In addition, m may be defined, for example, as a function of the payload size "n" of the uplink control information (UCI) bits reported to the base station 100. In addition, m and n may differ depending on, for example, whether the uplink shared channel (PUSCH: Physical Uplink Shared Channel) or the uplink control channel (PUCCH: Physical Uplink Control Channel) is used for transmission.

Furthermore, the Report field of configuration method 1 may store an average value of the CLI-RSSI values for each of multiple measurement blocks (e.g., an average CLI-RSSI value). The average CLI-RSSI value may be, for example, the average value of the CLI-RSSI values of the remaining measurement blocks that are different from the m CLI-RSSIs stored in the Report field, or the average value of the CLI-RSSI values of all measurement blocks, or may be calculated from the average value of the top or bottom X CLI-RSSI values (X is greater than m).

For example, in the example shown in FIG. 14, a CLI-RSSI value of m=4 is reported by the Report field (CLI report field) of Report number n. For example, the first to fourth columns (e.g., #1 to #4) of the Report field shown in FIG. 14 may store information (e.g., Measurement block ID) that identifies the measurement blocks corresponding to the top m CLI-RSSI values.

Furthermore, the fifth to eighth columns (e.g., #5 to #8) of the Report field shown in FIG. 14 may store quantized values of the CLI-RSSI values corresponding to each of Measurement block IDs #1 to #4. For example, as shown in FIG. 14, a quantized CLI-RSSI value (quantized RSSI) obtained by quantizing the measurement value using a quantization table may be stored as a report value corresponding to the CLI-RSSI value corresponding to Measurement block IDs #1 (e.g., the largest CLI-RSSI value). Also, as shown in FIG. 14, a quantized differential CLI-RSSI value (quantized differential RSSI) obtained by quantizing the difference between the measurement value and the CLI-RSSI value of Measurement block ID #1 using a quantization differential table may be stored as a report value corresponding to the CLI-RSSI value corresponding to Measurement block IDs #2 to #4.

Furthermore, the ninth column (e.g., #9) of the Report field shown in FIG. 14 may store, for example, a quantized value of the average CLI-RSSI (in the example of FIG. 14, the average CLI-RSSI value of the remaining measurement blocks that is different from the top four CLI-RSSIs). Note that in configuration method 1, the average CLI-RSSI value does not need to be included in the Report field.

In this way, in configuration method 1, the terminal 200 reports the CLI-RSSI of m measurement blocks out of multiple measurement blocks to the base station 100 using the Report field. This allows the terminal 200 to report to the base station 100 a detailed distribution of non-uniform CLI leakage within the CLI measurement band on a measurement block basis.

Based on, for example, the reported CLI-RSSI for each measurement block and the frequency position of the CLI-RSSI, the base station 100 can appropriately perform scheduling for the terminal 200 (e.g., determining MCS and DL allocation) by taking into account the detailed distribution of uneven CLI leakage within the CLI measurement band.

For example, by reporting the top m CLI-RSSIs in descending order, the base station 100 can identify frequency regions in the CLI measurement band where interference is strong, and can schedule to not allocate signals to those frequency regions. Also, for example, by reporting the bottom m CLI-RSSIs in ascending order, the base station 100 can identify frequency regions in the CLI measurement band where interference is weak, and can schedule to allocate signals to those frequency regions.

Scheduling that reduces interference between terminals in this way can reduce degradation of the reception characteristics at terminal 200.

Furthermore, in configuration method 1, the terminal 200 reports the average CLI-RSSI in the Report field. This allows the base station 100 to identify the approximate interference level in the remaining frequency ranges of the CLI measurement band that are not reported in the Report field. For example, if the top m CLI-RSSI values reported in descending order are large and the average CLI-RSSI value is also large (e.g., greater than a threshold), scheduling is possible that does not allocate signals to frequency ranges that are not reported in the Report field. On the other hand, for example, if the top m CLI-RSSI values reported in descending order are large and the average CLI-RSSI value is small (e.g., below a threshold), scheduling is possible that allocates signals to frequency ranges that are not reported in the Report field.

In addition, in configuration method 1, by setting (e.g., limiting) the number of CLI-RSSIs constituting the Report field to m, it is possible to reduce the number of UCI bits and the number of reports to the base station 100. Here, the reason that the number of reports can be reduced is that the number of UCI bits is limited, and when reporting all CLI-RSSIs, the terminal 200 may transmit UCI (e.g., including reports) to the base station 100 multiple times, but by limiting the number of CLI-RSSIs to be reported to m, the number of reports to the base station 100 can be reduced.

In configuration method 1, the CLI-RSSI of a specified number m of measurement blocks among multiple measurement blocks in the CLI measurement band is reported, but this is not limited to this, and the CLI-RSSI of all measurement blocks in the CLI measurement band may be reported (for example, m=k).

<Configuration method 2>
In configuration method 2, the Report field may be configured with information in a bitmap format corresponding to each of a plurality of (eg, k) measurement blocks into which the CLI measurement band is divided.

The base station 100, for example, divides the CLI measurement band into multiple threshold sections in the frequency direction. At least one threshold for the measured value of the CLI-RSSI may be set in each of the multiple threshold sections. Furthermore, each threshold section may include at least one measurement block.

The terminal 200 determines a CLI-RSSI report that includes, for example, information in a bitmap format indicating the comparison result between the measured CLI-RSSI value for each of a plurality of measurement blocks and a threshold. For example, the terminal 200 compares the threshold set for each threshold interval with the CLI-RSSI value in the measurement block within each threshold interval, and determines a one-bit value indicating the comparison result for each measurement block. For example, if the CLI-RSSI value is equal to or less than the threshold, '0' may be set, and if the CLI-RSSI value is greater than the threshold, '1' may be set.

Furthermore, multiple thresholds may be set in one threshold interval. This allows the terminal 200 to obtain a comparison result of multiple bits for each measurement block. For example, if two thresholds are set in one threshold interval, the measurement value of CLI-RSSI is expressed in two bits.

The threshold set for each threshold interval may be defined in the specifications (or standards), may be set in the terminal 200 by notification by the base station 100 (e.g., higher layer signaling or dynamic notification), or may be determined by the terminal 200. As a method for determining the threshold by the terminal 200, for example, the average CLI-RSSI value of all measurement blocks within the threshold interval, or an offset from the average CLI-RSSI value may be set as the threshold. The offset value may be defined in the specifications, or may be set in the terminal 200 by the base station 100. Furthermore, when the threshold is determined by the terminal 200, the terminal 200 may report the threshold to the base station 100.

Furthermore, the number of threshold intervals in the CLI measurement band and the size of the threshold interval (e.g., the bandwidth or the number of measurement blocks included in the threshold interval) may be determined by the terminal 200. In this case, the terminal 200 may report information about the threshold interval (including, for example, the number of threshold intervals and the size of the threshold interval (or the number of measurement blocks included in the threshold interval)) to the base station 100.

In this way, in configuration method 2, the terminal 200 reports information regarding the CLI-RSSI of all measurement blocks (e.g., information indicating whether it is greater than a threshold value) to the base station 100 via the Report field. This allows the terminal 200 to report to the base station 100 a detailed distribution of non-uniform CLI leakage within the CLI measurement band on a measurement block basis.

Based on, for example, the reported CLI-RSSI for each measurement block and the frequency position of the CLI-RSSI, the base station 100 can appropriately schedule the terminal 200 (e.g., determine the MCS and DL allocation) while taking into account the detailed distribution of the non-uniform CLI leakage within the CLI measurement band. Scheduling that reduces such interference between terminals can reduce the deterioration of the reception characteristics at the terminal 200.

In addition, in configuration method 2, by reporting the CLI-RSSI value in bitmap format, it is possible to reduce the number of UCI bits and the number of reports to the base station 100. Here, the reason that the number of reports can be reduced is that the number of UCI bits is limited, and when reporting all CLI-RSSI, the terminal 200 may transmit UCI (including reports, for example) to the base station 100 multiple times, but by reporting the CLI-RSSI value in bitmap format, it is possible to reduce the number of UCI bits and the number of reports to the base station 100.

In addition, in configuration method 2, by setting multiple threshold intervals in the frequency direction, it is possible to set thresholds according to the characteristics of the non-uniform CLI distribution (e.g., general, carrier leakage, and IQ image), and the terminal 200 can report a Report field suitable for the non-uniform CLI distribution.

Next, we will explain an example of how to configure the Report field in configuration method 2.

<Configuration method 2-1>
In configuration method 2-1, the Report field reports bitmap-format information (eg, '0' or '1') for all measurement blocks.

Figure 15 shows an example of a Report field for configuration method 2-1.

As shown in FIG. 15, terminal 200 compares the CLI-RSSI values (measured values) of all (e.g., k) measurement blocks within the CLI measurement band with the thresholds of each threshold interval. In the example of FIG. 15(a), terminal 200 compares the CLI-RSSI values of measurement blocks 1 to 3 with the threshold of threshold interval 1 (threshold 1), and compares the CLI-RSSI values of the remaining measurement blocks 4 to k with the threshold of threshold interval 2 (threshold 2).

For example, as shown in FIG. 15(b), for each measurement block, the terminal 200 stores '0' in the Report field if the CLI-RSSI value is less than or equal to the threshold, and stores '1' in the Report field if the CLI-RSSI value is greater than the threshold.

In this way, in the example of Figure 15(b), the CLI-RSSI value is reported in bitmap format (0 or 1) in the Report field, so that only one bit is required per measurement block, and the number of UCI bits can be reduced compared to when the CLI-RSSI value (e.g., quantized value) is reported.

In addition, even if the number of measurement blocks (the value of k in FIG. 15) increases, the number of bits used for reporting per measurement block is reduced, so the number of UCI bits and the number of reports to the base station 100 can be reduced.

<Configuration method 2-2>
In configuration method 2-2, the CLI-RSSI value is reported using "part 1" and "part 2" of the CLI report. The terminal 200 may determine, for example, CLI report part 1 including information in a bitmap format indicating a comparison result between the CLI-RSSI measurement value of each of a plurality of measurement blocks and a threshold, and CLI report part 2 including the CLI-RSSI measurement value of a prescribed number of measurement blocks among the plurality of measurement blocks.

Figure 16 shows an example of a Report field for configuration method 2-2.

For example, the terminal 200 may report part 1 and part 2 of the CLI report on the same PUSCH. Reporting of the CLI report using the PUSCH may be applied, for example, when the CLI report setting is an aperiodic CLI report or a semi-persistent CLI report.

Furthermore, for example, when terminal 200 reports CLI report part 1 but does not report CLI report part 2, terminal 200 may report CLI report part 1 on PUCCH. Reporting of a CLI report using PUCCH may be applied, for example, when the CLI report setting is periodic CLI report or semi-persistent CLI report.

Note that the channels used to report CLI Report Part 1 and CLI Report Part 2 are not limited to the above-mentioned examples and may be other channels. Furthermore, the combination of CLI report settings (e.g., periodic CLI report, aperiodic CLI report, and semi-persistent CLI report) and the channels used are not limited to the above-mentioned examples.

Furthermore, for example, the terminal 200 may encode

parts

1 and 2 of the CLI report separately and transmit CLI report part 2 after transmitting CLI report part 1. This allows the base station 100 to determine the data size of CLI report part 2, for example, based on CLI report part 1, and therefore to variably set the data size of CLI report part 2.

Furthermore, when generating CLI report part 1, as shown in FIG. 16(a), terminal 200 compares the CLI-RSSI value of the measurement block in each threshold interval with the threshold set for each threshold interval. Then, as shown in FIG. 16(b), CLI report part 1 may be configured with bitmap information (e.g., 0 or 1) corresponding to the comparison result between the CLI-RSSI value of the measurement block and the threshold, similar to configuration method 2-1.

Also, as shown in FIG. 16(c), CLI report part 2 may be composed of quantized values (e.g., quantized CLI-RSSI values and quantized differential CLI-RSSI values) of all measurement blocks whose CLI-RSSI values exceed a threshold among the measurement blocks reported by CLI report part 1, or, as in configuration method 1, quantized values of the top m CLI-RSSI values (e.g., quantized CLI-RSSI values and quantized differential CLI-RSSI values).

For example, in the case of a periodic CLI report that is reported many times (e.g., a periodic CLI report), the terminal 200 can reduce the number of reports by reporting CLI report part 1 and not reporting CLI report part 2.

Furthermore, for example, in the case of a non-periodic CLI report with a small number of reports (e.g., an aperiodic CLI report), the terminal 200 can report to the base station 100 a CLI value with a large quantization granularity that cannot be reported in the CLI report part 1 by reporting both the CLI report part 1 and the report part 2. This allows the base station 100 to perform scheduling (e.g., determining DL allocation resources and MCS) based on, for example, the detailed CLI-RSSI value reported by the CLI report part 2.

The above explains an example of how to configure the Report field in configuration method 2.

In the above example, a case where two threshold intervals are set within the CLI measurement band is described, but the number of threshold intervals is not limited to two, and three or more may be set. Alternatively, there may be only one threshold interval within the CLI measurement band.

In addition, in configuration method 2, one threshold may be set in one threshold interval, and multiple thresholds may be set in other threshold intervals.

In the above example, a case was described where bitmap-formatted information about all measurement blocks within the CLI measurement band was reported, but this is not limited thereto, and bitmap-formatted information about some of the measurement blocks within the CLI measurement band may also be reported. For example, in the Report field, information about measurement blocks corresponding to some of the frequency bands in the CLI measurement band may be reported, or information about measurement blocks at intervals of a specified number may be reported.

<Configuration method 3>
In configuration method 3, the Report field may be configured by the interference model number and the average value of the CLI-RSSI.

The interference model number is, for example, a number that identifies an interference model that models the expected distribution of CLI (or CLI leakage distribution) in the CLI measurement band.

Figure 17 shows an example of the Report field configuration for configuration method 3.

The base station 100, for example, sets information related to multiple interference models in the terminal 200. The setting of multiple interference models may be defined by a specification (e.g., a standard), may be set in the terminal 200 by higher layer signaling, or may be set (or notified) to the terminal 200 by downlink control information.

The terminal 200, for example, compares the CLI distribution (e.g., interference distribution) obtained from the measured CLI-RSSI values of each of multiple measurement blocks within the CLI measurement band with the set interference model, and identifies the interference model number of the interference model that corresponds to the CLI distribution (e.g., the closest interference model).

In addition, the terminal 200 calculates, for example, the average value of the CLI-RSSI values (average CLI-RSSI value) for each measurement block in the CLI measurement band.

Then, the terminal 200 reports a CLI-RSSI report including the identified interference model number and the average CLI-RSSI value to the base station 100.

In the example shown in FIG. 17(a), information on N interference models (e.g., interference models 0 to N-1) is set from base station 100 to terminal 200. Terminal 200 calculates the CLI distribution (CLI leakage) in the CLI measurement band, for example, based on the CLI-RSSI values of all measurement blocks in the CLI measurement band. Terminal 200 compares the calculated CLI distribution with the N interference models, and selects the interference model that is closest to the CLI distribution (interference model 1 in FIG. 17(a)).

In addition, the terminal 200 quantizes the average value of the CLI-RSSI values of all measurement blocks to obtain a quantized average CLI-RSSI value.

As shown in FIG. 17(b), the terminal 200 constructs (or stores) the selected interference model number (e.g., the first column (#1)) and the quantized average CLI-RSSI value (e.g., the second column (#2)) in the Report field and reports it to the base station 100.

Base station 100 identifies (or estimates) the CLI distribution in terminal 200 based on the interference model number and the quantized average CLI-RSSI value included in the report reported by terminal 200.

In this way, in configuration method 3, the terminal 200 reports information about the interference model corresponding to the CLI distribution in the CLI measurement band to the base station 100 through the Report field. This allows the terminal 200 to report to the base station 100 a detailed distribution of non-uniform CLI leakage within the CLI measurement band.

Base station 100 can appropriately schedule terminal 200 (e.g., determine MCS and DL allocation) based on, for example, an interference model corresponding to the CLI distribution in the reported CLI measurement band and the average CLI-RSSI value, taking into account the detailed distribution of non-uniform CLI leakage in the CLI measurement band. Scheduling that reduces such interference between terminals can reduce degradation of reception characteristics in terminal 200.

In addition, in configuration method 3, the terminal 200 reports an interference model number instead of the measured value of CLI-RSSI, which makes it possible to reduce the number of UCI bits and the number of reports to the base station 100.

In addition, since the terminal 200 reports the average CLI-RSSI value of all measurement blocks in the CLI measurement band, the base station 100 identifies the overall power of the CLI distribution. This allows the base station 100 to adjust the CLI distribution according to the interference model in accordance with the average CLI-RSSI value, thereby improving the estimation accuracy of the CLI distribution.

　Above, we have explained report field configuration methods 1 to 3.

In this manner, in this embodiment, the terminal 200 determines a CLI-RSSI report based on the measured CLI-RSSI value for each of a plurality of measurement blocks obtained by dividing the CLI measurement band (measurement resource) in the frequency domain, and transmits the CLI-RSSI report to the base station 100. In this manner, by reporting the CLI-RSSI report to the base station 100 based on the CLI-RSSI value for each measurement block, for example, the CLI-RSSI value for each measurement block can be reflected in the report content for the uneven distribution of CLI leakage. Therefore, according to this embodiment, the terminal 200 can appropriately report the CLI between terminals (uneven CLI distribution) to the base station 100. For example, the base station 100 can appropriately perform scheduling (for example, setting MCS or allocating DL resources) for the terminal 200 according to the reported CLI value and the frequency position (for example, the position of the measurement block) corresponding to the reported CLI.

Other Embodiments
In addition, an embodiment of the present disclosure is not limited to Layer 1-based reporting, but can also be applied to Layer 2-based reporting using Medium Access Control (MAC) signaling, or Layer 3-based reporting using Radio Resource Control (RRC) messages. In Layer 2-based reporting, the frequency of reporting is lower than that of Layer 1-based reporting, but the number of bits that can be transmitted is increased. In addition, in Layer 3-based reporting, the functionality of the reporting method in the existing L3-based SRS-RSRP (e.g., configuration or notification method, etc.) can be reused.

In addition, in the above embodiment, the measurement and reporting of short-term interference between terminals is not limited to within the same cell, but can also be applied to multiple cells. For example, when communication is performed in different directions in different cells, a terminal at the cell boundary receives CLI from a terminal in a different cell. For this reason, the measurement and reporting of short-term interference between terminals is effective in reducing CLI between terminals in multiple cells.

In the above embodiment, the size (or resource size, bandwidth) of the multiple measurement blocks in the CLI measurement band may be uniform or non-uniform. For example, when non-uniform sizes are set, the closer the measurement block is to the boundary between the UL subband and the DL subband, the narrower the bandwidth (e.g., smaller granularity) may be set. Alternatively, when non-uniform sizes are set, the closer the section (e.g., threshold section) is to the boundary between the UL subband and the DL subband, the narrower the bandwidth (e.g., smaller granularity) may be set. In this case, the size of the measurement blocks within the section may be the same or different. As a result, the closer to the boundary between the UL subband and the DL subband, the greater the frequency fluctuation of the CLI distribution (e.g., general in-band emission), so that the base station 100 can identify a more detailed CLI distribution. For example, the size of the measurement block may be defined in the specification, may be set in the terminal 200 by upper layer signaling, or may be set (or notified) to the terminal 200 by downlink control information.

In addition, the measurement block in the above embodiment may be referred to by other names such as subband or frequency block.

Furthermore, in the above embodiment, the reported measurement value of reception quality is not limited to CLI-RSSI, and may be other measurement values. For example, the reported measurement value may be other measurement values such as SRS-RSRP/SRS-RSRQ (Reference Signal Received Quality). The same report field configuration method and operation as for CLI-RSSI can be applied to other measurement values.

Furthermore, in the above-mentioned embodiment, values such as the number of measurement blocks in the CLI measurement band, the number of bits allocated to the CLI-RSSI value, and the prescribed numbers m, k, and N are merely examples and are not limited. Furthermore, the configuration of the Report field in the above-mentioned embodiment is merely an example and is not limited. For example, the storage order of the configuration of the Report field described above may be different, some of the information stored in the Report field described above may not be included, and other information may be included in addition to the information stored in the Report field described above.

(supplement)
Information indicating whether terminal 200 supports the functions, operations or processes described in the above-mentioned embodiments may be transmitted (or notified) from terminal 200 to base station 100, for example, as capability information or capability parameters of terminal 200.

The capability information may include information elements (IEs) that individually indicate whether the terminal 200 supports at least one of the functions, operations, or processes shown in the above-described embodiments. Alternatively, the capability information may include information elements that indicate whether the terminal 200 supports a combination of any two or more of the functions, operations, or processes shown in the above-described embodiments.

Based on the capability information received from the terminal 200, the base station 100 may, for example, determine (or decide or assume) the functions, operations, or processing that the terminal 200 that transmitted the capability information supports (or does not support). The base station 100 may perform operations, processing, or control according to the determination result based on the capability information. For example, the base station 100 may control reporting of CLI distribution to the terminal 200 based on the capability information received from the terminal 200.

Note that the fact that the terminal 200 does not support some of the functions, operations, or processes described in the above-described embodiment may be interpreted as meaning that such some of the functions, operations, or processes are restricted in the terminal 200. For example, information or requests regarding such restrictions may be notified to the base station 100.

The information regarding the capabilities or limitations of the terminal 200 may be defined in a standard, for example, or may be implicitly notified to the base station 100 in association with information already known at the base station 100 or information transmitted to the base station 100.

(Control signal)
In the present disclosure, a downlink control signal (or downlink control information) related to an embodiment of the present disclosure may be, for example, a signal (or information) transmitted in a Physical Downlink Control Channel (PDCCH) in a physical layer, or a signal (or information) transmitted in a Medium Access Control Control Element (MAC CE) or Radio Resource Control (RRC) in a higher layer. In addition, the signal (or information) is not limited to being notified by a downlink control signal, and may be predefined in a specification (or standard), or may be preconfigured in a base station and a terminal.

In the present disclosure, the uplink control signal (or uplink control information) related to one embodiment of the present disclosure may be, for example, a signal (or information) transmitted in a PUCCH in the physical layer, or a signal (or information) transmitted in a MAC CE or RRC in a higher layer. Furthermore, the signal (or information) is not limited to being notified by an uplink control signal, but may be predefined in a specification (or standard), or may be preconfigured in a base station and a terminal. Furthermore, the uplink control signal may be replaced with, for example, uplink control information (UCI), 1st stage sidelink control information (SCI), or 2nd stage SCI.

(base station)
In an embodiment of the present disclosure, the base station may be a Transmission Reception Point (TRP), a cluster head, an access point, a Remote Radio Head (RRH), an eNodeB (eNB), a gNodeB (gNB), a Base Station (BS), a Base Transceiver Station (BTS), a parent device, a gateway, or the like. In addition, in sidelink communication, a terminal may play the role of a base station. In addition, instead of a base station, a relay device that relays communication between an upper node and a terminal may be used. Also, a roadside unit may be used.

(Uplink/Downlink/Sidelink)
An embodiment of the present disclosure may be applied to, for example, any of an uplink, a downlink, and a sidelink. For example, an embodiment of the present disclosure may be applied to a Physical Uplink Shared Channel (PUSCH), a Physical Uplink Control Channel (PUCCH), a Physical Random Access Channel (PRACH) in the uplink, a Physical Downlink Shared Channel (PDSCH), a PDCCH, a Physical Broadcast Channel (PBCH) in the downlink, or a Physical Sidelink Shared Channel (PSSCH), a Physical Sidelink Control Channel (PSCCH), or a Physical Sidelink Broadcast Channel (PSBCH) in the sidelink.

Note that PDCCH, PDSCH, PUSCH, and PUCCH are examples of a downlink control channel, a downlink data channel, an uplink data channel, and an uplink control channel, respectively. Also, PSCCH and PSSCH are examples of a sidelink control channel and a sidelink data channel. Also, PBCH and PSBCH are examples of a broadcast channel, and PRACH is an example of a random access channel.

(Data Channel/Control Channel)
An embodiment of the present disclosure may be applied to, for example, any of a data channel and a control channel. For example, the channel in an embodiment of the present disclosure may be replaced with any of the data channels PDSCH, PUSCH, and PSSCH, or the control channels PDCCH, PUCCH, PBCH, PSCCH, and PSBCH.

(Reference signal)
In one embodiment of the present disclosure, the reference signal is, for example, a signal known by both the base station and the mobile station, and may be called a Reference Signal (RS) or a pilot signal. The reference signal may be any of a Demodulation Reference Signal (DMRS), a Channel State Information - Reference Signal (CSI-RS), a Tracking Reference Signal (TRS), a Phase Tracking Reference Signal (PTRS), a Cell-specific Reference Signal (CRS), or a Sounding Reference Signal (SRS).

(Time interval)
In an embodiment of the present disclosure, the unit of time resource is not limited to one or a combination of slots and symbols, but may be, for example, a time resource unit such as a frame, a superframe, a subframe, a slot, a time slot subslot, a minislot, or a symbol, an Orthogonal Frequency Division Multiplexing (OFDM) symbol, a Single Carrier - Frequency Division Multiplexing (SC-FDMA) symbol, or another time resource unit. In addition, the number of symbols included in one slot is not limited to the number of symbols exemplified in the above embodiment, and may be another number of symbols.

(frequency band)
An embodiment of the present disclosure may be applied to either a licensed band or an unlicensed band.

(communication)
An embodiment of the present disclosure may be applied to any of communication between a base station and a terminal (Uu link communication), communication between terminals (Sidelink communication), and Vehicle to Everything (V2X) communication. For example, the channel in an embodiment of the present disclosure may be replaced with any of PSCCH, PSSCH, Physical Sidelink Feedback Channel (PSFCH), PSBCH, PDCCH, PUCCH, PDSCH, PUSCH, and PBCH.

Furthermore, an embodiment of the present disclosure may be applied to either a terrestrial network or a non-terrestrial network (NTN: Non-Terrestrial Network) using a satellite or a High Altitude Pseudo Satellite (HAPS: High Altitude Pseudo Satellite). Furthermore, an embodiment of the present disclosure may be applied to a terrestrial network in which the transmission delay is large compared to the symbol length or slot length, such as a network with a large cell size or an ultra-wideband transmission network.

(Antenna port)
In one embodiment of the present disclosure, an antenna port refers to a logical antenna (antenna group) consisting of one or more physical antennas. For example, an antenna port does not necessarily refer to one physical antenna, but may refer to an array antenna consisting of multiple antennas. For example, an antenna port may be defined as the minimum unit by which a terminal station can transmit a reference signal, without specifying how many physical antennas the antenna port is composed of. In addition, an antenna port may be defined as the minimum unit by which a weighting of a precoding vector is multiplied.

<5G NR system architecture and protocol stack>
3GPP continues to work on the next release of the fifth generation of mobile phone technology (also simply referred to as "5G"), which includes the development of a new radio access technology (NR) that will operate in the frequency range up to 100 GHz. The first version of the 5G standard was completed in late 2017, allowing the prototyping and commercial deployment of 5G NR compliant terminals (e.g., smartphones).

For example, the system architecture as a whole assumes an NG-RAN (Next Generation - Radio Access Network) comprising gNBs. The gNBs provide the UE-side termination of the NG radio access user plane (SDAP/PDCP/RLC/MAC/PHY) and control plane (RRC) protocols. The gNBs are connected to each other via an Xn interface. The gNBs are also connected to the Next Generation Core (NGC) via a Next Generation (NG) interface, more specifically to the Access and Mobility Management Function (AMF) (e.g., a specific core entity performing AMF) via an NG-C interface, and to the User Plane Function (UPF) (e.g., a specific core entity performing UPF) via an NG-U interface. The NG-RAN architecture is shown in Figure 18 (see, for example, 3GPP TS 38.300 v15.6.0, section 4).

The NR user plane protocol stack (see, for example, 3GPP TS 38.300, section 4.4.1) includes the PDCP (Packet Data Convergence Protocol (see, for example, TS 38.300, section 6.4)) sublayer, the RLC (Radio Link Control (see, for example, TS 38.300, section 6.3)) sublayer, and the MAC (Medium Access Control (see, for example, TS 38.300, section 6.2)) sublayer, which are terminated on the network side at the gNB. A new Access Stratum (AS) sublayer (SDAP: Service Data Adaptation Protocol) is also introduced on top of PDCP (see, for example, 3GPP TS 38.300, section 6.5). A control plane protocol stack is also defined for NR (see, for example, TS 38.300, section 4.4.2). An overview of Layer 2 functions is given in clause 6 of TS 38.300. The functions of the PDCP sublayer, RLC sublayer, and MAC sublayer are listed in clauses 6.4, 6.3, and 6.2 of TS 38.300, respectively. The functions of the RRC layer are listed in clause 7 of TS 38.300.

For example, the Medium-Access-Control layer handles multiplexing of logical channels and scheduling and scheduling-related functions, including handling various numerologies.

For example, the physical layer (PHY) is responsible for coding, PHY HARQ processing, modulation, multi-antenna processing, and mapping of signals to appropriate physical time-frequency resources. The physical layer also handles the mapping of transport channels to physical channels. The physical layer provides services to the MAC layer in the form of transport channels. A physical channel corresponds to a set of time-frequency resources used for the transmission of a particular transport channel, and each transport channel is mapped to a corresponding physical channel. For example, the physical channels include the PRACH (Physical Random Access Channel), PUSCH (Physical Uplink Shared Channel), and PUCCH (Physical Uplink Control Channel) as uplink physical channels, and the PDSCH (Physical Downlink Shared Channel), PDCCH (Physical Downlink Control Channel), and PBCH (Physical Broadcast Channel) as downlink physical channels.

NR use cases/deployment scenarios may include enhanced mobile broadband (eMBB), ultra-reliable low-latency communications (URLLC), and massive machine type communication (mMTC), which have diverse requirements in terms of data rate, latency, and coverage. For example, eMBB is expected to support peak data rates (20 Gbps in the downlink and 10 Gbps in the uplink) and effective (user-experienced) data rates that are about three times higher than the data rates offered by IMT-Advanced. On the other hand, for URLLC, stricter requirements are imposed on ultra-low latency (0.5 ms for user plane latency in UL and DL, respectively) and high reliability (1-10-5 within 1 ms). Finally, mMTC may require preferably high connection density (1,000,000 devices/km ² in urban environments), wide coverage in adverse environments, and extremely long battery life (15 years) for low-cost devices.

Therefore, OFDM numerology (e.g., subcarrier spacing, OFDM symbol length, cyclic prefix (CP) length, number of symbols per scheduling interval) suitable for one use case may not be valid for other use cases. For example, low latency services may preferably require a shorter symbol length (and therefore a larger subcarrier spacing) and/or fewer symbols per scheduling interval (also called TTI) than mMTC services. Furthermore, deployment scenarios with large channel delay spreads may preferably require a longer CP length than scenarios with short delay spreads. Subcarrier spacing may be optimized accordingly to maintain similar CP overhead. NR may support one or more subcarrier spacing values. Correspondingly, subcarrier spacings of 15 kHz, 30 kHz, 60 kHz... are currently considered. The symbol length Tu and subcarrier spacing Δf are directly related by the formula Δf = 1/Tu. Similar to LTE systems, the term "resource element" can be used to mean the smallest resource unit consisting of one subcarrier for the length of one OFDM/SC-FDMA symbol.

In the new wireless system 5G-NR, for each numerology and each carrier, a resource grid of subcarriers and OFDM symbols is defined for the uplink and downlink, respectively. Each element of the resource grid is called a resource element and is identified based on a frequency index in the frequency domain and a symbol position in the time domain (see 3GPP TS 38.211 v15.6.0).

<Functional separation between NG-RAN and 5GC in 5G NR>
Figure 19 shows the functional separation between NG-RAN and 5GC. The logical nodes of NG-RAN are gNB or ng-eNB. 5GC has logical nodes AMF, UPF, and SMF.

For example, gNBs and ng-eNBs host the following main functions:
- Radio Resource Management functions such as Radio Bearer Control, Radio Admission Control, Connection Mobility Control, dynamic allocation (scheduling) of resources to UEs in both uplink and downlink;
- IP header compression, encryption and integrity protection of the data;
- Selection of an AMF at UE attach time when routing to an AMF cannot be determined from information provided by the UE;
- Routing of user plane data towards the UPF;
- Routing of control plane information towards the AMF;
- Setting up and tearing down connections;
- scheduling and transmission of paging messages;
Scheduling and transmission of system broadcast information (AMF or Operation, Admission, Maintenance (OAM) origin);
- configuration of measurements and measurement reporting for mobility and scheduling;
- Transport level packet marking in the uplink;
- Session management;
- Support for network slicing;
- Management of QoS flows and mapping to data radio bearers;
- Support for UEs in RRC_INACTIVE state;
- NAS message delivery function;
- sharing of radio access networks;
- Dual connectivity;
- Close cooperation between NR and E-UTRA.

The Access and Mobility Management Function (AMF) hosts the following main functions:
– the ability to terminate Non-Access Stratum (NAS) signalling;
- NAS signalling security;
- Access Stratum (AS) security control;
- Core Network (CN) inter-node signaling for mobility between 3GPP access networks;
- Reachability to idle mode UEs (including control and execution of paging retransmissions);
- Managing the registration area;
- Support for intra-system and inter-system mobility;
- Access authentication;
- Access authorization, including checking roaming privileges;
- Mobility management control (subscription and policy);
- Support for network slicing;
– Selection of Session Management Function (SMF).

Additionally, the User Plane Function (UPF) hosts the following main functions:
- anchor point for intra/inter-RAT mobility (if applicable);
- external PDU (Protocol Data Unit) Session Points for interconnection with data networks;
- Packet routing and forwarding;
- Packet inspection and policy rule enforcement for the user plane part;
- Traffic usage reporting;
- an uplink classifier to support routing of traffic flows to the data network;
- Branching Point to support multi-homed PDU sessions;
QoS processing for the user plane (e.g. packet filtering, gating, UL/DL rate enforcement);
- Uplink traffic validation (mapping of SDF to QoS flows);
- Downlink packet buffering and downlink data notification triggering.

Finally, the Session Management Function (SMF) hosts the following main functions:
- Session management;
- Allocation and management of IP addresses for UEs;
- Selection and control of UPF;
- configuration of traffic steering in the User Plane Function (UPF) to route traffic to the appropriate destination;
- Control policy enforcement and QoS;
- Notification of downlink data.

<RRC connection setup and reconfiguration procedure>
Figure 20 shows some of the interactions between the UE, gNB, and AMF (5GC entities) when the UE transitions from RRC_IDLE to RRC_CONNECTED, NAS part (see TS 38.300 v15.6.0).

RRC is a higher layer signaling (protocol) used for UE and gNB configuration. With this transition, the AMF prepares UE context data (which includes, for example, PDU session context, security keys, UE Radio Capability, UE Security Capabilities, etc.) and sends it to the gNB with an INITIAL CONTEXT SETUP REQUEST. The gNB then activates AS security together with the UE. This is done by the gNB sending a SecurityModeCommand message to the UE and the UE responding with a SecurityModeComplete message to the gNB. The gNB then sends an RRCReconfiguration message to the UE, and upon receiving an RRCReconfigurationComplete from the UE, the gNB performs reconfiguration to set up Signaling Radio Bearer 2 (SRB2) and Data Radio Bearer (DRB). For signaling-only connections, the RRCReconfiguration steps are omitted, since SRB2 and DRB are not set up. Finally, the gNB notifies the AMF that the setup procedure is complete with an INITIAL CONTEXT SETUP RESPONSE.

Therefore, the present disclosure provides a 5th Generation Core (5GC) entity (e.g., AMF, SMF, etc.) comprising: a control circuit that, during operation, establishes a Next Generation (NG) connection with a gNodeB; and a transmitter that, during operation, transmits an initial context setup message to the gNodeB via the NG connection such that a signaling radio bearer between the gNodeB and a user equipment (UE) is set up. Specifically, the gNodeB transmits Radio Resource Control (RRC) signaling including a resource allocation configuration information element (IE) to the UE via the signaling radio bearer. The UE then transmits in the uplink or receives in the downlink based on the resource allocation configuration.

<IMT usage scenarios after 2020>
Figure 21 shows some of the use cases for 5G NR. The 3rd generation partnership project new radio (3GPP NR) considers three use cases that were envisioned by IMT-2020 to support a wide variety of services and applications. The first phase of specifications for enhanced mobile-broadband (eMBB) has been completed. Current and future work includes standardization for ultra-reliable and low-latency communications (URLLC) and massive machine-type communications (mMTC), in addition to expanding support for eMBB. Figure 21 shows some examples of envisioned usage scenarios for IMT beyond 2020 (see, for example, ITU-R M.2083 Figure 2).

The URLLC use cases have stringent requirements for performance such as throughput, latency, and availability. It is envisioned as one of the enabling technologies for future applications such as wireless control of industrial or manufacturing processes, remote medical surgery, automation of power transmission and distribution in smart grids, and road safety. URLLC's ultra-high reliability is supported by identifying technologies that meet the requirements set by TR 38.913. For NR URLLC in Release 15, key requirements include a target user plane latency of 0.5 ms for UL (uplink) and 0.5 ms for DL (downlink). The overall URLLC requirement for a single packet transmission is a block error rate (BLER) of 1E-5 for a packet size of 32 bytes with a user plane latency of 1 ms.

From a physical layer perspective, reliability can be improved in many possible ways. Current room for reliability improvement includes defining a separate CQI table for URLLC, more compact DCI formats, PDCCH repetition, etc. However, this room can be expanded to achieve ultra-high reliability as NR becomes more stable and more developed (with respect to the key requirements of NR URLLC). Specific use cases for NR URLLC in Release 15 include Augmented Reality/Virtual Reality (AR/VR), e-health, e-safety, and mission-critical applications.

In addition, the technology enhancements targeted by NR URLLC aim to improve latency and reliability. Technology enhancements for improving latency include configurable numerology, non-slot-based scheduling with flexible mapping, grant-free (configured grant) uplink, slot-level repetition in data channel, and pre-emption in downlink. Pre-emption means that a transmission for which resources have already been allocated is stopped and the already allocated resources are used for other transmissions with lower latency/higher priority requirements that are requested later. Thus, a transmission that was already allowed is preempted by a later transmission. Pre-emption is applicable regardless of the specific service type. For example, a transmission of service type A (URLLC) may be preempted by a transmission of service type B (eMBB, etc.). Technology enhancements for improving reliability include a dedicated CQI/MCS table for a target BLER of 1E-5.

The mMTC (massive machine type communication) use case is characterized by a very large number of connected devices transmitting relatively small amounts of data that are typically not sensitive to latency. The devices are required to be low cost and have very long battery life. From an NR perspective, utilizing very narrow bandwidth portions is one solution that saves power from the UE's perspective and allows for long battery life.

As mentioned above, the scope of reliability improvement in NR is expected to be broader. One of the key requirements for all cases, e.g. for URLLC and mMTC, is high or ultra-high reliability. Several mechanisms can improve reliability from a radio perspective and a network perspective. In general, there are two to three key areas that can help improve reliability. These areas include compact control channel information, data channel/control channel repetition, and diversity in frequency, time, and/or spatial domains. These areas are generally applicable to reliability improvement regardless of the specific communication scenario.

For NR URLLC, further use cases with more demanding requirements are envisaged, such as factory automation, transportation and power distribution. The demanding requirements are high reliability (up to 10-6 level of reliability), high availability, packet size up to 256 bytes, time synchronization up to a few μs (depending on the use case, the value can be 1 μs or a few μs depending on the frequency range and low latency of around 0.5 ms to 1 ms (e.g. 0.5 ms latency at the targeted user plane).

Furthermore, for NR URLLC, there may be several technology enhancements from a physical layer perspective. These include PDCCH (Physical Downlink Control Channel) enhancements for compact DCI, PDCCH repetition, and increased monitoring of PDCCH. Also, UCI (Uplink Control Information) enhancements related to enhanced HARQ (Hybrid Automatic Repeat Request) and CSI feedback enhancements. There may also be PUSCH enhancements related to minislot level hopping, and retransmission/repetition enhancements. The term "minislot" refers to a Transmission Time Interval (TTI) that contains fewer symbols than a slot (a slot comprises 14 symbols).

<QoS Control>
The 5G Quality of Service (QoS) model is based on QoS flows and supports both QoS flows that require a guaranteed flow bit rate (GBR QoS flows) and QoS flows that do not require a guaranteed flow bit rate (non-GBR QoS flows). Thus, at the NAS level, QoS flows are the finest granularity of QoS partitioning in a PDU session. QoS flows are identified within a PDU session by a QoS Flow ID (QFI) carried in the encapsulation header over the NG-U interface.

For each UE, 5GC establishes one or more PDU sessions. For each UE, the NG-RAN establishes at least one Data Radio Bearer (DRB) for the PDU session, e.g. as shown above with reference to Figure 20. Additional DRBs for the QoS flows of the PDU session can be configured later (when it is up to the NG-RAN). The NG-RAN maps packets belonging to different PDU sessions to different DRBs. The NAS level packet filters in the UE and 5GC associate UL and DL packets with QoS flows, whereas the AS level mapping rules in the UE and NG-RAN associate UL and DL QoS flows with DRBs.

Figure 22 shows the non-roaming reference architecture for 5G NR (see TS 23.501 v16.1.0, section 4.23). An Application Function (AF) (e.g. an external application server hosting 5G services as illustrated in Figure 21) interacts with the 3GPP core network to provide services, e.g. accessing a Network Exposure Function (NEF) to support applications that affect traffic routing, or interacting with a policy framework for policy control (e.g. QoS control) (see Policy Control Function (PCF)). Based on the operator's deployment, Application Functions that are considered trusted by the operator can interact directly with the relevant Network Functions. Application Functions that are not allowed by the operator to access the Network Functions directly interact with the relevant Network Functions using an external exposure framework via the NEF.

Figure 22 further shows further functional units of the 5G architecture, namely Network Slice Selection Function (NSSF), Network Repository Function (NRF), Unified Data Management (UDM), Authentication Server Function (AUSF), Access and Mobility Management Function (AMF), Session Management Function (SMF), and Data Network (DN, e.g. operator provided services, Internet access, or third party provided services). All or part of the core network functions and application services may be deployed and run in a cloud computing environment.

Therefore, the present disclosure provides an application server (e.g., an AF in a 5G architecture) comprising: a transmitter that, in operation, transmits a request including QoS requirements for at least one of a URLLC service, an eMMB service, and an mMTC service to at least one of 5GC functions (e.g., a NEF, an AMF, an SMF, a PCF, an UPF, etc.) to establish a PDU session including a radio bearer between a gNodeB and a UE according to the QoS requirements; and a control circuit that, in operation, performs a service using the established PDU session.

The present disclosure can be realized by software, hardware, or software in conjunction with hardware. Each functional block used in the description of the above embodiments may be realized, in part or in whole, as an LSI, which is an integrated circuit, and each process described in the above embodiments may be controlled, in part or in whole, by one LSI or a combination of LSIs. The LSI may be composed of individual chips, or may be composed of one chip that contains some or all of the functional blocks. The LSI may have data input and output. Depending on the degree of integration, the LSI may be called an IC, system LSI, super LSI, or ultra LSI.

The integrated circuit method is not limited to LSI, and may be realized by a dedicated circuit, a general-purpose processor, or a dedicated processor. Also, a field programmable gate array (FPGA) that can be programmed after LSI manufacturing, or a reconfigurable processor that can reconfigure the connections and settings of circuit cells inside the LSI, may be used. The present disclosure may be realized as digital processing or analog processing.

Furthermore, if an integrated circuit technology that can replace LSI appears due to advances in semiconductor technology or other derived technologies, it would be natural to use that technology to integrate functional blocks. The application of biotechnology, etc. is also a possibility.

The present disclosure may be implemented in any type of apparatus, device, or system (collectively referred to as a communications apparatus) having communications capabilities. The communications apparatus may include a radio transceiver and processing/control circuitry. The radio transceiver may include a receiver and a transmitter, or both as functions. The radio transceiver (transmitter and receiver) may include an RF (Radio Frequency) module and one or more antennas. The RF module may include an amplifier, an RF modulator/demodulator, or the like. Non-limiting examples of communication devices include telephones (e.g., cell phones, smartphones, etc.), tablets, personal computers (PCs) (e.g., laptops, desktops, notebooks, etc.), cameras (e.g., digital still/video cameras), digital players (e.g., digital audio/video players, etc.), wearable devices (e.g., wearable cameras, smartwatches, tracking devices, etc.), game consoles, digital book readers, telehealth/telemedicine devices, communication-enabled vehicles or mobile transport (e.g., cars, planes, ships, etc.), and combinations of the above-mentioned devices.

Communication devices are not limited to portable or mobile devices, but also include any type of equipment, device, or system that is non-portable or fixed, such as smart home devices (home appliances, lighting equipment, smart meters or measuring devices, control panels, etc.), vending machines, and any other "things" that may exist on an IoT (Internet of Things) network.

Communications include data communication via cellular systems, wireless LAN systems, communication satellite systems, etc., as well as data communication via combinations of these.

The communication apparatus also includes devices such as controllers and sensors that are connected or coupled to a communication device that performs the communication functions described in this disclosure. For example, it includes controllers and sensors that generate control signals and data signals used by the communication device to perform the communication functions of the communication apparatus.

In addition, communication equipment includes infrastructure facilities, such as base stations, access points, and any other equipment, devices, or systems that communicate with or control the various non-limiting devices listed above.

In one embodiment of the present disclosure, the control circuit determines the reporting information including the measurement values of a predetermined number of blocks among the plurality of blocks.

In one embodiment of the present disclosure, the measurement values of the specified number of blocks are stored in descending or ascending order in the report information field.

In one embodiment of the present disclosure, the report information field stores the average value of the measurement values for each of the multiple blocks.

In one embodiment of the present disclosure, the control circuit determines the report information including information in a bitmap format indicating a comparison result between the measurement value of each of the plurality of blocks and a threshold value.

In one embodiment of the present disclosure, the control circuit determines first report information including information in a bitmap format indicating a comparison result between the measurement value of each of the plurality of blocks and a threshold value, and second report information including the measurement value of a predetermined number of blocks among the plurality of blocks.

In one embodiment of the present disclosure, the control circuit determines the report information including information about an interference model corresponding to an interference distribution obtained by the measurements of each of the plurality of blocks.

In one embodiment of the present disclosure, the report information includes information regarding the average value of the measurement value for each of the multiple blocks.

A base station according to one embodiment of the present disclosure includes a receiving circuit that receives report information based on measurement values of reception quality for each of a plurality of blocks into which a measurement resource in the frequency domain is divided, and a control circuit that estimates the measurement values for each of the plurality of blocks based on the report information.

In a communication method according to one embodiment of the present disclosure, a terminal determines report information based on a measurement value of reception quality for each of a number of blocks into which a measurement resource in the frequency domain is divided, and transmits the report information.

In a communication method according to one embodiment of the present disclosure, a base station receives report information based on measurement values of reception quality for each of a plurality of blocks into which a measurement resource in the frequency domain is divided, and estimates the measurement values for each of the plurality of blocks based on the report information.

The entire disclosures of the specification, drawings and abstract contained in the Japanese application No. 2023-008095, filed on January 23, 2023, are incorporated herein by reference.

An embodiment of the present disclosure is useful in wireless communication systems.

100

Base station

101, 201

Receiving unit

102, 202 Demodulation and decoding unit 103 CLI distribution estimation unit 104

Scheduling unit

105, 205 Control

information storage unit

106, 206 Data and control

information generation unit

107, 207 Encoding and

modulation unit

108, 208 Transmitting unit 200 Terminal 203 CLI measurement unit 204 Transmission control unit

Claims

a control circuit that determines report information based on a measurement value of reception quality for each of a plurality of blocks obtained by dividing a measurement resource in the frequency domain;
A transmission circuit for transmitting the report information;
A terminal comprising:
the control circuitry determines the reporting information including the measurements for a predefined number of blocks of the plurality of blocks.
The terminal according to claim 1.
The measurement values of the specified number of blocks are stored in a field of the report information in descending or ascending order.
The terminal according to claim 2.
The field of the report information stores an average value of the measurement values for each of the plurality of blocks.
The terminal according to claim 3.
the control circuit determines the report information including information in a bitmap format indicative of a comparison result between the measurement value of each of the plurality of blocks and a threshold value.
The terminal according to claim 1.
The control circuit determines first report information including information in a bitmap format indicating a comparison result between the measurement value of each of the plurality of blocks and a threshold value, and second report information including the measurement value of a prescribed number of blocks among the plurality of blocks.
The terminal according to claim 1.
the control circuit determines the report information including information regarding an interference model corresponding to an interference distribution obtained by the measurements of each of the plurality of blocks.
The terminal according to claim 1.
The report information includes information regarding an average value of the measurement value for each of the plurality of blocks.
The terminal according to claim 7.
a receiving circuit for receiving report information based on a measurement value of reception quality for each of a plurality of blocks obtained by dividing a measurement resource in a frequency domain;
a control circuit for estimating the measurement value for each of the plurality of blocks based on the report information;
A base station comprising:
The terminal is
determining report information based on measurement values of reception quality for each of a plurality of blocks obtained by dividing a measurement resource in the frequency domain;
Transmitting the report information;
Communication method.
The base station is
receiving report information based on measurement values of reception quality for each of a plurality of blocks obtained by dividing a measurement resource in the frequency domain;
estimating the measurement value for each of the plurality of blocks based on the report information;
Communication method.
An integrated circuit for controlling processing of a terminal, the processing comprising:
A process of determining report information based on a measurement value of reception quality for each of a plurality of blocks obtained by dividing a measurement resource in the frequency domain;
A process of transmitting the report information;
4. An integrated circuit comprising:
An integrated circuit for controlling processing of a base station, the processing comprising:
A process of receiving report information based on measurement values of reception quality for each of a plurality of blocks obtained by dividing a measurement resource in the frequency domain;
estimating the measurement value for each of the plurality of blocks based on the report information;
4. An integrated circuit comprising: