Terminal, base station, and wireless communication method

Abstract

This terminal comprises a transmission unit for transmitting an upstream signal, a reception unit for receiving downstream control information (DCI) or a media access control element (MAC CE) that includes information regarding a transform precoder, and a control unit for determining whether or not to apply the transform precoder to the upstream signal.

Description

Cross - reference to related applications

[0001] This application is based on Japanese Patent Application No. 2021 - 134522 filed on August 20, 2021, claims the benefit of its priority, and all the contents of the patent application are incorporated herein by reference.

Technical Field

[0002] This disclosure relates to a terminal and a wireless communication method.

Background Art

[0003] In the Third Generation Partnership Project (3GPP), which is an international standardization organization, Release 15 of New Radio (NR), which is the fifth - generation (5G) Radio Access Technology (RAT), has been standardized as a successor to Long Term Evolution (LTE), which is the 3.9 - generation RAT, and LTE - Advanced, which is the fourth - generation RAT (for example, Non - Patent Document 1). LTE and / or LTE - Advanced are also called Evolved Universal Terrestrial Radio Access (E - UTRA).

Prior Art Documents

Non - Patent Documents

[0004]

Non - Patent Document 1

Summary of the Invention

[0005] In Releases 15 and 16 of NR, as the waveform of a signal, Orthogonal Frequency Division Multiplexing (OFDM) using a Cyclic Prefix (CP) (hereinafter referred to as "CP-OFDM"), or Discrete Fourier Transform spreading (DFT spreading) OFDM (hereinafter referred to as "DFT-s-OFDM") can be applied. DFT-s-OFDM is CP-OFDM to which a function for performing DFT spreading (hereinafter referred to as "transform precoder") is applied. Therefore, depending on whether or not to apply the transform precoder, it is possible to switch which waveform of DFT-s-OFDM or CP-OFDM to use.

[0006] In Releases 15 and 16 of NR, whether or not to apply the transform precoder is configured for a terminal by a network (e.g., a base station) using signaling of a Radio Resource Control (RRC) layer (hereinafter referred to as "RRC signaling"). However, when using RRC signaling, compared with the case of using signaling of a layer lower than the RRC layer, the processing delay in the terminal becomes large, so there is a possibility that it may not be possible to switch whether or not to apply the transform precoder at an appropriate timing according to the radio situation. One of the objects of the present disclosure is to provide a terminal and a wireless communication method capable of appropriately switching whether or not to apply a transform precoder.

[0007] A terminal according to one aspect of the present disclosure includes a transmission unit that transmits an uplink signal, a reception unit that receives downlink control information (DCI) or a media access control element (MAC CE) including information about a transform precoder, and a control unit that determines whether or not to apply the transform precoder to the uplink signal based on the information about the transform precoder.

[0008] According to one aspect of the present disclosure, one of the objectives is to provide a terminal and a wireless communication method that can appropriately switch whether to apply a transform precoder.

Brief Description of the Drawings

[0009]

Figure 1

Figure 2

Figure 3

Figure 4

Figure 5

Figure 6

Figure 7

Figure 8

Figure 9

Figure 10

Figure 11

Figure 12

Figure 13

Figure 14

Figure 15

Figure 16

Figure 17

Figure 18

[0010] Hereinafter, the present embodiment will be described with reference to the accompanying drawings. For ease of understanding the description, the same reference numerals are given to the same components in each drawing as much as possible, and redundant descriptions are omitted.

[0011] FIG. 1 is a diagram showing an example of the outline of the wireless communication system according to the present embodiment. As shown in FIG. 1, the wireless communication system 1 may include a terminal 10, a base station 20, and a core network 30. Note that the numbers of the terminal 10 and the base station 20 shown in FIG. 1 are merely examples and are not limited to the illustrated numbers.

[0012] As the radio access technology (RAT) of the wireless communication system 1, for example, NR is assumed, but it is not limited thereto, and various RATs such as RATs after the sixth generation can be used.

[0013] The terminal 10 is a predetermined terminal or device such as, for example, a smartphone, a personal computer, an in-vehicle terminal, an in-vehicle device, a stationary device, a telematics control unit (TCU), etc. The terminal 10 may be referred to as a user equipment (UE), a mobile station (MS), a user terminal, a radio apparatus, a subscriber terminal, an access terminal, etc. The terminal 10 may be mobile or fixed. The terminal 10 is configured to be communicable using, for example, NR as a RAT.

[0014] The base station 20 forms one or more cells C and communicates with the terminal 10 using the cell. The cell C may be mutually paraphrased as a serving cell, a carrier, a component carrier (CC), etc. For example, the base station 20 may set and communicate with the terminal 10 one primary cell and one or more secondary cells (also referred to as carrier aggregation). That is, one or more cells C include at least a primary cell and may include a secondary cell.

[0015] Also, one or more bandwidth parts (BWPs) may be set for one cell C. Here, the BWP mainly used when the terminal 10 makes an initial access to the cell is also referred to as an initial downlink (DL) BWP and an initial uplink (UL) BWP. For example, the base station 20 may include in the system information information used to set the frequency position, bandwidth, subcarrier spacing, and / or cyclic prefix for each of the initial downlink BWP and the initial uplink BWP and notify it.

[0016] The base station 20 may be referred to as a gNodeB (gNB), en-gNB, Next Generation-Radio Access Network (NG-RAN) node, low-power node, Central Unit (CU), Distributed Unit (DU), gNB-DU, Remote Radio Head (RRH), Integrated Access and Backhaul / Backhauling (IAB) node, etc. The base station 20 is not limited to a single node and may be composed of a plurality of nodes (for example, a combination of a lower node such as a DU and an upper node such as a CU).

[0017] The core network 30 is, for example, a core network (5G Core Network: 5GC) corresponding to NR, but is not limited thereto. Devices on the core network 30 (hereinafter, also referred to as "core network devices") perform mobility management such as paging and location registration of the terminal 10. The core network device may be connected to the base station 20 via a predetermined interface (for example, an S1 or NG interface).

[0018] The core network device may include, for example, at least one of an Access and Mobility Management Function (AMF) that manages C-plane information (for example, information related to access and mobility management, etc.) and a User Plane Function (UPF) that performs transmission control of U-plane information (for example, user data).

[0019] In the wireless communication system 1, the terminal 10 receives a downlink (DL) signal from the base station 20 and / or transmits an uplink (UL) signal to the base station 20. One or more cells C are configured for the terminal 10, and at least one of the configured cells is activated. The maximum bandwidth of each cell is, for example, 20 MHz or 400 MHz, etc.

[0020] Also, the terminal 10 performs cell search based on synchronization signals (e.g., Primary Synchronization Signal (PSS) and / or Secondary Synchronization Signal (SSS)) from the base station 20. Cell search is a procedure in which the terminal 10 acquires time and frequency synchronization in a cell and detects an identifier of the cell (e.g., physical layer cell ID).

[0021] A block including at least one of the above synchronization signal, Physical Broadcast Channel (PBCH), and Demodulation Reference Signal (DMRS) for PBCH demodulation is also called a Synchronization Signal Block (SSB), an SS / PBCH block, etc. One or more SSBs may constitute one SS burst, and one or more SS bursts may constitute one SS burst set. The SS burst set may be transmitted at a predetermined period (e.g., 20 ms (2 radio frames)). In the case of multi-beam operation, SSBs with different indexes may correspond to different beams and may be transmitted by sequentially switching the beam direction by beam sweeping.

[0022] The terminal 10 determines a search space set and / or a Control Resource Set (CORESET) based on parameters (hereinafter referred to as "RRC parameters") included in the RRC message, and monitors downlink control information (DCI) transmitted via the Physical Downlink Control Channel (PDCCH) within the search space set associated with the CORESET. Note that the RRC message may include, for example, an RRC setup message, an RRC reconfiguration message, an RRC resume message, system information, etc.

[0023] Monitoring of DCI means that the terminal 10 blindly decodes PDCCH candidates in the search space set in the assumed DCI format. The number of bits of the DCI format (also referred to as the size, bit width, etc.) is predetermined or derived according to the number of bits of the fields included in the DCI format. The terminal 10 detects the DCI for the terminal 10 based on the number of bits of the DCI format and a specific radio network temporary identifier (RNTI) used for scrambling the cyclic redundancy check (CRC) bits (also referred to as CRC parity bits) of the DCI format (hereinafter referred to as "CRC scrambling"). Monitoring of DCI is also called PDCCH monitoring, monitoring, etc. In addition, the period for performing DCI monitoring is also called a PDCCH monitoring occasion.

[0024] A search space set is a set of one or more search spaces, and may include a search space set (hereinafter referred to as a "Common search space (CSS) set") that is commonly used by one or more terminals 10, and a UE-specific search space (USS) set specific to a terminal. The search space set used for PDCCH monitoring of the terminal 10 may be set for the terminal 10 using upper layer parameters (for example, RRC Information Element (IE) "SearchSpace", RRC IE "pagingSearchSpace", RRC IE "searchSpaceSIB1", RRC IE "searchSpaceOtherSystemInformation", etc.). The terminal 10 detects DCI scrambled by an RNTI through PDCCH monitoring using the search space set, and controls reception of a Physical Downlink Shared Channel (PDSCH) scheduled using the DCI and / or transmission of a Physical Uplink Shared Channel (PUSCH).

[0025] The system information broadcast in cell C may include a Master Information Block (MIB) and / or one or more System Information Blocks (SIBs). The MIB is broadcast via the PBCH. The MIB and SIB1 are also called Minimum System Information, and SIB1 is also called Remaining Minimum System Information (RMSI). SIB1 is broadcast via the PDSCH. SIBx other than SIB1 (where x is any string such as 2, 3, … etc.) is also called Other System Information (OSI). SIB1 is cell-specific, and SIBx other than SIB1 is cell-specific or area-specific including one or more cells. The area is also called a system information area etc.

[0026] In the radio communication system 1, the terminal 10 transitions between a plurality of states (for example, an idle state, a non-active state, and a connected state) regarding the connection of the RRC layer (hereinafter referred to as the “RRC connection”).

