Apparatus and communication method

Abstract

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

Description

Technical Field

[0001] This disclosure relates to equipment and communication methods. Background Technology

[0002] In NR (New Radio) (also known as "5G"), which is the successor system to LTE (Long Term Evolution), technologies are being researched to meet requirements such as high-capacity systems, high-speed data transmission, low latency, simultaneous connection of a large number of terminals, low cost, and power saving (see, for example, Non-Patent Literature 1).

[0003] Furthermore, in 3GPP (registered trademark) version 18 (Rel-18), Ambient Internet of Things (A-IoT) is being studied (see, for example, non-patent document 2). In Ambient Internet of Things, the target is a device with a structure that is extremely simple and designed for low-end IoT applications that operate with minimal power consumption.

[0004] Furthermore, in 3GPP Rel-19 or Rel-20 or later, which are extended for use in environmental IoT, it is possible to study ARQ processes that may include HARQ (hybrid automatic repeat request) as research projects for environmental IoT (e.g., see non-patent documents 3 and 4).

[0005] Existing technical documents

[0006] Non-patent literature

[0007] Non-patent document 1: 3GPP TS 38.300 V17.3.0 (2022-12)

[0008] Non-patent literature 2: "Revised SID on Ambient IoT", RP-232404, 3GPP TSG RANMeeting #101, September 2023

[0009] Non-patent literature 3: "Summary for RAN Rel-19 Package: RAN1 / 2 / 3-led", RP-232745, 3GPP RAN #102, December 2023

[0010] Non-patent literature 4: "Study on solutions for Ambient IoT (Internet of Things) in NR", RP-234058, 3GPP TSG RAN Meeting #102, December 2023

[0011] Non-patent document 5: 3GPP TS 36.211 V16.8.0 (2023-09)

[0012] Non-patent document 6: 3GPP TR 38.848 V1.0.0 (2023-09) Summary of the Invention

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

[0014] Environmental IoT devices are lower-end than NB-IoT devices, and the more complex ARQ process can complicate the operation of such devices, thus requiring the specification of appropriate ARQ operations.

[0015] This disclosure provides a device and a communication method capable of performing ARQ operations appropriately.

[0016] One aspect of this disclosure relates to a device with lower complexity than an NB-IoT (Narrow Band Internet of Things) device, the device comprising: a receiving unit for receiving downlink data from a network; and a control unit for generating an acknowledgment signal indicating success or failure of decoding the downlink data. Attached Figure Description

[0017] Figure 1 This is a diagram illustrating an example of a wireless communication system according to an embodiment of the present disclosure.

[0018] Figure 2 This is a diagram illustrating Topology 1.

[0019] Figure 3 This is a diagram illustrating topology 2.

[0020] Figure 4 This is a diagram illustrating topology 3 in DL-assisted programming.

[0021] Figure 5 This is a diagram illustrating topology 3 in UL-assisted programming.

[0022] Figure 6 This is a diagram illustrating topology 4.

[0023] Figure 7 This is a diagram illustrating an example of the interaction between a network and an A-IoT device according to an embodiment of this disclosure.

[0024] Figure 8 This is a diagram illustrating an example of the interaction between a network and an A-IoT device according to an embodiment of this disclosure.

[0025] Figure 9 This is a diagram illustrating an example of DL data reception and ACK / NACK feedback transmission according to an embodiment of this disclosure.

[0026] Figure 10 This is a diagram illustrating an example of DL data reception and ACK / NACK feedback transmission according to an embodiment of this disclosure.

[0027] Figure 11 This is a diagram illustrating an example of DL data reception and ACK / NACK feedback transmission according to an embodiment of this disclosure.

[0028] Figure 12 This is a diagram illustrating an operational example of the device involved in an embodiment of this disclosure.

[0029] Figure 13 This is a diagram illustrating an example of the interaction between a network and an A-IoT device according to an embodiment of this disclosure.

[0030] Figure 14 This is a diagram illustrating an example of the interaction between a network and an A-IoT device according to an embodiment of this disclosure.

[0031] Figure 15 This is a diagram illustrating an example of UL data transmission and ACK / NACK feedback reception as described in an embodiment of this disclosure.

[0032] Figure 16 This is a diagram illustrating an example of UL data transmission and ACK / NACK feedback reception as described in an embodiment of this disclosure.

[0033] Figure 17 This is a diagram illustrating an operational example of the device involved in an embodiment of this disclosure.

[0034] Figure 18 This is a block diagram illustrating an example of the structure of a base station according to an embodiment of the present disclosure.

[0035] Figure 19 This is a block diagram illustrating an example of the structure of a device according to an embodiment of the present disclosure.

[0036] Figure 20This is a diagram illustrating an example of the hardware structure of a base station and device according to an embodiment of this disclosure.

[0037] Figure 21 This is a diagram illustrating an example of the structure of a vehicle according to an embodiment of the present disclosure. Detailed Implementation

[0038] Hereinafter, an embodiment of the present disclosure will be described with reference to the accompanying drawings. Furthermore, the embodiment described below is an example, and the application of the present disclosure is not limited to the following embodiment.

[0039] In operating the wireless communication system according to the embodiments of this disclosure, existing technology is appropriately used. This existing technology includes, for example, existing LTE or NR, but is not limited to, existing LTE or NR. Furthermore, the term "LTE" as used in this specification is assumed to have a broad meaning encompassing LTE-Advanced and subsequent methods, unless otherwise specified.

[0040] Furthermore, in the embodiments of this 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 ease of description; signals, functions, etc., that are the same as these can also be referred to by other names. In addition, the above 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 explicitly stated as "NR-".

[0041] Furthermore, in the embodiments of this disclosure, the duplex mode can be either TDD (Time Division Duplex) or FDD (Frequency Division Duplex), or other modes (e.g., Flexible Duplex).

[0042] Furthermore, in the embodiments of this disclosure, the so-called "configured" wireless parameters can be either specific values ​​that are pre-configured or wireless parameters that are notified from base stations, devices, etc.

[0043] (Implementation Method)

[0044] <Wireless Communication Systems>

[0045] Figure 1 This is a diagram illustrating an example of a wireless communication system according to an embodiment of this disclosure. (See diagram for example.) Figure 1 As shown, the wireless communication system 1 includes a base station 10 and a device 20. Figure 1 In this example, one base station 10 and one device 20 are shown, but this is just one example; multiple base stations and devices may exist. Device 20 can also be referred to as a terminal (UE: User Equipment), or it can be an environmental IoT device with lower complexity than an NB-IoT device. Environmental IoT devices can also be called environmental IoT terminals, environmental IoT UEs, etc.

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

[0047] Base station 10 sends control information, setting information, data, and other DL signals to device 20 via DL (Downlink). Base station 10 receives control information, information related to the processing capabilities of device 20 (capability (information) or device capability (information); for example, capability, device capability, A-IoT capability, A-IoT device capability, etc.), data, and other UL signals from device 20 via UP (Uplink).

[0048] The channels used in transmitting DL signals include, for example, data channels and control channels. For instance, 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, base station 10 uses PDCCH to transmit control information and PDSCH to transmit DL data signals to device 20. Furthermore, PDSCH is an example of a downlink shared channel or data channel, and PDCCH is an example of a downlink control channel. PDCCH can also be rewritten to transmit downlink control information (DCI), control information, etc., within the PDCCH.

[0049] As will be described later, wireless communication systems may also include intermediate nodes, assisting nodes, and / or terminals (UEs) (see <Equipment Types and Topologies> below). Additionally, hereinafter, "and / or" will sometimes be simply referred to as " / ".

[0050] Device 20 is a communication device with wireless communication capabilities, as described above, and may also be an environmental IoT device (e.g., a sensor).

[0051] Device 20 receives control signals, setting information, data and other DL signals from base station 10 via DL, and sends control signals, device 20 capability information, data and other UL signals to base station 10 via UL.

[0052] The channels used in transmitting UL signals include, for example, data channels and control channels. For instance, a data channel may include a Physical Uplink Shared Channel (PUSCH), and a control channel may include a Physical Uplink Control Channel (PUCCH). For example, device 20 uses PUCCH to transmit control information and PUSCH to transmit UL data signals. Furthermore, PUSCH is an example of an uplink shared channel or a data channel, and PUCCH is an example of an uplink control channel. Additionally, PUSCH or PUCCH can be rewritten to transmit uplink control information (UCI), control information, etc., within PUSCH or PUCCH.

[0053] <Environmental IoT>

[0054] In Rel-18, research on environmental IoT that is lower-end than existing NB-IoT (e.g., see section 10 of Non-Patent Document 5) is permitted (e.g., see Non-Patent Document 2). In environmental IoT, ultra-low power consumption and ultra-low complexity devices are targeted.

[0055] In environmental IoT, for example, for associated use cases, the following import scenarios and characteristics can be studied.

[0056] Indoor or outdoor environment

[0057] • Base station category, for example, configuration based on macro / micro / pecimen cells

[0058] • The connectivity involved, such as whether any node in the topology—e.g., a base station, a user terminal (UE), a relay station, or a repeater—communicates with environmental IoT devices.

[0059] • Is the duplex mode TDD or FDD? Is the frequency band licensed or unlicensed?

[0060] • Coexistence with UEs and network equipment in frequency bands oriented towards existing 3GPP technologies

[0061] • Concept of services originating from / incoming from the device

[0062] Based on the aforementioned import scenarios and characteristics, for example, the following RAN design goals can be planned and formulated.

[0063] Power consumption

[0064] Complexity

[0065] • Coverage

[0066] Data rate

[0067] • Positioning accuracy

[0068] Based on import scenarios suitable for associated use cases, compare and evaluate the feasibility of achieving the design goals, and determine the supported functions.

[0069] <Device Type and Topology>

[0070] Based on the results of the research project, TR 38.848 (Non-Patent Document 6) is licensed. In TR 38.848, environmental IoT devices of the following category are investigated.

[0071] Device A: Device A does not have an energy storage device, nor does it have independent signal generation and signal amplification functions, and it performs backscattering transmission.

[0072] Device B: Device B has a power storage device but does not have independent signal generation capabilities; it performs backscatter transmission. Device B uses the stored power to amplify the reflected signal.

[0073] Device C: Device C has a power storage device, an independent signal generation function, and an active RF (radio frequency) component for transmission.

[0074] In addition, regarding the complexity of device A, consider the level of RFID (Radio Frequency Identification).

[0075] In TR 38.848, in the context of IoT networks, topologies 1-4 as described below are defined.

[0076] Figure 2 This is a diagram illustrating Topology 1. For example... Figure 2 As shown, Topology 1 is the structure for communication between the base station (BS) and environmental IoT devices. The environmental IoT devices directly perform bidirectional communication with the base station.

[0077] Figure 3 This is a diagram illustrating Topology 2. For example... Figure 3As shown, Topology 2 is a structure in which the base station and the environmental IoT device communicate via an intermediate node. The environmental IoT device performs bidirectional communication with the intermediate node configured between the base station and the environmental IoT device. The intermediate node can be, for example, a relay station, an IAB (Integrated Access and Backhaul) node, a UE, a repeater, etc.

[0078] Figure 4 This is a diagram illustrating topology 3 in DL-assisted programming. For example... Figure 4 As shown, Topology 3 is a structure that includes communication between the base station and the assistant node, communication between the assistant node and the environmental IoT device, and communication between the environmental IoT device and the base station.

