Method and apparatus for repetitive transmission for ambient IoT communication

WO2026169044A1PCT designated stage Publication Date: 2026-08-13LG ELECTRONICS INC
View PDF 0 Cites 0 Cited by

Patent Information

Authority / Receiving Office
WO · WO
Patent Type
Applications
Current Assignee / Owner
Filing Date
2026-02-06
Publication Date
2026-08-13

Smart Images

  • Figure KR2026002240_13082026_PF_FP_ABST
    Figure KR2026002240_13082026_PF_FP_ABST
Patent Text Reader

Abstract

A method, according to one embodiment of the present specification, comprises the steps of: receiving reader-to-device (R2D) control information from a reader; and performing device-to-reader (D2R) transmission to the reader. The D2R transmission is generated on the basis of the block repetition of a D2R transport block. The D2R transport block and one or more transport blocks which are block repetitions of the D2R transport block are transmitted through at least one physical device-to-reader channel (PDRCH) on the basis of the R2D control information.
Need to check novelty before this filing date? Find Prior Art

Description

Repetitive transmission method and device for ambient IoT communication

[0001] The present specification relates to a repetitive transmission method and apparatus for ambient IoT communication.

[0002] The 5G mobile communication system is a successor technology to LTE (Long Term Evolution) and is a new clean-slate type of mobile communication system characterized by high performance, low latency, and high availability. In the case of 5G NR, all available spectrum resources can be utilized, ranging from low-frequency bands below 1 GHz to intermediate frequency bands between 1 GHz and 10 GHz, and high-frequency (millimeter wave) bands above 24 GHz. Based on the underlying technology of 5G mobile communication, 6G mobile communication systems are being developed.

[0003] The 6G (wireless communication) system aims for (i) very high data rates per device, (ii) a very large number of connected devices, (iii) global connectivity, (iv) very low latency, (v) reduced energy consumption of battery-free IoT (internet of things) devices, (vi) ultra-reliable connectivity, and (vii) connected intelligence with machine learning capabilities. The vision of the 6G system can be four aspects: intelligent connectivity, deep connectivity, holographic connectivity, and ubiquitous connectivity.

[0004] Meanwhile, a repetitive transmission operation is defined to meet the requirements for communication coverage in an Ambient IoT communication environment.

[0005] For example, block repetition and bit repetition methods are being considered for Reader-to-Device (R2D) transmission and / or Device-to-Reader (D2R) transmission. Generally, in repetitive transmission methods, a greater time diversity gain can be secured as the same information is transmitted across a temporally distributed range. In this regard, block repetition has the advantage of securing additional time diversity gain compared to bit repetition, as the same information can be transmitted over a wider range of time intervals when the transmission block size is large.

[0006] For Ambient IoT communication, iterative transmission methods for Reader-to-Device transmission (R2D transmission) and / or Device-to-Reader transmission (D2R transmission) are being considered. To achieve efficient R2D transmission and / or D2R transmission in various communication environments, when applying block repetition to transmission blocks, a method or criterion is required to determine whether to transmit the repeated transmission blocks over a single PRDCH (or PDRCH) or over multiple PRDCHs (or PDRCHs). The purpose of this specification is to propose a block iterative transmission method to solve the aforementioned problem.

[0007] Meanwhile, when block repetition is applied to R2D transmission and / or D2R transmission, channel coding may be performed on the repeated transmission blocks. In this case, if channel coding is performed continuously for each of the repeated transmission blocks, the bit stream values ​​of the coded blocks may differ from one another. Consequently, from the receiver's perspective, it is difficult to easily perform combining of the repeated transmission blocks before decoding, which may lead to a degradation in reception performance for the repeated transmission blocks. Another objective of this specification is to propose a channel coding method for transmission blocks to which block repetition is applied in order to solve the aforementioned problems.

[0008] The technical problems to be solved in this specification are not limited to those mentioned above, and other technical problems not mentioned will be clearly understood by those skilled in the art to which this invention belongs from the description below.

[0009] To solve the aforementioned technical problem, a method according to one embodiment of the present specification includes the steps of receiving reader-device control information (R2D control information) from a reader and performing device-to-reader transmission (D2R transmission) to the reader.

[0010] The above D2R transmission is generated based on block repetition of the D2R transport block.

[0011] The above D2R transmission block and one or more transmission blocks in which the above D2R transmission block is block repeated are transmitted through at least one Physical Device-to-Reader Channel (PDRCH) based on the above R2D control information.

[0012] By doing so, by clearly defining a method or criterion for determining whether to transmit the repeated transmission blocks over a single PRDCH (or PDRCH) or over multiple PRDCHs (or PDRCHs), a repeated transmission method adaptable to various communication environments can be provided.

[0013] The above R2D control information may be included in the Physical Reader-to-Device Channel (PRDCH).

[0014] The above PRDCH may include information related to the size of the D2R transport block.

[0015] The above D2R transmission block and the one or more transmission blocks may be transmitted i) through one PDRCH or ii) through different PDRCHs based on the size of the D2R transmission block.

[0016] The above PRDCH may further include information related to the maximum size of the D2R transmission block.

[0017] The above block repetition can be performed based on the size of the D2R transmission block and the maximum size of the D2R transmission block.

[0018] The above D2R transmission block and the one or more transmission blocks may be transmitted through a single PDRCH based on the fact that the size of the D2R transmission block is less than a preset or defined value.

[0019] The above D2R transmission block and the one or more transmission blocks can each be transmitted through different PDRCHs based on the fact that the size of the D2R transmission block is greater than or equal to the preset or defined value.

[0020] The above preset or defined value can be determined based on the maximum size of the transmission block that can be included in the PDRCH and the size of the D2R transmission block.

[0021] The above D2R transmission block and the one or more transmission blocks may be transmitted through one or more PDRCHs based on the maximum number of transmission blocks that can be included in the PDRCH.

[0022] The above maximum number can be determined based on the size of the D2R transmission block.

[0023] The above maximum number can be determined based on the maximum size of the transmission block that can be included in the PDRCH and the size of the D2R transmission block.

[0024] The above D2R transmission can be generated based on channel coding.

[0025] The above channel coding can be performed so that the values ​​of the coded streams generated for each of the D2R transmission block and the one or more transmission blocks become identical.

[0026] The initial values ​​of the shift registers of the channel coding for each of the above D2R transmission block and the one or more transmission blocks can be set to the same values.

[0027] A device according to another embodiment of the present specification comprises one or more transceivers, one or more processors, and one or more memories connected to the one or more processors and storing instructions. The instructions are characterized by causing the device to perform all steps of any one of the methods based on execution by the one or more processors.

[0028] An apparatus according to another embodiment of the present specification comprises one or more memories and one or more processors connected to the one or more memories. The one or more memories are characterized by storing instructions that cause the apparatus to perform all steps of any one of the methods based on execution by the one or more processors.

[0029] A non-transitory computer-readable storage medium according to another embodiment of the present specification stores instructions. The instructions, executable by one or more processors, are characterized by causing a device to perform all steps of any one of the methods.

[0030] A method according to another embodiment of the present specification includes the steps of transmitting reader-device control information (R2D control information) to a device and receiving device-reader transmission (D2R transmission) from the device.

[0031] The above D2R transmission is generated based on block repetition of the D2R transport block.

[0032] The above D2R transmission block and one or more transmission blocks in which the above D2R transmission block is block repeated are transmitted through at least one Physical Device-to-Reader Channel (PDRCH) based on the above R2D control information.

[0033] A reader according to another embodiment of the present specification comprises one or more transceivers, one or more processors, and one or more memories connected to the one or more processors and storing instructions. The instructions are characterized by causing the reader to perform all steps of any one of the methods based on execution by the one or more processors.

[0034] Block repetition can be applied to R2D or D2R transmission for Ambient IoT communication. When block-repeated transmission blocks are transmitted over a single PRDCH (or PDRCH), there is an advantage that the signaling overhead is relatively small compared to when the transmission blocks are transmitted over multiple PRDCHs (or PDRCHs). On the other hand, when block-repeated transmission blocks are transmitted over multiple PRDCHs (or PDRCHs), frequency hopping can be applied to each PRDCH (or PDRCH), and there is also an advantage that each PRDCH (or PDRCH) can be transmitted discontinuously so that the repeated transmission blocks are distributed in the time domain. According to the embodiments of the present specification, by clearly defining a method or criterion for determining whether to transmit repeated transmission blocks over a single PRDCH (or PDRCH) or over a plurality of PRDCHs (or PDRCHs), a repeated transmission method adaptable to various communication environments, including cases where transmission reliability is required and cases where relatively simple transmission is sufficient, can be provided.

[0035] Meanwhile, when block repetition is applied to R2D transmission or D2R transmission, channel coding may be performed on the repeated transmission blocks. According to an embodiment of the present specification, when channel coding is performed on repeated transmission blocks, the bit stream values ​​of the coded blocks are set to be identical, thereby facilitating the combination of repeated blocks from the perspective of the receiver, and as a result, the reception performance of the receiver for R2D transmission and / or D2R transmission may be improved.

[0036] The effects obtainable in this specification are not limited to those mentioned above, and other unmentioned effects will be clearly understood by those skilled in the art from the description below.

[0037] The drawings attached below are intended to aid in understanding the present specification and may provide embodiments of the present specification along with detailed descriptions. However, the technical features of the present specification are not limited to specific drawings, and features disclosed in each drawing may be combined with one another to form new embodiments. Reference numerals in each drawing may denote structural elements.

[0038] Figure 1 is an example showing a topology of direct connection between a base station and an A-IoT device.

[0039] Figure 2 is an example showing a topology in which a base station and an A-IoT device are connected through an intermediate node.

[0040] Figure 3 is an example showing a topology supported by auxiliary nodes.

[0041] Figure 4 is another example showing a topology supported by auxiliary nodes.

[0042] Figure 5 is an example showing a topology of direct connection between a terminal and an A-IoT device.

[0043] Figure 6 shows an example of power consumption and device energy status according to the operating state of an energy harvesting-based device.

[0044] Figure 7 is an example showing a combination of Deployment scenario 1 and topology 1 with various CWs.

[0045] Figure 8 is an example showing a combination of Deployment scenario 2 and topology 2 with various CWs.

[0046] Figure 9 shows an example of UHF passive RFID application.

[0047] Figure 10 is an example showing the relationship between the OFDM symbol and the chip in Method Type 2.

[0048] Figure 11 is a diagram illustrating the sequence of PDRCH signal generation according to the repetitive transmission type.

[0049] FIG. 12 is a diagram illustrating a channel coding method according to an embodiment of the present specification.

[0050] FIG. 13 is a drawing for explaining a method according to one embodiment of the present specification.

[0051] FIG. 14 is a drawing for illustrating a method according to another embodiment of the present specification.

[0052] FIG. 15 is a drawing showing the configuration of a first device and a second device according to an embodiment of the present specification.

[0053] In this specification, "A or B" may mean "only A," "only B," or "both A and B." Alternatively, in this specification, "A or B" may be interpreted as "A and / or B." For example, in this specification, "A, B or C" may mean "only A," "only B," "only C," or "any combination of A, B and C."

