Method for transmitting and receiving signals related to ambient iot, and device therefor

By controlling device availability through time intervals for sleep or energy harvesting, the method addresses inefficiencies in Ambient IoT systems, enhancing energy efficiency and reducing collisions and interference.

WO2026035031A1PCT designated stage Publication Date: 2026-02-12LG ELECTRONICS INC

Patent Information

Application Number
PCT/KR2025/011830
Authority / Receiving Office
WO · WO
Patent Type
Applications
Current Assignee / Owner
Priority Date
2024-08-08
Filing Date
2025-08-06
Publication Date
2026-02-12

AI Technical Summary

Technical Problem

Existing Ambient IoT systems face challenges in controlling device availability and efficiency due to devices transitioning to unavailable states based on energy status, leading to unnecessary signaling and delays, and increased probability of collisions and interference.

Method used

A method to control device availability by determining time intervals for sleep or energy harvesting based on device availability, reducing unnecessary signaling and improving operational efficiency by restricting devices to energy harvesting or sleep states, thereby minimizing device concurrency and collisions.

Benefits of technology

This approach enhances the energy efficiency and reduces signaling overhead and delay in Ambient IoT operations, improving reception sensitivity and reducing collisions and interference.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure KR2025011830_12022026_PF_FP_ABST
    Figure KR2025011830_12022026_PF_FP_ABST
Patent Text Reader

Abstract

A method according to one embodiment of the present specification comprises a step of transmitting, to a second device, information related to device availability. The information includes information related to a time interval determination. The time interval is related to sleep or energy harvesting of the second device.
Need to check novelty before this filing date? Find Prior Art

Description

Method and device for transmitting and receiving signals related to AMBIENT IOT

[0001] This specification relates to a method and device for transmitting and receiving signals related to Ambient IoT.

[0002] The 5G mobile communications system, the successor to LTE (long-term evolution), is a new, clean-slate mobile communications system characterized by high performance, low latency, and high availability. 5G NR can utilize all available spectrum resources, 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. 6G mobile communications systems are being developed based on the underlying technologies of 5G mobile communications.

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

[0004] In general, the availability / unavailability of an Ambient IoT device cannot be controlled by the Reader and is determined by the current energy state of the device.

[0005] The purpose of this specification is to propose a method for controlling the availability / unavailability of a device.

[0006] The technical problems to be achieved in this specification are not limited to the technical problems mentioned above, and other technical problems not mentioned can be clearly understood by a person having ordinary skill in the technical field to which this specification pertains from the description below.

[0007] A method according to one embodiment of the present disclosure for solving the above-described technical problem includes a step of transmitting information related to device availability to a second device. The information includes information related to determining a time interval. The time interval is characterized as being related to sleep or energy harvesting of the second device. The time interval related to sleep or energy harvesting can be determined based on the information related to device availability. Since the time interval can be used to distinguish between available and unavailable periods of the second device, the availability / unavailability of the second device can be explicitly controlled.

[0008] In the conventional method, devices automatically transition to an unavailable state based on their energy status. The reader can only passively detect a device's unavailability through a lack of response. This results in unnecessary signaling and delays. Specifically, the reader may send messages / commands to an unavailable device, resulting in unnecessary signaling. Furthermore, the reader must spend additional time verifying the unavailable device's lack of response.

[0009] According to embodiments of the present disclosure, the time intervals associated with sleep or energy harvesting of a second device are determined based on information related to device availability. Therefore, the impact of device unavailability can be minimized. Specifically, compared to conventional methods, operations related to Ambient IoT (e.g., inventory rounds, random access procedures) can be improved in terms of signaling overhead and delay.

[0010] Additionally, by utilizing the above time interval, the operation of some devices can be restricted to OFF (energy harvesting only) or sleep states, thereby controlling the number of devices capable of responding at a given time. By reducing the concurrency of backscatter / transmission operations (D2R transmission) performed by devices, the probability of collisions and interference can be reduced. This can improve the reception sensitivity of Ambient IoT communications.

[0011] Additionally, Ambient IoT systems that manage large-scale Ambient IoT devices can be operated in a more energy-efficient manner.

[0012] The effects that can be obtained from this specification are not limited to the effects mentioned above, and other effects that are not mentioned can be clearly understood by a person having ordinary skill in the technical field to which this specification belongs from the description below.

[0013] Figure 1 illustrates topology 1 related to Ambient IoT.

[0014] Figure 2 illustrates topology 2 related to Ambient IoT.

[0015] Figure 3 is an example of topology 3 related to Ambient IoT.

[0016] Figure 4 is another example of topology 3 related to Ambient IoT.

[0017] Figure 5 illustrates topology 4 related to Ambient IoT.

[0018] Figure 6 illustrates the state according to the operating status of an energy harvesting-based device.

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

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

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

[0022] As used herein, "A or B" can mean "only A," "only B," or "both A and B." In other words, as used herein, "A or B" can be interpreted as "A and / or B." For example, as used herein, "A, B or C" can mean "only A," "only B," "only C," or "any combination of A, B and C."

[0023] As used herein, a slash ( / ) or a comma can mean "and / or." For example, "A / B" can mean "A and / or B." Accordingly, "A / B" can mean "only A," "only B," or "both A and B." For example, "A, B, C" can mean "A, B, or C."

[0024] 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 identically to "at least one of A and B".

[0025] Additionally, in this specification, “at least one of A, B and C” can mean “only A,” “only B,” “only C,” or “any combination of A, B and C.” Additionally, “at least one of A, B or C” or “at least one of A, B and / or C” can mean “at least one of A, B and C.”

[0026] Additionally, parentheses used herein 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."

[0027] In the following explanation, ‘when, if, in case of’ can be replaced with ‘based on’.

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

[0029] In this specification, a terminal (UE, User Equipment) may be a portable device and may be a second node that receives a signal from a base station / first node / IAB node.

[0030] In this specification, a base station (BS) may be a base station / first node / IAB node / Transmission-Reception Point.

[0031] In this specification, higher layer parameters may be parameters that are set for the terminal, preset, or predefined. For example, a base station or network may transmit higher layer parameters to the terminal. For example, higher layer parameters may be transmitted via radio resource control (RRC) signaling or medium access control (MAC) signaling.

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

[0033] Hereinafter, downlink (DL) refers to communication from a base station to a terminal, and uplink (UL) refers to communication from a terminal to a base station. In downlink, a transmitter may be part of a base station, and a receiver may be part of a terminal. In uplink, a transmitter may be part of a terminal, and a receiver may be part of a base station. A base station may be expressed as a first communication device, and a terminal may be expressed as a second communication device. A base station (BS) may be replaced by terms such as a fixed station, Node B, eNB (evolved-NodeB), gNB (Next Generation NodeB), BTS (base transceiver system), access point (AP: Access Point), 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, etc.

[0034] Ambient IoT communication (Rel-18)