[0079] The auxiliary node supports deep communication. For example, such as Figure 4 As shown, the auxiliary node receives the DL signal from the base station and sends the received DL signal to the environmental IoT device. For UL communication, the environmental IoT device sends the UL signal directly to the base station.

[0080] Figure 5 This is a diagram illustrating topology 3 in UL-assisted implementation. For example... Figure 5 As shown, Topology 3 is a structure that includes communication between the base station and auxiliary nodes, communication between auxiliary nodes and environmental IoT devices, and communication between environmental IoT devices and the base station.

[0081] The auxiliary node supports UL communication. For example, such as... Figure 5 As shown, the auxiliary node receives the UL signal from the environmental IoT device and sends the received UL signal to the base station. For DL ​​communication, the environmental IoT device receives the DL signal directly from the base station.

[0082] Figure 4 as well as Figure 5 The auxiliary nodes shown can also be relay stations, IAB nodes, UEs, repeaters, etc.

[0083] Figure 6 This diagram illustrates Topology 4. Topology 4 is the structure for communication between the UE and the environmental IoT devices. The environmental IoT devices and the UE perform bidirectional communication. The communication involved in Topology 4 can also be understood as side-link (SL) communication.

[0084] In addition, in the topologies 1 to 4 described above, environmental IoT devices can also be provided with carriers from other nodes inside or outside the topology (see Section 4.2.1 of Non-Patent Document 6).

[0085] In the wireless communication system 1 (wireless communication network), in addition to device 20, it may also include a base station, auxiliary nodes, intermediate nodes, and / or terminals (UEs of topology 4). In this specification, base station, auxiliary nodes, intermediate nodes, and terminals may also be rewritten as network or (network) node. Furthermore, A-IoT devices are sometimes simply referred to as A-IoT.

[0086] As mentioned above, with the advent of 3GPP Rel-19 or Rel-20, it may be possible to discuss (H)ARQ as a physical layer procedure. Therefore, the current HARQ operation will be explained below.

[0087] <HARQ>

[0088] The following section explains HARQ operations in current wireless communication systems (HARQ operations in NB-IoT / NR).

[0089] In both DL and UL data transmission, the MAC (Medium Access Control) entity of the terminal containing the NB-IoT device can maintain multiple simultaneous HARQ processes.

[0090] [DL]

[0091] The following explains the HARQ operations related to DL.

[0092] In Deep Learning (DL), the DL scheduling DCI includes the HARQ process index and the NDI (New Data Indicator). The HARQ process index can also be called the HARQ process number, HARQ process ID, HARQ process identifier, or HARQ process identification information, representing information used to identify the HARQ process. The NDI indicates whether the transmitted data is new data (based on newly transmitted data) or retransmitted data (based on retransmitted data).

[0093] When a HARQ process generates a DL (Data Stream) transmission, if the NDI (Network Component Index) is toggled compared to a previously transmitted value (meaning it differs from the previously transmitted value), the DL transmission is considered a new transmission. In this case, the MAC entity attempts to decode the received data. Conversely, if the NDI is not toggled compared to a previously transmitted value (meaning it is the same as the previously transmitted value), 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.

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

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

[0096] [UL]

[0097] Next, the HARQ operation related to UL will be explained.

[0098] In UL, the UL scheduling DCI includes the HARQ process index and NDI.

[0099] Upon receiving UL scheduling permission, for a given HARQ process, if the NDI is toggled compared to a previously transmitted value, and the transmitted MAC PDU (Protocol Data Unit) is acquired (i.e., if new data exists), a new transmission is triggered, and the MAC PDU is stored in the HARQ buffer. Conversely, if no MAC PDU is acquired (i.e., if new data does not exist), the HARQ buffer is flushed. Conversely, if the NDI is not toggled compared to a previously transmitted value, a retransmission is triggered.

[0100] [Report on HARQ ACK / NACK feedback from the terminal to the network for DL ​​reception]

[0101] The time and frequency resources used for HARQ ACK / NACK feedback are provided over the network. Alternatively, the time and frequency resources can be rewritten as time-domain resources and frequency-domain resources, respectively.

[0102] In NR, HARQ ACK / NACK feedback is sent via PUCCH. The time slot offset between PDSCH and HARQ ACK / NACK feedback is provided via the network as information representing time resources, and the starting PRB (Physical Resource Block) and number of PRBs of PUCCH are provided via the network as information representing frequency resources. The PDSCH processing time and the minimum (shortest) time gap between PDSCH and HARQ ACK / NACK feedback are defined in the specification. The terminal provides valid HARQ ACK / NACK feedback for PDSCH reception only if the PUCCH carrying HARQ ACK / NACK feedback begins after the minimum time gap required from the end of the PDSCH.

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

[0104] <Analysis>

[0105] Regarding HARQ operations for A-IoT, the aforementioned HARQ operations for NB-IoT / NR can serve as a starting point. On the other hand, assuming that A-IoT devices have an extremely simple structure, the following points (1) to (4) can be considered.

[0106] (1) Can A-IoT devices maintain multiple simultaneous HARQ processes or can they only maintain one HARQ process?

[0107] (2) Does the A-IoT device support a soft buffer for DL ​​data decoding?

[0108] For example, in the absence of a soft buffer in A-IoT devices, each DL transmission is treated as a new transmission. Therefore, in order for the network to identify whether the DL data has been decoded correctly, the A-IoT device simply reports ACK / NACK to the network.

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

[0110] (4) Does the A-IoT device support the buffer zone used by UL?

[0111] For example, a buffer is needed to support the retransmission of UL data.

[0112] However, current research on control and operation related to (H)ARQ in A-IoT is insufficient. Therefore, the following is a proposal for properly performing ARQ operation.

[0113] Specifically, this proposal includes Proposal 1 and Proposal 2, wherein Proposal 1 includes Proposal 1-1, Proposal 1-2 and Proposal 1-3, and Proposal 2 includes Proposal 2-1, Proposal 2-2 and Proposal 2-3.

[0114] (Proposal 1: Proposal related to DL reception in A-IoT)

[0115] Proposal 1-1: A proposal regarding the support for multiple concurrent HARQ processes.

[0116] Proposals 1-2: Proposals related to the presence or absence of support for soft buffers

[0117] Proposals 1-3: Proposals related to ACK / NACK reporting for DL ​​reception (DL data)

[0118] (Proposal 2: Proposal related to UL transmission of A-IoT)

[0119] Proposal 2-1: A proposal regarding the potential association with support for multiple concurrent HARQ processes.

[0120] Proposal 2-2: Proposal related to ACK / NACK notifications for UL reception (UL data)

[0121] Proposals 2-3: Proposals related to the reception of ACK / NACK for UL reception (UL data)

[0122] In addition, some or all of the proposals described below may be applied to all A-IoT device types (e.g., all of the devices A, B, C, etc. mentioned above) or to a portion of A-IoT device types (e.g., only specific A-IoT device types).

[0123] Furthermore, the different options in the proposals described below can also be applied to different types of A-IoT devices.

[0124] Furthermore, the proposals described below may be applied to all topologies (e.g., all of the topologies 1, 2, 3, 4, etc. mentioned above) or to a portion of the topologies (e.g., only specific topologies).

[0125] Furthermore, some or all of the different options in the proposals described below can also 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 can also be sent from the base station (BS) / intermediate node / auxiliary node / terminal (UE) to the A-IoT device, and information from the A-IoT device to the network can also be sent from the A-IoT device to the base station (BS) / intermediate node / auxiliary node / terminal (UE).

[0126] Furthermore, different types of A-IoT devices may have different device capabilities as described below.

[0127] Furthermore, some or all of the proposals described below may also be applied only if the corresponding capability is supported by an A-IoT device and / or if the corresponding function is activated by a network.

[0128] Furthermore, the matters described in Proposal 1-1, Proposal 1-2, Proposal 1-3, Proposal 2-1, Proposal 2-2, and Proposal 2-3 can be appropriately combined as long as they do not contradict each other.

[0129] In addition, the word "provide" can also be rewritten as "notify".

[0130] In addition, the word "report" can also be rewritten as "send".

[0131] <Proposal 1-1>

[0132] The following is an explanation of the above viewpoint (1) and the proposal (Proposal 1-1) regarding whether or not it is related to the support for multiple simultaneous HARQ processes based on A-IoT devices.

[0133] A-IoT devices can also generate an "ACK" feedback (or simply "ACK") if they decode DL data from the network correctly, appropriately, normally, or successfully, or if the decoding of DL data from the network is successful. Furthermore, A-IoT devices can also generate a "NACK" feedback (or simply "NACK") if they do not decode DL data from the network correctly, appropriately, normally, or successfully, or if the decoding of DL data from the network is unsuccessful.

[0134] A-IoT devices can also report the generated ACK / NACK feedback to the network. For example, a 1-bit field for ACK / NACK feedback can be used for this reporting. For instance, a bit value of "0" in this field could represent "NACK," and a bit value of "1" could represent "ACK." Alternatively, the mapping could be reversed, where a bit value of "0" in this field represents "ACK," and a bit value of "1" represents "NACK."

[0135] Here, depending on whether multiple parallel, concurrent, or simultaneous HARQ processes are supported (hereinafter referred to as simultaneous HARQ processes), that is, whether parallel, concurrent, or simultaneous DL data (processing / receiving) is supported, the HARQ operation may need to be different. In other words, an A-IoT device may or may not support multiple simultaneous HARQ processes (supporting only a single HARQ process (single DL data processing)), and depending on whether this support is available, the HARQ operation may need to be changed.

[0136] [Option 1]

[0137] The following is an explanation of the scenario where A-IoT devices support multiple simultaneous HARQ processes, as option 1.

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

[0139] An A-IoT device can also receive other DL data #j from a different HARQ process #j after receiving DL data #i from HARQ process #i (HARQ process number i) and before sending an ACK / NACK for DL ​​data #i from HARQ process #i. In other words, an A-IoT device can also send an ACK / NACK for DL ​​data #i from HARQ process #i after receiving DL data #i from HARQ process #i and other DL data #j from HARQ process #j that is different from HARQ process #i.

[0140] In addition, A-IoT devices can also send a single ACK / NACK response that combines ACK / NACK responses for multiple received DL data (ACK / NACK bundling), or they can be sent by combining resources.

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

[0142] One or more of the restrictions shown below can also be defined in the specification.

[0143] For example, regarding the limitation, it could be that if an A-IoT device receives DL data #i from HARQ process #i and then receives DL data #j from HARQ process #j, it could send DL data #j from HARQ process #j after sending an ACK / NACK for DL ​​data #i from HARQ process #i, or simply send DL data #j.

[0144] As another example, regarding the limitation, it could also be about the same HARQ process, where it's not envisioned that the A-IoT device receives additional DL data (a new transmission of new DL data or a retransmission of previous DL data) before sending an ACK / NACK for previous DL data, or that it doesn't receive that additional DL data. In other words, regarding the limitation, it could also be about the same HARQ process, where it's envisioned that the A-IoT device receives additional DL data after sending an ACK / NACK for previous DL data, or receives that additional DL data.

