Method and apparatus for applying orthogonal covering code to non-terrestrial network uplink channel in wireless communication system

Abstract

The purpose of the present disclosure is to apply an orthogonal covering code (OCC) to a non-terrestrial network (NTN) uplink channel in a wireless communication system, and an operation method of a terminal may comprise: transmitting capability information about uplink transmission; receiving configuration information about an orthogonal covering code (OCC) applied to a physical uplink shared channel (PUSCH); identifying information about a DMRS port number corresponding to the PUSCH; and transmitting the PUSCH by using an OCC weight associated with the DMRS port number.

Description

Method and device for applying orthogonal covering codes to non-terrestrial network uplink channels in wireless communication systems

[0001] The present disclosure relates to a non-terrestrial network (NTN) in a wireless communication system, and more particularly, to a method and apparatus for applying an orthogonal covering code (OCC) to an uplink channel.

[0002] Communication networks (e.g., 5G communication networks, 6G communication networks, etc.) are being developed to provide improved communication services compared to existing communication networks (e.g., long term evolution (LTE) and advanced LTE-A). 5G communication networks (e.g., new radio (NR) communication networks) can support frequency bands above 6 GHz as well as frequency bands below 6 GHz. That is, 5G communication networks can support FR1 bands and / or FR2 bands. 5G communication networks can support a variety of communication services and scenarios compared to LTE communication networks. For example, usage scenarios of 5G communication networks may include enhanced Mobile Broadband (eMBB), Ultra Reliable Low Latency Communication (URLLC), and massive Machine Type Communication (mMTC).

[0003] Compared to 5G, 6G communication networks can support a wider range of communication services and scenarios. 6G communication networks can meet requirements for ultra-high performance, ultra-high bandwidth, ultra-high space, ultra-high precision, ultra-intelligence, and / or ultra-reliability. 6G communication networks can support diverse and wide frequency bands and be applied to various usage scenarios (e.g., terrestrial communications, non-terrestrial communications, sidelink communications, etc.).

[0004] Compared to 5G, 6G communication networks can support a wider range of communication services and scenarios. 6G communication networks can meet requirements for ultra-high performance, ultra-high bandwidth, ultra-high space, ultra-high precision, ultra-intelligence, and / or ultra-reliability. 6G communication networks can support diverse and wide frequency bands and be applied to various usage scenarios (e.g., terrestrial communications, non-terrestrial communications, sidelink communications, etc.).

[0005] Communication networks (e.g., 5G communication networks, 6G communication networks, etc.) can provide communication services to terminals located on the ground. Demand for communication services for not only terrestrial but also non-terrestrial devices such as aircraft, drones, and satellites is increasing, and technologies for non-terrestrial networks (NTNs) are being discussed to address this need. NTNs can be implemented based on 5G communication technologies, 6G communication technologies, etc. For example, in NTNs, communication between satellites and ground-based communication nodes or non-terrestrial communication nodes (e.g., aircraft, drones, etc.) can be performed based on 5G communication technologies, 6G communication technologies, etc. In NTNs, satellites can function as base stations in communication networks (e.g., 5G communication networks, 6G communication networks, etc.).

[0006] Meanwhile, the technology that serves as the background for the invention is written to promote understanding of the background for the invention, and may include content that is not a prior art already known to a person with ordinary skill in the field to which the technology belongs.

[0007] The present disclosure may provide a method and device for applying an orthogonal covering code (OCC) to an uplink channel in a wireless communication system supporting a non-terrestrial network (NTN).

[0008] The present disclosure may provide a method and device for determining an OCC weight applied to a PUSCH (physical uplink shared channel) in a wireless communication system.

[0009] The present disclosure can provide a method and device for associating an OCC weight applied to a PUSCH in a wireless communication system with a demodulation reference signal (DMRS).

[0010] The technical objectives to be achieved in the present disclosure are not limited to those mentioned above, and other technical tasks not mentioned can be considered by a person having ordinary skill in the technical field to which the technical configuration of the present disclosure is applied from the embodiments of the present disclosure described below.

[0011] According to one embodiment of the present disclosure, a method of operating a terminal in a wireless communication system may include transmitting capability information for uplink transmission, receiving configuration information for an orthogonal covering code (OCC) applied to a physical uplink shared channel (PUSCH), checking information on a DMRS port number corresponding to the PUSCH, and transmitting the PUSCH using an OCC weight associated with the DMRS port number.

[0012] According to one embodiment of the present disclosure, a method of operating a non-terrestrial network (NTN) base station in a wireless communication system may include receiving capability information for uplink transmission, transmitting configuration information for an orthogonal covering code (OCC) applied to a physical uplink shared channel (PUSCH), and receiving the PUSCH transmitted using an OCC weight associated with a DMRS port number corresponding to the PUSCH.

[0013] According to one embodiment of the present disclosure, in a wireless communication system, a terminal includes at least one transceiver, at least one processor, and at least one memory operably connected to the at least one processor and storing instructions that, when executed by the processor, control the terminal to perform operations, wherein the operations may include transmitting capability information for uplink transmission, receiving configuration information for an orthogonal covering code (OCC) applied to a physical uplink shared channel (PUSCH), checking information for a DMRS port number corresponding to the PUSCH, and transmitting the PUSCH using an OCC weight associated with the DMRS port number.

[0014] According to one embodiment of the present disclosure, in a wireless communication system, a non-terrestrial network (NTN) base station includes at least one transceiver, at least one processor, and at least one memory operably connected to the at least one processor and storing instructions that, when executed by the processor, control the terminal to perform operations, wherein the operations may include receiving capability information for uplink transmission, transmitting configuration information for an orthogonal covering code (OCC) applied to a physical uplink shared channel (PUSCH), and receiving the PUSCH transmitted using an OCC weight associated with a DMRS port number corresponding to the PUSCH.

[0015] The proposed technology enables effective application of orthogonal covering codes (OCCs) to uplink channels in wireless communication systems.

[0016] The effects that can be obtained from the embodiments of the present disclosure are not limited to the effects mentioned above, and other effects not mentioned can be clearly derived and understood by those skilled in the art to which the technical configuration of the present disclosure is applied, from the description of the embodiments of the present disclosure below. In other words, unintended effects resulting from implementing the configuration described in the present disclosure can also be derived by those skilled in the art from the embodiments of the present disclosure.

[0017] FIG. 1a and FIG. 1b illustrate the structure of a transparent-based non-terrestrial network (NTN) according to an embodiment of the present disclosure.

[0018] FIGS. 2A to 2C illustrate the structure of a regenerative-based NTN according to an embodiment of the present disclosure.

[0019] FIG. 3 illustrates a block diagram of a communication node constituting an NTN according to an embodiment of the present disclosure.

[0020] FIG. 4 illustrates a block diagram of a communication node according to an embodiment of the present disclosure.

[0021] FIGS. 5A and 5B illustrate block diagrams of a transmission path and a reception path of a communication node according to an embodiment of the present disclosure.

[0022] FIG. 6 illustrates an example of a system frame in a wireless communication system according to an embodiment of the present disclosure.

[0023] FIG. 7 illustrates an example of a subframe in a wireless communication system according to an embodiment of the present disclosure.

[0024] FIG. 8 illustrates an example of a slot in a wireless communication system according to an embodiment of the present disclosure.

[0025] FIG. 9 illustrates the timing relationship between uplink and downlink in a wireless communication system according to an embodiment of the present disclosure.

[0026] FIG. 10A and FIG. 10B illustrate examples of protocol stacks of a user plane and a control plane in a transparent payload-based NTN in a wireless communication system according to an embodiment of the present disclosure.

[0027] FIG. 11a and FIG. 11b illustrate examples of protocol stacks of a user plane and a control plane in a regenerative payload-based NTN in a wireless communication system according to an embodiment of the present disclosure.

[0028] Figure 12 illustrates an example of an NTN providing non-terrestrial NR access to a UE by means of an NTN payload and an NTN gateway.

[0029] Figure 13 illustrates the timing relationship between objects included in NTN.

[0030] FIGS. 14A to 14C illustrate examples of OCC (orthogonal covering code) application methods in a wireless communication system according to one embodiment of the present disclosure.

[0031] FIG. 15 illustrates an example of a method for integrating intra-symbol OCC and inter-symbol OCC in a wireless communication system according to one embodiment of the present disclosure.

[0032] FIG. 16 illustrates an example of a procedure for applying OCC in a wireless communication system according to one embodiment of the present disclosure.

[0033] FIG. 17 illustrates an example of a procedure for a terminal to transmit a PUSCH using OCC in a wireless communication system according to one embodiment of the present disclosure.

[0034] FIG. 18 illustrates an example of a procedure for a base station to receive a PUSCH to which an OCC is applied in a wireless communication system according to one embodiment of the present disclosure.

[0035] This disclosure may be subject to various modifications and various embodiments. Specific embodiments are illustrated and described in detail in the drawings. However, this is not intended to limit the disclosure to specific embodiments, but rather to encompass all modifications, equivalents, and alternatives falling within the spirit and technical scope of the disclosure.

[0036] While terms such as "first" and "second" may be used to describe various components, these components should not be limited by these terms. These terms are used solely to distinguish one component from another. For example, without departing from the scope of the present disclosure, a first component could be referred to as a "second component," and similarly, a second component could also be referred to as a "first component." The term "and / or" may refer to a combination of multiple related items described herein or to any of multiple related items described herein.

[0037] In the present disclosure, “at least one of A and B” may mean “at least one of A or B” or “at least one of combinations of one or more of A and B.” Additionally, in the present disclosure, “at least one of A and B” may mean “at least one of A or B” or “at least one of combinations of one or more of A and B.”

[0038] In the present disclosure, (re)transmission may mean “transmission,” “retransmission,” or “transmission and retransmission,” (re)setting may mean “setting,” “resetting,” or “setting and resetting,” (re)connection may mean “connection,” “reconnection,” or “connection and reconnection,” and (re)connection may mean “connection,” “reconnection,” or “connection and reconnection.”

[0039] When a component is referred to as being "connected" or "connected" to another component, it should be understood that it may be directly connected or connected to that other component, but that there may be other components intervening. Conversely, when a component is referred to as being "directly connected" or "connected" to another component, it should be understood that there are no other components intervening.

[0040] The terminology used in this disclosure is only used to describe specific embodiments and is not intended to limit the present disclosure. The singular expression includes the plural expression unless the context clearly indicates otherwise. In this disclosure, it should be understood that the terms "comprises" or "has" indicate the presence of a feature, number, step, operation, component, part, or combination thereof described in the specification, but do not preclude the presence or addition of one or more other features, numbers, steps, operations, components, parts, or combinations thereof.