[0054] A slash ( / ) or a comma used in this specification may mean "and / or." For example, "A / B" may mean "A and / or B." Accordingly, "A / B" may mean "only A," "only B," or "both A and B." For example, "A, B, C" may mean "A, B or C."

[0055] In this specification, "at least one of A and B" may mean "only A," "only B," or "both A and B." Additionally, in this specification, the expressions "at least one of A or B" or "at least one of A and / or B" may be interpreted as synonymous with "at least one of A and B."

[0056] Additionally, in this specification, "at least one of A, B and C" may mean "only A," "only B," "only C," or "any combination of A, B and C." Also, "at least one of A, B or C" or "at least one of A, B and / or C" may mean "at least one of A, B and C."

[0057] Additionally, parentheses used in this specification may mean "for example." Specifically, when indicated as "control information (PDCCH)," "PDCCH" may be proposed as an example of "control information." In other words, "control information" in this specification is not limited to "PDCCH," and "PDCCH" may be proposed as an example of "control information." Furthermore, even when indicated as "control information (i.e., PDCCH)," "PDCCH" may be proposed as an example of "control information."

[0058] In the following explanation, 'when, if, in case of' can be replaced with 'based on'.

[0059] Technical features described individually within a single drawing in this specification may be implemented individually or simultaneously.

[0060] In this specification, a higher layer parameter may be a parameter that is set for the terminal, pre-set, or pre-defined. For example, a base station or a network may transmit the higher layer parameter to the terminal. For example, the higher layer parameter may be transmitted via radio resource control (RRC) signaling or medium access control (MAC) signaling.

[0061] In this specification, "set or defined" may be interpreted as being set or pre-configured to the device through pre-defined signaling (e.g., SIB, MAC, RRC) from a base station or network. In this specification, "set or defined" may be interpreted as being pre-configured to the device.

[0062] In this specification, user equipment (UE) may refer to portable devices, wireless devices, etc. In this specification, base station (BS) may refer to a radio access network (RAN) node, a transmission reception point (TRP), a network, an integrated access and backhaul (IAB) node, a portable device, a wireless device, etc.

[0063] In the following, the downlink (DL) refers to communication from a base station to a terminal, and the uplink (UL) refers to communication from a terminal to a base station. In the downlink, the transmitter may be part of the base station and the receiver may be part of the terminal. In the uplink, the transmitter may be part of the terminal and the receiver may be part of the base station. The base station may be referred to as the first communication device and the terminal as the second communication device. The base station (BS) may be replaced by terms such as fixed station, Node B, eNB (evolved-NodeB), gNB (Next Generation NodeB), BTS (base transceiver system), Access Point (AP), network (5G network), AI system, RSU (road side unit), vehicle, robot, drone (Unmanned Aerial Vehicle, UAV), AR (Augmented Reality) device, VR (Virtual Reality) device, etc. In addition, the terminal may be fixed or mobile and may be replaced with terms such as UE (User Equipment), MS (Mobile Station), UT (user terminal), MSS (Mobile Subscriber Station), SS (Subscriber Station), AMS (Advanced Mobile Station), WT (Wireless terminal), MTC (Machine-Type Communication) device, M2M (Machine-to-Machine) device, D2D (Device-to-Device) device, vehicle, robot, AI module, drone (Unmanned Aerial Vehicle, UAV), AR (Augmented Reality) device, VR (Virtual Reality) device.

[0064] Ambient IoT (A-IoT)

[0065] Below, Ambient IoT (A-IoT) is explained.

[0066] A-IoT can be a new type of device or segment that operates solely on energy harvested from the surrounding environment. For example, A-IoT may refer to a new class of Internet of Things devices that operate by being powered by various energy sources harvestable from the surrounding environment, such as radio waves, light, motion, and thermal energy. Table 1 shows examples of use cases for A-IoT. Table 2 shows matters related to IoT communications discussed in the 3GPP RAN.

[0067]

[0068]

[0069] For example, active signal generation and / or backscattering may be one of the communication technologies considered to achieve low-power operation of A-IoT devices. For example, backscattering is a widely used technique in radio frequency identification (RFID) that can enable a device to communicate with a network by reflecting incident waves after modulating them with information to be transmitted. For example, the device may be powered by an incident RF signal or stored energy.

[0070] For example, A-IoT devices can be classified into various device types, such as passive, semi-passive, and active, depending on the energy storage and transmission signal generation methods. For example, a passive device does not have an energy storage device (e.g., a capacitor) and can communicate based on backscatter communication technology. For example, a semi-passive device has an energy storage device and can communicate using backscatter communication technology with the assistance of the energy storage device. For example, an active device has an energy storage device and can communicate by actively generating signals using active RF components and stored energy. For example, in this specification, the following three types of IoT devices may be considered. For example, device A may be a device without energy storage and without independent signal generation (e.g., a device supporting backscatter transmission). For example, device B may be a device with energy storage and without independent signal generation (e.g., a device supporting backscatter transmission). In this case, for example, the use of stored energy may include amplification of the reflected signal. For example, device C may be a device with energy storage and independent signal generation (e.g., a device with an active RF component for transmission).

[0071] For example, the following basic topologies may be considered to support A-IoT devices in indoor and outdoor scenarios. For example, basic topologies may include a direct connection between a base station and an A-IoT device, a connection between a base station, an intermediate node, and an A-IoT device, support for connection by an auxiliary node, and / or a connection between a terminal and an A-IoT device. The basic topologies proposed herein are merely examples, and the proposals in this specification may be extended and applied to other topologies.

[0072] FIG. 1 is an example illustrating a topology in which a base station and an A-IoT device are directly connected. Specifically, FIG. 1 illustrates a topology in which a base station and an A-IoT device are directly connected (e.g., Topology 1) according to one embodiment of the present specification. The embodiment of FIG. 1 may be combined with various embodiments of the present specification.

[0073] Referring to FIG. 1, an A-IoT device can communicate directly and bidirectionally with a base station. For example, communication between a base station and an A-IoT device may include A-IoT data and / or signals. For example, A-IoT data and / or signals may be transmitted or received based on a control channel and / or a data channel (e.g., a shared channel). In the embodiment of FIG. 1, the base station transmitting to the A-IoT device and the base station receiving from the A-IoT device may be different. For example, in the topology 1, a base station in a micro-cell environment and an A-IoT device can communicate directly with each other. For example, the base station may be located at a co-site with a base station equipped with existing 3GPP technology.

[0074] FIG. 2 is an example illustrating a topology in which a base station and an A-IoT device are connected through an intermediate node. Specifically, FIG. 2 illustrates a topology (e.g., Topology 2) in which a base station and an A-IoT device are connected through an intermediate node, according to one embodiment of the present specification. The embodiment of FIG. 2 may be combined with various embodiments of the present specification.

[0075] Referring to FIG. 2, an A-IoT device can communicate bidirectionally with an intermediate node between the device and the base station. Here, for example, the intermediate node may be an A-IoT-enabled relay, IAB node, terminal, repeater, etc. For example, the intermediate node may transmit A-IoT data and / or signals between the base station and the A-IoT device. For example, A-IoT data and / or signals may be transmitted or received based on a control channel and / or a data channel (e.g., a shared channel). In the embodiment of FIG. 2, the intermediate node transmitting to the A-IoT device and the intermediate node receiving from the A-IoT device may be different. For example, in the topology 2, an intermediate node may exist between the base station in a macro-cell environment and the A-IoT device. For example, the base station may be located at a co-site with a base station equipped with existing 3GPP technology. For example, the intermediate node may be limited to a terminal, and the intermediate node may be located indoors.

[0076] Figure 3 is an example showing a topology supported by auxiliary nodes.

[0077] Figure 4 is another example showing a topology supported by auxiliary nodes.

[0078] Specifically, FIGS. 3 and 4 illustrate a topology (e.g., topology 3) supported by an auxiliary node according to one embodiment of the present specification. The embodiment of FIGS. 3 and 4 may be combined with various embodiments of the present specification.

[0079] Referring to FIG. 3, an auxiliary node may be supported for downlink reception. For example, an A-IoT device may transmit data / signals to a base station, and the A-IoT device may receive data / signals from the auxiliary node. Referring to FIG. 4, an auxiliary node may be supported for uplink transmission. For example, an A-IoT device may receive data / signals from a base station, and the A-IoT device may transmit data / signals to the auxiliary node. Here, for example, the auxiliary node may be an A-IoT-enabled relay, IAB node, terminal, repeater, etc.

[0080] FIG. 5 is an example illustrating a topology in which a terminal and an A-IoT device are directly connected. Specifically, FIG. 5 illustrates a topology in which a terminal and an A-IoT device are directly connected (e.g., topology 4) according to one embodiment of the present specification. The embodiment of FIG. 5 may be combined with various embodiments of the present specification.

[0081] Referring to FIG. 5, an A-IoT device can communicate bidirectionally with a terminal. For example, communication between the terminal and the A-IoT device may include A-IoT data and / or signals. For example, A-IoT data and / or signals may be transmitted or received based on a control channel and / or a data channel (e.g., a shared channel).

[0082] For example, transmission by an A-IoT device can be performed in the frequency division duplexing (FDD) spectrum (e.g., FDD UL spectrum).

[0083] Meanwhile, a study item titled "Study on solutions for Ambient IoT (Internet of Things) in NR" was approved in 3GPP NR release 19. Specifically, the study item is scheduled to proceed in 3GPP NR release 19 based on the following content.

[0084] This study aims to further evaluate Ambient IoT at the RAN WG level, a new 3GPP IoT technology suitable for deployment in 3GPP systems, which relies on ultra-low complexity devices with ultra-low power consumption for very low-level IoT applications. This study must provide a clear differentiation; that is, it must address use cases and scenarios that cannot be met based on existing 3GPP LPWA IoT technologies (e.g., NB-IoT with reduced peak Tx power).

[0085] General range

[0086] The definitions provided in TR 38.848 apply to this SI, and the following are exclusive general scopes.

[0087] A. The overall objective is to research a harmonized wireless interface design that minimizes differences when Ambient IoT is required to enable the following devices.

[0088] i. ~1μW peak power consumption, energy storage, initial sampling frequency offset (SFO) of up to 10X ppm, no DL or UL amplification in the device. The device's UL transmission is backscattered from the externally provided carrier wave.

[0089] ii. Peak power consumption ≤ several hundred μW1, energy storage, initial sampling frequency offset (SFO) of up to 10X ppm, and DL and / or UL amplification in the device. UL transmission in the device may be generated internally or backscattered from carrier waves provided externally.

[0090] -X is determined in WG.

[0091] -Coverage design target: Up to 10-50m distance with the device indoors according to TR 38.848: "...range where WG can sub-select".

[0092] - According to TR 38.848, for Topologies 1 and 2 (UEs acting as intermediate nodes under NW control), there is no RRC state, no mobility (i.e., no functions such as cell selection / reselection at least), no HARQ, and no ARQ.

[0093] Note 1: It should be understood that the WG has no duty to set a specific value for "≤ hundreds of μW", and that determining whether the proposed design and its power consumption meet the "≤ hundreds of μW" requirement is a matter for the WG to discuss.