[0145] Figure 7This diagram illustrates an example of the interaction between the base station / auxiliary node / intermediate node and the A-IoT device involved in Option 1. (See diagram below.) Figure 7 As shown, the base station and other networks send 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 in the following order. Furthermore, as... Figure 7 As shown, the A-IoT device sends the ACK / NACK for DL ​​data #1, ACK / NACK for DL ​​data #2, ..., ACK / NACK for DL ​​data #X to the base station and other networks in the order of success or failure of decoding.

[0146] Option 1 enables the HARQ operation of A-IoT devices to be identical to current wireless communication systems, thus mitigating the impact on specifications.

[0147] [Option 2]

[0148] The following is an explanation of option 2, regarding the situation where A-IoT devices do not support multiple simultaneous HARQ processes.

[0149] A-IoT devices can also support or maintain a single HARQ process (in other words, they can process a single DL data (receive) at a time, or they can process multiple DL data (receive) in a non-parallel, parallel, or simultaneous manner).

[0150] One or more of the restrictions shown below can also be defined in the specification.

[0151] For example, regarding limitations, it could also be assumed that A-IoT devices do not receive other DL data (new transmission of new DL data or retransmission of previous DL data) before sending an ACK / NACK for previous DL data, or they do not receive such other DL data. In other words, regarding limitations, it could also be assumed that A-IoT devices receive other DL data after sending an ACK / NACK for previous DL data, or they receive such other DL data.

[0152] As another example, regarding limitations, it could also be assumed that the A-IoT device receives a new transmission of new DL data before sending an ACK for previous DL data, or that it does not receive the new transmission. In other words, regarding limitations, it could also be assumed that the A-IoT device receives a new transmission of new DL data after sending an ACK for previous DL data, or that it receives the new transmission.

[0153] Figure 8 This diagram illustrates an example of the interaction between the base station / auxiliary node / intermediate node and the A-IoT device involved in Option 2. (See diagram below.) Figure 8As shown, if a base station or other network sends DL data to an A-IoT device, the A-IoT device sends an ACK / NACK to the base station or other network for the DL data based on whether the decoding of the DL data was successful or not, and then repeats the same operation.

[0154] Option 2 enables HARQ operation of A-IoT devices to be adapted to the simplified structure of A-IoT devices.

[0155] <Proposal 1-2>

[0156] Next, regarding the above viewpoint (2), we will explain the proposals (Proposals 1-2) related to the support for soft buffers based on A-IoT devices.

[0157] Depending on whether soft buffers are supported for DL ​​data decoding, the HARQ operation may need to be different. In other words, A-IoT devices may or may not support soft buffers, and depending on whether this support is present, the HARQ operation may need to be changed.

[0158] [Alt.1]

[0159] The following section, as Alt.1, explains the situation where A-IoT devices support soft buffers.

[0160] As mentioned above, similar to NB-IoT / NR, A-IoT devices can also support or maintain soft buffers. For example, A-IoT devices can maintain one soft buffer per HARQ process in Option 1 of Proposal 1-1, or one soft buffer in Option 2 of Proposal 1-1.

[0161] NDI can also be provided to A-IoT devices from the network when the A-IoT device receives DL data from the network. NDI can also be provided via DCI or combined with DL data (e.g., via a data channel). NDI indicates whether the received DL data is based on newly transmitted data or retransmitted data.

[0162] When the DL data is newly transmitted, the A-IoT device decodes the received DL data. On the other hand, when the DL data is retransmitted, the A-IoT device combines (synthesizes) the received DL data with the currently stored or saved DL data in the soft buffer (either the corresponding soft buffer among multiple soft buffers or a single soft buffer), and then decodes the combined DL data.

[0163] If an A-IoT device does not correctly decode the received DL data, it will store or save the received DL data in a soft buffer.

[0164] In Option 1 of Proposal 1-1, when the A-IoT device receives DL data from the network, the HARQ process index can also be provided to the A-IoT device along with NDI from the network. The HARQ process index can also be provided via DCI or combined with DL data (e.g., via a data channel). The size of the HARQ process index field is related to the number (e.g., X) of simultaneous HARQ processes supported or maintained by the A-IoT device. For example, the size of the HARQ process index field could be 1 bit when X is 2, 2 bits when X is greater than 2 and less than 4, 3 bits when X is greater than 4 and less than 8, and so on.

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

[0166] [Alt.2]

[0167] The following section, as Alt.2, explains the situation where A-IoT devices do not support soft buffers.

[0168] As mentioned above, A-IoT devices may also not support or maintain soft buffers. In this case, each DL data can also be considered as newly transmitted data. Furthermore, in this case, the HARQ process index and / or NDI do not need to be provided to the A-IoT device from the network.

[0169] Alt.2 can also be applied only to option 2 in proposal 1-1. This is because A-IoT devices may not have a buffer for supporting simultaneous DL data processing.

[0170] According to Alt.2, HARQ operation of A-IoT devices can be adapted to the simple structure of A-IoT devices.

[0171] Furthermore, when NDI is provided (e.g., in the case of Alt.1), NDI can be interpreted either in the same way as the current wireless communication system or differently from the current wireless communication system, as follows.

[0172] Option 1

[0173] The interpretation of NDI can be the same as or identical to that of NB-IoT / NR. Specifically, if the NDI is flipped compared to a previously transmitted value (meaning it differs from a previously transmitted value), the A-IoT device can treat the DL transmission as a new transmission. Conversely, if the NDI is not flipped compared to a previously transmitted value (meaning it is the same as a previously transmitted value), the A-IoT device can treat the DL transmission as a retransmission. In option 1, the A-IoT device needs to store the NDI value.

[0174] Option 1 enables the HARQ operation of A-IoT devices to be identical to current wireless communication systems, thus mitigating the impact on specifications.

[0175] Option 2

[0176] NDI can also take the value indicating that the DL transmission is a new transmission (first value) or the value indicating that the DL transmission is a retransmission (second value). The first and second values ​​can also be defined in the specification. For example, NDI can also take two values. For instance, when NDI is set to bit value "0", the A-IoT device can also treat the DL transmission as a new transmission. On the other hand, when NDI is set to bit value "1", the A-IoT device can also treat the DL transmission as a retransmission. Alternatively, it can be the opposite mapping. That is, when NDI is set to bit value "1", the A-IoT device can also treat the DL transmission as a new transmission, and when NDI is set to bit value "0", the A-IoT device can also treat the DL transmission as a retransmission. In option 2, the A-IoT device does not need to store the NDI value.

[0177] Option 2 enables HARQ operation of A-IoT devices to adapt to the simple structure of A-IoT devices and achieves more reliable HARQ operation.

[0178] <Proposal 1-3>

[0179] Next, regarding the above viewpoint (3), we will explain the proposals (Proposals 1-3) related to the ACK / NACK reports received by DL based on A-IoT devices.

[0180] For example, information related to the following resources can be provided to A-IoT devices from the network, defined in the specification, or reported by the A-IoT devices to the network as a device capability related to the transmission of ACK / NACK feedback for DL ​​reception. In the case of information being provided to A-IoT devices from the network, such information can also be included in DL data scheduling information (e.g., DCI).

[0181] Resource-related information may also include the time resources used for sending ACK / NACK feedback (information indicating the time resources used for sending ACK / NACK feedback). For example, ... Figure 9 As shown, the information representing the time resources used for sending ACK / NACK feedback can also be the time offset between the reception of DL data (e.g., the end or end) and the transmission of ACK / NACK feedback. A-IoT devices can also send ACK / NACK feedback at a timed interval after the time offset from the reception of DL data.

[0182] 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.

[0183] The minimum (shortest) time offset can also be defined in the specification or reported to the network by the A-IoT device as a device capability. The minimum (shortest) time offset can also be understood as the time required for the A-IoT device to decode or process the data. The A-IoT device may not be expected to be notified of a (shorter) time offset smaller than the minimum (shortest) time offset (or a time offset below the minimum (shortest) time offset) (or, the A-IoT device may not be notified of a (shorter) time offset smaller than the minimum (shortest) time offset (or a time offset below the minimum (shortest) time offset)). In other words, the A-IoT device may also be expected to be notified of a time offset greater than the minimum (shortest) time offset (or a (longer) time offset greater than the minimum (shortest) time offset) (or, the A-IoT device may also be notified of a time offset greater than the minimum (shortest) time offset (or a (longer) time offset greater than the minimum (shortest) time offset)).

[0184] When the time offset is defined in the specification, for example, an A-IoT device may also send ACK / NACK feedback to the network X milliseconds / slots / symbols after the end of DL data reception.

[0185] The time resources (also known as candidate resources) available for sending ACK / NACK feedback can be predefined in the specification or through the network. One or more of the predefined candidate resources can also be notified to the A-IoT device by the network. For example, candidate resources can also be set / defined by the network through higher-level signaling such as RRC, and one or more of the candidate resources can also be notified by the network through DCI.

[0186] • Indicates changes in information about time resources 1

[0187] Considering that A-IoT devices may not support or maintain DL / UL synchronization, the period or time interval (duration) for sending ACK / NACK feedback can be defined in the specification, provided by the network, or reported to the network by the A-IoT device as a device capability. In this case, the A-IoT device may also be able to (and may be allowed to) send ACK / NACK feedback within this time interval.