[0027] Here, the idle state is a state in which the RRC connection between the terminal 10 and the base station 20 is not established, and is also called RRC_IDLE, idle mode, RRC idle mode, etc. The terminal 10 in the idle state receives the system information broadcast in the cell C where it camps. When the RRC connection of the terminal 10 in the idle state is (re)established, it transitions to the connected state. Note that when the terminal 10 in the idle state receives a message for establishing the RRC connection (hereinafter referred to as the “RRC setup message”, for example, “RRCSetup”) from the base station 20, the RRC connection is established. Also, when the terminal 10 receives a message for reestablishing the RRC connection (hereinafter referred to as the “RRC reestablishment message”, for example, “RRCReestablishment”) from the base station 20, the RRC connection is reestablished.

[0028] Also, the non-active state is a state in which the above RRC connection is established but suspended, and is also called the RRC_INACTIVE state, non-active mode, RRC non-active mode, etc. The terminal 10 in the non-active state receives the system information notified by the cell C on which it camps. When the RRC connection of the terminal 10 in the non-active state is resumed, it transitions to the connected state, and when the RRC connection is released, it transitions to the idle state. Note that when the terminal 10 in the non-active state receives an "RRC setup message" or a "message for resuming the RRC connection" (hereinafter referred to as the "RRC resume message", for example, "RRCResume") from the base station 20, the RRC connection is resumed.

[0029] The connected state is a state in which the above RRC connection is established, and is also called the RRC_CONNECTED state, connected mode, RRC connected mode, etc. When the RRC connection of the terminal 10 in the connected state is released, it transitions to the idle state, and when the RRC connection is suspended, it transitions to the non-active state. Note that when the terminal 10 in the connected state receives a "message for releasing the RRC connection" (hereinafter referred to as the "RRC release message", for example, "RRCRelease") from the base station 20, the RRC connection is released. Also, when the terminal 10 in the connected state receives a "message for reconfiguring the RRC connection" (hereinafter referred to as the "RRC reconfiguration message", for example, "RRCReconfiguration") from the base station 20, the RRC connection is updated (modified).

[0030] (Random access procedure) As random access procedures in the wireless communication system 1, contention based random access (CBRA) and contention free random access (CFRA) may be supported.

[0031] CBRA is a random access procedure implemented using a random access preamble randomly selected by the terminal 10, and collisions may occur between terminals 10 using the same random access preamble. On the other hand, CFRA is a random access procedure implemented using a random access preamble assigned by the base station 20, and collisions between terminals 10 do not occur. When a random access preamble is assigned to the terminal 10 using PDCCH, CFRA is also called a random access procedure initiated by a PDCCH order.

[0032] Also, two types are supported for CBRA and CFRA respectively. The first type is called type 1, type 1 random access procedure, 4-step RACH, or 4-step random access, etc. The second type is called type 2, type 2 random access procedure, 2-step RACH, or 2-step random access, etc.

[0033] Figures 2(A) and (B) are diagrams showing an example of type 1 CBRA and CFRA. As shown in Figure 2(A), in type 1 CBRA, in step S11, the terminal 10 transmits a random access preamble to the base station 20 via the Physical Random Access Channel (PRACH). The random access preamble may also be referred to as message 1, PRACH, RACH or RACH preamble, sequence or preamble, etc.

[0034] In step S12, the terminal 10 receives, via the PDSCH, a response message for the above-mentioned random access preamble (hereinafter referred to as "Random Access Response (RAR)"). The RAR may also be referred to as Message 2, MAC RAR, etc. The RAR may include, for example, information regarding scheduling of the PUSCH (hereinafter referred to as "UL grant"), an uplink timing correction value (hereinafter referred to as "Timing Advanced (TA) command"), and / or an identifier of the terminal 10. The identifier of the terminal 10 may be a temporary identifier (also referred to as "Temporary Cell (TC)-RNTI") or a Cell(C)-RNTI which is the identifier of the terminal 10 in cell C. The UL grant in the RAR is also referred to as "RAR UL grant".

[0035] In step S13, the terminal 10 transmits, via the PUSCH scheduled by the UL grant in the above RAR, a message (hereinafter referred to as "RRC setup request") for requesting establishment of an RRC connection. The RRC setup request may also be referred to as Message (Message:MSG) 3, MSG3 PUSCH, or "RRCSetupRequest", etc. Note that the establishment of the RRC connection may also be referred to as the establishment of a Signaling Radio Bearer (SRB). The RRC setup request may include an identifier of the terminal 10 (for example, the above TC-RNTI or C-RNTI).

[0036] In step S14, the terminal 10 receives, via the PDSCH, a message for setting up an RRC connection (hereinafter referred to as "RRC setup") in response to the above RRC setup request. The RRC setup may also be referred to as message 4, a contention resolution message, or "RRCSetup", etc. The DCI used for scheduling the PDSCH is CRC scrambled by the identifier of the terminal 10 in step S13 (for example, the above TC-RNTI or C-RNTI), and the collision may be resolved by detecting the DCI. As described above, type 1 CBRA is implemented in four steps: steps S11, S12, S13, and S14 shown in FIG. 2(A).

[0037] On the other hand, as shown in FIG. 2(B), in type 1 CFRA, in step S21, the terminal 10 monitors the search space set configured for the terminal 10 to detect a DCI (for example, DCI format 1_0) that is CRC scrambled by the identifier of the terminal 10 (for example, C-RNTI). When a specific field (for example, the frequency domain allocation field) of the DCI has a specific value (for example, all "1"), the terminal 10 may determine that the DCI is for a random access procedure started by a PDCCH order.

[0038] In step S22, when the terminal 10 determines that the DCI received in step S21 is for a random access procedure started by a PDCCH order, the terminal 10 transmits, using the PRACH, a random access preamble specified by the value of a predetermined field (for example, the random access preamble index field) in the DCI.

[0039] In step S23, the terminal 10 receives, via the PDSCH, an RAR for the above random access preamble. As described above, type 1 CFRA is implemented in two steps: steps S21 and S22 shown in FIG. 2(B).

[0040] Figures 3(A) and (B) are diagrams showing an example of Type 2 CBRA and CFRA. As shown in Figure 3(A), in the Type 2 CBRA, steps S11 and S13 in the Type 1 CBRA of Figure 2(A) are integrated into a single step S31 (step A), and steps S12 and S14 are integrated into a single step S32 (step B).

[0041] As shown in Figure 3(A), in the Type 2 CBRA, in step S31, the terminal 10 selects a random access preamble from among a plurality of random access preambles, transmits the selected random access preamble via the PRACH, and transmits the PUSCH. The random access preamble and the PUSCH are also called Message A, and step S31 is also called step A.

[0042] In step S32, the terminal 10 transmits Message B corresponding to Message A. Message B corresponds to the above RAR and collision resolution message, and may include, for example, a TA (Timing Adjustment) command and / or an identifier of the terminal 10 (for example, TC-RNTI or C-RNTI). The terminal 10 monitors a DCI (for example, DCI format 1_0) scrambled with a specific RNTI (for example, MsgB-RNTI) by CRC. The terminal 10 detects the DCI, and when the DCI satisfies a predetermined condition, receives a transport block via the PDSCH scheduled by the DCI.

[0043] On the one hand, as shown in FIG. 3(B), in Type 2 CFRA, in step S41, the terminal 10 detects DCI (e.g., DCI format 1_0) scrambled by the CRC with the identifier of the terminal 10 (e.g., TC-RNTI or C-RNTI) by monitoring the search space set configured for the terminal 10. If a specific field of the DCI (e.g., the frequency domain allocation field) has a specific value (e.g., all "1"), the terminal 10 may determine that the DCI is for a random access procedure initiated by the PDCCH order.

[0044] [[ID=·3]] As shown in FIG. 3(B), in step S42, the terminal 10 is different from step S31 in FIG. 3(A) in that the terminal 10 transmits the random access preamble specified based on the DCI received in step S41 via the PRACH. Step S42 in FIG. 3(B) is the same as step S32 in FIG. 3(A).

[0045] FIG. 4 is a diagram showing an example of fallback from Type 2 CBRA to Type 1. Step S51 in FIG. 4 is the same as step S31 in FIG. 3(A). In step S52 of FIG. 4, the base station 20 transmits a response message to the message A in step S51 (hereinafter referred to as "fallback RAR"). The fallback RAR may include, for example, information indicating the random access preamble index transmitted in step S51 (Random Access Preamble ID field), UL grant, TA command, and / or the identifier of the terminal 10 (e.g., TC-RNTI or C-RNTI). Steps S53 and S54 in FIG. 4 are the same as steps S13 and S14 in FIG. 2(A).

[0046] (Waveform) The waveform of the signal transmitted and received in the wireless communication system 1 may be CP-OFDM or DFT-s-OFDM. For example, for the uplink signal (e.g., PUSCH and / or Phase-Tracking-Reference-Signals (PTRS)), either CP-OFDM or DFT-s-OFDM may be used. On the other hand, for the downlink signal (e.g., PDSCH) and the signal from another terminal 10 (hereinafter referred to as the "sidelink signal", e.g., Physical Sidelink Shared Channel (PSSCH)), CP-OFDM may be used. Note that the sidelink is direct communication between terminals 10.

[0047] Since CP-OFDM is a multi-carrier waveform, it has the advantage of being resistant to multipath interference, but has the disadvantage of an increasing Peak to Average Power Ratio (PAPR). Also, since CP-OFDM is a multi-carrier waveform, the transmitted data sequence and the reference signal (RS) can be frequency-division multiplexed on different sub-carriers of the same symbol. Also, the transmission band of the transmitted signal of CP-OFDM is not limited to a continuous frequency band (e.g., one or more consecutive Physical Resource Blocks (PRBs)), and may be composed of a discontinuous frequency band (e.g., a plurality of discontinuous PRBs). Therefore, compared with DFT-s-OFDM, there are fewer scheduling constraints. For this reason, for example, in a cell where the load is higher than a predetermined level, the frequency utilization efficiency can be improved by using CP-OFDM.