[0041] Unless otherwise defined, all terms used herein, including technical or scientific terms, have the same meaning as commonly understood by a person of ordinary skill in the art to which this disclosure pertains. Terms defined in commonly used dictionaries should be interpreted as having a meaning consistent with their meaning in the context of the relevant technology, and shall not be interpreted in an idealized or overly formal sense unless explicitly defined herein.

[0042] Hereinafter, preferred embodiments of the present disclosure will be described in more detail with reference to the attached drawings. In order to facilitate an overall understanding in describing the present disclosure, the same reference numerals will be used for identical components in the drawings, and redundant descriptions of identical components will be omitted. In addition to the embodiments explicitly described in the present disclosure, operations may be performed according to combinations of embodiments, extensions of embodiments, and / or modifications of embodiments. The performance of some operations may be omitted, and the order of operation may be changed.

[0043] In an embodiment, even if a method (e.g., transmitting or receiving a signal) performed by a first communication node among communication nodes is described, a corresponding second communication node can perform a method (e.g., receiving or transmitting a signal) corresponding to the method performed by the first communication node. That is, if an operation of a UE (user equipment) is described, a corresponding base station can perform an operation corresponding to the operation of the UE. Conversely, if an operation of a base station is described, a corresponding UE can perform an operation corresponding to the operation of the base station.

[0044] A base station may be referred to as a NodeB, an evolved NodeB, a gNodeB (next generation node B), a gNB, a device, an apparatus, a node, a communication node, a BTS (base transceiver station), a RRH (radio remote head), a TRP (transmission reception point), a RU (radio unit), an RSU (road side unit), a radio transceiver, an access point, an access node, etc. A UE may be referred to as a terminal, a device, an apparatus, a node, a communication node, an end node, an access terminal, a mobile terminal, a station, a subscriber station, a mobile station, a portable subscriber station, an OBU (on-broad unit), etc.

[0045] In the present disclosure, signaling may be at least one of upper layer signaling, MAC signaling, or PHY (physical) signaling. A message used for upper layer signaling may be referred to as an "upper layer message" or an "upper layer signaling message." A message used for MAC signaling may be referred to as a "MAC message" or a "MAC signaling message." A message used for PHY signaling may be referred to as a "PHY message" or a "PHY signaling message." Upper layer signaling may refer to a transmission and reception operation of system information (e.g., a master information block (MIB), a system information block (SIB)) and / or an RRC message. MAC signaling may refer to a transmission and reception operation of a MAC control element (CE). PHY signaling may refer to a transmission and reception operation of control information (e.g., downlink control information (DCI), uplink control information (UCI), sidelink control information (SCI)).

[0046] In the present disclosure, “an operation (e.g., a transmission operation) is set” may mean that “setting information for the operation (e.g., an information element, a parameter)” and / or “information instructing the performance of the operation” is signaled. “An information element (e.g., a parameter) is set” may mean that the information element is signaled. In the present disclosure, “a signal and / or a channel” may mean a signal, a channel, or “a signal and a channel,” and a signal may be used to mean “a signal and / or a channel.”

[0047] The communication system may include at least one of a terrestrial network (TN), an NTN, a 4G communication network (e.g., a long-term evolution (LTE) communication network), a 5G communication network (e.g., a new radio (NR) communication network), or a 6G communication network. Each of the 4G communication network, the 5G communication network, and the 6G communication network may include the terrestrial network and / or the NTN. The NTN may be operated based on at least one communication technology among the LTE communication technology, the 5G communication technology, and the 6G communication technology. The NTN may provide communication services in various frequency bands.

[0048] The communication networks to which the embodiments of the present disclosure are applied are not limited to those described below, and the embodiments may be applied to various communication networks (e.g., 4G communication networks, 5G communication networks, and / or 6G communication networks). Here, the term "communication network" may be used interchangeably with the term "communication system."

[0049] FIG. 1a and FIG. 1b illustrate the structure of a transparent-based non-terrestrial network (NTN) according to an embodiment of the present disclosure.

[0050] Referring to FIG. 1A, the NTN may include a satellite (110), a communication node (120), a gateway (130), a data network (140), etc. A unit including the satellite (110) and the gateway (130) may be referred to as a remote radio unit (RRU). The satellite (110) may be a low Earth orbit (LEO) satellite, a medium Earth orbit (MEO) satellite, a geostationary Earth orbit (GEO) satellite, a high elliptical orbit (HEO) satellite, or an unmanned aircraft system (UAS) platform. The UAS platform may include a high altitude platform station (HAPS). The non-GEO satellite may be a LEO satellite and / or a MEO satellite.

[0051] The communication node (120) may include a communication node located on the ground (e.g., a UE, a terminal) and a communication node located off the ground (e.g., an airplane, a drone). A service link may be established between the satellite (110) and the communication node (120), and the service link may be a radio link. The satellite (110) may be referred to as an NTN payload. The gateway (130) may support multiple NTN payloads. The satellite (110) may provide a communication service to the communication node (120) using one or more beams. The shape of the reception range (footprint) of the beam of the satellite (110) may be elliptical or circular.

[0052] In NTN, three types of service links can be supported as follows:

[0053] - Earth-fixed: The service link may be provided by beam(s) that continuously cover the same geographic area at all times (e.g. Geosynchronous Orbit (GSO) satellites).

[0054] - Quasi-earth-fixed: The service link may be provided by beam(s) that cover one geographic area for a limited period and another geographic area for another period (e.g., NGSO (non-GSO) satellites that produce steerable beams).

[0055] - Earth-moving: The service link may be provided by beam(s) moving over the Earth's surface (e.g., NGSO satellites producing fixed beams or non-steerable beams).

[0056] The communication node (120) can perform communication (e.g., downlink communication, uplink communication) with the satellite (110) using 4G communication technology, 5G communication technology, and / or 6G communication technology. Communication between the satellite (110) and the communication node (120) can be performed using an NR-Uu interface and / or a 6G-Uu interface. When DC (dual connectivity) is supported, the communication node (120) can be connected to not only the satellite (110) but also other base stations (e.g., base stations supporting 4G functions, 5G functions, and / or 6G functions), and can perform DC operations based on technologies defined in the 4G standard, the 5G standard, and / or the 6G standard.

[0057] The gateway (130) may be located on the ground, and a feeder link may be established between the satellite (110) and the gateway (130). The feeder link may be a wireless link. The gateway (130) may be referred to as an 'NTN gateway'. Communication between the satellite (110) and the gateway (130) may be performed based on a NR-Uu interface, a 6G-Uu interface, or a satellite radio interface (SRI). The gateway (130) may be connected to a data network (140). A "core network" may exist between the gateway (130) and the data network (140). In this case, the gateway (130) may be connected to the core network, and the core network may be connected to the data network (140). The core network may support 4G communication technology, 5G communication technology, and / or 6G communication technology. For example, the core network may include an access and mobility management function (AMF), a user plane function (UPF), a session management function (SMF), etc. Communication between the gateway (130) and the core network may be performed based on a NG-C / U interface or a 6G-C / U interface.

[0058] As shown in Fig. 1b, in a transparent payload-based NTN, a base station and a core network may exist between a gateway (130) and a data network (140).

[0059] Referring to FIG. 1B, a gateway may be connected to a base station, the base station may be connected to a core network, and the core network may be connected to a data network. Each of the base station and the core network may support 4G communication technology, 5G communication technology, and / or 6G communication technology. Communication between the gateway and the base station may be performed based on a NR-Uu interface or a 6G-Uu interface, and communication between the base station and the core network (e.g., AMF, UPF, SMF) may be performed based on a NG-C / U interface or a 6G-C / U interface.

[0060] FIGS. 2A to 2C illustrate the structure of a regenerative-based NTN according to an embodiment of the present disclosure.

[0061] Referring to FIG. 2A, the NTN may include a first satellite (211), a second satellite (212), a communication node (220), a gateway (230), a data network (1240), etc. Each of the first satellite (211) and the second satellite (212) may perform a regeneration operation (e.g., a demodulation operation, a decoding operation, a re-encoding operation, a re-modulation operation, and / or a filtering operation) on a payload received from another entity constituting the NTN (e.g., a communication node (220), a gateway (230)) and transmit the regenerated payload.

[0062] Each of the first satellite (211) and the second satellite (212) may be a LEO satellite, an MEO satellite, a GEO satellite, an HEO satellite, or a UAS platform. The UAS platform may include a HAPS. Satellite #1 (211) may be connected to the second satellite (212), and an inter-satellite link (ISL) may be established between the first satellite (211) and the second satellite (212). The ISL may operate in a radio frequency (RF) frequency or an optical band. The ISL may be optional. The communication node (220) may include a ground-based communication node (e.g., a UE, terminal) and a non-ground-based communication node (e.g., an airplane, a drone). A service link (e.g., a wireless link) may be established between satellite #1 (211) and the communication node (220). The first satellite (211) may be referred to as an NTN payload. The first satellite (211) can provide communication services to a communication node (220) using one or more beams.

[0063] The communication node (220) can perform communication (e.g., downlink communication, uplink communication) with the first satellite (211) using 4G communication technology, 5G communication technology, and / or 6G communication technology. Communication between the first satellite (211) and the communication node (220) can be performed using an NR-Uu interface or a 6G-Uu interface. When DC is supported, the communication node (220) can be connected to other base stations (e.g., base stations supporting 4G functions, 5G functions, and / or 6G functions) as well as the first satellite (211), and can perform DC operations based on technologies defined in the 4G standard, the 5G standard, and / or the 6G standard.

[0064] The gateway (230) may be located on the ground, and a feeder link may be established between the first satellite (211) and the gateway (230), and a feeder link may be established between the second satellite (212) and the gateway (230). The feeder link may be a wireless link. If an ISL is not established between the first satellite (211) and the second satellite (212), the feeder link between the first satellite (211) and the gateway (230) may be established mandatorily. Communication between the first satellite (211) and satellite #2 (212) and the gateway (230) may be performed based on an NR-Uu interface, a 6G-Uu interface, or an SRI. The gateway (230) may be connected to a data network (240).

[0065] As in the embodiments of FIGS. 2b and 2c, a core network may exist between the gateway (230) and the data network (240).

[0066] Referring to FIGS. 2b and 2c, a gateway may be connected to a core network, and the core network may be connected to a data network. The core network may support 4G communication technology, 5G communication technology, and / or 6G communication technology. For example, the core network may include AMF, UPF, SMF, etc. Communication between the gateway and the core network may be performed based on the NG-C / U interface or the 6G-C / U interface. The function of the base station may be performed by a satellite. That is, the base station may be located on the satellite. Payloads may be processed by the base station located on the satellite. Base stations located on different satellites may be connected to the same core network. A single satellite may have one or more base stations. In the NTN of FIG. A-2b, an ISL between satellites may not be established, and in the NTN of FIG. A-2c, an ISL between satellites may be established.