[0094] B. Deployment scenarios with the following characteristics, referring to the table in Clause 4.2.2 of TR 38.848:

[0095] - Deployment Scenario 1 using Topology 1

[0096] Base Station and Coexistence Characteristics: Microcells, Co-sites

[0097] - Deployment Scenario 2 using a UE as an intermediate node under Topology 2 and network control

[0098] Base Station and Coexistence Characteristics: Macro Cells, Co-sites

[0099] The location of the intermediate node is indoors

[0100] C. FDD's FR1 License Spectrum.

[0101] D. In-band spectrum distribution for NR, guard band for LTE / NR, standalone band(s)

[0102] E. Traffic types DO-DTT, DT focused on rUC1 (Indoor Inventory) and rUC4 (Indoor Command).

[0103] - In RAN#104, this study evaluates whether a harmonized wireless interface design (see bullet point 'A' above) can handle DO-A (Device-Initiated Autonomous) use cases and identifies which parts of the harmonized wireless interface design (see bullet point 'A' above) are insufficient for DO-A use cases.

[0104] Transmission from surrounding IoT devices (including backscattering when in use) may occur at least within the UL spectrum.

[0105] The next goal is set within the general range.

[0106] 1. Evaluation Assumptions

[0107] a) Conclude at least the following aspects of the design objectives left to the WG in Clause 5 (RAN Design Objectives) of TR 38.848 [RAN1].

[0108] Clause 5.3: Applicable maximum distance target value

[0109] Clause 5.6: Refine the definition of latency suitable for use in the RAN WG.

[0110] Clause 5.8: 2D distribution of the device

[0111] b) Define the necessary additional evaluation assumptions for deployment scenarios for coverage and coexistence evaluation. [RAN1, RAN4]

[0112] c) Identify the basic blocks / components of possible peripheral IoT device architectures by considering modern implementations of low-power, low-complexity devices that meet RAN design goals regarding power consumption and complexity. [RAN1]

[0113] d) Define link budget calculations for coverage, including whether / how to model carrier waves at nodes inside or outside the connection topology.

[0114] Note: The evaluation performance of the design target falls within the scope of the feasibility and necessity study of the proposal in the following objectives. For example, it involves inspecting the reference implementation in the field, performing simulations, and conducting analytical analysis.

[0115] Note: We strive to minimize evaluation cases in RAN1.

[0116] 2. Investigate necessary and viable solutions for Ambient IoT as defined in the general scope. This includes determining which functions, procedures, etc. are necessary and which are not, and ensuring at least the essential functions specified in Section 6.2 of TR 38.848.

[0117] Rel-19 localization studies are led by RAN3 and are limited to features that have no or minimal impact on the specification (Note: This does not imply decisions related to WI generation).

[0118] We study the feasibility and necessary functions for proximity determination (coordination with SA3 is necessary for privacy reasons).

[0119] - RAN1-led:

[0120] For Ambient IoT DL and UL:

[0121] Frame structure, synchronization and timing, random access

[0122] Numerology, Bandwidth, and Multiple Access

[0123] Waveform and Modulation

[0124] Channel coding

[0125] Downlink Channel / Signal Aspect

[0126] Uplink Channel / Signal Side

[0127] Scheduling and Timing Relationships

[0128] We study the necessary characteristics of carrier wave waveforms provided externally to ambient IoT devices, including interference processing at ambient IoT UL receivers and NR base stations.

[0129] For Topology 2, there is no difference in the physical layer design compared to Topology 1.

[0130] RAN2 Lead:

[0131] We research and determine the functions required for the Ambient IoT Compact Protocol stack and lightweight signaling procedures that enable DO-DTT and DT data transmission, and study those functions.

[0132] for example:

[0133] Paging

[0134] Random access

[0135] Data transmission including necessary wireless resource control aspects that comply with general range limitations

[0136] Interaction with the upper class

[0137] Features not listed above are researched only if deemed essential.

[0138] RAN3 Leading:

[0139] Identify the necessary effects on the signals and procedures of the CN-RAN interface to enable the following.

[0140] Paging

[0141] Device Context Management

[0142] Data transmission

[0143] Identify RAN architecture aspects, including whether partitioned architecture support is required.

[0144] Identify potential solutions for finding Ambient IoT devices without impacting specifications. For example, reuse existing user location reports or transmit location information to the core network with minimal impact on specifications.

[0145] RAN4 Leading:

[0146] Research on the coexistence of Ambient IoT and NR / LTE.

[0147] Research on RF Requirements for Ambient IoT:

[0148] Ambient IoT BS Transmitter / Receiver

[0149] Ambient IoT devices and transmission / reception based on general range

[0150] Intermediate node (UE) and transmission / reception based on general range

[0151] RAN2 and RAN3 are expected to cooperate with SA2 to identify RAN-CN functional splits.

[0152] Note: This study targets IoT segments that are much lower than existing 3GPP IoT technologies (e.g., NB-IoT, eMTC, RedCap, etc.). This study does not aim to replace existing 3GPP LPWA technologies.

[0153] For example, as described above, the types of A-IoT devices can be classified into two as follows. For example, a Type 1 device has a maximum power consumption of approximately 1 uW, is capable of energy storage, has no amplification function, and can perform transmission by backscattering a carrier wave (CW) provided from an external source (e.g., a reader such as a base station or terminal, or a separate node). For example, a Type 2 device has a maximum power consumption of approximately several hundred uW, is capable of energy storage, has an amplification function, and can perform transmission by backscattering a carrier wave (CW) provided from an external source (e.g., a reader such as a base station or terminal, or a separate node) or by using a signal generated internally.

[0154] For example, in addition to the classification methods described above, the type / class of an A-IoT device may be distinguished based on parameters associated with device characteristics (e.g., presence / capacity of energy storage, degree of energy / power consumption, presence / capability of amplification, presence / capability of a band-pass filter (BPF), supported DL / UL transmission method(s), etc.) or combinations of parameters. Here, for example, the BPF capability may be distinguished by the 3-dB bandwidth of the supported BPF, sharpness, etc., and the UL transmission methods may be distinguished by, for example, backscattered UL transmission, UL transmission by internal signal generation, etc.

[0155] In addition, the type / class of an A-IoT device may be subdivided based on parameters associated with the above device characteristics (e.g., presence / capacity of energy storage, degree of energy / power consumption, presence / capability of amplification, presence / capability of a band-pass filter (BPF), supported DL / UL transmission method(s), etc.) or combinations of such parameters. For example, the above-described Type 2 device may be classified into Type 2a when it performs transmission by backscattering a carrier wave (CW) provided from an external source (e.g., a reader such as a base station or terminal, or a separate node), and Type 2b when it performs transmission using a signal generated internally. In this case, Types 2a and 2b may be identical in that they have a maximum power consumption of approximately several hundred uW, are capable of energy storage, and have amplification capabilities.

[0156] For example, some types / classes of A-IoT devices (e.g., device B, device C, type 1 device, and / or type 2 device) may be equipped with energy storage capabilities (e.g., capacitors or charging batteries) for the following purposes.

[0157] - Securing stable energy at the time of reception / transmission

[0158] - Operation of low-power communication modules through energy storage in low RF energy states

[0159] For example, the minimum RF reception sensitivity for operating a low-power communication module may be -20dBm, and the minimum reception sensitivity for energy harvesting may be -20dBm. In this case, if the received power of the A-IoT device is distributed between -30 and -20dBm, communication may be impossible without a capacitor, and communication may be possible after a charging time with a capacitor.

[0160] - Store energy harvested from different energy sources (e.g., solar, thermal, wind, kinetic, etc.) in a single capacitor to operate a low-power communication module at a desired time.

[0161] FIG. 6 illustrates examples of power consumption and device energy status according to the operating state of an energy harvesting-based device. Specifically, FIG. 6 illustrates examples of power consumption and device energy status according to the operating state of an energy harvesting-based device having energy storage capabilities, according to one embodiment of the present specification. The embodiment of FIG. 6 may be combined with various embodiments of the present specification.

[0162] Referring to FIG. 6(b), S1 may be a sleep state, S2 may be an active state, and P1 and P2 may be power consumption in S1 and S2, respectively. For example, the active state may refer to a state in which the device consumes power to perform operations such as receiving / transmitting for communication or sensing, and the sleep state may be a state that is not an active state.

[0163] FIG. 6(a) may represent the device energy state corresponding to FIG. 6(b). Referring to FIG. 6(a), the E1 and E2 values ​​may vary by device (type / class), and the device may report information related to the E1 value and / or information related to the E2 value to R and / or the base station as capability parameters. For example, the E2 value may be defined as the energy value in the buffered state, and the E1 value as the minimum energy value required in the active state.

[0164] For example, the transition from S1 to S2 may be possible only when the device energy state value is E2 or reaches E2. For example, the transition from S1 to S2 may be possible when the device energy state value is greater than E1 (i.e., within the range between E1 and E2). An embodiment of FIG. 6 illustrates an example in which the transition from S1 to S2 is performed when the device energy state value is E2 or reaches E2.

[0165] For example, an A-IoT device may require an externally provided CW for backscatter transmission. For example, the CW can be used to supply energy to A-IoT devices or as a CW for DL ​​transmission, regardless of the transmission mode (e.g., backscatter transmission or internally generated transmission).

[0166] For example, CW waveforms can be supported in various types. For instance, the type of CW waveform can be a single-tone CW waveform or a somewhat complex multi-tone CW waveform. For instance, single-tone CW may be advantageous over multi-tone CW in terms of the multiplexing capacity of tags or readers and in terms of interference, as it uses fewer resources. On the other hand, multi-tone CW has advantages, such as the ability to deliver more energy when transmitting CW over DL and to secure greater coverage on a single device.

[0167] Considering the advantages of these different CW waveform types, multiple CW waveform types may be supported in an A-IoT system, and the base station / IN / AN / UE may configure the CW waveform type. For example, one or more CW waveform types supported in the A-IoT communication system may be pre-configured / defined, and the base station / IN / AN / UE may select one of the one or more supported CW waveform types and transmit it to an A-IoT device. For example, the base station / IN / AN / UE may configure / instruct / display the selected CW waveform type to the A-IoT device in the form of a command / message transmitted as a preamble / frame-sync or payload.

[0168] For example, in this specification, for A-IoT communication, at least one of the necessary characteristics of a carrier waveform for a carrier provided outside the A-IoT device (including interference handling at the A-IoT device UL receiver and NR base station) may be proposed. For example, in this specification, for A-IoT communication, at least one of paging, random access, data transmission including necessary radio resource control aspects complying with general range limitations, interaction with upper layers (e.g., RRC layer, NAS (non-access stratum) layer, application layer, etc.), device context management, data transmission, coexistence of A-IoT and 6G / NR / LTE, and / or RF requirements for A-IoT may be proposed.

[0169] For example, technical terms used in this specification may be as follows.

[0170] - SSB: Synchronization Signal Block

[0171] - MIB: Master Information Block

[0172] - RMSI: Remaining Minimum System Information