[0048] Since DFT-s-OFDM is a single-carrier waveform, it can reduce PAPR more than CP-OFDM. Therefore, power close to the maximum rated power can be utilized, and higher-order modulation schemes and / or higher coding rates can be used. As a result, the power consumption of the terminal 10 and / or the cost of the terminal 10 can be reduced. Also, it becomes easier to secure a coverage area. On the other hand, in DFT-s-OFDM, the transmission data sequence and RS of a certain terminal 10 are time-division multiplexed into different symbols. That is, the transmission data sequence and RS of a certain terminal 10 are not frequency-division multiplexed into different subcarriers of the same symbol, which is different from CP-OFDM. Also, the transmission band of the transmission signal of DFT-s-OFDM is limited to a continuous frequency band (for example, one or more consecutive PRBs).

[0049] FIG. 5(A) and (B) are diagrams showing an example of transmission blocks of DFT-s-OFDM and CP-OFDM according to the present embodiment, respectively. As shown in FIG. 5(A), DFT-s-OFDM is different from CP-OFDM shown in FIG. 5(B) in that it includes a function for performing DFT spreading (hereinafter referred to as "transform precoder"). That is, DFT-s-OFDM is CP-OFDM to which a transform precoder is applied. Note that the transform precoder may be referred to as transform precoding, DFT precoder, or DFT precoding, etc.

[0050] As shown in FIG. 5(A), in DFT-s-OFDM, the transmitted data sequence or RS after encoding and modulation is input to an M-point DFT and is converted from the time domain to the frequency domain. The output from the DFT is mapped to M subcarriers, input to an N-point Inverse Fast Fourier Transform (IFFT), and is converted from the frequency domain to the time domain. Note that the DFT may be replaced with a Fast Fourier Transform (FFT), and the IFFT may be replaced with an Inverse Discrete Fourier Transform (IDFT).

[0051] Here, N > M, and the input information to the unused IFFT is set to zero. N may be equal to the number of subcarriers corresponding to a predetermined frequency bandwidth (e.g., the bandwidth of a BWP or cell C). M may be the number of subcarriers corresponding to the transmission bandwidth. Thereby, the output of the IFFT becomes a signal with small instantaneous power fluctuations and a bandwidth that depends on M. The output from the IFFT is subjected to a Parallel to Serial (P / S) conversion, and a Cyclic Prefix (CP) is added. The CP is also called a Guard Interval (GI). Thus, in DFT-s-OFDM, a signal having single-carrier characteristics is generated and transmitted in one symbol. Note that the CP may be inserted before the P / S conversion for the output from the IFFT.

[0052] As shown in FIG. 5(B), in CP-OFDM, the transmitted data sequence and / or RS after encoding and modulation are mapped to a number of subcarriers equal to the transmission bandwidth and input to the IFFT. The input information to the unused IFFT is set to zero. The output from the IFFT is subjected to a P / S conversion, and a CP is inserted. Thus, in CP-OFDM, since multi-carriers are used, the RS and the transmitted data sequence can be frequency-division multiplexed. Of course, it is also possible to transmit the transmitted data sequence without frequency-division multiplexing with the RS.

[0053] As described above, since the characteristics of DFT-s-OFDM and CP-OFDM are in a trade-off relationship, it is desirable to switch between DFT-s-OFDM and CP-OFDM according to various parameters (such as cell load, scheduling situation, antenna state, etc.). Note that DFT-s-OFDM and CP-OFDM can be switched by whether or not to apply a transform precoder, as described in FIGS. 5(A) and (B).

[0054] By the way, it is assumed that the switching between DFT-s-OFDM and CP-OFDM is performed using RRC signaling. For example, in Releases 15 and 16 of 3GPP, at least one of SIB1, RRC setup message, RRC reestablishment message, RRC resume message, and RRC reconfiguration message includes an RRC parameter related to the transform precoder (for example, at least one of RRC IEs "transformPrecoder", "msg3-transformPrecoder", "transformPrecoderDisabled", and "transformPrecoderEnabled") to switch the waveform of the uplink signal (for example, PUSCH and / or PTRS) between DFT-s-OFDM and CP-OFDM.

[0055] Thus, in Releases 15 and 16, it is mainly assumed that the waveform of the uplink signal is switched using an RRC message transmitted from the base station 20 to the terminal 10 when transitioning from the idle state or the inactive state to the connected state in the initial access. In Releases 15 and 16, when switching the waveform of the uplink signal of the terminal 10 that is already in the connected state, an RRC reconfiguration message transmitted from the base station 20 to the terminal 10 is used. However, when using RRC signaling, compared with the case of using signaling of a layer lower than the RRC layer, the processing delay (for example, several tens of msec) from receiving the RRC signaling to applying the received parameters is long, and the signaling amount is also large. Therefore, there is a risk that the waveform of the uplink signal cannot be switched at an appropriate timing according to the radio situation.

[0056] Therefore, in the present embodiment, by including information on the transform precoder for the uplink signal (hereinafter referred to as "transform precoder information") in signaling lower than the RRC signaling (for example, physical layer signaling or MAC signaling), the network switches the waveform of the uplink signal at a flexible timing determined by the network. Specifically, operations related to switching the waveform of the uplink signal based on the transform precoder information included in the DCI (the first switching operation) and operations related to switching the waveform of the uplink signal based on the transform precoder information of the MAC control element (MAC CE) (the second switching operation) will be described.

[0057] Here, the transform precoder information may be, for example, information indicating whether to apply the transform precoder to the uplink signal (hereinafter, "transform precoder identifier (Transform Precoder Indicator: TPI)"). Note that whether to apply the transform precoder may be rephrased as whether to enable or activate the transform precoder, etc. Hereinafter, TPI will be described as an example of the transform precoder information, but the transform precoder information is not limited to this. The TPI in the following may be rephrased as any information regarding the transform precoder.

[0058] Also, the uplink signal whose waveform is determined based on the TPI is, for example, at least one of PUSCH and uplink PTRS. Hereinafter, the switching of the waveform of PUSCH will be described, but it is not limited to this, and the waveform switching of the present embodiment may be applied to uplink signals other than PUSCH (for example, PTRS, etc.). Also, the waveform switching of the present embodiment is not limited to uplink signals, and may be applied to other signals (for example, sidelink signals, etc.).

[0059] (First switching operation) In the first switching operation, the terminal 10 determines whether to apply the transform precoder to the PUSCH based on the TPI in the DCI. That is, the terminal 10 determines which waveform of DFT-s-OFDM (applying the transform precoder) or CP-OFDM (not applying the transform precoder) to apply to the PUSCH based on the TPI in the DCI.

[0060] Hereinafter, as an example of DCI including TPI, DCI used for the random access procedure of PDCCH order (for example, DCI format 1_0), that is, DCI including information on the random access preamble (hereinafter referred to as "random access preamble information") will be described, but it is not limited thereto. The DCI including TPI may be DCI used for scheduling PUSCH (for example, DCI format 0_x (x = 0, 1,...), also referred to as UL grant or uplink grant), or other DCI (for example, DCI format 2_x (x = 0, 1,...)).

[0061] FIG. 6 is a diagram showing an example of DCI including TPI according to the present embodiment. In FIG. 6, DCI for the random access procedure started by the PDCCH order is shown. The terminal 10 may determine whether the DCI is for the random access procedure started by the PDCCH order based on the value of a specific field of the DCI. Further, when a specific field in the DCI is a predetermined value, the terminal 10 may determine that the TPI field is included in a field other than the specific field in the DCI.

[0062] For example, in FIG. 6, when all bits of the frequency domain resource allocation field of DCI format 1_0 are "1", the terminal 10 determines that the DCI format 1_0 is for the random access procedure started by the PDCCH order. That is, when all bits of the frequency domain resource allocation field of DCI format 1_0 are "1", the terminal 10 determines that the remaining bits are the random access preamble index field, Uplink / Supplementary Uplink (IL / SUL) identifier field, SS / PBCH field, TPI field, and reserved bits. Note that at least one field other than the TPI field shown in FIG. 6 may be omitted or reserved.

[0063] The value of the random access preamble index field indicates random access preamble information (e.g., a random access preamble index). The terminal 10 transmits a random access preamble determined based on the random access preamble information in the CFRA.

[0064] The value of the UL / SUL identifier field indicates whether the uplink carrier for transmitting the PRACH (i.e., the random access preamble) is the SUL or the normal UL when the SUL is set. Note that the SUL is an uplink carrier without a corresponding downlink carrier.

[0065] The value of the SS / PBCH index field indicates the SS / PBCH for determining the time domain and / or frequency domain resources (hereinafter referred to as "RACH opportunity") of the PRACH (i.e., the random access preamble). Each RACH opportunity is associated with at least one SS / PBCH. The value of the PRACH mask field indicates the RACH opportunity associated with the above SS / PBCH.

[0066] The value of the TPI field indicates whether to apply a transform precoder. For example, the TPI value "0" may indicate that the transform precoder is not applied to the uplink signal (i.e., disabled), and the TPI value "1" may indicate that the transform precoder is applied to the uplink signal (i.e., enabled). In the case of type 1 CFRA, the TPI value "1" indicates that the transform precoder is enabled when the random access procedure started by the PDCCH order is completed (i.e., when the RAR is received), and the TPI value "0" may indicate that the transform precoder is disabled when the random access procedure started by the PDCCH order is completed. In the case of type 2 CFRA, the TPI value "1" indicates that the transform precoder is enabled from the PUSCH in message A, and the TPI value "0" may indicate that the transform precoder is disabled from the PUSCH in message A.

[0067] <First Example> In the first example, when type 1 CFRA is started by DCI of a PDCCH order, the terminal 10 determines whether to apply a transform precoder to a PUSCH scheduled by a specific DCI (for example, DCI format (DF) 0_x (x = 0, 1, 2,...), also referred to as "UL grant") based on the TPI in the DCI of the PDCCH order.