[0067] Meanwhile, entities (e.g., satellites, base stations, UEs, communication nodes, gateways, etc.) constituting the NTN illustrated in FIGS. 1a, 1b, 2a, 2b, and / or 2c may be configured as follows. In the present disclosure, entities may be referred to as communication nodes.

[0068] FIG. 3 illustrates a block diagram of a device according to an embodiment of the present disclosure. The structure illustrated in FIG. 3 may be understood as the structure of at least a portion of a communication node, base station, satellite, or core network entity. The wireless device (300) illustrated in FIG. A-3 may be a mobile terminal such as a smartphone, tablet PC, or wearable device, but is not limited thereto.

[0069] FIG. 3 illustrates an example of a wireless device (300) in a wireless communication system according to one embodiment of the present disclosure. The wireless device (300) according to the embodiment of the present disclosure may be a mobile terminal such as a smartphone, tablet PC, or wearable device, but is not limited thereto.

[0070] Referring to FIG. 3, the wireless device (300) may include at least one control unit (310), at least one memory (320), at least one power unit (330), at least one transceiver unit (340), at least one input unit (350), at least one output unit (360), and / or at least one antenna (370).

[0071] The control unit (310) can control the memory (320) and / or the transceiver (340), and can be configured to implement the descriptions, functions, procedures, proposals, methods, and / or operation flowcharts disclosed in the present disclosure. The memory (320) can be connected to the control unit (310) and can store various information related to the operation of the control unit (310). For example, the memory (320) can perform some or all of the controls controlled by the control unit (310), or store software code including commands for performing the descriptions, functions, procedures, proposals, methods, and / or operation flowcharts disclosed in the present disclosure. The configuration of the memory is not limited in a specific manner. For example, it can be configured as at least one of a read-only memory (ROM) and a random access memory (RAM).

[0072] At least one control unit (310) may be referred to as a processor, microcontroller, microprocessor, or microcomputer. The descriptions, functions, procedures, proposals, methods, and / or operational flowcharts disclosed in the present disclosure may be implemented using firmware or software in the form of codes, instructions, and / or a set of instructions. Here, the firmware or software may execute another program stored in the memory (320), such as an OS. The control unit (310) may be implemented to support beamforming or directional routing operations in which signals from at least one antenna (370) are weighted differently to effectively steer signals outgoing in a desired direction.

[0073] Additionally, at least one control unit (310) may be coupled to a backhaul or network interface. The wireless device (300) may communicate with other wireless devices through the backhaul or network interface. The control unit (310) may include at least one processor. The processor may refer to a central processing unit (CPU), a graphics processing unit (GPU), or a dedicated processor on which methods according to embodiments of the present disclosure are performed.

[0074] At least one transceiver (340) may be connected to the control unit (310) and may transmit and / or receive a wireless signal via at least one antenna (370). The transceiver (340) may include a transmitter and / or a receiver. The at least one transceiver (340) may transmit user data, control information, wireless signals / channels, etc. mentioned in the methods and / or operation flowcharts of the present disclosure to at least one other device. For example, the at least one transceiver (340) may be connected to at least one control unit (310) and may transmit and receive wireless signals. In addition, the at least one control unit (310) may control the at least one transceiver (340) to transmit user data, control information, or wireless signals to at least one other device. The at least one transmitter (340) may receive a signal transmitted by another wireless device from at least one antenna (370). Additionally, at least one transceiver (24) may downconvert or upconvert the received signal to generate a baseband signal. At least one antenna (370) may be a plurality of physical antennas or a plurality of logical antennas (e.g., antenna ports).

[0075] The input unit (350) can obtain information such as user input, video, and audio, and may include various input means such as various mechanical / electronic input means, cameras, and microphones. The output unit (360) is for providing information to users by generating output related to sight, hearing, or touch, and may include a display, a speaker, a vibration module, and the like. The wireless device (300) supplies power through the power supply unit (330), and the power supply unit (330) may include a wired / wireless charging circuit, a battery, and the like.

[0076] A more detailed example of the structure of the control unit (310) and / or the transceiver unit (340) is shown in FIG. 4. FIG. 4 illustrates a block diagram of devices performing communication according to one embodiment of the present disclosure. FIG. 4 illustrates the structure of a first communication node (400a) and a second communication node (400b) that transmit and / or receive signals. In FIG. 4, each of the first communication node (400a) and the second communication node (400b) may be a base station or a UE.

[0077] Referring to FIG. 4, a first communication node (400a) can transmit a signal to a second communication node (400b). A transmission processor (411) included in the first communication node (400a) can receive data (e.g., a data unit) from a data source (410). The transmission processor (411) can receive control information from a controller (416). The control information can include at least one of system information, RRC configuration information (e.g., information configured by RRC signaling), MAC control information (e.g., MAC CE), or PHY control information (e.g., DCI, SCI).

[0078] The transmitting processor (411) may perform a processing operation (e.g., an encoding operation, a symbol mapping operation, etc.) on data to generate data symbol(s). The transmitting processor (411) may perform a processing operation (e.g., an encoding operation, a symbol mapping operation, etc.) on control information to generate control symbol(s). In addition, the transmitting processor (411) may generate synchronization / reference symbol(s) for a synchronization signal and / or a reference signal.

[0079] The Tx MIMO processor (412) may perform spatial processing operations (e.g., precoding operations) on data symbol(s), control symbol(s), and / or synchronization / reference symbol(s). The output (e.g., symbol stream) of the Tx MIMO processor (412) may be provided to modulators (MODs) included in the transceivers (413a to 413t). The modulators (MODs) may perform processing operations on the symbol streams to generate modulation symbols, and may perform additional processing operations (e.g., analog conversion operations, amplification operations, filtering operations, upconversion operations) on the modulation symbols to generate signals. The signals generated by the modulators (MODs) of the transceivers (413a to 413t) may be transmitted via the antennas (414a to 414t).

[0080] Signals transmitted by the first communication node (400a) may be received by antennas (464a to 464r) of the second communication node (400b). Signals received by the antennas (464a to 464r) may be provided to demodulators (DEMODs) included in transceivers (463a to 463r). The demodulator (DEMOD) may perform a processing operation (e.g., a filtering operation, an amplification operation, a downconversion operation, a digital conversion operation) on the signal to obtain samples. The demodulator (DEMOD) may perform an additional processing operation on the samples to obtain symbols. The MIMO detector (462) may perform a MIMO detection operation on the symbols. The receiving processor (461) may perform a processing operation (e.g., a deinterleaving operation, a decoding operation) on the symbols. The output of the receiving processor (461) may be provided to a data sink (460) and a controller (466). For example, data may be provided to the data sink (460) and control information may be provided to the controller (466).

[0081] Meanwhile, the second communication node (400b) can transmit a signal to the first communication node (400a). The transmitting processor (468) included in the second communication node (400b) can receive data (e.g., data units) from a data source (467) and perform a processing operation on the data to generate data symbol(s). The transmitting processor (468) can receive control information from the controller (466) and perform a processing operation on the control information to generate control symbol(s). In addition, the transmitting processor (468) can perform a processing operation on a reference signal to generate reference symbol(s).

[0082] The Tx MIMO processor (469) may perform spatial processing operations (e.g., precoding operations) on data symbol(s), control symbol(s), and / or reference symbol(s). The output (e.g., symbol stream) of the Tx MIMO processor (469) may be provided to modulators (MODs) included in the transceivers (463a to 463t). The modulators (MODs) may perform processing operations on the symbol streams to generate modulation symbols, and may perform additional processing operations (e.g., analog conversion operations, amplification operations, filtering operations, upconversion operations) on the modulation symbols to generate signals. The signals generated by the modulators (MODs) of the transceivers (463a to 463t) may be transmitted via the antennas (464a to 464t).

[0083] Signals transmitted by the second communication node (400b) may be received by the antennas (414a to 414r) of the first communication node (400a). The signals received by the antennas (414a to 414r) may be provided to demodulators (DEMODs) included in the transceivers (413a to 413r). The demodulator (DEMOD) may perform a processing operation (e.g., a filtering operation, an amplification operation, a downconversion operation, a digital conversion operation) on the signal to obtain samples. The demodulator (DEMOD) may perform an additional processing operation on the samples to obtain symbols. The MIMO detector (420) may perform a MIMO detection operation on the symbols. The receiving processor (419) may perform a processing operation (e.g., a deinterleaving operation, a decoding operation) on the symbols. The output of the receiving processor (419) may be provided to a data sink (418) and a controller (416). For example, data may be provided to the data sink (418) and control information may be provided to the controller (416).

[0084] Memories (415 and 465) can store data, control information, and / or program code. Scheduler (417) can perform scheduling operations for communication. Processors (411, 412, 419, 461, 468, 469) and controllers (416, 466) illustrated in FIG. 4 may be the processor (310) illustrated in FIG. 3 and may be used to perform the methods described in the present disclosure.

[0085] FIG. 5A and FIG. 5B illustrate block diagrams of a transmission path and a reception path of a communication node according to an embodiment of the present disclosure.

[0086] Referring to FIGS. 5A and 5B, a transmission path (510) may be implemented in a communication node that transmits a signal, and a reception path (520) may be implemented in a communication node that receives a signal. The transmission path (510) may include a channel coding and modulation block (511), an S-to-P (serial-to-parallel) block (512), an N IFFT (Inverse Fast Fourier Transform) block (513), a P-to-S (parallel-to-serial) block (514), a CP (cyclic prefix) addition block (515), and an UC (up-converter) (UC) (516). The receiving path (520) may include a DC (down-converter) (521), a CP removal block (522), an S-to-P block (523), an N FFT block (524), a P-to-S block (525), and a channel decoding and demodulation block (526). Here, N may be a natural number.

[0087] In the transmission path (510), information bits may be input to a channel coding and modulation block (511). The channel coding and modulation block (511) may perform a coding operation (e.g., low-density parity check (LDPC) coding operation, polar coding operation, etc.) and a modulation operation (e.g., quadrature phase shift keying (QPSK), quadrature amplitude modulation (QAM), etc.) on the information bits. The output of the channel coding and modulation block (511) may be a sequence of modulation symbols.

[0088] The S-to-P block (512) can convert modulation symbols in the frequency domain into parallel symbol streams to generate N parallel symbol streams. N can be an IFFT size or an FFT size. The N IFFT block (513) can perform an IFFT operation on the N parallel symbol streams to generate signals in the time domain. The P-to-S block (514) can convert the output (e.g., parallel signals) of the N IFFT block (513) into a serial signal to generate a serial signal.