[0173] - FR1: Frequency Range 1. Refers to the frequency range of 6 GHz or lower (e.g., 450 MHz ~ 6000 MHz).

[0174] - FR2: Frequency Range 2. Refers to the millimeter wave (mmWave) region above 24 GHz (e.g., 24,250 MHz ~ 52,600 MHz).

[0175] - BW: Bandwidth

[0176] - BWP: Bandwidth Part

[0177] - RNTI: Radio Network Temporary Identifier

[0178] - CRC: Cyclic Redundancy Check

[0179] - SIB: System Information Block

[0180] - SIB1: SIB1 for NR devices (i.e., Remaining Minimum System Information (RMSI)). Broadcasts information necessary for cell connection of NR terminals.

[0181] - CORESET: Control Resource Set. The time / frequency resource when the NR terminal attempts candidate PDCCH decoding.

[0182] - CORESET#0: CORESET for Type0-PDCCH CSS set for NR devices (configured in MIB)

[0183] - Type0-PDCCH CSS set: a search space set in which an NR UE monitors a set of PDCCH candidates for a DCI format with CRC scrambled by a SI-RNTI

[0184] - MO: PDCCH Monitoring Occasion for Type0-PDCCH CSS set

[0185] - SIB1-R: (additional) SIB1 for reduced capability NR devices. This may be limited to cases where it is created as a separate TB from SIB1 and transmitted via a separate PDSCH.

[0186] - CORESET#0-R: CORESET#0 for reduced capability NR devices

[0187] - Type0-PDCCH-R CSS set: a search space set in which a redcap UE monitors a set of PDCCH candidates for a DCI format with CRC scrambled by a SI-RNTI

[0188] - MO-R: PDCCH Monitoring Occasion for Type0-PDCCH CSS set

[0189] - Cell defining SSB (CD-SSB): An NR SSB that includes RMSI scheduling information

[0190] - Non-cell defining SSB (non-CD-SSB): Refers to an SSB deployed in an NR sync raster that does not include the corresponding cell's RMSI scheduling information for measurement purposes. However, it may include information indicating the location of the cell defining SSB.

[0191] - SCS: subcarrier spacing

[0192] - SI-RNTI: System Information Radio-Network Temporary Identifier

[0193] - Camp on: “Camp on” is the UE state in which the UE stays on a cell and is ready to initiate a potential dedicated service or to receive an ongoing broadcast service.

[0194] - TB: Transport Block

[0195] - RSA (Redcap standalone): Redcap device 또는 service만 지원하는 cell.

[0196] - SIB1(-R)-PDSCH: SIB1(-R)을 전송하는 PDSCH

[0197] - SIB1(-R)-DCI: SIB1(-R)-PDSCH를 scheduling하는 DCI. DCI format 1_0 with CRC scrambled by SI-RNTI.

[0198] - SIB1(-R)-PDCCH: SIB1(-R)-DCI를 전송하는 PDCCH

[0199] - FDRA: Frequency Domain Resource Allocation

[0200] - TDRA: Time Domain Resource Allocation

[0201] - RA: Random Access

[0202] - MSGA: preamble and payload transmissions of the random access procedure for 2-step RA type.

[0203] - MSGB: response to MSGA in the 2-step random access procedure. MSGB may consist of response(s) for contention resolution, fallback indication(s), and backoff indication.

[0204] - RO-N: normal UE 4-step RACH and 2-step RACH(if configured)를 위한 RO(RACH Occasion)

[0205] - RO-N1, RO-N2: When separate ROs are configured for normal UE 2-step RACH, they are distinguished as RO-N1 (4-step) and RO-N2 (2-step).

[0206] - RO-R: RO (RACH Occasion) configured separately from RO-N for RedCap UE 4-step RACH and 2-step RACH (if configured)

[0207] - RO-R1, RO-R2: When separate ROs are configured for Redcap UE 2-step RACH, they are distinguished as RO-R1 (4-step) and RO-R2 (2-step).

[0208] - PG-R: MsgA-Preambles Group for redcap UEs

[0209] - RAR: Random Access Response

[0210] - RAR window: the time window to monitor RA response(s)

[0211] - FH: Frequency Hopping

[0212] - iBWP: initial BWP

[0213] - iBWP-DL(-UL): initial DL(UL) BWP

[0214] - iBWP-DL(-UL)-R: (separate) initial DL(UL) BWP for RedCap

[0215] - CS: Cyclic shift

[0216] - NB: Narrowband

[0217] - TO: Traffic Offloading

[0218] -mMTC; Massive Machine Type Communications

[0219] - eMBB: enhanced Mobile Broadband Communication

[0220] - URLLC: Ultra-Reliable and Low Latency Communication

[0221] - RedCap: Reduced Capability

[0222] - eRedCap: enhanced RedCap

[0223] - FDD: Frequency Division Duplex

[0224] - HD-FDD: Half-Duplex-FDD

[0225] - DRX: Discontinuous Reception

[0226] - RRC: Radio Resource Control

[0227] - RRM: Radio Resource Management

[0228] - MM: Mobility Management

[0229] - IWSN: Industrial Wireless Sensor Network

[0230] - LPWA: Low Power Wide Area

[0231] - RB: Resource Block

[0232] - CCE: Control Channel Element

[0233] - AL: Aggregation Level

[0234] - PRG: Physical Resource-block Group

[0235] - DFT-s-OFDM: DFT-spread OFDM

[0236] - PBCH: Physical Broadcast Channel

[0237] - A-PBCH: Additional PBCH

[0238] - BD: blind detection

[0239] - EPRE: Energy Per RE

[0240] - SNR: Signal-to-Noise Ratio

[0241] - TDM: Time Division Multiplexing

[0242] - FDM: Frequency Division Multiplexing

[0243] - DMRS: DeModulation Reference Signal

[0244] - TDD: Time Division Duplex

[0245] - PCI: Physical layer Cell ID

[0246] - EH: Energy Harvesting

[0247] - EH device: A device that operates based on EH. It may include all of Device A / B / C currently under discussion at 3GPP. Additionally, while the present invention primarily considers RF EH, the EH device does not necessarily have to be RF EH-based.

[0248] - ES: Energizing Signal. A signal / channel transmitted by a base station / IN / AN / UE for the purpose of supplying RF energy to a device operating on an RF-based energy harvesting basis. (Modulated) CW, NR / LTE DL / UL signals, etc. can be ES, and a dedicated signal / channel for ES can be designed to support it.

[0249] - ET: Energy Transfer

[0250] - CW: Carrier wave. Ambient IoT devices supporting backscattering-based UL transmission transmit information by modulating and backscattering the “externally provided” CW. Ambient IoT devices supporting independent signal generation-based UL transmission transmit information by modulating the “internally generated” CW. Unless otherwise noted, it is assumed to refer to the “externally provided” CW for backscattering. The CW can be used as an ES (Energizing Signal) for RF energy transfer.

[0251] - CWN: Carrier Wave Node. A node that provides the above CW. It may be a base station, IN, AN, or UE, and a separate CWN may exist for the purpose of providing CW.

[0252] - R: Reader / Interrogator. This is an RFID standard term. In the 3GPP Ambient IoT context, depending on the topology, gNBs / eNBs, intermediate / assisting nodes, UEs, etc., can act as readers. Furthermore, since Ambient IoT is not limited to 4G / 5G communication systems, it can include base stations, intermediate / assisting nodes, and UEs of next-generation communication systems. It may also refer to an Ambient IoT reader.

[0253] - T: Tag / ambient IoT device. An RFID standard term. In the present invention, it can be interchangeably used with EH device, and in the 3GPP Ambient IoT context, it mainly refers to Ambient IoT device, Device A / B / C.

[0254] - D: Ambient IoT device (may have the same meaning as T above)

[0255] - R=>T: Reader-to-Tag or Reader-to-Tag communication link. If the base station or intermediate / assisting node is the reader, it may have the same meaning as DL or forward link.

[0256] - R2D: R-to-D link (Can be synonymous with R=>T. Can be denoted as R=>D.)

[0257] - CW2D: CWN-to-D link (CW node to Ambient IoT device link)

[0258] - T=>R: Tag-to-Reader or Tag-to-Reader communication link. If the base station or intermediate / assisting node is the reader, it may have the same meaning as UL or reverse / backward link.

[0259] - D2R: May have the same meaning as T=>R. Can be written as D=>R.

[0260] - R<=>T: Includes cases of R=>T and T=>R, or R=>T or T=>R. May apply to both R=>T and T=>R.

[0261] - R<=>D: Includes cases of R2D and D2R, or R2D or D2R. May apply to both R2D and D2R. (May have the same meaning as R<=>T)

[0262] - RF-EH: RF energy harvesting

[0263] - PRDCH: Physical R2D CHannel (may be denoted as PR2DCH). Physical channel for R2D communication.

[0264] - PDRCH: Physical D2R CHannel (may be denoted as PD2RCH). Physical channel for D2R communication.

[0265] - BS: Base Station

[0266] - IN: Intermediate node. In Topology 2 (BS ↔ IN ↔ Ambient IoT device), IN acts as a reader. Relays, IABs, UEs, repeaters, etc., can be INs.

[0267] - AN: Assisting node. It can assist with DL transmission in Topology 3-1 (BS AN Ambient IoT device BS) or assist with UL transmission in Topology 3-2 (BS Ambient IoT device AN BS). Relays, IABs, UEs, repeaters, etc. can be ANs.

[0268] - UE: User Equipment. In the case of LTE, NR, or next-generation communication systems, it refers to the LTE, NR, or next-generation communication system UE / terminal, respectively. It is a general wireless communication terminal form distinct from Ambient IoT devices or Devices A / B / C. In Topology 4 (UE ↔ Ambient IoT device), the UE acts as a reader.

[0269] - Device: Unless otherwise noted, and when used alone, it refers to the EH device, Ambient IoT device, or Device A / B / C without distinction.

[0270] - AmIoT: Ambient IoT (=A-IoT)

[0271] - F-gap: Frequency gap

[0272] - T-gap: Time gap

[0273] - TD: Time Domain

[0274] - FD: Frequency Domain

[0275] - PEI: Paging Early Indication

[0276] - LP-WUS: Low-Power Wake-Up Signal

[0277] - LP-SS: Low-Power Synchronization Signal

[0278] - RSRP: Reference Signal Received Power

[0279] - ESRP: ES Received Power. May refer to RSRP measured using ES. May have the same meaning as ES-RSRP.

[0280] - PRB: Physical Resource Block

[0281] - EH circuit: A circuit that performs EH operation. An EH device can be viewed as including the EH circuit as a component.

[0282] - PHR: Power Headroom Report

[0283] - EHR: Energy Headroom Report

[0284] - BPF: Band-Pass Filter

[0285] - SM: Subcarrier Modulation

[0286] - FS: Frequency Shift. In FDD, it can be divided into small FS, which is performed within a small range (e.g., hundreds of kHz) within the DL spectrum or UL spectrum (mainly by baseband processing), and large FS, which is performed within a relatively large range (e.g., tens of MHz) from DL to UL spectrum or from UL to DL spectrum.