[0068] Note that DF0_0 does not depend on the function set for the terminal 10 and may be used for scheduling the PUSCH of one cell. For example, when scheduling is performed during the execution of RRC reconfiguration, or when it is unknown at what timing the function and parameters of the terminal 10 are changed by RRC reconfiguration, DF0_0 may be used for scheduling the PUSCH. DF0_1 may be used for scheduling one or more PUSCHs of one cell, or may indicate downlink feedback information for a cell group for the terminal 10. DF0_1 may include a field of variable size according to the function set for the terminal 10. For example, when carrier aggregation is set for the terminal 10 and cross-carrier scheduling is performed, a carrier indicator field indicating the carrier on which the PUSCH is scheduled may be included. DF0_2 is DCI for Ultra-Reliable and Low Latency Communications (URLLC) and may be used for scheduling the PUSCH of one cell. DF0_2 may be smaller in size than DF0_1.

[0069] FIG. 7 is a diagram showing a first example of the first switching operation according to the present embodiment. In FIG. 7, the waveform of the PUSCH is switched using type 1 CFRA started by DCI of the PDCCH order. In FIG. 7, the terminal 10 is in the connected state, and it is assumed that RRC parameters (for example, "msg3-transformPrecoder" in the RRC IE or "transformPrecoder" in the RRC IE "pusch-Config") regarding the application of the transform precoder to message 3 or the PUSCH are set.

[0070] As shown in FIG. 7, in step S101, the terminal 10 detects DCI (for example, DCI format (DF) 0_x) scrambled by a specific RNTI by monitoring the PDCCH. The specific RNTI may be, for example, Configured Scheduling RNTI (CS-RNTI), Cell RNTI (C-RNTI), Modulation and Coding Scheme-C-RNTI (MCS-C-RNTI), or Semi-Persistent Channel State Information RNTI (SP-CSI-RNTI). The CS-RNTI is an identifier of the terminal 10 for a configured grant, and the New Data Indicator (NDI) in the DCI scrambled by the CS-RNTI may be 1. The DF0_x scrambled by the CS-RNTI and having NDI = 1 may be regarded as DCI for dynamically scheduling the PUSCH (that is, a dynamic uplink grant). On the other hand, the DF0_x scrambled by the CS-RNTI and having NDI = 0 may be regarded as a configured grant. The C-RNTI is used as an identifier of the RRC connection and may be an identifier of the terminal 10 for scheduling. The MCS-C-RNTI may be an identifier of the terminal 10 used to indicate an alternative MCS table for the PDSCH and PUSCH. The SP-CSI-RNTI may be an identifier of the terminal 10 used for reporting semi-persistent channel state information (SP-CSI) on the PUSCH.

[0071] In step S102, the terminal 10 determines whether to apply a transform precoder to the PUSCH scheduled using the DCI in step S101 based on the RRC parameters related to the configured transform precoder (for example, the "transformPrecoder" in the RRC IE "msg3-transformPrecoder" or the RRC IE "pusch-Config"). In FIG. 7, for example, since the "transformPrecoder" in the RRC IE "msg3-transformPrecoder" or the RRC IE "pusch-Config" is set to enable, the terminal 10 applies the transform precoder (that is, uses DFT-s-OFDM) to transmit the PUSCH.

[0072] In step S103, a random access procedure of the PDCCH order is started, and the terminal 10 detects a DCI (for example, DCI format 1_0) that is CRC scrambled by a specific RNTI (for example, C-RNTI) and in which a specific field (for example, the frequency domain resource allocation field) is set to a specific value (for example, all 1s). As shown in FIG. 6, the DCI may include a random access preamble index and a TPI. In step S104, the terminal 10 transmits, via the PRACH, a random access preamble determined based on the random access preamble field value in the DCI.

[0073] In step S105, the terminal 10 detects a DCI (for example, DCI format 1_0) that is CRC scrambled by a specific RNTI (for example, Random Access RNTI (RA-RNTI)) by monitoring the PDCCH. In step S106, the terminal 10 receives a random access response via the PDSCH scheduled using the DCI. The reception of the random access response completes the type 1 CFRA.

[0074] In step S107, the terminal 10 detects DCI (e.g., DCI format 0_x) scrambled by a specific RNTI (e.g., CS-RNTI, C-RNTI, MCS-C-RNTI, or SP-CSI-RNTI) through monitoring of the PDCCH after completion of the CFRA of type 1. In step S108, the terminal 10 determines whether to apply a transform precoder to the PUSCH scheduled using the DCI in step S107 based on the TPI in the detected DCI instead of a preset RRC parameter (e.g., the RRC IE "msg3-transformPrecoder"). In FIG. 7, for example, since TPI = 0, the terminal 10 transmits the PUSCH without applying a transform precoder (i.e., using CP-OFDM).

[0075] As described above, for example, in FIG. 7, for PUSCH transmission scheduled by a PDCCH scrambled by a specific RNTI (e.g., CS-RNTI, C-RNTI, MCS-C-RNTI, or SP-CSI-RNTI with NDI = 1): - If a DCI with a scheduling grant is received in DCI format 0_0, - If the transform precoder is enabled or disabled by receiving the TPI via DCI format 1_0, the terminal 10 may determine whether to enable or disable transform precoding for the PUSCH transmission according to the TPI. - If the TPI is not received via DCI format 1_0, the terminal 10 may determine whether to enable or disable transform precoding for the PUSCH transmission according to an RRC parameter (e.g., the RRC IE "msg3-transformPrecoder"). - If a DCI with a scheduling grant is not received in DCI format 0_0 (e.g., received in DCI format 0_1 or DCI format 0_2), If the transform precoder is enabled or disabled by receiving TPI via DCI format 1_0, the terminal 10 may determine whether to enable or disable transform precoding for the PUSCH transmission according to the TPI. If TPI is not received via DCI format 1_0 and an RRC parameter (e.g., RRC IE "transformPrecoder") regarding the transform precoder is set in the PUSCH configuration information (e.g., RRC IE "pusch-Config"), the terminal 10 may determine whether to enable or disable the transform precoder for the PUSCH transmission according to the RRC parameter. If TPI is not received via DCI format 1_0 and an RRC parameter (e.g., RRC IE "transformPrecoder") regarding the transform precoder is not set in the PUSCH configuration information (e.g., RRC IE "pusch-Config"), the terminal 10 may determine whether to enable or disable the transform precoder for the PUSCH transmission according to other RRC parameters (e.g., RRC IE "msg3-transformPrecoder") regarding the transform precoder.

[0076] <Second Example> In the second example, when type 1 CFRA is started by DCI of the PDCCH order, the terminal 10 determines whether to apply the transform precoder to the PUSCH based on the configured grant according to the TPI in the DCI of the PDCCH order.

[0077] Here, a configured grant is persistent or semi-persistent scheduling information based on RRC parameters (e.g., the RRC IE "ConfiguredGrantConfig"). In a type 1 configured grant, a PUSCH with a predetermined period is scheduled based on RRC parameters (e.g., the UL grant "rrc-ConfiguredUplinkGrant" in the RRC IE "ConfiguredGrantConfig") without using DCI. In a type 2 configured grant, a PUSCH with a predetermined period based on RRC parameters (e.g., the RRC IE "ConfiguredGrantConfig" excluding the UL grant "rrc-ConfiguredUplinkGrant") is activated using DCI.

[0078] FIG. 8 is a diagram showing a second example of the first switching operation according to the present embodiment. FIG. 8 is different from FIG. 7 in that a PUSCH is transmitted at a predetermined period based on a configured grant. Hereinafter, the description will focus on the differences from FIG. 7. In FIG. 8, the terminal 10 is in a connected state, and it is assumed that RRC parameters (e.g., the RRC IE "msg3-transformPrecoder" or the "transformPrecoder" in the RRC IE "ConfiguredGrantConfig") regarding the application of the transform precoder of the PUSCH based on message 3 or the configured grant are set.

[0079] In step S201, the terminal 10 determines whether to apply a transform precoder to the PUSCH with a predetermined period based on the configured grant, based on the above RRC parameters regarding the application of the transform precoder. In FIG. 8, for example, since the RRC IE "msg3-transformPrecoder" or the "transformPrecoder" in the RRC IE "ConfiguredGrantConfig" is set to enable, the terminal 10 applies the transform precoder (i.e., uses DFT-s-OFDM) to transmit the PUSCH at a predetermined period.

[0080] Steps S202 to S205 are the same as steps S103 to S106 in FIG. 7. In step S206, the terminal 10 determines whether to apply a transform precoder to the PUSCH with a predetermined period based on the configured grant, based on the TPI in the DCI detected in step S202, rather than the above configured RRC parameters. In FIG. 8, for example, since TPI = 0, the terminal 10 transmits the PUSCH without applying the transform precoder (i.e., using CP-OFDM).

[0081] As described above, for example, in FIG. 8, for PUSCH transmission with a configured grant: - If the transform precoder is enabled or disabled by receiving the TPI via DCI format 1_0, the terminal 10 may determine whether to enable or disable the transform precoding for the PUSCH transmission according to the TPI. - If the TPI is not received via DCI format 1_0 and the RRC parameter regarding the transform precoder (e.g., the RRC IE "transformPrecoder") is set in the RRC parameter regarding the configured grant (e.g., the RRC IE "configuredGrantConfig"), the terminal 10 may determine whether to enable or disable the transform precoder for the PUSCH transmission according to the RRC parameter. - If TPI is not received via DCI format 1_0 and the RRC parameter related to the transform precoder (e.g., RRC IE "transformPrecoder") is not set within the RRC parameters related to the configured grant (e.g., RRC IE "configuredGrantConfig"), the terminal 10 may determine whether to enable or disable the transform precoder for the PUSCH transmission according to the RRC parameter related to the transform precoder in message 3 (e.g., RRC IE "msg3-transformPrecoder").

[0082] <The third example> In the third example, when type 2 CFRA is started by the DCI of the PDCCH order, the terminal 10 determines whether to apply the transform precoder to the PUSCH as message A based on the TPI in the DCI of the PDCCH order.