[0089] The CP addition block (515) can insert a CP into a signal. The UC (516) can up-convert the frequency of the output of the CP addition block (515) to an RF (radio frequency) frequency. Additionally, the output of the CP addition block (515) can be filtered at the baseband before up-conversion.

[0090] A signal transmitted from a transmission path (510) may be input to a reception path (520). An operation in the reception path (520) may be the reverse operation of the operation in the transmission path (510). A DC (521) may down-convert the frequency of the received signal to a baseband frequency. A CP removal block (522) may remove a CP from a signal. The output of the CP removal block (522) may be a serial signal. An S-to-P block (523) may convert the serial signal into parallel signals. An NFFT block (524) may perform an FFT algorithm to generate N parallel signals. A P-to-S block (525) may convert the parallel signals into a sequence of modulation symbols. A channel decoding and demodulation block (526) may perform a demodulation operation on the modulation symbols and perform a decoding operation on the result of the demodulation operation to restore data.

[0091] In FIGS. 5A and 5B , Discrete Fourier Transform (DFT) and Inverse DFT (IDFT) may be used instead of FFT and IFFT. Each of the blocks (e.g., components) in FIGS. 5A and 5B may be implemented by at least one of hardware, software, or firmware. For example, in FIGS. 5A and 5B , some blocks may be implemented by software, and the remaining blocks may be implemented by hardware or a “combination of hardware and software.” In FIGS. 5A and 5B , a single block may be subdivided into multiple blocks, multiple blocks may be integrated into a single block, some blocks may be omitted, and blocks supporting other functions may be added.

[0092] FIG. 6 illustrates an example of a system frame in a wireless communication system according to an embodiment of the present disclosure.

[0093] Referring to Figure 6, time resources in a communication system can be divided into frame units. For example, system frames can be set consecutively in the time domain of the communication system. The length of a system frame can be 10 ms (milliseconds). The system frame number (SFN) can be set from #0 to #1023. In this case, 1024 system frames can be repeated in the time domain of the communication system. For example, the SFN of the system frame after system frame #1023 can be #0.

[0094] A system frame may include two half frames. A half frame may be 5 ms long. A half frame located at the beginning of the system frame may be referred to as "half frame #0," and a half frame located at the end of the system frame may be referred to as "half frame #1." A system frame may include 10 subframes. A subframe may be 1 ms long. The 10 subframes within a system frame may be referred to as "subframes #0-9."

[0095] FIG. 7 illustrates an example of a subframe in a wireless communication system according to an embodiment of the present disclosure.

[0096] Referring to Fig. 7, one subframe can include n slots, where n can be a natural number. Therefore, one subframe can be composed of one or more slots.

[0097] FIG. 8 illustrates an example of a slot in a wireless communication system according to an embodiment of the present disclosure.

[0098] Referring to Figure 8, a single slot may contain one or more symbols. A single slot, as illustrated in Figure A-8, may contain 14 symbols. The length of a slot may vary depending on the number and length of symbols contained in the slot. Alternatively, the length of a slot may vary depending on the numerology.

[0099] In a communication system, the numerology applied to physical signals and channels can be variable. The numerology can be variable to meet various technical requirements of the communication system. In a communication system applying CP (cyclic prefix)-based OFDM waveform technology, the numerology can include subcarrier spacing and CP length (or CP type). [Table 1] may be an embodiment of a method for configuring a numerology for a CP-OFDM-based communication system. At least some of the numerologies in [Table 1] may be supported depending on the frequency band in which the communication system operates. In addition, the communication system may additionally support numerologies not listed in [Table 1].

[0100] Subcarrier spacing 15kHz 30kHz 60kHz 120kHz 240kHz 480kHz OFDM symbol length [μs] 66.733.316.78.34.22.1 CP length [us] 4.762.381.190.600.300.151 Number of OFDM symbols in ms 142856112224448

[0101] When the subcarrier spacing is 15 kHz (e.g., μ=0), the slot length can be 1 ms. In this case, one system frame can contain 10 slots. When the subcarrier spacing is 30 kHz (e.g., μ=1), the slot length can be 0.5 ms. In this case, one system frame can contain 20 slots.

[0102] When the subcarrier spacing is 60 kHz (e.g., μ=2), the slot length can be 0.25 ms. In this case, one system frame can contain 40 slots. When the subcarrier spacing is 120 kHz (e.g., μ=3), the slot length can be 0.125 ms. In this case, one system frame can contain 80 slots. When the subcarrier spacing is 240 kHz (e.g., μ=4), the slot length can be 0.0625 ms. In this case, one system frame can contain 160 slots.

[0103] A symbol may be configured as a downlink (DL) symbol, a flexible (FL) symbol, or an uplink (UL) symbol. A slot consisting of only DL symbols may be referred to as a "DL slot," a slot consisting of only FL symbols may be referred to as an "FL slot," and a slot consisting of only UL symbols may be referred to as a "UL slot."

[0104] FIG. 9 illustrates the timing relationship of uplink and downlink in a wireless communication system according to an embodiment of the present disclosure.

[0105] There is one frame set in the uplink and one frame set in the downlink for each carrier. The uplink frame number i for transmission from the UE is It must be started before, and must coincide with the start of the corresponding downlink frame observed at the UE.

[0106] Here, and can be provided by adjusting the transmission timing of the synchronization procedure. However, for msgA transmission on PUSCH (physical uplink shared channel), NTA = 0.

[0107] is derived from the upper layer parameters ta-Common, ta-CommonDrift, ta-CommonDriftVariant, which if not configured am.

[0108] is computed by the UE only if the UE's position and related upper layer parameters are configured according to the transmission timing adjustment of the synchronization procedure, otherwise am.

[0109] As described above, the timing of downlink and uplink can be adjusted based on the transmission timing adjustment of the synchronization procedure. For example, the terminal can receive the value of at least one timing advance (TA) offset for the serving cell and adjust the timing based on the received at least one TA offset value. Here, the at least one TA offset value can be configured differently depending on the TCI state, the carrier, or the TRP.

[0110] The aforementioned TA (timing advance) can be determined based on the signal transmission and reception times of the random access procedure. Specifically, the terminal can identify uplink resources and determine uplink transmission power based on control information and / or configuration information received from the base station. Then, the terminal can transmit a PUSCH using the identified resources and the determined power. For example, the base station can determine the TA based on the arrival time of the preamble transmitted by the terminal. Sections 8.1 and 8.2 of 3GPP TS 38.213 define the random access procedure.

[0111] A terminal that has performed a random access procedure can receive configuration information from the base station and transmit a PUSCH based on the configuration information. Specifically, the terminal can identify uplink resources and determine uplink transmission power based on control information and / or configuration information received from the base station. Then, the terminal can transmit a PUSCH using the identified resources and the determined power. Section 7.11 of 3GPP TS 38.213 defines the PUSCH transmission procedure for the terminal.

[0112] The aforementioned PUSCH transmission can be controlled via a physical uplink control channel (PUCCH). In NR, a terminal transmits uplink control information (UCI) to a base station via the PUCCH. The control information may include at least one of a HARQ-ACK indicating whether demodulation / decoding of a TB (transport block) received by the terminal via the PDSCH was successful, a scheduling request (SR) for requesting resource allocation from a PUSCH base station for uplink data transmission by the terminal, and channel state information (CSI), which is information for reporting the channel status of the terminal. The PUCCH can be repeatedly transmitted, and the repeated transmission procedure can be performed based on the following section 9.2.6 of 3GPP TS 38.213.

[0113]

[0114] Meanwhile, NTN reference scenarios can be defined as shown in [Table 3] below.

[0115] NTN shown in Fig. 1a NTNGEO shown in Fig. 2a Scenario A Scenario BLEO (steerable beam) Scenario C1 Scenario D1 LEO (beam moving with satellite) Scenario C2 Scenario D2

[0116] If the satellite (110) in the NTN illustrated in FIG. 1a and / or FIG. 1b is a GEO satellite (e.g., a GEO satellite supporting transparent functionality), this may be referred to as “Scenario A.” If the first satellite (211) and the second satellite (212) in the NTN illustrated in FIG. 2a, FIG. 2b, and / or FIG. 2c are each GEO satellites (e.g., a GEO supporting regeneration functionality), this may be referred to as “Scenario B.”

[0117] If the satellite (110) in the non-terrestrial network illustrated in FIG. 1a and / or FIG. 1b is a LEO satellite having steerable beams, this may be referred to as “Scenario C1.” If the satellite (110) in the non-terrestrial network illustrated in FIG. 1a and / or FIG. 1b is a LEO satellite having beams move with the satellite, this may be referred to as “Scenario C2.” If each of satellite #1 (211) and satellite #2 (212) in the non-terrestrial network illustrated in FIG. 2a, FIG. 2b, and / or FIG. 2c is a LEO satellite having steerable beams, this may be referred to as “Scenario D1.” In the non-terrestrial network illustrated in FIG. 2a, FIG. 2b, and / or FIG. 2c, if each of satellite #1 (211) and satellite #2 (212) is a LEO satellite having beams that travel with the satellite, this may be referred to as “Scenario D2.”

[0118] Parameters for the NTN reference scenarios defined in [Table 3] can be defined as shown in [Table 4] below.

[0119] Scenario A and B Scenario C and D Altitude 35,786 km 600 km 1,200 km Spectrum (service link) <6 GHz (e.g., 2 GHz) > 6 GHz (e.g., DL 20 GHz, UL 30 GHz) Maximum channel bandwidth capability (service link) 30 MHz for band < 6 GHz 1 GHz for band > 6 GHz Maximum distance between satellite and communication node (e.g., UE) at minimum elevation angle 40,581 km 1,932 km (600 km altitude) 3,131 km (1,200 km altitude) Maximum round trip delay (RTD) (propagation delay only) Scenario A: 541.46 ms (service and feeder links) Scenario B: 270.73 ms (service link only) Scenario C: (Transparent payload: service and feeder links) -25.77 ms (600 km) Altitude) -41.77ms (1200km altitude) Maximum differential delay within a cell 10.3m3.12ms (600km altitude) 3.18ms (1200km altitude) Service link NR or 6G Feeder link Radio interface defined in 3GPP or non-3GPP

[0120] Additionally, in the NTN reference scenario defined in [Table 3], the delay constraint can be defined as in [Table 5] below.

[0121] Scenario A Scenario B Scenario C1-2 Scenario D1-2 Satellite altitude 35,768 km 600 km Maximum RTD on the air interface between the base station and the UE 541.75 ms (worst case) 270.57 ms 28.41 ms 12.88 ms Minimum RTD on the air interface between the base station and the UE 477.14 ms 238.57 ms 8 ms 4 ms

