Device and communication method

Abstract

Provided is a device that has less complexity than a Narrow Band Internet of Things (NB-IoT) device and that comprises: a reception unit that receives downlink data from a network; and a control unit that generates a response signal indicating the success or failure of the decoding of the downlink data.

Description

Device and communication method

[0001] The present disclosure relates to devices and communication methods.

[0002] For NR (New Radio) (also called "5G"), the successor system to LTE (Long Term Evolution), technologies are being considered that meet the requirements of a large-capacity system, high-speed data transmission speed, low latency, simultaneous connection of a large number of terminals, low cost, low power consumption, etc. (see, for example, Non-Patent Document 1).

[0003] Furthermore, in Release 18 (Rel-18) of 3GPP (registered trademark), ambient IoT (A-IoT: Ambient Internet of Things) is being considered (see, for example, Non-Patent Document 2). Ambient IoT targets devices with extremely simple configurations for low-end IoT applications that operate with extremely low power consumption.

[0004] Furthermore, towards 3GPP Rel-19 or Rel-20 and beyond for the extension of ambient IoT, ARQ procedures that may include hybrid automatic repeat request (HARQ) may be discussed as a study item for ambient IoT (see, for example, Non-Patent Documents 3 and 4).

[0005] 3GPP TS 38.300 V17.3.0 (2022-12)”Revised SID on Ambient IoT”, RP-232404, 3GPP TSG RAN Meeting #101, September 2023 “Summary for RAN Rel-19 Package: RAN1 / 2 / 3-led”, RP-232745, 3GPP RAN #102, December 2023 “Study on solutions for Ambient IoT (Internet of Things) in NR”, RP-234058, 3GPP TSG RAN Meeting #102, December 2023 3GPP TS 36.211 V16.8.0 (2023-09)3GPP TR 38.848 V1.0.0 (2023-09)

[0006] In current wireless communication systems, low-end Narrow Band IoT (NB-IoT) devices are defined. NB-IoT is described in, for example, Section 10 of Non-Patent Document 5.

[0007] Ambient IoT devices are even lower end than NB-IoT devices, and more complex ARQ procedures may complicate the operation of such devices, so it is necessary to define appropriate ARQ operations.

[0008] One aspect of the present disclosure provides a device and a communication method that can appropriately perform ARQ operations.

[0009] A device according to one aspect of the present disclosure is a device of lower complexity than an NB-IoT (Narrow Band Internet of Things) device, and includes a receiving unit that receives downlink data from a network, and a control unit that generates a response signal indicating success or failure in decoding the downlink data.

[0010] 1 is a diagram illustrating an example of a wireless communication system according to an embodiment of the present disclosure. A diagram illustrating Topology 1. A diagram illustrating Topology 2. A diagram illustrating Topology 3 in DL assistance. A diagram illustrating Topology 3 in UL assistance. A diagram illustrating Topology 4. A diagram illustrating an example of interaction between a network and an A-IoT device according to an embodiment of the present disclosure. A diagram illustrating an example of interaction between a network and an A-IoT device according to an embodiment of the present disclosure. A diagram illustrating an example of DL data reception and ACK / NACK feedback transmission according to an embodiment of the present disclosure. A diagram illustrating an example of DL data reception and ACK / NACK feedback transmission according to an embodiment of the present disclosure. A diagram illustrating an example of DL data reception and ACK / NACK feedback transmission according to an embodiment of the present disclosure. A diagram illustrating an example of device operation according to an embodiment of the present disclosure. A diagram illustrating an example of interaction between a network and an A-IoT device according to an embodiment of the present disclosure. A diagram illustrating an example of interaction between a network and an A-IoT device according to an embodiment of the present disclosure. A diagram illustrating an example of UL data transmission and ACK / NACK feedback reception according to an embodiment of the present disclosure. FIG. 1 is a diagram illustrating an example of UL data transmission and reception of ACK / NACK feedback according to an embodiment of the present disclosure. FIG. 2 is a diagram illustrating an example of device operation according to an embodiment of the present disclosure. FIG. 3 is a block diagram illustrating an example of a configuration of a base station according to an embodiment of the present disclosure. FIG. 4 is a block diagram illustrating an example of a configuration of a device according to an embodiment of the present disclosure. FIG. 5 is a diagram illustrating an example of a hardware configuration of a base station and a device according to an embodiment of the present disclosure. FIG. 6 is a diagram illustrating an example of a configuration of a vehicle according to an embodiment of the present disclosure.

[0011] Hereinafter, an embodiment according to one aspect of the present disclosure will be described with reference to the drawings. Note that the embodiment described below is an example, and the embodiment to which the present disclosure is applied is not limited to the following embodiment.

[0012] In the operation of the wireless communication system according to the embodiment of the present disclosure, existing technology is used as appropriate. The existing technology is, for example, the existing LTE or NR, but is not limited to the existing LTE or NR. In addition, the term "LTE" used in this specification has a broad meaning including LTE-Advanced and systems subsequent to LTE-Advanced, unless otherwise specified.

[0013] In addition, in the embodiments of the present disclosure described below, terms such as SS (synchronization signal), PSS (primary SS), SSS (secondary SS), PBCH (physical broadcast channel), PRACH (physical random access channel), PDCCH (physical downlink control channel), PDSCH (physical downlink shared channel), PUCCH (physical uplink control channel), and PUSCH (physical uplink shared channel) used in existing LTE are used. This is for convenience of description, and similar signals, functions, etc. may be referred to by other names. Furthermore, the above-mentioned terms in NR correspond to NR-SS, NR-PSS, NR-SSS, NR-PBCH, NR-PRACH, etc. However, even signals used in NR are not necessarily designated as "NR-".

[0014] Furthermore, in the embodiments of the present disclosure, the duplex method may be a time division duplex (TDD) method, a frequency division duplex (FDD) method, or another method (for example, flexible duplex, etc.).

[0015] Furthermore, in the embodiments of the present disclosure, "configuring" radio parameters and the like may mean that predetermined values ​​are pre-configured, or that radio parameters notified from a base station, a device, and the like are set.

[0016] (Embodiment) <Wireless Communication System> Fig. 1 is a diagram illustrating an example of a wireless communication system according to an embodiment of the present disclosure. As illustrated in Fig. 1, the wireless communication system 1 includes a base station 10 and a device 20. While Fig. 1 illustrates one base station 10 and one device 20, this is merely an example, and multiple base stations and devices may exist. The device 20 may be considered a form of terminal (UE: User Equipment) and may be an ambient IoT device, which is a device with lower complexity than an NB-IoT device. The ambient IoT device may also be referred to as an ambient IoT terminal, ambient IoT UE, or the like.

[0017] The base station 10 is a communication device that provides one or more cells and performs wireless communication with the device 20. The physical resources of a wireless signal are defined in the time domain and the frequency domain. The time domain may be defined by the number of Orthogonal Frequency Division Multiplexing (OFDM) symbols. The frequency domain may be defined by the number of subcarriers or the number of resource blocks.

[0018] The base station 10 transmits DL (Downlink) signals such as control information, setting information, and data to the device 20. The base station 10 receives UL signals such as control information, information related to the processing capability of the device 20 (capability (information) or device capability (information); for example, capability, device capability, A-IoT capability, A-IoT device capability, etc.), and data from the device 20 via UP (Uplink).

[0019] Channels used for transmitting DL signals include, for example, data channels and control channels. For example, the data channel may include a physical downlink shared channel (PDSCH), and the control channel may include a physical downlink control channel (PDCCH). For example, the base station 10 transmits control information to the device 20 using the PDCCH, and transmits DL data signals using the PDSCH. Note that the PDSCH is an example of a downlink shared channel or a data channel, and the PDCCH is an example of a downlink control channel. The PDCCH may be interpreted as downlink control information (DCI), control information, etc. transmitted in the PDCCH.

[0020] As will be described later, the wireless communication system may include intermediate nodes, assisting nodes, and / or terminals (UEs) (see <Device Types and Topologies> below). Note that, hereinafter, "and / or" may be written simply as " / ".

[0021] The device 20 is a communication device equipped with wireless communication capabilities, and as described above, may be an ambient IoT device (e.g., a sensor, etc.).

[0022] The device 20 receives DL signals such as control signals, setting information, and data from the base station 10 via DL, and transmits UL signals such as control signals, capability information of the device 20, and data to the base station 10 via UL.

[0023] Channels used for transmitting UL signals include, for example, data channels and control channels. For example, the data channel may include a physical uplink shared channel (PUSCH), and the control channel may include a physical uplink control channel (PUCCH). For example, the device 20 transmits control information using the PUCCH and transmits UL data signals using the PUSCH. Note that the PUSCH is an example of an uplink shared channel or a data channel, and the PUCCH is an example of an uplink control channel. Note that the PUSCH or the PUCCH may be interpreted as uplink control information (UCI), control information, etc. transmitted in the PUSCH or the PUCCH.

[0024] <Ambient IoT> Rel-18 approved the study of ambient IoT, which is even lower-end than the existing NB-IoT (see, for example, Section 10 of Non-Patent Document 5) (see, for example, Non-Patent Document 2). Ambient IoT targets ultra-low power consumption and ultra-low complexity devices.

[0025] In Ambient IoT, for example, the following deployment scenarios and characteristics may be considered for relevant use cases: Indoor or outdoor environment Base station type, e.g., macro / micro / pico cell-based deployment Connectivity topology, e.g., which nodes communicate with Ambient IoT devices, such as base stations, terminals (UE), relays and repeaters Duplexing method, TDD or FDD, licensed or unlicensed frequency band Coexistence with UE and network equipment in frequency bands for existing 3GPP technologies Assumptions of traffic originating from / terminating to devices

[0026] Based on the above deployment scenarios and characteristics, for example, the following RAN design targets can be formulated: Power consumption Complexity Coverage Data rate Positioning accuracy

[0027] Based on deployment scenarios appropriate for the relevant use cases, compare and evaluate the feasibility of meeting design targets and identify supporting features.

[0028] <Device Types and Topologies> Based on the results of the study items, TR 38.848 (Non-Patent Document 6) was approved. TR 38.848 considers the following categories of ambient IoT devices: Device A: Device A does not have power (energy) storage, does not have independent signal generation or signal amplification functions, and performs backscattering transmission. Device B: Device B has power storage, does not have independent signal generation functions, and performs backscattering transmission. Device B uses the stored power to amplify reflected signals. Device C: Device C has power storage, independent signal generation functions, and has an active RF (radio frequency) component for transmission.

[0029] The complexity of device A is assumed to be about the same as RFID (Frequency Frequency Identification).

[0030] TR 38.848 defines the following topologies 1 to 4 in an ambient IoT network.

[0031] Fig. 2 is a diagram illustrating Topology 1. As shown in Fig. 2, Topology 1 is a configuration in which a base station (BS) and an ambient IoT device communicate with each other. The ambient IoT device directly communicates with the base station in a two-way manner.

[0032] 3 is a diagram illustrating Topology 2. As shown in FIG. 3, Topology 2 is a configuration in which a base station and an ambient IoT device communicate with each other via an intermediate node. The ambient IoT device performs bidirectional communication with the intermediate node located between the base station and the ambient IoT device. The intermediate node may be, for example, a relay, an integrated access and backhaul (IAB) node, a UE, a repeater, or the like.

[0033] 4 is a diagram illustrating Topology 3 in DL assistance. As shown in FIG. 4, Topology 3 is a configuration including communication between a base station and an assisting node, communication between the assisting node and an ambient IoT device, and communication between the ambient IoT device and a base station.

[0034] The support node supports DL communication. For example, as shown in Figure 4, the support node receives DL signals from the base station and transmits the received DL signals to the ambient IoT device. For UL communication, the ambient IoT device transmits UL signals directly to the base station.

[0035] Fig. 5 is a diagram illustrating Topology 3 in UL support. As shown in Fig. 5, Topology 3 is a configuration including communication between a base station and a support node, communication between a support node and an ambient IoT device, and communication between the ambient IoT device and a base station.

[0036] The support node supports UL communication. For example, as shown in Figure 5, the support node receives UL signals from the ambient IoT device and transmits the received UL signals to the base station. For DL ​​communication, the ambient IoT device receives DL signals directly from the base station.

[0037] The supporting nodes shown in FIGS. 4 and 5 may be, for example, relays, IAB nodes, UEs, repeaters, etc.