[0083] FIG. 9 is a diagram showing a third example of the first switching operation according to the present embodiment. FIG. 9 is different from FIGS. 7 and 8 in that the waveform of the PUSCH is switched using type 2 CFRA started by the DCI of the PDCCH order. Hereinafter, the differences from FIG. 7 will be mainly described. In FIG. 9, the terminal 10 is in the connected state, and it is assumed that the RRC parameters related to the application of the transform precoder in message A or message 3 (e.g., RRC IE "msgA-TransformPrecoder" or RRC IE "msg3-transformPrecoder" or) are set.

[0084] Steps S301 to S303 are the same as steps S101 to S103 in FIG. 7. In step S304, the terminal 10 transmits the PRACH and PUSCH as message A. Specifically, the terminal 10 transmits the random access preamble determined based on the DCI in step S303 via the PRACH, and transmits the PUSCH based on the RRC parameters (for example, the RRC IE "MsgA-PUSCH-Config") regarding the setting of the PUSCH as message A. Also, the terminal 10 determines whether to apply a transform precoder to the PUSCH based on the TPI in the DCI detected in step S303. In FIG. 9, for example, since TPI = 0, the terminal 10 transmits the PUSCH without applying a transform precoder (that is, using CP-OFDM).

[0085] In step S305, the terminal 10 detects, by monitoring the PDCCH, a DCI (for example, DCI format 1_0) scrambled by a specific RNTI (for example, RA-RNTI). In step S306, the terminal 10 receives a random access response (message B) via the PDSCH scheduled using the DCI.

[0086] As described above, for example, in FIG. 9, for the PUSCH as message A: - If the transform precoder is enabled or disabled by receiving the TPI via DCI format 1_0, the terminal 10 may determine whether to enable or disable the transform precoding for the PUSCH transmission according to the TPI. - If TPI is not received via DCI format 1_0 and an RRC parameter regarding the application of the transform precoder for message A (e.g., RRC IE "msgA-TransformPrecoder") is set, terminal 10 may determine whether to activate or deactivate the transform precoder for the PUSCH transmission according to the RRC parameter. If the RRC parameter is not set, terminal 10 may determine whether to activate or deactivate the transform precoder for the PUSCH transmission according to the RRC parameter regarding the transform precoder for message 3 (e.g., RRC IE "msg3-transformPrecoder").

[0087] <Fourth example> In the fourth example, when type 1 or type 2 CFRA started by DCI of the PDCCH order fails, terminal 10 determines whether to apply the transform precoder to the PUSCH based on the RRC parameter regarding the application of the transform precoder or the application state of the transform precoder before the execution of the CFRA instead of the DCI of the PDCCH order. Here, the case where type 1 or type 2 CFRA fails means, for example, that a random access response cannot be received before a predetermined timer or window (e.g., ra-ResponseWindow) expires, and a retransmission of RACH is performed and it reaches the specified number of retransmissions (e.g., preambleTransMax).

[0088] FIG. 10 is a diagram showing a fourth example of the first switching operation according to the present embodiment. FIG. 10 mainly explains the differences from FIG. 7 when type 1 CFRA fails. The present embodiment can also be appropriately applied when type 1 CFRA fails as shown in FIG. 8 and when type 2 CFRA fails as shown in FIG. 9. Steps S401 to S404 and S405 in FIG. 10 are the same as steps S101 to S104 and S107 in FIG. 7.

[0089] As shown in FIG. 10, when the CFRA started by the DCI of the PDCCH order fails, in step S406, the terminal 10 determines whether to apply a transform precoder to the PUSCH based on the RRC parameter related to the application of the transform precoder (for example, "transformPrecoder" in the RRC IE "pusch-Config" or "configuredGrantConfig", RRC IE "msg3-transformPrecoder", or RRC IE "msgA-transformPrecoder"). In FIG. 10, for example, since the RRC parameter is set to enabled, the terminal 10 applies the transform precoder (that is, uses DFT-s-OFDM) to transmit the PUSCH.

[0090] As described above, for example, in FIG. 10, TPI is included in the DCI (for example, DCI format 1_0) that triggers the CFRA. If the CFRA fails, the terminal 10 may determine whether to enable or disable the transform precoder for the PUSCH transmission according to the above RRC parameter related to the application of the transform precoder (for example, "transformPrecoder" in the RRC IE "pusch-Config" or "configuredGrantConfig", RRC IE "msg3-transformPrecoder", or RRC IE "msgA-transformPrecoder").

[0091] <The Fifth Example> In the fifth example, in the type 2 CFRA started by the DCI of the PDCCH order, when the terminal 10 receives a fallback indication to type 1, the terminal 10 switches the waveform of the PUSCH based on a preset RRC parameter or the application state of the transform precoder before the execution of the CFRA instead of the DCI of the PDCCH order.

[0092] FIG. 11 is a diagram showing a fifth example of the first switching operation according to the present embodiment. FIG. 11 mainly describes the differences from FIG. 9 in the case of falling back to the random access procedure from type 2 to type 1. Steps S501 to S505 in FIG. 11 are the same as steps S301 to S305 in FIG. 9.

[0093] As shown in FIG. 11, in step S506, the terminal 10 receives a fallback random access response (fallback RAR) via the PDSCH scheduled by the DCI in step S505.

[0094] In step S507, the terminal 10 transmits a PUSCH (message 3) based on the UL grant (also referred to as "fallback RAR UL grant") in the fallback RAR in step S506. The terminal 10 determines whether to apply a transform precoder to the PUSCH based on an RRC parameter related to the application of the transform precoder (for example, "transformPrecoder" in the RRC IE "pusch-Config" or "configuredGrantConfig", RRC IE "msg3-transformPrecoder", or RRC IE "msgA-transformPrecoder") instead of the TPI in the DCI of the PDCCH order detected in step S503. In FIG. 11, for example, since the RRC parameter is set to enabled, the terminal 10 transmits the PUSCH by applying a transform precoder (that is, using DFT-s-OFDM).

[0095] In step S508, the terminal 10 detects a DCI (for example, DCI format 1_0) scrambled by a specific RNTI (for example, RA-RNTI) by monitoring the PDCCH. In step S509, the terminal 10 receives a collision resolution message (message 4) via the PDSCH scheduled by the DCI.

[0096] As described above, for example, in FIG. 11, if TPI is included in the DCI (e.g., DCI format 1_0) that triggers CFRA, type 2 CFRA is performed, and a fallback instruction to type 1 is received in message B, the terminal 10 may determine whether to enable or disable the transform precoder for PUSCH transmission according to the RRC parameter related to the application of the transform precoder (e.g., "transformPrecoder" in the RRC IE "pusch-Config" or "configuredGrantConfig", RRC IE "msg3-transformPrecoder", or RRC IE "msgA-transformPrecoder").

[0097] <Example 6> In the sixth example, the terminal 10 may determine whether to apply the transform precoder to the PUSCH scheduled by a specific DCI (e.g., DCI format 0_0) scrambled by a specific RNTI (e.g., TC-RNTI) based on the TPI in the DCI of the PDCCH order. Note that the PUSCH scheduled by the DCI format 0_0 scrambled by the TC-RNTI may be, for example, the PUSCH scheduled when the retransmission of message 3 is requested. Also, the terminal 10 may determine whether to apply the transform precoder to the PUSCH scheduled by the RAR UL grant based on the TPI in the DCI of the PDCCH order.

[0098] As described above, for example, for the PUSCH scheduled by the UL grant in the RAR, the PUSCH scheduled by the UL grant in the fallback RAR, or the PUSCH scheduled by the DCI format 0_0 scrambled by the TC-RNTI: If the transform precoder is enabled or disabled by receiving TPI via DCI format 1_0, the terminal 10 may determine whether to enable or disable transform precoding for the PUSCH transmission according to the TPI. If TPI is not received via DCI format 1_0, whether to enable or disable the transform precoder for the PUSCH transmission may be determined according to the RRC parameter related to the transform precoder in message 3 (for example, the RRC IE "msg3-transformPrecoder").

[0099] As described above, according to the first switching operation, since the DCI includes TPI, the terminal 10 can flexibly switch whether to apply the transform precoder at the appropriate timing determined by the network. For example, by including TPI in the DCI of the PDCCH order that triggers CFRA, the network side can flexibly switch the waveform of the PUSCH.

[0100] (The second switching operation) In the second switching operation, the terminal 10 determines whether to apply the transform precoder to the PUSCH based on the TPI in the MAC control element (MAC CE). That is, the terminal 10 determines which waveform of DFT-s-OFDM (applying the transform precoder) or CP-OFDM (not applying the transform precoder) to use for the PUSCH based on the TPI in the MAC CE. The second switching operation will be mainly described with differences from the first switching operation.

[0101] FIG. 12 is a diagram showing an example of a MAC CE including a TPI according to this embodiment. For example, the MAC CE shown in FIG. 12 includes an A / D field, a serving cell ID field, a BWP ID field, a SUL field, a TPI field, and a reserved bit. Note that at least one field other than the TPI field shown in FIG. 12 may be omitted or reserved. Note that the configuration of the MAC CE shown in FIG. 12 is merely an example, and the positions, the number of bits, etc. of the respective fields are not limited to those shown in the figure.

[0102] The A / D field is a field indicating whether to activate or deactivate a resource set for a semi-persistent zero power channel state information reference signal (SP-ZP-CSI-RS). For example, when the value of the field is "1", it may be indicated that the resource set is activated, and when the value of the field is "0", it may be indicated that the resource set is deactivated.

[0103] The serving cell ID field is a field indicating an identifier of the serving cell ID to which the MAC CE is applied. The field may be configured with a predetermined number of bits (for example, 5 bits). The BWP ID field is a field indicating the downlink BWP to which the MAC CE is applied. The downlink BWP may be indicated by a code point of a bandwidth part identifier field in DCI. The BWP ID field may be configured with a predetermined number of bits (for example, 2 bits).