[0122] FIG. 10A and FIG. 10B illustrate examples of protocol stacks of a user plane and a control plane in a transparent payload-based NTN in a wireless communication system according to an embodiment of the present disclosure.

[0123] Referring to FIGS. 10A and 10B , user data may be transmitted and / or received between a UE and a core network (e.g., UPF), and control data (e.g., control information) may be transmitted and / or received between a UE and a core network (e.g., AMF). Each of the user data and the control data may be transmitted and / or received via a satellite and / or a gateway. The protocol stack of the user plane illustrated in FIG. 10A may be applied identically or similarly to a 6G communication network. The protocol stack of the control plane illustrated in FIG. 10B may be applied identically or similarly to a 6G communication network.

[0124] FIG. 11a and FIG. 11b illustrate examples of protocol stacks of a user plane and a control plane in a regenerative payload-based NTN in a wireless communication system according to an embodiment of the present disclosure.

[0125] Referring to FIGS. 11A and 11B , user data and control data (e.g., control information) may be transmitted and / or received via an interface between a UE and a satellite (e.g., a base station). The user data may include a user protocol data unit (PDU). The protocol stack of the satellite radio interface (SRI) may be used to transmit and / or receive the user data and / or control data between the satellite and the gateway. The user data may be transmitted and / or received via a GPRS (general packet radio service) tunneling protocol (GTP)-U tunnel between the satellite and the core network.

[0126] In relation to NTN communication, an NTN may be configured to provide non-terrestrial NR access to a UE via an NTN payload and an NTN gateway. A service link may refer to a connection between an NTN payload and a UE, and a feeder link may refer to a link between an NTN gateway and an NTN payload. The configuration and procedures for the NTN, service link, and feeder link may be implemented in combination with, or partially performed or modified from, the configuration and procedures disclosed in section 16.14 of 3GPP TS 38.300.

[0127] Figure 12 illustrates an example of an NTN providing non-terrestrial NR access to a UE via an NTN payload and an NTN gateway. Figure 12 shows a service link between the NTN payload and the UE, and a feeder link between the NTN gateway and the NTN payload.

[0128] The NTN payload transparently transmits wireless protocols received from the UE via the service link to the NTN gateway via the feeder link, or vice versa. The connectivity supported by the NTN payload is as follows.

[0129] - NTN gateway can serve multiple NTN payloads.

[0130] - A single NTN payload can be served by multiple NTN gateways.

[0131] - NTN payloads can change carrier frequency before being retransmitted on the service link, or vice versa (on each feeder link).

[0132] In NTN, in addition to the network identifier, the following may apply:

[0133] - A tracking area corresponds to a fixed geographic area. Each mapping is configured in the RAN.

[0134] - Mapped cell ID as defined in Section 16.14.5.

[0135] Three types of service links are supported:

[0136] - Earth-fixed: The service link may be provided by beam(s) that continuously cover the same geographic area at all times (e.g. Geosynchronous Orbit (GSO) satellites).

[0137] - Quasi-earth-fixed: The service link may be provided by beam(s) that cover one geographic area for a limited period and another geographic area for another period (e.g., NGSO (non-GSO) satellites producing steerable beams).

[0138] - Earth-moving: The service link may be provided by beam(s) moving over the surface of the Earth (e.g., NGSO satellites producing fixed beams or non-steerable beams).

[0139] A gNB operating as an NGSO satellite can provide a quasi-Earth fixed service link or an Earth mobile service link, and a gNB operating as a GSO satellite can provide an Earth fixed service link.

[0140] Timing and synchronization are as follows:

[0141] Regarding scheduling and timing, downlink and uplink frames are aligned using an offset given by the NTA offset (see Section 4.2 of TS 38.213) from the uplink time synchronization reference point (RP). To accommodate the propagation delay of the NTN, some timing relationships are enhanced by a common timing advance (TA) and two offsets, K_offset and k_mac.

[0142] - Common TA is a timing offset configured equal to the round trip time (RTT) between the RP and NTN payloads.

[0143] - K offset is a configured scheduling offset that must be greater than or equal to the sum of the service link RTT and common TA.

[0144] - k mac is an offset that is configured to be approximately equal to the RTT between the RP and gNB.

[0145] Scheduling offset K offset is used to allow the UE sufficient processing time between downlink reception and uplink transmission (see TS 38.213). Offset k mac is used to delay the application of downlink configuration indicated by MAC CE command on PDSCH (see TS 38.213) and for estimation of UE-gNB RTT (see TS 38.321). If downlink and uplink frame timing are not aligned at the gNB, offset k mac can be provided by the network. Also, the offset k mac is used to determine the RAR window / MsgB window start time after sending Msg1 / MsgA in the random access procedure (see TS 38.213). Service link RTT, feeder link RTT, RP, common TA, k mac And TTA is as shown in Fig. 13. Fig. 13 shows the timing relationship between objects included in NTN.

[0146] The network can configure HARQ operation as follows:

[0147] - For downlink, HARQ feedback can be enabled or disabled on a per-HARQ process basis. Disabling HARQ feedback allows scheduling a HARQ process before one HARQ RTT has elapsed since the last scheduling.

[0148] - For uplink, HARQ modes (e.g., HARQ mode A or HARQ mode B) can be configured for each HARQ process. HARQ mode B allows scheduling a HARQ process before one HARQ RTT has elapsed since the last scheduling.

[0149] For HARQ processes configured to have HARQ feedback enabled / disabled, it is up to the network implementation to ensure the appropriate HARQ feedback configuration (e.g., all enabled or all disabled) for the HARQ processes used in the SPS configuration. For HARQ processes configured in HARQ mode, it is up to the network implementation to ensure the appropriate HARQ mode configuration (e.g., all HARQ mode A or all HARQ mode B) for the HARQ processes used in the configured grant (CG) configuration.

[0150] Meanwhile, in NTN, a base station can transmit system information (e.g., SIB19) containing satellite assistance information for NTN access. A UE can receive system information (e.g., SIB19) from the base station, check the satellite assistance information included in the system information, and perform communication (e.g., non-terrestrial communication) based on the satellite assistance information. SIB19 can include the information element(s) defined in [Table 6] below.

[0151] SIB19-r17 :: = SEQUENCE {ntn-Config-r17 NTN-Config-r17 OPTIONAL,t-service-r17 INTEGER(1..549755813887) OPTIONAL,referenceLocation-r17 ReferenceLocation-r17 OPTIONAL,distanceThresh-r17 INTEGER(1..65525) OPTIONAL,ntn-NeighCellConfigList-r17 NTN-NeighCellConfigList-r17 OPTIONAL,lateNonCRiticalExtension OCTET STRING...,[[ntn-NeighCellConfigListExt-v1720 NTN-NeighCellConfigList-r17 OPTIONAL,]],[[movingReferenceLocation-r18 ReferenceLocation-r17 OPTIONAL,satSwitchWithReSync-r18 SatSwitchWithReSync-r18 OPTIONAL,]]}NTN-NeighCellConfigList-r17 :: = SEQUENCE (SIZE(1..maxCellNTN-r17)) OFNTN-NeighCellConfig-r17NTN-NeighCellConfig-r17 :: = SEQUENCE {ntn-Config-r17 NTN-Config-r17 OPTIONAL,carrierFreq-r17 ARFCN-ValueNR OPTIONAL,physCellId-r17 PhysCellId OPTIONAL}SatSwitchWithReSync-r18 :: = SEQUENCE {ntn-Config-r18 NTN-Config-r17,t-ServiceStart-r18 INTEGER(1..549755813887) OPTIONAL,ssb-TimeOffset-r18 INTEGER(1..159) OPTIONAL}

[0152] NTN-Config defined in [Table 6] may include information element(s) defined in [Table 7] below.

[0153] NTN-Config-r17 ::= SEQUENCE {epochTime-r17 EpochTime-r17ntn-UISyncValidityDuration-r17 ENUMERATED {s5, s10, s15, s20, s25, s30, s35, s40, s45, s50, s55, s60, s120, s180, s240, s900}cellSpecificKoffset-r17 INTEGER(1..1023)kmac-r17 INTEGER(1..512)ta-Info-r17 TA-Info-r17ntn-PolarizationDL-r17 ENUMERATED {rhcp, lhcp, linear}ntn-PolarizationUL-r17 ENUMERATED {rhcp, lhcp, linear}ephemerisInfo-r17 EphemerisInfo-r17ta-Report-r17 ENUMERATED {enabled}...}EpochTime-r17 ::= SEQUENCE {sfn-r17 INTEGER(1..1023)subFrameNR-r17 INTEGER(1..9)}TA-Info-r17 ::= SEQUENCE {ta-Common-r17 INTEGER(1..66485757)ta-CommonDrift-r17 INTEGER(-257303..257303)ta-CommonDriftVarant-r17 INTEGER(0..28949)}

[0154] EphemerisInfo defined in [Table 7] may include information element(s) defined in [Table 8] below.

[0155] EphemerisInfo-r17 ::= CHOICE {positionVelocity-r17 PositionVelocity-r17,orbital-r17 Orbital-r17}PositionVelocity-r17 ::= SEQUENCE {positionX-r17 PositionStateVector-r17,positionY-r17 PositionStateVector-r17,positionZ-r17 PositionStateVector-r17, velocity V INTEGER (0..1048575),periapsis-r17 INTEGER (0..268435455),longitude-r17 INTEGER (0..268435455),incliating-r17 INTEGER (-67108864..67108863),meanAnomaly-r17 INTEGER (0..268435455)}PositionStateVector-r17 ::= INTEGER (-33554432..33554431)VelocityStateVector-r17 ::= INTEGER (-131072..131071)

[0156] Additionally, if there is a difference in the NTN connection setup compared to the TN connection, the NTN-parameter may include the information elements defined in [Table 9] below to convey the UE wireless connection capability parameters applicable to the NTN connection.

[0157] NTN-parameters-r17 ::= SEQUENCE {inactiveStateNTN-r17 ENUMERATED {supported} OPTIONAL,ra-SDT-NTN-r17 ENUMERATED {supported} OPTIONAL,srb-SDT-NTN-r17 ENUMERATED {supported} OPTIONAL,measAndMobParametersNTN-r17 MeasAndMobParameters OPTIONAL,mac-ParametersNTN-r17 Mac-Parameters OPTIONAL,phy-ParametersNTN-r17 Phy-Parameters OPTIONAL,fdd-ADD-UE-NR-CapabilitiesNTN-r17 UE-NR-CapabilityNTNAddXDD-Mode OPTIONAL,frl-ADD-UE-NR-CapabilitiesNTN-r17 UE-NR-CapabilityNTNAddFRX-Mode OPTIONAL,ue-BasedPerfMeas-ParametersNTN-r17 UE-BasedPerfMeas-Parameters-r16 OPTIONAL,son-ParametersNTN-r17 SON-Parameters-r16 OPTIONAL}