[0035] Ambient IoT (A-IoT) may be a new device type / segment that operates solely on energy harvested from the surrounding environment. For example, A-IoT could refer to a new type of Internet of Things (IoT) device that is powered by various energy sources harvested from the surrounding environment, such as radio waves, light, motion, and heat. Examples of A-IoT use cases are shown in Table 1.

[0036]

[0037] Table 2 shows the IoT communication-related issues discussed in 3GPP RAN.

[0038]

[0039] For example, active signal generation and / or backscattering may be among the communication technologies considered to achieve low-power operation of A-IoT devices. For example, backscattering is a technique widely used in radio frequency identification (RFID), which allows devices 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 the incident RF signal or by stored energy.

[0040] For example, IoT devices can be classified into various device types, such as passive, semi-passive, and active, depending on how they store energy and generate transmission signals. 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 help of the energy storage device. For example, an active device has an energy storage device and can actively generate signals using active RF components and the stored energy to communicate. For example, in the present disclosure, the following three types of IoT devices can be considered. For example, device A can be a device without energy storage and without independent signal generation (e.g., a device that supports backscatter transmission). For example, device B can be a device with energy storage and without independent signal generation (e.g., a device that supports backscatter transmission). In this case, for example, the use of stored energy may involve 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).

[0041] For example, the following basic topologies may be considered to support A-IoT devices in indoor and outdoor scenarios. For example, the basic topologies may include direct connections between base stations and A-IoT devices, connections between base stations and intermediate nodes and A-IoT devices, connection support by auxiliary nodes, and / or connections between terminals and A-IoT devices. The basic topologies proposed in this disclosure are merely examples, and the proposals in this disclosure may be extended / applied to other topologies.

[0042] Figure 1 illustrates topology 1 related to Ambient IoT.

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

[0044] Referring to FIG. 1, an Ambient IoT device (A-IoT device) can communicate directly and bidirectionally with a base station (BS). For example, communication between the BS and the A-IoT device may include A-IoT data and / or signals. For example, the 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 BS transmitting to the A-IoT device and the BS receiving from the A-IoT device may be different. For example, in the topology 1, the BS and the A-IoT device in a micro-cell environment may communicate directly with each other. For example, the BS may be located at a co-site with a BS equipped with an existing 3GPP technology.

[0045] Figure 2 illustrates topology 2 related to Ambient IoT.

[0046] Specifically, FIG. 2 illustrates a topology (e.g., topology 2) in which a base station (BS) and an Ambient IoT device (A-IoT device) are connected via an intermediate node, according to one embodiment of the present disclosure. The embodiment of FIG. 2 can be combined with various embodiments of the present disclosure.

[0047] Referring to FIG. 2, an A-IoT device can bidirectionally communicate with an intermediate node between the device and a base station. Here, for example, the intermediate node can be an A-IoT-capable relay, an IAB node, a terminal, a repeater, etc. For example, the intermediate node can transmit A-IoT data and / or signals between the base station and the A-IoT device. For example, the A-IoT data and / or signals can 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 can be different. For example, in the topology 2, an intermediate node can exist between a base station and the A-IoT device in a macro-cell environment. For example, the base station can be located at a co-site with a base station equipped with an existing 3GPP technology. For example, intermediate nodes may be limited to terminals, and intermediate nodes may be located indoors.

[0048] Fig. 3 is an example of topology 3 related to Ambient IoT. Fig. 4 is another example of topology 3 related to Ambient IoT.

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

[0050] 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 an auxiliary node. Here, for example, the auxiliary node may be an A-IoT-capable relay, an IAB node, a terminal, a repeater, etc.

[0051] Figure 5 illustrates topology 4 related to Ambient IoT.

[0052] Specifically, FIG. 5 illustrates a topology (e.g., topology 4) in which a terminal (UE) and an Ambient IoT device (A-IoT device) are directly connected according to one embodiment of the present disclosure. The embodiment of FIG. 5 can be combined with various embodiments of the present disclosure.

[0053] Referring to FIG. 5, the A-IoT device can communicate bidirectionally with the terminal. For example, communication between the terminal and the A-IoT device may include A-IoT data and / or signals. For example, the 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).

[0054] For example, transmission by an A-IoT device may be performed over a frequency division duplexing (FDD) spectrum (e.g., an FDD UL spectrum).

[0055] < Ambient IoT solutions SI (Rel-19) >

[0056] 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 will be conducted in 3GPP NR Release 19 based on the following:

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

[0058] General range

[0059] The definitions given in TR 38.848 apply to this SI and are of an exclusive general scope.

[0060] A. The overall goal is to study a harmonized wireless interface design that minimizes the differences required to enable Ambient IoT to enable the following devices:

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

[0062] ii. ≤hundreds of μW peak power consumption1, energy storage, initial sampling frequency offset (SFO) of up to 10X ppm, and DL and / or UL amplification within the device. The device's UL transmission may be generated internally or backscattered from an externally provided carrier wave.

[0063] -X is decided by WG.

[0064] - Coverage design goal: Up to 10-50 m distance with the device indoors according to TR 38.848: "...the range within which the WG can sub-select".

[0065] -No RRC state, no mobility (i.e. at least no functionality like cell selection / reselection), no HARQ, no ARQ for topologies 1 and 2 (UE as intermediate node under NW control) according to TR 38.848.

[0066] Note 1: It should be understood that the WG is not tasked with setting a specific value for "≤hundreds of μW", and it is a matter for the WG to discuss whether the proposed design and its power consumption meet the "≤hundreds of μW" requirement.

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

[0068] - Deployment Scenario 1 Using Topology 1

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

[0070] - Deployment scenario 2 using UE as an intermediate node under topology 2 and network control.

[0071] Base Station and Coexistence Characteristics: Macro Cell, Co-site

[0072] The location of the intermediate node is indoors

[0073] C. FDD's FR1 licensed spectrum.

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

[0075] E. Traffic types DO-DTT, DT focusing on rUC1 (indoor inventory) and rUC4 (indoor command).

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

[0077] Transmissions from surrounding IoT devices (including backscattering when used) can occur at least in the UL spectrum.

[0078] The following goals are set within the general range:

[0079] 1. Evaluation assumptions

[0080] 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]:

[0081] Article 5.3: Applicable Maximum Distance Target Value

[0082] Clause 5.6: Refines the definition of latency suitable for use in RAN WGs.

[0083] Article 5.8: 2D Distribution of Devices

[0084] b) Define additional assessment assumptions required for deployment scenarios for coverage and coexistence assessments [RAN1, RAN4].

[0085] c) Identify the basic blocks / components of a possible peripheral IoT device architecture, considering the latest implementations of low-power, low-complexity devices that meet RAN design goals for power consumption and complexity. [RAN1]

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

[0087] Note: The evaluation performance of the design target falls within the scope of the feasibility and necessity study of the proposal, with the following objectives: For example, testing a reference implementation in the field, conducting simulations, and conducting analytical tests.