[0104] The SUL field is a field indicating whether the MAC CE is applied to a normal uplink carrier (NUL) or SUL. When the value of the field is "1", it may be indicated that the MAC CE is applied to SUL, and when the value of the field is "0", it may be indicated that the MAC CE is applied to NUL.

[0105] The TPI field is a field indicating whether the transform precoder is enabled or disabled. If the value of this field is "1", it indicates that the transform precoder is to be enabled, and if the value of this field is "0", it may indicate that the transform precoder is to be disabled.

[0106] <First Example> In the first example, the terminal 10 determines whether to apply a transform precoder to the PUSCH scheduled by a specific DCI (e.g., DCI format 0_x) based on the TPI in the MAC CE.

[0107] FIG. 13 is a diagram showing a first example of a second switching operation according to the present embodiment. In FIG. 13, it is different from FIG. 7 in that the TPI is included not in the DCI of the PDCCH order that starts the type 1 CFRA but in the MAC CE. Hereinafter, the description will focus on the differences from FIG. 7. Steps S601 and S602 in FIG. 13 are the same as steps S101 and S102 in FIG. 7.

[0108] In step S603, the terminal 10 monitors the PDCCH to detect a DCI (e.g., DCI format 1_x (x = 1, 2, 3,...), also referred to as "DL assignment") scrambled by a specific RNTI (e.g., C-RNTI). In step S604, the terminal 10 receives a MAC CE including the TPI via the PDSCH scheduled by the DCI in step S603.

[0109] In step S605, the terminal 10 detects DCI (e.g., DCI format 0_x) scrambled by a CRC with a specific RNTI (e.g., CS-RNTI with NDI = 1, C-RNTI, MCS-C-RNTI, or SP-CSI-RNTI) by monitoring the PDCCH. In step S606, the terminal 10 determines whether to apply a transform precoder to the PUSCH scheduled using the DCI in step S605 based on the TPI in the MAC CE received in step S604, rather than the above RRC parameter regarding the transform precoder. In FIG. 13, for example, since TPI = 0 in the MAC CE, the terminal 10 transmits the PUSCH without applying a transform precoder (i.e., using CP-OFDM).

[0110] As described above, for example, in FIG. 13, for PUSCH transmission scheduled by a PDCCH scrambled by a CRC with a specific RNTI (e.g., CS-RNTI with NDI = 1, C-RNTI, MCS-C-RNTI, or SP-CSI-RNTI): - If DCI having a schedule grant is received in DCI format 0_0, - If the transform precoder is enabled or disabled by receiving a TPI via a MAC CE that activates or deactivates the transform precoder, the terminal 10 may determine whether to enable or disable transform precoding for the PUSCH transmission according to the TPI. - If the TPI is not received via the above MAC CE, the terminal 10 may determine whether to enable or disable transform precoding for the PUSCH transmission according to an RRC parameter (e.g., RRC IE “msg3-transformPrecoder”). - If DCI having a schedule grant is not received in DCI format 0_0 (e.g., if received in DCI format 0_1 or DCI format 0_2), - If the transform precoder is enabled or disabled by receiving a TPI via a MAC CE that activates or deactivates the transform precoder, the terminal 10 may determine whether to enable or disable transform precoding for the PUSCH transmission according to the TPI. - If the TPI is not received via the MAC CE and an RRC parameter (e.g., RRC IE "transformPrecoder") regarding the transform precoder is set in the PUSCH configuration information (e.g., RRC IE "pusch-Config"), the terminal 10 may determine whether to enable or disable the transform precoder for the PUSCH transmission according to the RRC parameter. - If the TPI is not received via the MAC CE and an RRC parameter (e.g., RRC IE "transformPrecoder") regarding the transform precoder is not set in the PUSCH configuration information (e.g., RRC IE "pusch-Config"), the terminal 10 may determine whether to enable or disable the transform precoder for the PUSCH transmission according to another RRC parameter (e.g., RRC IE "msg3-transformPrecoder") regarding the transform precoder.

[0111] <Second Example> In the second example, the terminal 10 determines whether to apply the transform precoder to the PUSCH based on the configured grant according to the TPI in the MAC CE.

[0112] FIG. 14 is a diagram showing a second example of the second switching operation according to the present embodiment. In FIG. 14, it is different from FIG. 8 in that the TPI is included not in the DCI of the PDCCH order that starts the type 1 CFRA but in the MAC CE. Hereinafter, the differences from FIGS. 8 and 13 will be mainly described. Step S701 in FIG. 14 is the same as step S201 in FIG. 8. Steps S702 and S703 in FIG. 14 are the same as steps S603 and S604 in FIG. 13.

[0113] In step S704, the terminal 10 determines whether to apply a transform precoder to the PUSCH based on the configured grant, based on the TPI in the MAC CE received in step S703, rather than the RRC parameters related to the transform precoder (for example, the RRC IE "msg3-transformPrecoder" or "transformPrecoder" in the RRC IE "ConfiguredGrantConfig"). In FIG. 14, for example, since the TPI in the MAC CE is 0, the terminal 10 transmits the PUSCH without applying the transform precoder (that is, using CP-OFDM).

[0114] As described above, for example, in FIG. 14, for PUSCH transmission with a configured grant: - If the transform precoder is enabled or disabled by receiving the TPI via the MAC CE that activates or deactivates the transform precoder, the terminal 10 may determine whether to enable or disable the transform precoding for the PUSCH transmission according to the TPI. - If the TPI is not received via the above MAC CE and the RRC parameter related to the transform precoder (for example, the RRC IE "transformPrecoder") is set in the RRC parameter related to the configured grant (for example, the RRC IE "configuredGrantConfig"), the terminal 10 may determine whether to enable or disable the transform precoder for the PUSCH transmission according to the RRC parameter. - If the TPI is not received via the above MAC CE and the RRC parameter related to the transform precoder (e.g., RRC IE "transformPrecoder") is not set within the RRC parameters related to the configured grant (e.g., RRC IE "configuredGrantConfig"), the terminal 10 may determine whether to activate or deactivate the transform precoder for the PUSCH transmission according to the RRC parameter related to the transform precoder in message 3 (e.g., RRC IE "msg3-transformPrecoder").

[0115] <The third example> In the third example, the terminal 10 determines whether to apply the transform precoder to the PUSCH as message A based on the TPI in the MAC CE.

[0116] FIG. 15 is a diagram showing a third example of the second switching operation according to the present embodiment. In FIG. 15, it is different from FIG. 9 in that the TPI is included not in the DCI of the PDCCH order that starts the type 2 CFRA but in the MAC CE. Hereinafter, the differences from FIGS. 9 and 13 will be mainly described. Steps S801 and S802 in FIG. 15 are the same as steps S301 and S302 in FIG. 9. Steps S803 and S804 in FIG. 15 are the same as steps S603 and S604 in FIG. 13.

[0117] In step S805, the random access procedure of the PDCCH order is started, and the terminal 10 detects a DCI (e.g., DCI format 1_0) that is CRC scrambled by a specific RNTI (e.g., C-RNTI) and in which a specific field (e.g., frequency domain resource allocation field) is set to a specific value (e.g., all 1).

[0118] In step S806, the terminal 10 transmits the PRACH and the PUSCH as message A. Specifically, the terminal 10 transmits the random access preamble determined based on the DCI in step S805 via the PRACH, and transmits the PUSCH based on the RRC parameters (for example, the RRC IE "MsgA-PUSCH-Config") related to the configuration of the PUSCH as message A. Also, the terminal 10 determines whether to apply a transform precoder to the PUSCH based on the TPI in the MAC CE received in step S804. In FIG. 15, for example, since the TPI in the MAC CE is 0, the terminal 10 transmits the PUSCH without applying a transform precoder (that is, using CP-OFDM). Steps S807 and S808 in FIG. 15 are the same as steps S305 and S306 in FIG. 9.

[0119] As described above, for example, in FIG. 15, for the PUSCH as message A: - If the transform precoder is enabled or disabled by receiving the TPI via the MAC CE that activates or deactivates the transform precoder, the terminal 10 may determine whether to enable or disable the transform precoding for the PUSCH transmission according to the TPI. - If the TPI is not received via the above MAC CE and the RRC parameters (for example, the RRC IE "msgA-TransformPrecoder") related to the application of the transform precoder of message A are set, the terminal 10 may determine whether to enable or disable the transform precoder for the PUSCH transmission according to the RRC parameters. If the RRC parameters are not set, the terminal 10 may determine whether to enable or disable the transform precoder for the PUSCH transmission according to the RRC parameters (for example, the RRC IE "msg3-transformPrecoder") related to the transform precoder of message 3.

[0120] <Example 4> In Example 4, the terminal 10 determines whether to apply a transform precoder to a PUSCH scheduled by a specific DCI (e.g., DCI format 0_0) scrambled by a specific RNTI (e.g., TC-RNTI) based on the TPI in the MAC CE.

[0121] As described above, for example, for a PUSCH scheduled by a UL grant in an RAR, a PUSCH scheduled by a UL grant in a fallback RAR, or a PUSCH scheduled by DCI format 0_0 scrambled by a TC-RNTI: - If the transform precoder is enabled or disabled by receiving a TPI via a MAC CE that activates or deactivates the transform precoder, the terminal 10 may determine whether to enable or disable transform precoding for the PUSCH transmission according to the TPI. - In other cases, whether to enable or disable the transform precoder for the PUSCH transmission may be determined according to an RRC parameter related to the transform precoder in message 3 (e.g., the RRC IE "msg3-transformPrecoder").

[0122] As described above, according to the second switching operation, since the MAC CE includes the TPI, the terminal 10 can flexibly switch whether to apply the transform precoder at an appropriate timing determined by the network. For example, even if the CFRA is not triggered by DCI of the PDCCH order, the network side can flexibly switch the waveform of the PUSCH.

[0123] (Configuration of the wireless communication system) Next, the configuration of each device in the wireless communication system 1 as described above will be explained. Note that the following configuration is for showing the necessary configuration in the description of this embodiment, and does not exclude that each device has functional blocks other than those shown in the figures.