[0287] - SFO: Sampling Frequency Offset

[0288] - ASK: Amplitude Shift Keying

[0289] -DSB-ASK: Double-SideBand ASK

[0290] -SSB-ASK: Single-SideBand ASK

[0291] - PR-ASK: Phase-Reversal ASK

[0292] - OOK: On-Off Keying

[0293] - PSK: Phase-Shift Keying

[0294] - BPSK: Binary-PSK

[0295] - FSK: Frequency-Shift Keying

[0296] - B-FSK: Binary FSK

[0297] - M-FSK: M-ary FSK

[0298] - PIE: Pulse-Interval Encoding

[0299] - Ncp-ofdm, Ncp, Nu: Sample unit lengths of the CP-OFDM symbol segment, CP segment, and useful OFDM symbol segment, respectively, in the CP-OFDM symbol. Ncp-ofdm = Ncp + Nu

[0300] - R-TAS: R2D Timing Acquisition Signal. R-TAS consists of SIP and CAP.

[0301] - SIP: Start Indicator Part

[0302] - CAP: Clock Acquisition Part

[0303] - D-TAS: D2R Timing Acquisition Signal

[0304] Ultra High Frequency (UHF) passive RFID communication (ISO 18000-6C) can be considered as a standardized conventional technology with a communication method similar to Ambient IoT communication. For R=>T communication, this UHF passive RFID supports Pulse-Interval Encoding (PIE) as the data encoding method and DSB-ASK and / or SSB-ASK and / or PR-ASK as the modulation method. Additionally, for T=>R communication, it supports FM0 baseband encoding and Miller modulated subcarrier methods as the data encoding methods and ASK and / or PSK-based backscatter modulation methods as the modulation method.

[0305] In addition, UHF passive RFID supports Cyclic Redundancy Check (CRC) functionality, and two types of CRC codes, CRC-16 and CRC-5, are supported. The Tag uses CRC to verify the validity of R=>T commands, and the interrogator / reader uses CRC to verify the validity of backscattered T=>R replies.

[0306] Meanwhile, to support Ambient IoT in 4G / 5G / 6G communication systems, it is necessary to determine data encoding and modulation methods that take into account requirements different from conventional UHF passive RFID, device types, (spectrum) deployment scenarios, connectivity topologies, design targets, and functions. In addition, the issue of coexistence with efficient 4G / 5G / 6G communication systems must also be given important consideration.

[0307] The present specification proposes a method for supporting AmIoT iterative transmission and / or a method for supporting an error detection code for AmIoT communication, taking into account the points mentioned above.

[0308] The methods proposed in this specification can be applied to both topology 1 and topology 2. They can also be applied to both deployment scenario 1 and deployment scenario 2. To support Ambient IoT communication in 4G / 5G / 6G communication systems, the following combinations of topology, deployment scenario, and CW node type (CW inside topology or CW outside topology) are being considered.

[0309] Figure 7 is an example showing a combination of Deployment scenario 1 and topology 1 with various CWs.

[0310] Referring to Fig. 7, it can be seen that in Deployment scenario 1 and topology 1 (indoor BS and indoor AIoT device), i) the case where the external CW is inside the topology (D1T1-A), ii) the case where the external CW is outside the topology (D1T1-B), and iii) the case where there is no external CW (in other words, the case where D2R is transmitted using an internally generated CW, D1T1-C) are considered.

[0311] D1T1-A can be considered in cases i) where the CW2D / R2D and D2R nodes are different (D1T1-A1 in Fig. 7) and ii) where the CW and R nodes for CW2D, D2R, and R2D are the same (D1T1-A2 in Fig. 7).

[0312] Specifically, D1T1-A1 represents the case where i) CW of CW2D and R of D2R are different, ii) CW of CW2D and R of R2D are the same, and iii) R of R2D and R of D2R are different.

[0313] D1T1-B represents the case where i) CW of CW2D and R of D2R are different, ii) CW of CW2D and R of R2D are different, and iii) R of R2D and R of D2R are the same.

[0314] D1T1-C can be considered only for device 2b.

[0315] Figure 8 is an example showing a combination of Deployment scenario 2 and topology 2 with various CWs.

[0316] Referring to Fig. 8, it can be seen that in Deployment scenario 2 and topology 2 (outdoor BS, Indoor Intermediate UE and Indoor AIoT device), i) the case where the external CW is inside the topology (D2T2-A), ii) the case where the external CW is outside the topology (D2T2-B), and iii) the case where there is no external CW (i.e., when D2R is transmitted using an internally generated CW, D2T2-C).

[0317] D2T2-A can be considered in cases i) where the CW2D / R2D and D2R nodes are different (D2T2-A1 in FIG. 8) and ii) where the CW and R nodes for CW2D, D2R, and R2D are the same (D2T2-A2 in FIG. 8).

[0318] Specifically, D2T2-A1 represents the case where i) CW of CW2D and R of D2R are different, ii) CW of CW2D and R of R2D are the same, and iii) R of R2D and R of D2R are different.

[0319] D2T2-B represents the case where i) CW of CW2D and R of D2R are different, ii) CW of CW2D and R of R2D are different, and iii) R of R2D and R of D2R are the same.

[0320] D2T2-C can be considered only for device 2b.

[0321] Ambient IoT intends to define the following three types of A-IoT devices first and support them sequentially (TR 38.796).

[0322]

[0323] In addition, to support outdoor scenarios, we intend to additionally support Device C having the following features.

[0324]

[0325] In this specification, “AmIoT device type” may include at least the above-described Device 1 / 2a / 2b / C.

[0326] Data Encoding and Modulation Methods

[0327] For R2D / D2R communication, low-power / low-complexity modulation methods such as ASK (e.g., OOK), PSK (e.g., BPSK), and FSK (e.g., B-FSK) can be considered. Additionally, for efficient control of R2D / D2R communication, a chip, which is the basic unit of modulation application, can be defined, and based on this, the start and / or end times between the transmission symbols (e.g., OFDM symbols) of coexisting 4G / 5G / 6G communication systems and AmIoT transmission symbols can be aligned, or parameters for R2D / D2R communication (e.g., R2D / D2R data / chip rate, FS value) can be indicated / controlled.

[0328] A chip, which is the basic unit of modulation application, can be defined as a unit of a bit sequence or phase sequence at the output of a channel / baseband / data encoder. For example, when Manchester Encoding (ME) is applied to data-0, a 2-chip Manchester codeword consisting of {1, 0} is generated. In this case, ME represents an encoding method in which i) data-0 is mapped to {+phase, -phase} or {1, 0} and data-1 is mapped to {-phase, +phase} or {0, 1}, or ii) conversely, data-0 is mapped to {-phase, +phase} or {0, 1} and data-1 is mapped to {+phase, -phase} or {1, 0}.

[0329] Based on the definition of these chips, codeword durations can be defined for channel / baseband / data encoding schemes being considered in AmIoT communication. As previously explained, for ME codewords, the codeword duration can be defined as 2 chips. For Extended / Repeated ME (e-ME / r-ME), codeword durations can be defined as 4 chips, 8 chips, etc., depending on the degree of extension / repetition. For example, in the case of e-ME / r-ME with 4 chips, the method may be such that data-0 is mapped to {1, 1, 0, 0} or {1, 0, 1, 0}, respectively.

[0330] Figure 9 shows an example of UHF passive RFID application.

[0331] Referring to Fig. 9, in the case of PIE, the length of the low interval (PW) is set equally by R regardless of data-0 and data-1, and data-0 and data-1 are identified by the difference in the high interval. R can select / determine the lengths of data-0 and data-1 within a certain range, and can instruct T regarding this selection / determination information through R=>T preamble or frame sync. To support this method in Topology 2 for AmIoT communication, the base station can set / instruct the IN (e.g., UE) information regarding the lengths of data-0 and data-1. Alternatively, it can set / instruct information regarding the difference between the length of data-0 and the length of data-1 and the length of data-0. The IN (e.g., UE) can perform R2D transmission and / or D2R reception operations using the set / instructed information.

[0332] When applying the PIE method for AmIoT communication, the chip can be defined in the following two ways.

[0333] - Method 1) A method of defining the chip based on the Low / off / -phase (e.g., “PW”) duration in Fig. 9

[0334] For example, the codeword / encoded (symbol) duration of Data-0 is defined as 2 chips, and data-1 can be defined as N1 (>2) chips.

[0335] For example, i) the data-0 codeword / encoded (symbol) duration is defined in the form {high, low} with 2 chips, and ii) the data-1 codeword / encoded (symbol) duration is defined in the form {high, high, low} when there are 3 chips (N1=3) and in the form {high, high, high, low} when there are 4 chips (N1=4).

[0336] For example, to apply method 1, i) the data-0 codeword / encoded (symbol) duration may be limited to twice the chip duration, and ii) the data-1 codeword / encoded (symbol) duration may be limited to an integer multiple of the chip duration. Alternatively, method 1 may be applied only when the conditions are satisfied that i) the data-0 codeword / encoded (symbol) duration is twice the chip duration, and ii) the data-1 codeword / encoded (symbol) duration is an integer multiple of the chip duration.

[0337] - Method 2) A method of defining the chip based on the Reference (e.g., data-0) codeword / encoded (symbol) duration (e.g., based on “Tari” in Fig. 9)

[0338] For example, the codeword / encoded (symbol) duration of Data-0 may be defined as 1 chip, and data-1 may be defined as N2 (>1) chips.

[0339] For example, i) the data-0 codeword / encoded (symbol) duration is defined as {high, low} with 1 chip, and ii) the data=1 codeword / encoded (symbol) duration is defined as {high, high, low} when 1.5 chips (N2=1.5) and as {high, high, high, low} when 2 chips (N2=2).

[0340] For example, to apply method 2, the data-1 codeword / encoded (symbol) duration can be limited to X / 2 times the chip duration (where X is an integer greater than or equal to 3). Alternatively, method 2 can be applied only when the condition that the data-1 codeword / encoded (symbol) duration is X / 2 times the chip duration (where X is an integer greater than or equal to 3) is satisfied.

[0341] The codeword / encoded (symbol) duration, data rate, FS value, etc. can be controlled at the chip unit defined above, and such control information can be transmitted / instructed through preamble / midamble / postamble / sync signals and / or payload.

[0342] A Reader (or AmIoT device) may select / determine between Method 1 and Method 2 and transmit / instruct the selection / decision information to the AmIoT device (or reader) through frame sync / preamble / midamble / postamble / sync signals. Alternatively, in Topology 2 for AmIoT communication, a base station may set / instruct one of Method 1 and Method 2 to an IN (e.g., UE). The IN (e.g., UE) may perform R2D transmission and / or D2R reception operations by applying the set / instructed method.

[0343] <OFDM waveform 기반의 R2D 전송 방식>

[0344] In OFDM waveform-based R2D / D2R transmission, unintended phase / energy / value transitions / changes may be detected from the perspective of the R2D receiver due to CP insertion. When receiving OFDM-based R2D, an AmIoT device (depending on the device type or capability) may either i) be able to handle unintended phase / energy / value transitions / changes caused by CP insertion (Assumption 1) or ii) be unable to handle unintended phase / energy / value transitions / changes caused by CP insertion (Assumption 2). For such AmIoT devices, the following CP handling methods at the R2D transmission end are being considered.

