Method and device for receiving downlink channel on basis of plurality of waveforms in wireless communication system

Abstract

The present disclosure relates to a 5G or 6G communication system for supporting a higher data transmission rate. The present disclosure relates to a method and device for receiving a downlink channel on the basis of a plurality of waveforms in a wireless communication system.

Description

Method and apparatus for receiving a downlink channel based on multiple waveforms in a wireless communication system

[0001] The present disclosure relates to a wireless communication system, and in particular to a method and apparatus for receiving a downlink channel based on a plurality of waveforms in a wireless communication system.

[0002] 5G mobile communication technology defines a wide frequency band to enable fast transmission speeds and new services, and can be implemented not only in frequency bands below 6 GHz ('Sub 6 GHz'), such as 3.5 gigahertz (3.5 GHz), but also in ultra-high frequency bands called millimeter waves (mmWave), such as 28 GHz and 39 GHz ('Above 6 GHz'). In addition, for 6G mobile communication technology, which is referred to as a system beyond 5G, implementation in the terahertz band (e.g., the 3 terahertz (3 THz) band at 95 GHz) is being considered to achieve transmission speeds 50 times faster and ultra-low latency reduced to one-tenth compared to 5G mobile communication technology.

[0003] In the early stages of 5G mobile communication technology, aiming to satisfy service support and performance requirements for enhanced Mobile BroadBand (eMBB), Ultra-Reliable Low-Latency Communications (URLLC), and massive Machine-Type Communications (mMTC), technologies such as beamforming and Massive MIMO to mitigate path loss and increase transmission distance in ultra-high frequency bands, support for various numerologies (such as the operation of multiple subcarrier spacings) and dynamic operation of slot formats for the efficient utilization of ultra-high frequency resources, initial access techniques to support multi-beam transmission and broadband, definition and operation of Band-Width Parts (BWP), Low Density Parity Check (LDPC) codes for high-volume data transmission, new channel coding methods such as Polar Codes for the reliable transmission of control information, and L2 pre-processing (L2 Standardization has been carried out for pre-processing, network slicing which provides a dedicated network specialized for specific services, and other methods.

[0004] Currently, discussions are underway to improve and enhance the performance of the initial 5G mobile communication technology, taking into account the services that the 5G mobile communication technology was intended to support. Additionally, standardization of the physical layer is in progress for technologies such as V2X (Vehicle-to-Everything), which helps autonomous vehicles make driving decisions and enhance user convenience based on their own location and status information transmitted by the vehicle; NR-U (New Radio Unlicensed), which aims for system operation in unlicensed bands to comply with various regulatory requirements; NR terminal low power consumption technology (UE Power Saving); Non-Terrestrial Network (NTN), which is direct terminal-satellite communication for securing coverage in areas where communication with the terrestrial network is impossible; and positioning.

[0005] In addition, standardization is underway in the field of wireless interface architecture / protocols for technologies such as the Industrial Internet of Things (IIoT) to support new services through linkage and convergence with other industries, Integrated Access and Backhaul (IAB) which provides nodes to expand network service areas by integrating wireless backhaul links and access links, Mobility Enhancement including Conditional Handover and Dual Active Protocol Stack (DAPS) Handover, and 2-step Random Access (2-step RACH for NR) which simplifies random access procedures. Standardization is also underway in the field of system architecture / services for 5G baseline architectures (e.g., Service based Architecture, Service based Interface) to incorporate Network Functions Virtualization (NFV) and Software-Defined Networking (SDN) technologies, and Mobile Edge Computing (MEC), which provides services based on the location of the terminal.

[0006] When such 5G mobile communication systems are commercialized, connected devices, which are increasing explosively, will be connected to communication networks. Accordingly, it is expected that there will be a need to enhance the functionality and performance of 5G mobile communication systems and to integrate the operation of connected devices. To this end, new research is planned to be conducted on 5G performance improvement and complexity reduction, support for AI services, support for metaverse services, and drone communication using eXtended Reality (XR), Artificial Intelligence (AI), and Machine Learning (ML) to efficiently support Augmented Reality (AR), Virtual Reality (VR), and Mixed Reality.

[0007] Furthermore, the advancement of these 5G mobile communication systems encompasses multi-antenna transmission technologies such as new waveforms to guarantee coverage in the terahertz band of 6G mobile communication technology, Full Dimensional MIMO (FD-MIMO), array antennas, and large-scale antennas; metamaterial-based lenses and antennas to improve terahertz band signal coverage; high-dimensional spatial multiplexing technology using OAM (Orbital Angular Momentum); and Reconfigurable Intelligent Surface (RIS) technology; as well as Full Duplex technology for enhancing frequency efficiency and system networks in 6G mobile communication technology; AI-based communication technologies that realize system optimization by utilizing satellites and AI from the design stage and internalizing end-to-end AI support functions; and the realization of services of complexity exceeding the limits of terminal computing capabilities by utilizing ultra-high-performance communication and computing resources. It could serve as a foundation for the development of next-generation distributed computing technologies.

[0008] As mentioned above, with the advancement of mobile communication systems, it has become possible to provide various services; consequently, measures to effectively provide these services are required, and in particular, support for technologies specialized for various scenarios is needed, such as technologies to increase cell coverage and technologies to support satellite communication.

[0009] The present disclosure provides a method for indicating a channel waveform when using multiple waveforms for downlink channel transmission and reception in a wireless communication system, and a method and apparatus for operating a base station and a terminal according to the same.

[0010] The technical problems to be solved by the present invention are not limited to those mentioned above, and other unmentioned technical problems may be considered by those skilled in the art from the various embodiments of the present disclosure described below.

[0011] The present invention, for solving the above-mentioned problems, is characterized in that a method for processing a control signal in a wireless communication system comprises: a step of receiving a first control signal transmitted from a base station; a step of processing the received first control signal; and a step of transmitting a second control signal generated based on the processing to the base station.

[0012] The present disclosure may provide a method and apparatus capable of effectively providing services in a wireless communication system.

[0013] According to one embodiment of the present invention, a method for setting a plurality of downlink waveforms to enable the use of waveforms specialized for specific services and environments during downlink channel transmission and reception, a method for indicating a waveform of a downlink channel, and a method and device for operating a base station and a terminal according to the same may be provided.

[0014] The effects obtainable in the present disclosure are not limited to those mentioned in the various embodiments, and other unmentioned effects will be clearly understood by those skilled in the art to which the present disclosure pertains from the description below.

[0015] FIG. 1 is a diagram illustrating an example of the basic structure of the time-frequency resource domain of a 5G system according to one embodiment of the present invention.

[0016] FIG. 2 is a diagram illustrating an example of a time domain mapping structure of a synchronization signal and a beam sweeping operation according to an embodiment of the present invention.

[0017] FIG. 3 is a diagram illustrating an example of a random access procedure according to one embodiment of the present invention.

[0018] FIG. 4 is a diagram illustrating an example of a procedure in which a terminal reports terminal capability (UE capability) information to a base station according to an embodiment of the present invention.

[0019] FIG. 5 is a diagram showing an example of a method for RRC IDLE and RRC CONNECTED terminals to determine the waveform of a channel for each downlink channel according to an embodiment of the present invention.

[0020] FIG. 6 is a diagram showing an example of a method for indirectly determining the WF of PDSCH according to a resource allocation type according to an embodiment of the present invention.

[0021] FIG. 7 is a diagram illustrating an example of a method for distinguishing WF used according to CORESET#0 setting according to one embodiment of the present invention.

[0022] FIG. 8 is a diagram illustrating an example of a method using a WF pattern to support various WFs in a time resource according to an embodiment of the present invention.

[0023] FIG. 9 is a diagram showing an example of a method for determining WF by a terminal with SPS set according to an embodiment of the present invention.

[0024] FIG. 10 is a diagram showing an example of a method for transmitting data to a single terminal and a method for transmitting data to multiple terminals using a DFT-s-OFDM waveform according to an embodiment of the present invention.

[0025] FIG. 11 is a diagram illustrating an example of the operation of a terminal when transmitting and receiving a channel that can be set to a plurality of waveforms according to an embodiment of the present invention.

[0026] FIG. 12 is a diagram illustrating an example of the operation of a base station when transmitting and receiving a channel that can be set to a plurality of waveforms according to an embodiment of the present invention.

[0027] FIG. 13 is a block diagram illustrating an example of the structure of a terminal according to an embodiment of the present invention.

[0028] FIG. 14 is a block diagram illustrating an example of the structure of a base station according to one embodiment of the present invention.

[0029] Hereinafter, embodiments of the present disclosure will be described in detail with reference to the accompanying drawings. Furthermore, in describing the present disclosure, if it is determined that a detailed description of related known functions or configurations may unnecessarily obscure the essence of the present invention, such detailed description will be omitted. Additionally, the terms described below are defined considering their functions in the present disclosure, and these may vary depending on the intentions or conventions of the user or operator. Therefore, their definitions should be based on the content throughout this specification.

[0030] The advantages and features of the present disclosure and the methods for achieving them will become clear by referring to the embodiments described below in detail together with the accompanying drawings. However, the present disclosure is not limited to the embodiments disclosed below but may be implemented in various different forms. The embodiments provided are merely to ensure that the disclosure is complete and to fully inform those skilled in the art of the scope of the invention, and the present disclosure is defined only by the scope of the claims. Throughout the specification, the same reference numerals refer to the same components.

[0031] At this point, it will be understood that each block of the process flow diagrams and combinations of the flow diagrams can be executed by computer program instructions. Since these computer program instructions can be loaded into the processor of a general-purpose computer, a special-purpose computer, or other programmable data processing equipment, the instructions executed through the processor of the computer or other programmable data processing equipment create means to perform the functions described in the flow diagram block(s). Since these computer program instructions can also be stored in computer-available or computer-readable memory that can be directed toward the computer or other programmable data processing equipment to implement the function in a specific way, the instructions stored in computer-available or computer-readable memory can also produce a manufactured item containing instruction means to perform the function described in the flow diagram block(s). Since computer program instructions can be loaded onto a computer or other programmable data processing equipment, instructions that perform a series of operation steps on the computer or other programmable data processing equipment to create a process executed by the computer can also provide steps for executing the functions described in the flowchart block(s).

[0032] Additionally, each block may represent a module, segment, or part of code containing one or more executable instructions for executing a specific logical function(s). It should also be noted that in some alternative execution examples, the functions mentioned in the blocks may occur out of order. For example, two blocks described in succession may actually be executed substantially simultaneously, or the blocks may sometimes be executed in reverse order according to their corresponding functions.

[0033] In this embodiment, the term "part" refers to a software or hardware component such as an FPGA (Field Programmable Gate Array) or an ASIC (Application Specific Integrated Circuit), and the "part" performs certain roles. However, the meaning of "part" is not limited to software or hardware. The "part" may be configured to reside in an addressable storage medium or may be configured to run one or more processors. Accordingly, as an example, the "part" includes components such as software components, object-oriented software components, class components, and task components, as well as processes, functions, attributes, procedures, subroutines, segments of program code, drivers, firmware, microcode, circuits, data, databases, data structures, tables, arrays, and variables. The functions provided within the components and "parts" may be combined into a smaller number of components and "parts" or further separated into additional components and "parts." In addition, the components and '~parts' may be implemented to utilize one or more CPUs within the device or secure multimedia card. Also, in the embodiment, the '~part' may include one or more processors.

[0034] In describing the present disclosure below, specific descriptions of related known functions or configurations will be omitted if it is determined that such detailed descriptions would unnecessarily obscure the essence of the present disclosure. Embodiments of the present disclosure will be described below with reference to the attached drawings.

[0035] Terms used in the following description to identify connection nodes, terms referring to network entities, terms referring to messages, terms referring to interfaces between network entities, terms referring to various identification information, etc., are examples provided for the convenience of explanation. Accordingly, the present disclosure is not limited to the terms described below, and other terms referring to objects having equivalent technical meanings may be used.

[0036] In the following description, the terms "physical channel" and "signal" may be used interchangeably with "data" or "control signal." For example, PDSCH (physical downlink shared channel) is a term referring to a physical channel through which data is transmitted, but PDSCH may also be used to refer to data. That is, in this disclosure, the expression "transmits a physical channel" may be interpreted as equivalent to the expression "transmits data or a signal through a physical channel."

[0037] In the present disclosure, upper signaling refers to a signal transmission method transmitted from a base station to a terminal using a physical layer downlink data channel, or from a terminal to a base station using a physical layer uplink data channel. Upper signaling may be understood as radio resource control (RRC) signaling or a media access control (MAC) control element (CE).

[0038] For convenience of explanation, the present disclosure uses terms and names defined in the 3GPP NR (New Radio, 5th generation mobile communication standard) specifications. However, the present disclosure is not limited by the above terms and names and may be applied equally to systems conforming to other standards. Additionally, the term "terminal" may refer to mobile phones, smartphones, IoT devices, sensors, as well as other wireless communication devices.

[0039] Hereinafter, the base station is an entity that performs resource allocation for terminals and may be at least one of a gNode B, gNB, eNode B, eNB, Node B, BS (Base Station), wireless access unit, base station controller, or a node on the network. The terminal may include a UE (user equipment), MS (mobile station), cellular phone, smartphone, computer, or a multimedia system capable of performing communication functions. Of course, it is not limited to the above examples.

[0040] Below, A / B may be understood as A or / and B.

[0041] 5G (5 thInitial standards for the Generation) system or New Radio access technology (NR) have been completed. While existing mobile communication systems focused on conventional voice / data communication, 5G systems aim to satisfy various services and requirements, such as enhanced Mobile Broadband (eMBB) services to improve existing voice / data communication, Ultra-Reliable and Low Latency Communication (URLC) services for high reliability and ultra-low latency, and massive Machine Type Communication (MTC) services to support mass communication of the Internet of Things.

[0042] While the system transmission bandwidth per carrier in existing LTE and LTE-A is limited to a maximum of 20 MHz, the primary goal of 5G systems is to provide ultra-high-speed data services reaching several Gbps by utilizing a significantly wider ultra-wide bandwidth. Accordingly, 5G systems are considering ultra-high frequency bands ranging from several GHz to up to 100 GHz as candidate frequencies, where securing ultra-wide bandwidth frequencies is relatively easy. Additionally, it is possible to secure wide bandwidth frequencies for 5G systems through frequency reallocation or allocation from frequency bands ranging from several hundred MHz to several GHz currently used by existing mobile communication systems.

[0043] The above-mentioned radio waves in the ultra-high frequency band have wavelengths of several millimeters and are also called millimeter waves (mmWave). However, in the ultra-high frequency band, path loss of radio waves increases in proportion to the frequency band, and the coverage of mobile communication systems becomes smaller.

[0044] To overcome the disadvantage of reduced coverage in the aforementioned ultra-high frequency band, beamforming technology is applied by using multiple antennas to concentrate the radiated energy of radio waves toward a predetermined target point, thereby increasing the reach of the radio waves. That is, a signal to which the beamforming technology is applied has a relatively narrowed beam width, and as radiated energy is concentrated within this narrowed beam width, the reach of the radio waves is increased. The beamforming technology can be applied to both the transmitting and receiving ends. In addition to the effect of increasing coverage, beamforming technology has the effect of reducing interference in areas outside the beamforming direction. For the beamforming technology to operate properly, accurate measurement and feedback methods for the transmit and receive beams are required. The beamforming technology can be applied to a control channel or data channel that corresponds one-to-one between a predetermined terminal and a base station. In addition, beamforming technology may be applied to increase coverage for common signals transmitted by a base station to multiple terminals within the system, such as synchronization signals, physical broadcast channels (PBCH), and control and data channels used to transmit system information (or system information block, SIB). When beamforming technology is applied to common signals, beam sweeping technology, which changes the beam direction to transmit the signal, is additionally applied to ensure that the common signal reaches terminals located at any position within the cell.

[0045] Another requirement for 5G systems is ultra-low latency services, where the transmission delay between the transmitter and receiver is approximately 1ms. As a measure to reduce transmission delay, it is necessary to design a frame structure based on a shorter transmission time interval (TTI) compared to LTE and LTE-A. The TTI is the basic time unit for performing scheduling, and the TTI of existing LTE and LTE-A systems is 1ms, which corresponds to the length of one subframe. For example, to satisfy the requirements for ultra-low latency services in the aforementioned 5G systems, short TTIs such as 0.5ms, 0.25ms, and 0.125ms, which are shorter than those of existing LTE and LTE-A systems, are possible.

[0046] FIG. 1 is a diagram showing an example of the basic structure of the time-frequency resource domain of a 5G system according to one embodiment of the present invention.

[0047] Figure 1 shows the basic structure of a time-frequency resource area, which is a wireless resource area where data or control channels of a 5G system are transmitted.

[0048] Referring to FIG. 1, the horizontal axis represents the time domain and the vertical axis represents the frequency domain. The minimum transmission unit in the time domain of a 5G system is an OFDM (orthogonal frequency division multiplexing) symbol, (102) symbols are combined to form one slot (106), and A number of slots can be combined to form a single subframe (105). The length of the subframe (105) is 1.0 ms, and 10 subframes can be combined to form a frame (114) with a length of 10 ms. The minimum transmission unit in the frequency domain is a subcarrier, and the bandwidth of the entire system transmission bandwidth is a total of N BW It can be composed of (104) subcarriers.

[0049] In the time-frequency domain, the basic unit of a resource is the resource element (RE, 112), which can be represented by an OFDM symbol index and a subcarrier index. In the frequency domain, a resource block (RB or physical resource block, PRB) is... It can be defined as (110) consecutive subcarriers. In a 5G system = 12, and the data rate can increase in proportion to the number of RBs scheduled to the terminal.

[0050] In a 5G system, base stations map data in RB units and can generally perform scheduling on RBs that constitute a slot for a given terminal. That is, in a 5G system, the basic time unit for which scheduling is performed is a slot, and the basic frequency unit for which scheduling is performed may be an RB.

[0051] OFDM symbol count It is determined by the length of the cyclic prefix (CP) added to each symbol to prevent interference between symbols; for example, if a normal CP is applied = 14, if extended CP is applied = 12. Extended CP is applied to systems with relatively longer transmission distances than standard CP, enabling the maintenance of orthogonality between symbols. In the case of standard CP, the ratio of CP length to symbol length is maintained at a constant value, allowing the overhead caused by CP to remain constant regardless of the subcarrier spacing. That is, if the subcarrier spacing is small, the symbol length increases, and consequently, the CP length can also increase. Conversely, if the subcarrier spacing is large, the symbol length decreases, and consequently, the CP length can be reduced. The symbol length and CP length can be inversely proportional to the subcarrier spacing.

[0052] In 5G systems, various frame structures can be supported by adjusting the subcarrier spacing to satisfy diverse services and requirements. For example,

[0053] From the perspective of the operating frequency band, a larger subcarrier spacing is advantageous for recovering phase noise in the high-frequency band.

[0054] From the perspective of transmission time, a larger subcarrier spacing results in shorter symbol lengths in the time domain, which in turn shortens slot lengths and is advantageous for supporting ultra-low latency services such as URLLC.

[0055] - From the perspective of cell size, a longer CP length allows for the support of larger cells, so a smaller subcarrier spacing allows for the support of relatively larger cells. A cell is a concept in mobile communication that refers to the area covered by a single base station.

[0056] The above subcarrier spacing, CP length, etc. are essential information for OFDM transmission and reception, and smooth transmission and reception are possible only when the base station and the terminal recognize the subcarrier spacing, CP length, etc. as common values. [Table 1] shows the relationship between the subcarrier spacing configuration (μ), subcarrier spacing (f), and CP length supported by the 5G system.

[0057] [Table 1]

[0058]

[0059] [Table 2] shows the number of symbols per slot for each subcarrier spacing setting (μ) for the general type CP ( ), number of slots per frame( ), number of slots per subframe( It represents ).

[0060] [Table 2]

[0061]

[0062] [Table 3] shows the number of symbols per slot for each subcarrier spacing setting (μ) for extended CP ( ), number of slots per frame( ), number of slots per subframe( It represents ).

[0063] [Table 3]

[0064]

[0065] In the early stages of the introduction of 5G systems, coexistence or dual-mode operation with existing LTE / LTE-A systems is expected. This allows existing LTE / LTE-A to provide stable system operation to terminals, while the 5G system can play the role of providing enhanced services to terminals. Therefore, the frame structure of the 5G system needs to include at least the frame structure of LTE / LTE-A or a set of essential parameters (i.e., subcarrier spacing = 15 kHz).

[0066] For example, when comparing a frame structure with a subcarrier spacing setting μ=0 (hereinafter frame structure A) and a frame structure with a subcarrier spacing setting μ=1 (hereinafter frame structure B), compared to frame structure A, frame structure B shows that the subcarrier spacing and RB size are doubled, while the slot length and symbol length are doubled. In the case of frame structure B, 2 slots can form 1 subframe, and 20 subframes can form 1 frame.

[0067] Generalizing the frame structure of a 5G system provides high scalability by ensuring that essential parameter sets, such as subcarrier spacing, CP length, and slot length, have an integer multiple relationship with each other for each frame structure. Additionally, a subframe of fixed length of 1ms can be defined to represent a reference time unit independent of the frame structure.

[0068] Frame structures can be applied to various scenarios. From the perspective of cell size, since a longer CP length enables support for larger cells, Frame Structure A can support relatively larger cells compared to Frame Structure B. From the perspective of operating frequency band, since a larger subcarrier spacing is advantageous for recovering phase noise in the high-frequency band, Frame Structure B can support relatively higher operating frequencies compared to Frame Structure A. From the perspective of service, since a shorter slot length—the basic time unit of scheduling—is advantageous for supporting ultra-low latency services such as URLLC, Frame Structure B may be relatively more suitable for URLLC services compared to Frame Structure A.

[0069] In the following description of the present disclosure, an uplink (UL) refers to a wireless link through which a terminal transmits data or control signals to a base station, and a downlink (DL) may refer to a wireless link through which a base station transmits data or control signals to a terminal.

[0070] In the initial access phase, when the terminal first connects to the system, the terminal can synchronize downlink time and frequency from the synchronization signal transmitted by the base station through a cell search and obtain a cell identifier (cell ID). Then, the terminal can use the obtained cell ID to receive the PBCH and obtain the master information block (MIB), which contains essential system information, from the PBCH. Additionally, the terminal can receive the system information block (SIB) transmitted by the base station to obtain cell-common control information related to transmission and reception. This cell-common control information may include control information related to random access, control information related to paging, and common control information for various physical channels.

[0071] The synchronization signal serves as a reference signal for cell search, and subcarrier spacing may be applied for each frequency band to suit channel environments such as phase noise. In the case of data channels or control channels, as previously mentioned, subcarrier spacing may be applied differently depending on the service type to support various services.

[0072] FIG. 2 is a diagram illustrating an example of a time domain mapping structure of a synchronization signal and a beam sweeping operation according to an embodiment of the present invention.

[0073] For illustrative purposes, the following components may be defined. Of course, they are not limited to the examples below.

[0074] - PSS (primary synchronization signal): PSS is a signal that serves as the reference for DL ​​time / frequency synchronization and can provide some information about the cell ID.

[0075] - SSS (secondary synchronization signal): The SSS serves as a reference for DL ​​time / frequency synchronization and can provide some of the remaining information, including the cell ID. Additionally, the SSS can serve as a reference signal for PBCH demodulation.

[0076] - PBCH: The PBCH can provide MIB, which is essential system information required for the transmission and reception of the terminal's data and control channels. This essential system information may include control information related to the search space, which represents wireless resource mapping information for the control channel; scheduling control information for a separate data channel that transmits system information; and information such as the SFN (system frame number), which is a frame-unit index serving as a timing reference.

[0077] - SS / PBCH block (synchronization signal / PBCH block or SSB (synchronization signal block)): An SS / PBCH block consists of N OFDM symbols and can be composed of combinations such as PSS, SSS, and PBCH. In systems where beam sweeping technology is applied, the SS / PBCH block may be the minimum unit to which beam sweeping is applied. In a 5G system, N may be 4. A base station can transmit up to L SS / PBCH blocks, and L SS / PBCH blocks can be mapped within a half frame (0.5ms). Additionally, L SS / PBCH blocks may be repeated periodically in units of a predetermined period P. The base station may notify the terminal of the period P through signaling. If there is no separate signaling for the period P, the terminal may apply a pre-agreed default value.

[0078] Referring to FIG. 2, FIG. 2 illustrates an example in which beam sweeping is applied in units of SS / PBCH blocks over time. In the example of FIG. 2, terminal 1 (205) can receive an SS / PBCH block using a beam radiated in the direction of #d0 (203) by beamforming applied to SS / PBCH block #0 at time t1 (201). And terminal 2 (206) can receive an SS / PBCH block using a beam radiated in the direction of #d4 (204) by beamforming applied to SS / PBCH block #4 at time t2 (202). The terminal can obtain an optimal synchronization signal through a beam radiated from the base station in the direction where the terminal is located. For example, it may be difficult for terminal 1 (205) to obtain time / frequency synchronization and essential system information from the SS / PBCH block through a beam radiated in the direction of #d4 (204) away from the location of terminal 1 (205).

[0079] In addition to the initial connection procedure, the terminal may also receive SS / PBCH blocks to determine whether the radio link quality of the current cell is maintained above a certain level. Furthermore, during the handover procedure in which the terminal moves the connection from the current cell to an adjacent cell, the terminal may receive SS / PBCH blocks of the adjacent cell to determine the radio link quality of the adjacent cell and to obtain time / frequency synchronization with the adjacent cell.

[0080] After the terminal obtains MIB and system information from the base station through the initial access procedure, the terminal may perform a random access procedure to transition the link with the base station to a connected state (connected state or RRC_CONNECTED state). Upon completion of the random access procedure, the terminal transitions to the connected state, enabling one-to-one communication between the base station and the terminal. The random access procedure will be explained in detail below with reference to Fig. 3.

[0081] FIG. 3 is a diagram showing an example of a random access procedure according to one embodiment of the present invention.

[0082] Referring to FIG. 3, as a first step (310) of the random access procedure, the terminal can transmit a random access preamble (RAP) to the base station. The random access preamble, which is the initial transmission message of the terminal in the random access procedure, may be referred to as message 1. The base station can measure the transmission delay value between the terminal and the base station from the random access preamble and synchronize the uplink. At this time, the terminal can arbitrarily select which random access preamble to use from a set of random access preambles given in advance by system information. The initial transmission power of the random access preamble can be determined according to the path loss between the base station and the terminal measured by the terminal. Additionally, the terminal can determine the transmission beam direction of the random access preamble from the synchronization signal received from the base station and transmit the random access preamble to the base station.

[0083] In the second step (320), the base station may transmit an uplink transmission timing control command to the terminal based on the transmission delay value measured from the random access preamble received in the first step (310). Additionally, the base station may transmit uplink resource and power control commands to be used by the terminal as scheduling information. The scheduling information may include control information for the terminal's uplink transmission beam. The message transmitted by the base station to the terminal in the second step (320) may be a random access response (RAR) message. The random access response may be referred to as message 2.

[0084] If the terminal does not receive a random access response (RAR, message 2), which is scheduling information for message 3, from the base station within a predetermined time during the second step (320), the first step (310) may be performed again. If the first step (310) is performed again, the terminal can increase the probability of the base station receiving the random access preamble by increasing the transmission power of the random access preamble by a predetermined step (power ramping).

[0085] In the third step (330), the terminal can transmit uplink data (i.e., message 3) including its terminal ID to the base station via the uplink data channel (physical uplink shared channel, PUSCH) using the uplink resources allocated in the second step (320). The transmission timing of the uplink data channel for transmitting message 3 may follow the timing control command received from the base station in the second step (320). The transmission power of the uplink data channel for transmitting message 3 may be determined by considering the power control command received from the base station in the second step (320) and the power ramping value of the random access preamble. The uplink data channel for transmitting message 3 may refer to the first uplink data signal transmitted by the terminal to the base station after the transmission of the random access preamble.

[0086] In step 4 (340), if the base station determines that the terminal has performed random access without collision with other terminals, it may transmit data (message 4, message 4) containing the ID of the terminal that transmitted uplink data in step 3 (330) to the terminal. When the terminal receives the signal transmitted by the base station in step 4 (340), it may determine that the random access was successful. Then, the terminal may transmit HARQ-ACK information indicating successful reception of message 4 to the base station through the physical uplink control channel (PUCCH).

[0087] If the data transmitted by the terminal in the third step (330) and the data of another terminal collide with each other, and the base station fails to receive the data signal from the terminal, the base station may not transmit any further data to the terminal. Accordingly, if the terminal fails to receive the data transmitted from the base station in the fourth step (340) within a certain period of time, it is determined that the random access procedure has failed, and the process may be performed again starting from the first step (310).

[0088] When the random access procedure is successfully completed, the terminal transitions to the connected state (RRC_CONNECTED state), and one-to-one communication between the base station and the terminal becomes possible.

[0089] The base station receives UE capability information from connected terminals and can adjust scheduling by referring to the terminal capability information of the said terminal. Through the terminal capability information, the terminal can inform the base station of whether it supports a specific function, the maximum allowable value of the function supported by the terminal, etc. Therefore, the terminal capability information reported by each terminal to the base station may be different values ​​for each terminal.

[0090] For example, the terminal may report terminal capability information to the base station as terminal capability information, including at least a portion of the following control information. Of course, it is not limited to the examples below.

[0091] - Control information related to frequency bands supported by the terminal

[0092] - Control information related to channel bandwidth supported by the terminal

[0093] - Control information regarding the maximum modulation scheme supported by the terminal

[0094] - Control information regarding the maximum number of beams supported by the terminal

[0095] - Control information regarding the maximum number of layers supported by the terminal

[0096] - Control information related to channel state information supported by the terminal

[0097] - Control information on whether the terminal supports frequency hopping

[0098] - Bandwidth-related control information when Carrier Aggregation (CA) is supported

[0099] - Control information on whether cross-carrier scheduling is supported when carrier bundling is supported

[0100] FIG. 4 is a diagram illustrating an example of a procedure in which a terminal reports terminal capability information to a base station according to an embodiment of the present invention.

[0101] Referring to FIG. 4, in step 410, the base station (402) can send a request message for terminal capability information (UE capability information) to the terminal (401). In response to the base station's request for terminal capability information, the terminal can send terminal capability information to the base station in step 420.

[0102] Through the aforementioned process, a terminal connected to a base station can engage in one-to-one communication as a connected terminal. Conversely, a terminal that is not connected is in an idle state (RRC_IDLE state), and the operation of a terminal in the idle state can be classified as follows. Of course, it is not limited to the examples below.

[0103] - Operates terminal-specific DRX (discontinuous reception) cycles set by the upper layer

[0104] - Operation of receiving paging messages from the core network

[0105] - Obtain system information

[0106] - Measurement operation and cell reselection related to surrounding cells

[0107] In 5G systems, a new state called the inactive state (RRC_INACTIVE state) has been defined to reduce the energy and time consumed for the initial access of a terminal. A terminal in the inactive state can perform the following actions in addition to the actions performed by a terminal in the idle state. Of course, it is not limited to the examples below.

[0108] - Stores AS (access stratum) information required for cell access

[0109] - Terminal-specific DRX cycle operation set by the RRC layer

[0110] - Configure RNA (RAN-based notification area) that can be utilized during handover by the RRC layer and perform periodic updates

[0111] - Monitoring RAN-based paging messages transmitted via I-RNTI (inactive radio network temporary identifier)

[0112] The following describes a scheduling method in which a base station transmits downlink data to a terminal or instructs the terminal to transmit uplink data.

[0113] Downlink control information (DCI) is control information transmitted by a base station to a terminal via the downlink, and may include downlink data scheduling information or uplink data scheduling information for a specific terminal. Generally, the base station may channel-code the DCI independently for each terminal and then transmit it to each terminal via the physical downlink control channel (PDCCH).

[0114] A base station may operate by applying a predetermined DCI format to a terminal to be scheduled, depending on the purpose, such as whether it is scheduling information for downlink data (downlink assignment) or scheduling information for uplink data (uplink grant), or whether it is a DCI for power control.

[0115] A base station can transmit downlink data to a terminal via a physical downlink shared channel (PDSCH). Scheduling information, such as specific mapping locations in the time and frequency domains of the PDSCH, modulation schemes, HARQ-related control information, and power control information, can be provided by the base station to the terminal through the DCIs related to downlink data scheduling information among the DCIs transmitted via the PDSCH.

[0116] The terminal can transmit uplink data to the base station via PUSCH. Scheduling information, such as specific mapping locations in the time and frequency domains of PUSCH, modulation schemes, HARQ-related control information, and power control information, can be provided by the base station to the terminal through the DCI related to uplink data scheduling information among the DCIs transmitted via PDCCH.

[0117] The time-frequency resource to which the PDCCH is mapped may be called a control resource set (CORESET). In the frequency domain, a CORESET may be set to all or part of the frequency resources within the bandwidth supported by the terminal. In the time domain, a CORESET may be set to one or more OFDM symbols, which can be defined as the CORESET duration. A base station may set one or more CORESETs to the terminal via upper-layer signaling (e.g., at least one of system information, MIB, and RRC signaling). Setting a CORESET to the terminal may mean providing information such as the CORESET identity, the frequency location of the CORESET, and the symbol length of the CORESET. The information provided by the base station to the terminal to set a CORESET may include at least some of the information included in [Table 4].

[0118] [Table 4]

[0119]

[0120] CORESET in the frequency domain It can be composed of RBs, and in the time domain It can be composed of ∈{1,2,3} symbols. An NR PDCCH can be composed of one or more CCEs (control channel elements). One CCE can be composed of six REGs (resource element groups), and a REG can be defined as one RB during one OFDM symbol. Within a CORESET, REGs can be indexed in time-first order starting with REG index 0, beginning with the first OFDM symbol of the CORESET, the lowest RB.

[0121] Interleaved and non-interleaved methods may be supported as transmission methods for PDCCH. The base station may configure the terminal to perform interleaved or non-interleaved transmission for each CORESET through upper-layer signaling. Interleaving may be performed on a REG bundle basis. A REG bundle may be defined as a set of one or more REGs. Based on the interleaved or non-interleaved transmission configuration received from the base station, the terminal may determine the CCE-to-REG mapping method in the corresponding CORESET in the manner shown in [Table 5] below.

[0122] [Table 5]

[0123]

[0124] The base station can notify the terminal of configuration information, such as whether the PDCCH is mapped to a specific symbol within the slot and the transmission period, through signaling.

[0125] The search space of a PDCCH is described as follows. The number of CCEs required to transmit a PDCCH can be 1, 2, 4, 8, or 16 depending on the aggregation level (AL), and different numbers of CCEs can be used for link adaptation of the downlink control channel. For example, if AL=L, one downlink control channel can be transmitted through L CCEs. The terminal performs blind decoding to detect signals without knowing information about the downlink control channel; to this end, a search space representing a set of CCEs can be defined. The search space is a set of downlink control channel candidates consisting of CCEs that the terminal must attempt to decode at a given aggregation level, and since there are various aggregation levels that form a group of 1, 2, 4, 8, or 16 CCEs, the terminal may have multiple search spaces. A search space set can be defined as a set of search spaces at all established aggregation levels.

[0126] Search spaces can be classified into a common search space (CSS) and a terminal-specific search space (USS). A certain group of terminals or all terminals may examine the common search space of the PDCCH to receive cell-common control information, such as dynamic scheduling or paging messages for system information. For example, a terminal may receive scheduling allocation information for the PDSCH for receiving system information by examining the common search space of the PDCCH. In the case of the common search space, since a certain group of terminals or all terminals must receive the PDCCH, it may be defined as a set of pre-agreed CCEs. Scheduling allocation information for a terminal-specific PDSCH or PUSCH may be received by a terminal by examining the terminal-specific search space of the PDCCH. The terminal-specific search space may be defined terminal-specifically as a function of the terminal's identifier and various system parameters.

[0127] The base station can configure configuration information for the search space of the PDCCH to the terminal through upper-layer signaling (e.g., SIB, MIB, RRC signaling). For example, the base station can configure the number of PDCCH candidates at each aggregation level L, the monitoring period for the search space, the occasion for monitoring at the symbol level within the slot of the search space, the search space type (common search space or terminal-specific search space), the combination of the DCI format and RNTI (radio network temporary identifier) ​​to be monitored in the search space, and the CORESET index to be monitored in the search space to the terminal. For example, parameters for the search space of the PDCCH may include information such as that shown in [Table 6] below.

[0128] [Table 6]

[0129]

[0130]

[0131]

[0132] According to configuration information, a base station may set one or more sets of search spaces for a terminal. According to one embodiment of the present disclosure, a base station may set search space set 1 and search space set 2 for a terminal. In search space set 1, the terminal may be configured to monitor DCI format A scrambled with X-RNTI in a common search space, and in search space set 2, the terminal may be configured to monitor DCI format B scrambled with Y-RNTI in a terminal-specific search space.

[0133] According to the configuration information, one or more sets of search spaces may exist in a common search space or a terminal-specific search space. For example, Search Space Set #1 and Search Space Set #2 may be configured as a common search space, and Search Space Set #3 and Search Space Set #4 may be configured as a terminal-specific search space.

[0134] In the common search space, terminals can monitor the following combinations of DCI formats and RNTI. Of course, they are not limited to the following examples.

[0135] - DCI format 0_0 / 1_0 with CRC scrambled by C-RNTI, CS-RNTI, SP-CSI-RNTI, RA-RNTI, TC-RNTI, P-RNTI, SI-RNTI

[0136] - DCI format 2_0 with CRC scrambled by SFI-RNTI

[0137] - DCI format 2_1 with CRC scrambled by INT-RNTI

[0138] - DCI format 2_2 with CRC scrambled by TPC-PUSCH-RNTI, TPC-PUCCH-RNTI

[0139] - DCI format 2_3 with CRC scrambled by TPC-SRS-RNTI

[0140] Terminal—In a specific search space, the terminal can monitor the following combinations of DCI formats and RNTI. Of course, it is not limited to the following examples.

[0141] - DCI format 0_0 / 1_0 with CRC scrambled by C-RNTI, CS-RNTI, TC-RNTI

[0142] - DCI format 1_0 / 1_1 with CRC scrambled by C-RNTI, CS-RNTI, TC-RNTI

[0143] The aforementioned RNTIs may follow the following definitions and uses.

[0144] - C-RNTI (cell RNTI): Used for terminal-specific PDSCH or PUSCH scheduling

[0145] - TC-RNTI (temporary cell RNTI): Used for terminal-specific PDSCH scheduling

[0146] - CS-RNTI (Configured Scheduling RNTI): Used for semi-static terminal-specific PDSCH scheduling.

[0147] - RA-RNTI (random access RNTI): Used for PDSCH scheduling during the random access phase

[0148] - P-RNTI (paging RNTI): Used for PDSCH scheduling where paging is transmitted

[0149] - SI-RNTI (System Information RNTI): Used for PDSCH scheduling where system information is transmitted.

[0150] - INT-RNTI (interruption RNTI): Used to indicate whether PDSCH has been punctured.

[0151] - TPC-PUSCH-RNTI (transmit power control for PUSCH RNTI): Used to instruct power control commands to the PUSCH

[0152] - TPC-PUCCH-RNTI (transmit power control for PUCCH RNTI): Used to instruct power control commands to the PUCCH

[0153] - TPC-SRS-RNTI (transmit power control for SRS RNTI): Used to instruct power control commands to the SRS

[0154] The DCI formats described above may follow the definitions in [Table 7] below.

[0155] [Table 7]

[0156]

[0157] The search space of aggregation level L in CORESET p and search space set s can be expressed as [Equation 1] below.

[0158]

[0159] As described above, in order to achieve ultra-high-speed data services reaching several Gbps in a 5G system, signal transmission and reception with ultra-wide bandwidths of tens to hundreds of MHz or several GHz can be supported. Signal transmission and reception with ultra-wide bandwidths can be supported through a single component carrier (CC) or through carrier bundling technology that combines multiple component carriers. Carrier bundling technology enables ultra-high-speed data services by combining individual component carriers with relatively small bandwidths to increase the total frequency bandwidth when a mobile operator has not secured a frequency bandwidth sufficient for providing ultra-high-speed data services with a single component carrier.

[0160] In 5G, various services were provided using waveforms (WF) based on CP-OFDM, which offers the advantages of ease of implementation and scalability. CP-OFDM was used for downlink channel transmission and reception, while Discrete Fourier Transform-spread-OFDM (DFT-s-OFDM) was supported only on some uplink channels to expand coverage. However, since the requirements and performance vary by service, supporting only a single waveform may lead to limitations in improving the performance of specific services. For example, while there is a desire to maximize base station coverage or reduce power consumption to save energy, CP-OFDM inherently possesses a high Peak-to-Average Power Ratio (PAPR); therefore, there may be limitations even if energy savings are sought through other technologies. As another example, base stations supporting terminals moving at very high speeds can provide high-quality services to those terminals by using waveforms that are robust to high speeds. Alternatively, if waveforms specialized for terminals and base stations communicating via NTN are separately supported, it is expected that the access barrier to NTN services can be lowered.

[0161] Therefore, in 6G, terminals and base stations that support multiple waveforms rather than a single waveform may be considered for the purpose of supporting various services and enhancing the performance of each service. In this case, WFs that may be considered include, in addition to CP-OFDM and DFT-s-OFDM supported in existing 5G, OTFS (Orthogonal Time Frequency Space) or OTFS-based modified waveforms that are robust to HST (High Speed ​​Train), or DFT-s-OFDM-based modified waveforms with low PAPR. Furthermore, other types of WFs may be additionally considered depending on the type and characteristics of the supported services. Meanwhile, in this disclosure, communicating with a base station and communicating with a cell are considered to have the same meaning, and any entity capable of communicating directly with a terminal can be considered to be capable of performing the same procedures as the operations performed by the base station or cell of this disclosure.

[0162] <1st Embodiment>

[0163] The first embodiment of the present disclosure describes a procedure for operating based on a basic waveform and a method for determining a waveform per channel. Specifically, it describes a method for a base station to set multiple waveforms including a basic waveform, and the operations of a terminal to determine the waveform of a downlink channel according to the terminal's performance and RRC status. Although the present disclosure focuses on downlink channels, the same technology may be applied to uplinks unless otherwise noted.

[0164] Similar to 5G, terminals with different performance capabilities may be considered in 6G to support various communication services. For example, there may be high-performance terminals capable of supporting reliable communication in scenarios such as satellite communication or HST, while there may also be terminals with limited performance that support only the minimum necessary communication capabilities to reduce the complexity of terminal implementation. Furthermore, there may be terminals that primarily communicate in environments with sufficient cell coverage, whereas there may be terminals that need to communicate even in environments with insufficient cell coverage. Considering the purpose of introducing multiple waveforms (Waveforms) in Radio Access Technology (RAT), different WFs are likely to be introduced for specific channel environments or use cases; therefore, it is highly probable that terminals will selectively support only the necessary WFs rather than supporting all of them. In other words, terminals support only the WFs they intend to use based on their usage purpose and environment, and can report to the network in advance which WFs they can use to transmit and receive on the channel. In this case, a WF that all terminals must support first in order to guarantee a certain level of communication performance even in special situations or to communicate with the network for the first time may be specified in the standard as a default WF. In situations where it is difficult to continue communication with a specific WF, such as when a problem occurs while a terminal is transmitting and receiving with a base station using a specific WF among multiple WFs, the terminal may attempt to resume communication with the cell or another cell by using the default WF.That is, the terminal may determine which WF to use for a specific channel or period based on information set by the base station, but in exceptional situations where communication with the WF is not possible, the terminal uses the default WF, and information on when and how the default WF can be used needs to be provided in the specifications and the base station settings.

[0165] As previously explained, the standard specifies that base stations and terminals must unconditionally use the default WF in specific situations, and the base station may configure this. In other words, even if multiple types of WFs are supported in the RAT, in specific situations, on specific channels, or on specific resources, it may operate using only a single predetermined WF and define this as the default WF. Meanwhile, in the following description, the WFs supported by the RAT standard that exclude the default WF may be referred to as "other WFs." Additionally, there may be WFs that base stations and terminals supporting a specific RAT are required to support; in the following description, such WFs may be referred to as "mandatory WFs." For example, in NR, since all NR terminals must support CP-OFDM on the downlink, the mandatory WF for NR on the downlink can be considered to be CP-OFDM. In addition, since all NR terminals must support both CP-OFDM and DFT-s-OFDM in the uplink, the mandatory WFs for NR in the uplink can be said to be CP-OFDM and DFT-s-OFDM. As such, multiple mandatory WFs may be introduced in the uplink and / or downlink depending on the RAT. However, while in NR, all WFs supported by the standard are mandatory WFs that both terminals and base stations must support, in new RATs to be introduced in the future (e.g., 6G), while there are WFs that all terminals are required to support as mandatory WFs, there may also be WFs that are selectively supported based on terminal capabilities, such as terminal performance. In other words, excluding the mandatory WFs specified in the standard, the number and types of WFs that can be supported may vary depending on the base station or terminal.Conversely, in the following description, a WF that can be selectively supported based on the terminal capability according to purpose or performance without the terminal and base station necessarily needing to support it may be referred to as an optional WF.

[0166] In this case, while a mandatory WF does not necessarily have to be associated with a default WF, if a default WF is specified in the standard, base stations and terminals supporting that standard are highly likely to be required to support the WF set as the default WF. That is, when a default WF is specified in the standard, the default WF may be either a mandatory WF or one of the mandatory WFs (if there are multiple mandatory WFs). Meanwhile, if a base station can configure which WF to use as the default WF based on communication purposes, it may select at least one WF from among the mandatory WF and optional WFs and set it as the default WF. However, if one of the optional WFs is set as the default WF, the terminals that can connect to the base station may be restricted, and additional consideration is required for a method to determine whether a terminal can connect to the base station. Specific details regarding such cases will be covered in this disclosure. The terms defined above may be replaced with other terms or explained by other methods.

[0167] The default WF can be configured in two main ways. The first method is to define a specific WF as the default WF in the specification. In this case, depending on the embodiment, the standard specification may enforce the use of only a specific WF for specific situations or channels without directly mentioning the default WF. For example, the specification may specify that channels such as SSB, which are received preferentially during the cell search process for a terminal to communicate with a base station, are transmitted only with a specific WF (e.g., CP-OFDM). As another example, one can consider a situation where a specific channel, such as PDCCH, is always transmitted with CP-OFDM, and the WF for PDCCH is selected from a group of multiple WF candidates based on the base station's configuration or established rules. Examples of defined rules that can be considered, in addition to those directly specified by the base station or standard, include determining whether to apply a default WF when transmitting and receiving PDSCHs scheduled by the PDCCH based on the RNTI scrambled in the PDCCH transmission, and / or allowing a specific WF from among multiple WFs to be applied. Specifically, for a PDCCH scrambled with a specific RNTI, such as SI-RNTI or P-RNTI, a rule may be established to use a default WF when transmitting and receiving PDSCHs associated with that PDCCH. In this case, the RNTI specified to use a default WF is likely to be an RNTI associated with a broadcast channel (e.g., SIB, paging, etc.) commonly received by terminals within the cell. On the other hand, even if a WF is not directly specified as the default WF, a WF specified in the standard for use in a specific situation or channel may be regarded as the default WF.In addition, if the specification explicitly or implicitly indicates that a specific WF is used as the default WF, it is highly likely that the WF is one of the mandatory WFs. This is because a terminal that does not support optional WFs and only supports mandatory WFs must also support the operations specified in the specification, and if there is a channel that transmits and receives via optional WFs, a terminal that only supports mandatory WFs cannot transmit or receive via that channel.

[0168] The second method is one where the standard specifies only the operation of the base station and terminal regarding the default WF, and the base station determines which WF to use as the default WF. The base station may set which WF to use as the default WF among multiple mandatory WFs, or it may set a specific WF as the default WF from among all WFs supported by the base station, including optional WFs. However, if an optional WF is set as the default WF, procedures such as ensuring that only terminals supporting that WF connect to the cell may be required.

[0169] Meanwhile, if multiple WFs are supported in the standard, a specific ID may be assigned to each WF to facilitate the configuration and reporting of which WFs the base station and terminal support. In particular, the unique number set for each WF can be utilized to provide information such as which WFs the base station supports, which WF is used as the default WF, and which WFs are used in other channels or resources. For example, values ​​such as WF_ID = 0 for CP-OFDM, WF_ID = 1 for DFT-s-OFDM, and WF_ID = 2 for OTFS can be presented, or they can be expressed as code points represented in binary, as shown in [Table 8]. Referring to [Table 8], when a base station and terminal represent a specific WF, they can represent it using 3 bits of information, and whenever a WF supported by the RAT is added, the code point corresponding to 'reserved' can be assigned as the code point for the new WF. The WF_ID or code point value that each WF will have may be directly specified in the standard or set by the base station as system information. The waveforms included in [Table 8] are given as examples, and other types of waveforms may be considered, the number of waveforms may vary, and the number of bits in the code point may vary.

[0170] [Table 8]

[0171]

[0172] As shown in [Table 8], if a code point value or a unique ID corresponding to each WF is specified in the standard, the base station can use that value to configure the terminal which WF is used on which channel or resource. For example, to indicate which WF is used in a specific BWP, the WF can be expressed as a binary code point value when setting the WF information used in the corresponding BWP in the system information (or configuration information) for the BWP. BWP is a concept used in 5G, and the base station may configure the WF used in a specific resource unit, such as a unit of frequency resources or other units of time resources that can replace or be treated similarly to it, to the terminal; or the base station may configure the WF used in a corresponding channel to the terminal when providing settings for specific channel information. For example, when providing dedicated PDSCH information to the terminal, the WF configured as a binary code point value corresponding to the WF can be expressed to configure the WF used when receiving the PDSCH. For example, if the value of the field corresponding to the parameter pdsch-waveform in the terminal-specific PDSCH-related configuration information (e.g., PDSCH-Config) is "001", the terminal can receive the PDSCH based on DFT-s-OFDM by default when receiving the PDSCH. However, the terminal may operate as a different WF if the condition that it must operate as a default WF based on the standard and information provided by the base station is satisfied, or if a different WF is indicated via DCI. Specific details regarding such cases will be covered in the present disclosure.In other words, the WF_ID or code point can be used to encompass when setting which WF candidates the base station and terminal support, when setting system information or RRC information on which WF is used in a given situation (e.g., a specific resource or channel), or when instructing DCI to transmit and receive a specific channel.

[0173] Meanwhile, when providing information about the default WF, the unique WF_ID or code point value defined for each WF may also be utilized. If the specification defines what the default WF is, it may directly specify which WF is used; however, the specification may also provide information on which WF is used in specific situations by using the unique WF_ID or code point value corresponding to the WF. For example, referring to [Table 8], the specification may specify that a WF corresponding to a WF_ID of 0 or a code point value of '000' is considered the default WF. In this case, the WF_ID may be set to a value identical to the index in [Table 8] or a value derived from the index. Additionally, the total number of bits for the code point value is determined by the maximum number of WFs supported by the RAT specification, and different code point values ​​may be used accordingly. For example, if only four different WFs are supported, only 2 bits are required to represent the various WFs, and the code point corresponding to the default WF can also be represented as '00'. As another way to set what the default WF is, you can provide all the WF_ID or code point values ​​of the WFs supported by the RAT regardless of the default WF, and specify in the specification which code point or WF_ID the default WF has. Alternatively, if the specification does not specify a direct term definition or description for the default WF, you can specify the WF_ID or code point corresponding to the WF to be used in a specific situation, and provide a specific description in the specification of the conditions and situations in which the WF is used.

[0174] Alternatively, one may consider not assigning any WF_ID or code point to the default WF. For example, if the default WF is specified in the standard or provided by the base station settings, the 'default-WF' parameter can be used to determine whether the default WF is used when configuring information for a specific channel or resource. If a 1-bit value of '1' is transmitted or the setting is 'enabled', it is considered that the default WF is in use; if a value of '0' is transmitted or the setting is 'disenabled', it is considered that the default WF is not in use. However, if the default WF is not considered to be in use, additional configuration is required to determine which other WF is to be used by utilizing the code point or WF_ID assigned to other WFs. In this case, indicating the usage of the default WF with the 'default-WF' parameter and setting it to the code point associated with other WFs when the default WF is not used applies equally even if a specific WF_ID or code point is assigned to the default WF. However, the only difference is whether the default WF also has a unique WF_ID or code point. As another example, whether the default WF is used may not be directly provided through system information provided by the base station or RRC information provided to a specific terminal. That is, this is a case where the description of the conditions or situations in which the default WF is used is fully specified in the standard. In this case, one of the conditions under which the default WF is used may include when the optional WF is not configured.For example, the specification may specify that if there is no separate setting or instruction for the WF, the default WF or a specific WF that implicitly acts as the default WF should be used. Therefore, for channels or resources that do not use the default WF, a WF_ID or code point value corresponding to the other WF is provided so that the terminal can know that the other WF configured by system information or RRC information, or indicated via DCI, is used instead of the default WF.

[0175] When a base station sets a default WF, it can determine which WF operates as the default WF using a unique WF_ID or code point value based on system information or RRC information provided to the terminal. Additionally, while the default WF used across all resources and channels may be uniform, the default WF may vary depending on the resource or channel configured by the base station. For example, the default WF may be set to CP-OFDM for resources in the low frequency band, while for resources in the high frequency band, a WF capable of achieving low PAPR, such as DFT-s-OFDM or TR-based OFDM, may be set as the default WF to achieve power saving or coverage improvement effects. As another example, when setting different default WFs per channel, the default WF for PDCCH reception may be set to CP-OFDM, while for PDSCH or PUSCH, where coverage is limited due to high data volume, a WF capable of achieving low PAPR may be set as the default WF. However, in cases where a base station sets a default WF, there is a need for the standard to specify which WF the terminal will operate with until it obtains system information or RRC information. This will be explained in detail in the present disclosure.

[0176] Referring to [Table 8], in addition to the code point value corresponding to each WF, it includes information on whether a WF is supported as a mandatory WF or an optional WF in the RAT specification. As such, whether a WF is mandatory can be provided in a table that provides the code point or WF_ID corresponding to the WF, or it can be specified separately in the specification. Furthermore, the code point value or WF_ID corresponding to the WF may be provided only for optional WFs and not assigned to mandatory WFs. In such cases, when a code point value or WF_ID is not assigned to a mandatory WF, a method similar to the case where a code point value or WF_ID is not assigned to a default WF may be applied. For example, information on whether a specific mandatory WF will be used can be provided as a 1-bit value, and the code point or WF_ID information for an optional WF, which is used only when the mandatory WF is not 'enabled', can be set or indicated. If multiple mandatory WFs are supported, the 'enabled' or 'disabled' status of each mandatory WF can be represented by a separate 1-bit, or a combination of multiple bits can be used to indicate which mandatory WF is being used and whether an optional WF is being used instead of a mandatory WF. In other words, if there is no field corresponding to a mandatory WF, it means that the resource or channel is operating as an optional WF, and therefore, the field corresponding to which optional WF is being used can be set or indicated.

[0177] In this case, as explained earlier, base stations and terminals may support only some of the various optional WFs, considering factors such as usage purpose and channel environment. Accordingly, the base station needs to provide the terminal with information regarding which WFs are supported as system information or configure this information for the terminal via RRC. In the case of the terminal, when reporting its capability, it must report to the network information regarding which WFs can be supported within which frequency resources (e.g., bands). One method involves defining parameters for each optional WF and representing whether a WF is supported using 1-bit information. Alternatively, a single parameter can be defined to set or report optional WF support, and the specifications can pre-define which optional WFs are supported based on the value of that field. For example, the field of the parameter can be configured in a bitmap format so that each optional WF corresponds to a single bit. In this case, information regarding which optional WF corresponds to which bit must be specified in the specifications. Alternatively, the field can be configured in the form of a code point to indicate which optional WFs are supported by setting or reporting a corresponding code point value. In this case, the code point value may include cases where each optional WF is supported, cases where multiple optional WFs are supported, and cases where no optional WFs are supported.For example, assuming there are a total of four optional WFs, there is a method of associating each code point with one optional WF using 2 bits, such as using '00' when supporting only the WF corresponding to WF_ID = 0 and '01' when supporting only the WF corresponding to WF_ID = 1. Alternatively, more information bits than 2 bits (e.g., 3 bits) can be used to assign the code point '000' when no optional WFs are supported and '111' when all optional WFs are supported. The remaining code point values, excluding these, may be used for cases where one optional WF or two to three optional WFs are supported, and the specification must specify which code point corresponds to which combination of optional WF support. Depending on the embodiment, it is not necessary to support all combinations as code points; instead, only the combinations likely to be implemented by the base station or terminal may be specified in the specification. For example, if it is determined that there is no possibility that a terminal will simultaneously support a waveform primarily used by a high-performance terminal (e.g., OTFS) and a waveform primarily used by a low-power terminal (e.g., OOK), then for a high-performance terminal, it is highly likely that a code point corresponding to a waveform primarily used by a low-power terminal will not be defined, and for a low-power terminal, it is highly likely that a code point corresponding to a waveform primarily used by a high-performance terminal will not be defined. The method of setting or indicating optional WFs supported by a base station and the method of reporting optional WFs supported by a terminal may use the same method or different methods.When a terminal reports its capability regarding a supported WF to the base station in a defined manner, the base station may select one of the WFs supported by the terminal based on the reported capability when setting or instructing the WF of the channel or resource that the terminal needs to transmit or receive. In this case, a separate process may be defined for the terminal to request a reset or retransmission from the base station in the event that a WF different from the one supported by the terminal is set. For example, a method of requesting a reset from the base station by transmitting the uplink channel corresponding to the channel and resource (e.g., PRACH) may be considered. Alternatively, the setting or instruction may be treated as an error, and the operation may proceed as if the setting or instruction was not successfully received. Or, it may be specified that a process such as cell re-searching be performed when specific conditions are met, such as when such a process is repeated.

[0178] Meanwhile, the code point value or unique ID corresponding to each WF may be determined by the base station's settings. If the standard does not provide any information that can represent the WF, such as unique ID information or code point values ​​for each WF, parameters for each WF may be predefined, and the base station may arbitrarily set the corresponding WF_ID. In this case, the WF_ID or code point value set by the base station may be set to include all mandatory WFs, or it may be set only for optional WFs. If the base station sets the WF_ID or code point value for optional WFs it supports but does not set such information for optional WFs it does not support, the terminal may receive information from the base station regarding which WFs the base station supports, along with the WF_ID or code point value corresponding to each set WF. On the other hand, even if the standard provides unique ID information or code point values ​​for each WF, the base station may be permitted to set them to different values. For example, when the number of WFs supported by the standard is large, resulting in a large WF_ID value or code point bit count, but the number of WFs actually supported by the base station or a specific terminal is limited, the base station may be allowed to arbitrarily specify a WF_ID or code point value for the purpose of limiting the maximum value of the WF_ID or the number of code point bit count. In this case, the terminal and the base station use the value defined in the standard before the base station sets the WF_ID or code point for the WF (e.g., when in the RRC IDLE / INACTIVE state), and after the base station sets it (e.g., when in the RRC CONNECTED state), they can determine which WF was used based on the WF_ID or code point value set by the base station.

[0179] If the base station sets a WF_ID or code point value, when the terminal reports capability to the network, the report can be made based on the code point or WF_ID specified in the standard. If the standard does not provide unique WF information such as a WF_ID or code point, parameters related to each optional WF exist, allowing the terminal to report whether it supports the corresponding WF through these parameters. As a simple example, reporting optional WF1 as 'supported' or '1' indicates that optional WF1 is supported.

[0180] Based on the methods described above, the method for determining which WF a terminal will use for a specific channel or specific resource can be divided into four cases as shown in [Table 9] below.

[0181] [Table 9]

[0182]

[0183] Case 0 of [Table 9] refers to the case where a default WF specified in the standard or configured by the base station is used without any specific settings or instructions, and the terminal may determine the waveform (WF) in the manner of Case 0 for specific conditions or specific channels. The conditions for determining the waveform in Case 0 or the channels corresponding to Case 0 must be specified in the standard, and details regarding specific conditions, etc., will be discussed in detail in this disclosure. Case 1 of [Table 9] refers to the use of a WF configured by SIB, and the SIB configuration details may include information on which WF to use, as well as which WF to use for which resource or / and which channel. That is, it may mean that parameters for the WF are separately added and configured in the fields for each channel (e.g., PDSCH) and each resource (e.g., a specific BWP or a specific slot / frame group). In addition, since the terminal's SIB is information that can be commonly obtained by all RRC IDLE / INACTIVE terminals and RRC CONNECTED terminals within the cell, it may be possible for a terminal to determine the waveform on a specific channel or specific resource using the method of case 1 even if the terminal is not connected to the base station—that is, even if the terminal is not in the RRC CONNECTED state. Case 2 in [Table 9] is a case where the terminal determines the waveform based on RRC information that is dedicated to a specific terminal, unlike the SIB which is applied commonly to all terminals within the cell. Therefore, case 2 can be applied only to terminals that have received RRC settings, and accordingly, when an RRC CONNECTED terminal transmits or receives a channel on a specific channel or specific resource, the waveform can be determined using the method of case 2. In this case, a method may be used in which parameters for the WF are separately added and configured for the RRC settings, just as with the SIB.Case 3 of [Table 9] is a method for determining which WF a terminal can use, either explicitly or implicitly, based on values ​​in specific fields related to WF within the DCI format transmitted to the PDCCH. Depending on the characteristics of the DCI format, the WF indicated by the corresponding fields may be applied to the channel scheduled by the PDCCH containing the DCI format, or it may be applied only during a period satisfying specific time resources, frequency resources, or specific conditions. The specific indication method through the fields of the DCI format and the terminal's operation accordingly are described in detail in Example 2. Which case among the cases listed in [Table 9] the terminal determines the WF may vary depending on the terminal's RRC state and / or the channel the terminal transmits and receives, or / or the characteristics of the feature that supports multiple WFs.

[0184] FIG. 5 is a diagram showing an example of a method for RRC IDLE and RRC CONNECTED terminals to determine the waveform of a channel for each downlink channel according to an embodiment of the present invention.

[0185] Referring to FIG. 5, three scenarios (501-503) can be considered. These scenarios can be distinguished based on how the WF of the channels (505-508) that transmit and receive when the terminal (504) in the RRC IDLE state is in the RRC IDLE state is determined. Meanwhile, when the terminal (509) is in the RRC CONNECTED state, terminal-specific unicast information (510) is transmitted, so the same methods can be applied to determine the WF regardless of the scenarios (501-503) shown in FIG. 5.

[0186] Each scenario in FIG. 5 is broadly divided into two cases. A terminal that supports multiple waveforms as described in this disclosure and supports the operation of setting and determining which waveform among them will be used can be considered to support multiple WF features. This feature may be supported as mandatory or optional in a specific RAT. In this case, the fact that the multiple WF feature is mandatory can be interpreted to mean that there is a high probability that at least multiple mandatory WFs will be specified in the standard. This is because if there is only one mandatory WF but the terminal must unconditionally support multiple WF features, it is equivalent to forcing the terminal to unconditionally support one of the optional WFs. Although such cases are not limited, there is a high probability that there are cases where only mandatory WFs are supported to simplify the implementation of the terminal. Scenario 1 (501) and Scenario 2 (502) correspond to cases where the feature is supported optionally (511). That is, not all terminals support multiple waveforms, and they correspond to cases (511) where they do not support a method of determining which waveform to use according to the settings and instructions for the waveforms. Scenario 3 (503) corresponds to the case where multiple WF features are mandatory (512). That is, Scenario 3 (503) corresponds to the case where all terminals support multiple waveforms.

[0187] Meanwhile, features for multiple WFs may be supported separately for the uplink (UL) and downlink (DL). For example, supporting multiple DL WF features may mean that the terminal supports multiple WFs and the function to set which WF to use when receiving a downlink. Also, supporting multiple UL WF features may mean that the terminal supports multiple WFs and the function to set which WF to use when transmitting an uplink. Furthermore, whether the feature is mandatory may be applied separately to the UL and DL. For example, multiple DL WF features may be supported as optional, while multiple UL WF features may be mandatory. Meanwhile, although FIG. 5 explains the multiple DL WF feature based on the WF determination method of the downlink channel, there may be parts where the specific method for determining WFs is applied identically to the uplink channel as well.

[0188] 505-508 in FIG. 5 represent the channels received by the RRC IDLE state terminal (504) in the downlink, and 513-521 represent how the WF can be determined when a terminal supporting multiple DL WF features receives each channel according to scenario (501-503). Cases 0 through 3 represented by 513-521 in FIG. 5 correspond to the cases classified in [Table 9], respectively. At this time, the operation of the RRC IDLE state terminal receiving the channels of FIG. 5 and the method of determining the WF upon channel reception can be applied in the same way to the RRC INACTIVE state terminal.

[0189] In the 505 process, terminals in the RRC IDLE and INACTIVE states receive a PBCH first to obtain information about a specific cell or cell search process, and can obtain the MIB, which is essential system information, from it. The obtained MIB contains information that allows receiving SIB1, which contains the remaining system information.

[0190] The terminal can utilize information obtained from the MIB to obtain SIB1 and other system information required by the terminal during the 506 process. For example, it obtains information to receive the PDCCH associated with the SIB through the MIB, and obtains SIB1 through the PDSCH scheduled by the PDCCH associated with the SIB. Upon receiving SIB1, the terminal can obtain information from the said SIB1 to receive the remaining SIBs. Terminals maintaining an RRC IDLE and INACTIVE state can continuously repeat the 505 to 506 reception process according to a given period or specific conditions to check system information. Additionally, to periodically check for paging, the terminal can check the paging PDCCH and PDSCH, or the Paging Early Indication (PEI) signal or Low Power Wake Up Signal (LP-WUS) signal indicating whether paging is active, every DRX cycle.

[0191] Meanwhile, a terminal that intends to switch the link with the base station to a connected state, i.e., an RRC CONNECTED state, can receive channels 507 to 508 by performing a random access procedure as described in FIG. 3. After transmitting a PRACH, the terminal expects to receive message 2 (507) in response. The PDCCH that schedules message 2 (507) is transmitted within a specific window time set by the base station, and message 2 is obtained when the PDSCH scheduled by that PDCCH is received. At this time, the terminal can obtain resource information and uplink transmission timing information necessary to transmit message 3 through message 2. At this time, the DCI format transmitted through the PDCCH that schedules message 2 is transmitted by CRC scrambling into RA_RNTI, and RA_RNTI can be determined based on the PRACH information transmitted by the terminal, and multiple terminals may have the same RA_RNTI. That is, multiple terminals may simultaneously decode a PDSCH containing message 2 information with the same RA_RNTI. Therefore, to resolve collisions between terminals when multiple terminals transmit the same PRACH and receive the same RAR, the base station may transmit message 4 (508) based on the terminal identification information in message 3 transmitted by the terminals. Thus, a terminal selected by the base station can receive a PDCCH scheduling message 4 corresponding to itself within a specific time (e.g., ra-ContentionResolutionTimer of 5G) after transmitting message 3.If the terminal does not receive the PDCCH associated with message 4 from the base station within the specified time, or if the terminal identification information included in the received message 4 is different from its own, it is considered a failure of the random access procedure and the procedure of transmitting PRACH can be performed again.

[0192] Referring to scenario 1 (501) in FIG. 5, even a terminal that supports multiple DL WF features can be made to unconditionally use the default WF when in the RRC IDLE state. That is, if the WF used when a terminal that does not support multiple DL WF features receives channels 505-508 is the same as the default WF, it can be assumed that the terminal in the RRC IDLE state uses the same WF regardless of whether it supports multiple DL WF features. In particular, since channels 505 to 506 are information that must be provided in common to all terminals within the cell, using the same WF can reduce the burden on the base station. Meanwhile, regardless of which WF is specified as the default WF in 501, a terminal supporting the multiple DL WF feature uses only the default WF in the RRC IDLE state, and in the RRC CONNECTED state, it can receive the PDCCH or / and PDSCH by determining which WF to use among other WFs that are semi-statically set (522) with RRC information including the default WF or other WFs that are dynamically indicated (523) through DCI. Meanwhile, considering the case where the base station sets the default WF, since obtaining the minimum information of the cell operated by the base station is possible through reception in step 505, the WF used when the terminal receives the signal in step 505 must be specified in the standard. The default WF in subsequent steps 506-508 can be operated by setting a WF different from the WF specified in the standard as the default WF through MIB or SIB, but such operation may be a burden on the base station, especially in the environment of scenario 1 or scenario 2.This is because if a terminal that does not support the multiple DL WF feature sets a WF it does not support as the default WF, the base station may block the connection or camping of that terminal, or it may need to transmit channels 506-508 based on different WFs for terminals that support the feature and those that do not. Alternatively, WFs operating by specific frequency or time resources may be distinguished, and resources capable of transmitting and receiving information when in the RRC IDLE state may be distinguished according to the terminal's capability. For example, resource A, which operates as WF A (an existing default WF that can be used even by terminals that do not support the multiple DL WF feature), and resource B, which operates as WF B (a newly configured default WF), are distinguished, and a terminal that supports the multiple DF WF feature and WF B can perform operations (e.g., paging operation or / and PRACH operation or / and RRM measurement, etc.) when in the RRC IDLE / INACTIVE state on resource B. In the following description, the operation of the base station changing the default WF is not restricted, but each scenario is described assuming a situation where the default WF is specified in the standard and supported by all terminals.

[0193] Referring to scenario 2 (502) in FIG. 5, the fact that not all terminals support the multiple DL WF feature (511) is the same as in scenario 1 (501). Therefore, the PBCH (505) containing the MIB, which is a channel that the base station periodically broadcasts to all terminals in the cell, and the PDCCH / PDSCH (506) for SIB transmission can use a default WF (514) so ​​that they can receive based on the same WF regardless of whether the terminals support the multiple DL WF feature. However, the PDCCH / PDSCH (507) associated with message 2 transmission and the PDCCH / PDSCH (508) associated with message 4 transmission, which are channels for the random access procedure, can be made to receive using the WF (515) set in the SIB. For example, to ensure successful random access for terminals in specific environments, such as fast-moving terminals, terminals located at the cell edge with limited coverage, or terminals using satellite communication, a base station may support random access by using a WF optimized for the specific environment. The terminal may obtain information about which WF is supported, along with information about whether the base station supports multiple WF features, through the MIB and / or SIB (506) transmitted by the base station, by means of the standard. For example, the terminal may obtain information through the MIB and / or SIB about whether multiple WF features are supported from the random access procedure, whether the feature is supported for each of the uplink and downlink, and which WF can be supported in the random access procedure. Alternatively, the standard may specify that if multiple WF features are supported, the function must be supported from the random access procedure.In this case, if the base station does not support multiple WF features in the random access procedure, it can be considered to follow the same operation and procedure as scenario 1 (501). Meanwhile, the terminal can determine whether the base station supports multiple UL / DL WF features and which WF features it supports by receiving 505 or 506, but if the multiple UL / DL WF features are optional, the base station may not know whether the terminal attempting random access supports the feature. Therefore, depending on which multiple WF features the terminal supports in the random access procedure, the process by which the terminal and the base station determine the WF used in the random access procedure may differ, and each case is classified and explained in detail. When each feature is mandatory, it can be considered to follow an operation and procedure similar to scenario 3 (503).

[0194] The operation of a terminal that supports the multiple DL WF feature, which is one of the optional features in scenario 2 (502) of FIG. 5, is described. At this time, the multiple UL WF feature may be mandatory or optional, and when it is an optional feature, the terminal may or may not support the multiple UL WF feature. When the terminal first attempts random access, it transmits PRACH (message 1). Depending on the characteristics of the multiple UL WF feature, all terminals may use the same WF, or PRACH transmission may be allowed with different WFs for each terminal. For example, the case where the terminals use the same WF is when a single WF is specified in the standard as the WF for PRACH transmission, or when the base station has configured one WF from a group of multiple WF candidates to be used for PRACH transmission. At this time, the terminal can obtain the relevant information through channels 505 to 506, and the configured WF may be restricted to selecting only one of the multiple mandatory WFs, or it may be allowed to include optional WFs in the configuration. According to the embodiment, if an optional WF is included, terminals that do not support the WF cannot transmit PRACH, so access to the cell itself can be considered blocked. In order to allow PRACH transmission with a different WF for each terminal, a method may be considered in which the base station sets a PRACH transmission resource corresponding to the WF. For example, a RACH occasion (RO) or frequency resource in which a specific WF is used can be set for the terminal through system information (505-506). At this time, the terminal can determine which WF can be used to use PRACH and can transmit PRACH from the resource allocated to the selected WF.Alternatively, a RAP that uses a specific WF can be configured for the terminal through system information (505-506). At this time, the terminal can determine which WF can be used to perform PRACH and can transmit a RAP corresponding to the selected WF. Alternatively, according to an embodiment, a PRACH occasion and a RAP corresponding to the WF can be configured for the terminal, and the terminal can transmit a RAP using the RAP and PRACH occasion corresponding to the selected WF. Another method is for the base station to instruct a specific terminal to perform random access by requesting RRC CONNECTION, etc., or to provide PRACH information applicable only to a specific terminal (e.g., Contention Free Random Access), and also to configure which WF the terminal transmits PRACH to. This is possible when the base station knows whether the terminal supports multiple UL WF features and which WF can be used even before the terminal transmits PRACH. In other words, this is a method that can be applied when you know whether multiple UL WF features are mandatory, whether the terminal supports the feature, and which WF is supported.

[0195] Additionally, the transmission of PRACH may serve to directly or indirectly convey information about the candidate WFs available for use when the terminal subsequently receives message 2 (507) or / and message 4 (508). As previously explained, the base station may not know whether the terminal attempting random access supports multiple DL WF features and which WFs it supports until PRACH is transmitted. Therefore, PRACH can be utilized to determine subsequent actions of the base station and the terminal regarding random access. For example, PRACH can be used to report to the base station the WF(s) or preferred WFs that the terminal can use to receive message 2 or / and message 4. In this case, the WF(s) reported by the terminal may be a subset of the WFs that the terminal actually supports. Various methods can be considered for transmitting this information via PRACH. Typically, considering the combination of WF types that a terminal can report, appropriate PRACH resources (e.g., RAP and / or PRACH occasion) may be specified in the standard or configured as system information of the base station. For example, resources used by a terminal that can only use WF1 and resources used by a terminal that can use both WF1 and WF2 may be configured differently, so that the base station can obtain partial or full capability information regarding multiple DL WFs for the PRACH based on the resource to which the PRACH was transmitted. As an example of another method, methods that can generate various PRACH sequences based on the information the terminal intends to transmit, such as a method in which a different sequence or another arbitrary complex value is multiplied based on the information derived from a fundamentally generated PRACH sequence, may also be considered.Based on the transmitted PRACH, the base station obtains some capability information of the terminal that transmitted the PRACH. At this time, the base station can transmit message 2 (507) based on the capability reported by the terminal through the PRACH transmission. For example, the specification may specify an operation in which the terminal selects and reports only one WF from a group of various DL WF candidates set by the base station as system information, and the base station uses the WF reported by the terminal to transmit message 2 (507) or / and message 4 (508). This example may force the base station to use only the WF reported by the terminal for the transmission of message 2 to message 4. In another example, the base station may select the WF to transmit to the downlink of random access based on the terminal's report. If the terminal reports the capability to use multiple WFs, a rule for determining this is required because the terminal does not know which WF the base station will use when receiving 507. For example, if the PDCCH scheduling message 2 can also be transmitted using multiple WFs, the PDCCH transmission resources (e.g., search space, etc.) corresponding to each WF may be configured separately. However, in this case, the burden of PDCCH monitoring may increase because the terminal must perform actions to receive different PDCCHs for each type of supported WF. Another method may be to receive the PDCCH with a default WF or with a single pre-configured WF, and then instruct via the PDCCH which WF to use when receiving a PDCCH thereafter. In this case, the DCI format transmitted via the PDCCH may include a field indicating the WF.Meanwhile, as explained earlier, another terminal may receive the same RAR after PRACH is transmitted. In the 502 scenario, there is a mix of terminals that support multiple DL WF features and those that do not, and since the types of WF supported by each terminal differ, when the base station transmits the PDCCH of message 2, if a field indicating the WF is included or if the indicated WF is a WF that the terminal does not support, the terminal may recognize that the RAR does not apply to it and perform the operation of retransmitting PRACH.

[0196] The methods and procedures described above may be applied equally to the reception of message 4 as well as message 2. Alternatively, the message 2 reception operation (507) may operate with a default WF as in 501, and the method described above may be applied when receiving 508. In this case, for the 508 reception process, instead of transmitting PRACH, some capability information regarding the terminal's WF feature may be included and transmitted during the message 3 transmission process. Alternatively, information regarding the WF feature and related capability may be transmitted via PRACH, but message 2 may use a WF that is pre-configured or defined in the standard as a default WF, and the application of a different WF may be applied starting from the transmission of message 4 or message 3. As with message 2, when terminals that have different WF features or prefer different types of WF during the random access process each receive the same PDCCH in message 4, they can determine in advance whether the message applies to them through the WF-related fields within the PDCCH. If a WF that is not supported by the device is used, the device may perform procedures such as retrying random access through PRACH retransmission.

[0197] Additionally, although not described in FIG. 5, regarding the WF used for uplink channel transmission when performing a random access procedure, system information such as MIB / SIB or message 2 may be included to configure which WF the terminal will use for uplink transmission, or it may be specified in the standard to operate in conjunction with previously received downlink information. For example, since a default WF was received to receive SIB information, it may be specified that PRACH transmission is also transmitted using the default WF, and if message 2 is received with a different WF (e.g., WF A), message 3 PUSCH may also be transmitted with WF A. In this case, when the terminal reports some information regarding the capability of the WF as WF A, the operation can be performed smoothly only if the terminal supports WF A for both uplink and downlink. That is, in the above example, when the terminal reports a preferred WF, it must report a WF that supports both uplink and downlink.

[0198] Referring to scenario 3 (503) of FIG. 5, it is assumed that all terminals support multiple DL WF features (512). Accordingly, when the terminal first connects to a cell and acquires 505, it uses the default WF specified in the standard (516), and other acquisition methods may be used in subsequent processes. In the process of receiving 506, the terminal receives the PDCCH with the default WF, and the PDSCH scheduled to that PDCCH can acquire PDSCH information corresponding to the SIB through a field (517) indicating the WF within the PDCCH. Meanwhile, as a method for determining the WF of the PDCCH to receive the SIB, the default WF specified in the standard may be used, or the relevant WF information may be provided within the MIB. Depending on the embodiment, even if all terminals are mandatory to support multiple DL WF (512), the process of receiving the SIB (506) may also be restricted to using the default WF (case 0). For a terminal performing random access in a 503 scenario, the WF used when receiving message 2 and message 4 may be configured via MIB and SIB (518, 520), or indicated in the WF-related field of the DCI format within the PDCCH when scheduling PDSCH in each PDCCH (519, 521). In this case, the WF information used in the PDCCH may be specified in the standard to use a specific WF, such as a default WF, or configured via MIB or SIB.At this time, even if all terminals support multiple DL WFs, the terminals may have different preferred WFs, so the base station may set or instruct each channel or resource to use a different WF for each terminal to reflect this, and the methods described in 502 scenario (scenario 2) for reporting the WF preferred by the terminal can be used in the same way.

[0199] Meanwhile, in cases where the base station stores all capability information of all terminals and provides information on which terminal is camping in which cell, the base station may select one of the WFs that the terminals camping and connected to the cell can support and set it as the SIB (case 1) or instruct it via PDCCH (case 3) without a separate report from the terminal during the random access process. Alternatively, among the various cells operated by the base station, a specific cell may be used for all channel transmission and reception with a specific WF other than the default WF specified in the standard, and the base station may induce only terminals that support that WF to camp or perform RRC CONNECTION in that cell. Furthermore, in situations where it is known what capability a terminal intending to perform random access has regarding multiple WF features (e.g., when an RRC-connected terminal performs random access such as during handover), the RRC information may be set to indicate which WF the terminal can use to perform random access (case 2). At this time, only the WF for receiving the PDCCH is set, and information about the WF of the PDSCH may be indicated by the WF field information included in the DCI format within the PDCCH, or both the WF information for the PDCCH and the PDSCH may be set to RRC.

[0200] As previously explained, the scenarios in Fig. 5 are classified into three types based on the timing at which the WF used among several candidate WFs can be set or indicated. The operation of the related terminal and base station is not limited to the described scenarios but can be applied in the same way to other scenarios where the timing or conditions for setting the WF are subdivided. For example, the same WF determination method can be used for a channel that performs a similar role in a 2-step random access procedure (e.g., 5G type-2 random access) rather than the 4-step random access procedure in Fig. 3.

[0201] As previously explained, a default WF may be used when specified by a standard or configured by a base station to use a default WF for a specific resource or channel. Among these, examples of conditions for using a default WF, specifically when specified by a standard, will be explained in detail. In this case, as previously explained, the default WF may be specified by a standard as one of the WFs that all terminals unconditionally support, or it may be a default WF configured by a base station.

[0202] First, specific channels may be restricted to unconditionally use the default WF. In particular, the standard may specify that the SSB used for initial cell search, RSs including CSI-RS used for channel measurement and various other purposes, or PDCCH must unconditionally use the default WF. That is, if all the channels mentioned in the previous example are specified to use the default WF, it can be understood that the multiple DL WF feature applies only to PDSCH. In this case, even if a different WF is configured using SIB or RRC information, the base station and terminal may operate by using the default WF for the specific channels specified in the standard as in the example above.

[0203] Secondly, the conditions under which the default WF is used may be specified in the standard. In this case, the transmission and reception of the channel described in the first method may be specified as one of the conditions. As another example of a condition, the RRC state of the terminal may also be used as one of the conditions for determining whether to use the default WF. For example, as shown in FIG. 5, the standard may specify that all or part of the transmission and reception channels use the default WF depending on the RRC state of the terminal. For example, all transmission and reception channels of a terminal in the RRC IDLE / INACTIVE state may be restricted to using the default WF (501). Alternatively, the standard may specify that the default WF be used for a specific channel among the transmission and reception channels in the RRC IDLE / INACTIVE state (502, 503). As another example, if the terminal does not receive information about the WF from the base station via SIB, RRC message, or DCI information, it may be made to operate only with the default WF. Information regarding the WF being used, including whether to use a default WF for specific channels and resources, may be provided directly; however, the base station may indirectly indicate that a default WF is being used by providing no information. In another scenario, the default WF may be specified to be used if a communication quality issue, such as a link failure, occurs during the process of the terminal communicating with the base station or cell. Situations in which the terminal and the base station determine that there is a problem with the communication link can occur in various cases, and the terminal's procedures accordingly may be defined differently. For example, there may be cases where the random access procedure is performed again in the relevant cell, or where the cell re-selection procedure is performed in another cell. In such cases, the terminal may perform the corresponding operation using the default WF.Alternatively, the standard may specify that when a terminal requests retransmission because it failed to receive a specific PDSCH, the retransmitted PDCCH or PDSCH will use the default WF instead of the pre-configured WF. Another example is that the base station may set a period during which only the default WF is used. For instance, a timer can be activated periodically or arbitrarily based on instructions from the base station to restrict the use of only the default WF, ignoring all existing settings during the timer's operation. Conversely, restrictions can be placed so that other WFs other than the default WF are applied only when a specific timer is active. The terminal may then use the default WF once the timer expires. Another example to consider is the case where a scheduled resource cannot be received by the configured other WF. For example, when multiple channels are transmitted via multiplexing, a terminal can receive multiple channels simultaneously. In this case, there are instances where there is no problem in transmitting and receiving each channel even if different WFs are used for each channel, whereas there may be instances where it is impossible to use different WFs for transmission and reception, or where such cases are not supported by the base station or the terminal. For instance, when channels transmitted and received via WF A and WF B, which do not support multiplexing, overlap in the same time resource, a situation may arise where the terminal must determine which WF A or WF B will be used or which of the two channels to receive. In such cases, a rule for determining which channel to receive may be specified in the standard, and a rule for determining which WF has priority may also be specified in the standard.For example, if WF A and WF B contain a default WF, the default WF is used, and if they do not contain a default WF, both channels are to use the default WF, or a separate rule may be provided in the specification regarding which of the two WFs has priority.

[0204] Meanwhile, similar to a terminal, a base station may also provide a choice of which WF to use as the default WF from among the multiple WF candidates supported by the relevant RAT standard, considering factors such as achieving a specific purpose or the base station's primary communication channel environment. In other words, cases where the default WF is selected by the base station may also be considered. On the other hand, the default WF set by the base station may be applied in all cases or only in specific cases. For example, the default WF set by the base station may operate only when the RRC CONNECTED state is active or after receiving system information, while operating with the default WF specified in the standard in other cases. In such cases, the terminal can obtain information about the base station's default WF through MIB or SIB information. At this time, the WFs of the channels received by the terminal to obtain the MIB or SIB use the WF specified in the standard, and if the default WF set by the base station is not one that it supports, it may determine that communication with that base station or cell is impossible and search for another cell.

[0205] Meanwhile, when most channels, including channels related to initial access such as SSB, are transmitted and received using the default WF set by the base station, communication with that cell can be restricted by making it impossible for a terminal that does not support the default WF to perform the process of receiving the cell's channel and obtaining information. However, since it is unclear from the terminal's perspective which cell uses which WF, going through the cell search process without knowing the default WF of each cell can be a significant burden. Therefore, methods to reduce the burden of the cell search process for a terminal communicating with that cell or base station may be considered.

[0206] The first method involves neighboring cells or base stations providing information. For example, assuming that Cell A's default WF is configured among WFs that are not mandatory WFs that all terminals are required to support, Cell B, which operates with a mandatory WF that all terminals must support, can provide information regarding Cell A's WF. This information can then be provided to terminals capable of supporting that WF, or at least those capable of supporting Cell A's default WF, to enable them to communicate with Cell A. In other words, the base station can be utilized for the purpose of enhancing the performance of high-performance terminals that support various WFs, such as for terminals used for specific purposes or as a method to improve communication performance in specific channel environments. However, as a prerequisite, this may be subject to the restriction that it must operate in conjunction with a base station or cell that operates a WF supported by all terminals as the default WF. For example, information regarding Cell A can be provided to the terminal as system information of Cell B. Specifically, this may be included when providing the terminal with information about cells connected to Cell B or base stations surrounding Cell B. Meanwhile, generally, to support a terminal's handover or movement to another cell, the terminal is required to perform a neighboring cell RRM measurement rather than the currently serving cell. When configuring which cell to perform the channel measurement on, the list of cells to be measured may be configured differently depending on the WF supported by the terminal. For example, for a terminal capable of supporting WF 1, WF 1 can be set as the default WF to measure the channel of the serving cell X under specific conditions or periodically. In other words, a terminal that does not support WF 1 is not configured to perform channel measurements of cell X, and it can be assumed that no information transmission or reception takes place with cell X.A terminal capable of supporting WF 1 may be configured to transmit and receive information at Cell X if it is determined, based on channel information measured at Cell X, that communicating at Cell X is more advantageous in terms of terminal and system performance than communicating at the currently operating cell. The determination of which cell is advantageous to communicate in may be made by the base station based on the terminal's channel measurement report values, or by the terminal itself considering requirements (RRM requirements), and the method and entity responsible for such determination may be distinguished according to the terminal's RRC status. In this case, the cell (or base station) that has set WF 1 as the default WF may be a neighboring cell rather than a serving cell, and in a CA environment utilizing multiple carriers, it may be a cell among the set of serving cells corresponding to each carrier where the terminal does not perform communication. In the above example, when the terminal performs a channel measurement for a specific cell, both channel measurements based on the default WF set by the base station and channel measurements based on a WF other than the default WF among the WFs supported by that base station may be considered. Specifically, when a base station uses various WFs for signals used for channel measurement, the terminal may perform channel measurements for multiple WFs, report the results to the base station, or determine on its own which WF is most suitable, and then the base station or the terminal may operate subsequent channel transmission and reception procedures using that WF. Alternatively, when operating with different WFs for each cell, the terminal may measure the channel status of the cell corresponding to the WF supported by the terminal using the corresponding WF, and then determine which cell is most suitable for communication. Alternatively, channel measurement may be restricted to channel measurements based on WFs that all terminals specified in the standard must support, and this case may be specified in the standard as one of the specific conditions under which the default WF is used.However, for terminals that do not support the WF supported by the cell, especially those that do not support the default WF set in the cell, even if the channel for the cell can be measured, there will be difficulties in performing communication later, so it may be configured not to measure the channel for the cell in advance.

[0207] According to the first method described above, there is a limitation that in order to receive information about a base station operating with a specific WF, the terminal must operate in conjunction with a base station operating with a WF supported by all terminals. As an alternative method free from this limitation, a cell search method distinct by WF supported by the base station or cell can be specified in the standard. Specifically, as a cell search method distinct by WF, a synchronization raster design different for each WF can be considered. A synchronization raster is designed to reduce the burden on the terminal during cell search and refers to the location within the frequency band where the SSB is transmitted. Therefore, if the synchronization raster for SSB transmission is designed to be distinct by WF, the terminal can determine which frequency band location and which WF is used to transmit the SSB, thereby reducing the time and burden consumed during the terminal's cell search. In this case, the SSB design can be different for each WF. That is, the overall configuration of the SSB, including the SSB bandwidth and the number of OFDM symbols, along with the SSB transmission location, can be designed differently for each WF and specified in the standard. Alternatively, the SSB may be based on the same design with the same WF applied, but the default WF used in the corresponding frequency band may be distinguished differently based on the location where the SSB is transmitted and specified in the standard. In this case, while the burden of cell search for the terminal can be reduced, it may impose restrictions on the base station using the desired WF for the frequency band. This is because the default WF for a specific frequency band is specified in the standard in advance.Conversely, even within a specific frequency band, multiple default WFs may be supported depending on the base station's selection. However, cases may also be considered where different synchronization rasters or SSB designs are applied for each WF to distinguish them, and the SSB is transmitted at the corresponding frequency location according to the WF selected by the base station. In this case, it is guaranteed that the base station can select a WF regardless of the frequency band; however, as more synchronization rasters and SSB designs are supported for various types of WFs within the same band, the burden on the terminal to perform cell discovery may increase. That is, since the terminal does not know which WF the base station will use in a specific cell, it is necessary to search for all synchronization rasters corresponding to the WF supported by the terminal even within a single cell.

[0208] Specific terms used in this disclosure may be changed, and the content of this disclosure is not limited by the examples described herein.

[0209] <Second Embodiment>

[0210] A second embodiment of the present disclosure describes a method for a terminal to be indicated by a channel waveform when a base station uses a plurality of waveforms (WF) for channel transmission and reception. Specifically, specific methods for a base station to set information or various design methods for a related control channel are described in order to provide the terminal with information regarding the waveform used for a specific channel.

[0211] Referring to [Table 9], the methods for determining the WF used in a specific channel or resource are classified according to various cases. At this time, the various methods by which the terminal determines the WF through the information included in the DCI format corresponding to case 3 are explained in detail. First, DCI formats can be broadly classified into two types. One is a DCI used for the scheduling purposes of PDSCH or PUSCH (i.e., DCI for scheduling grant), and the other is a DCI used for purposes other than scheduling (i.e., DCI for non-scheduling grant or DCI for other purpose). When a base station indicates a WF through a DCI for scheduling grant, it can be understood that it is indicating the WF used when transmitting or receiving the PDSCH or PUSCH corresponding to the PDCCH containing that DCI format. Furthermore, when indicating a WF via a DCI for scheduling grant, a direct indication method or an indirect indication method may be used.

[0212] When specifying a WF using a DCI for scheduling grant, the direct specification method involves defining a field for the WF among the fields of the DCI format and directly indicating which WF is being used through that field. In this case, as mentioned in the first embodiment, a specific location within the bitmap is determined for each WF supported by the base station or each WF supported by the standard, so the bit at the location of the WF to be specified can be transmitted as '1' to indicate it. Alternatively, a corresponding codepoint value for each WF is defined by the standard or the base station, and the codepoint value corresponding to the WF to be specified can be included in the WF-related field information and transmitted. In this case, depending on which WF is specified in the DCI format, the types and interpretation methods of other fields within the same DCI format may vary. For example, different FDRA (Frequency domain resource allocation) or TDRA (Time domain resource allocation) and MCS (Modulation and Coding scheme) tables can be used for each WF, and accordingly, the size of the table, that is, the maximum number of information bits that make up the field, may vary for each WF.

[0213] When specifying a WF using DCI for scheduling grant, the indirect specification method determines the WF based on the values ​​used in fields other than the field that directly specifies the WF. In this case, various fields can be involved in determining the WF. For convenience, the following explanation describes a method for indirectly specifying a WF, assuming that the base station fundamentally supports CP-OFDM as the default WF and additionally supports DFT-s-OFDM as an optional WF for coverage improvement or energy saving. First, it is possible to indirectly indicate which WF will be used through resource-related information among the PDSCH scheduling information contained in the DCI format within the PDCCH. The resource information provided by the DCI format is broadly divided into frequency resources and time resources for the transmission of the PDSCH. Specifically, the frequency resources for PDSCH transmission are provided in RB units, and Resource Allocation (RA) types are broadly classified into two types depending on whether only consecutive RBs are allocated for channel transmission or whether the allocation of non-consecutive RBs is also permitted. In this case, for discontinuous RB allocation, the bit information corresponding to each RB or RB group (RBG) within the bitmap indicates which RBG is being used, and this method is referred to as type 0 RA. Meanwhile, a method that allows only continuous RBs and calculates a resource indication value (RIV) based on the index of the RB where the PDSCH begins to be transmitted and the length of the continuously used RBs, and provides this as frequency resource allocation information, is referred to as type 1 RA. In this case, there may be instances where it is impossible to transmit discontinuously over a frequency resource for a specific WF.For example, in the case of DFT-s-OFDM, transmission is based on OFDM, but because it is a waveform that applies transform precoding (TP) before subcarrier mapping to achieve the same effect as single-carrier transmission using multiple subcarriers, it is difficult to allocate frequencies to each RB or RBG forming the subcarrier as in conventional CP-OFDM. Even if DFT-s-OFDM-based channel transmission is allocated to discontinuous RBs or RBGs, it may be impossible to transmit another WF-based channel in the frequency resources between RBGs to which a single DFT-s-OFDM-based channel is allocated. In other words, it may be impossible to transmit another WF-based channel between the frequency resources of DFT-s-OFDM-based channels transmitted by applying a single transform precoding within the same symbol.

[0214] FIG. 6 is a diagram showing an example of a method for indirectly determining the WF of PDSCH according to a resource allocation type according to an embodiment of the present invention.

[0215] Before explaining FIG. 6, it is assumed (600) that in all cases of the example, different WFs are configured to be used for PDCCH and PDSCH reception, respectively. For example, PDCCH transmission and reception use a WF specified in the standard or a WF configured by the base station (WF A in FIG. 6), while PDSCH transmission and reception are configured to use a different WF (WF B in FIG. 6) due to the specification in the standard, the base station's system information, or RRC information. Although WF A and WF B in FIG. 6 are not limited to specific WFs, for convenience in the following description, it is exemplarily assumed that WF A is CP-OFDM and WF B is DFT-s-OFDM.

[0216] Referring to 601, it illustrates a case where the resources transmitted by PDCCH (604), namely the CORESET resources, and the time and frequency resources of PDSCH (605) scheduled by the PDCCH partially overlap. In this case, since it is easy for the terminal to receive the signal with a single WF when receiving it, it may be specified to receive it with the same WF even if the WFs of the previously set PDCCH (604) and PDSCH (605) are different. At this time, since the relationship between the resources transmitted by PDCCH (604) and PDSCH (605) cannot be known until the resource allocation field within the DCI format in the PDCCH is checked, the WF of PDSCH (605) can be changed to use the same WF as the WF of PDCCH (604). That is, although the WF set in advance was WF B, if resource allocation is made as in the case of 601 after receiving PDCCH (604), it may implicitly mean using WF A (606) to transmit and receive PDSCH (605). On the other hand, there may be situations where using different WFs is not supported in the resource allocation situations of PDCCH (604) and PDSCH (605) shown in 601. For example, as explained earlier, if DFT-s-OFDM is set to be used for PDSCH (605), resource allocation as in 601 may not be supported. To explain specifically the resource allocation relationship between PDCCH (604) and PDSCH (605) in 601, refer to 607. During a specific time interval (e.g., specific symbols) (T1), the transmission of PDCCH (604) and PDSCH (605) occurs simultaneously, followed by a interval (T2) (608) in which only PDSCH (605) is transmitted.At this time, in the interval (T1, 607) where PDCCH (604) and PDSCH (605) transmissions occur simultaneously, the frequency intervals allocated to each PDCCH (604) and PDSCH (605) may be continuous, but they may also be discontinuous, as in the case of 609 and 610 of 601. Referring to 601, in the interval T1 (607), the frequency resources allocated to PDSCH (605) are located apart as F1 (609) and F2 (610), and PDCCH (604) is transmitted at the frequency between 609 and 610. When using the waveform of DFT-s-OFDM, since the signal is transmitted and received as if using a single carrier by applying TP to a set of multiple subcarriers, the existing DFT-s-OFDM transmission method, which applies only one TP to a symbol transmitting a single PDSCH (605), cannot support resource allocation of 601, so it can implicitly mean (606) that CP-OFDM used in PDCCH (604), rather than DFT-s-OFDM, must be used for receiving PDSCH (605). Therefore, methods to indirectly determine which WF to use for resource allocation that cannot be supported for a specific WF can be specified in the standard. Meanwhile, if the position of 604 is assigned to be located at the top or bottom of 605, that is, if the magnitude of one of F1 (609) or F2 (610) is 0, then since the frequency resources to which DFT-s-OFDM is assigned in a specific time resource are continuous, DFT-s-OFDM (or WF B of FIG. 6) can be used for PDSCH (604) according to the existing settings.

[0217] Referring to 602, compared to 601, the resources (611) where PDCCH is transmitted and the resources (612-613) where PDSCH is transmitted do not overlap in terms of time resources. However, since the resources for transmitting PDSCH are allocated discontinuously, PDSCH is transmitted through two sets of frequency resources (612 and 613, respectively). As previously explained, in the case of DFT-s-OFDM, all frequency resources to which a single TP is applied must be continuous; therefore, if they are separated like 612 and 613, it can cause problems in receiving the channel. This is because, in order to transmit PDSCH using WF B according to the existing configuration, the base station cannot transmit other channels in the frequency resources (F3, 614) between 612 and 613. If the base station accepts these constraints, it can receive 612 and 613 simultaneously by applying DFT-s-OFDM even if discontinuous resource allocation occurs, and when applying TP, it must also consider F3 (614) along with the frequency resources of 612 and 613. However, considering the efficient resource usage of the base station, it is more likely to limit channel transmission and reception based on DFT-s-OFDM with discontinuous resource allocation rather than this approach. Therefore, if the frequency resource allocation of the PDSCH scheduled via 611 is discontinuous, this may indirectly indicate (615) that the PDCCH uses WF A (or CP-OFDM) instead of the previously configured WF B (or DFT-s-OFDM). In this case, the WF used instead of WF B may be provided in advance through the standard or the base station's settings.

[0218] Meanwhile, although the preceding explanation was based on the DFT-s-OFDM method supported by existing standards, where only a single TP is applied, if a TP is applied separately to each frequency resource (609 and 610 or 612 and 613) that is transmitted discontinuously, unlike the existing DFT-s-OFDM, the terminal can receive DFT-s-OFDM signals by applying different TPs to each frequency resource. In other words, from the terminal's perspective, this can be viewed as equivalent to receiving two DFT-s-OFDM signals that are multiplexed from the frequency resources, and the standard may also specify how a single channel mapped to multiple DFT-s-OFDM signals can be interpreted. In the case of base stations or terminals that generally support these operations, it is possible that the method of indirectly determining the WF, as explained in the previous example, will not be utilized.

[0219] Referring to 603, it can be seen that the resources (616) to which the PDCCH is transmitted and the resources (617) allocated to the PDSCH scheduled by the PDCCH do not overlap in time resources, and that the resource allocation of the PDSCH (617) is continuous in frequency resources. When the resources of the PDSCH (617) are allocated as in 603, the terminal determines that there is no problem in receiving the PDSCH (617) transmitted to the WF B (or DFT-s-OFDM) and can receive the PDSCH (617) transmitted to the WF B as previously provided.

[0220] As explained earlier, while there is a method to determine which WF to use based on the relationship between the PDCCH and the resources of the PDSCH it schedules, a method to determine which WF to use based solely on the resource allocation method used, before identifying the relationship of allocated resources, may also be considered. For example, as previously explained, there are type 0 RA and type 1 RA, and a bit indicating which RA type is used is allocated at the beginning of the frequency resource allocation field in the DCI format. In this case, if information indicating that frequencies are allocated including type 0 RA, which allows for non-consecutive PDSCH frequency resource allocation, appears in the RA type indication field, the terminal can determine the PDSCH's WF as using WF A instead of WF B. Conversely, if information indicating that only type 1 RA, which allows for consecutive frequency allocation, is used appears in the RA type indication field, it can be interpreted as using WF B according to the existing settings.

[0221] Another method of indirectly indicating via DCI is to imply which WF is to be used through the location of the indicated resource. For example, a base station can pre-configure which WF is to be used for a specific frequency resource (e.g., BWP) or a specific time resource (e.g., slot, subframe, or frame unit). Subsequently, based on the location of the resource of the PDSCH scheduled by the PDCCH, it can be determined which WF can be applied to the corresponding PDSCH using information configured by the base station. For example, when WF A is configured for BWP 1 and WF B is configured for BWP 2, if the terminal is instructed via DCI to receive the PDSCH at BWP 1, this implies that the PDSCH is to be received using WF A, and if it is instructed to receive the PDSCH at BWP 2, this implies that WF B is to be used.

[0222] Another method involves using look-up tables that provide the information necessary for scheduling PDSCH. For instance, if MCS tables or TDRA (time domain resource allocation) tables are defined in the standard, and an index of that table is indicated via DCI, information regarding the PDSCH can be obtained based on the information corresponding to that index. In this case, if the standard specifies which WF to use for each index, information about the WF can be obtained indirectly while acquiring MCS or TDRA information. Additionally, the WF can be determined based on the frequency size allocated for PDSCH transmission. Indirect instructions can be given by using WF A if the PDSCH is scheduled using a number of PRBs smaller than the standard PRB count defined in the standard or provided by the base station, and WF B if it is scheduled using a larger number of PRBs. In particular, low PAPR waveforms such as DFT-s-OFDM are used to reduce PAPR; since the PAPR of CP-OFDM waveforms increases as more frequency resources are used, it may be specified that CP-OFDM should be used up to a certain number of PRBs, and DFT-s-OFDM should be used when more PRBs are allocated. Meanwhile, DFT-s-OFDM or waveforms developed based on DFT-s-OFDM may have constraints that the amount of resources used must have a specific value. Currently, when applying DFT-s-OFDM waveforms for the uplink in 5G, there is a constraint that the number of RBs allocated to the uplink must be a multiple of 2, 3, or 5.Therefore, in the case of DFT-s-OFDM-based waveforms, if the corresponding conditions are specified, a method of indirectly indicating the WF may be considered, such as using DFT-s-OFDM when the conditions are satisfied and using another waveform provided by the standard or base station settings when the conditions are not satisfied. Alternatively, the WF used may be provided in correspondence with the number of repetitions of the PDSCH specified by DCI. For example, since DFT-s-OFDM has a larger coverage than CP-OFDM, it may be considered that DFT-s-OFDM is used when repetitions are not required and are not set, or when fewer repetitions than a set reference value are set, and CP-OFDM is used otherwise.

[0223] Meanwhile, in addition to the method of indirectly determining the WF based on the values ​​indicated by fields within the DCI as previously explained, WF information can also be indirectly implied during the process of transmitting DCI information to the terminal. For example, if the RNTI used during PDCCH transmission is configured to be distinct for each WF, it can indirectly indicate which WF the PDSCH is scheduling. In this case, the types of DCI fields and the sizes of each field may differ depending on the RNTI used for PDCCH transmission. That is, because the characteristics of each WF differ, DCI information can be interpreted based on differently defined fields. Another example is that the search space receiving the PDCCH may be distinguished by WF. When setting the search space for the terminal, additional WF information related to the PDCCH transmitted within that search space may be provided to assist the terminal in determining the WF. In this case, the provided WF information may apply to both the PDCCH received in the search space and the PDSCH scheduled by that PDCCH, or it may apply to only one of the two. Another method to apply different WFs using DCI formats distinguished by another method may be considered. DCI formats can primarily be distinguished based on the RNTI, and DCI formats with the same RNTI can be identified through the values ​​of related fields, such as the indicator field within the DCI. Once the DCI format is determined in this manner, it is possible to indirectly determine which WF uses the PDSCH scheduled by that DCI, depending on the DCI format. At this time, the DCI format corresponding to each WF may be provided to the terminal by the standard or the base station.

[0224] When a WF is specified using a DCI for scheduling grant, usually only the WF information of the PDSCH or PUSCH scheduled with that DCI is specified. However, the same WF can be continuously applied to specific channels transmitting and receiving before receiving the next PDCCH. In this case, which channels can receive the same WF can be specified in the standard or configured by the base station.

[0225] When a WF is specified via a DCI for non-scheduling grant, it can be understood that the DCI includes the purpose of changing the WF. Considering that when a base station changes the WF, it is more likely to change the WF for the entire cell or the entire band of a specific BWP depending on the base station's operational conditions, rather than changing the WF used for transmission and reception by a specific terminal, the DCI may be used as a group common or cell common DCI. Alternatively, when a terminal performs semi-persistent scheduling (SPS), that is, receiving a PDSCH without a DCI for scheduling grant, the base station may transmit a DCI for non-scheduling grant that allows for UE-specific WF changes using the DCI to modify the WF used during SPS reception. When a DCI for non-scheduling grant is used for the purpose of changing the WF, the changed WF can be applied for a predefined period. For example, the specification may specify which channel or for how long the changed WF will be applied upon receiving the DCI. For example, a related timer may be defined and the changed WF may be applied only while the timer is running, or the WF may be continuously applied until it is changed to something else through another DCI. Alternatively, the WF indicated by the DCI may be applied after the timer has expired. When using a DCI for non-scheduling grant, there is an advantage that the WF can be indicated through a DCI transmitted once without the need to continuously transmit information about the WF when using a single WF across multiple channels or for a long period of time, whereas there is a problem that performance may be degraded if the terminal misses the DCI.A terminal that misses the DCI changing the WF will not be able to properly receive subsequent transmitted PDCCH or PDSCH, and will therefore determine that the RRC CONNECTION has been lost and perform procedures such as random access. To prevent this problem, if the PDCCH uses only the default WF without being affected by WF changes, information can be provided to the PDCCH to help determine whether the terminal has missed the WF change signal. For example, if the index indicating the total number of downlink channels the terminal is supposed to receive using the DAI (Downlink Assignment Index) differs from the index indicating the number of downlink channels the terminal actually received, and subsequent PDSCH is not properly received, the terminal may suspect that the WF has changed and notify the base station, such as by reporting the details to the base station, thereby taking measures to resolve the problem.

[0226] Meanwhile, in contrast to indicating and determining WFs that are used dynamically through DCI, there are methods for setting WFs semi-statically, and cases 1 and 2 in [Table 9] correspond to such cases. Case 1 involves obtaining WF information through system information, which primarily allows obtaining WF information for channels transmitted and received by the terminal before establishing a separate RRC connection, such as paging PDSCH. In this case, information from the MIB can also be used to obtain WF information in addition to the SIB. While the contents described in the first embodiment explained how to determine WF information for subsequent channels after obtaining WF information through the SIB or MIB, this embodiment specifically describes a method for obtaining the SIB using various WFs.

[0227] FIG. 7 is a diagram illustrating an example of a method for distinguishing WF used according to CORESET#0 setting according to one embodiment of the present invention.

[0228] Referring to FIG. 7, a terminal can obtain information on CORESET#0 (701, 702) that is distinguished through information such as the base station's MIB. Each CORESET#0 (701, 702) is information corresponding to a distinguished WF, and may include CORESET#0 (701) which operates as a WF supported by all terminals or a default WF, considering terminals that do not support multiple DL WF features. Additionally, the base station may also provide information on CORESET#0 (702) that corresponds to a WF that is not the default WF, thereby providing an opportunity for a terminal supporting the WF to select the WF to use when receiving system information and performing processes such as paging and random access.

[0229] Referring to FIG. 7, if the terminal wants to operate in the default WF, it can receive (703) a PDCCH transmitted within 701 using the default WF, and receive (704) a PDSCH scheduled by the PDCCH using the default WF.

[0230] If the terminal wishes to use another WF provided by the base station (e.g., WF B of FIG. 7), it may receive (705) the PDCCH transmitted within 702 using WF B, and receive (706) the PDSCH scheduled by the PDCCH using WF B. At this time, the PDCCH received by the terminal may use a default WF or another WF specified in the standard to be used for receiving the PDCCH, and may use WF B only for receiving the PDSCH. According to an embodiment, if the terminal fails to properly receive 705 and 706, or satisfies a pre-specified condition requiring the reception of the default WF, the terminal may receive channels 703 and 704 using the default WF. Additionally, the same approach may be considered for other CORESETs as well as CORESET#0 for obtaining the SIB.

[0231] FIG. 8 is a diagram illustrating an example of a method using a WF pattern to support various WFs in a time resource according to an embodiment of the present invention.

[0232] Figure 8 explains a method of representing a WF pattern using a bitmap among WF patterns for supporting various WFs in time resources.

[0233] Referring to FIG. 8, the time unit in which the WF pattern is applied, i.e., the indication period (801), is specified in advance, and the WF pattern can be seen as an expression of which WF is used in which interval within that period. At this time, the WF used may be thought to be repeated every 801 period, or the timing for applying the pattern (e.g., frame number, etc.) may be specifically presented. Referring to FIG. 8, the base station supports WF A, WF B, and WF C, and the duration for using each WF may be determined (802, 803, 804). In the case of an RRC CONNECTED terminal, the base station can directly know which WF the terminal prefers, so it can inform the terminal which WF is being used; however, in the case of transmitting a channel for an RRC IDLE / INACTIVE terminal, i.e., in a situation where the terminal does not know which WF it prefers, the terminal may be informed of the duration of a specific WF, such as 805, 806, and 807. That is, based on the bit information transmitted in 805, 806, and 807, the terminal can obtain information on when the preferred WF is used and transmitted, and perform necessary operations in a state where RRC CONNECTION is not established, such as receiving necessary system information during the corresponding interval, or performing paging operations or channel measurement operations. Specifically, each bit in the bitmap represents a slot(s), frame(s), TTI unit, or symbol unit, and if it appears as '1', it may mean that the corresponding WF is being used, and if it appears as '0', it may mean that the corresponding WF is not being used. For example, in FIG. 8, 805 represents bitmap information indicating the interval where WF A is used, and by referring to 805, the interval 808 is marked as '1', which means that the base station is using WF A, and the interval 809 is marked as '0', which means that the base station is not using WF A.If the base station is constrained to support only two WFs (e.g., WF A and WF B), the period for using WF A is indicated as '1' and the period for using WF B is indicated as '0', thereby providing information about the supported WFs to the terminal using only one bitmap information. However, as shown in FIG. 8, if three or more WFs are supported, at least two bitmaps may be required. FIG. 8 illustrates a case where three bitmap informations (805, 806, 807) are supported to match the number of supported WFs. According to an embodiment, if one of these bitmaps represents the two WF informations as '1' and '0' as described above, when an additional WF is supported (e.g., WF C), only the bitmap for WF C is provided separately, and three types of WF pattern information can be obtained through the two bitmap informations. While this method has the advantage that the terminal is provided with the type of WF used for a specific channel, selects a suitable WF based on the terminal's preference and the channel environment it experiences, and transmits and receives the channel in that section, it has limitations in that it lacks flexibility in terms of utilizing base station resources and may inevitably cause delays in transmitting and receiving the channel depending on which WF the terminal selects.

[0234] Meanwhile, for RRC-CONNECTED terminals, methods can be used to dynamically notify them via DCI or semi-statically notify them via RRC settings. In this case, if a semi-persistent scheduling (SPS) PDSCH is configured for the terminal, the PDSCH can be transmitted without transmitting DCI, and a method to determine the WF may be required when the SPS PDSCH is configured. SPS PDSCH is one of the methods for transmitting PDSCH, and in the following description, SPS PDSCH is briefly referred to as SPS. A base station can configure multiple SPS for a terminal, and when the SPS is activated, information such as the resources for receiving the SPS and the information for transmitting ACK / NACK related to SPS reception must be provided to the terminal in advance through the base station's settings and specifications. In this case, the SPS may be activated after a given time following the base station's RRC configuration, or it may be activated after receiving a DCI instructing the activation of a pre-configured SPS.

[0235] FIG. 9 is a diagram showing an example of a method for determining WF by a terminal with SPS set according to an embodiment of the present invention.

[0236] Referring to FIG. 9, after the SPS is activated via RRC or DCI, the base station can transmit PDSCH according to the SPS at a time pre-configured to the terminal (901). At this time, when providing information about the SPS, the terminal can be provided with information on which WF to use. Referring to 902, the terminal receives the SPS (downlink data according to the SPS) based on the WF information provided. The terminal may receive WF-related information when receiving the SPS configuration via an RRC message, or it may use the WF used by the resource receiving the SPS as a basis for receiving the SPS even if there is no WF information directly in the SPS. For example, the terminal may use a WF configured in association with the BWP receiving the SPS or a WF configured in association with the timing at which the SPS is transmitted. Alternatively, the terminal may obtain WF information based on the DCI that activates the SPS. If the base station needs to, it is also possible to instruct the terminal to switch the WF through the DCI when using a different WF other than the WF associated with the previously configured SPS.

[0237] When the SPS is activated, the terminal can receive the SPS from a designated resource and then transmit an ACK or NACK to determine whether it has been properly received, thereby allowing the base station to determine whether it needs to retransmit the SPS information. For example, if the terminal properly receives the SPS as in 901, the terminal can transmit an ACK (903) information to the base station (904) indicating that it has properly received the information transmitted via the SPS. Meanwhile, referring to 905, if the terminal does not properly receive the SPS, the terminal can transmit a NACK (907) information to the base station (908) indicating that it has not received the information transmitted via the SPS (906). At this time, the base station can perform a procedure to retransmit the information that should be transmitted via the SPS when the terminal fails to properly receive the SPS (906) that it is supposed to receive, and the information can be dynamically transmitted through a PDSCH scheduled by DCI. Referring to 909 and 910, the base station receives (908) a NACK (906) transmitted from the terminal, and then transmits (911) a PDCCH (910) to the terminal that schedules a PDSCH (909) to retransmit information that needs to be transmitted during the 906 process. At this time, referring to 909, the terminal may receive information (912) using WF B instead of the previously used WF A for the PDSCH to receive the retransmitted information. Information that the PDSCH (909) must be received using WF B may be indicated by the PDCCH (910) that schedules the PDSCH (909), but the case where information about the WF is not provided to the PDCCH (910) and the retransmission occurs may also be considered. At this time, the base station may set the retransmitted PDSCH (909) to use a different WF or specify it in the standard. In other words, the WF used in PDSCH is distinguished based on whether the information transmitted through PDSCH is a retransmission or new information.For example, when receiving SPS at 902 and 906, the terminal can receive PDSCH using CP-OFDM. However, since there is a case (905) where the signal was not properly received when using CP-OFDM, the terminal can receive the retransmitted PDSCH (909) using a waveform such as DFT-s-OFDM, which has a wider coverage. At this time, the waveform of the received PDSCH may also use DFT-s-OFDM (WF B in FIG. 9), or, considering that the coverage of the PDSCH is wider than that of the PDSCH, CP-OFDM (WF A in FIG. 9) may be used in the same way as used in the SPS. Although FIG. 9 describes the retransmission of SPS, the methods described above can be applied commonly to all retransmitted channels, including not only SPS but also PDSCH scheduled by DCI.

[0238] In addition, in the case of the embodiment for the above SPS, it can be similarly applied to the configured uplink transmission (i.e., CG-PUSCH transmission) for uplink transmission.

[0239] In the case of configured uplink transmission (configured grant), the terminal can transmit uplink data according to a preset period of scheduling information, such as DCI. Configured uplink transmission can be configured grant type 1 or configured grant type 2. In configured grant type 1, configuration information, such as resource configuration information of CG-PUSCH regarding the uplink transmission period, is set via an RRC message (e.g., an RRC reconfiguration message), and accordingly, the terminal can transmit uplink data without a separate activation command. In the case of configured grant type 2, configuration information for configured uplink transmission is provided via an RRC message, and when a separate activation command is received through PDCCH (DCI), configured uplink transmission is activated and the terminal can transmit uplink data.

[0240] Even in such cases, when the configured uplink transmission is enabled via RRC or DCI, the base station may also configure which WF to use to the terminal when providing configuration information for the configured uplink transmission. The terminal may receive WF-related information when receiving the configuration for the configured uplink transmission via an RRC message, or even if there is no WF information directly in the configured uplink transmission, it may use the WF used by the resource configured to transmit the configured uplink transmission as a basis for transmitting the configured uplink transmission. For example, the terminal may use a WF configured in association with the BWP transmitting the configured uplink transmission or a WF configured in association with the timing of the transmission of the configured uplink transmission. In this case, if the WF associated with the resource of the repeatedly transmitted CG-PUSCH is different, a different WF may be used for each CG-PUSCH transmission, or the WF used may be determined according to a defined rule. For example, the WF used for the initial CG-PUSCH transmission may be used until the CG-PUSCH transmission is disabled, or it may be configured or specified in the standard to use a different WF when a specific event occurs, such as a failure in the CG-PUSCH transmission.

[0241] Alternatively, the terminal may obtain WF information based on the DCI that enables the configured uplink transmission. If the base station requires it, it is also possible to instruct the terminal to switch the WF via the DCI when it intends to use a different WF than the one associated with the previously configured uplink transmission.

[0242] Meanwhile, the WF used for the above CG-PUSCH transmission may be indirectly determined by other settings required for transmission to PUSCH. For example, if frequency hopping is not set for PUSCH transmission, only WF A may be used, and if frequency hopping is set, an operation in which WF B or multiple WFs are used alternately according to a rule may be considered. Additionally, when a repetition operation is set, a specific WF may be indirectly associated and used, or a case in which multiple WFs are used for each information that is repeatedly transmitted and received may also be considered. Furthermore, according to an embodiment, the terminal checks whether the base station has properly received the configured uplink transmission, and if it is determined that it has not been properly received, the terminal may perform a retransmission procedure. In this case, the terminal may transmit an uplink retransmission signal using a different WF B instead of WF A, which was used for the transmission of the existing configured uplink transmission. Since the operation related to this is similar to the retransmission operation of the above SPS, a detailed explanation thereof will be omitted.

[0243] <Third Embodiment>

[0244] The third embodiment of the present disclosure describes a DCI design method for simultaneously scheduling multiple terminals using a specific waveform. Specifically, it describes a method and necessary procedures for a base station to simultaneously schedule multiple terminals using a DFT-s-OFDM waveform. Although the methods of the present disclosure are described based on DFT-s-OFDM, they can be applied equally to waveforms that have been developed and modified based on DFT-s-OFDM, and the same methods can be applied to other waveforms having the same characteristics. That is, when creating channels for multiple terminals and performing frequency domain multiplexing (FDM) to transmit simultaneously, the methods described below can be utilized for waveforms that require information related to other terminals.

[0245] FIG. 10 is a diagram showing an example of a method for transmitting data to a single terminal and a method for transmitting data to multiple terminals using a DFT-s-OFDM waveform according to an embodiment of the present invention.

[0246] Figure 10, 1001, describes a channel generation method when applying DFT-s-OFDM to channel transmission and reception for a single terminal without FDM. The base station generates a transport block (TB) to be transmitted to the terminal, then sequentially applies CRC attachment, channel coding, rate matching, etc., and applies modulation (e.g., QAM) based on the generated bit stream to obtain multiple data symbols (1002) transmitted in a single OFDM symbol. In the case of CP-OFDM, the generated 1002 is mapped to a subcarrier corresponding to a resource pre-configured to the terminal and a signal is generated through the process of performing IFFT. However, when generating a signal based on a DFT-s-OFDM waveform, TP is performed on 1002 (1003) to give the effect that the signal transmitted by mapping to multiple subcarriers operates as a single carrier. Samples generated after 1003 can be mapped to the resources configured for the corresponding terminal and the corresponding subcarriers through process 1004, and an IFFT can be performed to generate a signal to be transmitted to the terminal. This is the same as when a terminal transmits on the uplink channel using DFT-s-OFDM in 5G. In this case, in the uplink, the terminal can receive settings or instructions from the base station regarding which precoding to apply for beamforming, etc., after applying the TP, whereas in the downlink, the application of precoding, etc., can only be performed by the base station's implementation. In 5G, the transmission of information by applying DFT-s-OFDM in the uplink is supported for the purpose of reducing the terminal's PAPR and increasing coverage, and generally, a TP generated based on the number of subcarriers per OFDM symbol allocated to the terminal for uplink transmission (i.e., the number of REs) is applied to a single OFDM symbol.

[0247] Unlike the uplink, where data is transmitted from the perspective of a single terminal, for downlink transmission, the base station can transmit data for multiple terminals by FDMing it from a single OFDM symbol. Referring to 1005, methods for how TP is applied to each terminal when a DFT-s-OFDM waveform is applied to a downlink that has been FDMed for multiple terminals are described in 1006 and 1007.

[0248] Figure 1006 of FIG. 10 illustrates a case where distinct TPs are applied to each terminal. It is assumed that signals transmitted to a total of N terminals, from a signal for terminal 1 (1008) to a signal for terminal N (1009), are FDMed from a single OFDM symbol. Multiple data symbols (1010 and 1011) that must be transmitted to each terminal in the corresponding OFDM symbol may each have a TP (1012 and 1013) applied to them. That is, a TP is applied to the data symbol (1010) for terminal 1 via 1012, and a TP is applied to the data symbol (1011) for terminal N via 1013, and so on, with TPs for a total of N terminals being applied separately. The samples to which the TPs of each terminal are applied can be multiplexed in the frequency dimension during the process of performing subcarrier mapping and IFFT through 1014. At this time, the size of the TP is equal to the number of subcarriers allocated to the downlink transmission of each terminal, and therefore, the size of the TP of each terminal may vary depending on the number of subcarriers allocated to the terminal. Additionally, although omitted in FIG. 10, the base station may apply different precoding to each terminal after applying each TP. When the method described in 1006 is applied to the base station, the method of receiving a signal based on DFT-s-OFDM from the perspective of each terminal may be the same as when the method described in 1001 is applied to the base station. However, considering that the motivation for applying the DFT-s-OFDM waveform to the downlink is to reduce the PAPR generated during downlink transmission to expand coverage or save energy, the effect of applying the method in 1006 may be reduced.This is because applying a DFT-s-OFDM waveform can reduce PAPR by providing the effect of transmitting information over a single carrier. Therefore, if a separate TP is applied to each terminal, it provides the effect of transmitting information over a single carrier from the terminal's perspective. However, from the base station's transmission perspective, since there are as many single carriers for channel transmission as there are terminals transmitting via FDM, the PAPR actually increases compared to transmitting a DFT-s-OFDM-based channel for a single terminal. In other words, the more terminals are transmitted via FDM using the 1006 method, the higher the PAPR becomes, and the coverage improvement or energy saving effect decreases accordingly.

[0249] In order to achieve PAPR reduction in scenario 1005, a method (1007) may be considered in which a single TP is applied to the channels of the FDM terminals to produce the same effect as transmitting channels using a single carrier in terms of base station transmission. Specifically, the process up to the stage before applying the TP can be carried out in the same way as scenario 1006. That is, multiple data symbols (1017 and 1018) are generated for each terminal from terminal 1 to terminal N (1015 and 1016) that are FDMed. However, in the subsequent process, a TP that is commonly applied to a total of N terminals may be applied (1019). That is, the size of the TP is equal to the total number of subcarriers allocated to N terminals. Meanwhile, before performing subcarrier mapping and IFFT (1020) on the samples generated after the TP is applied to the total resources allocated to N terminals, the applied precoding may be applied at the TP level or at the subcarrier level allocated to each terminal. Depending on the PAPR reduction performance, this may be restricted to being applied only in TP units, may be allowed to be applied in units of resources allocated to each terminal, or may be left freely to the implementation of the base station.

[0250] When using the method of 1006 in Fig. 10, the only additional information required in addition to the information provided when transmitting the PDSCH to the existing terminal is that the PDSCH is transmitted and received using DFT-s-OFDM, and the method of applying TP can be borrowed from the uplink. However, when using the method of 1007, there is additional information that must be provided to each terminal, and DCI designs for providing such information, as shown in 1021, may be considered.

[0251] One method to support multiple terminals using a common TP by utilizing DCI is to consider a method using group common DCI (1022). In particular, when applying the same TP to create a DFT-s-OFDM-based channel to be transmitted to each terminal, there may be elements that all terminals must have in common, along with the size of the TP, or elements that terminals must have the same value to increase the PAPR reduction effect. Specifically, terminals with the same TP applied have the same rank, DMRS type and information about the CDM (code division multiplexing) group, the location of the data symbol and DMRS symbol, the modulation order, and the rate matching pattern, which increases the potential effect of applying the same TP. Therefore, if this information is transmitted as common DCI information such as 1022 rather than being transmitted individually for each terminal, the overhead of DCI transmission can be reduced. Furthermore, when designing a group common DCI (1022) used for the purpose of supporting DFT-s-OFDM-based FDM, information that applies equally to terminals using the same TP is included in the fields within 1023 and transmitted as a value that applies commonly to all terminals, while information that needs to be transmitted differently for each terminal is transmitted individually through the fields within 1024. In this case, if there is a large amount of information to be transmitted individually to each terminal, 1022 containing only the content of 1023 or simplified content of 1024 is transmitted first, and information that needs to be transmitted individually to each terminal, such as HARQ process number, can be transmitted through a simplified UE-specific DCI.At this time, the information that is typically included in 1024 and must be individually transmitted to the terminal is information regarding which sample segment the data for each terminal was mapped to and transmitted before the TP was applied. For example, referring to 1007, this is information regarding which location in the common TP (1019) multiple data symbols (1017 and 1018) for each terminal were mapped to and transmitted. This information is necessary so that the terminal can receive the signal transmitted to a single TP, apply the TP in reverse, extract the sample segment corresponding to itself, and obtain the multiple data symbols to be received. At this time, there is no need to extract the segment where data symbols for other terminals are transmitted, and methods such as scrambling using specific codes unique to the terminal during the process of generating TB or data symbols may be considered to prevent information from being leaked to other terminals that were transmitted together via FDM.

[0252] Meanwhile, information regarding the common TP and resource-related information individually allocated to each terminal in correspondence may be transmitted via the group common DCI or via the UE specific DCI. Referring to FIG. 10, a specific field (1025) for UE A may exist within 1024 transmitted via the group common DCI for UE A, or the information may be transmitted via the support allocation field of the DCI individually transmitted to UE A or a field (1026) with a similar function. Specifically, what information needs to be transmitted is explained through 1027 to 1031.

[0253] First, the terminal can receive information regarding the common TP size (1027) that applies commonly to N terminals and the relative position Fc (1029) between the downlink BWP (1028) set for the terminal. That is, information regarding the size and position of the common TP is required. At this time, the size of 1027 may be transmitted within the field (1023) that is commonly transmitted to the terminals, or it may be provided in advance by the base station via RRC settings or transmitted through other DCI information, etc. Alternatively, the terminal may receive information regarding the common TP (1027) indirectly rather than directly from the base station. For example, if support is provided only when all terminals are allocated the same amount of resources, the terminal may indirectly determine the size of the TP (1027) provided to all terminals when the number of terminals that are FDMed together is provided. Alternatively, it may operate by assuming that the size of the TP is the same as the size (1028) of the downlink BWP allocated to the terminal, in which case there is a constraint that the size of the BWP of all FDM terminals must be the same. In this way, when the size of the BWP of the FDM terminals is set to be the same, the Fc (1029) value also becomes the same for all terminals, and only in that case can the 1029 information be transmitted through 1023. In other words, since the BWPs of N FDM terminals may be set to be the same or different, the terminals may have a common Fc or different Fc, and accordingly, the composition of the information transmitted in 1023-1026 may differ. In addition, each terminal must be provided with information about the resource (1030) allocated to each terminal within the common TP (1027). To this end, the location Fa (1031) of the resource allocated to the terminal from the starting point of the common TP and the size of the resource allocated to the terminal may be provided.Alternatively, information regarding 1031 and 1032 may be provided to provide information about the start and end points of the resource allocated to a specific terminal (UE A in FIG. 10). Alternatively, the locations of data symbols of a specific terminal within a common TP may be provided as a bitmap, or the locations of discontinuous data symbols may be supported by incorporating an interleaving function. The method for indicating resource allocation and location may utilize and supplement the resource allocation method used in existing DCIs.

[0254] As explained above, either a group common DCI or a UE-specific DCI may be considered as a method of indication, or a combination of both methods may be considered. In particular, when a group common DCI is used, it may be used as a one-time scheduling DCI for each terminal to receive a single PDSCH, whereas it may also be used as information that operates for a certain period of time in conjunction with a specific timer after the group common DCI is received. Additionally, only minimal information may be transmitted via the DCI, while most information may be provided through RRC settings. Specifically, regarding the contents included in 1023 and 1024, a method using dynamic indication methods such as a group common DCI may be considered to configure the terminal via RRC and activate the corresponding function. Although this was explained in terms of multiplexing multiple terminals based on the downlink, the same method may be considered for the uplink as well. For example, the same method may be applied to the aspect of multiplexing multiple channels when a terminal transmits an uplink channel. Alternatively, it may also be considered for the base station to provide information so that multiple terminals transmit uplink channels simultaneously using the same TP.

[0255] Specific terms used in the above examples may be changed, and the content of the present disclosure is not limited by the examples described in the present disclosure. At least one method of the first embodiment or / and the second embodiment or / and the third embodiment of the present disclosure may be used in combination with each other.

[0256] <Fourth Embodiment>

[0257] The fourth embodiment of the present disclosure describes the operation and procedure of a terminal and a base station when transmitting and receiving a channel that can be set to a plurality of waveforms.

[0258] FIG. 11 is a diagram illustrating an example of the operation of a terminal when transmitting and receiving a channel that can be set to a plurality of waveforms according to an embodiment of the present invention.

[0259] Referring to FIG. 11, terminals capable of supporting multiple waveforms in step 1100 can report their relevant capabilities to the network. At this time, the base station may operate by receiving the terminal's capability information from the network, or it may operate without knowing the terminal's exact capability.

[0260] Terminals that support Multiple WF can obtain information through step 1101 about whether the base station also supports the Multiple WF feature and which WFs it supports. Then, in step 1102, the terminal can determine whether the base station supports Multiple WF.

[0261] If the base station does not support multiple WF features and only supports a default WF for transmitting and receiving all channels, then the operation to transmit and receive information can be performed using the default WF without needing to determine the WF (step 1103). In this case, the default WF may be specified as one of the mandatory WFs supported by all terminals as described in the first embodiment, or it may be determined by the base station's settings.

[0262] Meanwhile, if the base station supports multiple WFs, in step 1104, the terminal in the RRC IDLE / INACTIVE state may perform a process of determining which WF to use to perform the relevant operation. As described in the first embodiment, the RRC IDLE / INACTIVE terminal periodically receives paging-related information and system information and measures the channel state, and must determine which WF to use on the receiving channel for the operation, and specific examples of the method are specified in the first embodiment.

[0263] Then, at step 1106, the terminal can determine whether to transition to the RRC connected state. If the terminal does not need to transition to the RRC CONNECTED state, the terminal can return to step 1104 and repeat the process (step 1105).

[0264] If the terminal determines that it has transitioned to the RRC CONNECTED state, the terminal can perform random access in step 1107.

[0265] At this time, WF information related to random access may be specified in the standard or provided through MIB or / and SIB information in step 1101.

[0266] If the base station supports random access based on multiple WFs, and it is determined in step 1107 that the terminal has received information regarding WFs related to channels or resources related to random access from the base station, in step 1108 the terminal may determine a suitable WF for random access and attempt random access based on the said WF, or transmit information about a preferred WF to the base station to receive a preferred WF for random access from the base station. Specific details regarding these operations are specified in the first embodiment.

[0267] If, in step 1107, it is determined that WF information related to a random access channel or resource is not provided to the terminal by the specifications and base station settings, in step 1109, the terminal may perform random access using the default WF or any WF supported by the terminal specified in the specifications.

[0268] A terminal performing random access may repeat steps 1108 and / or 1109 to perform random access until an RRC connection is established in step 1110. However, if certain conditions are satisfied, such as when random access is not successful for a long period of time, other actions may be performed, such as attempting to connect to another cell.

[0269] If the terminal succeeds in establishing an RRC connection through step 1110, in step 1111, it can be determined whether the content regarding the WF used to transmit and receive the channel as an RRC CONNECTED terminal has been set as RRC information. Specific RRC setting methods may be considered as the methods specified in the first embodiment.

[0270] In step 1111, if the terminal receives WF-related information via RRC, the terminal can determine the WF used for channel transmission and reception based on the information set by the base station. At this time, before transmitting or receiving a data channel (PDSCH or PUSCH), in step 1112, the terminal can determine whether WF-related information has been received based on the information in the DCI within the PDCCH. If WF-related information has been received via the DCI, in step 1113, the terminal can determine the WF to be used for the channel to be transmitted and received subsequently based on the information set via RRC and the WF-related information provided directly or indirectly within the DCI. If there is no information provided directly or indirectly through the DCI, the terminal can determine the WF based on the RRC setting in step 1114.

[0271] Meanwhile, if it is determined in step 1111 that information regarding the WF was not received through the RRC settings, in step 1115 the terminal can determine whether it received information regarding the WF directly through the DCI. If, in step 1115 the terminal received WF information through the DCI associated with a specific channel or resource, the terminal can determine the WF to be used on that channel or resource directly or indirectly through the DCI in step 1116. If, in step 1115 the terminal did not receive the WF through the DCI, it means that the terminal did not obtain information regarding the WF through the DCI in addition to the RRC settings, so in step 1117 the terminal can transmit and receive the channel using the default WF or the WF that is provided by default to all terminals in the standard.

[0272] While the terminal maintains the RRC CONNECTED state and transmits and receives the channel, the RRC information may be updated, and since the RRC configured information may differ for each channel or resource, steps 1111 through 1117 may be repeated whenever a specific channel is transmitted or received from a given resource. At this time, examples of methods for determining the WF based on the RRC configuration or information within the DCI are specifically specified in the first and second embodiments.

[0273] In addition, although omitted in FIG. 11, even if WF-related information is provided in steps 1101, 1107, 1111, 1112, or 1115, if the condition that a default WF must be used as specified in the standard or set by the base station is satisfied, the channel or resource may prioritize the use of the default WF. Furthermore, although the present disclosure describes cases where WF-related information is provided based on RRC settings and DCI instruction-based signaling, operations where WF-related information is set via MAC CE-based signaling may also be considered in combination.

[0274] Meanwhile, information regarding the WF provided as system information, RRC information, or DCI information may differ. When different information is set for determining the WF, rules regarding which WF to determine may be specified in the standard, and examples of rules that can be used in such cases are proposed through the first and second embodiments of the present disclosure. As another rule, the switching time required to switch the WF may also be considered. Specifically, if a different WF is used for a terminal to transmit and receive channels consecutively, the WF may be determined based on whether the switching time condition is satisfied when switching the used WF. This may vary depending on which WF is being switched to or from which WF, and the specific switching time value for each WF may follow values ​​specified in the standard, set by the base station, or reported by the terminal. For example, when the WF is switched via DCI, the WF indicated by DCI is used only if the switching time requirement is satisfied, and otherwise, the WF set by RRC may be used.

[0275] FIG. 12 is a diagram illustrating an example of the operation of a base station when transmitting and receiving a channel that can be set to a plurality of waveforms according to an embodiment of the present invention.

[0276] Referring to FIG. 12, in step 1201, the base station may operate with the default WF specified in the standard (a WF that all terminals support by default) before activating the multiple WF function. At this time, as described in the first embodiment, when the base station sets the default WF, it may perform the operation of step 1201 by directly or indirectly providing the default WF that the base station intends to use to the terminals using MIB or SIB information or a synchronization raster, etc.

[0277] If a base station intends to support multiple WFs, it may enable the corresponding function in step 1202. To this end, in step 11203, processes such as providing information related to the WFs supported by the base station as system information, such as an MIB or SIB, or setting it as RRC information may be performed. At this time, it is highly likely that the base station already knows in advance, through the terminal's capability report, whether a terminal supports multiple WF features and which WFs it supports. The operation depending on whether the base station receives such information in advance has been explained in detail in the first embodiment. If the base station does not support multiple WFs, it may operate by applying a default WF as in step 1201.

[0278] When information regarding the WF candidate group supported by the base station is provided to terminals within the cell, the base station can transmit and receive channels based on the configured WF information in step 1204. At this time, various examples of methods for providing WF information by channel or resource are specifically provided through the first, second, and third embodiments.

[0279] In step 1205, the base station can decide whether to disable the multiple WF function. If the multiple WF function is not disabled, the base station can repeat step 1204.

[0280] In addition, if the base station intends to disable the multiple WF function, it can directly or indirectly inform all terminals within the cell that the multiple WF function is no longer supported through an update of the MIB, SIB, or RRC settings in step 1206. Furthermore, a method of dynamically disabling the multiple WF function via DCI may be considered, and various methods for enabling and disabling the multiple WF function may be considered, such as temporarily disabling it in conjunction with a specific timer and re-enabling it when the timer expires, or vice versa. Meanwhile, a base station with the multiple WF function disabled can return to step 1201 and repeat the following operations.

[0281] The flowcharts described in FIGS. 5, 11, and 12 illustrate exemplary methods that may be implemented according to the principles of the present disclosure, and various modifications may be made to the methods illustrated in the flowcharts of this specification. For example, although illustrated as a series of steps, the various steps in each figure may overlap, occur in parallel, occur in a different order, or occur multiple times. In other examples, steps may be omitted or replaced with other steps.

[0282] FIG. 13 is a block diagram illustrating an example of the structure of a terminal according to an embodiment of the present invention.

[0283] Referring to FIG. 13, the terminal (1300) may include a transceiver (1301), a control unit (e.g., a processor) (1302), and a storage unit (e.g., memory, 1303). The transceiver (1301), control unit (1302), and storage unit (1303) of the terminal (1300) may operate according to at least one or a combination thereof of the methods corresponding to the above-described embodiments. However, the components of the terminal (1300) are not limited to the illustrated examples. According to other embodiments, the terminal (1300) may include more components or fewer components than the above-described components. In addition, in certain cases, the transceiver (1301), control unit (1302), and storage unit (1303) may be implemented in the form of a single chip.

[0284] According to one embodiment, the transceiver (1301) may be composed of a transmitter and a receiver. The transceiver (1301) may transmit and receive signals with a base station. The signals may include control information and data. The transceiver (1301) may be configured to include an RF transmitter that up-converts and amplifies the frequency of a transmitted signal, and an RF receiver that low-noise amplifies a received signal and down-converts the frequency. The transceiver (1301) may receive a signal through a wireless channel and output it to a control unit (1302), and transmit the signal output from the control unit (1302) through a wireless channel.

[0285] The control unit (1302) can control a series of procedures that allow the terminal (1300) to operate according to the embodiments of the present disclosure described above. For example, the control unit (1302) can perform or control the operation of the terminal to perform at least one of the methods according to the embodiments of the present disclosure or a combination thereof. The control unit (1302) may include at least one processor. For example, the control unit (1302) may include a communication processor (CP) that performs control for communication and an application processor (AP) that controls an upper layer (e.g., an application).

[0286] The storage unit (1303) can store control information (e.g., setting information for a WF set for a terminal (1300)) or data, and may have an area for storing data required for control of the control unit (1302) and data generated during control by the control unit (1302).

[0287] FIG. 14 is a block diagram illustrating an example of the structure of a base station according to one embodiment of the present invention.

[0288] Referring to FIG. 14, a base station (1400) may include a transceiver (1401), a control unit (e.g., a processor) (1402), and a storage unit (e.g., a memory) (1403). The transceiver (1401), control unit (1402), and storage unit (1403) of the base station (1400) may be operated according to at least one or a combination thereof of the methods corresponding to the above-described embodiments. However, the components of the base station (1400) are not limited to the illustrated examples. According to other embodiments, the base station (1400) may include more components or fewer components than the above-described components. In addition, in certain cases, the transceiver (1401), control unit (1402), and storage unit (1403) may be implemented in the form of a single chip.

[0289] According to one embodiment, the transceiver (1401) may be composed of a transmitter and a receiver. The transceiver (1401) may transmit and receive signals to and from a terminal. The signals may include control information and data. The transceiver (1401) may be configured to include an RF transmitter that up-converts and amplifies the frequency of a transmitted signal, and an RF receiver that low-noise amplifies a received signal and down-converts the frequency. The transceiver (1401) may receive a signal through a wireless channel and output it to a control unit (1402), and transmit the signal output from the control unit (1402) through a wireless channel.

[0290] The control unit (1402) can control a series of procedures to enable the base station (1400) to operate according to the embodiments of the present disclosure described above. For example, the control unit (1402) can perform or control the operation of the base station to perform at least one of the methods according to the embodiments of the present disclosure or a combination thereof. The control unit (1402) may include at least one processor. For example, the control unit (1402) may include a communication processor (CP) that performs control for communication and an application processor (AP) that controls an upper layer (e.g., an application).

[0291] The storage unit (1403) can store control information (e.g., setting information for WF), data, control information received from a terminal, or data, and may have an area for storing data required for control of the control unit (1402) and data generated during control by the control unit (1402).

[0292] In the specific embodiments of the present disclosure described above, the components included in the disclosure are expressed in a singular or plural form according to the specific embodiments presented. However, the singular or plural expression is selected to suit the situation presented for convenience of explanation, and the disclosure of the present invention is not limited to singular or plural components; even if a component is expressed in the plural form, it may be composed of a singular form, and even if a component is expressed in the singular form, it may be composed of a plural form.

[0293] Meanwhile, although specific embodiments have been described in the detailed description of the present invention, it is understood that various modifications are possible within the scope of the present invention. Therefore, the scope of the present invention should not be limited to the described embodiments, but should be defined by the claims set forth below as well as equivalents thereof.

Claims

1. In the method of the terminal, Step of identifying a waveform for a downlink channel; The method includes the step of receiving the downlink channel from a base station based on a waveform for the downlink channel in an RRC (radio resource control) IDLE state or an RRC INACTIVE state, and The waveform for the downlink channel is a default waveform or a waveform determined based on downlink channel waveform-related information received from the base station, and A method characterized by the fact that the above-mentioned downlink channel waveform information is based on a downlink channel waveform ID (identifier).

2. In Paragraph 1, The waveform for the above downlink channel is the above basic waveform, and A method characterized by applying the basic waveform to all downlink channels received in the above RRC IDLE state or the above RRC INACTIVE state.

3. In Paragraph 1, The method further includes the step of transmitting waveform-related capability information to the above-mentioned base station via PRACH (physical random access channel), and The above downlink channel is associated with the transmission of message 2 or message 4, and The above downlink channel waveform related information is received from the base station via the SIB, and The above downlink channel waveform-related information is based on the above waveform-related capability information, and A method characterized in that the waveform for the downlink channel is determined based on information related to the downlink channel waveform.

4. In Paragraph 1, A method characterized by applying the same transform precoding (TP) to multiple downlink channels associated with multiple terminals that are frequency division multiplexed (FDM) with the downlink channel, when the waveform for the downlink channel is DFT-s-OFDM.

5. Regarding the base station method, Step of identifying a waveform for a downlink channel; The method includes the step of transmitting the downlink channel based on a waveform for the downlink channel to a terminal in an RRC (radio resource control) IDLE state or an RRC INACTIVE state. The waveform for the downlink channel is a default waveform or a waveform determined based on downlink channel waveform-related information transmitted to the terminal, and A method characterized by the fact that the above-mentioned downlink channel waveform information is based on a downlink channel waveform ID (identifier).

6. In Paragraph 5, The waveform for the above downlink channel is the above basic waveform, and A method characterized by applying the basic waveform to all downlink channels transmitted to the terminal in the RRC IDLE state or the RRC INACTIVE state.

7. In Paragraph 5, The method further includes the step of receiving waveform-related capability information from the above terminal via PRACH (physical random access channel), and The above downlink channel is associated with the transmission of message 2 or message 4, and The above downlink channel waveform information is transmitted to the terminal via SIB, and The above downlink channel waveform-related information is based on the above waveform-related capability information, and A method characterized in that the waveform for the downlink channel is determined based on information related to the downlink channel waveform.

8. In Paragraph 5, A method characterized by applying the same transform precoding (TP) to multiple downlink channels associated with multiple terminals that are frequency division multiplexed (FDM) with the downlink channel, when the waveform for the downlink channel is DFT-s-OFDM.

9. Regarding the terminal, Transmitter / receiver; and Identify the waveform for the downlink channel, It includes a control unit configured to receive the downlink channel from a base station based on a waveform for the downlink channel in an RRC (radio resource control) IDLE state or an RRC INACTIVE state, and The waveform for the downlink channel is a default waveform or a waveform determined based on downlink channel waveform-related information received from the base station, and A terminal characterized by the fact that the above-mentioned downlink channel waveform-related information is based on a downlink channel waveform ID (identifier).

10. In Paragraph 9, The waveform for the above downlink channel is the above basic waveform, and A terminal characterized by the application of the basic waveform to all downlink channels received in the above RRC IDLE state or the above RRC INACTIVE state.

11. In Paragraph 9, The above control unit is further configured to transmit waveform-related capability information to the base station via PRACH (physical random access channel), and The above downlink channel is associated with the transmission of message 2 or message 4, and The above downlink channel waveform related information is received from the base station via the SIB, and The above downlink channel waveform-related information is based on the above waveform-related capability information, and A terminal characterized in that the waveform for the downlink channel is determined based on information related to the downlink channel waveform.

12. In Paragraph 9, A terminal characterized in that, when the waveform for the downlink channel is DFT-s-OFDM, the same transform precoding (TP) is applied to multiple downlink channels associated with multiple terminals that are frequency division multiplexed (FDM) with the downlink channel.

13. Regarding base stations, Transmitter / receiver; and Step of identifying a waveform for a downlink channel; A control unit configured to transmit the downlink channel based on a waveform for the downlink channel to a terminal in an RRC (radio resource control) IDLE state or an RRC INACTIVE state, and The waveform for the downlink channel is a default waveform or a waveform determined based on downlink channel waveform-related information transmitted to the terminal, and A base station characterized by the fact that the above-mentioned downlink channel waveform information is based on a downlink channel waveform ID (identifier).

14. In Paragraph 13, The waveform for the above downlink channel is the above basic waveform, and A base station characterized by the application of the basic waveform to all downlink channels transmitted to the terminal in the RRC IDLE state or the RRC INACTIVE state.

15. In Paragraph 13, The above control unit is further configured to receive waveform-related capability information from the terminal via PRACH (physical random access channel), and The above downlink channel is associated with the transmission of message 2 or message 4, and The above downlink channel waveform information is transmitted to the terminal via SIB, and The above downlink channel waveform-related information is based on the above waveform-related capability information, and A base station characterized in that the waveform for the downlink channel is determined based on information related to the downlink channel waveform.

Images