[0124] <Hardware Configuration> FIG. 16 is a diagram showing an example of the hardware configuration of each device in the wireless communication system according to this embodiment. Each device (for example, terminal 10, base station 20, CN 30, etc.) in the wireless communication system 1 includes a processor 11, a storage device 12, a communication device 13 that performs wired or wireless communication, an input device that receives various input operations, and an input / output device 14 that outputs various information.

[0125] The processor 11 is, for example, a CPU (Central Processing Unit), and controls each device in the wireless communication system 1. The processor 11 may execute various processes described in this embodiment by reading a program from the storage device 12 and executing it. Each device in the wireless communication system 1 may be configured by one or more processors 11. Also, each of these devices may be called a computer.

[0126] The storage device 12 is composed of, for example, a memory, an HDD (Hard Disk Drive), and / or an SSD (Solid State Drive) or other storage. The storage device 12 may store various information necessary for the execution of processing by the processor 11 (for example, a program executed by the processor 11, etc.).

[0127] The communication device 13 is a device that communicates via a wired and / or wireless network, and may include, for example, a network card, a communication module, a chip, an antenna, etc. Also, the communication device 13 may include an amplifier, an RF (Radio Frequency) device that performs processing on radio signals, and a BB (BaseBand) device that performs baseband signal processing.

[0128] The RF device generates a radio signal to be transmitted from the antenna by performing, for example, D / A conversion, modulation, frequency conversion, power amplification, etc. on the digital baseband signal received from the BB device. Also, the RF device generates a digital baseband signal by performing frequency conversion, demodulation, A / D conversion, etc. on the radio signal received from the antenna, and transmits it to the BB device.

[0129] The BB device performs a process of converting data into a digital baseband signal. Specifically, the BB device may map the data to subcarriers, perform IFFT to generate an OFDM symbol, insert a CP into the generated OFDM symbol, and generate a digital baseband signal. Note that the BB device may apply a transform precoder (DFT spread) before mapping the data to subcarriers.

[0130] Also, the BB device performs a process of converting a digital baseband signal into data. Specifically, the BB device may remove the CP from the digital baseband signal input from the RF device, perform FFT on the signal after removing the CP, and extract the signal in the frequency domain. Note that the BB device may apply IDFT to the signal in the frequency domain.

[0131] The input / output device 14 includes, for example, an input device such as a keyboard, a touch panel, a mouse, and / or a microphone, and an output device such as a display and / or a speaker.

[0132] The hardware configuration described above is only an example. Each device in the wireless communication system 1 may have some of the hardware described in FIG. 16 omitted, or may be equipped with hardware not described in FIG. 16. Also, the hardware shown in FIG. 16 may be constituted by one or a plurality of chips.

[0133] <Functional block configuration> ≪Terminal≫ FIG. 17 is a diagram showing an example of the functional configuration of the terminal according to the present embodiment. As shown in FIG. 17, the terminal 10 includes a receiving unit 101, a transmitting unit 102, and a control unit 103. The functional configuration shown in FIG. 17 is merely an example, and the functional classification and the names of the functional units may be any as long as the operations according to the present embodiment can be executed. Also, the receiving unit 101 and the transmitting unit 102 may be collectively referred to as a communication unit.

[0134] Note that all or part of the functions realized by the receiving unit 101 and the transmitting unit 102 can be realized using the communication device 13. Also, all or part of the functions realized by the receiving unit 101 and the transmitting unit 102 and the control unit 103 can be realized by the processor 11 executing a program stored in the storage device 12. Further, the program can be stored in a storage medium. The storage medium storing the program may be a computer-readable non-transitory storage medium (Non-transitory computer readable medium). The non-transitory storage medium is not particularly limited, and for example, it may be a storage medium such as a USB memory or a CD-ROM.

[0135] The receiving unit 101 receives a signal (for example, a downlink signal and / or a sidelink signal). Also, the receiving unit 101 may receive information and / or data transmitted via the signal. Here, "receiving" may include performing reception-related processes such as at least one of wireless signal reception, demapping, demodulation, decoding, monitoring, and measurement. The downlink signal may include, for example, at least one of PDSCH, PDCCH, downlink reference signal, synchronization signal, PBCH, etc.

[0136] The receiving unit 101 monitors PDCCH candidates within the search space to detect DCI. The receiving unit 101 may receive downlink data via a PDSCH scheduled using the DCI. The downlink data may include downlink user data and / or control information of a higher layer (e.g., parameters of at least one of the MAC layer, RRC layer, and Non-Access Stratum (NAS) layer). The receiving unit 101 may receive system information via the PBCH and / or PDSCH.

[0137] The transmitting unit 102 receives a signal (e.g., an uplink signal and / or a sidelink signal). Also, the transmitting unit 102 may transmit information and / or data transmitted via the signal. Here, "transmit" may include performing processing related to transmission such as at least one of encoding, modulation, mapping, and transmission of a radio signal. The uplink signal may include at least one of, for example, PUSCH, PRACH, Physical Uplink Control Channel (PUCCH), and uplink reference signal.

[0138] The transmitting unit 102 may transmit uplink data via a PUSCH scheduled using the DCI received by the receiving unit 101. The uplink data may transmit uplink user data and / or control information of a higher layer (e.g., parameters of at least one of the MAC layer, RRC layer, and NAS layer).

[0139] The control unit 103 performs various controls in the terminal 10. Specifically, the control unit 103 may control the operation of the terminal 10 based on information regarding various settings (e.g., parameters of the RRC layer) received by the receiving unit 101 from the base station 20 or another terminal 10. The terminal 10 operating based on the information may be synonymous with "the setting information is configured in the terminal 10".

[0140] The control unit 103 may control the reception of signals in the receiving unit 101. Further, the control unit 103 may control the transmission of signals in the transmitting unit 102. The control unit 103 may determine whether to apply a transform precoder to the signals transmitted by the transmitting unit 102.

[0141] In this embodiment, the terminal 10 includes a transmitting unit 102 that transmits an uplink signal, a receiving unit 101 that receives downlink control information (DCI) or a media access control element (MAC CE) including information related to a transform precoder, and a control unit 103 that determines whether to apply a transform precoder to the uplink signal based on the information related to the transform precoder.

[0142] The DCI includes information related to a random access preamble, and the transmitting unit 102 may transmit a random access preamble determined based on the information related to the random access preamble.

[0143] The uplink signal may be an uplink signal transmitted after a random access response to the random access preamble is received in a first type or second type of random access procedure started based on the DCI.

[0144] The uplink signal may include a physical uplink shared channel (PUSCH) transmitted as message A together with the random access preamble in a second type of random access procedure started based on the DCI.

[0145] The receiving unit 101 receives RRC parameters related to a transform precoder, and when the first type or second type of random access procedure fails, the control unit 103 may determine whether to apply a transform precoder to the uplink signal according to the RRC parameters or the application state of the transform precoder before the execution of the failed random access procedure. 。

[0146] The receiving unit 101 receives RRC parameters related to the transform precoder, and when the control unit 103 falls back from the second type of random access procedure to the first type of random access procedure, the control unit 103 may determine whether to apply the transform precoder to the uplink signal according to the RRC parameters or the application state of the transform precoder before execution of the failed random access procedure.

[0147] ≪Base Station≫ FIG. 18 is a diagram showing an example of the functional block configuration of the base station according to the present embodiment. As shown in FIG. 18, the base station 20 includes a receiving unit 201, a transmitting unit 202, and a control unit 203. The functional configuration shown in FIG. 18 is merely an example, and the functional classification and the names of the functional units may be any as long as the operations according to the present embodiment can be executed. Further, the receiving unit 201 and the transmitting unit 202 may be collectively referred to as a communication unit.

[0148] Note that all or part of the functions realized by the receiving unit 201 and the transmitting unit 202 can be realized using the communication device 13. Further, all or part of the functions realized by the receiving unit 201 and the transmitting unit 202 and the control unit 203 can be realized by the processor 11 executing a program stored in the storage device 12. Further, the program can be stored in a storage medium. The storage medium storing the program may be a computer-readable non-transitory storage medium. The non-transitory storage medium is not particularly limited, and may be, for example, a storage medium such as a USB memory or a CD-ROM.

[0149] The receiving unit 201 receives a signal (for example, an uplink signal and / or a sidelink signal). Further, the receiving unit 201 may receive information and / or data (for example, the uplink data) transmitted via the signal.

[0150] The transmitting unit 202 transmits signals (for example, downlink signals and / or sidelink signals). Further, the transmitting unit 202 may transmit information and / or data (for example, the above-mentioned downlink data) transmitted via the signals. Note that some information transmitted from the transmitting unit 202 may be transmitted by a transmitting unit within the core network device.

[0151] The control unit 203 performs various controls for communication with the terminal 10. Specifically, the control unit 203 may determine information regarding various settings (for example, parameters of the RRC layer) notified to the terminal 10. Transmitting the information to the terminal 10 may be synonymous with "the information is set in the terminal".

[0152] The control unit 203 may control the reception of signals in the receiving unit 201. Further, the control unit 203 may control the transmission of signals in the transmitting unit 202.

[0153] In the present embodiment, the base station 20 includes a receiving unit 201 that receives an uplink signal, a transmitting unit 202 that transmits downlink control information (DCI) or a media access control element (MAC CE) including information regarding a transform precoder, and a control unit 203 that generates information regarding the transform precoder used for determining whether to apply the transform precoder to the uplink signal.

[0154] The DCI includes information regarding a random access preamble, and the receiving unit 201 may receive a random access preamble determined based on the information regarding the random access preamble.

[0155] The uplink signal may be an uplink signal transmitted after a random access response to the random access preamble is received in a first type or second type of random access procedure started based on the DCI.

[0156] The uplink signal may include a Physical Uplink Shared Channel (PUSCH) transmitted as Message A together with the random access preamble in a second type of random access procedure started based on the DCI.