[0088] Note: RAN1 strives to minimize evaluation cases.

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

[0090] Positioning research for Rel-19 is led by RAN3 and is limited to features that have no or minimal impact on the specification (Note: This does not imply decisions regarding WI generation).

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

[0092] - RAN1 led:

[0093] For Ambient IoT DL and UL:

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

[0095] Numerology, Bandwidth, and Multi-Access

[0096] Waveforms and modulation

[0097] Channel coding

[0098] Downlink channel / signal aspect

[0099] Uplink channel / signal aspect

[0100] Scheduling and Timing Relationships

[0101] We study the required characteristics of the carrier wave waveform provided to ambient IoT devices from outside, including interference handling at ambient IoT UL receivers and NR base stations.

[0102] For topology 2, there is no difference in the physical layer design from topology 1.

[0103] RAN2 led:

[0104] We study and determine the features required for an ambient IoT compact protocol stack and lightweight signaling procedures that enable DO-DTT and DT data transmission.

[0105] for example:

[0106] Paging

[0107] Random access

[0108] Data transmission including necessary radio resource control aspects that comply with general range limitations.

[0109] Interaction with higher layers

[0110] Features not listed above will only be studied if deemed essential.

[0111] RAN3 led:

[0112] Identify the necessary impacts on the signals and procedures of the CN-RAN interface to enable:

[0113] Paging

[0114] Device context management

[0115] Data transfer

[0116] Identify RAN architecture aspects, including whether split architecture support is required.

[0117] Identify potential solutions for finding Ambient IoT devices that don't impact the specifications. For example, reusing existing user location reports or transmitting location information to the core network with minimal impact on the specifications.

[0118] RAN4 led:

[0119] A study on the coexistence of Ambient IoT and NR / LTE.

[0120] RF Requirements Study for Ambient IoT:

[0121] Ambient IoT BS Transmission and Reception

[0122] Ambient IoT devices, transmitting and receiving, according to general scope

[0123] Intermediate nodes (UEs) according to general range, transmitting and receiving

[0124] RAN2 and RAN3 are expected to work with SA2 to identify the RAN-CN functional split.

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

[0126] For example, as mentioned above, the types of A-IoT devices can be divided into two as follows. For example, a Type 1 device has a maximum power consumption of approximately 1 uW, can store energy, has no amplification function, and can transmit by backscattering a carrier wave (CW) provided from the outside (e.g., a reader such as a base station or a terminal, or a separate node). For example, a Type 2 device has a maximum power consumption of approximately several hundred uW, can store energy, has an amplification function, and can transmit by backscattering a carrier wave (CW) provided from the outside (e.g., a reader such as a base station or a terminal, or a separate node) or by using a signal generated internally by itself.

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

[0128] In addition, the type / class of A-IoT devices can be subdivided based on parameters associated with the device characteristics (e.g., presence / capacity of energy storage, level of energy / power consumption, presence / capacity of amplification, presence / capacity of band-pass filter (BPF), supported DL / UL transmission method(s), etc.) or a combination of parameters. For example, the above-described Type 2 device can be classified into Type 2a if it performs transmission by backscattering a carrier wave (CW) provided from the outside (e.g., a reader such as a base station or terminal or a separate node), and Type 2b if it performs transmission using a signal generated internally by itself. In this case, Type 2a and 2b can be the same in that they have a maximum power consumption of approximately several hundred microwatts, are capable of energy storage, and have an amplification function.

[0129] For example, some types / classes of A-IoT devices (e.g., Device B, Device C, Type 1 devices, and / or Type 2 devices) may have energy storage capabilities (e.g., capacitors or charging batteries) for the following purposes:

[0130] - Stable energy security at the time of reception / transmission

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

[0132] For example, the minimum RF reception sensitivity for operation of a low-power communication module may be -20 dBm, and the minimum reception sensitivity for energy harvesting may be -20 dBm. In this case, if the reception power of the A-IoT device ranges between -30 and -20 dBm, communication may not be possible without a capacitor, but communication may be possible after a charging time with a capacitor.

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

[0134] Figure 6 illustrates the state according to the operating status of an energy harvesting-based device.

[0135] Specifically, FIG. 6 illustrates power consumption and device energy states according to the operating states of an energy harvesting-based device with energy storage capabilities, according to an embodiment of the present disclosure. The embodiment of FIG. 6 may be combined with various embodiments of the present disclosure.

[0136] Referring to (b) of Fig. 6, 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 mean a state in which the device consumes power to perform operations such as receiving / transmitting for communication and sensing, and the sleep state may be a state in which it is not an active state.

[0137] Figure 6 (a) may represent a device energy state corresponding to Figure 6 (b). Referring to Figure 6 (a), the E1 value and the E2 value may differ depending on the 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 an energy value in a buffered state, and the E1 value may be defined as a minimum energy value required in an active state.

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

[0139] For example, A-IoT devices may require externally provided CW for backscatter transmission. For example, CW may be used to power A-IoT devices or as CW for downlink transmission, regardless of the transmission mode (e.g., backscatter transmission or internally generated transmission).

[0140] For example, CW waveforms can be supported in various types. For example, the CW waveform type can be a single-tone CW waveform type or a more complex multi-tone CW waveform type. For example, single-tone CW can be advantageous over multi-tone CW in terms of the multiplexing capacity of tags or readers and in terms of interference because it uses fewer resources. On the other hand, multi-tone CW has advantages such as being able to transfer more energy when transmitting CW in DL, and also securing greater coverage from a single device.

[0141] Considering the advantages of these different CW waveform types, multiple CW waveform types can be supported in the A-IoT system, and the base station / IN / AN / UE can configure the CW waveform type. For example, one or more CW waveform types supported in the A-IoT communication system can be configured / defined in advance, and the base station / IN / AN / UE can select one of the one or more supported CW waveform types and transmit it to the A-IoT device. For example, the base station / IN / AN / UE can configure / instruct / indicate 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.

[0142] For example, the present disclosure may propose at least one of the following for A-IoT communication: frame structure, synchronization and timing, random access, numerology, bandwidth, multiple access, waveforms, modulation, channel coding, channel / signal aspects, scheduling and timing relationships, and / or required characteristics of carrier waveforms for carriers provided external to the A-IoT device (including interference handling at the A-IoT device UL receiver and the NR base station). For example, the present disclosure may propose at least one of the following for A-IoT communication: paging, random access, data transmission including required radio resource control aspects to comply with general range limitations, interaction with upper layers (e.g., RRC layer, non-access stratum (NAS) layer, application layer, etc.), device context management, data transmission, coexistence of A-IoT and 6G / NR / LTE, and / or RF requirements for A-IoT.

[0143] For example, technical terms used in this specification may include:

[0144] - SSB: Synchronization Signal Block