[0038] 6 is a diagram illustrating Topology 4. Topology 4 is a configuration in which a UE and an ambient IoT device communicate with each other. The ambient IoT device performs bidirectional communication with the UE. Communication related to Topology 4 may be considered as side link (SL) communication.

[0039] In the above topologies 1 to 4, the ambient IoT device may be provided with a carrier wave from another node inside or outside the topology (see Section 4.2.1 of Non-Patent Document 6).

[0040] The wireless communication system 1 (wireless communication network) may include a base station, a support node, an intermediate node, and / or a terminal (UE of Topology 4) in addition to the device 20. In this specification, the base station, the support node, the intermediate node, and the terminal may be read as a network or a (network) node. Also, an A-IoT device may be simply referred to as A-IoT.

[0041] As mentioned above, (H)ARQ may be discussed as a physical layer procedure for 3GPP Rel-19 or Rel-20 and beyond, so the current HARQ operation will be described below.

[0042] <HARQ> Below, we will explain HARQ operations in current wireless communication systems (HARQ operations in NB-IoT / NR).

[0043] In both DL and UL data transmission, the Medium Access Control (MAC) entity of a terminal, including an NB-IoT device, is capable of maintaining multiple simultaneous HARQ processes.

[0044] [DL] The HARQ operation for DL ​​will now be described.

[0045] In DL, the DL scheduling DCI includes a HARQ process index and an NDI (New Data Indicator). The HARQ process index may also be referred to as a HARQ process number, a HARQ process ID, a HARQ process identifier, HARQ process identification information, etc., and represents information for identifying a HARQ process. The NDI indicates whether the transmission data is new data (whether due to new transmission) or retransmission data (whether due to retransmission).

[0046] When a DL transmission occurs for a certain HARQ process, if the NDI is toggled compared to the value of the previous transmission (if it is different from the value of the previous transmission), the DL transmission is considered a new transmission. In this case, the MAC entity attempts to decode the received data. On the other hand, if the NDI is not toggled compared to the value of the previous transmission (if it is the same as the value of the previous transmission), the DL transmission is considered a retransmission. In this case, the MAC entity combines the received data with the data currently stored in the soft buffer and attempts to decode the combined data.

[0047] If the data is not successfully decoded, it is stored in a soft buffer.

[0048] Then, depending on whether the data is successfully decoded, HARQ acknowledgement (ACK) / negative acknowledgement (NACK) feedback is reported to a network (e.g., a base station). More specifically, if a transport block (TB) is successfully decoded, the terminal reports an ACK, and if the TB is not successfully decoded, the terminal reports a NACK. The HARQ ACK / NACK feedback may also be referred to as an ACK / NACK, HARQ feedback, HARQ response, HARQ ACK / NACK response, HARQ information, HARQ ACK / NACK information, HARQ control information, HARQ ACK / NACK control information, a (delivery) confirmation signal or (acknowledgement) response signal for data, a (delivery) confirmation signal, (acknowledgement) response signal, or (control) information in response to success or failure of data decoding, a (delivery) confirmation signal, (acknowledgement) response signal, or (control) information indicating success or failure of data decoding, etc.

[0049] [UL] Next, the HARQ operation for the UL will be described.

[0050] In the UL, the UL scheduling DCI includes a HARQ process index and an NDI.

[0051] When an UL scheduling grant is received, for a certain HARQ process, if the NDI has been toggled compared to the value of the previous transmission, then if a MAC Protocol Data Unit (PDU) to be transmitted is obtained (i.e., there is new data to be transmitted), a new transmission is triggered and the MAC PDU is stored in the HARQ buffer, while if no MAC PDU is obtained (i.e., there is no new data to be transmitted), the HARQ buffer is flushed. On the other hand, if the NDI has not been toggled compared to the value of the previous transmission, a retransmission is triggered.

[0052] [Reporting HARQ ACK / NACK Feedback for DL ​​Reception from UE to Network] Time and frequency resources for HARQ ACK / NACK feedback are provided by the network. Hereinafter, time resources and frequency resources may be read as time domain resources and frequency domain resources, respectively.

[0053] In NR, HARQ ACK / NACK feedback is transmitted on the PUCCH. The slot offset between the PDSCH and the HARQ ACK / NACK feedback is provided by the network as information indicating the time resource, and the starting PRB (Physical Resource Block) and number of PRBs of the PUCCH are provided by the network as information indicating the frequency resource. The PDSCH processing time and the minimum (shortest) time gap between the PDSCH and the HARQ ACK / NACK feedback are defined in the specifications. The terminal provides valid HARQ ACK / NACK feedback for PDSCH reception only if the PUCCH carrying the HARQ ACK / NACK feedback starts after the required minimum time gap from the end of the PDSCH.

[0054] On the other hand, in NB-IoT, HARQ ACK / NACK feedback is transmitted on a narrowband physical uplink shared channel (NPUSCH). The slot offset between the narrowband physical downlink shared channel (NPDSCH) and the HARQ ACK / NACK feedback is provided by the network as information indicating the time resource, and the allocated subcarriers for the HARQ ACK / NACK feedback are provided by the network as information indicating the frequency resource.

[0055] <Analysis> Regarding the HARQ operation of A-IoT, the HARQ operation of NB-IoT / NR described above can be a starting point. On the other hand, since A-IoT devices are expected to have a very simple configuration, the following points (1) to (4) can be taken into consideration.

[0056] (1) Whether an A-IoT device can have multiple simultaneous HARQ processes or only one HARQ process

[0057] (2) Whether the A-IoT device supports a soft buffer for DL ​​data decoding. For example, if the A-IoT device does not have a soft buffer, each DL transmission is considered a new transmission. Therefore, the A-IoT device will simply report ACK / NACK to the network to let the network know whether the DL data has been successfully decoded.

[0058] (3) Time and / or frequency resources for ACK / NACK feedback

[0059] (4) Whether the A-IoT device supports a buffer for UL. For example, a buffer is required to support retransmission of UL data.

[0060] However, at present, the control and operation of (H)ARQ in A-IoT has not been fully studied. Therefore, the following describes a proposal for appropriately performing ARQ operation.

[0061] Specifically, this proposal includes Proposal 1, which includes the following Proposal 1-1, Proposal 1-2, and Proposal 1-3, and Proposal 2, which includes the following Proposal 2-1, Proposal 2-2, and Proposal 2-3. (Proposal 1: Proposal related to DL reception of A-IoT) Proposal 1-1: Proposal related to whether or not multiple simultaneous HARQ processes are supported Proposal 1-2: Proposal related to whether or not soft buffers are supported Proposal 1-3: Proposal related to reporting ACK / NACK for DL ​​reception (DL data) (Proposal 2: Proposal related to UL transmission of A-IoT) Proposal 2-1: Proposal related to whether or not multiple simultaneous HARQ processes are supported Proposal 2-2: Proposal related to reporting ACK / NACK for UL reception (UL data) Proposal 2-3: Proposal related to receiving ACK / NACK for UL reception (UL data)

[0062] It should be noted that some or all of the proposals described below may be applied to all A-IoT device types (e.g., all of the above-mentioned devices A, B, and C), or may be applied to some A-IoT device types (e.g., only certain A-IoT device types).

[0063] Also, different options in the proposals described below may apply to different A-IoT device types.

[0064] Furthermore, some or all of the proposals described below may be applied to all topologies (e.g., all of the above-mentioned topologies 1, 2, 3, and 4), or may be applied to only some topologies (e.g., only specific topologies).

[0065] Also, different options in some or all of the proposals described below may be applied to different topologies. For example, in the proposals described below, according to Topologies 1, 2, 3, and 4, information from the network to the A-IoT device may be transmitted from a base station (BS) / intermediate node / support node / terminal (UE) to the A-IoT device, and information from the A-IoT device to the network may be transmitted from the A-IoT device to a base station (BS) / intermediate node / support node / terminal (UE).

[0066] Also, with regard to the device capabilities described below, different A-IoT device types may have different device capabilities.

[0067] Furthermore, some or all of the suggestions described below may only apply if the corresponding capabilities are supported by the A-IoT device and / or if the corresponding functionality is enabled by the network.

[0068] Furthermore, the items explained in Proposal 1-1, Proposal 1-2, Proposal 1-3, Proposal 2-1, Proposal 2-2, and Proposal 2-3 may be combined as appropriate as long as no contradictions arise.

[0069] In the following, the term "provision" may be read as "notification."

[0070] In addition, in the following, the expression "report" may be read as the expression "send."

[0071] <Proposal 1-1> In the following, with regard to the above-mentioned viewpoint (1), a proposal (Proposal 1-1) related to whether or not an A-IoT device supports multiple simultaneous HARQ processes will be described.

[0072] The A-IoT device may generate "ACK" feedback (or simply "ACK") when it correctly, appropriately, normally, or successfully decodes DL data from the network, or when it successfully decodes DL data from the network. The A-IoT device may also generate "NACK" feedback (or simply "NACK") when it does not correctly, appropriately, normally, or successfully decode DL data from the network, or when it does not successfully or fails to decode DL data from the network.

[0073] The A-IoT device may report the generated ACK / NACK feedback to the network. For reporting the ACK / NACK feedback, for example, a 1-bit field for ACK / NACK feedback may exist. For example, a bit value "0" in the field may represent "NACK", and a bit value "1" in the field may represent "ACK". Alternatively, the mapping may be reversed. That is, a bit value "0" in the field may represent "ACK", and a bit value "1" in the field may represent "NACK".

[0074] Here, it may be necessary to vary the HARQ operation depending on whether multiple parallel, concurrent, or simultaneous HARQ processes (hereinafter, simultaneous HARQ processes) are supported, i.e., whether parallel, concurrent, or simultaneous DL data (processing / reception) is supported. In other words, an A-IoT device may support multiple simultaneous HARQ processes, or may not support multiple simultaneous HARQ processes (support only a single HARQ process (single DL data processing)), and it may be necessary to vary the HARQ operation depending on whether this support is present or absent.

[0075] [Option 1] Hereinafter, as option 1, a case where an A-IoT device supports multiple simultaneous HARQ processes will be described.

[0076] As described above, an A-IoT device may support or maintain multiple (e.g., X) simultaneous HARQ processes (in other words, may process multiple (e.g., X) DL data receptions in parallel, in parallel, or simultaneously), similar to an NB-IoT / NR. The number of simultaneous HARQ processes that an A-IoT device can support or maintain / the number of simultaneous DL data (processing / reception) that an A-IoT device can process may be defined in a specification or may be reported to the network by the A-IoT device as a device capability. The number of simultaneous HARQ processes / the number of simultaneous DL data (processing / reception) may differ depending on the A-IoT device type (in other words, different numbers of simultaneous HARQ processes / numbers of simultaneous DL data (processing / reception) may be supported by different A-IoT device types). For example, the above-mentioned device A may support only one HARQ process, while the above-mentioned device B and device C may support multiple HARQ processes.

[0077] After receiving DL data #i of HARQ process #i (HARQ process number i), the A-IoT device may receive other DL data #j of a HARQ process #j different from the HARQ process #i before transmitting an ACK / NACK for the DL data #i of the HARQ process #i. In other words, the A-IoT device may transmit an ACK / NACK for the DL data #i of the HARQ process #i after receiving DL data #i of the HARQ process #i and other DL data #j of a HARQ process #j different from the HARQ process #i.

[0078] In addition, the A-IoT device may transmit a single ACK / NACK feedback (ACK / NACK bundling) that combines ACK / NACK feedback for multiple received DL data, or may transmit them all together using a single resource.