[0345] - Method Type 1: Remove CP from device without specified sender action (based on Assumption 1)

[0346] - Method Type 2: When inserting a CP into an OFDM-based waveform, ensures that no false rising / falling edge occurs between the last OOK chip of the (n-1)th OFDM symbol and the first OOK chip of the nth OFDM symbol (based on Assumption 2).

[0347] Method Type 1 may be a method in which, for example, M (e.g., M = 1, 2, 4, 8, 16, 32) chips are mapped during the Nu interval, and based on this, a cyclic prefix (CP) of size Ncp is inserted to generate an OFDM-based waveform of size Ncp-ofdm (=Nu+Ncp).

[0348] The specific types of Method Type 1 are summarized in TR 38.769 as follows.

[0349]

[0350] Method Type 2 may be a method for generating an OFDM-based waveform such that M chips are mapped during the Ncp-ofdm interval, for example, and may be a method that satisfies the following conditions.

[0351] - The values ​​of the first X chip(s) and the last X chip(s) in the OFDM symbol are identical so that false rising / falling edges do not occur even after CP insertion.

[0352] In this case, X can be 1 or 2. If the number of chips M in the OFDM symbol is less than or equal to M0, X=1; otherwise, X=2. M0 is a value determined based on (Nu+Ncp) / Ncp and can be the maximum value satisfying the condition “M0 < (Nu+Ncp) / Ncp” (e.g., M0=8).

[0353] - After inserting the CP, the length of all chips is the same.

[0354] The specific types of Method Type 2 are summarized in TR 38.769 as follows.

[0355]

[0356] Figure 10 is an example showing the relationship between the OFDM symbol and the chip in Method Type 2.

[0357] In Figure 10, it is assumed that there are M chips within a single OFDM symbol, and the chips within the OFDM symbol are classified as chip index = 0, 1, 2, …, M-1.

[0358] For convenience of explanation in this specification, the value / phase / state of chip m of OFDM symbol n may be expressed as m@n.

[0359] A Reader (or AmIoT device) may select / determine one of the above methods (Method Type 1 and Method Type 2) and transmit / instruct the AmIoT device (or reader) the selection / determination information through a payload transmitted via frame sync / preamble / midamble / postamble / sync signals / R2D (or D2R) control info / PRDCH (or PDRCH). Alternatively, in Topology 2 for AmIoT communication, a base station may set / instruct an IN (e.g., UE) one of the above methods. The IN (e.g., UE) may perform R2D transmission and / or D2R reception operations by applying the set / instructed method.

[0360] Whether Method Type 1 or Method Type 2 is supported and / or applied can be determined based on the value M, which is the number of chips within the supported OFDM symbol. For example, Method Type 2 may be supported / applied / configured only when the value M is greater than a specific value M1 (e.g., M1=4).

[0361] Alternatively, support and / or application of Method Type 1 or Method Type 2 may be determined by other R2D / D2R transmission parameters. For example, considering that Method Type 1 is relatively easier to apply when line coding (e.g., ME, PIE) is applied, if line coding is set / applied, only Type 1 may be set / applied without separate additional settings.

[0362] <OFDM waveform 기반의 R2D 전송 방식>

[0363] AmIoT devices aim for target coverage in the range of approximately 10m to 50m depending on the device type (e.g., Device 1 / 2a / 2b / C). The maximum target distance value for each scenario is shown in Table 7 below (TR 38.769).

[0364]

[0365] To achieve such target coverage, the introduction of R2D / D2R repetition techniques may be required. In particular, for backscatter-based devices (e.g., Device 1 / 2a), achieving the aforementioned target coverage in D2R transmission may not be easy; therefore, repetition transmission may be suitable as a method to improve D2R coverage without increasing D2R transmission power. Table 8 shows the repetition transmission methods being considered by AmIoT. (TR 38.769)

[0366]

[0367] For convenience, in the present invention, block-level repetition will be referred to as block repetition and bit-level repetition as bit repetition.

[0368] Figure 11 is a diagram illustrating the sequence of PDRCH signal generation according to the repetitive transmission type.

[0369] Referring to FIG. 11, the positions where the block-level repeat type, bit-level type 1 repeat type, and bit-level type 2 repeat type are applied in the sequence of generating the PDRCH signal are exemplified.

[0370] For example, block-level iteration can be performed after CRC is added to information bits and before Forward Error Correction (FEC) is applied.

[0371] For example, bit-level type 1 iteration can be performed after CRC is added to the information bits and before FEC is applied.

[0372] For example, bit-level type 2 iteration can be performed after CRC is added to the information bits, after FEC is applied, and before line coding is applied.

[0373] Among the aforementioned D2R repetition transmission techniques under consideration, block repetition techniques are known to be superior to bit repetition techniques in terms of performance. This may be because, when the block size is sufficiently large, the block repetition method can obtain additional time diversity gain compared to the bit repetition method. However, block repetition has the disadvantage of potentially increasing the implementation complexity of AmIoT devices because it may require a larger buffer size than bit repetition. To overcome this disadvantage, this specification proposes the following methods for determining the repetition type.

[0374] Method #1: How to Select Iteration Type Based on Block Size (or TBS) Value

[0375] Depending on the block size or Transport Block Size (TBS) of the R2D transmission (and / or the block size or TBS of the D2R transmission), the repetition type may be selected / determined between bit repetition and block repetition. For example, i) block repetition may be selected / applied when the TBS or block size of the R2D transmission / D2R transmission is X or less, and ii) bit repetition may be selected / applied when the TBS or block size of the R2D transmission / D2R transmission exceeds X. In this case, X may be set / defined, for example, to a size of tens of bits. Through this, the buffer size required to apply block repetition is limited to tens of bits, so that block repetition can be supported without significantly increasing the implementation complexity / cost on the device side.

[0376] For example, when transmitting R2D, the Reader may transmit information regarding the TBS or block size (and repetition number) to the device via the R2D transmission (e.g., L1 R2D control information), and may transmit the R2D transmission by selecting / applying a repetition type among block repetition and bit repetition according to Method #1 (without separate signaling for the repetition method). When the AmIoT device receives information regarding the TBS or block size (and repetition number) via the R2D transmission (e.g., L1 R2D control), it may determine the repetition type (e.g., block repetition or bit repetition) (and repetition number) according to Method #1, and perform an R2D reception operation based on the corresponding repetition type (and repetition number).

[0377] For example, for D2R transmission, the Reader may transmit information regarding the TBS or block size (and repetition number) via an R2D transmission (e.g., L1 R2D control information), and may perform D2R transmission by selecting a repetition type between block repetition and bit repetition according to Method #1 (without separate signaling for the repetition method). In this case, the R2D transmission (e.g., L1 R2D control information) transmitting information regarding the TBS or block size (and repetition number) may further include an indicator (e.g., a flag) instructing the device to apply Method #1. When the AmIoT device receives information regarding the TBS or block size (and repetition number) via an R2D transmission (e.g., L1 R2D control information), it may determine the repetition type (e.g., block repetition or bit repetition) (and repetition number) according to Method #1 and perform a D2R transmission operation based on the corresponding repetition type (and number of repetitions). At this time, the AmIoT device may be instructed by the reader to apply Method #1 based on an indicator included in the R2D transmission (e.g., a flag indicating the application of Method #1).

[0378] Method #2 Block repetition method with a limited block size

[0379] A method to limit the block size for block repetition to tens of bits or hundreds of bits may be considered. In other words, a method to limit the block size for block repetition to a value smaller than a pre-set / defined max TBS (e.g., about 1,000 bits) may be considered. Through this, the buffer size required to apply block repetition is limited to tens of bits or hundreds of bits, so that block repetition can be supported without significantly increasing the implementation complexity / cost of the device.

[0380] For example, when transmitting R2D, the Reader may transmit information regarding a separate block size (and repetition number) for block repetition through the R2D transmission (e.g., L1 R2D control information), and may transmit to the device by applying block repetition to the R2D transmission according to Method #2. The separate block size for block repetition may be limited / set / defined by device type (e.g., Device 1 / 2a / 2b / C). When the AmIoT device receives information regarding the TBS and the block size (and repetition number) for block repetition through the R2D transmission (e.g., L1 R2D control information), it may recognize that block repetition has been applied according to Method #2 and perform an R2D reception operation based on this.

[0381] For example, for D2R transmission, the Reader may transmit information regarding a separate block size (and repetition number) for block repetition via R2D transmission (e.g., L1 R2D control information). The separate block size for block repetition may be limited / configured / defined per device type (e.g., Device 1 / 2a / 2b / C). The R2D transmission (e.g., L1 R2D control information) may further include an indicator (e.g., a flag) that instructs the device to apply Method #2. When the AmIoT device receives information regarding the TBS and block size (and repetition number) via R2D transmission (e.g., L1 R2D control information), it may perform a D2R block repetition transmission operation according to Method #2 based on this information. At this time, the AmIoT device may receive instructions from the reader to apply Method #2 based on the indicator included in the R2D transmission (e.g., a flag instructing the application of Method #2).

[0382] The following Table 9 shows TBS and block size Y bits( <TBS)를 가정하여, block repetition을 수행하는 방법을 표시한다.

[0383]

[0384] As described above in FIG. 11, when the block size is somewhat large, the block repetition method can obtain additional time diversity gain compared to the bit repetition method, and thus the block repetition method is known to have superior performance compared to the bit repetition methods. More specifically, when the block repetition method is applied, the block repetition can be implemented / executed in at least one of the following two ways.

[0385] [Method 1] A method of transmitting all repeating blocks to a single PDRCH

[0386] [Method 2] A method of transmitting repeating blocks to individual PDRCHs.

[0387] Method #3: A method for the reader to indicate whether to transmit repeated blocks to a single PDRCH or to each individual PDRCH during D2R block repetition transmission.

[0388] When transmitting D2R, each PDRCH may be accompanied by all or some of the preamble / D-TAS / midamble / postamble. In other words, when transmitting D2R, each PDRCH may be accompanied by all or some of the preamble / D-TAS / midamble / postamble. Therefore, the above method 1 has the advantage of having smaller signaling overhead compared to the above method 2.

[0389] On the other hand, the above method 2 has the advantage that i) the device can transmit by applying frequency hopping (FH) to the PDRCHs, or ii) the device can transmit the PDRCHs non-consecutively in the time domain to maximize time diversity.

[0390] According to one embodiment, considering the trade-off relationship described above between method 1 and method 2, the reader may select either method 1 or method 2 for the device's D2R repeated transmission and instruct the device to do so through R2D control information. Through the R2D control information, the AmIoT device may i) transmit repeated blocks (e.g., a D2R transmission block and one or more transmission blocks in which the D2R transmission block is repeated) to the reader over a single PDRCH when method 1 is instructed, and ii) transmit each of the repeated blocks to the reader over an individual PDRCH when method 2 is instructed.

[0391] Method #4: A method for determining, based on block size, whether to transmit repeated blocks to a single PDRCH or to individual PDRCHs during D2R block repetition transmission.