[0158] The coverage of Phase 3 NTN discussed in Rel-19 RAN WG1 is presented in the work item description (WID), and the contents regarding uplink capacity enhancement are as follows.

[0159] Uplink Capacity / Throughput Enhancement for FR1-NTN [RAN1, RAN2, RAN4]* Study then specify, if beneficial, DFT-s-OFDM PUSCH enhancements via Orthogonal Cover Codes (OCC)- Determine the achievable capacity improvement to be targeted taking into account realistic impairments (e.g. Doppler, time variation, phase distortion, etc)Specify necessary signalling, if needed- Update RF requirements accordingly, if needed- Note: The study can consider orthogonal cover codes across OFDM symbols, across slots, and / or within an OFDM symbol.- Note: the study phase is targeted to be completed by RAN#104* Notes for this objective:- The enhancement is not targeting improvements / impacts of MU-MIMO capability- The enhancement is not targeted to PUSCH DMRS- No enhancement for initial access- Enhancements to PRACH are not in scope.- This feature may be applicable for UEs operating in terrestrial networks based on a common design

[0160] Referring to the WID in [Table 10], the application of orthogonal cover codes (OCCs) to the PUSCH payload is currently under discussion to increase uplink capacity and throughput for DFT-s-OFDM PUSCH. Approvals from recent meetings related to this topic are as follows.

[0161] Proposal 1-3Deprioritize OCC length 8 for PUSCH for inter-slot OCC, inter-symbol(s) OCC, and intra-symbol OCC.Proposal 2-1Supported OCC techniques [without combination]:o Inter-slot time-domain OCC with PUSCH repetition Type A with OCC length 2 [and 4]o One OCC technique with OCC length 4 [and 2] to be down-selected between:- Inter-symbol(s) time domain OCC- Intra-symbol pre-DFT-s OCC (comb-like structure as in PUCCH format 4)R1-2405507 Feature lead summary #2 of AI 9.11.3 on NR-NTN uplink capacity and throughput Moderator (MediaTek)AgreementFor the normative phase, at least one of the OCC techniques will be specified:- Inter-slot time-domain OCC with PUSCH repetition Type A with OCC length 2 or 4- Inter-symbol(s) time domain OCC with OCC length 2 or 4- Intra-symbol pre-DFT-s OCC (comb-like structure as in PUCCH format 4) with OCC length 2 or 4- FFS Combination of OCC techniques including multiplexing of 8 UEs- FFS Use of OCC techniques with TBoMS- FFS Backward compatibility with non-Rel-19 UEs.

[0162] To summarize the above approvals, OCC can be applied within a symbol (intra-symbol OCC), between symbols (inter-symbol OCC), and / or between slots (inter-slot OCC), and it is expected that at least one method will be decided upon based on the results of future discussions. For each method, OCC lengths of 2 or 4 are considered. As a future research topic, it is expected that PUSCH multiplexing for up to 8 UEs will be supported through OCC technology that combines intra-symbol, inter-symbol, or inter-slot OCC methods. In addition, OCC usage in TBoMS (transport block processing over multiple slots) and compatibility with Rel-18 or earlier UEs will also be discussed.

[0163] Figures 14a to 14c illustrate examples of OCC application methods in a wireless communication system according to an embodiment of the present disclosure. Figures 14a, 14b, and 14c illustrate three methods for applying OCC: intra-symbol OCC, inter-symbol OCC, and inter-slot OCC. In the present disclosure, values ​​multiplied for OCC may be referred to as OCC weights, OCC weight values, OCC weight vectors, OCC sequences, OCC codes, etc. In addition, any one of the available OCC weight vectors may be specified using an OCC weight index, an OCC sequence index, etc.

[0164] Referring to Fig. 14a, in the case of OCC within a symbol, OCC can be applied before the transform precoding (e.g., DFT) operation. Additionally, by using appropriate OCC weights (e.g., [w0, w1] or [w0, w1, w2, w3]), a comb-shaped signal is generated in the stage after the frequency transform precoding as shown in Fig. 14a. For example, when w0=+1 and w1=+1 in the OCC length 2, a signal is output to the subcarriers of index 2k (k>=0 integer), and a signal of 0+j0 is output to the subcarriers of other indices 2k+1 (k>=0 integer). Similarly, for OCC length 4, depending on the weight values ​​applied to OCC (e.g., w0, w1, w2, w3), signals are generated on subcarriers of indices 4k, 4k+1, 4k+2, or 4k+3 (k>=0 integer), and the DFT output of 0+j0 is obtained on other subcarriers.

[0165] Referring to Fig. 14b, in the case of inter-symbol OCC, OCC can be applied to multiple PUSCH data symbols (e.g., symbols carrying payloads, excluding DMRS symbols) within one slot, as shown in Fig. 14b. In the example of Fig. 14b, a symbol marked with X indicates a symbol to which a PUSCH is not assigned. In Fig. 14b, the pattern filling each symbol indicates one OFDM symbol and a symbol in which the symbol is repeated, and each symbol is transmitted after being multiplied by the weight of the OCC. For example, in the first example (1321) of Fig. 14b, two symbols (e.g., sym3, sym4) are symbols carrying the same data, and are transmitted after being multiplied by the weights of w0 and w1, respectively. As another example, in the second example (1322) of Fig. 14b, sym3, sym4, sym5, and sym6 carry the same data, which are transmitted after being multiplied by w0, w1, w2, and w3, respectively.

[0166] In addition, various OCC schemes can be considered. For example, in the third example (1323) of Fig. 14b, a case can be considered where sym3 and sym5 carry the same data. In this case, sym3 and sym5 are multiplied by w0 and w1, respectively, and then transmitted. Other PUSCH symbols can also be multiplied by w0 and w1 according to the same rule and then transmitted. For example, in the third example (1323) of Fig. 14b, OCC is applied to each of the four symbol pairs: (sym3, sym5), (sym4, sym6), (sym7, sym9), and (sym8, sym10).

[0167] Referring to Fig. 14c, for inter-slot OCC, a method similar to inter-symbol OCC can be applied. In this method, the PUSCH within one slot is repeated in subsequent slots, multiplied by an OCC weight, and then transmitted. For example, as shown in Fig. 14c, inter-slot OCC can be applied. Referring to Fig. 14c, in slot N, at least one PUSCH symbol is multiplied by w0 and then transmitted, and in slot N+1, the PUSCH signal of slot N is repeated, multiplied by w1, and then transmitted. Here, the DMRS signal of the repeated PUSCH may be the same or different. In addition, the number of PUSCH data symbols in slot N and slot N+1 may also be the same or different.

[0168] Additionally, the inter-slot OCC example presented in Fig. 14c corresponds to a case where the OCC length = 2 and the OCC group size = 1, as in the first example (1321) of Fig. 14b, are applied in the form of an inter-slot OCC. In a similar manner, the second example (1322) and the third example (1323) of Fig. 14b can be applied / extended in the form of an inter-slot OCC.

[0169] A method that fuses the three types of OCC methods illustrated in FIGS. 14a, 14b, and 14c may be considered. For example, a method in which intra-symbol OCC and inter-symbol OCC are applied together, or an inter-symbol OCC and inter-slot OCC are applied together may be considered. FIG. 15 illustrates an example of a method for fuse-ing intra-symbol OCC and inter-symbol OCC in a wireless communication system according to an embodiment of the present disclosure. The example of FIG. 15 corresponds to a case in which the OCC length for intra-symbol OCC is 4, and the OCC length for inter-symbol OCC is 2. Through a method like FIG. 15, an effect similar to that of OCC length = 8 is obtained, and it is possible to multiplex 8-UE or 8-layer PUSCH within the same resource. Similarly to FIG. 15, by fuse-ing intra-symbol OCC length = 2 and inter-symbol OCC length = 4, 8-UE or 8-layer PUSCH multiplexing can be performed similarly. In addition, similar to FIG. 15, a method that fuses inter-symbol OCC and inter-slot OCC may also be considered. The weights applied to the intra-symbol OCC and inter-symbol OCC applied in FIG. 15 may be the same or different.

[0170]

[0171] The present disclosure relates to a method and device for applying OCC to uplink communication in a non-terrestrial network (NTN) environment. Specifically, the present disclosure proposes a technique for associating weight information with a PUSCH DMRS port number assigned to each UE and / or layer to indicate OCC weight information used in the OCC of a PUSCH data symbol.

[0172] In an NTN environment, a terminal transmitting a PUSCH with repeated transmissions and OCC can use a single layer. For convenience of explanation, the present disclosure assumes that each terminal transmits a single-layer PUSCH. However, if a terminal transmits a two-layer PUSCH, the embodiments described below can be applied to each layer.

[0173] [Mathematical expression 1] represents the generation rule of the DMRS symbol.

[0174]

[0175]

[0176]

[0177]

[0178]

[0179] In [Equation 1], is the frequency location and time location DMRS symbol value, is the DMRS port number, and are OCC weights, means an element of the DMRS sequence.

[0180] Terminals multiplexed based on OCC can expect that different PUSCH DMRS port numbers will be set. Here, the DMRS port number means p0 in [Mathematical Formula 1]. In the case of DMRS configuration type 1 of CP-OFDM, the DMRS port number can have an integer in the range [0, 7] or [0, 15], and in the case of DFT-s-OFDM, the DMRS port number can have an integer in the range [0, 7]. Depending on the DMRS port number p0, the location of the DMRS frequency resource and w in [Mathematical Formula 1] f () and wt () values ​​are determined. For normal PUSCH reception, the base station can indicate different DMRS port numbers to the terminal.

[0181] In order for the base station to receive the multiplexed PUSCH data symbols through the aforementioned OCC, different OCC weights are assigned to multiple UEs that are multiplexed based on the OCC. For example, if four UEs are multiplexed through OCC between symbols with an OCC length of 4, each UE applies the OCC using an orthogonal weight vector. For example, the sets of weight vectors for the four UEs may be [1,1,1,1], [1,-1,1,-1], [1,j,-1,-j], [1,-j,-1,j].

[0182] As described above, terminals multiplexed with OCC are assigned different OCC weight vectors and DMRS port numbers. Therefore, by linking the OCC weight vector to the DMRS port number, the base station can specify the OCC weight vector to be applied to the terminal.

[0183]