[0145] - MIB: Master Information Block

[0146] - RMSI: Remaining Minimum System Information

[0147] - FR1: Frequency Range 1. Refers to the frequency range below 6 GHz (e.g., 450 MHz to 6000 MHz).

[0148] - FR2: Frequency Range 2. Refers to the millimeter wave (mmWave) range above 24 GHz (e.g., 24250 MHz to 52600 MHz).

[0149] - BW: Bandwidth

[0150] - BWP: Bandwidth Part

[0151] - RNTI: Radio Network Temporary Identifier

[0152] - CRC: Cyclic Redundancy Check

[0153] - SIB: System Information Block

[0154] - SIB1: SIB1 for NR devices = RMSI (Remaining Minimum System Information). Broadcasts information necessary for NR terminals to access cells.

[0155] - CORESET: CONTOL REsource SET. Time / frequency resource for the terminal to attempt candidate PDCCH decoding.

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

[0157] - 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

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

[0159] - SIB1-R: (additional) SIB1 for reduced capability NR devices. May be limited to cases where it is generated as a separate TB from SIB1 and transmitted on a separate PDSCH.

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

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

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

[0163] - Cell defining SSB (CD-SSB): SSB containing RMSI scheduling information among NR SSBs

[0164] Non-cell defining SSB (non-CD-SSB): An SSB that is placed in the NR sync raster but does not contain RMSI scheduling information for the corresponding cell for measurement purposes. However, it may contain information indicating the location of the cell defining SSB.

[0165] - SCS: subcarrier spacing

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

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

[0168] - TB: Transport Block

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

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

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

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

[0173] - FDRA: Frequency Domain Resource Allocation

[0174] - TDRA: Time Domain Resource Allocation

[0175] - RA: Random Access

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

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

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

[0179] - RO-N1, RO-N2: When a separate RO is set for normal UE 2-step RACH, it is divided into RO-N1 (4-step) and RO-N2 (2-step).

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

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

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

[0183] - RAR: Random Access Response

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

[0185] - FH: Frequency Hopping

[0186] - iBWP: initial BWP

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

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

[0189] - CS: Cyclic shift

[0190] - NB: Narrowband

[0191] - TO: Traffic Offloading

[0192] -mMTC; Massive Machine Type Communications

[0193] - eMBB: enhanced Mobile Broadband Communication

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

[0195] - RedCap: Reduced Capability

[0196] - eRedCap: enhanced RedCap

[0197] - FDD: Frequency Division Duplex

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

[0199] - DRX: Discontinuous Reception

[0200] - RRC: Radio Resource Control

[0201] - RRM: Radio Resource Management

[0202] - MM: Mobility Management

[0203] - IWSN: Industrial Wireless Sensor Network

[0204] - LPWA: Low Power Wide Area

[0205] - RB: Resource Block

[0206] - CCE: Control Channel Element

[0207] - AL: Aggregation Level

[0208] - PRG: Physical Resource-block Group

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

[0210] - PBCH: Physical Broadcast Channel

[0211] - A-PBCH: Additional PBCH

[0212] - BD: blind detection

[0213] - EPRE: Energy Per RE

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

[0215] - TDM: Time Division Multiplexing

[0216] - FDM: Frequency Division Multiplexing

[0217] - DMRS: DeModulation Reference Signal

[0218] - TDD: Time Division Duplex

[0219] - PCI: Physical layer Cell ID

[0220] - EH: Energy Harvesting

[0221] - EH device: A device that operates based on EH. It can include all of Device A / B / C being discussed in 3GPP. In addition, although this specification primarily considers RF EH, an EH device does not necessarily have to be RF EH-based.

[0222] - 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 RF-based energy harvesting. (Modulated) CW, NR / LTE DL / UL signals, etc. can be ES, and a dedicated signal / channel for ES can also be designed and supported.

[0223] - ET: Energy Transfer

[0224] CW: Carrier wave. Ambient IoT devices supporting backscattering-based UL transmission transmit information by modulating and backscattering "externally provided" CW. Ambient IoT devices supporting independent signal generation-based UL transmission transmit information by modulating "internally generated" CW. Unless otherwise specified, "externally provided" CW for backscattering is assumed. CW can be used as an energizing signal (ES) for RF energy transfer.

[0225] - CWN: Carrier Wave Node. A node that provides the CW. It may be a base station / IN / AN / UE, and there may be a separate CWN for CW provision purposes.

[0226] - R: Reader / interrogator. This is a standard RFID term. In the 3GPP Ambient IoT context, readers can include gNB / eNB, intermediate / assisting nodes, and UEs, depending on the topology. Furthermore, Ambient IoT is not limited to 4G / 5G communication systems, and can include base stations, intermediate / assisting nodes, and UEs in next-generation communication systems. This can also refer to Ambient IoT readers.

[0227] - T: Tag / ambient IoT device. This is a standard RFID term. In this specification, it can be interchanged with EH device, and in the 3GPP Ambient IoT context, it mainly refers to Ambient IoT device, Device A / B / C. The abbreviation 'T' can be interpreted / replaced with 'D', which stands for Ambient IoT Device.

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

[0229] - R=>T: Reader-to-Tag or Reader-to-Tag communication link. When the base station or intermediate / assisting node is the reader, it can have the same meaning as DL or forward link. 'R=>T' can be interpreted / replaced with 'R=>D' (Reader-to-Device).

[0230] - R2D: R-to-D link (can mean the same thing as R=>T. Can also be written as R=>D.)

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

[0232] - T=>R: Tag-to-Reader or Tag-to-Reader communication link. When the base station or intermediate / assisting node is the reader, it may have the same meaning as UL or reverse / backward link. 'T=>R' can be interpreted / replaced with 'D=>R' (Device-to-Reader).

[0233] - D2R: It can have the same meaning as T=>R. It can be written as D=>R.

[0234] - R<=>T: Includes cases where R=>T and T=>R, or R=>T or T=>R. It may be the case that both R=>T and T=>R apply.

[0235] - R<=>D: Includes R2D and D2R, or either R2D or D2R. This may apply to both R2D and D2R. (This may have the same meaning as R<=>T.)

[0236] - RF-EH: RF energy harvesting

[0237] - PRDCH: Physical R2D CHannel (may be written as PR2DCH). A physical channel for R2D communication.

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

[0239] - BS: Base Station

[0240] - IN: Intermediate node. In Topology 2 (BS ↔ IN ↔ Ambient IoT device), IN acts as the reader. Relay, IAB, UE, repeater, etc. can be IN.

[0241] - AN: Assisting node. It can assist DL transmission in Topology 3-1 (BS -> AN -> Ambient IoT device -> BS), or assist UL transmission in Topology 3-2 (BS -> Ambient IoT device -> AN -> BS). AN can be a relay, IAB, UE, repeater, etc.