[0157] The transmitting unit 202 transmits RRC parameters related to the transform precoder, and when the random access procedure of the first type or the second type fails, the RRC parameters or the application state of the transform precoder before the execution of the failed random access procedure may be used to determine whether to apply the transform precoder to the uplink signal.

[0158] The transmitting unit 202 transmits RRC parameters related to the transform precoder, and when falling back from the random access procedure of the second type to the random access procedure of the first type, the RRC parameters or the application state of the transform precoder before the execution of the failed random access procedure may be used to determine whether to apply the transform precoder to the uplink signal.

[0159] (Supplementary) The various signals, information, and parameters in the above embodiments may be signaled at any layer. That is, the various signals, information, and parameters may be replaced with signals, information, and parameters of any layer such as a higher layer (for example, Non-Access Stratum (NAS) layer, RRC layer, MAC layer, etc.) or a lower layer (for example, physical layer). Also, the notification of predetermined information is not limited to being explicitly performed and may be implicitly performed (for example, by not notifying information or by using other information).

[0160] In addition, the names of various signals, information, parameters, IEs, channels, time units, and frequency units in the above embodiments are merely examples and may be replaced with other names. For example, a slot may have any name as long as it is a time unit having a predetermined number of symbols. Also, an RB may have any name as long as it is a frequency unit having a predetermined number of subcarriers. Also, "first ~" and "second ~" are merely for identifying a plurality of pieces of information or signals, and the order may be appropriately interchanged.

[0161] For example, in the above embodiment, as an example of a physical channel for transmitting downlink data, a physical channel for transmitting uplink data, a physical channel for transmitting DCI, a physical channel for transmitting notification information, and a physical channel for transmitting a random access preamble, PDSCH, PUSCH, PDCCH, PBCH, PRACH, etc. are exemplified respectively. However, as long as it is a physical channel having the same function, the name is not limited to these. Also, these physical channels may be rephrased as transport channels to which the physical channels are mapped. Also, PDSCH, PUSCH, PDCCH, PBCH, PRACH, etc. may be rephrased as transport channels (for example, at least one of a downlink shared channel (DL-SCH), an uplink shared channel (UL-SCH), a broadcast channel (BCH), and a random access channel (RCH)) that are mapped to the physical channels respectively. Also, these transport channels may be rephrased as logical channels to which the transport channels are mapped. Also, downlink data and uplink data are downlink and uplink data respectively, and the data may include user data and control information of a higher layer (for example, RRC parameters, medium access control (MAC) parameters, etc.).

[0162] Moreover, the uses of the terminal 10 in the above embodiments (e.g., for RedCap, IoT, etc.) are not limited to the examples, and as long as they have similar functions, they may be used in any applications (e.g., eMBB, URLLC, Device-to-Device (D2D), Vehicle-to-Everything (V2X), etc.). Also, the formats of various information are not limited to the above embodiments and may be appropriately changed to bit representations (0 or 1), true / false values (Boolean: true or false), integer values, characters, etc. Further, the singular and plural in the above embodiments may be changed to each other.

[0163] The embodiments described above are for facilitating the understanding of the present disclosure and are not for limiting and interpreting the present disclosure. The flowcharts, sequences, each element included in the embodiments, as well as their arrangements, indexes, conditions, etc. described in the embodiments are not limited to the illustrated ones and can be appropriately changed. Also, at least a part of the configurations described in the above embodiments can be partially replaced or combined.

Claims

1. Receive system information including information for setting to enable a transform precoder from a base station, Receive a radio resource control (RRC) message from the base station that includes physical uplink shared channel (PUSCH) configuration information (PUSCH-Config) including information indicating whether to enable the transform precoder, Receive a first downlink control information (DCI) format used for scheduling of a physical uplink shared channel (PUSCH) from the base station via a physical downlink control channel (PDCCH), A receiver that receives a second DCI format used for scheduling of the PUSCH from the base station via the PDCCH, When the first DCI format is received, apply the transform precoder to the transmission of the PUSCH scheduled using the first DCI format based on the information for setting to enable the transform precoder included in the system information, When the second DCI format including information indicating whether to enable the transform precoder is received, apply the transform precoder to the transmission of the PUSCH scheduled using the second DCI format based on the information indicating whether to enable the transform precoder included in the second DCI format, When transmission of a PUSCH in a random access procedure is scheduled, apply the transform precoder to the transmission of the PUSCH in the random access procedure based on the information for setting to enable the transform precoder included in the system information, When the second DCI format not including information indicating whether to enable the transform precoder is received, a control unit that applies the transform precoder to the transmission of the PUSCH scheduled using the second DCI format based on the information indicating whether to enable the transform precoder included in the PUSCH configuration information, A terminal comprising:

2. The first DCI format is, Scrambled by C (Cell) - RNTI (Radio Network Temporary Identifier) or MCS (Modulation and Coding Scheme) - C - RNTI for CRC (Cyclic Redundancy Check), or Including a new data identifier set to 1 and scrambled by CS (Configured Scheduling) - RNTI for CRC The terminal according to claim 1.

3. The second DCI format is Scrambled by C (Cell) - RNTI (Radio Network Temporary Identifier) or MCS (Modulation and Coding Scheme) - C - RNTI for CRC (Cyclic Redundancy Check), or Including a new data identifier set to 1 and scrambled by CS (Configured Scheduling) - RNTI for CRC The terminal according to claim 1 or 2.

4. The transmission of the PUSCH in the random access procedure is scheduled using a UL (Uplink) grant included in a random access response (RAR) or a fallback RAR and is used for the transmission of message 3. The terminal according to any one of claims 1 to 3.

5. The transmission of the PUSCH in the random access procedure is set using information included in system information and is used for the transmission of message A. The terminal according to any one of claims 1 to 3.

6. Transmit system information including information for setting to enable a transform precoder to the terminal, Transmit a radio resource control (RRC) message to the terminal including PUSCH configuration information (PUSCH - Config) including information indicating whether to enable the transform precoder, Transmit a first downlink control information (DCI) format used for scheduling a physical uplink shared channel (PUSCH) to the terminal on a physical downlink control channel (PDCCH), A transmitting unit that transmits the second DCI format used for scheduling the PUSCH to the terminal on the PDCCH When the first DCI format is transmitted, based on information for setting to enable the transform precoder included in the system information, perform reception of the PUSCH to which the transform precoder is applied and which is scheduled using the first DCI format, When the second DCI format including information indicating whether to enable the transform precoder is transmitted, based on the information indicating whether to enable the transform precoder included in the second DCI format, perform reception of the PUSCH to which the transform precoder is applied and which is scheduled using the second DCI format, When scheduling a PUSCH in a random access procedure, based on information for setting to enable the transform precoder included in the system information, perform reception of the PUSCH in the random access procedure to which the transform precoder is applied, A receiving unit that, when receiving the second DCI format not including information indicating whether to enable the transform precoder, performs reception of the PUSCH to which the transform precoder is applied and which is scheduled using the second DCI format, based on the information indicating whether to enable the transform precoder included in the PUSCH setting information. Base station.

7. The second DCI format is CRC (Cyclic Redundancy Check) scrambled with a C (Cell) - RNTI (Radio Network Temporary Identifier) or an MCS (Modulation and Coding Scheme) - C - RNTI, or Includes a new data identifier set to 1 and is CRC scrambled by a CS (Configured Scheduling) - RNTI, The base station according to claim 6.

8. The transmission of the PUSCH in the random access procedure is scheduled using a UL (Uplink) grant included in a Random Access Response (RAR) or a fallback RAR, and is used for receiving Message 3. The base station according to claim 6 or 7.

9. The transmission of the PUSCH in the random access procedure is set using information included in system information, and is used for receiving Message A. The base station according to claim 6 or 7.

10. Receiving system information including information for setting to enable a transform precoder from a base station; Receiving a Radio Resource Control (RRC) message including PUSCH configuration information (PUSCH-Config) including information indicating whether to enable a transform precoder from the base station; Receiving, from the base station via a Physical Downlink Control Channel (PDCCH), a first Downlink Control Information (DCI) format used for scheduling a Physical Uplink Shared Channel (PUSCH); Receiving, from the base station via the PDCCH, a second DCI format used for scheduling the PUSCH; When the first DCI format is received, applying the transform precoder to the transmission of the PUSCH scheduled using the first DCI format based on the information for setting to enable the transform precoder included in the system information; When the second DCI format including information indicating whether to enable the transform precoder is received, applying the transform precoder to the transmission of the PUSCH scheduled using the second DCI format based on the information indicating whether to enable the transform precoder included in the second DCI format; When the transmission of the PUSCH in the random access procedure is scheduled, applying the transform precoder to the transmission of the PUSCH in the random access procedure based on the information for setting to enable the transform precoder included in the system information. When receiving the second DCI format that does not include information indicating whether to enable the transform precoder, based on the information indicating whether to enable the transform precoder included in the PUSCH configuration information, applying the transform precoder to the transmission of the PUSCH scheduled using the second DCI format; having a method for a terminal.

11. The first DCI format is CRC (Cyclic Redundancy Check) scrambled with C (Cell)-RNTI (Radio Network Temporary Identifier) or MCS (Modulation and Coding Scheme)-C-RNTI, or includes a new data identifier set to 1 and is CRC scrambled by CS (Configured Scheduling)-RNTI, The method according to claim 10.

12. The second DCI format is CRC (Cyclic Redundancy Check) scrambled with C (Cell)-RNTI (Radio Network Temporary Identifier) or MCS (Modulation and Coding Scheme)-C-RNTI, or includes a new data identifier set to 1 and is CRC scrambled by CS (Configured Scheduling)-RNTI, The method according to claim 10 or 11.

13. The transmission of the PUSCH in the random access procedure is scheduled using a UL (Uplink) grant included in a random access response (RAR) or a fallback RAR and is used for the transmission of message 3. The method according to any one of claims 10 to 12.

14. The transmission of the PUSCH in the random access procedure is configured using information included in the system information and is used for the transmission of message A. The method according to any one of claims 10 to 12.

Images