[0184] FIG. 16 illustrates an example of a procedure for applying OCC in a wireless communication system according to one embodiment of the present disclosure. FIG. 16 illustrates signal exchange between a terminal (1610) and a base station (1620).

[0185] Referring to FIG. 16, in step S1601, the terminal (1610) transmits capability information including information about uplink OCC to the base station (1620). The information about uplink OCC may include information indicating whether OCC application is possible for NTN data symbols. Here, whether OCC application is possible may be indicated explicitly or implicitly. For example, whether OCC application is possible may be expressed using a release number supported by the terminal (1610). As another example, whether OCC application is possible may be indicated by an explicit indicator.

[0186] In step S1603, the base station (1620) transmits configuration information for an uplink OCC to the terminal (1610). The configuration information may include information necessary for the terminal (1610) to apply the OCC to uplink data. For example, the configuration information may include at least one of information regarding conditions for applying the OCC, information regarding the type of OCC applied to the PUSCH, information regarding the length of the OCC applied to the PUSCH, or information regarding the group size of the OCC. Additionally, according to one embodiment, the configuration information may include information regarding OCC weights associated with DMRS port numbers.

[0187] In step S1605, the terminal (1610) determines OCC weights corresponding to the DMRS ports. That is, each DMRS port corresponds to one OCC weight. According to one embodiment, the terminal (1610) determines the association between the DMRS port numbers and the OCC weights based on the configuration information. That is, the terminal (1610) can determine the association between the DMRS port numbers and the OCC weights based on the received configuration information. According to another embodiment, the terminal (1610) can determine the association between the DMRS port numbers and the OCC weights according to a predefined rule. That is, the association between the DMRS port numbers and the OCC weights may not be separately signaled but may be predefined.

[0188] In step S1607, the base station (1620) transmits a DMRS port number for an uplink channel. The DMRS port number may be indicated via DCI or an RRC message. For example, if the uplink channel, i.e., PUSCH, is scheduled according to dynamic scheduling, the DMRS port number may be indicated by a parameter (e.g., antenna port) included in the DCI that schedules the PUSCH. As another example, if the uplink channel, i.e., PUSCH, is scheduled according to a configured grant (CG), the DMRS port number may be indicated by a parameter (e.g., antenna port) included in an RRC message that configures the CG.

[0189] In step S1609, the terminal (1610) transmits uplink data to which OCC is applied to the base station (1620). Specifically, the terminal (1610) may repeatedly transmit the uplink data, multiply the OCC weight by the repetition unit (e.g., slot), and transmit the data. At this time, the terminal (1610) may transmit the PUSCH based on the OCC weight vector associated with the DMRS port number, i.e., the antenna port number indicated by DCI or RRC signaling. If the terminal (1610) cannot apply the PUSCH OCC, the terminal (1610) may only perform repeated PUSCH transmission without applying the OCC.

[0190]

[0191] FIG. 17 illustrates an example of a procedure for a terminal to transmit a PUSCH using OCC in a wireless communication system according to an embodiment of the present disclosure. FIG. 17 also illustrates an operating method of the terminal.

[0192] Referring to FIG. 17, in step S1701, the terminal transmits capability information. Prior to this, the terminal may perform a random access procedure to connect to the base station, establish a connection, and then receive a request for capability information. According to one embodiment, the capability information includes information regarding uplink transmission, and the information regarding uplink transmission may include information indicating whether OCC application to NTN data symbols is possible.

[0193] In step S1703, the terminal receives configuration information related to the OCC. The configuration information related to the OCC may include at least one of information required for OCC application, information about an uplink channel to which the OCC is applied, and information about scheduling of the uplink channel to which the OCC is applied. In addition, the information required for OCC application may include at least one of information about conditions for OCC application, information about the type of OCC applied to the PUSCH, information about the length of the OCC applied to the PUSCH, or information about the group size of the OCC. In addition, according to one embodiment, the information required for OCC application may include information about OCC weights associated with antenna port numbers.

[0194] In step S1705, the UE verifies the DMRS port number for the PUSCH. The UE can verify the antenna port based on configuration information or control information related to PUSCH allocation or scheduling. Here, the verified antenna port information corresponds to the DMRS port information.

[0195] In step S1707, the terminal transmits a PUSCH using the OCC weight associated with the DMRS port number. The terminal generates complex symbols containing uplink data and maps them to the time-frequency resources allocated for the PUSCH. At this time, the complex symbols are repeated in repetition units (e.g., symbols or slots), and the terminal multiplies the repetition units by the OCC weights and maps them to the time-frequency resources. In addition, the terminal can generate OFDM symbols by performing OFDM modulation and transmit the OFDM symbols.

[0196]

[0197] FIG. 18 illustrates an example of a procedure for a base station to receive a PUSCH using OCC in a wireless communication system according to an embodiment of the present disclosure. FIG. 18 also illustrates an operation method of a terminal.

[0198] Referring to FIG. 18, in step S1801, the base station receives capability information. Prior to this, the base station may perform a random access procedure with the terminal, establish a connection, and then transmit a request for capability information to the terminal. According to one embodiment, the capability information includes information regarding uplink transmission, and the information regarding uplink transmission may include information indicating whether OCC application to NTN data symbols is possible.

[0199] In step S1803, the base station transmits configuration information related to the OCC. The configuration information related to the OCC may include at least one of information required for OCC application, information about an uplink channel to which the OCC is applied, and information about scheduling of the uplink channel to which the OCC is applied. In addition, the information required for OCC application may include at least one of information about conditions for OCC application, information about the type of OCC applied to the PUSCH, information about the length of the OCC applied to the PUSCH, or information about the group size of the OCC. In addition, according to one embodiment, the information required for OCC application may include information about OCC weights associated with antenna port numbers.

[0200] In step S1805, the base station receives a PUSCH transmitted using the OCC weight associated with the DMRS port number. At this time, the base station may receive PUSCHs transmitted using different OCC weights from multiple terminals. Prior to this, the base station may transmit configuration information or control information for scheduling the PUSCH. Furthermore, after receiving the PUSCH, the base station may combine repeatedly transmitted PUSCHs using the OCC weights and decode the PUSCH.

[0201]

[0202] According to the various embodiments described above, OCC can be applied using OCC weights associated with antenna ports. The procedures (e.g., pre-procedure and PUSCH transmission) according to one embodiment of the present disclosure can be summarized as follows.

[0203] [Action 1-1]: Reporting PUSCH_OCC_Capability information of the terminal (Direction: From the terminal to the base station)

[0204] [Action 1-2]: Transmit PUSCH_OCC_configuration (Direction: Base Station to Terminal)

[0205] [Operation 1-3]: Setting the OCC weight vector by DMRS port number (Direction: Base Station to Terminal)

[0206] [Action 2]: Indicate the DMRS port number of each terminal's PUSCH.

[0207] [Operation 3]: For terminals capable of applying PUSCH OCC, the OCC weight vector linked to the DMRS port number is applied before PUSCH transmission. For terminals that cannot apply PUSCH OCC, only repeated transmission is performed without applying OCC.

[0208] [Operation 1-1] PUSCH_OCC_Capability indicates whether the UE can apply OCC to data symbols when transmitting PUSCH. For example, existing Rel-18 UEs are expected to be unable to apply PUSCH OCC, and the base station can obtain this information for scheduling purposes. As another example, even among Rel-19 UEs, there may be UEs with limited PUSCH OCC application, and the base station can obtain this information for scheduling purposes.

[0209] [Operation 1-2] is the step for setting the OCC configuration to be applied by the terminal. Here, the OCC configuration may include all or some of the following information items. Depending on various embodiments, only all or some of the following information items may be used. Alternatively, at least some of the following information items may be omitted from signaling due to lack of instruction.

[0210] Information Item Description OCC Type Select which type of OCC to apply among intra-symbol OCC, inter-symbol OCC, and inter-slot OCC. For example, intra-symbol OCC can be indicated to the terminal. As another example, the method of applying both intra-symbol OCC and inter-symbol OCC can be indicated to the terminal. OCC Length Indicates the OCC length for the OCC type. For example, when applying both intra-symbol OCC and inter-symbol OCC, the OCC length for each can be specified (e.g. intra-symbol OCC length=2, inter-symbol OCC length=2, e.g. intra-symbol OCC length=4, inter-symbol OCC length=2). OCC Group Size Indicates the OCC group size when applying inter-symbol OCC and / or inter-slot OCC.

[0211] [Operation 1-3] is a step of configuring an OCC weight vector mapped according to a DMRS port number. According to various embodiments, the base station may indicate the OCC weight vector to the terminal through signaling. Alternatively, the base station and the terminal may specify the OCC weight vector based on a mapping rule defined in a specification document. According to one embodiment, the OCC weight vectors corresponding to the DMRS port numbers may be determined based on a predefined rule for the association between DMRS ports and OCC weights applied to the DMRS. For example, by modifying the predefined rule for the association between DMRS ports and OCC weights applied to the DMRS (e.g., splitting, combining, cyclically shifting, etc. of weight vectors), the association between the DMRS port number and the OCC weight vectors applied to the PUSCH may be determined.

[0212] [Example 1] Inter-slot OCC with OCC length = 4 DMRS port number Inter-symbol OCC weight vector w = [w0,w1,w2,w3] 0 or 4w = [+1,+1,+1,+1] 1 or 5w = [+1,-1,+1,-1] 2 or 6w = [+1,+1,-1,-1] 3 or 7w = [+1,-1,-1,+1]

[0213] [Example 2] Inter-slot OCC with OCC length = 2 DMRS port number Inter-slot OCC weight vector w = [w0,w1] 0,1,4,5 w = [+1,+1] 2,3,6,7 w = [+1,-1]

[0214] [Example 3] Intra-symbol OCC with length = 4 and inter-symbol OCC with length = 2 DMRS port number Intra-symbol OCC weight vector w = [w0, w1, w2, w3] Inter-symbol OCC weight vector v=[v0,v1]0w=[+1,+1,+1,+1]v=[+1,+1]1w=[+1,-1,+1,-1]v=[+1,+1]2w=[+1,+j,+1,-j]v=[+1,+1]3w=[+1,-j,+1,+j]v=[+ 1,+1]4w=[+1,+1,+1,+1]v=[+1,-1]5w=[+1,-1,+1,-1]v=[+1,-1]6w=[+1,+j,+1,-j]v=[+1,-1]7w=[+1,-j,+1,+j]v=[+1,-1]