[0242] - 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 type that is distinct from Ambient IoT devices or Device A / B / C. In Topology 4 (UE ↔ Ambient IoT device), the UE acts as the reader.

[0243] - Device: Unless otherwise stated, and when used alone, refers to EH device, Ambient IoT device, or Device A / B / C indiscriminately.

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

[0245] - F-gap: Frequency gap

[0246] - T-gap: Time gap

[0247] - TD: Time Domain

[0248] - FD: Frequency Domain

[0249] - PEI: Paging Early Indication

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

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

[0252] - RSRP: Reference Signal Received Power

[0253] - ESRP: ES Received Power. This may refer to RSRP measured using ES. It may have the same meaning as ES-RSRP.

[0254] - PRB: Physical Resource Block

[0255] - EH circuit: A circuit that performs EH operations. An EH device can be viewed as containing an EH circuit in component form.

[0256] - PHR: Power Headroom Report

[0257] - EHR: Energy Headroom Report

[0258] - BPF: Band-Pass Filter

[0259] - SM: Subcarrier Modulation

[0260] The methods proposed in this specification can be commonly applied to topology 1 and topology 2, and the gNB and UE1 as IN are conveniently referred to as readers. In addition, the embodiments of this specification can be extended to cases where a reader receiving a BSS (beam search signal) can directly generate and transmit a CW, or where a node transmitting a CW is a separate node from the reader. The BSS may refer to a signal that is transmitted spatially separated from an existing signal / channel (e.g., a downlink signal / channel) for beam search. The BSS may be transmitted based on a dedicated port for beam search. For example, the dedicated port may be a different port from a port for transmitting an existing signal / channel (e.g., SSB, PDSCH, etc.).

[0261] The Ambient IoT BS (base station) (e.g., reader) used in this specification can be a gNB in ​​topology 1 and a specific UE in topology 2. Additionally, the Ambient IoT device (e.g., tag) used in this specification can be interpreted as an Ambient IoT device in both topology 1 and / or topology 2.

[0262] Meanwhile, this specification proposes preamble, midamble, and postamble design methods that can be used for Ambient IoT transmission and reception. In this specification, the term "x-amble" is used to refer to all three: preamble, midamble, and postamble. Specifically, the preamble is transmitted at the very beginning of a specific D2R or R2D transmission, the midamble is transmitted in the middle, and the postamble is transmitted at the very end.

[0263] Meanwhile, the preamble, midamble, and postamble mentioned in this specification may be transmitted together with D2R, R2D transmission (e.g., PDRCH, PRDCH), or may be transmitted by being included in the corresponding D2R, R2D transmission.

[0264] The device ID mentioned in this specification may refer to a unique ID embedded within each device. However, instead of the device ID used in this specification, an ID such as the C-RNTI, which can be exchanged between devices and readers during the inventory round, may also be considered.

[0265] In this document, ' / ' means 'and', 'or', or 'and / or' depending on the context.

[0266] This specification proposes a method for configuring contention-based random access (CBRA) and / or contention-free random access (CFRA) for specific inventory rounds in an Ambient IoT system. The term "slot" used herein refers to a slot considered in slotted ALOHA operation. A slot can have a variable time-domain length depending on the reader's configuration / instructions.

[0267] In this specification, 'Query' can be interpreted / replaced with an A-IoT paging message or paging message, and 'QueryRep' can be interpreted / replaced with an Access Trigger message or Trigger message. The Query (A-IoT paging message) is a message that starts an inventory round and also triggers transmission for the first slot. Transmission for the first slot is triggered through the Query (A-IoT paging message), and when transmission and reception for the first slot is terminated, the reader can trigger transmission for the next slot by transmitting the QueryRep (Access trigger message).

[0268] In this specification, an inventory round refers to a periodic query and response procedure performed by the reader to scan devices and confirm their presence or identify them (collect their IDs). For example, the following operations are performed:

[0269] 1) The reader initiates an inventory round at specific time intervals. Specifically, the reader broadcasts a query message over a frequency channel / slot. Surrounding devices perform either i) or ii) of the following actions:

[0270] i) Transmit your ID or sensor data

[0271] ii) Non-responsive behavior in specific slots to avoid collisions.

[0272] 2) The reader that receives a response from the device can record the device's identification, location, status, sensor information, etc.

[0273] 3) If necessary, the reader can perform another inventory round for the remaining devices in the next round (e.g., an additional round to resolve collisions).