[0079] The A-IoT device may transmit one ACK / NACK to the network in a single UL transmission, or may transmit multiple ACK / NACKs (e.g., an ACK / NACK for DL ​​data #i of HARQ process #i and an ACK / NACK for DL ​​data #j of HARQ process #j, etc.). Note that the number of ACK / NACKs that the A-IoT device can transmit in a single UL transmission may be defined in the specification or may be reported to the network by the A-IoT device as device capability.

[0080] One or more of the following constraints may be defined (in the specification):

[0081] For example, the restriction may be that when an A-IoT device receives DL data #i of HARQ process #i and then receives DL data #j of HARQ process #j, it will assume that it will transmit DL data #j of HARQ process #j after transmitting an ACK / NACK for the DL data #i of HARQ process #i, or it will transmit DL data #j.

[0082] As another example, the restriction may be that, for the same HARQ process, the A-IoT device does not expect or does not receive another DL data (a new transmission of new DL data or a retransmission of previous DL data) before sending an ACK / NACK for the previous DL data. In other words, the restriction may be that, for the same HARQ process, the A-IoT device expects or receives another DL data after sending an ACK / NACK for the previous DL data.

[0083] 7 is a diagram showing an example of an exchange between a base station / support node / intermediate node and an A-IoT device according to Option 1. As shown in FIG. 7, a network such as a base station sequentially transmits DL data #1 of HARQ process #1, DL data #2 of HARQ process #2, ..., DL data #X of HARQ process #X to the A-IoT device. Also, as shown in FIG. 7, the A-IoT device sequentially transmits ACK / NACK for DL ​​data #1, ACK / NACK for DL ​​data #2, ..., ACK / NACK for DL ​​data #X to the network such as a base station depending on whether decoding of these DL data is successful or unsuccessful.

[0084] Option 1 allows the HARQ operation of A-IoT devices to be similar to that of current wireless communication systems, thereby minimizing the impact on specifications.

[0085] [Option 2] Hereinafter, as Option 2, a case where the A-IoT device does not support multiple simultaneous HARQ processes will be described.

[0086] An A-IoT device may support or have a single HARQ process (in other words, it may process a single DL data (reception) at a time, or it may process multiple DL data (receptions) in parallel, concurrently or not simultaneously).

[0087] One or more of the following constraints may be defined (in the specification):

[0088] For example, the restriction may be that the A-IoT device does not expect or does not receive another DL data (a new transmission of new DL data or a retransmission of previous DL data) before transmitting an ACK / NACK for the previous DL data. In other words, the restriction may be that the A-IoT device expects or receives another DL data after transmitting an ACK / NACK for the previous DL data.

[0089] As another example, the restriction may be that the A-IoT device does not expect or receive a new transmission of new DL data before sending an ACK for the previous DL data. In other words, the restriction may be that the A-IoT device expects or receives a new transmission of new DL data after sending an ACK for the previous DL data.

[0090] Fig. 8 is a diagram showing an example of interactions between a base station / support node / intermediate node and an A-IoT device according to Option 2. As shown in Fig. 8, when a network such as a base station transmits DL data to an A-IoT device, the A-IoT device transmits an ACK / NACK for the DL data to the network such as a base station depending on whether decoding of the DL data is successful or unsuccessful, and thereafter, similar operations are repeated.

[0091] Option 2 allows the HARQ operation of A-IoT devices to be adapted to simple configurations of A-IoT devices.

[0092] <Proposal 1-2> Next, with regard to the above-mentioned viewpoint (2), a proposal (Proposal 1-2) related to whether or not an A-IoT device supports a soft buffer will be described.

[0093] Depending on whether a soft buffer for DL ​​data decoding is supported or not, the HARQ operation may need to be different. In other words, an A-IoT device may or may not support a soft buffer, and depending on whether or not this support is present, the HARQ operation may need to be different.

[0094] [Alt. 1] Below, as Alt. 1, a case where an A-IoT device supports a soft buffer will be described.

[0095] As described above, A-IoT devices may support or maintain soft buffers, similar to NB-IoT / NR. For example, in the case of Option 1 in Proposal 1-1, the A-IoT device may maintain one soft buffer per HARQ process, and in the case of Option 2 in Proposal 1-1, the A-IoT device may maintain one soft buffer.

[0096] When the A-IoT device receives DL data from the network, the NDI may be provided from the network to the A-IoT device. The NDI may be provided in the DCI or together with the DL data (e.g., in the data channel). The NDI indicates whether the received DL data is from a new transmission or a retransmission.

[0097] If the DL data is due to a new transmission, the A-IoT device decodes the received DL data. On the other hand, if the DL data is due to a retransmission, the A-IoT device combines (synthesizes) the received DL data with the DL data currently stored or saved in a soft buffer (a corresponding soft buffer or one soft buffer among multiple soft buffers) and decodes the combined DL data.

[0098] If the A-IoT device does not correctly decode the received DL data, it stores or saves the received DL data in a soft buffer.

[0099] In the case of Option 1 in Proposal 1-1, when the A-IoT device receives DL data from the network, the HARQ process index may be provided to the A-IoT device from the network along with the NDI. The HARQ process index may be provided in the DCI or together with the DL data (e.g., in the data channel). The size of the HARQ process index field is related to the number of simultaneous HARQ processes (e.g., X) supported or maintained by the A-IoT device. For example, the size of the HARQ process index field may be 1 bit when X is 2, 2 bits when X is greater than 2 and less than or equal to 4, 3 bits when X is greater than 4 and less than or equal to 8, etc.

[0100] According to Alt. 1, the HARQ operation of A-IoT devices can be made similar to that of current wireless communication systems, thereby suppressing the impact on specifications.

[0101] [Alt. 2] Below, as Alt. 2, a case where an A-IoT device does not support a soft buffer will be described.

[0102] As mentioned above, the A-IoT device may not support or maintain a soft buffer. In this case, each DL data may be considered as a new transmission. Also, in this case, the HARQ process index and / or NDI need not be provided to the A-IoT device by the network.

[0103] This Alt. 2 may only be applied to Option 2 in Proposal 1-1, because A-IoT devices may not have buffers to support simultaneous DL data processing.

[0104] According to Alt. 2, the HARQ operation of an A-IoT device can be adapted to a simple configuration of the A-IoT device.

[0105] In addition, when NDI is provided (for example, in the case of Alt. 1), the NDI may be interpreted in the same way as in the current wireless communication system, or may be interpreted differently from the current wireless communication system, as follows.

[0106] Option 1: The interpretation of the NDI may be similar to or the same as that of NB-IoT / NR. Specifically, if the NDI is toggled compared to the value of the previous transmission (if it is different from the value of the previous transmission), the A-IoT device may consider the DL transmission to be a new transmission. On the other hand, if the NDI is not toggled compared to the value of the previous transmission (if it is the same as the value of the previous transmission), the A-IoT device may consider the DL transmission to be a retransmission. In Option 1, the A-IoT device needs to store the NDI value.

[0107] Option 1 allows the HARQ operation of A-IoT devices to be similar to that of current wireless communication systems, thereby minimizing the impact on specifications.

[0108] Option 2: The NDI may take a value indicating that the DL transmission is a new transmission (first value) or a value indicating that the DL transmission is a retransmission (second value). The first and second values ​​may be defined in the specification. For example, the NDI may take two values. For example, if the NDI is set to a bit value of "0", the A-IoT device may consider the DL transmission to be a new transmission. On the other hand, if the NDI is set to a bit value of "1", the A-IoT device may consider the DL transmission to be a retransmission. Alternatively, the mapping may be reversed. That is, if the NDI is set to a bit value of "1", the A-IoT device may consider the DL transmission to be a new transmission, and if the NDI is set to a bit value of "0", the A-IoT device may consider the DL transmission to be a retransmission. In Option 2, the A-IoT device does not need to store the NDI value.

[0109] Option 2 allows the HARQ operation of an A-IoT device to be adapted to a simple configuration of the A-IoT device, and can also achieve more reliable HARQ operation.

[0110] <Proposal 1-3> Next, with regard to the above-mentioned viewpoint (3), a proposal (Proposal 1-3) related to reporting of ACK / NACK of DL reception by an A-IoT device will be described.

[0111] For example, information about the following resources may be provided by the network to the A-IoT device, may be defined in a specification, or may be reported by the A-IoT device to the network as device capabilities for sending ACK / NACK feedback for DL ​​reception: When provided by the network to the A-IoT device, such information may be included in DL data scheduling information (e.g., DCI):

[0112] The information about resources may include (information indicating) a time resource for transmitting ACK / NACK feedback. For example, as shown in FIG. 9 , the information indicating the time resource for transmitting ACK / NACK feedback may be a time offset between (e.g., the end or tail of) DL data reception and the transmission of ACK / NACK feedback. The A-IoT device may transmit ACK / NACK feedback at a timing when the time offset has elapsed since the reception of DL data.

[0113] The granularity of the time offset can be subframe / slot / slot group / symbol / symbol group / second / millisecond / microsecond or any time unit defined for A-IoT.

[0114] A minimum (shortest) time offset may be defined in a specification or may be reported by an A-IoT device to the network as a device capability. The minimum (shortest) time offset may be considered to be the time required for an A-IoT device to decode or process the reception of data. An A-IoT device may not expect a time offset smaller (shorter) than the minimum (shortest) time offset (or a time offset equal to or less than the minimum (shortest) time offset) to be notified (or an A-IoT device may not be notified of a time offset smaller (shorter) than the minimum (shortest) time offset). In other words, an A-IoT device may expect a time offset equal to or greater than the minimum (shortest) time offset (or a time offset larger (longer) than the minimum (shortest) time offset) to be notified (or an A-IoT device may be notified of a time offset equal to or greater than the minimum (shortest) time offset).

[0115] If the time offset is defined in the specification, for example, the A-IoT device may send ACK / NACK feedback to the network after X milliseconds / slot / symbol etc. from the end of DL data reception.

[0116] Time resources (which may be referred to as candidate resources) available for transmitting ACK / NACK feedback may be predefined in a specification or by a network, and one or more resources among the predefined candidate resources may be signaled to the A-IoT device by the network. For example, the candidate resources may be configured / defined by the network through higher layer signaling such as RRC, and one or more resources among the candidate resources may be signaled by the network through DCI.

[0117] Variation 1 of information indicating time resource: Considering that an A-IoT device may not support or maintain DL / UL synchronization, a time duration for transmitting ACK / NACK feedback may be defined in a specification, provided by the network, or reported by the A-IoT device to the network as a device capability, in which case the A-IoT device may be able (allowed) to transmit ACK / NACK feedback within that time duration.

[0118] For example, as shown in FIG. 10, the time offset (shown as time offset #1) between DL data reception (e.g., end or tail) and the start (time) of the time interval may be defined in the specification, provided by the network, or reported to the network by the A-IoT device as a device capability.

[0119] Also, for example, as shown in FIG. 10, the time offset (shown as time offset #2) between DL data reception (e.g., end or tail) and the end (time) of the time interval may be defined in the specification, provided by the network, or reported to the network by the A-IoT device as a device capability.

[0120] Also, for example, the length of the time interval (the difference between time offset #2 and time offset #1 shown in FIG. 10) may be defined in the specification, provided by the network, or reported to the network by the A-IoT device as a device capability.

[0121] The A-IoT device may transmit ACK / NACK feedback after time offset #1 has elapsed since receiving the DL data and before time offset #2 has elapsed since receiving the DL data.

[0122] For example, if an A-IoT device receives DL data in time unit #n, it may send an ACK / NACK for the DL data to the network after time unit #n+k and / or before time unit #n+m.

[0123] Variation 2 of information indicating time resource: As shown in Fig. 11 , when the A-IoT device receives a signal (which may be called an ACK / NACK trigger signal or the like) that triggers (the transmission of) ACK / NACK feedback from the network, the A-IoT device may transmit the ACK / NACK feedback to the network (for example, as a backscatter transmission). Note that "Time separation for DL ​​data processing" shown in Fig. 11 may correspond to the minimum (shortest) time offset described above.

[0124] Furthermore, the information regarding resources may include (information indicating) frequency resources for transmitting ACK / NACK feedback.

[0125] The granularity of the frequency resource may be a subcarrier / resource block, or any frequency unit defined for A-IoT.

[0126] The A-IoT device may transmit ACK / NACK feedback on one or more subcarriers / resource blocks / other frequency units.

[0127] If ACK / NACK feedback is transmitted on multiple subcarriers / resource blocks / other frequency units, the start and length (i.e., width) (or start and end) of the frequency resource may be defined in the specification or provided to the A-IoT device by the network.

[0128] For example, frequency resources (which may be referred to as candidate resources) available for transmitting ACK / NACK feedback may be predefined in a specification or by a network, and one or more resources among the predefined candidate resources may be notified to the A-IoT device by the network. For example, the candidate resources may be configured / defined by the network by higher layer signaling such as RRC, and one or more resources among the candidate resources may be notified by the network by DCI.

[0129] Also, for example, the relationship between frequency resources for transmitting ACK / NACK feedback and frequency resources for data channels may be defined in a specification or may be notified to A-IoT devices by the network.

[0130] According to Proposals 1-3, an A-IoT device can appropriately report ACK / NACK to the network based on information about resources, i.e., using the time resources and / or frequency resources indicated by the information about resources.

[0131] <Operation Example According to Proposal 1> Next, an operation example of the device 20 will be described with reference to FIG.

[0132] In step S11, the device 20 receives downlink data from the network.

[0133] In step S12, the device 20 generates a response signal indicating success or failure in decoding the received downlink data.

[0134] Steps S11 and S12 may be performed according to suggestions 1-1 to 1-3 including Option and Alt described above.

[0135] As described above, according to Proposal 1, ARQ operation can be performed appropriately for DL.

[0136] <Proposal 2-1> Next, with regard to the above-mentioned viewpoints (1) and (4), a proposal (Proposal 2-1) related to whether or not an A-IoT device supports multiple simultaneous HARQ processes will be described.

[0137] The A-IoT device transmits UL data to the network. Depending on whether multiple parallel, concurrent, or simultaneous HARQ processes (hereinafter, simultaneous HARQ processes) are supported, i.e., whether parallel, concurrent, or simultaneous UL data (transmission / processing) is supported, the HARQ operation may need to be different. In other words, the A-IoT device may support multiple simultaneous HARQ processes, or may not support multiple simultaneous HARQ processes (support only a single HARQ process (single UL data processing)), and depending on whether this support is present or absent, the HARQ operation may need to be different.

[0138] [Option 1] Hereinafter, as option 1, a case where an A-IoT device supports multiple simultaneous HARQ processes will be described.

[0139] As mentioned above, the A-IoT device may support or maintain multiple (e.g., X) simultaneous HARQ processes (in other words, may process multiple (e.g., X) UL data transmissions in parallel, concurrently, or simultaneously). For example, the A-IoT device may maintain one buffer per HARQ process.

[0140] The number of simultaneous HARQ processes / number of simultaneous UL data (processing / transmissions) that can be supported or maintained by an A-IoT device may be defined in a specification or may be reported by the A-IoT device to the network as a device capability. The number of simultaneous HARQ processes / number of simultaneous UL data (processing / transmissions) may vary depending on the A-IoT device type (in other words, different numbers of simultaneous HARQ processes / number of simultaneous UL data (processing / transmissions) may be supported by different A-IoT device types).

[0141] When the A-IoT device performs a new transmission of new UL data, it stores or saves the UL data in a corresponding buffer.

[0142] The A-IoT device may transmit another UL data #j of a HARQ process #j different from the HARQ process #i after transmitting UL data #i of a HARQ process #i (HARQ process number i) and before receiving an ACK / NACK for the UL data #i of the HARQ process #i. In other words, the A-IoT device may receive an ACK / NACK for the UL data #i of the HARQ process #i after transmitting the UL data #i of the HARQ process #i and another UL data #j of a HARQ process #j different from the HARQ process #i.

[0143] In addition, the A-IoT device may receive a single ACK / NACK feedback (ACK / NACK bundling) that combines ACK / NACK feedback for multiple UL data sent, or may receive them all together in a single resource.

[0144] The A-IoT device may receive one ACK / NACK from the network in a single DL reception, or may receive multiple ACK / NACKs (e.g., an ACK / NACK for UL data #i of HARQ process #i and an ACK / NACK for UL data #j of HARQ process #j, etc.). Note that the number of ACK / NACKs that the A-IoT device can receive in a single DL reception may be defined in the specification or may be reported to the network by the A-IoT device as device capability.

[0145] One or more of the following constraints may be defined (in the specification):

[0146] For example, the restriction may be that when an A-IoT device transmits UL data #i of HARQ process #i and then transmits UL data #j of HARQ process #j, it assumes or receives an ACK / NACK for UL data #j of HARQ process #i after receiving an ACK / NACK for UL data #i of HARQ process #i.

[0147] As another example, the restriction may be that, for the same HARQ process, the A-IoT device does not assume, does not assume, or does not transmit another UL data (a new transmission of new UL data or a retransmission of previous UL data) that the A-IoT device is scheduled to transmit another UL data before receiving an ACK / NACK for the previous UL data. In other words, the restriction may be that, for the same HARQ process, the A-IoT device assumes, assumes, or transmits another UL data that the A-IoT device is scheduled to transmit another UL data after receiving an ACK / NACK for the previous UL data.

[0148] 13 is a diagram showing an example of an exchange between a base station / support node / intermediate node and an A-IoT device according to Option 1. As shown in FIG. 13, the A-IoT device sequentially transmits UL data #1 of HARQ process #1, UL data #2 of HARQ process #2, ..., UL data #X of HARQ process #X to a network such as a base station. Also, as shown in FIG. 13, the A-IoT device sequentially receives ACK / NACK for UL data #1, ACK / NACK for UL data #2, ..., ACK / NACK for UL data #X from the network such as a base station, depending on whether the network such as a base station successfully decodes these UL data.

[0149] According to Option 1, the HARQ operation of A-IoT devices can be made similar to that of current wireless communication systems for DL ​​reception, thereby minimizing the impact on specifications.

[0150] [Option 2] Hereinafter, as Option 2, a case where the A-IoT device does not support multiple simultaneous HARQ processes will be described.

[0151] The A-IoT device may support or maintain a single HARQ process (in other words, it may process a single UL data (transmission) at a time, or may process multiple UL data (transmissions) in parallel, concurrently or not simultaneously), in which case, for example, the A-IoT device may maintain one buffer.

[0152] When the A-IoT device performs a new transmission of new UL data, it stores or saves the UL data in a buffer.

[0153] One or more of the following constraints may be defined (in the specification):

[0154] For example, the restriction may be that the A-IoT device does not assume, assumes, or does not transmit another UL data (a new transmission of new DL data or a retransmission of previous DL data) before receiving an ACK / NACK for the previous UL data. In other words, the restriction may be that the A-IoT device is scheduled, assumes, or transmits another UL data after receiving an ACK / NACK for the previous UL data.

[0155] As another example, the restriction may be that the A-IoT device does not assume that it is scheduled to transmit new UL data before receiving an ACK for previous UL data, does not assume that it will transmit the new UL data, or does not transmit the new UL data. In other words, the restriction may be that the A-IoT device assumes that it is scheduled to transmit new UL data after receiving an ACK for previous UL data, assumes that it will transmit the new UL data, or transmits the new UL data.

[0156] 14 is a diagram showing an example of interactions between a base station / support node / intermediate node and an A-IoT device according to Option 2. As shown in FIG. 14, when the A-IoT device transmits UL data to a network such as a base station, the network such as the base station transmits an ACK / NACK for this UL data to the A-IoT device depending on whether decoding of this UL data is successful or unsuccessful, and the A-IoT device receives the ACK / NACK from the network such as the base station. Thereafter, similar operations are repeated.

[0157] Note that the reception of ACK / NACK for UL data by an A-IoT device, i.e., the notification of ACK / NACK for UL data by the network, will be explained in Proposal 2-2 below.

[0158] Option 2 allows the HARQ operation of A-IoT devices to be adapted to simple configurations of A-IoT devices.

[0159] In Proposal 2-1, the above-mentioned device A may support only one HARQ process, and the above-mentioned device B and device C may support multiple HARQ processes.

[0160] <Proposal 2-2> Next, regarding the above-mentioned viewpoints (1) and (4), a proposal (Proposal 2-2) related to the notification of ACK / NACK in response to UL reception (UL data) by the network will be described.

[0161] In current wireless communication systems, explicit notification or feedback of ACK / NACK for UL reception (UL data) by the network is not specified. However, in view of the simple configuration of A-IoT devices, the notification of ACK / NACK for UL reception (UL data) by the network may be performed differently from that in current wireless communication systems. That is, it may be necessary to vary the HARQ operation depending on how the network notifies ACK / NACK for UL data transmitted by the A-IoT device.

[0162] [Alt. 1] Below, as Alt. 1, a case will be described in which the network notifies the NDI when scheduling UL data transmission from an A-IoT device.

[0163] As mentioned above, the network may notify the NDI when scheduling UL data transmission from an A-IoT device. The NDI indicates whether the UL transmission is a new transmission (i.e., implies ACK) or a retransmission (i.e., implies NACK). That is, the NDI may indicate not only whether it is a new transmission or a retransmission, but also ACK / NACK.

[0164] If the UL transmission is announced as a new transmission, the A-IoT device flushes or clears the buffer of previous UL data and stores or saves the new UL data in the buffer, whereas if the UL transmission is announced as a retransmission, the A-IoT device retransmits the previous UL data that is stored or saved in the buffer.

[0165] In the case of Option 1 in Proposal 2-1, the network may notify the A-IoT device of a HARQ process index along with the NDI when scheduling UL data transmission from the A-IoT device. The size of the HARQ process index field is related to the number of simultaneous HARQ processes (e.g., X) supported or maintained by the A-IoT device. For example, the size of the HARQ process index field may be 1 bit when X is 2, 2 bits when X is greater than 2 and less than or equal to 4, 3 bits when X is greater than 4 and less than or equal to 8, etc.

[0166] The interpretation of NDI may be as follows:

[0167] Option 1: If the NDI is toggled compared to the value of the previous transmission (if it is different from the value of the previous transmission), the A-IoT device may consider the UL transmission as a new transmission. On the other hand, if the NDI is not toggled compared to the value of the previous transmission (if it is the same as the value of the previous transmission), the A-IoT device may consider the UL transmission as a retransmission. In option 1, the A-IoT device needs to store the NDI value.

[0168] Option 1 allows the HARQ operation of A-IoT devices to be similar to that of current wireless communication systems, thereby minimizing the impact on specifications.

[0169] Option 2: The NDI may take a value indicating that the UL transmission is a new transmission (first value) or a value indicating that the UL transmission is a retransmission (second value). The first value and the second value may be defined in the specification. For example, the NDI may take two values. For example, if the NDI is set to a bit value of "0", the A-IoT device may consider the UL transmission as a new transmission. On the other hand, if the NDI is set to a bit value of "1", the A-IoT device may consider the UL transmission as a retransmission. Alternatively, the mapping may be reversed. That is, if the NDI is set to a bit value of "1", the A-IoT device may consider the UL transmission as a new transmission, and if the NDI is set to a bit value of "0", the A-IoT device may consider the UL transmission as a retransmission. In Option 2, the A-IoT device does not need to store the NDI value.

[0170] Option 2 allows the HARQ operation of an A-IoT device to be adapted to a simple configuration of the A-IoT device, and can also achieve more reliable HARQ operation.

[0171] [Alt. 2] In the following, as Alt. 2, a case where the network directly notifies ACK / NACK, which may be separate from the scheduling of UL data transmission, is described.

[0172] As described above, the network may directly notify the A-IoT device of the ACK / NACK. ACK may take a first value, NACK may take a second value, or ACK / NACK may take two values. For example, a one-bit field for ACK / NACK notification may exist for notifying the ACK / NACK. For example, a bit value of "0" in the field may represent "NACK," and a bit value of "1" in the field may represent "ACK." Alternatively, the mapping may be reversed. That is, a bit value of "0" in the field may represent "ACK," and a bit value of "1" in the field may represent "NACK."

[0173] If the network notifies the A-IoT device of an ACK, the A-IoT device flushes or erases the previous UL data buffer, whereas if the network notifies the A-IoT device of a NACK, the A-IoT device maintains the previous UL data buffer.

[0174] In the case of Option 1 of Proposal 2-1, the network may notify the A-IoT device of the HARQ process index along with the ACK / NACK.

[0175] Also, for example, when the network schedules UL data transmission from the A-IoT device, if previous UL data does not exist in the buffer, the A-IoT device may transmit new UL data to the network or may store or save the new UL data in the buffer. Also, for example, when the network schedules UL data transmission from the A-IoT device, if previous UL data exists in the buffer, the A-IoT device may retransmit the previous UL data to the network. In the case of Option 1 of Proposal 2-1, the network may notify the HARQ process index when scheduling UL transmission.

[0176] The ACK / NACK may be carried in the same DL channel as the UL scheduling information. For example, the UL scheduling information is carried in a DCI carried in a DL control channel, but the ACK / NACK may be carried in a DCI with a different format from this DCI. For example, the ACK / NACK may be carried in a DCI for UL data scheduling with a different DCI format from the UL data scheduling DCI.

[0177] Alternatively, the ACK / NACK may be carried on a different DL channel than the UL scheduling information, for example, the UL scheduling information may be carried in a DCI carried on a DL control channel, while the ACK / NACK may be carried on another DL channel (e.g., a channel identical or similar to the physical HARQ indicator channel (PHICH) in LTE, or a data channel).

[0178] According to Alt. 2, the HARQ operation of an A-IoT device can be adapted to a simple configuration of the A-IoT device.

[0179] <Proposal 2-3> Next, regarding the above-mentioned viewpoint (3), a proposal (Proposal 2-3) related to the reception of ACK / NACK by an A-IoT device in response to UL reception by the network will be described.

[0180] For example, information about the following resources may be provided by the network to the A-IoT device, may be defined in a specification, or may be reported by the A-IoT device to the network as device capabilities for receiving ACK / NACK feedback for UL transmissions: When such information is provided by the network to the A-IoT device, it may be included in UL data scheduling information (e.g., DCI or UL grant):

[0181] The information about the resources may include (information indicating) a time resource for receiving ACK / NACK feedback. For example, as shown in FIG. 15 , the information indicating the time resource for receiving ACK / NACK feedback may be a time offset between (e.g., the end or tail of) the UL data transmission and the reception of the ACK / NACK feedback. The A-IoT device may receive the ACK / NACK feedback at a timing when the time offset has elapsed since the transmission of the UL data.

[0182] The granularity of the time offset may be subframe / slot / slot group / symbol / symbol group / second / millisecond / microsecond, or any time unit defined for A-IoT.

[0183] If the time offset is defined in the specification, for example, the A-IoT device may receive ACK / NACK feedback from the network X milliseconds / slot / symbol etc. after the end of the UL data transmission.

[0184] Time resources available for receiving ACK / NACK feedback (which may be referred to as candidate resources) may be predefined in a specification or by a network, and one or more of the predefined candidate resources may be signaled to the A-IoT device by the network. For example, the candidate resources may be configured / defined by the network through higher layer signaling such as RRC, and one or more of the candidate resources may be signaled by the network through DCI.

[0185] Variations of information indicating time resources Considering that an A-IoT device may not support or maintain DL / UL synchronization, a period or time interval for receiving ACK / NACK feedback may be defined in a specification, provided by the network, or reported by the A-IoT device to the network as a device capability. In this case, the A-IoT device may expect to receive or may receive ACK / NACK feedback within the time interval.

[0186] For example, as shown in FIG. 16, the time offset (shown as time offset #1) between (e.g., the end or tail of) the UL data transmission and the start (time) of the time interval may be defined in the specification, may be provided by the network, or may be reported to the network by the A-IoT device as a device capability.

[0187] Also, for example, as shown in FIG. 16, the time offset (shown as time offset #2) between (e.g., the end or tail of) the UL data transmission and the end (time) of the time interval may be defined in the specification, provided by the network, or reported to the network by the A-IoT device as a device capability.

[0188] Also, for example, the length of the time interval (the difference between time offset #2 and time offset #1 shown in FIG. 16) may be defined in the specification, provided by the network, or reported to the network by the A-IoT device as a device capability.

[0189] The A-IoT device may receive ACK / NACK feedback after time offset #1 has elapsed since the transmission of the UL data and before time offset #2 has elapsed since the transmission of the UL data.

[0190] For example, if an A-IoT device transmits UL data in time unit #n, it may receive an ACK / NACK for the UL data from the network after time unit #n+k and / or before time unit #n+m.

[0191] As a variation of the time interval, if the A-IoT device does not receive ACK / NACK feedback within the time interval, it may consider this as a NACK. Alternatively, conversely, if the A-IoT device does not receive ACK / NACK feedback within the time interval, it may consider this as an ACK.

[0192] Furthermore, the information regarding resources may include (information indicating) frequency resources for receiving ACK / NACK feedback.

[0193] The granularity of the frequency resource may be a subcarrier / resource block, or any frequency unit defined for A-IoT.

[0194] The A-IoT device may receive ACK / NACK feedback on one or more subcarriers / resource blocks / other frequency units.

[0195] If ACK / NACK feedback is received on multiple subcarriers / resource blocks / other frequency units, the start and length (or start and end) of the frequency resources may be defined in the specification or provided to the A-IoT device by the network.

[0196] For example, frequency resources (which may be referred to as candidate resources) available for receiving ACK / NACK feedback may be predefined in a specification or by a network, and one or more resources among the predefined candidate resources may be notified to the A-IoT device by the network. For example, the candidate resources may be configured / defined by the network through higher layer signaling such as RRC, and one or more resources among the candidate resources may be notified by the network through DCI.

[0197] Also, for example, the relationship between frequency resources for receiving ACK / NACK feedback and frequency resources for data channels may be defined in a specification or may be notified to an A-IoT device by the network.

[0198] As explained in Proposal 2-2, ACK / NACK feedback from the network may be applied only when a channel separate from UL / DL scheduling information is used for ACK / NACK feedback (e.g., when UL / DL scheduling information is carried in the DL control channel (DCI) and ACK / NACK is carried in the HARQ indicator channel (PHICH)).

[0199] According to Proposal 2-3, an A-IoT device can appropriately receive ACK / NACK from the network based on information about resources, i.e., using the time resources and / or frequency resources indicated by the information about resources.

[0200] <Operation Example According to Proposal 2> Next, an operation example of the device 20 will be described with reference to FIG.

[0201] In step S21, the device 20 transmits uplink data to the network.

[0202] In step S22, the device 20 receives a response signal from the network indicating success or failure of decoding the transmitted uplink data.

[0203] In step S23, the device 20 controls retransmission of the transmitted uplink data based on the received response signal.

[0204] Steps S21 to S23 may be performed according to the above-mentioned suggestions 2-1 to 2-3 including Option and Alt.

[0205] As described above, according to Proposal 2, ARQ operation can be performed appropriately for UL.

[0206] <Capability> The A-IoT capability indicating the capabilities of an A-IoT device such as the device 20 may include the following information indicating the device capabilities. The device 20 may report the following information indicating the device capabilities to the base station 10. Note that the information indicating the device capabilities may correspond to information that defines the device capabilities.

[0207] - defining whether the A-IoT device supports multiple simultaneous HARQ processes for DL ​​reception; - defining whether the A-IoT device supports simultaneous DL data (processing / reception); - information defining the number of simultaneous HARQ processes the A-IoT device can support or hold for DL ​​reception; - information defining the number of simultaneous DL data (processing / reception) the A-IoT device can process; - information defining whether the A-IoT device supports a soft buffer for DL ​​data decoding; - information defining the number of soft buffers the A-IoT device can support or hold; - information defining the number of ACK / NACKs the A-IoT device can transmit in a single UL transmission; - information defining the time and / or frequency resources for the transmission of ACK / NACK feedback; - information defining the minimum (shortest) time offset for the A-IoT device to transmit ACK / NACK feedback; - defining whether the A-IoT device supports multiple simultaneous HARQ processes for UL transmission. - defining whether the A-IoT device supports simultaneous UL data (processing / transmission); - information defining the number of simultaneous HARQ processes the A-IoT device can support or hold for UL transmission; - information defining the number of simultaneous UL data (processing / transmission) the A-IoT device can process; - information defining whether the A-IoT device supports buffers for UL data transmission; - information defining the number of buffers the A-IoT device can support or hold; - information defining the number of ACKs / NACKs the A-IoT device can receive in a single DL reception; - information defining the time and / or frequency resources for the A-IoT device for receiving ACK / NACK feedback; - information defining whether the A-IoT device supports which of the above-mentioned proposals and / or options and / or Alts the A-IoT device supports.

[0208] Next, the configurations of the base station 10 and the device 20 will be described. Note that the configurations of the base station 10 and the device 20 described below are examples of functions related to this embodiment. The base station 10 and the device 20 may have functions not shown. Furthermore, the functional divisions and / or names of the functional units are not limited as long as the functions perform the operations related to this embodiment.

[0209] <Configuration of Base Station> Fig. 18 is a block diagram showing an example of the configuration of a base station 10 according to an embodiment. The base station 10 includes, for example, a transmitting unit 101, a receiving unit 102, and a control unit 103. The base station 10 communicates with the device 20 (see Fig. 19) wirelessly. The base station 10 may be an intermediate node, a support node, or a terminal (a terminal of an SL that communicates with the device 20).

[0210] The transmitter 101 transmits a downlink (DL) signal to the device 20. For example, the transmitter 101 transmits the DL signal under the control of the controller 103.

[0211] The DL signal may include, for example, a downlink data signal and control information (e.g., DCI (Downlink Control Information)). The DL signal may also include information indicating scheduling related to signal transmission of the device 20 (e.g., an UL grant). The DL signal may also include control information of higher layers (e.g., control information of RRC (Radio Resource Control)). The DL signal may also include a reference signal.

[0212] The channels used for transmitting DL signals include, for example, a data channel and a control channel. For example, the data channel may include a PDSCH (Physical Downlink Shared Channel), and the control channel may include a PDCCH (Physical Downlink Control Channel). For example, the base station 10 transmits control information to the device 20 using the PDCCH and transmits downlink data signals using the PDSCH.

[0213] The reference signal included in the DL signal may include at least one of, for example, a Demodulation Reference Signal (DMRS), a Phase Tracking Reference Signal (PTRS), a Channel State Information-Reference Signal (CSI-RS), a Sounding Reference Signal (SRS), and a Positioning Reference Signal (PRS) for position information. For example, reference signals such as the DMRS and PTRS are used for demodulating downlink data signals and are transmitted using the PDSCH.

[0214] The receiving unit 102 receives an uplink (UL) signal transmitted from the device 20. For example, the receiving unit 102 receives the UL signal under the control of the control unit 103.

[0215] The control unit 103 controls the communication operations of the base station 10 , including the transmission processing of the transmission unit 101 and the reception processing of the reception unit 102 .

[0216] For example, the control unit 103 acquires information such as data and control information from the upper layer and outputs it to the transmitting unit 101. The control unit 103 also outputs the data, control information, etc. received from the receiving unit 102 to the upper layer.

[0217] For example, the control unit 103 allocates resources (or channels) used for transmitting and receiving DL signals and / or resources used for transmitting and receiving UL signals based on signals (e.g., data and control information, etc.) received from the device 20 and / or data and control information, etc. acquired from a higher layer. Information on the allocated resources may be included in control information transmitted to the device 20.

[0218] The control unit 103 configures PUCCH resources as an example of allocation of resources used for transmitting and receiving UL signals. Information related to the configuration of the PUCCH, such as a PUCCH cell timing pattern (PUCCH configuration information), may be notified to the device 20 by RRC.

[0219] Here, the transmitting unit 101 and the receiving unit 102 (which may be collectively referred to as a communication unit) communicate with the device 20 .

[0220] For example, the transmitting unit 101 may transmit downlink data to the device 20, and the receiving unit 102 may receive a response signal indicating success or failure in decoding the transmitted downlink data from the device 20. The transmitting unit 101 may transmit to the device 20 binary information indicating whether the transmission of the downlink data is a new transmission or a retransmission.

[0221] Furthermore, for example, the receiving unit 102 may receive uplink data from the device 20, the control unit 103 may generate a response signal indicating success or failure in decoding the received uplink data, and the transmitting unit 101 may transmit the generated response signal to the device 20. The response signal may take one of two values.

[0222] 19 is a block diagram showing an example of the configuration of a device 20 according to an embodiment. The device 20 includes, for example, a receiving unit 201, a transmitting unit 202, and a control unit 203. The device 20 communicates with, for example, a base station 10 wirelessly. The device 20 may be, for example, an A-IoT device.

[0223] The receiving unit 201 receives a DL signal transmitted from the base station 10. For example, the receiving unit 201 receives the DL signal under the control of the control unit 203.

[0224] The transmitting unit 202 transmits the UL signal to the base station 10. For example, the transmitting unit 202 transmits the UL signal under the control of the control unit 203.

[0225] The UL signal may include, for example, an uplink data signal and control information (e.g., UCI (Uplink Control Information)). For example, information related to the processing capability of the device 20 (e.g., A-IoT capability) may be included. The UL signal may also include a reference signal.

[0226] The channels used for transmitting UL signals include, for example, a data channel and a control channel. For example, the data channel may include a PUSCH (Physical Uplink Shared Channel), and the control channel may include a PUCCH (Physical Uplink Control Channel). For example, the device 20 transmits control information from the base station 10 using the PUCCH and transmits uplink data signals using the PUSCH.

[0227] The reference signal included in the UL signal may include, for example, at least one of a DMRS, a PTRS, a CSI-RS, an SRS, and a PRS. For example, the reference signal such as the DMRS or the PTRS is used for demodulating an uplink data signal and is transmitted using an uplink channel (for example, a PUSCH).

[0228] The control unit 203 controls the communication operations of the device 20 , including the reception processing in the receiving unit 201 and the transmission processing in the transmitting unit 202 .

[0229] For example, the control unit 203 acquires information such as data and control information from the upper layer and outputs it to the transmitting unit 202. Also, the control unit 203 outputs, for example, the data and control information received from the receiving unit 201 to the upper layer.

[0230] For example, the control unit 203 controls transmission of information to be fed back to the base station 10. The information to be fed back to the base station 10 may include, for example, HARQ ACK / NACK, Channel State Information (CSI), or a Scheduling Request (SR). The information to be fed back to the base station 10 may be included in UCI. The UCI is transmitted, for example, in PUCCH resources.

[0231] Control unit 203 configures PUCCH resources based on configuration information (for example, configuration information such as a PUCCH cell timing pattern and / or DCI notified by RRC) received from base station 10. Control unit 203 determines PUCCH resources to be used for transmitting information to be fed back to base station 10. Under the control of control unit 203, transmission unit 202 transmits the information to be fed back to base station 10 in the PUCCH resources determined by control unit 203.

[0232] Note that the channel used for transmitting the DL signal and the channel used for transmitting the UL signal are not limited to the above-mentioned examples. For example, the channel used for transmitting the DL signal and the channel used for transmitting the UL signal may include a Random Access Channel (RACH) and a Physical Broadcast Channel (PBCH). The RACH may be used to transmit DCI including a Random Access Radio Network Temporary Identifier (RA-RNTI), for example.

[0233] Here, the receiving unit 201 and the transmitting unit 202 (which may be collectively referred to as a communication unit) communicate with a network such as the base station 10 .

[0234] For example, the receiving unit 201 may receive downlink data from a network, and the control unit 203 may generate a response signal indicating success or failure in decoding the received downlink data. The device 20 may not maintain a soft buffer for decoding the downlink data. The receiving unit 201 may receive binary information indicating whether the transmission of the downlink data is a new transmission or a retransmission from the network, and the control unit 203 may determine whether the transmission of the downlink data is a new transmission or a retransmission based on the received binary information. The transmitting unit 202 may transmit a response signal to the network at a timing when a first time has elapsed since the reception of the downlink data, or may transmit a response signal to the network after the first time has elapsed since the reception of the downlink data and before a second time has elapsed since the reception of the downlink data.

[0235] Furthermore, for example, the transmitter 202 may transmit uplink data to a network, the receiver 201 may receive from the network a response signal indicating success or failure in decoding of the uplink data transmitted to the network, and the controller 203 may perform retransmission control of the uplink data transmitted to the network based on the received response signal. The device 20 may hold one or more buffers for transmitting uplink data. The response signal may take one of two values. The receiver 201 may receive the response signal at a timing when a first time has elapsed since the transmission of the uplink data, or may receive the response signal after the first time has elapsed since the transmission of the uplink data and before a second time has elapsed since the transmission of the uplink data.

[0236] (Summary of the embodiment) A device according to one aspect of the present disclosure is a device with lower complexity than an NB-IoT (Narrow Band Internet of Things) device, and includes a receiver that receives downlink data from a network, and a controller that generates a response signal indicating success or failure in decoding the downlink data.

[0237] By having the above configuration, for example, a device such as an A-IoT device can perform HARQ operations appropriately.

[0238] In one example, the device does not maintain a soft buffer for downlink data decoding.

[0239] With the above configuration, it is possible to realize HARQ operation that is tailored to a simple configuration.

[0240] In one example, the receiving unit receives binary information from the network indicating whether the transmission of the downlink data is a new transmission or a retransmission, and the control unit determines whether the transmission of the downlink data is a new transmission or a retransmission based on the binary information.

[0241] With the above configuration, it is possible to realize a HARQ operation that is adapted to a simple configuration, and also to realize a more reliable HARQ operation.

[0242] In one example, the device further includes a transmitter configured to transmit the response signal to the network when a first time period has elapsed since the reception of the downlink data.

[0243] With the above configuration, it is possible to report HARQ ACK / NACK at an appropriate timing.

[0244] In one example, the device further includes a transmitter that transmits the response signal to the network after a first time has elapsed since receiving the downlink data and before a second time has elapsed since receiving the downlink data.

[0245] With the above configuration, even if DL / UL synchronization is not supported, HARQ ACK / NACK can be reported appropriately.

[0246] A communication method according to one aspect of the present disclosure comprises a device with lower complexity than a Narrow Band Internet of Things (NB-IoT) device receiving downlink data from a network and generating a response signal indicating success or failure in decoding the downlink data.

[0247] By having the above configuration, for example, a device such as an A-IoT device can perform HARQ operations appropriately.

[0248] A device according to one aspect of the present disclosure is a device of lower complexity than an NB-IoT (Narrow Band Internet of Things) device, and includes a receiving unit that receives a response signal from a network indicating success or failure in decoding of uplink data transmitted to the network, and a control unit that controls retransmission of the uplink data based on the response signal.

[0249] By having the above configuration, for example, a device such as an A-IoT device can perform HARQ operations appropriately.

[0250] In one example, the device maintains one or more buffers for uplink data transmission.

[0251] With the above configuration, it is possible to perform the same operation as the existing downlink HARQ operation.

[0252] In one example, the response signal takes one of two values.

[0253] With the above configuration, it is possible to realize a HARQ operation that is adapted to a simple configuration, and also to realize a more reliable HARQ operation.

[0254] In one example, the receiver receives the response signal at a timing when a first time has elapsed since the transmission of the uplink data.

[0255] With the above configuration, it is possible to receive HARQ ACK / NACK at an appropriate timing.

[0256] In one example, the receiver receives the response signal after a first time has elapsed since the transmission of the uplink data and before a second time has elapsed since the transmission of the uplink data.

[0257] With the above configuration, even if DL / UL synchronization is not supported, HARQ ACK / NACK can be properly received.

[0258] A communication method according to one aspect of the present disclosure comprises a device with lower complexity than an NB-IoT (Narrow Band Internet of Things) device receiving a response signal from the network indicating success or failure in decoding uplink data transmitted to the network, and performing retransmission control of the uplink data based on the response signal.

[0259] By having the above configuration, for example, a device such as an A-IoT device can perform HARQ operations appropriately.

[0260] The present disclosure has been described above. Note that the division of items in the above description is not essential to the present disclosure, and items described in two or more items may be used in combination as needed, and items described in one item may be applied to items described in another item (unless they are inconsistent).

[0261] <Hardware Configuration, etc.> The block diagrams used to explain the above embodiments show functional blocks. These functional blocks (components) are realized by any combination of at least one of hardware and software. Furthermore, the method for realizing each functional block is not particularly limited. That is, each functional block may be realized using a single device that is physically or logically coupled, or may be realized using two or more physically or logically separated devices that are directly or indirectly connected (e.g., using wires, wirelessly, etc.) and these multiple devices. The functional block may also be realized by combining software with the single device or the multiple devices.

[0262] Functions include, but are not limited to, judgment, determination, assessment, calculation, computation, processing, derivation, investigation, search, confirmation, reception, transmission, output, access, resolution, selection, selection, establishment, comparison, assumption, expectation, consideration, broadcasting, notifying, communicating, forwarding, configuring, reconfiguring, allocating, mapping, and assignment. For example, a functional block (component) that performs transmission is called a transmitting unit or transmitter. As mentioned above, there are no particular limitations on how these functions are implemented.

[0263] For example, a base station, a device, or the like according to an embodiment of the present disclosure may function as a computer that performs processing of the wireless communication method of the present disclosure. Fig. 20 is a diagram illustrating an example of the hardware configuration of a base station and a device according to the embodiment. The above-described base station 10 and device 20 may be physically configured as a computer including a processor 1001, a memory 1002, a storage 1003, a communication device 1004, an input device 1005, an output device 1006, a bus 1007, and the like.

[0264] In the following description, the term "apparatus" can be interpreted as a circuit, a device, a unit, etc. The hardware configuration of the base station 10 and the device 20 may be configured to include one or more of the apparatuses shown in the drawings, or may be configured to exclude some of the apparatuses.

[0265] Each function in the base station 10 and the device 20 is realized by loading specified software (programs) onto hardware such as the processor 1001 and memory 1002, causing the processor 1001 to perform calculations, control communication by the communication device 1004, and control at least one of reading and writing data in the memory 1002 and storage 1003.

[0266] The processor 1001 controls the entire computer by running, for example, an operating system. The processor 1001 may be configured by a central processing unit (CPU) including an interface with peripheral devices, a control device, an arithmetic unit, a register, etc. For example, the above-mentioned control unit 103 and control unit 203 may be realized by the processor 1001.

[0267] The processor 1001 also reads programs (program codes), software modules, data, etc. from at least one of the storage 1003 and the communication device 1004 into the memory 1002 and executes various processes in accordance with the programs. The programs used are those that cause a computer to execute at least some of the operations described in the above-described embodiments. For example, the control unit 103 of the base station 10 and the control unit 203 of the device 20 may be implemented by a control program stored in the memory 1002 and running on the processor 1001, and similar implementations may be used for other functional blocks. While the above-described various processes have been described as being executed by one processor 1001, they may also be executed simultaneously or sequentially by two or more processors 1001. The processor 1001 may be implemented by one or more chips. The programs may also be transmitted from a network via a telecommunications line.

[0268] The memory 1002 is a computer-readable recording medium and may be configured by, for example, at least one of a read-only memory (ROM), an erasable programmable ROM (EPROM), an electrically erasable programmable ROM (EEPROM), a random access memory (RAM), etc. The memory 1002 may also be called a register, a cache, a main memory (primary storage device), etc. The memory 1002 can store executable programs (program codes), software modules, etc. for implementing a wireless communication method according to an embodiment of the present disclosure.

[0269] Storage 1003 is a computer-readable recording medium, and may be composed of at least one of, for example, an optical disk such as a CD-ROM (Compact Disc ROM), a hard disk drive, a flexible disk, a magneto-optical disk (e.g., a compact disk, a digital versatile disk, a Blu-ray (registered trademark) disk), a smart card, a flash memory (e.g., a card, a stick, a key drive), a floppy (registered trademark) disk, a magnetic strip, etc. Storage 1003 may also be referred to as an auxiliary storage device. The above-mentioned storage medium may be, for example, a database, a server, or other appropriate medium including at least one of memory 1002 and storage 1003.

[0270] The communication device 1004 is hardware (transmission / reception device) for communicating between computers via at least one of a wired network and a wireless network, and is also referred to as, for example, a network device, a network controller, a network card, a communication module, etc. The communication device 1004 may be configured to include a high-frequency switch, a duplexer, a filter, a frequency synthesizer, etc. to realize at least one of frequency division duplex (FDD) and time division duplex (TDD). For example, the above-mentioned transmitter 101, receiver 102, receiver 201, transmitter 202, etc. may be realized by the communication device 1004.

[0271] The input device 1005 is an input device (e.g., a keyboard, a mouse, a microphone, a switch, a button, a sensor, etc.) that receives input from the outside. The output device 1006 is an output device (e.g., a display, a speaker, an LED lamp, etc.) that outputs to the outside. The input device 1005 and the output device 1006 may be integrated into one device (e.g., a touch panel).

[0272] Furthermore, each device, such as the processor 1001 and the memory 1002, is connected by a bus 1007 for communicating information. The bus 1007 may be configured using a single bus, or may be configured using different buses between each device.

[0273] Furthermore, the base station 10 and the device 20 may be configured to include hardware such as a microprocessor, a digital signal processor (DSP), an application specific integrated circuit (ASIC), a programmable logic device (PLD), or a field programmable gate array (FPGA), and some or all of the functional blocks may be realized by the hardware. For example, the processor 1001 may be implemented using at least one of these pieces of hardware.

[0274] <Notification of Information, Signaling> Notification of information is not limited to the embodiments described in the present disclosure and may be performed using other methods. For example, notification of information may be performed by physical layer signaling (e.g., Downlink Control Information (DCI), Uplink Control Information (UCI)), higher layer signaling (e.g., Radio Resource Control (RRC) signaling, Medium Access Control (MAC) signaling, broadcast information (Master Information Block (MIB), System Information Block (SIB))), other signals, or a combination thereof. Furthermore, RRC signaling may be referred to as an RRC message, and may be, for example, an RRC Connection Setup message, an RRC Connection Reconfiguration message, or the like.

[0275] <Applicable Systems> The embodiments described in the present disclosure are applicable to LTE (Long Term Evolution), LTE-Advanced (LTE-A), SUPER 3G, IMT-Advanced, 4G (4th generation mobile communication system), 5G (5th generation mobile communication system), 6th generation mobile communication system (6G), xth generation mobile communication system (xG) (xG (x is, for example, an integer or a decimal)), FRA (Future Radio Access), NR (new Radio), New radio access (NX), Future generation radio access (FX), W-CDMA (registered trademark), GSM (registered trademark), CDMA2000, UMB (Ultra Mobile Broadband), IEEE 802.11 (Wi-Fi (registered trademark)), IEEE 802.16 (WiMAX (registered trademark)), IEEE 802.17 (WiMAX (registered trademark)), IEEE 802.19 (WiMAX (registered trademark)), IEEE 802.20 (WiMAX (registered trademark)), IEEE 802.21 (Wi-Fi (registered trademark)), IEEE 802.22 (WiMAX (registered trademark)), IEEE 802.23 (WiMAX (registered trademark)), IEEE 802.24 (WiMAX (registered trademark)), IEEE 802.25 (WiMAX (registered trademark)), IEEE 802.26 (WiMAX (registered trademark)), IEEE 802.27 (WiMAX (registered trademark)), IEEE 802.28 (WiMAX (registered trademark)), IEEE 802.29 (WiMAX (registered trademark)), IEEE 802.30 (WiMAX (registered trademark)), IEEE 802.31 (Wi-Fi (registered trademark)), IEEE 802.32 (WiMAX (registered trademark)), IEEE 802.33 (WiMAX (registered trademark)), IEEE 802.34 (WiMAX (registered trademark The present invention may be applied to at least one of systems using 802.20, UWB (Ultra-Wide Band), Bluetooth (registered trademark), or other suitable systems, and next-generation systems that are extended, modified, created, or defined based on these systems. The present invention may also be applied to a combination of multiple systems (e.g., a combination of LTE and / or LTE-A with 5G).

[0276] <Processing Procedures, etc.> The processing procedures, sequences, flowcharts, etc. of each aspect / embodiment described in this disclosure may be rearranged unless inconsistent. For example, the methods described in this disclosure present elements of various steps using an example order, and are not limited to the particular order presented.

[0277] <Operation of Base Station> In the present disclosure, specific operations described as being performed by a base station may also be performed by its upper node in some cases. In a network consisting of one or more network nodes having a base station, it is clear that various operations performed for communication with a terminal may be performed by at least one of the base station and another network node other than the base station (for example, an MME or an S-GW, etc., but are not limited to these). Although the above example illustrates a case where there is one other network node other than the base station, a combination of multiple other network nodes (for example, an MME and an S-GW) may also be used.

[0278] <Direction of Input / Output> Information, etc. (see <Information, Signal>) can be output from a higher layer (or a lower layer) to a lower layer (or a higher layer). It may also be input / output via multiple network nodes.

[0279] <Handling of Input / Output Information, etc.> Input / output information, etc. may be stored in a specific location (for example, memory) or may be managed using a management table. Input / output information, etc. may be overwritten, updated, or added. Output information, etc. may be deleted. Input information, etc. may be sent to another device.

[0280] <Determination method> The determination may be made based on a value represented by one bit (0 or 1), a Boolean value (true or false), or a comparison of numerical values ​​(e.g., comparison with a predetermined value).

[0281] <Variations of Aspects, etc.> Each aspect / embodiment described in the present disclosure may be used alone, in combination, or switched depending on the implementation. In addition, notification of predetermined information (e.g., notification that "X is true") is not limited to being done explicitly, but may be done implicitly (e.g., by not notifying the predetermined information).

[0282] Although the present disclosure has been described in detail above, it is clear to those skilled in the art that the present disclosure is not limited to the embodiments described herein. The present disclosure can be implemented in modified and altered forms without departing from the spirit and scope of the present disclosure as defined by the claims. Therefore, the description of the present disclosure is intended to be illustrative and does not have any limiting meaning on the present disclosure.

[0283] <Software> Software shall be construed broadly to mean instructions, instruction sets, code, code segments, program code, programs, subprograms, software modules, applications, software applications, software packages, routines, subroutines, objects, executable files, threads of execution, procedures, functions, etc., whether referred to as software, firmware, middleware, microcode, hardware description language, or otherwise.

[0284] Software, instructions, information, etc. may also be transmitted or received over a transmission medium. For example, if software is transmitted from a website, server, or other remote source using wired technologies (such as coaxial cable, fiber optic cable, twisted pair, Digital Subscriber Line (DSL)), and / or wireless technologies (such as infrared, microwave), then these wired and / or wireless technologies are included within the definition of transmission media.

[0285] Information, Signals, etc., described in this disclosure may be represented using any of a variety of different technologies. For example, data, instructions, commands, information, signals, bits, symbols, chips, etc., which may be referred to throughout the above description, may be represented by voltages, currents, electromagnetic waves, magnetic fields or magnetic particles, optical fields or photons, or any combination thereof.

[0286] Note that terms described in this disclosure and terms necessary for understanding this disclosure may be replaced with terms having the same or similar meanings. For example, at least one of a channel and a symbol may be a signal (signaling). Furthermore, a signal may be a message. Furthermore, a component carrier (CC) may be called a carrier frequency, a cell, a frequency carrier, etc.

[0287] <System, Network> As used in this disclosure, the terms "system" and "network" are used interchangeably.

[0288] <Parameter and Channel Names> Furthermore, the information, parameters, and the like described in the present disclosure may be expressed using absolute values, relative values ​​from a predetermined value, or other corresponding information. For example, a radio resource may be indicated by an index.

[0289] The names used for the above-described parameters are not intended to be limiting in any way. Furthermore, the mathematical expressions using these parameters may differ from those explicitly disclosed in this disclosure. The various channels (e.g., PUCCH, PDCCH, etc.) and information elements may be identified by any suitable names, and therefore the various names assigned to these various channels and information elements are not intended to be limiting in any way.

[0290] <Base Station> In the present disclosure, terms such as "base station (BS)," "radio base station," "fixed station," "NodeB," "eNodeB (eNB)," "gNodeB (gNB)," "access point," "transmission point," "reception point," "transmission / reception point," "cell," "sector," "cell group," "carrier," and "component carrier" may be used interchangeably. A base station may also be referred to by terms such as a macrocell, a small cell, a femtocell, and a picocell.

[0291] A base station can accommodate one or more (e.g., three) cells. When a base station accommodates multiple cells, the overall coverage area of ​​the base station can be partitioned into multiple smaller areas, and each smaller area can also be provided with communication services by a base station subsystem (e.g., a remote radio head (RRH)). The terms "cell" or "sector" refer to part or the entire coverage area of ​​a base station and / or base station subsystem that provides communication services within that coverage area.

[0292] In the present disclosure, the base station transmitting information to a terminal may be interpreted as the base station instructing the terminal to control or operate based on the information.

[0293] Mobile Station In this disclosure, the terms "Mobile Station (MS)," "user terminal," "User Equipment (UE)," "terminal," and the like may be used interchangeably.

[0294] A mobile station may also be referred to by those skilled in the art as a subscriber station, mobile unit, subscriber unit, wireless unit, remote unit, mobile device, wireless device, wireless communication device, remote device, mobile subscriber station, access terminal, mobile terminal, wireless terminal, remote terminal, handset, user agent, mobile client, client, or some other suitable terminology.

[0295] <Base Station / Mobile Station> At least one of the base station and the mobile station may be referred to as a transmitting device, a receiving device, a communication device, etc. At least one of the base station and the mobile station may be a device mounted on a mobile object, the mobile object itself, etc. The mobile object refers to a movable object, and may move at any speed. Naturally, this also includes cases where the mobile object is stationary. Examples of the mobile object include, but are not limited to, vehicles, transport vehicles, automobiles, motorcycles, bicycles, connected cars, excavators, bulldozers, wheel loaders, dump trucks, forklifts, trains, buses, handcars, rickshaws, ships and other watercraft, airplanes, rockets, satellites, drones (registered trademark), multicopters, quadcopters, balloons, and objects mounted thereon. The mobile object may also be an autonomous mobile object operating based on an operational command. It may be a vehicle (e.g., a car, an airplane, etc.), an unmanned mobile object (e.g., a drone, an autonomous vehicle, etc.), or a robot (manned or unmanned). At least one of the base station and the mobile station may be a device that does not necessarily move during communication operations. For example, at least one of the base station and the mobile station may be an IoT (Internet of Things) device such as a sensor.

[0296] Furthermore, the base station in the present disclosure may be read as a terminal. For example, the embodiments of the present disclosure may be applied to a configuration in which communication between a base station and a terminal is replaced with communication between multiple terminals (which may be called, for example, D2D (Device-to-Device) or V2X (Vehicle-to-Everything)). In this case, the device 20 may be configured to have the functions of the base station 10 described above. Furthermore, terms such as "uplink" and "downlink" may be read as terms corresponding to communication between terminals (for example, "side"). For example, terms such as an uplink channel and a downlink channel may be read as a side channel.

[0297] Similarly, the term "terminal" in the present disclosure may be read as a base station. In this case, the base station 10 may be configured to have the functions of the device 20 described above.

[0298] Fig. 21 shows an example configuration of a vehicle 2001. As shown in Fig. 21, the vehicle 2001 includes a drive unit 2002, a steering unit 2003, an accelerator pedal 2004, a brake pedal 2005, a shift lever 2006, front wheels 2007, rear wheels 2008, an axle 2009, an electronic control unit 2010, various sensors 2021 to 2029, an information service unit 2012, and a communication module 2013. Each aspect / embodiment described in the present disclosure may be applied to a communication device mounted on the vehicle 2001, and may be applied to the communication module 2013, for example.

[0299] The drive unit 2002 is configured, for example, by an engine, a motor, or a hybrid of an engine and a motor. The steering unit 2003 includes at least a steering wheel (also called a handle) and is configured to steer at least one of the front wheels and the rear wheels based on the operation of the steering wheel operated by the user.

[0300] The electronic control unit 2010 is composed of a microprocessor 2031, a memory (ROM, RAM) 2032, and a communication port (IO port) 2033. Signals are input to the electronic control unit 2010 from various sensors 2021 to 2029 provided in the vehicle 2001. The electronic control unit 2010 may also be called an ECU (Electronic Control Unit).

[0301] The signals from the various sensors 2021 to 2029 include a current signal from a current sensor 2021 that senses the current of the motor, a rotation speed signal of the front and rear wheels obtained by a rotation speed sensor 2022, an air pressure signal of the front and rear wheels obtained by an air pressure sensor 2023, a vehicle speed signal obtained by a vehicle speed sensor 2024, an acceleration signal obtained by an acceleration sensor 2025, an accelerator pedal depression amount signal obtained by an accelerator pedal sensor 2029, a brake pedal depression amount signal obtained by a brake pedal sensor 2026, a shift lever operation signal obtained by a shift lever sensor 2027, and a detection signal for detecting obstacles, vehicles, pedestrians, etc. obtained by an object detection sensor 2028.

[0302] The information service unit 2012 is composed of various devices, such as a car navigation system, an audio system, speakers, a television, and a radio, for providing (outputting) various types of information, such as driving information, traffic information, and entertainment information, and one or more ECUs that control these devices. The information service unit 2012 provides various types of multimedia information and multimedia services to the occupants of the vehicle 2001 by using information acquired from external devices via the communication module 2013, etc.

[0303] The information service unit 2012 may include input devices (e.g., keyboards, mice, microphones, switches, buttons, sensors, touch panels, etc.) that accept input from the outside, and may also include output devices (e.g., displays, speakers, LED lamps, touch panels, etc.) that output to the outside.

[0304] The driving assistance system unit 2030 is composed of various devices that provide functions for preventing accidents and reducing the driving burden on the driver, such as millimeter-wave radar, LiDAR (Light Detection and Ranging), cameras, positioning locators (e.g., GNSS, etc.), map information (e.g., high-definition (HD) maps, autonomous vehicle (AV) maps, etc.), gyro systems (e.g., IMU (Inertial Measurement Unit), INS (Inertial Navigation System), etc.), AI (Artificial Intelligence) chips, and AI processors, as well as one or more ECUs that control these devices. In addition, the driving assistance system unit 2030 transmits and receives various information via the communication module 2013 to realize the driving assistance function or the autonomous driving function.

[0305] The communication module 2013 can communicate with the microprocessor 2031 and components of the vehicle 2001 via the communication port. For example, the communication module 2013 transmits and receives data via the communication port 2033 to and from the drive unit 2002, steering unit 2003, accelerator pedal 2004, brake pedal 2005, shift lever 2006, front wheels 2007, rear wheels 2008, axle 2009, microprocessor 2031 and memory (ROM, RAM) 2032 in the electronic control unit 2010, and sensors 2021 to 29, which are provided in the vehicle 2001.

[0306] The communication module 2013 is a communication device that can be controlled by the microprocessor 2031 of the electronic control unit 2010 and can communicate with an external device. For example, it transmits and receives various information to and from the external device via wireless communication. The communication module 2013 may be located either inside or outside the electronic control unit 2010. The external device may be, for example, a base station, a mobile station, or the like.

[0307] The communication module 2013 may transmit at least one of signals from the above-mentioned various sensors 2021 to 2029 input to the electronic control unit 2010, information obtained based on the signals, and information based on input from the outside (user) obtained via the information service unit 2012 to an external device via wireless communication. The electronic control unit 2010, the various sensors 2021 to 2029, the information service unit 2012, etc. may be referred to as input units that accept input. For example, the PUSCH transmitted by the communication module 2013 may include information based on the above-mentioned input.

[0308] The communication module 2013 receives various information (traffic information, traffic signal information, vehicle distance information, etc.) transmitted from an external device and displays it on the information service unit 2012 provided in the vehicle 2001. The information service unit 2012 may also be called an output unit that outputs information (for example, outputs information to a device such as a display or speaker based on the PDSCH received by the communication module 2013 (or data / information decoded from the PDSCH)).

[0309] Furthermore, the communication module 2013 stores various information received from external devices in a memory 2032 that can be used by the microprocessor 2031. Based on the information stored in the memory 2032, the microprocessor 2031 may control the drive unit 2002, steering unit 2003, accelerator pedal 2004, brake pedal 2005, shift lever 2006, front wheels 2007, rear wheels 2008, axle 2009, sensors 2021 to 2029, and the like provided in the vehicle 2001.

[0310] <Meaning and Interpretation of Terms> As used in this disclosure, the terms "determining" and "determining" may encompass a wide variety of actions. "Determining" and "determining" may include, for example, judging, calculating, computing, processing, deriving, investigating, looking up, searching, inquiring (e.g., searching a table, database, or other data structure), ascertaining something that is considered to be a "judging" or "determining," and the like. "Determining" and "determining" may also include receiving (e.g., receiving information), transmitting (e.g., sending information), input, output, accessing (e.g., accessing data in memory), and the like that are considered to be a "judging" or "determining." Furthermore, "judgment" and "decision" can include regarding resolving, selecting, choosing, establishing, comparing, etc. as having been "judged" or "decided." In other words, "judgment" and "decision" can include regarding some action as having been "judged" or "decided." Furthermore, "judgment (decision)" can be interpreted as "assuming," "expecting," "considering," etc.

[0311] The terms "connected," "coupled," or any variation thereof, refer to any direct or indirect connection or coupling between two or more elements, and may include the presence of one or more intermediate elements between two elements that are "connected" or "coupled" to each other. The coupling or connection between elements may be physical, logical, or a combination thereof. For example, "connected" may be read as "access." As used in this disclosure, two elements may be considered to be "connected" or "coupled" to each other using one or more wires, cables, and / or printed electrical connections, as well as electromagnetic energy having wavelengths in the radio frequency range, microwave range, and optical (both visible and invisible) range, as some non-limiting and non-exhaustive examples.

[0312] <Reference Signal> A reference signal can also be abbreviated as RS (Reference Signal), and may also be called a pilot depending on the applicable standard.

[0313] <Meaning of "based on"> As used in this disclosure, the phrase "based on" does not mean "based only on," unless expressly stated otherwise. In other words, the phrase "based on" means both "based only on" and "based at least on."

[0314] "First," "Second" Any reference to an element using designations such as "first," "second," etc., used in this disclosure does not generally limit the quantity or order of those elements. These designations may be used in this disclosure as a convenient method of distinguishing between two or more elements. Thus, a reference to a first and a second element does not imply that only two elements may be employed or that the first element must precede the second element in some way.

[0315] <Means> The "means" in the configuration of each device above may be replaced with "section," "circuit," "device," etc.

[0316] Open Format: When the terms "include," "including," and variations thereof are used in this disclosure, these terms are intended to be inclusive, similar to the term "comprising." Furthermore, when the term "or" is used in this disclosure, it is not intended to be an exclusive or.

[0317] <Time Units such as TTI, Frequency Units such as RB, and Radio Frame Configuration> A radio frame may be composed of one or more frames in the time domain. Each of the one or more frames in the time domain may be called a subframe. A subframe may further be composed of one or more slots in the time domain. A subframe may have a fixed time length (e.g., 1 ms) that is independent of numerology.

[0318] Numerology may be a communication parameter that applies to the transmission and / or reception of a signal or channel, and may indicate, for example, at least one of subcarrier spacing (SCS), bandwidth, symbol length, cyclic prefix length, transmission time interval (TTI), number of symbols per TTI, radio frame structure, specific filtering operations performed by the transceiver in the frequency domain, and specific windowing operations performed by the transceiver in the time domain.

[0319] A slot may be composed of one or more symbols in the time domain (such as an Orthogonal Frequency Division Multiplexing (OFDM) symbol or a Single Carrier Frequency Division Multiple Access (SC-FDMA) symbol). A slot may be a time unit based on numerology.

[0320] A slot may include multiple minislots. Each minislot may consist of one or multiple symbols in the time domain. A minislot may also be called a subslot. A minislot may consist of fewer symbols than a slot. A PDSCH (or PUSCH) transmitted in a time unit larger than a minislot may be called PDSCH (or PUSCH) mapping type A. A PDSCH (or PUSCH) transmitted using a minislot may be called PDSCH (or PUSCH) mapping type B.

[0321] The radio frame, subframe, slot, minislot, and symbol all represent time units for transmitting signals, and may be referred to by other names corresponding to the radio frame, subframe, slot, minislot, and symbol.

[0322] For example, one subframe may be called a transmission time interval (TTI), multiple consecutive subframes may be called a TTI, or one slot or one minislot may be called a TTI. That is, at least one of the subframe and the TTI may be a subframe (1 ms) in existing LTE, a period shorter than 1 ms (for example, 1-13 symbols), or a period longer than 1 ms. Note that the unit representing the TTI may be called a slot, minislot, etc. instead of a subframe.

[0323] Here, TTI refers to, for example, the smallest time unit for scheduling in wireless communication. For example, in an LTE system, a base station performs scheduling to allocate radio resources (such as frequency bandwidth and transmission power that can be used by each user terminal) to each user terminal in TTI units. Note that the definition of TTI is not limited to this.

[0324] The TTI may be a transmission time unit for a channel-encoded data packet (transport block), a code block, a code word, etc., or may be a processing unit for scheduling, link adaptation, etc. When a TTI is given, the time interval (e.g., the number of symbols) to which a transport block, a code block, a code word, etc. is actually mapped may be shorter than the TTI.

[0325] When one slot or one minislot is called a TTI, one or more TTIs (i.e., one or more slots or one or more minislots) may be the minimum time unit for scheduling. Also, the number of slots (minislots) constituting the minimum time unit for scheduling may be controlled.

[0326] A TTI having a time length of 1 ms may be called a regular TTI (TTI in LTE Rel. 8-12), normal TTI, long TTI, regular subframe, normal subframe, long subframe, slot, etc. A TTI shorter than a regular TTI may be called a shortened TTI, short TTI, partial or fractional TTI, shortened subframe, short subframe, minislot, subslot, slot, etc.

[0327] In addition, a long TTI (e.g., a normal TTI, a subframe, etc.) may be interpreted as a TTI having a time length of more than 1 ms, and a short TTI (e.g., a shortened TTI, etc.) may be interpreted as a TTI having a TTI length shorter than the TTI length of a long TTI and greater than or equal to 1 ms.

[0328] A resource block (RB) is a resource allocation unit in the time domain and the frequency domain, and may include one or more consecutive subcarriers in the frequency domain. The number of subcarriers included in an RB may be the same regardless of numerology, for example, 12. The number of subcarriers included in an RB may be determined based on numerology.

[0329] The time domain of an RB may include one or more symbols and may have a length of one slot, one minislot, one subframe, or one TTI. One TTI, one subframe, etc. may each be composed of one or more resource blocks.

[0330] Note that one or more RBs may also be called a physical resource block (PRB), a sub-carrier group (SCG), a resource element group (REG), a PRB pair, an RB pair, etc.

[0331] Furthermore, a resource block may be composed of one or more resource elements (REs). For example, one RE may be a radio resource region of one subcarrier and one symbol.

[0332] A Bandwidth Part (BWP) (which may also be referred to as a fractional bandwidth) may represent a subset of contiguous common resource blocks (RBs) for a given numerology on a given carrier, where the common RBs may be identified by their index relative to a Common Reference Point of the carrier. PRBs may be defined in a BWP and numbered within the BWP.

[0333] The BWP may include a BWP for UL (UL BWP) and a BWP for DL ​​(DL BWP). One or more BWPs may be configured for a UE within one carrier.

[0334] At least one of the configured BWPs may be active, and the UE may not expect to transmit or receive a given signal / channel outside the active BWP. Note that the terms "cell," "carrier," etc. in this disclosure may be read as "BWP."

[0335] The above-described structures of radio frames, subframes, slots, minislots, symbols, etc. are merely examples, and various changes may be made to the number of subframes included in a radio frame, the number of slots per subframe or radio frame, the number of minislots included in a slot, the number of symbols and RBs included in a slot or minislot, the number of subcarriers included in an RB, the number of symbols in a TTI, the symbol length, the cyclic prefix (CP) length, etc.

[0336] <Maximum Transmit Power> The "maximum transmit power" in the present disclosure may refer to the maximum value of transmit power, the nominal UE maximum transmit power, or the rated UE maximum transmit power.

[0337] Articles In this disclosure, where articles are added by translation, such as a, an, and the in English, the disclosure may include that the nouns following these articles are in the plural form.

[0338] <"Different"> In the present disclosure, the term "A and B are different" may mean "A and B are different from each other." Note that the term may also mean "A and B are each different from C." Terms such as "separate" and "coupled" may also be interpreted in the same way as "different."

[0339] One aspect of the present disclosure is useful in wireless communication systems.

[0340] 10 Base station 20 Device 101, 202 Transmitter 102, 201 Receiver 103, 203 Controller

Claims

1. A device with lower complexity than an NB-IoT (Narrow Band Internet of Things) device, comprising: a receiving unit that receives downlink data from a network; and a control unit that generates a response signal indicating success or failure of decoding of the downlink data.

2. The device according to claim 1, wherein the device does not hold a soft buffer for downlink data decoding.

3. The device according to claim 1, wherein the receiving unit receives binary information indicating whether the transmission of the downlink data is a new transmission or a retransmission from the network, and the control unit determines whether the transmission of the downlink data is a new transmission or a retransmission based on the binary information.

4. The device according to claim 1, further comprising a transmitting unit that transmits the response signal to the network at a timing when a first period of time has elapsed since the reception of the downlink data.

5. The device according to claim 1, further comprising a transmitting unit that transmits the response signal to the network after a first period of time has elapsed since the reception of the downlink data and before a second period of time has elapsed since the reception of the downlink data.

6. A communication method in which a device with lower complexity than an NB-IoT (Narrow Band Internet of Things) device receives downlink data from a network and generates a response signal indicating success or failure of decoding of the downlink data.

Images