[0215] [Example 3-1] Intra-symbol OCC with length=4 and inter-symbol OCC with length=2 DMRS port number OCC weight vector w=[w00,w01,w02,w03, w10,w11,w12,w13]0w=[+1,+1,+1,+1, +1,+1,+1,+1]1w=[+1,-1,+1,-1, +1,-1,+1,-1]2w=[+1,+j,+1,-j, +1,+j,+1,-j]3w=[+1,-j,+1,+j, +1,-j,+1,+j]4w=[+1,+1,+1,+1, -1,-1,-1,-1]5w=[+1,-1,+1,-1, -1,+1,-1,+1]6w=[+1,+j,+1,-j, -1,-j,-1,+j]7w=[+1,-j,+1,+j, -1,+j,-1,-j]

[0216] For example, in [Operation 1-3], the mapping rules illustrated in [Table 13] to [Table 16] can be applied. Example 1 shows OCC weight vectors for inter-symbol OCC with OCC length = 4 and DMRS port numbers mapped thereto. In this case, a terminal with a DMRS port number of 2 transmits PUSCH data symbols repeated four times after multiplying them by 1, j, -1, and -j. Example 2 shows a case of inter-slot OCC with OCC length = 2, and the terminal transmits PUSCH data symbols after multiplying them by w0 and w1 every two slots. Example 3 shows a case where both intra-symbol OCC and inter-symbol OCC are applied, and similarly to Examples 1 and 2, the intra-symbol OCC weight vector and the inter-symbol OCC weight vector are each multiplied as the weights of the intra-symbol OCC and the inter-symbol OCC according to the DMRS port number. In the case of Example 3, a table can be expressed in a format similar to Example 3-1. In Example 3-1, the weight w pq In Example 3, the OCC weights w q and v p OCC weights defined to replace two multiplications with one multiplication.

[0217] According to various embodiments, [Operation 2] is a step of indicating information about the PUSCH DMRS port number to the terminal. [Operation 3] is a step of applying the OCC weight vector specified in [Operations 1-3] and transmitting the PUSCH. Terminals that cannot apply OCC can only perform repeated transmissions without applying OCC.

[0218] Depending on various embodiments, the order of [Operation 1-1], [Operation 1-2], and [Operation 1-3] may vary. For example, [Operation 1-2] may be performed first, and then [Operation 1-1] and [Operation 1-3] may be performed.

[0219] According to various embodiments, the configuration in [Operation 1-2] and / or [Operation 1-3] may be performed via SIB or indicated via MAC-CE and / or RRC signaling.

[0220] According to various embodiments, [Operation 1-2] and / or [Operation 1-3] may be configured multiple times. For example, after initial configuration of OCC type and / or OCC weight vector by DMRS port number is performed via SIB, the corresponding configurations may be updated via additional instructions.

[0221] According to various embodiments, [Operation 1-2] and / or [Operation 1-3] may be omitted. For example, instructions for some or all of the information indicated to the terminal in [Operation 1-2] and [Operation 1-3] (e.g., OCC type, DMRS port number and OCC weight vector mapping relationship, OCC length, OCC group size, etc.) may be omitted.

[0222] According to various embodiments, for terminals that cannot apply OCC (e.g., terminals that do not apply Rel-19), some of the operations after [Operation 1-1] described above may be omitted. For example, since OCC cannot be applied to data symbols, the instruction regarding OCC weight may be omitted. Terminals that cannot apply OCC can perform repeated transmissions, etc. without applying OCC. Such operations can be understood as applying an OCC weight of +1 to each repeated block.

[0223] According to various embodiments, the method for indicating OCC weights can be applied to general repetitions (e.g., intra-symbol repetition, inter-symbol repetition, inter-slot repetition). Furthermore, the aforementioned method for indicating OCC weights can also be applied to repetitions applied with TBoMS (e.g., intra-symbol repetition, inter-symbol repetition).

[0224] According to various embodiments, the information indicated by the base station in [Operation 1-2] and [Operation 1-3] may be indicated via DCI.

[0225] According to various embodiments, existing specifications may be reused as indicators (e.g., OCC indices) indicating OCC weights. For example, Table 6.3.2.5A-1 and / or Table 6.3.2.5A-2 of the existing specification document TS 38.211 may be used to indicate OCC weights between symbols and / or between slots. Additionally, Table 6.3.2.6.3-1 and / or Table 6.3.2.6.3-2, which are comb-like structures of PUCCH format 4 of the existing specification document TS 38.211, may be used to indicate OCC weights within symbols.

[0226] As in the embodiments described above, a DMRS port may be associated with an OCC weight used in the corresponding PUSCH. Accordingly, the OCC weight can be understood as being dynamically indicated using DCI. Furthermore, a DMRS port may be associated with an OCC length. The OCC length may be indicated by higher layer signaling or based on the association with the DMRS port. That is, the sequence and / or length of the OCC may be explicitly indicated in the DCI using the association with the DMRS port. In this case, the DMRS port number and the OCC length and sequence may be defined as shown in [Table 17] below.

[0227] DMRS Port Number (Signaling)Actual DMRS Port Number (Actual Applied Port Number)OCC LengthOCC Sequence Index002012212040314142425343601(OCC disabled)0… … … …

[0228] In [Table 17], the DMRS port number refers to the value signaled via DCI, and the actual DMRS port number refers to the DMRS port number used according to the corresponding value signaled. In other words, the signaled port number can be reused after being reinterpreted. However, whether or not to reinterpret the DMRS port number can be configured through upper-layer signaling.

[0229]

[0230] The methods according to the present disclosure may be implemented in the form of program instructions that can be executed by various computer means and recorded on a computer-readable medium. The computer-readable medium may include program instructions, data files, data structures, etc., either singly or in combination. The program instructions recorded on the computer-readable medium may be those specifically designed and configured for the present disclosure or may be known and available to those skilled in the computer software art.

[0231] Examples of computer-readable media include hardware devices specifically configured to store and execute program instructions, such as ROM, RAM, and flash memory. Examples of program instructions include machine language code, such as that produced by a compiler, as well as high-level language code that can be executed by a computer using an interpreter, etc.

[0232] While some aspects of the present disclosure have been described in the context of a device, they may also represent a description of a corresponding method, wherein a block or device corresponds to a method step or a feature of a method step. Similarly, aspects described in the context of a method may also be described as a corresponding block or item or a feature of a corresponding device. Some or all of the method steps may be performed by (or using) a hardware device, such as, for example, a microprocessor, a programmable computer, or an electronic circuit. In some embodiments, at least one or more of the most significant method steps may be performed by such a device.

[0233] A programmable logic device (e.g., a field-programmable gate array) may be used to perform some or all of the functions of the methods described in this disclosure. The field-programmable gate array may operate in conjunction with a microprocessor to perform one of the methods described in this disclosure. In general, the methods are preferably performed by some hardware device.

[0234] Although the present disclosure has been described with reference to the above embodiments, it will be understood by those skilled in the art that various modifications and changes can be made to the present disclosure without departing from the spirit and scope of the present disclosure as set forth in the claims below.

Claims

1. In a method of operating a terminal in a wireless communication system, Transmitting capability information for uplink transmission; Receiving configuration information for an orthogonal covering code (OCC) applied to a PUSCH (physical uplink shared channel); Checking information about the DMRS (demodulation reference signal) port number corresponding to the above PUSCH; and A method comprising transmitting the PUSCH using an OCC weight associated with the DMRS port number.

2. In claim 1, A method further comprising verifying an association between DMRS ports and the OCC weights based on the above configuration information.

3. In claim 1, A method in which the OCC weight associated with the above DMRS port number is determined based on predefined rules for the association between DMRS ports and OCC weights.

4. In claim 1, A method in which the above capability information includes information indicating whether the terminal can apply OCC to the PUSCH.

5. In claim 4, A method in which information indicating whether OCC can be applied to the PUSCH includes at least one of information about a release supported by the terminal or information indicating that application of the OCC is restricted.

6. In claim 1, A method wherein the configuration information includes at least one of: a type of OCC applied to the PUSCH, information on a length of the OCC applied to the PUSCH, or information on a group size of the OCC.

7. In claim 1, The above configuration information is received via system information, RRC signaling, or MAC-CE.

8. In claim 1, A method further comprising receiving other configuration information for updating associations between the DMRS ports and the weight vectors for the OCC.

9. In claim 1, A method in which the OCC weight associated with the above DMRS port number is determined based on predefined rules for the association between DMRS ports and OCC weights applied to the DMRS.

10. In claim 1, A method in which the OCC applied to the above PUSCH includes an inter slot OCC.

11. In a method of operating a NTN (non-terrestrial network) base station in a wireless communication system, Receiving capability information for uplink transmission; Transmitting configuration information for an orthogonal covering code (OCC) applied to a PUSCH (physical uplink shared channel); A method comprising receiving the PUSCH transmitted using an OCC weight associated with a DMRS (demodulation reference signal) port number corresponding to the PUSCH.

12. In claim 11, A method in which the above capability information includes information indicating whether the terminal can apply OCC to the PUSCH.

13. In claim 12, A method in which information indicating whether OCC can be applied to the PUSCH includes at least one of information about a release supported by the terminal or information indicating that application of the OCC is restricted.

14. In claim 11, A method wherein the configuration information includes at least one of: a type of OCC applied to the PUSCH, information on a length of the OCC applied to the PUSCH, or information on a group size of the OCC.

15. In claim 11, The above configuration information is received via system information, RRC signaling, or MAC-CE.

16. In claim 11, A method further comprising transmitting other configuration information for updating associations between the DMRS ports and the weight vectors for the OCC.

17. In claim 11, A method wherein the OCC weight associated with the above DMRS port number is determined based on predefined rules for the association between DMRS ports and OCC weights applied to the DMRS.

18. In claim 11, A method in which the OCC applied to the above PUSCH includes an inter slot OCC.

19. In a wireless communication system, at a terminal, At least one transmitter / receiver; at least one processor; and At least one memory operably connected to said at least one processor and storing instructions that, when executed by said processor, control said terminal to perform operations; The above actions are, Transmitting capability information for uplink transmission; Receiving configuration information for an orthogonal covering code (OCC) applied to a PUSCH (physical uplink shared channel); Checking information about the DMRS (demodulation reference signal) port number corresponding to the above PUSCH; and A terminal comprising transmitting the PUSCH using an OCC weight associated with the DMRS port number.

20. In a non-terrestrial network (NTN) base station in a wireless communication system, At least one transmitter / receiver; at least one processor; and At least one memory operably connected to said at least one processor and storing instructions that, when executed by said processor, control said terminal to perform operations; The above actions are, Receiving capability information for uplink transmission; Transmitting configuration information for an orthogonal covering code (OCC) applied to a PUSCH (physical uplink shared channel); An NTN base station comprising receiving the PUSCH transmitted using an OCC weight associated with a DMRS (demodulation reference signal) port number corresponding to the PUSCH.

Images