[0188] For example, such as Figure 10 As shown, the time offset between the DL data reception (e.g., the end or end) and the start (moment) of the time interval (time offset #1 in the figure) can be defined in the specification, provided by the network, or reported to the network by the A-IoT device as a device capability.

[0189] In addition, for example, such as Figure 10 As shown, the time offset between the DL data reception (e.g., the end or end) and the end of the time interval (time point) (the time offset shown in the figure #2) can be defined in the specification, provided by the network, or reported to the network by the A-IoT device as a device capability.

[0190] In addition, for example, the length of the time interval ( Figure 10 The time offset #2 (the difference between time offset #1) shown can be defined in the specification, provided by the network, or reported to the network by A-IoT devices as a device capability.

[0191] A-IoT devices can also send ACK / NACK feedback after a time offset #1 from the start of receiving DL data and before a time offset #2 from the start of receiving DL data.

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

[0193] • Indicates changes in information about time resources 2

[0194] like Figure 11 As shown, if an A-IoT device receives a signal from the network that triggers ACK / NACK feedback (also called an ACK / NACK trigger signal, etc.), it can also send ACK / NACK feedback (e.g., as a backscatter transmission) back to the network. Additionally, Figure 11The “Time separation for DL ​​data processing” shown can correspond to the minimum (shortest) time offset mentioned above.

[0195] In addition, the information related to resources may also include frequency resources used for transmitting ACK / NACK feedback (information on frequency resources used for transmitting ACK / NACK feedback).

[0196] The granularity of frequency resources can be subcarriers / resource blocks, or any frequency unit defined for A-IoT.

[0197] A-IoT devices can also send ACK / NACK feedback in one or more subcarriers / resource blocks / other frequency units.

[0198] When ACK / NACK feedback is transmitted across multiple subcarriers / resource blocks / other frequency units, the start position and length (i.e., width) (or start and end positions) of the frequency resources can be defined in the specification or provided to the A-IoT device by the network.

[0199] For example, the frequency resources (also known as candidate resources) that can be used in the transmission of ACK / NACK feedback can be predefined in the specification or through the network. One or more of the predefined candidate resources can also be notified to the A-IoT device by the network. For example, candidate resources can also be set / defined by the network through higher-level signaling such as RRC, and one or more of the candidate resources can also be notified by the network through DCI.

[0200] Furthermore, for example, the relationship between the frequency resources used for transmitting (ACK / NACK feedback) and the frequency resources used for the data channel can be defined in the specification or notified to A-IoT devices by the network.

[0201] According to Proposals 1-3, A-IoT devices can appropriately report ACK / NACK to the network based on resource-related information, that is, using time resources and / or frequency resources represented by resource-related information.

[0202] <Operational Examples Related to Proposal 1>

[0203] Next, refer to Figure 12 The operation example of device 20 is explained.

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

[0205] In step S12, device 20 generates an acknowledgment signal indicating whether the decoding of the received downlink data was successful or failed.

[0206] Steps S11 and S12 can also be performed according to proposals 1-1 to 1-3, which include the above options and Alt.

[0207] Based on Proposal 1, ARQ operations can be performed appropriately on DL.

[0208] <Proposal 2-1>

[0209] Next, regarding the above points (1) and (4), we will explain the proposal (Proposal 2-1) on whether or not it is related to the support for multiple simultaneous HARQ processes based on A-IoT devices.

[0210] A-IoT devices send UL data to the network. Depending on whether multiple parallel, concurrent, or simultaneous HARQ processes are supported (hereinafter referred to as simultaneous HARQ processes), i.e., whether parallel, concurrent, or simultaneous UL data (sending / processing) is supported, the HARQ operation may need to be different. In other words, an A-IoT device may or may not support multiple simultaneous HARQ processes (supporting only a single HARQ process (single UL data processing)), and the HARQ operation may need to be modified depending on whether this support is available.

[0211] [Option 1]

[0212] The following is an explanation of the scenario where A-IoT devices support multiple simultaneous HARQ processes, as option 1.

[0213] As mentioned above, A-IoT devices can also support or maintain multiple (e.g., X) simultaneous HARQ processes (in other words, they can also process multiple (e.g., X) UL data transmissions in parallel, concurrently, or simultaneously). For example, A-IoT devices can also maintain a buffer for each HARQ process.

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

[0215] When an A-IoT device sends new UL data, it stores or saves the UL data in the corresponding buffer.

[0216] An A-IoT device can also send other UL data #j from a different HARQ process #j after sending UL data #i from HARQ process #i (HARQ process number i) and before receiving an ACK / NACK for UL data #i from HARQ process #i. In other words, an A-IoT device can also receive an ACK / NACK for UL data #i from HARQ process #i after sending UL data #i from HARQ process #i and other UL data #j from HARQ process #j that are different from HARQ process #i.

[0217] In addition, A-IoT devices can also receive a single ACK / NACK response (ACK / NACK bundling) that combines ACK / NACK responses for multiple transmitted UL data, or they can receive a single resource merge.

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

[0219] One or more of the restrictions shown below can also be defined in the specification.

[0220] For example, regarding the limitation, it could be that if an A-IoT device sends UL data #j for HARQ process #j after sending UL data #i for HARQ process #i, it is conceivable that after receiving ACK / NACK for UL data #i for HARQ process #i, it can receive ACK / NACK for UL data #j for HARQ process #i, or receive that ACK / NACK.

[0221] As another example, regarding the limitation, it could also be regarding the same HARQ process, that it is not envisioned that the A-IoT device be scheduled to send other UL data (a new transmission of new UL data or a retransmission of previous UL data), not envisioned to send such other UL data, or not to send such other UL data, before receiving an ACK / NACK for previous UL data. In other words, regarding the limitation, it could also be regarding the same HARQ process, that it is envisioned that the A-IoT device be scheduled to send other UL data after receiving an ACK / NACK for previous UL data, envisioned to send such other UL data, or to send such other UL data.

[0222] Figure 13 This diagram illustrates an example of the interaction between the base station / auxiliary node / intermediate node and the A-IoT device involved in Option 1. (See diagram below.) Figure 13 As shown, the A-IoT device sequentially sends UL data #1 from HARQ process #1, UL data #2 from HARQ process #2, ..., and UL data #X from HARQ process #X to the base station and other networks. Furthermore, as... Figure 13 As shown, the A-IoT device receives ACK / NACK for UL data #1, ACK / NACK for UL data #2, ..., and ACK / NACK for UL data #X sequentially from the base station or other network, depending on whether the decoding of these UL data based on the base station or other network is successful or not.

[0223] Option 1 enables the HARQ operation of A-IoT devices to be identical to the current wireless communication systems associated with DL reception, thus suppressing the impact on specifications.

[0224] [Option 2]

[0225] The following is an explanation of option 2, regarding the situation where A-IoT devices do not support multiple simultaneous HARQ processes.

[0226] A-IoT devices can also support or maintain a single HARQ process (in other words, they can process a single UL data (transmit) at a time, or they can process multiple UL data (transmit) in a non-parallel, parallel, or simultaneous manner). In this case, for example, the A-IoT device can also maintain a buffer.

[0227] When an A-IoT device sends new UL data, it stores or saves the UL data in a buffer.

[0228] One or more of the restrictions shown below can also be defined in the specification.

[0229] For example, regarding limitations, it could also be that the A-IoT device is not envisioned being scheduled to send other UL data (a new transmission of new DL data or a retransmission of previous DL data) before receiving an ACK / NACK for previous UL data, or that the other UL data is not envisioned being sent, or that the other UL data is not sent. In other words, regarding limitations, it could also be that the A-IoT device is scheduled to send other UL data after receiving an ACK / NACK for previous UL data, or that the other UL data is envisioned being sent, or that the other UL data is sent.

[0230] As another example, regarding limitations, it could also be that the A-IoT device is not envisioned being scheduled to send new UL data before receiving an ACK for previous UL data, is not envisioned to send the new UL data, or is not envisioned to send the new UL data. In other words, regarding limitations, it could also be that the A-IoT device is envisioned being scheduled to send new UL data after receiving an ACK for previous UL data, is envisioned to send the new UL data, or is envisioned to send the new UL data.

[0231] Figure 14 This diagram illustrates an example of the interaction between the base station / auxiliary node / intermediate node and the A-IoT device involved in Option 2. (See diagram below.) Figure 14 As shown, if an A-IoT device sends UL data to a network such as a base station, the base station or other network sends an ACK / NACK to the A-IoT device based on the success or failure of decoding the UL data. The A-IoT device then receives the ACK / NACK from the base station or other network. This process is repeated.

[0232] In addition, the reception of ACK / NACK for UL data based on A-IoT devices, i.e., the notification of ACK / NACK for UL data based on the network, will be explained in Proposal 2-2 below.

[0233] Option 2 enables HARQ operation of A-IoT devices to be adapted to the simplified structure of A-IoT devices.

[0234] Alternatively, in Proposal 2-1, Device A could support only one HARQ process, while Devices B and C could support multiple HARQ processes.

[0235] <Proposal 2-2>

[0236] Next, regarding the above points (1) and (4), a proposal (Proposal 2-2) will be explained in connection with the network-based ACK / NACK notification for UL reception (UL data).

[0237] In current wireless communication systems, explicit ACK / NACK notifications or feedback for UL reception (UL data) are not specified based on the network. However, given the simplified architecture of A-IoT devices, network-based ACK / NACK notifications for UL reception (UL data) may differ from those in current wireless communication systems. That is, HARQ operations may need to differ depending on how the network notifies ACK / NACK for UL data transmitted by the A-IoT device.

[0238] [Alt.1]

[0239] The following section, as Alt.1, explains the situation where the network notifies NDI when scheduling UL data transmission from A-IoT devices.

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

[0241] When a UL transmission is notified as a new transmission, the A-IoT device refreshes or deletes the buffer of previous UL data and stores or saves the new UL data in the buffer. On the other hand, when a UL transmission is notified as a retransmission, the A-IoT device retransmits the previous UL data stored or saved in the buffer.

[0242] In Option 1 of Proposal 2-1, when scheduling UL data transmissions from A-IoT devices, the network can also notify the A-IoT devices of both the NDI and the HARQ process index. The size of the HARQ process index field is related to the number (e.g., X) of simultaneous HARQ processes supported or maintained by the A-IoT device. For example, the size of the HARQ process index field could be 1 bit when X is 2, 2 bits when X is greater than 2 and less than 4, 3 bits when X is greater than 4 and less than 8, and so on.

[0243] Alternatively, NDI can also be explained as follows.

[0244] Option 1

[0245] If the NDI is flipped compared to a previously transmitted value (meaning it differs from a previously transmitted value), the A-IoT device can treat the UL transmission as a new transmission. Conversely, if the NDI is not flipped compared to a previously transmitted value (meaning it is the same as a previously transmitted value), the A-IoT device can treat the UL transmission as a retransmission. In option 1, the A-IoT device needs to store the NDI value.

[0246] Option 1 enables the HARQ operation of A-IoT devices to be identical to current wireless communication systems, thus mitigating the impact on specifications.

[0247] Option 2

[0248] The NDI can also take the value indicating that the UL transmission is a new transmission (first value) or the value indicating that the UL transmission is a retransmission (second value). The first and second values ​​can also be defined in the specification. For example, the NDI can also take two values. For instance, when the NDI is set to bit value "0", the A-IoT device can also treat the UL transmission as a new transmission. On the other hand, when the NDI is set to bit value "1", the A-IoT device can also treat the UL transmission as a retransmission. Alternatively, it can be the opposite mapping. That is, when the NDI is set to bit value "1", the A-IoT device can also treat the UL transmission as a new transmission, and when the NDI is set to bit value "0", the A-IoT device can also treat the UL transmission as a retransmission. In option 2, the A-IoT device does not need to store the NDI value.

[0249] Option 2 enables HARQ operation of A-IoT devices to adapt to the simple structure of A-IoT devices and achieves more reliable HARQ operation.

[0250] [Alt.2]

[0251] The following, as Alt.2, explains the case where direct network notifications can also be scheduled independently of UL data transmission ACK / NACK.

[0252] As mentioned above, the network can also directly notify A-IoT devices of ACK / NACK. ACK can take the first value, NACK can take the second value, and ACK / NACK can take two values. For example, a 1-bit field can be used for ACK / NACK notification. For example, a bit value of "0" in this field can also represent "NACK", and a bit value of "1" in this field can also represent "ACK". Alternatively, it can be the opposite mapping. That is, a bit value of "0" in this field can also represent "ACK", and a bit value of "1" in this field can also represent "NACK".

[0253] When the network sends an ACK notification to the A-IoT device, the A-IoT device refreshes or deletes the buffer of previous UL data. On the other hand, when the network sends a NACK notification to the A-IoT device, the A-IoT device directly maintains the buffer of previous UL data.

[0254] In Option 1 of Proposal 2-1, the network can also notify A-IoT devices of the ACK / NACK along with the HARQ process index.

[0255] Furthermore, for example, when the network schedules the transmission of UL data from an A-IoT device, if previous UL data does not exist in the buffer, the A-IoT device can also send new UL data to the network, or store or preserve the new UL data in the buffer. Additionally, for example, when the network schedules the transmission of UL data from an A-IoT device, if previous UL data exists in the buffer, the A-IoT device can also retransmit the previous UL data to the network. In the case of option 1 of proposal 2-1, the network can also notify the HARQ process index when scheduling UL transmission.

[0256] ACK / NACK can also be carried in the same DL channel as the UL scheduling information. For example, the UL scheduling information is carried by a DCI carried in the DL control channel, but ACK / NACK can also be carried by a DCI with a different format than that DCI. For example, ACK / NACK can also be carried by a UL data scheduling DCI with a different DCI format than the UL data scheduling DCI.

[0257] Alternatively, ACK / NACK can also be carried on a DL channel that is different from the UL scheduling information. For example, the UL scheduling information is carried by the DCI carried on the DL control channel, but ACK / NACK can also be carried on other DL channels (e.g., channels that are the same as or the same as the PHICH (physical HARQ indicator channel) in LTE, or data channels).

[0258] According to Alt.2, HARQ operation of A-IoT devices can be adapted to the simple structure of A-IoT devices.

[0259] <Proposal 2-3>

[0260] Next, regarding the above viewpoint (3), we will explain the proposals (Proposals 2-3) related to the reception of ACK / NACK for network-based UL reception based on A-IoT devices.

[0261] For example, information related to the following resources can be provided to A-IoT devices from the network, defined in the specification, or reported by the A-IoT devices to the network as a device capability related to receiving ACK / NACK feedback sent to UL. In the case of information being provided to A-IoT devices from the network, such information can also be included in UL data scheduling information (e.g., DCI or UL authorization).

[0262] Resource-related information may also include time resources for receiving ACK / NACK feedback (information indicating the time resources used for receiving ACK / NACK feedback). For example, ... Figure 15 As shown, the information representing the time resources used to receive ACK / NACK feedback can also be the time offset between the transmission of UL data (e.g., the end or end) and the reception of ACK / NACK feedback. A-IoT devices can also receive ACK / NACK feedback at a time offset elapsed from the transmission of UL data.

[0263] 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.

[0264] When the time offset is defined in the specification, for example, an A-IoT device may also receive ACK / NACK feedback from the network X milliseconds / slots / symbols after the end of UL data transmission.

[0265] The time resources (also known as candidate resources) available for receiving ACK / NACK feedback can be predefined in the specification or through the network. One or more of the predefined candidate resources can also be notified to the A-IoT device by the network. For example, candidate resources can also be set / defined by the network through higher-level signaling such as RRC, and one or more of the candidate resources can also be notified by the network through DCI.

[0266] • Indicates changes in information related to time resources

[0267] Considering that A-IoT devices may not support or maintain DL / UL synchronization, the period or time interval for receiving ACK / NACK feedback can be defined in the specification, provided by the network, or reported to the network by the A-IoT device as a device capability. In this case, it is also conceivable that the A-IoT device receives ACK / NACK feedback within the time interval, or it may also receive ACK / NACK feedback.

[0268] For example, such as Figure 16 As shown, the time offset between the UL data transmission (e.g., the end or end) and the start (moment) of the time interval (time offset #1 in the figure) can be defined in the specification, provided by the network, or reported to the network by the A-IoT device as a device capability.

[0269] In addition, for example, such as Figure 16As shown, the time offset between the UL data transmission (e.g., the end or end) and the end of the time interval (time point) (time offset #2 in the figure) can be defined in the specification, provided by the network, or reported to the network by the A-IoT device as a device capability.

[0270] In addition, for example, the length of the time interval ( Figure 16 The time offset #2 (the difference between time offset #1) shown can be defined in the specification, provided by the network, or reported to the network by A-IoT devices as a device capability.

[0271] A-IoT devices can also receive ACK / NACK feedback after time offset #1 from the start of UL data transmission and before time offset #2 from the start of UL data transmission.

[0272] For example, an A-IoT device can also receive an ACK / NACK for the UL data from the network after time unit #n+k and / or before time unit #n+m, provided that UL data was sent in time unit #n.

[0273] As a change in time interval, if an A-IoT device does not receive ACK / NACK feedback within the time interval, it can also be considered as NACK. Conversely, if an A-IoT device does not receive ACK / NACK feedback within the time interval, it can also be considered as ACK.

[0274] In addition, the information related to resources may also include frequency resources for receiving ACK / NACK feedback (information on frequency resources for transmitting ACK / NACK feedback).

[0275] The granularity of frequency resources can be either subcarriers / resource blocks or any frequency unit defined for A-IoT.

[0276] A-IoT devices can also receive ACK / NACK feedback in one or more subcarriers / resource blocks / other frequency units.

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

[0278] For example, the frequency resources (also known as candidate resources) available for receiving ACK / NACK feedback can be predefined in the specification or through the network. One or more of the predefined candidate resources can also be notified to the A-IoT device by the network. For example, candidate resources can also be set / defined by the network through higher-level signaling such as RRC, and one or more of the candidate resources can also be notified by the network through DCI.

[0279] Furthermore, for example, the relationship between the frequency resources used for receiving (ACK / NACK feedback) and the frequency resources used for the data channel can be defined in the specification or notified to the A-IoT device by the network.

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

[0281] According to Proposal 2-3, A-IoT devices are able to appropriately receive ACK / NACK from the network based on resource-related information, that is, using time resources and / or frequency resources represented by resource-related information.

[0282] <Operational Examples Related to Proposal 2>

[0283] Next, refer to Figure 17 An example of operating equipment 20 is explained.

[0284] In step S21, device 20 sends uplink data to the network.

[0285] In step S22, device 20 receives from the network an acknowledgment signal indicating whether the decoding of the transmitted uplink data was successful or failed.

[0286] In step S23, device 20 performs retransmission control of the sent uplink data based on the received response signal.

[0287] Steps S21 to S23 can also be performed according to proposals 2-1 to 2-3, which include the above options and Alt.

[0288] Based on Proposal 2, ARQ operations can be appropriately performed with respect to UL.

[0289] <Capability>

[0290] The A-IoT capabilities that represent the capabilities of A-IoT devices such as device 20 may also include information representing the capabilities of the following devices. Device 20 may also report the information representing the capabilities of the following devices to base station 10. In addition, the information representing the device's capabilities may correspond to the information defining the device's capabilities.

[0291] • Define whether A-IoT devices support multiple simultaneous HARQ processes for DL ​​reception.

[0292] • Define whether A-IoT devices support simultaneous DL data (processing / receiving).

[0293] • Define information about the number of simultaneous HARQ processes that an A-IoT device can support or maintain with DL reception.

[0294] • Defines the amount of DL data (processing / receiving) that an A-IoT device can handle simultaneously.

[0295] • Define whether the A-IoT device supports a soft buffer for DL ​​data decoding.

[0296] • Information defining the number of soft buffers that an A-IoT device can support or maintain.

[0297] • Defines the number of ACK / NACKs that an A-IoT device can send in a single UL transmission.

[0298] • Define the time and / or frequency resources for A-IoT devices to transmit ACK / NACK feedback.

[0299] • Defines the minimum (shortest) time offset for A-IoT devices to send ACK / NACK feedback.

[0300] • Define whether A-IoT devices support multiple simultaneous HARQ processes for UL transmission.

[0301] • Define whether A-IoT devices support simultaneous UL data processing / transmission.

[0302] • Define the information about the number of HARQ processes that the A-IoT device can support or maintain simultaneously when transmitting UL data.

[0303] • Information defining the amount of UL data that an A-IoT device can process (process / transmit) simultaneously.

[0304] • Define whether the A-IoT device supports buffer information for UL data transmission.

[0305] • Information defining the number of buffers that an A-IoT device can support or maintain.

[0306] • Defines the number of ACK / NACKs that an A-IoT device can receive in a single DL reception.

[0307] • Define the time and / or frequency resources for A-IoT devices to receive ACK / NACK feedback.

[0308] • Define whether the A-IoT device supports the above proposals and / or options and / or which of the above Alt values.

[0309] Next, the structures of base station 10 and device 20 will be described. Furthermore, the structures of base station 10 and device 20 described below represent one example of the functions associated with this embodiment. Base station 10 and device 20 may also have functions not shown. Moreover, the functional distinctions and / or names of functional units are not limited as long as they perform the operations involved in this embodiment.

[0310] <Base station structure>

[0311] Figure 18 This is a block diagram illustrating an example of the structure of a base station 10 according to an embodiment. Base station 10 includes, for example, a transmitting unit 101, a receiving unit 102, and a control unit 103. Base station 10 communicates wirelessly with device 20 (see reference 103). Figure 19 The base station 10 can also be an intermediate node, an auxiliary node, or a terminal (the terminal of the SL that communicates with the device 20).

[0312] Transmitting unit 101 transmits a downlink (DL) signal to device 20. For example, transmitting unit 101 transmits the DL signal under the control of control unit 103.

[0313] The DL signal may also include, for example, downlink data signals and control information (e.g., DCI (Downlink Control Information)). Furthermore, the DL signal may also include scheduling information related to signal transmission by device 20 (e.g., UL authorization). Additionally, the DL signal may also include higher-layer control information (e.g., RRC (Radio Resource Control) control information). Furthermore, the DL signal may also include reference signals.

[0314] The channels used in transmitting DL signals may include, for example, data channels and control channels. For instance, 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, base station 10 and device 20 use the PDCCH to transmit control information and the PDSCH to transmit downlink data signals.

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

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

[0317] The control unit 103 controls the communication operation of the base station 10, which includes the transmission processing of the transmission unit 101 and the reception processing of the reception unit 102.

[0318] For example, control unit 103 obtains data and control information from higher layers and outputs it to transmitting unit 101. Furthermore, control unit 103 outputs data and control information received from receiving unit 102 to higher layers.

[0319] For example, the control unit 103 allocates resources (or channels) used in the transmission and reception of DL signals and / or UL signals based on signals received from the device 20 (e.g., data and control information) and / or data and control information obtained from higher layers. Information related to the allocated resources may also be included in the control information sent to the device 20.

[0320] Control unit 103 sets PUCCH resources as an example of resource allocation used in the transmission and reception of UL signals. Information related to PUCCH settings, such as PUCCH cell timing mode (PUCCH setting information), can also be notified to device 20 via RRC.

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

[0322] For example, the transmitting unit 101 can also transmit downlink data to the device 20, and the receiving unit 102 can also receive an acknowledgment signal from the device 20 indicating whether the decoding of the transmitted downlink data was successful or failed. The transmitting unit 101 can also send binary information to the device 20 indicating whether the transmission of the downlink data is a new transmission or a retransmission.

[0323] Furthermore, for example, receiving unit 102 can also receive uplink data from device 20, control unit 103 can also generate an acknowledgment signal indicating success or failure of decoding the received uplink data, and sending unit 101 can also send the generated acknowledgment signal to device 20. The acknowledgment signal can also take either of two values.

[0324] <Equipment Structure>

[0325] Figure 19 This is a block diagram illustrating an example of the structure of the 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 the base station 10 wirelessly, for example. The device 20 may also be an A-IoT device, for example.

[0326] The receiving unit 201 receives the 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.

[0327] The transmitting unit 202 transmits a 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.

[0328] The UL signal may also include, for example, uplink data signals and control information (e.g., UCI (Uplink Control Information)). For instance, it may also include information related to the processing capabilities of device 20 (e.g., A-IoT capability). Furthermore, the UL signal may also include a reference signal.

[0329] The channels used in transmitting UL signals may include, for example, data channels and control channels. For instance, 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, with respect to device 20, base station 10 uses the PUCCH to transmit control information and the PUSCH to transmit uplink data signals.

[0330] The reference signals included in the UL signal may include at least one of DMRS, PTRS, CSI-RS, SRS, and PRS. For example, reference signals such as DMRS and PTRS are used for demodulation of uplink data signals and are transmitted using an uplink channel (e.g., PUSCH).

[0331] The control unit 203 controls the communication operation of the device 20, which includes the receiving processing in the receiving unit 201 and the transmitting processing in the transmitting unit 202.

[0332] For example, control unit 203 obtains data and control information from higher layers and outputs it to transmitting unit 202. Furthermore, control unit 203 may output data and control information received from receiving unit 201 to higher layers, for example.

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

[0334] The control unit 203 configures the PUCCH resources based on the configuration information received from the base station 10 (e.g., PUCCH cell timing mode configuration information notified via RRC and / or DCI). The control unit 203 determines the PUCCH resources to be used in transmitting information fed back to the base station 10. The transmitting unit 202, under the control of the control unit 203, transmits the information fed back to the base station 10 using the PUCCH resources determined by the control unit 203.

[0335] Furthermore, the channels used in transmitting DL signals and UL signals are not limited to the examples described above. For instance, the channels used in transmitting DL signals and UL signals may also include RACH (Random Access Channel) and PBCH (Physical Broadcast Channel). RACH can also be used, for example, for transmitting DCI containing RA-RNTI (Random Access Radio Network Temporary Identifier).

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

[0337] For example, receiving unit 201 can also receive downlink data from the network, and control unit 203 can also generate an acknowledgment signal indicating success or failure of decoding the received downlink data. Device 20 may also not maintain a soft buffer for downlink data decoding. Receiving unit 201 can also receive binary information from the network indicating whether the transmission of the downlink data is a new transmission or a retransmission, and control unit 203 can also determine whether the transmission of the downlink data is a new transmission or a retransmission based on the received binary information. Transmitting unit 202 can also send an acknowledgment signal to the network at a timed interval after a first time has elapsed since the reception of the downlink data, or it can send an acknowledgment signal to the network after a 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.

[0338] Furthermore, for example, the transmitting unit 202 can also transmit uplink data to the network, the receiving unit 201 can also receive an acknowledgment signal from the network indicating success or failure of decoding the uplink data transmitted to the network, and the control unit 203 can also perform retransmission control of the uplink data transmitted to the network based on the received acknowledgment signal. The device 20 can also maintain one or more buffers for uplink data transmission. The acknowledgment signal can also take either of two values. The receiving unit 201 can receive the acknowledgment signal at a timed interval after a first time has elapsed since the transmission of the uplink data, or it can receive the acknowledgment signal after a first time has elapsed and before a second time has elapsed since the transmission of the uplink data.

[0339] (Summary of implementation methods)

[0340] One aspect of this disclosure relates to a device with lower complexity than an NB-IoT (Narrow Band Internet of Things) device, the device comprising: a receiving unit for receiving downlink data from a network; and a control unit for generating an acknowledgment signal indicating success or failure of decoding the downlink data.

[0341] With the above-described structure, devices such as A-IoT devices can perform HARQ operations appropriately.

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

[0343] With the above structure, HARQ operations that match the simplified structure can be implemented.

[0344] 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.

[0345] With the above structure, HARQ operations that match the simple structure can be implemented, and HARQ operations with higher reliability can be implemented.

[0346] In one example, the device further includes a transmitting unit that transmits the response signal to the network at a time interval after a first time elapsed since the reception of the downlink data.

[0347] With the above structure, it is possible to report HARQ ACK / NACK at appropriate timings.

[0348] In one example, the device further includes a transmitting unit that transmits the acknowledgment signal to the network after a first time elapsed since the reception of the downlink data and before a second time elapsed since the reception of the downlink data.

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

[0350] One aspect of this disclosure relates to a communication method in which a device with lower complexity than an NB-IoT (Narrowband Internet of Things) device receives downlink data from a network and generates an acknowledgment signal indicating success or failure of decoding the downlink data.

[0351] With the above-described structure, devices such as A-IoT devices can perform HARQ operations appropriately.

[0352] The device involved in one aspect of this disclosure is a device with lower complexity than an NB-IoT (Narrow Band Internet of Things) device, the device comprising: a receiving unit for receiving from the network an acknowledgment signal indicating success or failure of decoding uplink data sent to the network; and a control unit for performing retransmission control of the uplink data based on the acknowledgment signal.

[0353] With the above-described structure, devices such as A-IoT devices can perform HARQ operations appropriately.

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

[0355] With the above structure, the same operations as existing downlink HARQ operations can be performed.

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

[0357] With the above structure, HARQ operations that match the simple structure can be implemented, and HARQ operations with higher reliability can be implemented.

[0358] In one example, the receiving unit receives the acknowledgment signal after a time interval following the transmission of the uplink data.

[0359] With the above structure, it is possible to receive HARQ ACK / NACK at appropriate timing.

[0360] In one example, the receiving unit receives the acknowledgment signal after a first time elapsed since the transmission of the uplink data and before a second time elapsed since the transmission of the uplink data.

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

[0362] One aspect of this disclosure involves a communication method in which a device with lower complexity than an NB-IoT (Narrowband Internet of Things) device receives from the network an acknowledgment signal indicating success or failure of decoding uplink data sent to the network, and performs retransmission control of the uplink data based on the acknowledgment signal.

[0363] With the above-described structure, devices such as A-IoT devices can perform HARQ operations appropriately.

[0364] The above provides an explanation of this disclosure. Furthermore, the distinctions between items mentioned above are not essential in this disclosure; items described in two or more items may be combined as needed, and items described in one item may be applied to items described in other items (as long as they do not contradict each other).

[0365] <Hardware structure, etc.>

[0366] The block diagrams used in the description of the above embodiments illustrate functional units. These functional blocks (structural units) are implemented through any combination of at least one of hardware and software. Furthermore, the implementation method of each functional block is not particularly limited. That is, each functional block can be implemented using a single device that is physically or logically combined, or it can be implemented by directly or indirectly (e.g., using wired, wireless, etc.) connecting two or more physically or logically separate devices. A functional block can also be implemented by combining one or more of the aforementioned devices with software.

[0367] The functions include judgment, decision, determination, calculation, calculation, processing, derivation, investigation, search, confirmation, receiving, sending, output, access, resolution, selection, choosing, establishment, comparison, assumption, expectation, regard as, broadcasting, notifying, communicating, forwarding, configuring, reconfiguring, allocating, mapping, and assigning, but are not limited to these. For example, the functional block (structural unit) that implements the sending function is called a transmitting unit or a transmitter. Both are as described above, and the implementation method is not particularly limited.

[0368] For example, the base station, device, etc. in one embodiment of this disclosure can also function as a computer for processing the wireless communication method of this disclosure. Figure 20 This is a diagram illustrating an example of the hardware structure of the base station and device involved in the embodiment. The base station 10 and device 20 described above can also be physically configured as a computer device including a processor 1001, a memory 1002, a storage device 1003, a communication device 1004, an input device 1005, an output device 1006, a bus 1007, etc.

[0369] Additionally, in the following description, the term "device" can be replaced with circuit, device, unit, etc. The hardware structure of base station 10 and device 20 can be configured to include one or more of the devices shown in the figure, or it can be configured not to include some of the devices.

[0370] Regarding the various functions in base station 10 and device 20, specific software (programs) are read into hardware such as processor 1001 and memory 1002, so that processor 1001 performs calculations and controls communication based on communication device 1004, or controls at least one of reading out and writing data in memory 1002 and storage device 1003, thereby achieving the following:

[0371] The processor 1001, for example, enables the operating system to operate and control the computer as a whole. The processor 1001 may also be composed of a central processing unit (CPU) that includes interfaces with peripheral devices, control devices, arithmetic devices, registers, etc. For example, the control unit 103 and control unit 203 described above may also be implemented by the processor 1001.

[0372] Furthermore, the processor 1001 reads programs (program code), software modules, data, etc., from at least one of the storage 1003 and the communication device 1004 into the memory 1002, and performs various processes accordingly. As a program, a program that causes the computer to perform at least a portion of the operations described in the above embodiments can be used. For example, the control unit 103 of the base station 10 and the control unit 203 of the device 20 can also be implemented by control programs stored in the memory 1002 and operated by the processor 1001; similarly, other functional blocks can be implemented. The above-described various processes are executed by one processor 1001, but they can also be executed simultaneously or sequentially by two or more processors 1001. The processor 1001 can also be implemented by one or more chips. Additionally, the program can be transmitted from a network via an electrical communication line.

[0373] The memory 1002 is a computer-readable recording medium, and may be composed of at least one of the following: ROM (Read-Only Memory), EPROM (Erasable Programmable ROM), EEPROM (Electrically Erasable Programmable ROM), RAM (Random Access Memory). The memory 1002 may also be referred to as a register, cache, main memory (main storage device), etc. The memory 1002 can store executable programs (program code), software modules, etc., for implementing the wireless communication method according to an embodiment of this disclosure.

[0374] Storage 1003 is a computer-readable recording medium, and may be comprised of at least one of the following: CD-ROM (Compact Disc ROM) or other optical discs; hard disk drives; flexible discs; optical discs (e.g., compact discs, digital multifunction discs, Blu-ray discs); smart cards; flash memory (e.g., cards, sticks, key drives); floppy disks; magnetic stripes; etc. Storage 1003 may also be referred to as an auxiliary storage device. The aforementioned storage medium may also be, for example, a database, server, or other suitable medium that includes at least one of memory 1002 and storage 1003.

[0375] The communication device 1004 is hardware (transmitting and receiving device) used for communication between computers via at least one of a wired network and a wireless network. It is also referred to as a network device, network controller, network interface card (NIC), communication module, etc. To implement at least one of, for example, Frequency Division Duplex (FDD) and Time Division Duplex (TDD), the communication device 1004 may also be configured to include a high-frequency switch, a duplexer, a filter, a frequency synthesizer, etc. For example, the aforementioned transmitting unit 101, receiving unit 102, receiving unit 201, and transmitting unit 202 may also be implemented by the communication device 1004.

[0376] Input device 1005 is an input device that accepts input from external sources (e.g., keyboard, mouse, microphone, switch, button, sensor, etc.). Output device 1006 is an output device that performs output to external sources (e.g., display, speaker, LED light, etc.). Alternatively, input device 1005 and output device 1006 can also be an integrated structure (e.g., touch panel).

[0377] Furthermore, the processor 1001, memory 1002, and other devices are connected via a bus 1007 for communication of information. The bus 1007 can be configured as a single bus or as different buses between the devices.

[0378] Furthermore, the base station 10 and the device 20 can also be configured to include hardware such as a microprocessor, a digital signal processor (DSP), an ASIC (Application Specific Integrated Circuit), a PLD (Programmable Logic Device), and a FPGA (Field Programmable Gate Array), and can also use this hardware to implement part or all of the functional blocks. For example, the processor 1001 can also be implemented using at least one of these hardware components.

[0379] <Information notification and signaling>

[0380] The notification of information is not limited to the implementation methods described in this disclosure, and can also be performed by other methods. For example, the notification of information can also be implemented through physical layer signaling (e.g., DCI (Downlink Control Information), UCI (Uplink Control Information)), higher layer signaling (e.g., RRC (Radio Resource Control) signaling, MAC (Medium Access Control) signaling, broadcast information (MIB (Master Information Block)), SIB (System Information Block)), other signals, or combinations thereof. In addition, RRC signaling can also be referred to as RRC message, for example, it can also be an RRC Connection Setup message, an RRC Connection Reconfiguration message, etc.

[0381] <Application Systems>

[0382] The implementations described in this disclosure can also be applied to LTE (Long Term Evolution), LTE-A (LTE-Advanced), 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 At least one of 802.20, UWB (Ultra-Wideband), Bluetooth (Bluetooth (registered trademark)), systems utilizing other suitable systems, and next-generation systems derived from or extended by these systems. Furthermore, multiple systems may be combined (e.g., a combination of LTE and at least one of LTE-A with 5G, etc.) for application.

[0383] <Processing procedures, etc.>

[0384] The processing procedures, sequences, flowcharts, etc., of the various methods / implementations described in this disclosure may be rearranged as long as they do not contradict each other. For example, for the methods described in this disclosure, an exemplary order is used to indicate the elements of various steps, but the order in which they are indicated is not limited.

[0385] <Base Station Operation>

[0386] In this disclosure, specific operations are posited as being performed by a base station, and sometimes, depending on the circumstances, by its upper node. Clearly, in a network consisting of one or more network nodes having a base station, various operations performed for communication with a terminal can also be performed by at least one of the base station and other network nodes besides the base station (e.g., consider MME or S-GW, but not limited to these). The above example illustrates a case where there is only one other network node besides the base station; it could also be a combination of multiple other network nodes (e.g., MME and S-GW).

[0387] <Direction of input / output>

[0388] Information (see items under <Information, Signals>) can also be output from higher (or lower) layers to lower (or higher) layers. It can also be input and output via multiple network nodes.

[0389] <Processing of input and output information>

[0390] Input and output information can be stored in a specific location (e.g., memory) or managed using a management table. Input and output information can be overwritten, updated, or appended. Output information can also be deleted. Input information can also be sent to other devices.

[0391] <Judgment Method>

[0392] The determination can be made by a value represented by a single bit (0 or 1), by a true or false value (Boolean: true or false), or by a numerical comparison (e.g., a comparison with a specific value).

[0393] <Changes in methods, etc.>

[0394] The various methods / implementations described in this disclosure can be used individually or in combination, and can be switched as needed during execution. Furthermore, notification of specific information (e.g., a "It is X" notification) is not limited to explicit notification, but can also be done implicitly (e.g., without notifying the recipient of that specific information).

[0395] The present disclosure has been described in detail above, but it will be apparent 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 ways without departing from the spirit and scope of the present disclosure as determined by the claims. Therefore, the description in this disclosure is for illustrative purposes only and is not intended to be restrictive in any way.

[0396] <Software>

[0397] Whether software is called software, firmware, middleware, microcode, hardware description language, or any other name, it should be broadly interpreted to refer to instructions, instruction sets, code, code segments, program code, programs, subprograms, software modules, applications, software applications, software packages, routines, subroutines, objects, executable files, execution threads, procedures, functions, etc.

[0398] Furthermore, software, instructions, and information can also be sent and received via a transmission medium. For example, when software is sent from a website, server, or other remote source using at least one of wired technologies (coaxial cable, fiber optic cable, twisted pair, digital subscriber line (DSL), etc.) and wireless technologies (infrared, microwave, etc.), at least one of these wired and wireless technologies is included within the definition of a transmission medium.

[0399] <Information, Signals>

[0400] The information, signals, etc., described in this disclosure can also be represented using any of a variety of different technologies. For example, data, instructions, commands, information, signals, bits, symbols, chips, etc., which may be mentioned throughout the above description, can also be represented by voltage, current, electromagnetic waves, magnetic fields or magnetic particles, light fields or photons, or any combination thereof.

[0401] Furthermore, the terms described in this disclosure, as well as those necessary for understanding this disclosure, may be replaced with terms that have the same or similar meanings. For example, at least one of the channel and the symbol may also be a signal (signaling). Additionally, a signal may also be a message. Furthermore, a component carrier (CC) may also be referred to as a carrier frequency, cell, frequency carrier, etc.

[0402] <Systems, Networks>

[0403] The terms “system” and “network” are used interchangeably in this disclosure.

[0404] <Parameters, Channel Name>

[0405] Furthermore, the information, parameters, etc., described in this disclosure can be represented by absolute values, relative values ​​with respect to a specific value, or other corresponding information. For example, wireless resources can also be indicated by an index.

[0406] The names used for the parameters described above are not limiting names in any respect. Furthermore, the mathematical formulas used for these parameters sometimes differ from those explicitly disclosed in this disclosure. Various channels (e.g., PUCCH, PDCCH, etc.) and information elements can be identified by any suitable name; therefore, the various names assigned to these various channels and information elements are not limiting names in any respect.

[0407] <Base Station>

[0408] In this disclosure, the terms "base station (BS)," "wireless 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" are used interchangeably. There are also instances where terms such as macro cell, small cell, femtocell, and picocell are used to refer to base stations.

[0409] A base station can accommodate one or more (e.g., three) cells. When a base station accommodates multiple cells, its overall coverage area can be divided into several smaller areas, each of which can also provide communication services through a base station subsystem (e.g., a small indoor base station (Remote Radio Head (RRH))). Terms such as "cell" or "sector" refer to a portion or all of the coverage area of ​​at least one of the base station and base station subsystem providing communication services within that coverage area.

[0410] In this disclosure, the sending of information from the base station to the terminal can also be rewritten as the base station instructing the terminal to perform information-based control and operation.

[0411] <Mobile Station>

[0412] In this disclosure, the terms “Mobile Station (MS),” “user terminal,” “user equipment (UE),” and “terminal” are used interchangeably.

[0413] There are also cases where a mobile station is 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, hand set, user agent, mobile client, client, or several other appropriate terms.

[0414] <Base station / Mobile station>

[0415] At least one of the base station and the mobile station can also be referred to as a transmitting device, a receiving device, a communication device, etc. Furthermore, at least one of the base station and the mobile station can also be equipment mounted on a mobile body, the mobile body itself, etc. The mobile body refers to a movable object whose speed of movement is arbitrary. In addition, it naturally includes situations where the mobile body is stationary. The mobile body includes, for example, vehicles, transport vehicles, automobiles, autonomous two-wheelers, bicycles, connected cars, excavators, bulldozers, wheel loaders, dump trucks, forklifts, trains, buses, trailers, rickshaws, ships (boats and other watercraft), airplanes, rockets, artificial satellites, drones (registered trademark), multi-rotor aircraft, quadcopter aircraft, balloons, and objects mounted on them, and is not limited to these. Furthermore, the mobile body can also be a mobile body that moves autonomously based on operating commands. It can be a means of transportation (e.g., vehicles, airplanes, etc.), a mobile body that moves unmanned (e.g., drones, autonomous vehicles, etc.), or a robot (humanized or unmanned). In addition, at least one of the base station and the mobile station also includes a device that is not necessarily mobile during the communication operation. For example, at least one of the base station and the mobile station can also be an Internet of Things (IoT) device such as a sensor.

[0416] Furthermore, the base station in this disclosure can also be rewritten as a terminal. For example, embodiments of this disclosure can also be applied to structures where communication between the base station and the terminal is replaced by communication between multiple terminals (e.g., also referred to as D2D (Device-to-Device), V2X (Vehicle-to-Everything), etc.). In this case, it can also be configured such that the device 20 has the functions of the base station 10 described above. In addition, terms such as "uplink" and "downlink" can also be rewritten as terms corresponding to communication between terminals (e.g., "side"). For example, uplink channel, downlink channel, etc., can also be rewritten as side channel.

[0417] Similarly, the terminal in this disclosure can also be rewritten as a base station. In this case, it can also be configured such that the base station 10 has the functions of the device 20 described above.

[0418] Figure 21 An example of the structure of vehicle 2001 is shown. For example... Figure 21 As shown, the vehicle 2001 includes a drive unit 2002, a steering control unit 2003, an accelerator pedal 2004, a brake pedal 2005, a gear shift lever 2006, front wheels 2007, rear wheels 2008, an axle 2009, an electronic control unit 2010, various sensors 2021-2029, an information service unit 2012, and a communication module 2013. The various methods / implementations described in this disclosure can also be applied to communication devices mounted on the vehicle 2001, for example, to the communication module 2013.

[0419] The drive unit 2002 is configured, for example, as an engine, a motor, or a combination of an engine and a motor. The steering unit 2003 is configured to include at least a steering wheel (also called a handlebar) and to perform directional control on at least one of the front and rear wheels based on the operation of the steering wheel by the user.

[0420] The electronic control unit 2010 consists of a microprocessor 2031, a memory (ROM, RAM) 2032, and a communication port (IO port) 2033. Signals from various sensors 2021-2029 of the vehicle 2001 are input into the electronic control unit 2010. The electronic control unit 2010 can also be referred to as an ECU (Electronic Control Unit).

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

[0422] The information service unit 2012 consists of various devices such as a car navigation system, audio system, speakers, television, and radio, used to provide (output) various information such as driving information, traffic information, and entertainment information, and one or more ECUs that control these devices. The information service unit 2012 uses information obtained from external devices via the communication module 2013, etc., to provide various multimedia information and multimedia services to the occupants of the vehicle 2001.

[0423] The information service unit 2012 may include input devices (e.g., keyboard, mouse, microphone, switch, button, sensor, touch panel, etc.) that accept input from the outside, and output devices (e.g., display, speaker, LED light, touch panel, etc.) that implement output to the outside.

[0424] The driver assistance system unit 2030 comprises various devices used to provide functions for preventing accidents or reducing the driver's workload, such as millimeter-wave radar, LiDAR (Light Detection and Ranging), cameras, locators (e.g., GNSS), map information (e.g., high-definition (HD) mapping, autonomous vehicle (AV) mapping), gyroscope systems (e.g., IMU (Inertial Measurement Unit), INS (Inertial Navigation System)), AI (Artificial Intelligence) chips, and AI processors, and one or more ECUs that control these devices. Furthermore, the driver assistance system unit 2030 sends and receives various information via a communication module 2013 and implements driver assistance or autonomous driving functions.

[0425] The communication module 2013 can communicate with the microprocessor 2031 and the constituent elements of the vehicle 2001 via the communication port. For example, the communication module 2013 sends and receives data between the drive unit 2002, steering control unit 2003, accelerator pedal 2004, brake pedal 2005, gear shift lever 2006, front wheel 2007, rear wheel 2008, axle 2009, microprocessor 2031 in the electronic control unit 2010, and memory (ROM, RAM) 2032 and sensors 2021-29 in the vehicle 2001 via the communication port 2033.

[0426] The communication module 2013 can be controlled by the microprocessor 2031 of the electronic control unit 2010 and is a communication device capable of communicating with external devices. For example, it can transmit and receive various types of information between external devices via wireless communication. The communication module 2013 can be located either inside or outside the electronic control unit 2010. External devices can be, for example, base stations, mobile stations, etc.

[0427] The communication module 2013 can also wirelessly transmit to an external device at least one of the signals input to the electronic control unit 2010 from the various sensors 2021-2029 described above, information obtained based on these signals, and information based on input from an external source (user) obtained via the information service unit 2012. The electronic control unit 2010, the various sensors 2021-2029, and the information service unit 2012 can also be referred to as input units that receive input. For example, the PUSCH transmitted via the communication module 2013 can also contain information based on the aforementioned input.

[0428] The communication module 2013 receives various information (traffic information, signal information, vehicle-to-vehicle information, etc.) sent from external devices and displays it to the information service unit 2012 of the vehicle 2001. The information service unit 2012 can also be referred to as an output unit that outputs information (for example, outputs information to devices such as displays and speakers based on the PDSCH received through the communication module 2013 (or data / information decoded from the PDSCH).

[0429] Furthermore, the communication module 2013 stores various information received from external devices in a memory 2032 that can be utilized by the microprocessor 2031. The microprocessor 2031 can also control the drive unit 2002, steering unit 2003, accelerator pedal 2004, brake pedal 2005, gear shift lever 2006, front wheels 2007, rear wheels 2008, axles 2009, sensors 2021-2029, etc., of the vehicle 2001 based on the information stored in the memory 2032.

[0430] <Meaning and Explanation of Terms>

[0431] The terms "determining" and "determining" as used in this disclosure encompass a wide variety of actions. For example, "determining" or "determining" can include actions such as judging, calculating, computing, processing, deriving, investigating, searching (e.g., searching in a table, database, or other data structure), and ascertaining. Furthermore, "determining" or "determining" can include actions such as receiving (e.g., receiving information), transmitting (e.g., sending information), inputting, outputting, and accessing (e.g., accessing data in memory). Additionally, "determining" or "determining" can include actions such as resolving, selecting, choosing, establishing, and comparing. That is, "judgment" and "decision" can include situations where certain actions are regarded as having been "judged" or "decided". In addition, "judgment (decision)" can also be rewritten as "assuming", "expecting", "considering", etc.

[0432] The terms “connected,” “coupled,” or all variations thereof, refer to all direct or indirect connections or combinations between two or more elements, and can include cases where there is one or more intermediate elements between two mutually “connected” or “coupled” elements. The connection or combination between elements can be physical, logical, or a combination thereof. For example, “connected” can also be rewritten as “access.” In the context of this disclosure, it is possible to consider two elements being mutually “connected” or “coupled” using at least one or more wires, cables, or printed electrical connections, and as several non-limiting and non-exclusive examples, using electromagnetic energy with wavelengths in the wireless frequency domain, microwave region, and light (both visible and invisible) region.

[0433] <Reference Signal>

[0434] The reference signal can also be simply referred to as RS (Reference Signal), and may also be called a pilot depending on the standard applied.

[0435] <The meaning of "based on">

[0436] As used in this disclosure, the term "based on" does not mean "based on only" unless otherwise specified. In other words, the term "based on" means both "based on only" and "based on at least".

[0437] <"First", "Second">

[0438] Any reference to elements using the designations "first," "second," etc., as used in this disclosure does not comprehensively limit the quantity or order of these elements. These designations may be used in this disclosure as a convenient method of distinguishing between two or more elements. Therefore, references to the first and second elements do not imply that only two elements may be used, or that the first element must take precedence over the second element in some form.

[0439] <Unit>

[0440] Alternatively, the term "unit" in the structure of the above devices can be replaced with "section", "circuit", "equipment", etc.

[0441] <Open format>

[0442] In this disclosure, the terms “include,” “including,” and variations thereof, as well as the term “comprising,” refer to inclusion. Furthermore, the term “or” as used in this disclosure does not mean XOR.

[0443] <Time units such as TTI, frequency units such as RB, and radio frame structure>

[0444] A wireless frame can also consist of one or more frames in the time domain. These frames can also be referred to as subframes in the time domain. Furthermore, a subframe can also consist of one or more time slots in the time domain. A subframe can also be a fixed time length (e.g., 1 ms) independent of the parameter set (numerology).

[0445] A parameter set can also be a set of communication parameters applied in at least one of the transmission and reception of a signal or channel. For example, a parameter set can also represent at least one of the following: subcarrier spacing (SCS), bandwidth, symbol length, cyclic prefix length, transmission time interval (TTI), number of symbols per TTI, radio frame structure, specific filtering processing performed by the transmitter and receiver in the frequency domain, and specific windowing processing performed by the transmitter and receiver in the time domain.

[0446] In the time domain, a time slot can also be composed of one or more symbols (OFDM (Orthogonal Frequency Division Multiplexing) symbols, SC-FDMA (Single Carrier Frequency Division Multiple Access) symbols, etc.). A time slot can also be a time unit based on a set of parameters.

[0447] A time slot can also contain multiple mini-time slots. Each mini-time slot can also consist of one or more symbols in the time domain. Furthermore, a mini-time slot can also be called a sub-time slot. A mini-time slot can also consist of fewer symbols than a time slot. A PDSCH (or PUSCH) transmitted in a time unit larger than a mini-time slot can also be called PDSCH (or PUSCH) mapping type A. A PDSCH (or PUSCH) transmitted using mini-time slots can also be called PDSCH (or PUSCH) mapping type B.

[0448] Radio frames, subframes, time slots, mini-time slots, and symbols all represent time units for transmitting signals. Radio frames, subframes, time slots, mini-time slots, and symbols can also be referred to by their respective other names.

[0449] For example, a subframe can also be called a Transmission Time Interval (TTI), multiple consecutive subframes can also be called a TTI, and a time slot or a mini-time slot can also be called a TTI. That is, at least one of a subframe and a TTI can be a subframe in existing LTE (1ms), a period shorter than 1ms (e.g., 1-13 symbols), or a period longer than 1ms. In addition, the unit representing TTI may not be called a subframe, but a time slot, mini-time slot, etc.

[0450] Here, TTI refers, for example, to the smallest unit of time for scheduling in wireless communication. For instance, in an LTE system, the base station schedules radio resources (frequency bandwidth, transmit power, etc., available to each user terminal) in TTI units. However, the definition of TTI is not limited to this.

[0451] TTI can also be a unit of time for transmitting channel-coded data packets (transmission blocks), code blocks, codewords, etc., and can also be a unit of processing such as scheduling and link adaptation. In addition, when a TTI is given, the actual time interval (e.g., the number of symbols) mapped to the transmission block, code block, codeword, etc. can be shorter than the TTI.

[0452] Additionally, where a time slot or a mini-time slot is referred to as a TTI, more than one TTI (i.e., more than one time slot or more than one mini-time slot) can also be the minimum time unit for scheduling. Furthermore, the number of time slots (mini-time slots) constituting the minimum time unit of the schedule can also be controlled.

[0453] A TTI with a duration of 1ms can also be referred to as a normal TTI (TTI in LTE Rel.8-12), standard TTI, long TTI, normal subframe, standard subframe, long subframe, time slot, etc. A TTI shorter than a normal TTI can also be referred to as a shortened TTI, short TTI, partial TTI (partial or fractional TTI), shortened subframe, short subframe, mini time slot, sub-time slot, time slot, etc.

[0454] In addition, a long TTI (e.g., a normal TTI, a subframe, etc.) can also be rewritten as a TTI with a duration of more than 1 ms, and a short TTI (e.g., a shortened TTI, etc.) can also be rewritten as a TTI with a duration of less than a long TTI but more than 1 ms.

[0455] A resource block (RB) is a unit of resource allocation in both the time and frequency domains. In the frequency domain, it can also contain one or more consecutive subcarriers. The number of subcarriers in an RB can be the same regardless of the parameter set, for example, it can be 12. The number of subcarriers in an RB can also be determined based on the parameter set.

[0456] Furthermore, the time domain of an RB can also contain one or more symbols, or it can be the length of a time slot, a mini-time slot, a subframe, or a TTI. A TTI, a subframe, etc., can also be composed of one or more resource blocks.

[0457] In addition, one or more RBs can also be referred to as Physical Resource Blocks (PRBs), Sub-Carrier Groups (SCGs), Resource Element Groups (REGs), PRB pairs, RB pairs, etc.

[0458] Furthermore, a resource block can also consist of one or more resource elements (REs). For example, an RE can also be a radio resource area consisting of a subcarrier and a symbol.

[0459] The Bandwidth Part (BWP) (also known as partial bandwidth, etc.) can also represent a subset of consecutive common resource blocks (RBs) used for a certain parameter set in a certain carrier. Here, common RBs can also be determined by the index of RBs based on the common reference point of that carrier. PRBs can also be defined in a BWP and appended with numbers within that BWP.

[0460] A BWP can also include a UL BWP and a DL BWP. For a UE, one or more BWPs can also be set within a single carrier.

[0461] At least one of the configured BWPs can be active, and the UE may not intend to transmit or receive specific signals / channels outside of the active BWPs. Furthermore, the terms "cell," "carrier," etc., in this disclosure can be rewritten as "BWP."

[0462] The structures described above, such as radio frames, subframes, time slots, mini-time slots, and symbols, are merely illustrative. For example, the number of subframes contained in a radio frame, the number of time slots in each subframe or radio frame, the number of mini-time slots contained within a time slot, the number of symbols and RBs contained in a time slot or mini-time slot, the number of subcarriers contained in an RB, and the number of symbols in a TTI, symbol length, and cyclic prefix (CP) length can be varied in many ways.

[0463] <Maximum Transmit Power>

[0464] The term "maximum transmit power" as used in this disclosure may refer to the maximum value of the transmit power, the nominal maximum transmit power (the nominal UE maximum transmit power), or the rated maximum transmit power (the rated UE maximum transmit power).

[0465] <Article>

[0466] In this disclosure, for example, in cases where articles are added through translation, such as a, an, and the in English, the disclosure may also include cases where the noun following these articles is in a plural form.

[0467] <"Differences">

[0468] In this disclosure, the term "A is different from B" can also mean "A and B are different from each other." Additionally, the term can also mean "A and B are each different from C." Terms such as "separate" and "combined" can also be interpreted in the same way as "different."

[0469] Industrial availability

[0470] One aspect of this disclosure is useful for wireless communication systems.

[0471] Explanation of reference numerals in the attached figures

[0472] 10: Base station; 20: Equipment; 101, 202: Transmitting unit; 102, 201: Receiving unit; 103, 203: Control unit.

Claims

1. A device, which is less complex than a narrowband Internet of Things (NB-IoT) device, wherein the device comprises: The receiving unit receives downlink data from the network; and The control unit generates a response signal indicating whether the decoding of the downlink data was successful or failed.

2. The device as claimed in claim 1, wherein, The device does not maintain a soft buffer for downlink data decoding.

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

4. The apparatus of claim 1, wherein, The device also includes: The transmitting unit sends the response signal to the network after a time interval following the receipt of the downlink data.

5. The apparatus of claim 1, wherein, The device also includes: The transmitting unit sends the response signal to the network after a first time elapsed since the reception of the downlink data and before a second time elapsed since the reception of the downlink data.

6. A communication method, The following steps are performed by a device with lower complexity than narrowband IoT devices, i.e., NB-IoT devices: Receive downlink data from the network. Generate a response signal indicating whether the decoding of the downlink data was successful or failed.

Images