[0392] According to one embodiment, the device may be configured to select between the above method 1 and the above method 2 based on the size of a repeating D2R transmission block or a D2R transmission block in which repetition is indicated.

[0393] For example, the size of a D2R transmission block can be defined in units such as i) the number of information bits including or not including CRC, or ii) the number of coded bits after FEC is applied.

[0394] As a specific example, i) if the size of a repeated (or instructed to be repeated) D2R transmission block is less than a specific value (e.g., 100 information bits excluding CRC), the device may select a method (method 1) of transmitting the D2R transmission block and one or more block-repeated blocks over a single PDRCH, and ii) if the size of a repeated (or instructed to be repeated) D2R transmission block is greater than or equal to a specific value, the device may select a method (method 2) of transmitting each of the D2R transmission block and one or more block-repeated blocks over a separate PDRCH.

[0395] For example, the specific value may be determined based on the maximum TB size for which PDRCH transmission is allowed. In other words, the specific value may be determined based on the maximum TB size that can be transmitted over a single PDRCH. As a specific example, the specific value may be determined based on a ratio with respect to the maximum TB size. For instance, if the maximum TB size is defined as 1000 information bits excluding CRC, and the specific value is defined / set as 10% of the maximum TB size, the specific value may be determined as 100 bits excluding CRC.

[0396] Method #5: A method for transmitting up to N (>1) repeating blocks to a single PDRCH during D2R block repetition transmission.

[0397] According to one embodiment, the reader may instruct the device to i) transmit N transmission blocks among the repeated D2R transmission blocks (e.g., a D2R transmission block that is the subject of block repetition and one or more transmission blocks in which the D2R transmission block is block repeated) onto one PDRCH, and ii) transmit the remaining transmission blocks (in units of N) onto one or more other PDRCHs. In this case, N may represent the maximum number of D2R transmission blocks that can be included on one PDRCH. For example, N may be a natural number greater than 1. This method #5 is a compromise between method 1 and method 2, having advantages similar to method 2 when the value of N is close to 1, and having advantages similar to method 1 when the value of N is large.

[0398] According to one embodiment, for repeated D2R transmission, the Reader can select from the above method 1, the above method 2, and method #5, and can instruct the selected method / method to the device through R2D control information.

[0399] For example, if i) the reader specifies two or more methods among Method 1, Method 2, and Method #5, or ii) the reader does not specify any method among Method 1, Method 2, and Method #5, the A-IoT device may select one method (or method) among Method 1, Method 2, and Method #5 to perform repeated D2R transmission. In this case, the device may specify / report the method selected to the reader through D2R control information. If the reader or device specifies Method #5, information on the maximum number N of D2R transmission blocks that can be transmitted over a single PDRCH may be included in the R2D control information and / or D2R control information and transmitted.

[0400] As another example, the device may be configured to select / determine the maximum number N of D2R transmission blocks transmitted to a single PDRCH in Method #5 based on the size of the repeating (or instructed to repeat) D2R transmission block. Specifically, the value of the maximum number N of D2R transmission blocks that can be transmitted over a single PDRCH may be pre-mapped / defined in a standard specification and applied according to the size of the repeating (or instructed to repeat) D2R transmission block (or the range of said D2R transmission block sizes). More specifically, the size of the repeating (or instructed to repeat) D2R transmission block may be determined based on the maximum TB size allowed for PDRCH transmission, as in Method #4 above. In other words, the size of the repeating (or instructed to repeat) D2R transmission block may be determined based on the maximum TB size that can be transmitted over a single PDRCH. Specifically, the size of the repeating (or instructed to repeat) D2R transmission block may be determined based on the ratio to the maximum TB size.

[0401] Method #6: A method to initialize / reset the FEC before starting FEC encoding for each block during D2R block repetition transmission, and then apply FEC encoding.

[0402] FIG. 12 is a diagram illustrating a channel coding method according to an embodiment of the present specification. Specifically, with reference to FIG. 12, when an FEC is applied after information bit blocks (with attached CRC) are repeated, a process is illustrated in which an FEC (or convolution code) is initialized for each of the repeated blocks.

[0403] As shown in the block repetition of Fig. 11 above, when a convolutional code is applied consecutively after repeating information bit blocks (with CRC attached), the values ​​of the bit streams of each coded block become different due to the memory characteristics of the shift register of the convolutional encoding. In this case, it becomes impossible to combine the coded blocks that were repeatedly transmitted before FEC decoding at the receiver, which can degrade the decoding performance for D2R transmission.

[0404] According to one embodiment, in order to compensate for the aforementioned disadvantages, an FEC or convolution code may be initialized or reset applied to each D2R transmission block and one or more transmission blocks in which the D2R transmission block is repeated, so that the values ​​of the bit streams between the coded blocks are identical.

[0405] For example, for each of the repeated (or instructed to be repeated) D2R transmission blocks and said D2R, the shift registers of the convolutional encoder may be initialized to the same values ​​before the start of convolutional encoding. As a specific example, for each of the repeated (or instructed to be repeated) D2R transmission blocks, the initial value of said shift register may be set to the same value.

[0406] For example, when a D2R transmission block is repeatedly transmitted with FEC applied, the Reader may instruct the device via R2D control information whether to apply the initialization / reset of the aforementioned FEC (or convolutional code) to each repeated block. If the A-IoT device receives instructions from the reader to apply the initialization / reset, it may perform repeated D2R transmission by initializing / resetting the FEC between repeated blocks even within the same PDRCH.

[0407] In this specification, R2D control information may include i) L1 R2D control information, ii) L2 R2D control information transmitted through R2D data, MAC CE and / or higher layer control information, and / or iii) control information indicated through R2D preamble (R-TAS) / midamble / postamble or broadcast information. In this case, the L1 R2D control information may be i) transmitted together with R2D data on a PRDCH, ii) transmitted on a PRDCH separate from R2D data, or iii) transmitted on a channel / signal separate from the PRDCH.

[0408] In this specification, D2R control information may include i) L1 D2R control information, ii) L2 D2R control information transmitted through D2R data, MAC CE and / or higher layer control information, and / or iii) control information indicated through D2R preamble (D-TAS) / midamble / postamble or broadcast information. In this case, the L1 D2R control information may be i) transmitted together with D2R data on a PDRCH, ii) transmitted on a PDRCH separate from D2R data, or iii) transmitted on a channel / signal separate from the PDRCH.

[0409] For convenience, this specification has focused on D2R and PDRCH in the description of some methods, but it can be applied to R2D and PRDCH in the same way (e.g., by interpreting D2R as R2D, PDRCH as PRDCH, and transmission as reception).

[0410] Various embodiments of the present specification (e.g., embodiments according to methods #1 to #6) may be combined with each other.

[0411] In terms of implementation, the operations of the first device (e.g., Reader, base station (BS), intermediate node (IN), auxiliary node (AN), terminal (UE) / Ambient IoT Device) / second device (e.g., Ambient IoT Device / Reader, base station, intermediate node, auxiliary node, terminal) according to the embodiments described above can be processed by the device of FIG. 15 (e.g., the processor (110, 210) of FIG. 15).

[0412] In addition, the operations of the first device (e.g., Reader, base station, intermediate node, auxiliary node, terminal / Ambient IoT Device) / second device (e.g., Ambient IoT Device / Reader, base station, intermediate node, auxiliary node, terminal) according to the above-described embodiment may be stored in memory (e.g., 140, 240 of FIG. 15) in the form of instructions / programs (e.g., instruction, executable code) for driving at least one processor (e.g., processor (110, 210) of FIG. 15).

[0413] The embodiments described above will be explained in detail below with reference to FIGS. 13 and 14 in terms of the operation of a first device (e.g., Reader, base station, intermediate node, auxiliary node, terminal / Ambient IoT Device) and a second device (e.g., Ambient IoT Device / Reader, base station, intermediate node, auxiliary node, terminal). The methods described below are distinguished only for convenience of explanation, and it is understood that a part of one method may be substituted with a part of another method or combined with one another and applied.

[0414] FIG. 13 is a flowchart illustrating a method according to one embodiment of the present specification.

[0415] Referring to FIG. 13, a method according to one embodiment of the present specification includes a step of receiving R2D control information (S1310) and a step of performing D2R transmission (S1330).

[0416] In S1310, the device receives reader-device control information (R2D control information) from the reader.

[0417] For example, the R2D control information may include i) L1 R2D control information transmitted through Layer 1 control signaling, ii) control information transmitted through R2D data, and / or iii) control information transmitted through R2D preamble (e.g., R-TAS), midamble, postamble, or broadcast information.

[0418] For example, the control information transmitted through the above R2D data may include layer 2 control information (L2 R2D control information), MAC control elements (MAC Control Element, MAC CE) and / or higher layer control information.

[0419] For example, the L1 R2D control information may be transmitted i) together with the R2D data on a PRDCH, ii) transmitted on a PRDCH separate from the R2D data, or iii) transmitted through a channel and / or signal separate from the R2D data.

[0420] In S1330, the device performs a device-to-reader (D2R) transmission to the reader.

[0421] The above D2R transmission is generated based on block repetition of the D2R transport block.

[0422] The above D2R transmission block and one or more transmission blocks in which the above D2R transmission block is block repeated are transmitted through at least one Physical Device-to-Reader Channel (PDRCH) based on the above R2D control information.

[0423] For example, the D2R transmission block and the one or more transmission blocks are determined to be transmitted through i) one PDRCH or ii) multiple PDRCHs based on the R2D control information.

[0424] According to one embodiment, the R2D control information may be included in a Physical Reader-to-Device Channel (PRDCH).

[0425] For example, the PRDCH may include information related to the size of the D2R transport block.

[0426] For example, the D2R transmission block and the one or more transmission blocks may be transmitted through i) one PDRCH or ii) different PDRCHs based on the size of the D2R transmission block.

[0427] As a specific example, the D2R transmission block and the one or more transmission blocks may be transmitted through a single PDRCH based on the fact that the size of the D2R transmission block is less than a preset or defined value.

[0428] As a specific example, the D2R transmission block and the one or more transmission blocks may each be transmitted through different PDRCHs based on the fact that the size of the D2R transmission block is greater than or equal to the preset or defined value.

[0429] For example, the above preset or defined value may be determined based on the maximum size of the transmission block that can be included in the PDRCH and the size of the D2R transmission block.

[0430] This embodiment may be based on the above-described method #4.

[0431] According to one embodiment, the PRDCH may further include information related to the maximum size of the D2R transmission block.

[0432] For example, the block iteration can be performed based on the size of the D2R transmission block and the maximum size of the D2R transmission block.

[0433] As a specific example, the maximum size of the above D2R transmission block can be set or defined according to the type of device.

[0434] This embodiment may be based on the above-described method #2.

[0435] According to one embodiment, the D2R transmission block and the one or more transmission blocks may be transmitted through one or more PDRCHs based on the maximum number of transmission blocks that can be included in the PDRCH.

[0436] For example, the maximum number can be determined based on the size of the D2R transmission block.