[0274] [Method #1] How to set / instruct specific slot numbers for an inventory round, or a specific inventory round for CFRA or CBRA

[0275] In one embodiment, a method for a reader to set / indicate specific slot numbers of an inventory round for a CFRA or CBRA may be considered. That is, when the reader transmits a command for an inventory round (e.g., Query, QueryRep, Query Adjust, etc.), the reader may provide the devices with a specific slot number for a CFRA and / or a specific slot number for a CBRA along with a Q value. In other words, the command for an inventory round may include a specific slot number for a CFRA and / or a specific slot number for a CBRA. In addition, information may be additionally indicated that specific slot numbers for a CFRA cannot be selected by devices performing a CBRA. In other words, the command for an inventory round may further include information that specific slot numbers for a CFRA cannot be selected by devices performing a CBRA.

[0276] Afterwards, devices that want to perform CFRA use the slot number counter value set / instructed through the method set / instructed by the reader. Devices that want to perform CBRA determine the slot number counter value based on the corresponding Q value. Since the reader previously instructed that specific slot numbers for CFRA cannot be selected by devices that perform CBRA, devices that want to perform CBRA can randomly select a slot number counter value from among values ​​excluding the corresponding slot numbers.

[0277] For example, total M=2 Q - Among the 1 slot numbers, K slot numbers from 0 to K-1 can be configured / defined to be used for CFRA. The remaining MK slot numbers from K to M can be configured / defined to be used for CBRA. Devices that want to perform CBRA can randomly select one of the slot numbers from K to M. The devices can select the selected slot number as a slot number counter. The devices can decrease the slot number counter according to commands such as Query rep, and transmit msg1 when the slot number counter becomes 0.

[0278] Additionally, the above-described embodiment can be extended to 2-step RACH / 4-step RACH instead of the above CBRA / CFRA. For example, M=2 Q- Among the slot numbers, K slot numbers from 0 to K-1 can be set / defined to be used for 2-step RACH (or 4-step RACH), and MK slot numbers can be set / defined to be used for 4-step RACH (or 2-step RACH).

[0279] In one embodiment, a method for configuring / instructing a reader to perform a specific inventory round only as a CBRA or CFRA may be considered. Specifically, the reader may instruct the device whether a specific inventory round is a CBRA or a CFRA through a query (adjust) command, etc. For example, the device may be configured / defined to understand that the inventory round is for CFRA by including a device ID (device group ID) in the command and transmitting it without a separate explicit instruction. In other words, a device that receives a command including a device ID (device group ID) may determine the type of random access procedure (type of RA procedure) related to the inventory round as CFRA.

[0280] In this case, devices that have been configured / instructed to perform CFRA by receiving a device ID from the reader can participate in the inventory round for CFRA. Devices that attempt to perform CBRA without separate configuration / instruction can participate in the inventory round for CBRA.

[0281] Additionally, the above-described embodiment can be extended to apply to 2-step RACH / 4-step RACH instead of the CBRA / CFRA. For example, based on a query command, the random access type (RA type) related to an inventory round can be indicated as a 2-step RA type or a 4-step RA type. For example, based on a query command including a device ID, the random access type (RA type) related to an inventory round can be determined as a 2-step RA type or a 4-step RA type.

[0282] In the above proposed methods, a method of waking up in a necessary section and performing energy harvesting in an unnecessary section may be considered depending on whether a specific device selects CFRA / CBRA and / or inventory rounds according to the device type.

[0283] For example, it can be assumed that CFRA is applied to the first N slot numbers in a specific inventory round, and CBRA is applied to the remaining M slot numbers. It may be desirable for a device performing CBRA to perform energy harvesting while CFRA is in progress in the first N slots. Since the device cannot know when the first N slots will end, it needs to wake up periodically to obtain query rep information or information on the current number of slot numbers reduced. To this end, the reader can include the current number of reduced slot numbers when sending query rep information and / or sending msg2 / msg4, etc. during a random access process with a specific device.

[0284] For example, the reader can include the currently decremented slot number when sending Query rep information. In other words, the reader can send a Query rep message (access trigger message) to the device that includes the current decremented slot number.

[0285] For example, when transmitting msg2 / msg4, etc. during a random access process with a specific device, the reader may consider including the currently reduced slot number in the transmission. In other words, the reader may transmit msg2 and / or msg4 including the currently reduced slot number to the specific device.

[0286] In one embodiment, the reader may set / instruct / provide to the device the time consumed in a specific slot. Specifically, the reader may set / instruct / provide to the device the time consumed in a specific slot (e.g., a default minimum value), considering whether there is a device with the corresponding slot number counter or not.

[0287] For example, if there is a device with the corresponding slot number counter, the reader can set / instruct the device to consume the time for a specific slot as the default min value #1 (e.g., 10ms). If there is no device with the corresponding slot number counter, the reader can set / instruct the device to consume the time for a specific slot as the default min value #2 (e.g., 2ms). For example, the device can be configured to perform energy harvesting until it reaches the slot number selected by conservatively calculating the average consumption time for a specific slot (e.g., 5ms). In this case, the reader can also instruct the device to know the number of slot numbers that have been reduced so far, in the same manner as described above. Specifically, the reader can include the currently reduced slot number when sending query rep information and / or sending msg2 / msg4, etc. during a random access process with a specific device.

[0288] Additionally, a device that is not currently transmitting can be configured / defined to sleep or perform energy harvesting for the default min value #2. As an example, let's assume that the number of slot numbers that a specific device initially does not need is N. The device can be configured / defined to sleep or perform energy harvesting for (default min value#2) * (N). Afterwards, the device can wake up, check the decremented slot number counter (e.g., C), and repeat the operation of sleeping or energy harvesting for (default min value#2) * (N - C).

[0289] For example, a specific device may receive control information (or commands) for another device from a reader. Based on the control information (or commands) for the other device, the specific device may obtain necessary information (e.g., information for determining a time interval for sleep or energy harvesting as described above).

[0290] For example, a specific device may receive control information in msg4 from another device. Based on the control information in msg4, the specific device may assume that the RACH procedure will soon end and operate accordingly. Specifically, the specific device may estimate the time at which the query rep command is transmitted.

[0291] [Method #2] How to add PDRCH scheduling information to Msg4 (or Msg2 for CFRA)

[0292] In one embodiment, one may consider a method in which the reader appropriately selects and transmits information to be included in Msg4 (or Msg2 for CFRA).

[0293] For example, if there is only a positive response to Msg4 (or Msg2 for CFRA), the device may be configured to regard the Msg4 (or Msg2 for CFRA) as Msg4 (or Msg2 for CFRA) for contention resolution. Specifically, the device that receives the Msg4 (or Msg2 for CFRA) may wait without performing any other actions. In the present specification, the positive response may include a device ID.

[0294] For example, a method may be considered in which the reader notifies the device of the success or failure of contention resolution while simultaneously instructing PDRCH transmission. Specifically, the reader may provide the device with R2D control information for D2R scheduling in addition to a positive response based on Msg4 (or Msg2 for CFRA). In other words, the reader may transmit Msg4 (or Msg2 for CFRA) to the device, which includes a positive response and R2D control information for D2R scheduling.

[0295] For example, a method of differently setting whether to include PDRCH scheduling information in Msg4 (or Msg2 for CFRA) depending on device type (or device capability) may be considered.

[0296] As a concrete example, for device type 1 / 2a, the device can be configured / defined to expect only positive responses via Msg4 (or Msg2 for CFRA). In other words, a device whose device type is device type 1 / 2a can expect to receive Msg4 (or Msg2 for CFRA) containing only positive responses.

[0297] As a concrete example, for device type 2b, it can be assumed and operated that PDRCH scheduling information may be added to the positive response to Msg4 (or Msg2 for CFRA). In other words, a device whose device type is device type 2b can expect to receive either i) a positive response or ii) Msg4 (or Msg2 for CFRA) containing a positive response and PDRCH scheduling information.

[0298] Additionally, a method may be considered in which the reader sets / indicates whether msg3 reception is successful instead of whether the above contention resolution is successful.

[0299] For example, only whether msg3 was successfully received can be provided to the device via Msg4 (or Msg2 for CFRA). As a specific example, the reader can transmit Msg4 to the device, which includes information indicating whether msg3 was successfully received.

[0300] For example, it may be considered to provide information indicating whether msg3 was successfully received, along with information instructing the device to immediately transmit PDRCH, via msg4 (or msg2 for CFRA). As a specific example, the reader may transmit msg4 to the device, including information indicating whether msg3 was successfully received and PDRCH scheduling information.

[0301] The above suggested methods can be set / applied independently (depending on the Q value set / indicated by the reader), but it is also possible to set / apply multiple suggested methods in combination.

[0302] In the above proposed methods, the timing values ​​defined in advance and / or set / indicated by the reader may be set in units of chip(s) / codeword(s) / NR OFDM(s) symbol / NR slot. Alternatively, a time unit may be defined for Ambient IoT (e.g., Tc). The reader may set / indicate the timing value in units of the corresponding time unit. The reader may set / indicate the timing value in multiples of the corresponding time unit, etc.

[0303] In terms of implementation, the operations of the first device (e.g., Ambient IoT Device or Reader, BS, IN, AN, UE) / second device (e.g., Reader, BS, IN, AN, UE or Ambient IoT Device) according to the above-described embodiments can be processed by the device of FIG. 9 (e.g., the processor (110, 210) of FIG. 9).

[0304] In addition, the operations of the first device (e.g., Ambient IoT Device or Reader, BS, IN, AN, UE) / second device (e.g., Reader, BS, IN, AN, UE or Ambient IoT Device) according to the above-described embodiment may be stored in a memory (e.g., 140, 240 of FIG. 9) in the form of a command / program (e.g., instruction, executable code) for driving at least one processor (e.g., 110, 210 of FIG. 9).

[0305] The embodiments described below are specifically described with reference to FIGS. 7 and 8 in terms of the operation of a first device (e.g., Ambient IoT Device or Reader, base station, intermediate node, auxiliary node, terminal) and a second device (e.g., Reader, base station, intermediate node, auxiliary node, terminal, or Ambient IoT Device). The methods described below are distinguished only for convenience of explanation, and it goes without saying that some components of one method may be substituted for some components of another method or may be applied in combination with each other.

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

[0307] Referring to FIG. 7, a method according to one embodiment of the present specification includes a step (S710) of transmitting information related to device availability.

[0308] In S710, the first device transmits information related to device availability to the second device.

[0309] In one embodiment, the information may include information related to determining a time interval. The time interval may be related to sleep or energy harvesting of the second device. For example, the time interval may be based on a time interval (e.g., N slots) associated with a CFRA among the entire time interval (e.g., all slots) based on an inventory round. For example, the time interval may be based on the remaining slots (e.g., NC slots) among the slots associated with the CFRA.

[0310] In one embodiment, the information may be transmitted based on an access trigger message associated with an inventory round. In other words, the first device may transmit an access trigger message including the information related to the device availability to the second device. In other words, the information related to the device availability may be included in the access trigger message and transmitted from the first device to the second device. In other words, the container of the information may be based on the access trigger message.

[0311] In one embodiment, the information may be transmitted based on Message 2 (MSG2) or Message 4 (MSG4) related to a random access procedure. In other words, the first device may transmit MSG2 or MSG4 containing the information related to the device availability to the second device. In other words, the information related to the device availability may be transmitted from the first device to the second device by being included in MSG2 or MSG4. In other words, the container of the information may be based on MSG2 or MSG4.

[0312] In one embodiment, the information may include slot counter information.

[0313] For example, a slot number may be indicated based on the slot counter information (e.g., N, NC). The time interval may be determined based on counting the slot number. Specifically, the end of the time interval may be based on the point in time when the slot number becomes 0. In other words, the time interval may end based on the slot number becoming 0.

[0314] For example, the slot number may be based on the number of slots related to contention-free based random access (CFRA) among slots related to an inventory round. As a specific example, the slot number may be based on the number of slots related to CFRA (e.g., N) among slots related to an inventory round. As a specific example, the slot number may be a slot number (e.g., NC) based on the number of slots related to CFRA that remain so far among slots related to CFRA in an inventory round.

[0315] In one embodiment, the information may include information indicating a duration associated with one slot.

[0316] For example, the duration may be based on i) a value defined based on a slot counter (e.g., default min value #1) or ii) a default value (e.g., default min value #2). The information may include the defined value and / or the default value. For example, the duration may be calculated / determined based on the defined value and the default value.

[0317] For example, the time interval may be determined based on i) the duration and ii) a slot number. Specifically, the slot number may be i) a slot number selected by the second device or ii) a slot number indicated based on the information. More specifically, the slot number indicated based on the information may mean a slot number indicated based on the slot counter information. In this case, the information may include at least one of i) the defined value, ii) the default value, and / or iii) the slot counter information.

[0318] In one embodiment, the method may further include a step of receiving MSG1. Specifically, the first device may receive message 1 (MSG1) related to contention-based random access (CBRA) from the second device. MSG1 may be received after the time interval.

[0319] More specifically, until the time interval ends, the second device can operate in a sleep state or perform energy harvesting. In other words, during the time interval, the second device can operate in an off state (e.g., only energy harvesting can be performed) or a sleep state (e.g., energy harvesting, monitoring, maintaining memory, and rough clock running can be performed). Based on the end of the time interval, the first device can receive MSG1 related to CBRA from the second device. As a specific example, based on the end of slots for CFRA (e.g., N slots) among slots related to an inventory round, the first device can receive MSG1 related to CBRA from the second device. As a specific example, the second device can transmit MSG1 related to CBRA to the first device based on the counting of a randomly selected slot number.

[0320] In one embodiment, the method may further include a PDRCH receiving step. Specifically, the first device may receive a Physical Device to Reader Channel (PDRCH) from the second device. The PDRCH may be scheduled based on MSG4 associated with the CBRA. More specifically, the first device may transmit message 2 (MSG2) to the second device. The first device may receive message 3 (MSG3) from the second device. The first device may transmit MSG4, which includes control information for scheduling the PDRCH, to the second device.

[0321] For example, the PDRCH may carry i) any higher-layer payload, ii) a response transmitted from an Ambient IoT Device to a Reader during a contention-based access procedure, and / or iii) D2R control information.

[0322] For example, a signal transmitted from a first device (Reader) to a second device (Ambient IoT Device) may be based on a physical channel. The physical channel may be referred to as an R2D channel or a Physical Reader-to-Device CHannel (PRDCH). As a specific example, the PRDCH may carry i) all higher-layer payloads (e.g., a higher-layer payload including system information, a higher-layer payload including configuration / information other than system information) and / or ii) R2D control information.

[0323] In one embodiment, the first device and the second device may be based on devices that operate based on one of four topologies related to Ambient IoT (see FIGS. 1 to 5). Specifically, the first device may be i) a base station, ii) a user equipment (UE), iii) an intermediate node, or iv) an assisting node. The second device may be an Ambient IoT (Internet of Things) device.

[0324] In one embodiment, the method may further include a configuration transmission step. Specifically, a first device (e.g., a reader) may transmit a configuration to a second device (e.g., an ambient IoT device). For example, the configuration may include information based on at least one of Method #1 and Method #2. For example, the configuration may include a Q value related to the total number of slot numbers. For example, the configuration transmission step may be performed before S710.

[0325] The operations based on the above-described S710, MSG1 receiving step, PDRCH receiving step, and setting transmission step can be implemented by the device of FIG. 9. For example, referring to FIG. 9, the first device (100) can control one or more transceivers (130) and / or one or more memories (140) to perform operations based on the S710, MSG1 receiving step, PDRCH receiving step, and setting transmission step.

[0326] The embodiments described below are specifically described in terms of the operation of the second device.

[0327] The S810, MSG1 transmission step, PDRCH transmission step, and configuration reception step described below correspond to the S710, MSG1 reception step, PDRCH reception step, and configuration transmission step described in FIG. 7. Considering the above correspondence, redundant descriptions are omitted. That is, the specific description of the second device operation described below can be replaced with the description / example of FIG. 7 corresponding to the operation.

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