[0437] For example, the maximum number may be determined based on the maximum size that can be included in the PDRCH and the size of the D2R transmission block.

[0438] As another example, the above maximum number can be instructed to the device through the above R2D control information.

[0439] This embodiment may be based on the above-described method #5.

[0440] According to one embodiment, the D2R transmission can be generated based on channel coding.

[0441] For example, the channel coding can be performed after the block iteration is performed in the D2R transmission block.

[0442] For example, the channel coding can be performed such that the value of the coded stream generated for each of the D2R transmission block and the one or more transmission blocks becomes the same.

[0443] As a specific example, the initial value of the shift register of the channel coding for each of the D2R transmission block and the one or more transmission blocks can be set to the same value.

[0444] This embodiment may be based on the above-described method #6.

[0445] The operation based on the above-described S1310 to S1330 can be implemented by the device of FIG. 15.

[0446] For example, referring to FIG. 15, the device (200) can control one or more transceivers (230) and / or one or more memories (240) to perform operations based on S1310 to S1330.

[0447] The embodiments described above will be explained in detail below in terms of base station operation.

[0448] S1410 to S1430 described below correspond to S1310 to S1330 described in FIG. 13. Considering the above correspondence, redundant descriptions are omitted. The specific description of the reader operation described below may be replaced by the description / embodiment of FIG. 13 corresponding to the operation.

[0449] FIG. 14 is a flowchart illustrating a method according to another embodiment of the present specification.

[0450] Referring to FIG. 14, a method according to another embodiment of the present specification includes i) an R2D control information transmission step (S1410) and ii) a D2R transmission reception step (S1430).

[0451] In S1410, the reader transmits reader-device control information (R2D control information) to the device.

[0452] In S1430, the reader receives a device-to-reader (D2R) transmission from the device.

[0453] The above D2R transmission is generated based on block repetition of the D2R transport block.

[0454] The above D2R transmission block and one or more transmission blocks in which the above D2R transmission block is block repeated are transmitted through at least one Physical Device-to-Reader Channel (PDRCH) based on the above R2D control information.

[0455] Operations based on S1410 to S1430 described above can be implemented by the device of FIG. 15. For example, referring to FIG. 15, the second device (100) can control one or more transceivers (130) and / or one or more memories (140) to perform operations based on S1410 to S1430.

[0456] The operations / terms based on the embodiments described above are described assuming a 5G system. However, this is for the convenience of explanation and is not intended to limit the scope of application of the technical problems and means for solving problems to be solved by this specification to a specific system. The technical problems / technical issues / problems mentioned in this specification may exist in other systems (e.g., 6G systems). It is evident that the embodiments of this specification can be extended to solve problems that exist in other systems as well. Therefore, for the extended application of the embodiments of this specification to other systems, terms defined / described based on a 5G system may be replaced / changed with terms defined in other systems (or generalized terms not specific to one system).

[0457] Hereinafter, an apparatus to which the embodiments of the present specification can be applied (an apparatus implementing the method / operation according to the embodiments of the present specification) will be described with reference to FIG. 15.

[0458] FIG. 15 is a drawing showing the configuration of a first device and a second device according to an embodiment of the present specification.

[0459] The first device (100) may include a processor (110), an antenna unit (120), a transceiver (130), and a memory (140).

[0460] The processor (110) performs baseband-related signal processing and may include an upper layer processing unit (111) and a physical layer processing unit (115). The upper layer processing unit (111) may process operations of the MAC layer, RRC layer, or higher upper layers. The physical layer processing unit (115) may process operations of the PHY layer. For example, if the first device (100) is a base station device in base station-terminal communication, the physical layer processing unit (115) may perform uplink reception signal processing, downlink transmission signal processing, etc. For example, if the first device (100) is a first terminal device in terminal-terminal communication, the physical layer processing unit (115) may perform downlink reception signal processing, uplink transmission signal processing, sidelink transmission signal processing, etc. In addition to performing baseband-related signal processing, the processor (110) may also control the overall operation of the first device (100).

[0461] The antenna section (120) may include one or more physical antennas, and if it includes multiple antennas, it may support MIMO transmission and reception. The transceiver (130) may include an RF (Radio Frequency) transmitter and an RF receiver. The memory (140) may store information processed by the processor (110) and software, operating systems, applications, etc. related to the operation of the first device (100), and may include components such as a buffer.

[0462] The processor (110) of the first device (100) may be configured to implement the operation of the base station in base station-terminal communication (or the operation of the first terminal device in terminal-terminal communication) in the embodiments described herein.

[0463] The second device (200) may include a processor (210), an antenna unit (220), a transceiver (230), and a memory (240).

[0464] The processor (210) performs baseband-related signal processing and may include an upper layer processing unit (211) and a physical layer processing unit (215). The upper layer processing unit (211) may process operations of the MAC layer, RRC layer, or higher upper layers. The physical layer processing unit (215) may process operations of the PHY layer. For example, if the second device (200) is a terminal device in base station-terminal communication, the physical layer processing unit (215) may perform downlink reception signal processing, uplink transmission signal processing, etc. For example, if the second device (200) is a second terminal device in terminal-terminal communication, the physical layer processing unit (215) may perform downlink reception signal processing, uplink transmission signal processing, sidelink reception signal processing, etc. In addition to performing baseband-related signal processing, the processor (210) may also control the overall operation of the second device (210).

[0465] The antenna section (220) may include one or more physical antennas, and may support MIMO transmission and reception if it includes multiple antennas. The transceiver (230) may include an RF transmitter and an RF receiver. The memory (240) may store information processed by the processor (210) and software, operating systems, applications, etc. related to the operation of the second device (200), and may include components such as a buffer.

[0466] The processor (210) of the second device (200) may be configured to implement the operation of the terminal in base station-terminal communication (or the operation of the second terminal device in terminal-terminal communication) in the embodiments described herein.

[0467] In the operation of the first device (100) and the second device (200), the details described in the examples of this specification regarding the base station and terminal in base station-terminal communication (or the first terminal and the second terminal in terminal-terminal communication) may be applied in the same way, and redundant descriptions are omitted.

[0468] Here, wireless communication technology implemented in the device of this specification may include LTE, NR, and 6G, as well as Narrowband Internet of Things (NB-IoT) for low-power communication. For example, NB-IoT technology may be an example of Low Power Wide Area Network (LPWAN) technology and may be implemented according to standards such as LTE Cat NB1 and / or LTE Cat NB2, but is not limited to the names mentioned above.

[0469] Additionally or alternatively, the wireless communication technology implemented in the device of this specification may perform communication based on LTE-M technology. For example, LTE-M technology may be an example of LPWAN technology and may be referred to by various names such as eMTC (enhanced Machine Type Communication). For example, LTE-M technology may be implemented in at least one of various standards such as 1) LTE CAT 0, 2) LTE Cat M1, 3) LTE Cat M2, 4) LTE non-BL (non-Bandwidth Limited), 5) LTE-MTC, 6) LTE Machine Type Communication, and / or 7) LTE M, and is not limited to the names mentioned above.

[0470] Additionally or generally, the wireless communication technology implemented in the device of this specification may include at least one of ZigBee, Bluetooth, and Low Power Wide Area Network (LPWAN) for low-power communication, but is not limited to the names mentioned above. For example, ZigBee technology can create personal area networks (PANs) related to small / low-power digital communication based on various standards such as IEEE 802.15.4 and may be referred to by various names.

Claims

1. In a method performed by a device, A step of receiving reader-device control information (R2D control information) from a reader; and The step of performing device-to-reader transmission (D2R transmission) with the above reader; The above D2R transmission is generated based on block repetition of a D2R transport block, and A method characterized in that the above D2R transmission block and one or more transmission blocks in which the above D2R transmission block is block repeated are transmitted through at least one Physical Device-to-Reader Channel (PDRCH) based on the above R2D control information.

2. In Paragraph 1, A method characterized in that the above R2D control information is included in a Physical Reader-to-Device Channel (PRDCH).

3. In Paragraph 2, The above PRDCH includes information related to the size of the D2R transport block, and A method characterized in that the above D2R transmission block and the above one or more transmission blocks are transmitted through i) one PDRCH or ii) different PDRCHs based on the size of the above D2R transmission block.

4. In Paragraph 3, The above PRDCH further includes information related to the maximum size of the D2R transmission block, and A method characterized in that the above block repetition is performed based on the size of the D2R transmission block and the maximum size of the D2R transmission block.

5. In Paragraph 3, The above D2R transmission block and the one or more transmission blocks are transmitted through a single PDRCH based on the fact that the size of the D2R transmission block is less than a preset or defined value, and A method characterized in that the above D2R transmission block and the above one or more transmission blocks are each transmitted through different PDRCHs based on the fact that the size of the above D2R transmission block is greater than or equal to the above preset or defined value.

6. In Paragraph 5, A method characterized in that the above-mentioned preset or defined value is determined based on the maximum size of a transmission block that may be included in PDRCH and the size of the D2R transmission block.

7. In Paragraph 1, A method characterized in that the above D2R transmission block and the above one or more transmission blocks are transmitted through one or more PDRCHs based on the maximum number of transmission blocks that may be included in the PDRCH.

8. In Paragraph 7, A method characterized in that the maximum number is determined based on the size of the D2R transmission block.

9. In Paragraph 7, A method characterized in that the maximum number is determined based on the maximum size of the transmission block that can be included in the PDRCH and the size of the D2R transmission block.

10. In Paragraph 1, The above D2R transmission is generated based on channel coding, and A method characterized in that the channel coding is performed such that the value of the coded stream generated for each of the D2R transmission block and the one or more transmission blocks becomes the same.

11. In Paragraph 10, A method characterized in that the initial value of the shift register of the channel coding for each of the above D2R transmission block and the one or more transmission blocks is set to the same value.

12. Regarding the device, One or more transmitters / receivers; One or more processors; and It includes one or more memories connected to the above one or more processors and storing instructions, A device characterized by the above instructions enabling the device to perform all steps of the method according to any one of claims 1 to 11, based on execution by the one or more processors.

13. A device comprising one or more memories and one or more processors connected to the one or more memories, A device characterized in that the one or more of the above memories store instructions that cause the device to perform all steps of the method according to any one of claims 1 to 11, based on execution by the one or more processors.

14. In a non-transitory computer-readable storage medium for storing instructions, A non-transient computer-readable storage medium characterized by instructions executable by one or more processors such that the device performs all steps of the method according to any one of claims 1 to 11.

15. In a method performed by a reader, A step of transmitting reader-device control information (R2D control information) to a device; and The method includes the step of receiving a device-to-reader transmission (D2R transmission) from the above device, wherein The above D2R transmission is generated based on block repetition of a D2R transport block, and A method characterized in that the above D2R transmission block and one or more transmission blocks in which the above D2R transmission block is block repeated are transmitted through at least one Physical Device-to-Reader Channel (PDRCH) based on the above R2D control information.

16. Regarding readers, One or more transmitters / receivers; One or more processors; and It includes one or more memories connected to the above one or more processors and storing instructions, A reader characterized by the above instructions causing the reader to perform all steps of the method according to claim 15 based on execution by the one or more processors.