[0329] Referring to FIG. 8, a method according to another embodiment of the present specification includes a step of receiving information related to device availability (S810).

[0330] In S810, the second device receives information related to device availability from the first device.

[0331] In one embodiment, the information may include information related to determining a time interval. The time interval may be related to sleep or energy harvesting of the second device. For example, the second device may operate in a sleep state or perform energy harvesting until the time interval expires. For example, the second device may perform communication (e.g., transmit MSG1) after the time interval.

[0332] In one embodiment, the method may further include a step of transmitting MSG1. Specifically, the second device may transmit message 1 (MSG1) related to contention-based random access (CBRA) to the first device. MSG1 may be transmitted after the time interval.

[0333] In one embodiment, the method may further include a PDRCH transmission step. Specifically, the second device may transmit a Physical Device to Reader Channel (PDRCH) to the first device. The PDRCH may be scheduled based on MSG4 associated with the CBRA.

[0334] In one embodiment, the method may further include a configuration receiving step. Specifically, the second device (e.g., an Ambient IoT device) may receive configurations from the first device (e.g., a Reader). The configuration receiving step may be performed prior to S810.

[0335] The operations based on the above-described S810, MSG1 transmission step, PDRCH transmission step, and configuration reception step can be implemented by the device of FIG. 9. For example, referring to FIG. 9, the second device (200) can control one or more transceivers (230) and / or one or more memories (240) to perform operations based on S810, MSG1 transmission step, PDRCH transmission step, and configuration reception step.

[0336] Hereinafter, a device to which an embodiment of the present specification can be applied (a device that implements a method / operation according to an embodiment of the present specification) is described with reference to FIG. 9.

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

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

[0339] The processor (110) performs baseband-related signal processing and may include a higher layer processing unit (111) and a physical layer processing unit (115). The higher layer processing unit (111) may process operations of a MAC layer, an RRC layer, or higher layers. The physical layer processing unit (115) may process operations of a PHY layer. For example, when 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, when the first device (100) is a first terminal device in terminal-to-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).

[0340] The antenna unit (120) may include one or more physical antennas, and when including multiple antennas, 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), software, an operating system, applications, etc. related to the operation of the first device (100), and may also include components such as a buffer.

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

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

[0343] The processor (210) performs baseband-related signal processing and may include a higher layer processing unit (211) and a physical layer processing unit (215). The higher layer processing unit (211) may process operations of a MAC layer, an RRC layer, or higher layers. The physical layer processing unit (215) may process operations of a PHY layer. For example, when 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, when the second device (200) is a second terminal device in terminal-to-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).

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

[0345] The processor (210) of the second device (200) may be configured to implement operations of the terminal in base station-to-terminal communication (or operations of the second terminal device in terminal-to-terminal communication) in the embodiments described in the present disclosure.

[0346] In the operation of the first device (100) and the second device (200), the same explanations given for the base station and the terminal (or the first terminal and the second terminal in the terminal-to-terminal communication) in the examples of the present disclosure may be applied, and redundant explanations are omitted.

[0347] Here, the wireless communication technology implemented in the device of the present disclosure 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 LPWAN (Low Power Wide Area Network) technology and may be implemented in standards such as LTE Cat NB1 and / or LTE Cat NB2, and is not limited to the above-described names.

[0348] Additionally or alternatively, the wireless communication technology implemented in the device of the present disclosure may perform communication based on LTE-M technology. For example, LTE-M technology may be an example of LPWAN technology and may be called by various names such as eMTC (enhanced Machine Type Communication). For example, LTE-M technology may be implemented by 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 above-described names.

[0349] Additionally or alternatively, the wireless communication technology implemented in the device of the present disclosure may include at least one of ZigBee, Bluetooth, and Low Power Wide Area Network (LPWAN), which take low-power communication into account, and is not limited to the above-described names. 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 called by various names.

Claims

1. In the method, Including a step of transmitting information related to device availability to a second device, A method characterized in that the above information includes information related to the determination of a time interval, wherein the time interval is related to sleep or energy harvesting of the second device.

2. In paragraph 1, A method characterized in that the above information is transmitted based on an access trigger message related to an inventory round.

3. In paragraph 1, A method characterized in that the above information is transmitted based on Message 2 (Message2, MSG2) or Message 4 (Message4, MSG4) related to a random access procedure.

4. In paragraph 1, A method characterized in that the above information includes slot counter information.

5. In paragraph 4, A slot number is indicated based on the above slot counter information, A method characterized in that the above time interval is determined based on counting of the slot number.

6. In paragraph 5, A method characterized in that the above slot number is based on the number of slots related to non-contention based random access (CFRA) among slots related to an inventory round.

7. In paragraph 1, A method characterized in that the above information includes information indicating a duration associated with one slot.

8. In paragraph 7, A method characterized in that the above duration is based on i) a value defined based on a slot counter or ii) a default value.

9. In paragraph 8, A method characterized in that the above time interval is determined based on i) the duration and ii) a slot number.

10. In paragraph 9, A method characterized in that the above slot number is i) a slot number selected by the second device or ii) a slot number indicated based on the above information.

11. In paragraph 1, Further comprising a step of receiving a message 1 (message1, MSG1) related to contention-based random access (CBRA) from the second device; A method characterized in that the above MSG1 is received after the above time interval.

12. In paragraph 11, Further comprising a step of receiving a PDRCH (Physical Device to Reader Channel) from the second device; A method characterized in that the above PDRCH is scheduled based on MSG4 associated with the above CBRA.

13. In the first device, One or more transmitters and receivers; one or more processors; and One or more memories connected to said one or more processors and storing instructions, A first device characterized in that the instructions, based on being executed by the one or more processors, cause the first device to perform all steps of the method according to any one of claims 1 to 12.

14. In an electronic device comprising one or more memories and one or more processors connected to the one or more memories, An electronic device characterized in that said one or more memories store instructions that cause said electronic device to perform all steps of a method according to any one of claims 1 to 12, based on being executed by said one or more processors.

15. In a non-transitory computer-readable storage medium storing instructions, A non-transitory computer-readable storage medium having instructions executable by one or more processors, characterized in that the instructions cause a first device to perform all steps of a method according to any one of claims 1 to 12.

16. In the method, A step of receiving information related to device availability from a first device, A method characterized in that the above information includes information related to the determination of a time interval, wherein the time interval is related to sleep or energy harvesting of the second device.

17. In the second device, One or more transmitters and receivers; one or more processors; and One or more memories connected to said one or more processors and storing instructions, A second device characterized in that said instructions, based on being executed by said one or more processors, cause said second device to perform all steps of the method according to claim 16.

Citation Information

Patent Citations

  • Communication method and device, equipment and storage medium

    CN116095644A

Cited By

  • Frequency hopping for ambient internet of things reader-to-device repetitions

    US20260213783A1