Random access scheme method over internet of things (IOT) interface

The channel access method addresses resource configuration and failure recovery for A-IoT devices, optimizing network performance and reducing maintenance costs by implementing intelligent resource allocation and failure recovery mechanisms.

WO2026012409A1PCT designated stage Publication Date: 2026-01-15ESSEN INNOVATION CO LTD
View PDF 3 Cites 0 Cited by

Patent Information

Application Number
PCT/CN2025/107793
Authority / Receiving Office
WO · WO
Patent Type
Applications
Current Assignee / Owner
Priority Date
2025-05-09
Filing Date
2025-07-09
Publication Date
2026-01-15

AI Technical Summary

Technical Problem

Existing random-access procedures for ultra-low complexity Ambient IoT (A-IoT) devices face challenges in configuring resources, selecting appropriate schemes, generating messages, ensuring synchronization, and addressing failures due to their limited capabilities and reliance on external carrier waves.

Method used

A channel access method for A-IoT devices involving network nodes and IoT devices that includes determining trigger signals, detecting and transmitting messages, and implementing intelligent resource allocation and failure recovery mechanisms to optimize network performance and device energy consumption.

Benefits of technology

The method enables efficient integration of A-IoT devices into 3GPP systems, reducing communication failures and maintenance costs while supporting seamless integration with cellular networks and enabling sustainable IoT device deployment across diverse applications.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN2025107793_15012026_PF_FP_ABST
    Figure CN2025107793_15012026_PF_FP_ABST
Patent Text Reader

Abstract

A channel access method over an internet of things (IoT) interface. The network determines a time point for transmitting a trigger signal to at least one IoT device and transmits accordingly. The network detects a message carried in each of at least one first device-to-reader IoT signal from the at least one IoT device and determines target IoT device (s) in response to the detected message. The network transmits a message carried in a first reader-to-device IoT signal to the target IoT device (s). The network detects a message carried in one of second device-to-reader IoT signal (s) from one of the target IoT device (s). The network determines whether to transmit a message in a second reader-to-device IoT signal to the target IoT device (s) according to a decoding result of the detected message carried in the second device-to-reader IoT signal(s) associated with the one of the target IoT device (s).
Need to check novelty before this filing date? Find Prior Art

Description

RANDOM ACCESS SCHEME METHOD OVER INTERNET OF THINGS (IOT) INTERFACEBACKGROUND OF DISCLOSURE1. Field of Disclosure

[0001] The present disclosure relates to the field of communication systems, and more particularly, to a channel access method over internet of things (IoT) interface. 2. Description of Related Art

[0002] A study item of RAN on Ambient IoT (Internet of Things) in 3GPP has been discussed under the framework of 3GPP system. The study focused on ultra-low complexity A-IoT devices with ultra-low power consumption for the very-low end IoT applications, wherein the A-IoT devices can harvest energy from incident signals of ambient excitation sources. A-IoT devices distinguish themselves from existing 3GPP IoT technologies e.g., NB-IoT, LTE-M, RedCap, etc., in terms of lower complexity and power consumption with orders-of-magnitude.

[0003] Three types of A-IoT devices with energy storage capability were identified in 3GPP following terminologies: 1. Device 1: Exhibits a peak power consumption of approximately 1 μW, incorporates energy storage,  and has an initial sampling frequency offset (SFO) of up to 10X ppm. It lacks both downlink (DL) and uplink (UL) amplification, and its uplink transmissions are generated by backscattering an externally provided carrier wave. 2. Device 2a: Demonstrates a peak power consumption of a few hundred μW or less, includes energy  storage, and has an initial sampling frequency offset (SFO) of up to 10X ppm. It features DL and / or UL amplification, and its uplink transmissions are generated by backscattering an externally provided carrier wave. 3. Device 2b: Exhibits a peak power consumption of a few hundred μW or less, incorporates energy  storage, and has an initial sampling frequency offset (SFO) of up to 10X ppm. It features DL and / or UL amplification, and its uplink transmissions are generated internally by the device.

[0004] The device-to-reader (D2R) transmission of Device 1 and Device 2a relies on the backscattering on carrier wave signals provided externally from a carrier wave source node, and the transmission of D2R signal from Device 2b is internally generated with active RF components embedded within the device.

[0005] Technical Problem:

[0006] The proliferation of ultra-low complexity Ambient IoT (A-IoT) devices, designed for very-low end IoT applications with minimal power consumption, presents unique challenges for network access. Unlike conventional 3GPP IoT technologies, these A-IoT devices often rely on energy harvesting from ambient excitation sources and may lack internal amplification for uplink transmissions. Efficiently integrating these devices into existing 3GPP systems requires specialized random-access schemes that account for their limited capabilities and reliance on external carrier waves for backscattering.

[0007] Specifically, current random-access procedures, primarily designed for more robust devices, face several technical problems when applied to A-IoT. It is challenging to effectively indicate or configure random access resources, such as slot occasions or frequency locations, for contention-based and contention-free random access procedures to these constrained A-IoT devices. Furthermore, with multiple random-access schemes potentially being defined for various A-IoT application scenarios, a clear and efficient method for selecting a specific scheme is necessary to optimize network performance and device energy consumption. There is also a need to specify robust methods for generating and structuring messages (e.g., R2D and D2R transmissions) during the random-access procedure, ensuring proper synchronization, contention resolution, device identification, and information requests. Finally, developing solutions to address random-access failures is crucial, given the inherent limitations of A-IoT devices and their potential unavailability during charging periods.

[0008] Hence, a channel access method over internet of things (IoT) interface is desirable.

[0009] SUMMARY

[0010] An object of the present disclosure is to propose a channel access method over internet of things (IoT) interface.

[0011] In a first aspect, an embodiment of the invention provides a channel access method for execution by a network node, with backscatter communication enabled device-to-reader signal transmission, the method comprising: determining a time point for transmitting a trigger signal to at least one IoT device; transmitting the trigger signal to the at least one IoT device according to the determined time  point; detecting a message carried in each of at least one first device-to-reader IoT signal from the at  least one IoT device; determining one or more than one target IoT device in response to the detected message carried  in each of the at least one first device-to-reader IoT signal; transmitting a message carried in a first reader-to-device IoT signal to the one or more than one  target IoT device; detecting a message carried in one of one or more than one second device-to-reader IoT signal  from one of the one or more than one target IoT device; and determining whether to transmit a message in a second reader-to-device IoT signal to the one of  the one or more than one target IoT device according to a decoding result of the detected message carried in the one of the one or more than one second device-to-reader IoT signal associated with the one of the one or more than one target IoT device.

[0012] In a second aspect, an embodiment of the invention provides a channel access method for execution by an IoT device among at least one IoT device, with backscatter communication enabled device-to-reader signal transmission, the method comprising: receiving a trigger signal from a network node at a time point; transmitting a message carried in one of at least one first device-to-reader IoT signal from the IoT  device among the at least one IoT device to the network node; receiving a message carried in a first reader-to-device IoT signal from the network node in  response to the transmitted message carried in the one of the at least one first device-to-reader IoT signal; and transmitting a message carried in one of one or more than one second device-to-reader IoT signal  to the network node; determining a decoding result, at the network node, of the message carried in the one of the one  or more than one second device-to-reader IoT signal associated with the IoT device according to whether a message carried in a second reader-to-device IoT signal is detected by the IoT device..

[0013] In a third aspect, an embodiment of the invention provides an internet of things (IoT) device comprising a processor configured to call and run a computer program stored in a memory, to cause a device in which the processor is installed to execute the disclosed method.

[0014] In a fourth aspect, an embodiment of the invention provides a base station comprising a processor configured to call and run a computer program stored in a memory, to cause a device in which the processor is installed to execute the disclosed method.

[0015] In a fifth aspect, an embodiment of the invention provides a user equipment (UE) comprising a processor configured to call and run a computer program stored in a memory, to cause a device in which the processor is installed to execute the disclosed method.

[0016] The disclosed method may be programmed as computer executable instructions stored in non-transitory computer readable medium. The non-transitory computer readable medium, when loaded to a computer, directs a processor of the computer to execute the disclosed method.

[0017] The non-transitory computer readable medium may comprise at least one from a group consisting of:a hard disk, a CD-ROM, an optical storage device, a magnetic storage device, a Read Only Memory, a Programmable Read Only Memory, an Erasable Programmable Read Only Memory, EPROM, an Electrically Erasable Programmable Read Only Memory and a Flash memory.

[0018] The disclosed method may be programmed as a computer program product, that causes a computer to execute the disclosed method.

[0019] The disclosed method may be programmed as a computer program, that causes a computer to execute the disclosed method.Advantageous Effects

[0020] The present application provides technical solutions for configuring and operating Ambient Internet of Things (A-IoT) communications within 3GPP systems. The disclosure sets forth comprehensive parameters, procedures, and schemes that enable efficient configuration and scheduling of network nodes and A-IoT devices.

[0021] The comprehensive framework addresses the unique challenges of ultra-low power devices by providing flexible multi-step random access procedures (1-step through 4-step) that can be dynamically selected based on device capabilities, energy availability, and application requirements. The intelligent resource allocation mechanisms optimize spectrum efficiency while accommodating the intermittent nature of A-IoT device operations due to energy harvesting cycles, reducing communication failures and improving overall network reliability. The systematic approach to message generation and composition ensures interoperability between different device types (Device 1, 2a, and 2b) while supporting both backscattered and active transmission modes, enabling seamless integration with existing cellular networks without causing interference. The robust failure recovery mechanisms specifically designed for A-IoT constraints significantly reduce maintenance costs and environmental impact by eliminating the need for frequent battery replacements or manual recharging, supporting the deployment of billions of sustainable IoT devices across diverse applications. Furthermore, the disclosed schemes enable efficient inventory management and command delivery services that drive new market opportunities in smart agriculture, industrial monitoring, supply chain tracking, and environmental sensing, ultimately improving productivity, operational efficiency, and quality of life through ubiquitous, maintenance-free connectivity.BRIEF DESCRIPTION OF DRAWINGS

[0022] In order to more clearly illustrate the embodiments of the present disclosure or related art, the following figures will be described in the embodiments are briefly introduced. It is obvious that the drawings are merely some embodiments of the present disclosure, a person having ordinary skill in this field may obtain other figures according to these figures without paying the premise.

[0023] FIG. 1 illustrates a schematic view showing an A-IoT system topology 1.

[0024] FIG. 2 illustrates a schematic view showing an A-IoT system topology 2.

[0025] FIG. 3 illustrates a schematic view showing an A-IoT system topology 3.

[0026] FIG. 4 illustrates a schematic view showing an A-IoT system topology 4.

[0027] FIG. 5 illustrates a schematic view showing an A-IoT system.

[0028] FIG. 6 illustrates a schematic view showing a Msg0 triggered 3-step and 4-step random access scheme.

[0029] FIG. 7 illustrates a schematic view showing Msg0-triggered 1-step and 2-step random access scheme.

[0030] FIG. 8 illustrates a schematic view showing an embodiment of the disclosed channel access method over internet of things (IoT) interface.

[0031] FIG. 9 illustrates a schematic view showing another embodiment of the disclosed method at the immediate node side.

[0032] FIG. 10 illustrates a schematic view showing another embodiment of the disclosed method at the immediate node side.

[0033] FIG. 11 illustrates a schematic view showing an example of an A-IoT device.

[0034] FIG. 12 illustrates a schematic view showing an example of a user equipment (UE) .

[0035] FIG. 13 illustrates a schematic view showing an example of a base station.

[0036] FIG. 14 illustrates a schematic view showing a chip or executing the disclosed method in an A-IoT device.

[0037] FIG. 15 illustrates a schematic view showing a chip or executing the disclosed method in a UE.

[0038] FIG. 16 illustrates a schematic view showing a chip or executing the disclosed method in a base station.DETAILED DESCRIPTION OF EMBODIMENTS

[0039] Embodiments of the disclosure are described in detail with the technical matters, structural features, achieved objects, and effects with reference to the accompanying drawings as follows. Specifically, the terminologies in the embodiments of the present disclosure are merely for describing the purpose of the certain embodiment, but not to limit the disclosure. In this disclosure, the term " / " should be interpreted to indicate "and / or. "

[0040] This disclosure focuses on configuration, scheduling scheme, and related procedures for A-IoT related signal transmission, including carrier wave signal, R2D signal, and D2R signal.

[0041] Two general connectivity topologies in the following are considered in 3GPP and adopted in the description for A-IoT networks operating in indoor or outdoor scenarios, including BS in connection with Ambient IoT device and BS connected with Ambient IoT device through intermediate node. The bi-directional arrow symbol represents a connection between two entities.

[0042] TS 38.848 considers four general connectivity topologies for A-IoT networks operating in indoor or outdoor scenarios: 1 BS Ambient IoT device: Direct connection between base station and Ambient IoT device. 2 BS intermediate node Ambient IoT device: Connection through an intermediate node between  base station and Ambient IoT device. 3 BS assisting node Ambient IoT device BS: Connection involving base station, assisting node,  and Ambient IoT device with base station. 4 UE Ambient IoT device: Direct connection between user equipment and Ambient IoT device. Note that the bi-directional arrow symbol represents a connection between two entities. 1 Topology 1: BS Ambient IoT device

[0043] With reference to FIG. 1, In Topology 1, the Ambient IoT device directly and bidirectionally communicates with a base station. In this topology, a carrier wave can be provided to an A-IoT device (e.g., A-IoT device 60a) from the BS or from an external carrier wave source node outside of Topology 1. 2 Topology 2: BS intermediate node Ambient IoT device

[0044] With reference to FIG. 2, in Topology 2, the Ambient IoT device communicates bidirectionally with an intermediate node between the Ambient IoT device and base station. In this topology, a carrier wave can be provided to the A-IoT device from the intermediate node or from an external carrier source node outside of Topology 2. 3 Topology 3: BS assisting node Ambient IoT device BASE STATION

[0045] With reference to FIG. 3, in Topology 3, the Ambient IoT device transmits data / signaling to a base station and receives data / signaling from the assisting node; or the Ambient IoT device receives data / signaling from a base station and transmits data / signaling to the assisting node. 4 Topology 4: UE Ambient IoT device

[0046] With reference to FIG. 4, in Topology 4, the Ambient IoT device communicates bidirectionally with a UE (e.g., UE 10a, 10b, or 100) .

[0047] In Topology 2, an A-IoT device (e.g., A-IoT device 60a) communicates bidirectionally with an intermediate node between the A-IoT device and BS. In this topology, a carrier wave can be provided to the A-IoT device from the intermediate node or from an external carrier source node outside of Topology 2.

[0048] For Topology 2, the intermediate node supports both of A-IoT air interface as well as a 3GPP air interface, the intermediate node can be a 3GPP node of relay, IAB, UE, repeater, etc. That is, direction communication between base station (BS) and the 3GPP node using 3GPP protocols via existing 3GPP interfaces, e.g., Uu, PC5, etc., is possible.

[0049] In Topology 2, the intermediate node is designed to support both an A-IoT air interface and a 3GPP air interface. This intermediate node can function as various 3GPP nodes, such as a relay, integrated access and backhaul (IAB) unit, user equipment (UE) , or repeater. This dual capability means that direction communication between the base station (BS) and the 3GPP node is possible, using 3GPP protocols via 3GPP interfaces, such as Uu or PC5.

[0050] In the following embodiments, depending on the used topology of Topology 1 or Topology 2, a network node can be any node that has been specified in a network architecture of 3GPP or will be specified under the Topology 1 / 2, which can support at least part of 3GPP protocols using wired or wireless connection. The network node can be a gNB, a UE (e.g., UE 10a, 10b, or 100) , a relay node, an IAB, an A-IoT device supporting part of existing 3GPP protocols, an intermediate node in Topology 2, an assisting node, an entity of 3GPP core network, etc.

[0051] For Topologies 1 / 2, parameter settings associated with R2D signal transmission over R2D link, D2R signal transmission over D2R link, or carrier wave signal transmission from a network node to an A-IoT device or from a carrier wave source node to an A-IoT device can be configured by the network node via an A-IoT air interface.

[0052] For Topology 2, BS (e.g., gNB, BS 20a, or BS 200) can forward information of parameter settings to an intermediate node via 3GPP interface, e.g., Uu interface. The information includes R2D signal transmission over R2D link, D2R signal transmission over D2R link, or carrier wave signal transmission from an intermediate node (e.g., UE) to an A-IoT device or from a carrier wave source node to an A-IoT device.

[0053] For Topologies 1 / 2, BS (e.g., gNB, BS 20a, or BS 200) or an intermediate node (e.g., gNB) can exchange information of parameter settings with an external carrier wave source node via 3GPP or non-3GPP interface. The information includes configurations of an external carrier wave source node, such as activation of carrier wave signal transmission, generation scheme of carrier wave signal, or transmission scheme of carrier wave signal.

[0054] With reference to FIG. 5, a telecommunication system including a UE 10a, a base station 20a, a base station 20b, and a network entity device 30 executes the disclosed method according to an embodiment of the present disclosure. FIG. 5 is shown for illustrative, not limiting, and the system may comprise more UEs, BSs, and CN entities. Connections between devices and device components are shown as lines and arrows in the FIGs. The UE 10a may include a processor 11a, a memory 12a, and a transceiver 13a. The base station 20a may include a processor 21a, a memory 22a, and a transceiver 23a. The base station 20b may include a processor 21b, a memory 22b, and a transceiver 23b. The network entity device 30 may include a processor 31, a memory 32, and a transceiver 33. Each of the processors 11a, 21a, 21b, and 31 may be configured to implement the proposed functions, procedures, and / or methods described in this description. Layers of radio interface protocol may be implemented in the processors 11a, 21a, 21b, and 31. Each of the memory 12a, 22a, 22b, and 32 operatively stores a variety of programs and information to operate a connected processor. Each of the transceivers 13a, 23a, 23b, and 33 is operatively coupled with a connected processor, and transmits and / or receives a radio signal. Each of the base stations 20a and 20b may be an eNB, a gNB, or one of other radio nodes.

[0055] Each of the processors 11a, 21a, 21b, and 31 may include a general-purpose central processing unit (CPU) , application-specific integrated circuits (ASICs) , other chipsets, logic circuits and / or data processing devices. Each of the memory 12a, 22a, 22b, and 32 may include read-only memory (ROM) , a random-access memory (RAM) , a flash memory, a memory card, a storage medium and / or other storage devices. Each of the transceivers 13a, 23a, 23b, and 33 may include baseband circuitry and radio frequency (RF) circuitry to process radio frequency signals. When the embodiments are implemented in software, the techniques described herein can be implemented with modules, procedures, functions, entities and so on, that perform the functions described herein. The modules can be stored in a memory and executed by the processors. The memory can be implemented within a processor or external to the processor, in which those can be communicatively coupled to the processor via various means are known in the art.

[0056] The network entity device 30 may be a node in a CN. CN may include LTE CN or 5GC which may include user plane function (UPF) , session management function (SMF) , access and mobility management function (AMF) , unified data management (UDM) , policy control function (PCF) , control plane (CP)  / user plane (UP) separation (CUPS) , authentication server (AUSF) , network slice selection function (NSSF) , and the network exposure function (NEF) .

[0057] With reference to FIG. 5 and FIG. 11, the A-IoT device 60a may include a logical circuit 11a, a memory 12a, and a transceiver 13a. The logical circuit 11a is configured to call and run an A-IoT function, to cause A-IoT device 60a in which the logical circuit 11a is installed to execute the disclosed method, steps, and / or functions of an A-IoT device. The transceiver 13a may include baseband circuitry and radio frequency (RF) circuitry.

[0058] An example of A-IoT device in the description may include A-IoT device 60a. An example of the UE in the description may include one of the UE 10a or UE 10b. An example of the base station or gNB in the description may include the base station 20a. The term “resource” unless otherwise specified may be interpreted as radio resources in time domain and / or frequency domain.

[0059] Embodiments of the invention are detailed in the following:

[0060] In the following embodiments, the network node refers to any existing or future node specified in a 3GPP network that operates within the A-IoT topology or architecture. These network nodes support at least some 3GPP protocols through wired or wireless connections. Such nodes include gNBs, user equipment (UE) , relay nodes, integrated access and backhaul nodes (IAB) , A-IoT devices with partial 3GPP protocol support, intermediate nodes, and assisting nodes.

[0061] With reference to FIG. 8, a network node 40 (e.g., BS 20a, UE 10a, UE 10b, or an external network node) and at least one A-IoT device (e.g., one or more A-IoT devices 60a) performs an embodiment of the a channel access method in a random access procedure over an Internet of things (IoT) interface, with backscatter communication enabled device-to-reader signal transmission The A-IoT device 60a in the schematic diagram may comprise one or more than one A-IoT device. Examples of the external network node may comprise an intermediate node in Topologies 1 / 2. Step A001: The network node 40 transmits a trigger signal to A-IoT device 60a. Step A002: The A-IoT device 60a receives the trigger signal from the network node. Step A003: The A-IoT device 60a determines a resource location for transmitting a first device-to- reader IoT signal according to the trigger signal. Step A004: The A-IoT device 60a transmits the first device-to-reader IoT signal at the determined  resource location to the network node. Step A005: The network node 40 receives the first device-to-reader IoT signal at the resource  location from the IoT device, wherein the resource location is determined based on the trigger signal. Step A006: The network node 40 transmits a first reader-to-device IoT signal to the IoT device. Step A007: The A-IoT device 60a receives the first reader-to-device IoT signal from the network  node. Step A008: The A-IoT device 60a determines whether to transmit a second device-to-reader IoT  signal to the network node based on the first reader-to-device IoT signal upon receiving the first reader-to-device IoT signal. Step A009: The A-IoT device 60a transmits the second device-to-reader IoT signal to the network  node if the determination to transmit the second device-to-reader IoT signal is positive. The A-IoT device 60a does not transmit the second device-to-reader IoT signal to the network node if the determination to transmit the second device-to-reader IoT signal is not positive. Step A010: The network node 40 receives the second device-to-reader IoT signal from the IoT  device.

[0062] With reference to FIG. 9, a network node 40 (e.g., BS 20a, UE 10a, UE 10b, or an external network node) and at least one A-IoT device (e.g., one or more A-IoT devices 60a) performs an embodiment of the a channel access method in a random access procedure over an Internet of things (IoT) interface, with backscatter communication enabled device-to-reader signal transmission The A-IoT device 60a in the schematic diagram may comprise one or more than one A-IoT device. Examples of the external network node may comprise an intermediate node in Topologies 1 / 2. Step B001: The network node 40 transmits a trigger signal to an IoT device. Step B002: The A-IoT device 60a receives the trigger signal from a network node. Step B003: The A-IoT device 60a determines, based on information carried in the trigger signal,  whether to transmit a message carried in a first device-to-reader IoT signal to the network node upon receiving the information carried in the trigger signal. Step B004: The A-IoT device 60a transmits the message carried in the first device-to-reader IoT  signal to the network node if the determination is positive. The A-IoT device 60a does not transmit the message carried in the first device-to-reader IoT signal to the network node if the determination is not positive. Step B005: The network node 40 receives a message carried in a first device-to-reader IoT signal  from the IoT device if the IoT device determines to transmit the message based on information carried in the trigger signal upon the IoT device receiving information carried in the trigger signal; Step B006: The network node 40 transmits a first reader-to-device IoT signal to the IoT device in  response to the received first device-to-reader IoT signal. Step B007: The A-IoT device 60a receives the first reader-to-device IoT signal from the network  node in response to the transmitted first device-to-reader IoT signal. Step B008: The A-IoT device 60a determines whether to transmit a message carried in a second  device-to-reader IoT signal to the network node based on information carried in the first reader-to-device IoT signal upon receiving the information carried in the first reader-to-device IoT signal; Step B009: The A-IoT device 60a transmits the message carried in the second device-to-reader  IoT signal to the network node if the determination to transmit the message carried in the second device-to-reader IoT signal is positive. The A-IoT device 60a does not transmit the message carried in the second device-to-reader IoT signal to the network node if the determination to transmit the message carried in the second device-to-reader IoT signal is not positive. Step B010: The network node 40 detects the message carried in the second device-to-reader IoT  signal from the IoT device if the IoT device determines to transmit the message carried in the second device-to-reader IoT signal based on information carried in the first reader-to-device IoT signal upon the IoT device receiving information carried in the first reader-to-device IoT signal; and Step B011: The network node 40 determines whether to transmit to the IoT device a second  reader-to-device IoT signal in response to the message carried in the second device-to-reader IoT signal according to a decoding result of the message carried in the second device-to-reader IoT signal.  Step B012: The A-IoT device 60a determines whether the message carried in the second device- to-reader IoT signal is successfully received by the network node.

[0063] With reference to FIG. 10, a network node 40 (e.g., BS 20a, UE 10a, UE 10b, or an external network node) and at least one A-IoT device (e.g., one or more A-IoT devices 60a) performs an embodiment of the a channel access method in a random access procedure over an Internet of things (IoT) interface, with backscatter communication enabled device-to-reader signal transmission The A-IoT device 60a in the schematic diagram may comprise one or more than one A-IoT device. Examples of the external network node may comprise an intermediate node in Topologies 1 / 2. Step C001: The network node 40 determines a time point for transmitting a trigger signal to at  least one IoT device. Step C002: The network node 40 transmits the trigger signal to the at least one IoT device  according to the determined time point. Step C003: The A-IoT device 60a receives the trigger signal from a network node at a time point. Step C004: The A-IoT device 60a transmits a message carried in one of at least one first device- to-reader IoT signal from the IoT device among the at least one IoT device to the network node. Step C005: The network node 40 detects the message carried in each of the at least one first  device-to-reader IoT signal from the at least one IoT device; Step C006: The network node 40 determines one or more than one target IoT device in response  to the detected message carried in each of the at least one first device-to-reader IoT signal; Step C007: The network node 40 transmits a message carried in a first reader-to-device IoT  signal to the one or more than one target IoT device; Step C008: The A-IoT device 60a receives the message carried in a first reader-to-device IoT  signal from the network node in response to the transmitted message carried in the one of the at least one first device-to-reader IoT signal; Step C009: The A-IoT device 60a transmits a message carried in one (e.g., second device-to- reader IoT signal 401) of one or more than one second device-to-reader IoT signal to the network node; Step C010: The network node 40 detects the message carried in one of one or more than one  second device-to-reader IoT signal (including the second device-to-reader IoT signal 401) from one of the one or more than one target IoT device. In an embodiment, the network node 40 detects the message carried in each of one or more than one second device-to-reader IoT signal (including the second device-to-reader IoT signal 401) from the one or more than one target IoT device. Step C011: The network node 40 determines whether to transmit a message in a second reader- to-device IoT signal to the one of the one or more than one target IoT device according to a decoding result of the detected message carried in the one of the one or more than one second device-to-reader IoT signal associated with the one of the one or more than one target IoT device. In an embodiment, the network node 40 determines whether to transmit a message in a second reader-to-device IoT signal to one of the one or more than one target IoT device according to a decoding result of the detected message carried in each of the one or more than one second device-to-reader IoT signal. Step C012: The IoT device determines a decoding result, at the network node, of the message  carried in the one of the one or more than one second device-to-reader IoT signal associated with the IoT device according to whether a message carried in a second reader-to-device IoT signal is detected by the IoT device.

[0064] With reference to FIG. 8, more features associated with the disclosed method are detailed in the following.

[0065] In one or more embodiments of the disclosure, the network node is a base station or a UE, and if the network node is a UE, the UE receives control information regarding reader-to-device IoT signal transmission or device-to-reader IoT signal transmission from a base station.

[0066] In one or more embodiments of the disclosure, the trigger signal includes a paging message, and the paging message is transmitted in a Medium Access Control (MAC) layer of the IoT interface.

[0067] In one or more embodiments of the disclosure, the paging message includes an indication specifying the random access procedure is contention-based, and the paging message further includes an identifier associated with a group of IoT devices for performing the random access procedure, wherein the IoT device is one of the group of IoT devices.

[0068] In one or more embodiments of the disclosure, the paging message includes an indication specifying the random access procedure is contention-free, and the paging message further includes an identifier associated with the IoT device for performing the random access procedure.

[0069] In one or more embodiments of the disclosure, the trigger signal includes an indication specifying a number of transmission occasions for transmission of a first random access message in the first device-to-reader IoT signal.

[0070] In one or more embodiments of the disclosure, the IoT device randomly determines a first random access message resource among the number of transmission occasions for transmission of the first random access message in the first device-to-reader IoT signal.

[0071] In one or more embodiments of the disclosure, a location of received trigger signal is used to determine a starting point of a first random access message resource among the number of transmission occasions for the first random access message to be transmitted in the first device-to-reader IoT signal.

[0072] In one or more embodiments of the disclosure, a starting point of a first random access message resource among the number of transmission occasions for transmission of the first random access message is determined based on a number of reference time units elapsed from an ending point of the trigger signal.

[0073] In one or more embodiments of the disclosure, the reference time unit is derived from chip rate information associated with a physical reader-to-device channel (PRDCH) received in the trigger signal or associated with a physical device-to-reader channel (PDRCH) transmitted in the first device-to-reader IoT signal.

[0074] In one or more embodiments of the disclosure, the chip rate information associated with a PRDCH received in the trigger signal is derived from a preamble immediately preceding the PRDCH.

[0075] In one or more embodiments of the disclosure, the chip rate information associated with a PDRCH transmitted in the first device-to-reader IoT signal is derived from control information carried in the trigger signal.

[0076] In one or more embodiments of the disclosure, the trigger signal includes a PRDCH and a postamble immediately following the PRDCH, the starting point of the first random access message resource among the number of transmission occasions is determined based on a time offset relative to an ending point of the trigger signal.

[0077] In one or more embodiments of the disclosure, the PRDCH is immediately preceded by a preamble, and a sequence length of a postamble following the PRDCH is shorter than a sequence length of the preamble preceding the PRDCH.

[0078] In one or more embodiments of the disclosure, the time offset is defined in units of a reference time granularity.

[0079] In one or more embodiments of the disclosure, the time offset value for transmission of the first random access message is one of one or more predefined or standardized values.

[0080] In one or more embodiments of the disclosure, a location of the received first reader-to-device IoT signal is used to determine a starting point of a third random access message resource for transmission of the third random access message in the second device-to-reader IoT signal.

[0081] In one or more embodiments of the disclosure, the first reader-to-device IoT signal includes a PRDCH and a postamble immediately following the PRDCH, wherein the starting point of the third random access message resource is determined based on a time offset relative to an ending point of the first reader-to-device IoT signal.

[0082] In one or more embodiments of the disclosure, the time offset is defined in units of reference time granularity.

[0083] In one or more embodiments of the disclosure, the time offset value for the third random access message transmission is one of one or more predefined or standardized values.

[0084] In one or more embodiments of the disclosure, the paging message includes an indication specifying the random access procedure is contention-free, and the paging message further includes an indication specifying a specified first random access message resource for the IoT device to determine a resource location for transmission of the first random access message in the first device-to-reader IoT signal.

[0085] In one or more embodiments of the disclosure, the paging message is carried in a PRDCH, and the PRDCH is immediately followed by a postamble, the starting point of the specified first random access message resource is determined from an ending point of the postamble.

[0086] In one or more embodiments of the disclosure, the indication indicates an index of a frequency domain resource or a time domain resource for transmission of the first random access message in the first device-to-reader IoT signal.

[0087] In one or more embodiments of the disclosure, a length of a guard period between consecutive transmission occasions for transmission of the first random access message in the first device-to-reader IoT signal is reserved.

[0088] In one or more embodiments of the disclosure, the length of a guard period is expressed in terms of a time unit for scheduling transmission of the first random access message.

[0089] In one or more embodiments of the disclosure, the length of guard period is one of one or more predefined or standardized values.

[0090] In one or more embodiments of the disclosure, the trigger signal or the first reader-to-device IoT signal includes control information transmitted in an MAC layer of the IoT interface, and the control information includes an indication specifying a payload size or transport block size (TBS) of an associated message being transmitted in the trigger signal or the first reader-to-device IoT signal.

[0091] In one or more embodiments of the disclosure, the TBS is determined based on a message type being transmitted in the trigger signal or the first reader-to-device IoT signal.

[0092] In one or more embodiments of the disclosure, the paging message includes an indication specifying the random access procedure is contention-free, the first reader-to-device IoT signal includes control information transmitted in the MAC layer of the IoT interface, and the control information includes an indication specifying a payload size or transport block size (TBS) of a message being transmitted in the second device-to-reader IoT signal.

[0093] In one or more embodiments of the disclosure, the paging message includes an indication specifying the random access procedure is contention-based, and a payload size or transport block size (TBS) of a first random access message being transmitted in the first device-to-reader IoT signal or a third random access message being transmitted in the second device-to-reader IoT signal is one of one or more predefined or standardized values.

[0094] In one or more embodiments of the disclosure, the paging message includes an indication specifying the random access procedure is contention-free, and a payload size or transport block size (TBS) of a first random access message being transmitted in the first device-to-reader IoT signal is one of one or more predefined or standardized values.

[0095] In one or more embodiments of the disclosure, the paging message includes an indication specifying the random access procedure is contention-based, wherein the contention-based random access procedure is a 3-step random access procedure.

[0096] In one or more embodiments of the disclosure, the paging message includes an indication specifying the random access procedure is contention-free, wherein the contention-free random access procedure is a 1-step random access procedure.

[0097] In one or more embodiments of the disclosure, a maximum time offset or a minimum time offset for the IoT device to determine a time region for transmitting the first device-to-reader IoT signal or the second device-to-reader IoT signal is a standardized value, wherein the maximum time offset or the minimum time offset is relative to an ending point of the trigger signal or the first reader-to-device IoT signal.

[0098] In one or more embodiments of the disclosure, a maximum time offset or a minimum time offset for the network node to determine a time region for receiving the first device-to-reader IoT signal or the second device-to-reader IoT signal is a standardized value, wherein the maximum time offset or the minimum time offset is relative to an ending point of the trigger signal or the first reader-to-device IoT signal.

[0099] In one or more embodiments of the disclosure, the trigger signal or the first reader-to-device IoT signal includes control information transmitted in an MAC layer of the IoT interface, and the control information includes an indication specifying a repetition number for data transmission in the first device-to-reader IoT signal or the second device-to-reader IoT signal.

[0100] In one or more embodiments of the disclosure, the trigger signal or the first reader-to-device IoT signal includes control information transmitted in an MAC layer of the IoT interface, and the control information includes an indication specifying a channel coding scheme for data transmission in the first device-to-reader IoT signal or the second device-to-reader IoT signal.

[0101] In one or more embodiments of the disclosure, the trigger signal or the first reader-to-device IoT signal includes control information transmitted in an MAC layer of the IoT interface, and the control information includes an indication specifying a length of a midamble or a length of a preamble to be adopted in the first device-to-reader IoT signal or the second device-to-reader IoT signal.

[0102] In one or more embodiments of the disclosure, the trigger signal or the first reader-to-device IoT signal includes control information transmitted in an MAC layer of the IoT interface, and the control information includes an indication specifying presence of a midamble in the first device-to-reader IoT signal or the second device-to-reader IoT signal.

[0103] In one or more embodiments of the disclosure, the number of transmission occasions for transmission of the first random access message includes both time domain resources as well as frequency domain resources.

[0104] In one or more embodiments of the disclosure, the paging message includes an indication specifying a random access scheme for the IoT device, the first device-to-reader IoT signal includes a first random access message according to the random access scheme, wherein the first random access message includes an ID associated with the IoT device.

[0105] In one or more embodiments of the disclosure, if the random access scheme is contention-based, the ID associated with the IoT device is a random ID generated by the IoT device with a length of 16 bits.

[0106] In one or more embodiments of the disclosure, if the random access scheme is contention-free, the ID associated with the IoT device carried in the first random access message is a random ID generated by the IoT device or a dedicated ID previously assigned by the network node.

[0107] In one or more embodiments of the disclosure, the first reader-to-device IoT signal comprises a second random access message, and the IoT device determines to transmit a third random access message in the second device-to-reader IoT signal if the second random access message includes an ID identical to the random ID generated by the IoT device.

[0108] In one or more embodiments of the disclosure, the first reader-to-device IoT signal comprises a second random access message, and the network node determines to receive a third random access message in the second device-to-reader IoT signal if the second random access message includes an ID identical to the random ID generated by the IoT device.

[0109] In one or more embodiments of the disclosure, the second random access message further includes a dedicated ID associated with the IoT device and the dedicated ID is assigned by the network node with a length of 16 bits.

[0110] In one or more embodiments of the disclosure, the first reader-to-device IoT signal comprises a higher layer message, and the IoT device determines to transmit the second device-to-reader IoT signal to the network node if the higher layer message includes an ID identical to the random ID generated by the IoT device.

[0111] In one or more embodiments of the disclosure, the first reader-to-device IoT signal comprises a higher layer message, and the network node determines to receive the second device-to-reader IoT signal to the network node if the higher layer message includes an ID identical to the random ID generated by the IoT device.

[0112] In one or more embodiments of the disclosure, the first reader-to-device IoT signal comprises a higher layer message, and the IoT device determines to transmit the second device-to-reader IoT signal to the network node if the higher layer message includes an ID identical to the dedicated ID previously assigned by the network node.

[0113] In one or more embodiments of the disclosure, the first reader-to-device IoT signal comprises a higher layer message, and the network node determines to receives the second device-to-reader IoT signal to the network node if the higher layer message includes an ID identical to the dedicated ID previously assigned by the network node.

[0114] In one or more embodiments of the disclosure, the first reader-to-device IoT signal comprises a higher layer message, and the IoT device determines to transmit the second device-to-reader IoT signal to the network node if the higher layer message includes a command to request the IoT device to report IoT data from the IoT device.

[0115] In one or more embodiments of the disclosure, the first reader-to-device IoT signal comprises a higher layer message, and the network node determines to receives the second device-to-reader IoT signal to the network node if the higher layer message includes a command to request the IoT device to report IoT data from the IoT device.

[0116] In one or more embodiments of the disclosure, the higher layer message includes an ID associated with the IoT device, showing that the IoT device is a target IoT device for receiving the command.

[0117] In one or more embodiments of the disclosure, the ID associated with the IoT device carried in the first random access message is a random ID generated by the IoT device, the first reader-to-device IoT signal comprises a higher layer message, and the higher layer message includes a dedicated ID assigned by the network node.

[0118] In one or more embodiments of the disclosure, the higher layer message carried in the first reader-to-device IoT signal includes scheduling information for a higher layer message transmitted in the second device-to-reader IoT signal.

[0119] In one or more embodiments of the disclosure, the first reader-to-device IoT signal comprises a second random access message including one or more than one random ID associated with one or more than one IoT device, and the second random access message further includes corresponding resource scheduling of one or more than one third random access message for the one or more than one IoT device to transmit the one or more than one third random access message in one or more than one second device-to-reader IoT signal.

[0120] In one or more embodiments of the disclosure, if the second random access message includes more than one random ID, each resource for transmitting each third random access message in a corresponding second device-to-reader IoT signal that conveys the third random access message is scheduled based on a frequency division multiple access (FDMA) scheme.

[0121] In one or more embodiments of the disclosure, each of resources scheduled for transmitting third random access messages in corresponding second device-to-reader IoT signals has the same resource size.

[0122] In one or more embodiments of the disclosure, the same second random access message is retransmitted by the network node if the network node fails to receive a third random access message transmitted in the second device-to-reader IoT signal.

[0123] In one or more embodiments of the disclosure, after the IoT device transmitting the first device-to-reader IoT signal, the IoT device commences monitoring the first reader-to-device IoT signal at or after a time offset relative to the ending point of the first device-to-reader IoT signal.

[0124] In one or more embodiments of the disclosure, the time offset is used for indicating an earliest time point for the IoT device to monitor the first reader-to-device IoT signal and a length of the time offset is a standardized value.

[0125] In one or more embodiments of the disclosure, the third random access message includes a decoding result of the second random access message carried in the first reader-to-device IoT signal.

[0126] In one or more embodiments of the disclosure, the third random access message includes an ID identical to the random ID carried in the second random access message.

[0127] In one or more embodiments of the disclosure, the third random access message includes an ID identical to the dedicated ID carried in the second random access message.

[0128] In one or more embodiments of the disclosure, another first reader-to-device IoT signal carrying the same second random access message is detected by the IoT device if the IoT device fails to receive the second random access message .

[0129] In one or more embodiments of the disclosure, another first reader-to-device IoT signal carrying the same second random access message is transmitted to the IoT device if the IoT device fails to receive the second random access message .

[0130] In one or more embodiments of the disclosure, the IoT device transmits another first random access message in another first device-to-reader signal if the second random access message fails to include an ID identical to the random ID generated by the IoT device.

[0131] In one or more embodiments of the disclosure, the network node receives another first random access message in another first device-to-reader signal if the second random access message fails to include an ID identical to the random ID generated by the IoT device.

[0132] In one or more embodiments of the disclosure, the second random access message includes a command for requesting an IoT data report from the IoT device, and the IoT data requested by the command is carried in the third random access message.

[0133] In one or more embodiments of the disclosure, a frequency domain resource used for the third random access message in the second device-to-reader IoT signal is the same as a frequency domain resource used for the first random access message in the first device-to-reader IoT signal.

[0134] In one or more embodiments of the disclosure, the IoT device receives another trigger signal, and the IoT device refrains from transmitting another first device-to-reader IoT signal if the IoT device succeeds in channel access during a previous run of random access procedure .

[0135] In one or more embodiments of the disclosure, the IoT device receives another trigger signal, and the IoT device determines to transmit another first device-to-reader IoT signal if the IoT device fails in channel access during a previous run of random access procedure .

[0136] In one or more embodiments of the disclosure, the network node transmits another trigger signal to the IoT device, and the IoT device determines to transmit another first device-to-reader IoT signal if the IoT device fails in channel access during a previous run of random access procedure .

[0137] In one or more embodiments of the disclosure, the IoT device further receives a second reader-to-device IoT signal from the network node, wherein the second reader-to-device IoT signal includes a high layer message, and the high layer message includes a NACK-based hybrid automatic repeat request (HARQ) feedback in response to the third random access message carried in the second device-to-reader IoT signal if the network node fails to receive or decode the third random access message.

[0138] In one or more embodiments of the disclosure, the network node further transmits a second reader-to-device IoT signal from to the IoT device, wherein the second reader-to-device IoT signal includes a high layer message, and the high layer message includes a NACK-based hybrid automatic repeat request (HARQ) feedback in response to the third random access message carried in the second device-to-reader IoT signal if the network node fails to receive or decode the third random access message.

[0139] In one or more embodiments of the disclosure, when receiving the NACK-based HARQ feedback in response to the third random access message, the IoT device re-transmits the third random access message in another second device-to-reader IoT signal.

[0140] In one or more embodiments of the disclosure, when transmitting the NACK-based HARQ feedback in response to the third random access message, the network node receives the third random access message in another second device-to-reader IoT signal.

[0141] In one or more embodiments of the disclosure, if the NACK-based HARQ feedback in response to the third random access message is received by the IoT device, the IoT device performs another channel access via transmitting another first device-to-reader IoT signal upon receiving another trigger signal transmitted from the network node.

[0142] The channel access method of claim 68, wherein the IoT device refrains from performing an additional channel access by transmitting another first device-to-reader IoT signal upon receiving another trigger signal transmitted from the network node.

[0143] In one or more embodiments of the disclosure, the IoT device assumes the transmitted third random access message in the second device-to-reader IoT signal is successfully received by the network node if the IoT device fails to receive a second reader-to-device IoT signal from the network node, wherein the second reader-to-device IoT signal includes a NACK-based HARQ feedback in response to the third random access message.

[0144] In one or more embodiments of the disclosure, the IoT device assumes the transmitted third random access message in the second device-to-reader IoT signal is successfully received by the network node if failing to receive the NACK-based HARQ feedback in response to the third random access message in the second reader-to-device IoT signal within a time window.

[0145] In one or more embodiments of the disclosure, the IoT device further receives a second reader-to-device IoT signal from the network node, wherein the second reader-to-device IoT signal includes a high layer message and the high layer message includes a command that requests for an IoT data report from the IoT device, the IoT device transmits a high layer message in a third device-to-reader IoT signal, wherein the higher layer message in the third device-to-reader IoT signal carries the IoT data requested by the command.

[0146] In one or more embodiments of the disclosure, the network node further transmits a second reader-to-device IoT signal to the IoT device, wherein the second reader-to-device IoT signal includes a high layer message and the high layer message includes a command that requests for an IoT data report from the IoT device, the network node receives a high layer message in a third device-to-reader IoT signal, wherein the higher layer message in the third device-to-reader IoT signal carries the IoT data requested by the command.

[0147] In one or more embodiments of the disclosure, the IoT device assumes the transmitted high layer message in the third device-to-reader IoT signal is successfully decoded by the network node if the IoT device fails to receive a third reader-to-device IoT signal from the network node, wherein the third reader-to-device IoT signal includes a NACK-based HARQ feedback in response to the high layer message carried in the third device-to-reader IoT signal.

[0148] In one or more embodiments of the disclosure, the IoT device assumes the higher layer message in the third device-to-reader IoT signal fails to be decoded by the network node if the IoT device receives a third reader-to-device IoT signal from the network node, wherein the third reader-to-device IoT signal includes a NACK-based HARQ feedback in response to the higher layer message carried in the third device-to-reader IoT signal .

[0149] In one or more embodiments of the disclosure, if the NACK-based HARQ feedback in response to the higher layer message carried in the third device-to-reader IoT signal is received by the IoT device, the IoT device re-transmits the higher layer message in another third device-to-reader IoT signal.

[0150] With reference to FIG. 9, more features associated with the disclosed method are detailed in the following.

[0151] In one or more embodiments of the disclosure, the network node is a base station or a UE, and if the network node is a UE, the UE receives control information regarding reader-to-device IoT signal transmission or device-to-reader IoT signal transmission from a base station.

[0152] In one or more embodiments of the disclosure, the trigger signal comprises a paging message transmitted in a Medium Access Control (MAC) layer of the IoT interface, the IoT device determines to transmit the message carried in the first device-to-reader IoT signal to the network node if a single device identifier or a group device identifier associated with the IoT device is received by the IoT device.

[0153] In one or more embodiments of the disclosure, the paging message includes an indication specifying whether contention-free random access or contention-based random access is used by the IoT device associated with the single device identifier or the group device identifier.

[0154] In one or more embodiments of the disclosure, the IoT device determines to transmit the message carried in the first device-to-reader IoT signal to the network node if a capability of the IoT device matches an operation requirement of an IoT procedure.

[0155] In one or more embodiments of the disclosure, the IoT device determines to transmit the message carried in the first device-to-reader IoT signal to the network node if a device type of the IoT device matches an operation requirement of an IoT procedure.

[0156] In one or more embodiments of the disclosure, the IoT device determines whether to transmit the message carried in the first device-to-reader IoT signal according to a value of a counter, wherein the counter is used for counting a number of accumulated trigger signals transmitted from the network node and detected by the IoT device.

[0157] In one or more embodiments of the disclosure, the IoT device determines whether to transmit the message carried in the first device-to-reader IoT signal according to a location of a time window, wherein the time window is defined as a time range within which the first device-to-reader IoT signal can be transmitted.

[0158] In one or more embodiments of the disclosure, the IoT device determines whether to transmit the message carried in the first device-to-reader IoT signal or in the second device-to-reader IoT signal according to amount of remaining energy available for transmitting the first device-to-reader IoT signal with backscatter communication.

[0159] In one or more embodiments of the disclosure, the IoT device determines whether to transmit the message carried in the first device-to-reader IoT signal or in the second device-to-reader IoT signal according to detectability of a carrier wave signal being transmitted from a carrier source node.

[0160] In one or more embodiments of the disclosure, the IoT device determines to transmit the message carried in the first device-to-reader IoT signal if the IoT device determines the IoT device fails in a previous round of a random access procedure.

[0161] In one or more embodiments of the disclosure, the IoT device determines to transmit the message carried in the second device-to-reader IoT signal if the IoT device receives a confirmation in the first reader-to-device IoT signal showing that the message carried in the first device-to-reader IoT signal is correctly received by the network node.

[0162] In one or more embodiments of the disclosure, the confirmation is a message, and the message includes an ID with a length of 16 bits, and the ID matches an ID in the message carried in the first device-to-reader IoT signal.

[0163] In one or more embodiments of the disclosure, the second reader-to-device IoT signal includes an ID associated with the IoT device, and the ID is a dedicated ID assigned by the network node for the IoT device.

[0164] In one or more embodiments of the disclosure, the trigger signal includes an indication specifying a number of transmission occasions for the message carried in the first device-to-reader IoT signal.

[0165] In one or more embodiments of the disclosure, the IoT device determines to transmit the message carried in the first device-to-reader IoT signal according to a randomly selected transmission occasion among the number of transmission occasions.

[0166] In one or more embodiments of the disclosure, the IoT device determines to transmit the message carried in the second device-to-reader IoT signal to the network node if the IoT device receives a transmission grant associated with the IoT device in the first reader-to-device IoT signal, wherein the transmission grant includes a resource location for transmitting the message carried in the second device-to-reader IoT signal.

[0167] In one or more embodiments of the disclosure, the transmission grant includes resource locations for more than one IoT device to perform message transmission in respective second device-to-reader IoT signals.

[0168] In one or more embodiments of the disclosure, the resource locations for more than one IoT device to perform message transmission in respective second device-to-reader IoT signals are scheduled according to a frequency domain multiple access (FDMA) based scheme.

[0169] In one or more embodiments of the disclosure, the IoT device determines the network node fails to receive the message carried in the second device-to-reader IoT signal if the IoT device has detected a second reader-to-device IoT signal, wherein the second reader-to-device IoT signal includes a NACK-based HARQ feedback in response to the message carried in the second device-to-reader IoT signal.

[0170] In one or more embodiments of the disclosure, if the NACK-based HARQ feedback in response to the message carried in the second device-to-reader IoT signal is received by the IoT device, the IoT device re-accesses the channel via transmitting another first device-to-reader IoT signal upon receiving another trigger signal transmitted from the network node.

[0171] In one or more embodiments of the disclosure, the IoT device determines the transmitted message in the second device-to-reader IoT signal is successfully received by the network node if the IoT device does not receive a second reader-to-device IoT signal from the network node, wherein the second reader-to-device IoT signal includes a NACK-based HARQ feedback in response to the message carried in the second device-to-reader IoT signal.

[0172] In one or more embodiments of the disclosure, the IoT device receives another trigger signal after transmitting the second device-to-reader IoT signal, and the IoT device refrains from performing an additional channel access by transmitting another first device-to-reader IoT signal upon receiving the another trigger signal.

[0173] In one or more embodiments of the disclosure, if the NACK-based HARQ feedback in response to the message carried in the second device-to-reader IoT signal is received by the IoT device, the IoT device re-transmits the message in another second device-to-reader IoT signal.

[0174] In one or more embodiments of the disclosure, if the IoT device determines not to transmit a message carried in a second device-to-reader IoT signal to the network node upon receiving information carried in the first reader-to-device IoT signal, the IoT-device performs an additional channel access via transmitting another first device-to-reader IoT signal upon receiving another trigger signal transmitted from the network node.

[0175] In one or more embodiments of the disclosure, the IoT device determines the network node fails to receive the message carried in the second device-to-reader IoT signal if the IoT device has detected a second reader-to-device IoT signal, and the second reader-to-device IoT signal includes a transmission grant for the IoT device to retransmits the message carried in the second device-to-reader IoT signal.

[0176] In one or more embodiments of the disclosure, the second reader-to-device IoT signal includes an ID associated with the IoT device, and the ID associated with the IoT device is the same as an ID transmitted in the massage of the first device-to-reader IoT signal.

[0177] In one or more embodiments of the disclosure, the IoT device determines the transmitted message in the second device-to-reader IoT signal is successfully received by the network node if the IoT device fails to receive a second reader-to-device IoT signal from the network node for a period of time, wherein the second reader-to-device IoT signal includes a NACK-based HARQ feedback in response to the message carried in the second device-to-reader IoT signal.

[0178] In one or more embodiments of the disclosure, control information is included in the trigger signal or in the first reader-to-device IoT signal, the control information includes a type of information or message being carried in the trigger signal or in the first reader-to-device IoT signal.

[0179] In one or more embodiments of the disclosure, the control information is transmitted in a Medium Access Control (MAC) layer of the IoT interface.

[0180] With reference to FIG. 10, more features associated with the disclosed method are detailed in the following.

[0181] In one or more embodiments of the disclosure, the network node is a base station or a UE, and if the network node is a UE, the UE receives control information regarding reader-to-device IoT signal transmission or device-to-reader IoT signal transmission from a base station.

[0182] In one or more embodiments of the disclosure, the network node determines a time point to transmit the trigger signal to the at least one IoT device according to availability of a carrier wave signal for the at least one IoT device to perform backscatter communication.

[0183] In one or more embodiments of the disclosure, the network node determines a time point to transmit the trigger signal to the at least one IoT device according to remaining energy available for the at least one IoT device to perform backscatter communication.

[0184] In one or more embodiments of the disclosure, the network node determines a time point to transmit the trigger signal to the at least one IoT device according to a periodicity for periodic trigger signal transmissions.

[0185] In one or more embodiments of the disclosure, the network node determines a time point to transmit the trigger signal to the at least one IoT device according to a type of IoT device being requested.

[0186] In one or more embodiments of the disclosure, the network node determines a time point to transmit the trigger signal to the at least one IoT device according to a decoding result of the detected message carried in the at least one second device-to-reader IoT signal.

[0187] In one or more embodiments of the disclosure, the network node determines a time point to transmit the trigger signal to the at least one IoT device according to a number of transmission occasions for transmission of a message carried in the first device-to-reader IoT signal.

[0188] In one or more embodiments of the disclosure, the network node determines a time point to transmit the trigger signal to the at least one IoT device according to a length of a time window for performing a round of a random access procedure.

[0189] In one or more embodiments of the disclosure, the length of a time window depends on the number of transmission occasions available for transmission of a message carried in the first device-to-reader IoT signal.

[0190] In one or more embodiments of the disclosure, the network node determines a time point to transmit the trigger signal to the at least one IoT device based on whether the at least one IoT device fails in channel access during a previous round of random access procedure.

[0191] In one or more embodiments of the disclosure, the trigger signal comprises a paging message, and the paging message includes an indication specifying whether a contention-based random access scheme or a contention-free random access scheme is configured for the at least one IoT device.

[0192] In one or more embodiments of the disclosure, a size of the paging message depends on whether the contention-based random access scheme or contention-free random access scheme is triggered.

[0193] In one or more embodiments of the disclosure, the trigger signal or the first reader-to-device IoT signal comprises control information, the control information includes a type of information or message being carried in the trigger signal or the first reader-to-device IoT signal.

[0194] In one or more embodiments of the disclosure, the trigger signal or the first reader-to-device IoT signal comprises control information, and the control information includes a transport block size (TBS) of a data packet being carried in the trigger signal or the first reader-to-device IoT signal.

[0195] In one or more embodiments of the disclosure, the trigger signal comprises a paging message, and the paging message includes an identifier associated with a single IoT device or a group of IoT devices for responding the paging message.

[0196] In one or more embodiments of the disclosure, the trigger signal comprises a paging message, and the paging message includes an indication specifying more than one transmission occasion for the at least one IoT device to determine a resource for a message carried in the respective at least one first device-to-reader IoT signal.

[0197] In one or more embodiments of the disclosure, the more than one transmission occasion comprises time division multiple access (TDMA) based or frequency division multiple access (FDMA) based resource occasions.

[0198] In one or more embodiments of the disclosure, the message carried in one of the at least one first device-to-reader IoT signal includes an ID, the message is transmitted in a resource randomly selected by an IoT device among the more than one transmission occasion, and the ID is an ID randomly generated by the IoT device.

[0199] In one or more embodiments of the disclosure, the one or more than one target IoT device is determined based on detectability of one or more than one ID randomly generated by the at least one IoT device, and each of the one or more than one ID is included in a message carried in one of the at least one first device-to-reader IoT signal.

[0200] In one or more embodiments of the disclosure, the message carried in the first reader-to-device IoT signal includes one or more than one transmission grant for the determined one or more than one target IoT device to perform corresponding message transmission in the one or more than one second device-to-reader IoT signal.

[0201] In one or more embodiments of the disclosure, transmission grant resources scheduled for the determined one or more than one target IoT device is according to a frequency domain multiple access (FDMA) based scheme.

[0202] In one or more embodiments of the disclosure, the message carried in the first reader-to-device IoT signal includes one or more than one ID for the determined one or more than one target IoT device, each of the one or more than one ID is an ID generated by an IoT device and transmitted in one of the at least one first device-to-reader IoT signal.

[0203] In one or more embodiments of the disclosure, the message carried in the first reader-to-device IoT signal includes one or more than one ID for the determined one or more than one target IoT device, and each of the one or more than one ID is a dedicated ID assigned by the network node for an IoT device.

[0204] In one or more embodiments of the disclosure, the network node determines to transmit a message in the second reader-to-device IoT signal with a NACK-based hybrid automatic repeat request (HARQ) feedback in response to a message carried in a second device-to-reader IoT signal associated with an target IoT device if the network node fails in decoding the message carried in the second device-to-reader IoT signal associated with the target IoT device.

[0205] In one or more embodiments of the disclosure, the network node transmits another trigger signal after the second reader-to-device IoT signal, and the target IoT device receiving the second reader-to-device IoT signal with a NACK-based HARQ feedback performs an additional channel access by transmitting another first device-to-reader IoT signal upon receiving the another trigger signal transmitted from the network node.

[0206] In one or more embodiments of the disclosure, the target IoT device receives another trigger signal after the second reader-to-device IoT signal, and the target IoT device receiving the second reader-to-device IoT signal with a NACK-based HARQ feedback performs an additional channel access by transmitting another first device-to-reader IoT signal upon receiving the another trigger signal transmitted from the network node.

[0207] In one or more embodiments of the disclosure, the network node refrains from transmitting a decoding result in response to a message carried in a second device-to-reader IoT signal associated with an target IoT device if the network node successfully decodes the message carried in the second device-to-reader IoT signal associated with the target IoT device.

[0208] In one or more embodiments of the disclosure, the network node transmits another trigger signal, and the target IoT device refrains from performing an additional channel access by transmitting another first device-to-reader IoT signal upon receiving the another trigger signal.

[0209] In one or more embodiments of the disclosure, the target IoT device receives another trigger signal, and the target IoT device refrains from performing an additional channel access by transmitting another first device-to-reader IoT signal upon receiving the another trigger signal.

[0210] In one or more embodiments of the disclosure, the message carried in the second reader-to-device IoT signal includes a request for retransmission of a message carried in a second device-to-reader IoT signal from a target IoT device if the network node fails in decoding the message carried in the second device-to-reader IoT signal associated with the target IoT device.

[0211] In one or more embodiments of the disclosure, the message carried in the second reader-to-device IoT signal includes a retransmission of the message carried in the first reader-to-device IoT signal to a target IoT device if the network node fails in decoding a message carried in a second device-to-reader IoT signal associated with the target IoT device.

[0212] With the backscatter technology, an A-IoT device (e.g., A-IoT device 60a) (i.e., Device 1 and Device 2a) acting as a backscatter transmitter can harvest energy from carrier wave signals transmitted by a carrier wave source node and then transmits its data by reflecting and modulating the received carrier wave signals to either the same carrier wave source node or another network entity acting as a backscatter receiver. On the other hand. For Device 2b, carrier wave signal is internally generated and then modulated and transmitted using active RF components. In the description, signals transmitted from A-IoT devices to readers are categorized as follows: the reflected carrier wave signal transmitted from a backscatter transmitter (i.e., A-IoT Device 1 and Device 2a) is defined as a backscattered signal, while a signal transmitted from a transmitter with active RF components (i.e., Device 2b) is defined as an active signal. Since backscattered signal and active signal are transmitted from an A-IoT device (e.g., A-IoT device 60a) to a reader, they are collectively referred to as D2R signal or jointly indicated as backscattered / active signal. Unless otherwise specified, D2R signal and backscattered / active signal can be used interchangeably in the description. The information in the backscattered / active signal is conveyed by modifying amplitude, phase, or center frequency of an RF carrier. The RF carrier can be received from the carrier wave source node or be internally generated.

[0213] The backscatter technology can be categorized into monostatic based, bistatic based, or ambient based schemes. -In a monostatic based backscatter scheme, the carrier wave source node for transmitting carrier wave  signals and the backscatter receiver for receiving backscattered signals are integrated into a single device referred to as the reader. -For a bistatic based backscatter scheme, the carrier wave source node for transmitting carrier wave  signals and the backscatter receiver for receiving backscattered signals are located in separate, distinct devices. -For ambient based backscatter scheme, the excitation signals are received from ambient RF sources,  e.g., cellular base stations, Wi-Fi access points (Aps) , television / radio broadcast towers. Therefore, the A-IoT device can act as a backscatter transmitter to transmit backscattered signals directly to backscatter receivers without receiving excitation signals from a dedicated carrier wave source node.

[0214] Typical use cases of A-IoT procedures including inventory management (Inventory service) and command request (Command service) , which are associated with traffic types of device-originated-device-terminated triggered (DO-DTT) and device-terminated (DT) , respectively. The Inventory service uses a device identifier / identification (ID) or a group ID to track the presence of A-IoT devices, recognize A-IoT devices or count the number of A-IoT devices within a proximity area. A contention-based random-access procedure is suitable for Inventory service, wherein a group of devices can be triggered through multicast or broadcast messages transmitted from a reader to report of their identities. The command service utilizes a device ID to locate an A-IoT device (e.g., A-IoT device 60a) and deliver a command to the A-IoT device, after which the device executes the command requested by a reader. In this case, a contention-free random-access scheme is more suitable for Command service.

[0215] Another A-IoT use case is proximity determination, wherein a reader can determine whether an A-IoT device (e.g., A-IoT device 60a) is within its proximity during random access procedure. This feature is useful for a network to know proximity of a BS or an intermediate node acting as a reader to an A-IoT device (e.g., A-IoT device 60a) , thereby facilitating for A-IoT operations, even if the reader is portable. This feature allows the network to determine which BS or reader, including portable readers, is closest to the A-IoT device and available for communication.

[0216] For the purpose of clarity and consistency in describing the embodiments of the present invention, specific terminologies are adopted throughout this specification. These terms are defined to facilitate understanding of the technical features, system components, and operational methods disclosed herein, and they are used consistently unless otherwise indicated: 1. An A-IoT interface is a newly defined interface for applying A-IoT protocols of various layers in A-IoT  services, supporting communication between a network node and an A-IoT device (e.g., A-IoT device 60a) or between two A-IoT devices. 2. A physical channel carrying data or control information from a reader to an A-IoT device (e.g., A-IoT  device 60a) is defined as physical reader-to-device channel (PRDCH) . 3. A preamble preceding a PRDCH is defined as reader-to-device (R2D) preamble, and a postamble  attached to the end of PRDCH is defined as an R2D postamble. 4. Any signal transmitted from a reader to an A-IoT device (e.g., A-IoT device 60a) is defined as an R2D  signal. The R2D signal includes R2D preamble, PRDCH, and / or R2D postamble. The direction of transmitting an R2D signal is referred to as a R2D link. 5. A physical channel carrying data or control information from an A-IoT device (e.g., A-IoT device 60a)  to a reader is defined as physical device-to-reader channel (PDRCH) . 6. A preamble preceding a PDRCH is defined as a device-to-reader (D2R) preamble, and a postamble  attached to the end of PDRCH is defined as a D2R postamble. 7. Any signal transmitted from an A-IoT device (e.g., A-IoT device 60a) to a reader is defined as a D2R  signal. The D2R signal includes D2R preamble, PDRCH, and / or D2R postamble. The direction of transmitting D2R signal is referred to as a D2R link.

[0217] The description details random-access schemes, including transmissions of both R2D and D2R signal during a random-access procedure and interactive behavior between a network node (e.g., the network node 40) and an A-IoT device (e.g., A-IoT device 60a) . In the description, the network node can be a gNB (next-generation NodeB) , a UE, a relay node, an IAB, an A-IoT device (e.g., A-IoT device 60a) supporting part of existing 3GPP protocols, an intermediate node in Topology 2, an assisting node, or a 3GPP core network entity.

[0218] The deployment of Ambient Internet of Things (A-IoT) devices presents unique challenges in establishing efficient communication protocols within existing cellular networks. A-IoT devices are characterized by ultra-low power consumption and simplified hardware architectures, often relying on energy harvesting from ambient RF signals for operation. These devices require specialized random access procedures that accommodate their limited capabilities while ensuring reliable communication with network infrastructure.

[0219] Current random access mechanisms in cellular systems are not optimally designed for A-IoT applications. Several critical technical challenges exist in implementing effective random access schemes for A-IoT devices. First, network nodes must be able to indicate or configure random access resources for both contention-based and contention-free access methods, enabling A-IoT devices to determine appropriate slot occasions and frequency locations during random access procedures. This resource allocation becomes particularly complex given the diverse operational requirements of different A-IoT device types and application scenarios.

[0220] Second, as multiple random-access schemes may be defined to support various A-IoT application scenarios, there is a need for explicit or implicit methods that enable proper scheme selection. The selection mechanism must account for factors such as device capabilities, traffic types, and network conditions while maintaining simplicity to accommodate the limited processing capabilities of A-IoT devices.

[0221] Third, the generation and structuring of messages used in reader-to-device (R2D) and device-to-reader (D2R) transmissions during random access procedures require standardized methods. These methods must define the content of preambles and control information carried in each message to support essential functions including synchronization, contention resolution, device identification, and information requests.

[0222] Finally, addressing random access failures is particularly crucial for A-IoT applications due to the inherent limitations of A-IoT devices and their periodic unavailability during energy harvesting or charging periods. Unlike conventional IoT devices, A-IoT devices may become temporarily unreachable, requiring specialized failure recovery mechanisms that account for these operational constraints.

[0223] These challenges necessitate the development of comprehensive random access schemes specifically tailored for A-IoT communications, including detailed specifications for R2D and D2R signal transmissions and interactive behaviors between network nodes and A-IoT devices.

[0224] The present disclosure provides comprehensive solutions for A-IoT random access communications through several key technical contributions.

[0225] First, embodiments of the disclosure provide parameters, procedures, and schemes for indicating and configuring random access resources for both contention-based and contention-free random access procedures. These mechanisms enable network nodes to efficiently allocate and communicate resource assignments to A-IoT devices while accommodating their diverse operational requirements.

[0226] Second, embodiments of the disclosure provide parameters, procedures, and schemes for determining the appropriate random access scheme to be triggered by a network node (e.g., the network node 40) . These selection mechanisms consider factors such as device capabilities, application scenarios, and network conditions to optimize communication efficiency.

[0227] Third, embodiments of the disclosure define the utilized resources, message contents, and compositional structure of messages generated in each step of a random access procedure. This includes detailed specifications for R2D and D2R signal formats, preamble structures, and control information elements that support synchronization, contention resolution, and device identification functions.

[0228] Fourth, embodiments of the disclosure provide parameters, procedures, and schemes for addressing random access failure scenarios, specifically considering the potential unavailability of A-IoT devices during energy harvesting or charging periods. These failure recovery mechanisms ensure robust communication despite the intermittent nature of A-IoT device operations.

[0229] Embodiments of the disclosure provide significant technical and commercial advantages:

[0230] Massive Scale Deployment: The disclosed embodiments enable the deployment of tens or hundreds of billions of small-sized, low-complexity, and ultra-low power consumption A-IoT devices. This massive scalability drives the creation of new markets across diverse applications and scenarios, ultimately improving productivity and efficiency while enhancing quality of life through ubiquitous connectivity.

[0231] Enhanced Operational Efficiency: The disclosed A-IoT communication schemes realize typical A-IoT service use cases while simultaneously reducing maintenance costs and addressing environmental concerns. By enabling energy harvesting capabilities, A-IoT devices eliminate or significantly reduce the need for manual battery replacement or recharging, resulting in more sustainable and cost-effective IoT deployments.

[0232] Seamless Network Integration: The disclosed mechanisms ensure seamless coexistence with existing 3GPP networks by preventing severe interference and facilitating efficient interference management between A-IoT devices and conventional 3GPP devices. This compatibility preserves existing network performance while enabling new A-IoT functionalities.

[0233] In the following embodiments, the term "network node" encompasses any node defined within 3GPP network architectures or specified under Topology 1 or Topology 2 configurations, provided that such nodes support at least a subset of 3GPP protocols through wired or wireless connections. The network node can be a gNB (next-generation NodeB) , a UE, a relay node, an IAB, an A-IoT device (e.g., A-IoT device 60a) supporting part of existing 3GPP protocols, an intermediate node in Topology 2, an assisting node, or a 3GPP core network entity. The specific network node type depends on the deployed topology configuration. The network node can serve as a reader to initiate an inventory procedure and retrieve requested tag information from an A-IoT device (e.g., A-IoT device 60a) .

[0234] Direct Configuration (Topologies 1 and 2) : For Topologies 1 / 2, the network node can configure, via an A-IoT air interface, parameter settings associated with R2D signal transmission over R2D links, D2R signal transmission over D2R links, or carrier wave signal transmission from a network node (e.g., the network node 40) to an A-IoT device (e.g., A-IoT device 60a) or from a carrier wave source node to an A-IoT device (e.g., A-IoT device 60a) .

[0235] Intermediate Node Configuration (Topology 2) : For Topology 2, a base station (BS) (e.g., gNB) can forward information of parameter settings to an intermediate node through 3GPP interfaces, e.g., Uu interface. The information includes parameters for R2D signal transmission over R2D link, D2R signal transmission over D2R link, or carrier wave signal transmission from an intermediate node (e.g., UE) to an A-IoT device (e.g., A-IoT device 60a) or from a carrier wave source node to an A-IoT device (e.g., A-IoT device 60a) .

[0236] External Carrier Wave Source Coordination (Topologies 1 and 2) : For Topologies 1 / 2, a BS (e.g., gNB) or an intermediate node (e.g., UE) can exchange information of parameter settings with an external carrier wave source node via 3GPP or non-3GPP interfaces. The information includes configurations of an external carrier wave source node, such as activation of carrier wave signal transmission, carrier wave signal generation scheme for generating carrier wave signals, and / or carrier wave signal transmission scheme for transmitting carrier wave signals.

[0237] Random Access Scheme Configuration:

[0238] For a random-access scheme applied in Topologies 1 / 2, the telecommunication system supports 1-step, 2-step, 3-step, or 4-step random access procedures. A reader triggers an A-IoT application procedure or a random-access procedure using Msg0, where the reader can be any network node included in Topologies 1 / 2.

[0239] Msg0 triggered 4-step random access procedure:

[0240] In general, messages carried in Msg0 triggered 4-step random access procedures for A-IoT includes the following. The following embodiments will detail potential modifications to the information content and associated functions of each message. These modifications may include, but are not limited to the embodiments: · Msg0: Reader triggers a procedure with a trigger information for requesting triggered information  from A-IoT device (s) . · Msg1: A-IoT device sends an ID to the reader (e.g., a random ID generated by the A-IoT device) . · Msg2: Reader echoes the ID received in Msg1. · Msg3: A-IoT device sends Device ID of the A-IoT device and triggered information of the A-IoT  device requested by Reader. · Msg4: Reader responds to Msg 3.

[0241] Msg0 triggered 3-step random access procedure:

[0242] In general, messages carried in Msg0 triggered 3-step random access procedures for A-IoT includes the following. The following embodiments will detail potential modifications to the information content and associated functions of each message. These modifications may include, but are not limited to the embodiments: · Msg0: Reader triggers a procedure with a trigger information for requesting triggered information  from A-IoT device (s) . · Msg1: A-IoT device sends an ID to the reader (e.g., a random ID generated by the A-IoT device) . · Msg2: Reader echoes the ID received in Msg1. · Msg3: A-IoT device sends Device ID of the A-IoT device and triggered information of the A-IoT  device requested by Reader.

[0243] Msg0 triggered 2-step random access procedure:

[0244] In general, messages carried in Msg0 triggered 2-step random access procedures for A-IoT includes the following. The following embodiments will detail potential modifications to the information content and associated functions of each message. These modifications may include, but are not limited to the embodiments: · Msg0: Reader triggers a procedure with a trigger information for requesting triggered information  from A-IoT device (s) . · MsgA: A-IoT device sends Device ID of the A-IoT device and triggered information of the A-IoT  device requested by Reader. · MsgB: Reader responds to MsgA.

[0245] Msg0 triggered 1-step random access procedure:

[0246] In general, messages carried in Msg0 triggered 1-step random access procedures for A-IoT includes the following. The following embodiments will detail potential modifications to the information content and associated functions of each message. These modifications may include, but are not limited to the embodiments: · Msg0: Reader triggers a procedure with a trigger information for requesting triggered information  from A-IoT device (s) . · MsgA: A-IoT device sends Device ID of the A-IoT device and triggered information of the A-IoT  device requested by Reader.

[0247] Message Structure and Composition:

[0248] A message transmitted from a network node (e.g., the network node 40) to an A-IoT device (e.g., A-IoT device 60a) during a random-access procedure at least includes a R2D preamble, which may or may not be followed by a PRDCH.

[0249] Conversely, a message transmitted from an A-IoT device (e.g., A-IoT device 60a) to a network node (e.g., the network node 40) during a random-access procedure at least includes a D2R preamble, which may or may not be followed by a PDRCH.

[0250] FIG. 6 illustrates examples of Msg0 triggered 3-step and 4-step random access schemes, while FIG. 7 illustrates Msg0-triggered 1-step and 2-step random access schemes, respectively. In all configurations, one or more than one A-IoT device can be triggered to perform contention-based or contention-free random access according to trigger information carried in Msg0.

[0251] Msg0 is typically sent by the network node (reader) to trigger a random access procedure, requesting information from one or more A-IoT devices. It acts as an initial trigger for the A-IoT procedure.

[0252] Msg1 (PRACH Preamble) is transmitted by the A-IoT device to the network node. This message often contains a random ID generated by the A-IoT device, used for contention resolution in contention-based random access.

[0253] Msg2 (Random Access Response -RAR) is sent by the network node (reader) to the A-IoT device (s) in response to receiving Msg1. Msg2 echoes the ID received in Msg1, confirming successful reception and potentially granting resources for Msg3 transmission.

[0254] Msg3 is transmitted by the A-IoT device to the network node. This message typically carries the A-IoT device's Device ID and the triggered information requested by the reader in Msg0 or Msg2.

[0255] Msg4 is a response from the network node (reader) to the A-IoT device, often following Msg3. It can serve various purposes, such as responding to Msg3 (e.g., providing decoding results for Msg3 in PDRCH) , or even acting as a trigger for a next round of an A-IoT procedure.

[0256] MsgA is an alternative to Msg1, transmitted by the A-IoT device to the network node, specifically in 2-step random access. It combines the functions of Msg1 and Msg3 by sending the Device ID and triggered information directly.

[0257] MsgB is the network node's response to MsgA, sent from the network node (reader) to the A-IoT device. It functions similarly to Msg2 and Msg4 combined for the 2-step procedure.

[0258] Embodiment A: Trigger information

[0259] A network node (e.g., the network node 40) can provide trigger information to one or more than one A-IoT device to trigger D2R signal transmission from the one or more than one A-IoT device via an A-IoT interface. The trigger information can be carried in an R2D preamble or within a PRDCH that contains PHY layer A-IoT control information, a medium access control (MAC) control element (CE) , or a radio resource control (RRC) information element (IE) .

[0260] Embodiment A-1: Content and composition of trigger information transmitted by a network node.

[0261] Embodiment A-1-1: Trigger Information Format Types

[0262] The trigger information can be in the form of a message, signal, control or data information. For example, the trigger information includes but not limited to: · A Massage 0 (Msg0) , · A Message 2 (Msg2) , · A query signal for an A-IoT procedure, e.g., an inventory procedure, · A paging signal: For example, a paging signal for device wake-up and notification, · Scheduling control information for PRDCH or PDRCH resource allocation, · R2D preamble: Standalone preamble transmission, or · R2D preamble and PRDCH: Combined preamble and data channel transmission.

[0263] Embodiment A-1-2: Resource location or size used for transmitting trigger information from a network node to A-IoT devices.

[0264] Embodiment A-1-2 defines the methodology for determining resource location and size when transmitting trigger information from network nodes to A-IoT devices. This embodiment addresses three fundamental aspects of resource allocation that are critical for efficient A-IoT communication.

[0265] Frequency Location Specification:

[0266] The frequency location for trigger information transmission utilizes Physical Resource Blocks (PRBs) specifically defined for A-IoT applications within the NR FDD or TDD bands established by 3GPP standards. In many cases, the frequency location for trigger information may coincide with the frequency used for carrier wave (CW) signal transmission to optimize spectrum efficiency. For Topology 2 configurations, base stations maintain the capability to schedule frequency locations for intermediate nodes through standard 3GPP air interfaces, ensuring coordinated spectrum management across the network hierarchy.

[0267] Time and Frequency Determination Factors:

[0268] The selection of timing and frequency resources depends on several interconnected factors that reflect the unique operational characteristics of A-IoT devices. Device availability considerations are paramount, as A-IoT devices periodically become unavailable during energy harvesting or charging cycles, requiring the network to coordinate transmission timing to avoid these periods. Carrier wave signal availability represents another critical factor, particularly for backscattering devices (Device Types 1 and 2a) that require external carrier signals for transmission. The periodicity of trigger information transmission must be carefully managed, with adjustment capabilities based on previous round success rates and device availability patterns. Device type and capability variations necessitate different resource allocation strategies, as devices with varying frequency-shift capabilities and processing power require tailored resource assignments. Additionally, the distinction between initial triggering rounds and subsequent retry attempts may warrant different resource allocation approaches, including variations in access schemes, target device groups, and time window parameters.

[0269] Packet Size Optimization:

[0270] The packet size for trigger information is dynamically determined based on multiple operational parameters to ensure efficient spectrum utilization while meeting functional requirements. The specific command type carried within the trigger information directly influences packet size requirements, as different A-IoT procedures demand varying amounts of control information. The selected random access scheme (whether 1-step, 2-step, 3-step, or 4-step) affects the information density required in the trigger message. Traffic type and use case considerations, such as inventory management versus command delivery services, require different information payloads. Finally, the content type of control or data information, including whether the trigger involves contention-based or contention-free access mechanisms, determines the overall packet structure and size requirements.

[0271] A resource location or size used for transmitting trigger information can be at least one of the following:

[0272] Frequency location:

[0273] The frequency location for trigger information transmission is determined within a Physical Resource Block (PRB) that is either predefined for A-IoT applications or dynamically scheduled by a network node (e.g., the network node 40) . These PRBs operate within NR frequency-division duplex (FDD) or time-division duplex (TDD) frequency bands as specified in 3GPP standards.

[0274] To optimize spectrum efficiency, the frequency location used for transmitting trigger information may coincide with the frequency location designated for carrier wave (CW) signal transmission. This frequency alignment is particularly beneficial for backscattering operations where A-IoT devices rely on external carrier signals.

[0275] In Topology 2 configurations where an intermediate node functions as a reader, the base station retains scheduling authority and can assign frequency locations to the intermediate node through standard 3GPP air interfaces, ensuring coordinated spectrum management across the network hierarchy.

[0276] Time occasion or frequency location:

[0277] Time occasion or frequency location for trigger information transmission are determined based on at least one of several critical factors and operational conditions that account for the unique characteristics of A-IoT devices. The critical factors and operational conditions may comprise but not limited to: 1. IoT device availability; 2. Carrier wave signal availability; 3. Periodicity of trigger information transmission; 4. Device type or capability of A-IoT devices; and / or 5. Initial and additional round adaptations.

[0278] Some of the critical factors and operational conditions are illustrated in the following.

[0279] IoT device availability:

[0280] A primary consideration is the availability of A-IoT devices, which is constrained by their energy harvesting requirements. Network nodes implement intelligent scheduling to avoid transmitting trigger information during charging periods when target A-IoT devices are unavailable. To optimize communication windows, network nodes can coordinate with target A-IoT devices by sending notifications that instruct devices to remain active during potential trigger information transmission periods.

[0281] Notification and Coordination Schemes:

[0282] The notification can be indicated in trigger information according to at least one of the following indication schemes. The first approach uses time pattern notifications, where A-IoT devices track timing of the time pattern using either internal counters or by monitoring detected R2D preambles. In this scheme, A-IoT devices maintain an active state for brief periods during the ON duration of the time pattern. For periodic patterns, A-IoT devices keep alive whenever their internal counter reaches zero or when the number of detected R2D preambles reaches a predetermined threshold.

[0283] The second approach employs time window indications that specify periods during which future trigger events (i.e., trigger information transmission) may occur, prompting A-IoT devices to refrain from charging during these indicated time windows. The timing parameters (e.g., starting time or ending time) for these windows can be precisely defined using time offsets relative to specific message reception events, such as Msg0, Msg2, or Msg4 received during random access procedures. The duration of these time windows can either be fixed values predefined for specific random access procedures or dynamically indicated by the network node.

[0284] Carrier Wave Signal Availability:

[0285] The availability of carrier wave signals represents a critical factor for backscattering operations, particularly for Device Type 1 and 2a A-IoT devices that require external carrier wave signals to transmit backscattered signals carrying triggered information. Network nodes coordinate CW signal provision by transmitting trigger information followed by carrier wave signals, which can originate either from the same network node or from dedicated CW source nodes. When carrier wave signals are unavailable during random access procedures, network nodes may defer trigger information transmission to prevent communication failures for backscattering devices.

[0286] Periodicity of trigger information transmission:

[0287] For scenarios involving periodic trigger information transmission, the periodicity requires dynamic adjustment based on operational performance metrics. For example, the periodicity (e.g., transmission interval) can be modified according to random access failure probability and target device availability observed in previous communication rounds. Higher probabilities of channel access failure or device unavailability warrant shorter periodicity intervals to improve communication reliability. However, when implementing shorter periodicity, network nodes implement power-saving mechanisms by preventing redundant triggering of A-IoT devices that have already successfully accessed the channel and reported their triggered information. For example, for an A-IoT device (e.g., A-IoT device 60a) that has successfully accessed the channel and reported triggered information to a network node (e.g., the network node 40) , another round of triggering the same A-IoT device is prevented for the sake of power saving.

[0288] Device Type and Capability of A-IoT devices:

[0289] Different A-IoT device types and capabilities necessitate tailored resource allocation strategies for trigger information transmission and reception. Network nodes assign specific time and frequency resources based on target device types, ensuring optimal trigger information transmission and reception for each device type. The parameters governing slot occasion determination for triggered information transmission, particularly in slotted ALOHA channel access schemes, vary according to device types and priority levels of A-IoT devices. These variations include adjustments to time window sizes and the number of candidate slots available within each time window. Additionally, a frequency location for trigger information transmission can be associated with target device type or devices capability, with frequency-shift capable devices receiving more flexible frequency location options to optimize spectrum utilization.

[0290] Initial and Additional Round Adaptations

[0291] Resource allocation strategies differ between initial and subsequent triggering rounds to address collision scenarios and A-IoT device unavailability issues. A resource location or resource size for transmitting trigger information transmission can be different in different rounds of triggering procedures. These adaptations can involve multiple dimensional changes to improve communication success rates. For example, access scheme modifications may transition from contention-based random access in initial rounds to contention-free access in subsequent rounds, or from 4-step random access procedures to streamlined 2-step procedures. Target device scope (i.e., which A-IoT device (s) ) can shift from broadcast triggering in initial rounds to more focused unicast or groupcast triggering in additional rounds. Furthermore, slotted ALOHA time window parameters (e.g., window size) may be adjusted between rounds to optimize channel access probability and reduce collision rates.

[0292] Packet Size Determination for Trigger Information

[0293] The packet size of trigger information carried in the PRDCH is dynamically determined based on multiple operational parameters that reflect the specific communication requirements and context of each transmission. For example, a packet size of trigger information carried in PRDCH can be derived from at least one of the following: 1. A command type in trigger information. i、 The command type issued within the trigger information directly affects the required payload  size, as different A-IoT procedures demand varying amounts of control and configuration data. 2. A random access scheme being triggered in trigger information. i、 The random access scheme being triggered (whether 1-step, 2-step, 3-step, or 4-step)  influences the information density required in the initial trigger message. 3. A traffic type or usage type (or use case) of an A-IoT application requested in trigger information. i、 The traffic type or use case of the A-IoT application, such as inventory management versus command delivery services, determines the specific information elements that must be included. 4. A content type of control or data information carried in PRDCH. i、 The content type of control or data information carried in the PRDCH establishes the  fundamental structure and size requirements. The content type carried in PRDCH can refer to a type of information mentioned in Alternative 2 of Embodiment A-1-3. That is, the packet size depends on specific information carried in the trigger information, such as random access relevant information (e.g., contention-based or contention-free random access being initiated by a network node (e.g., the network node 40) ) . This content-dependent approach ensures that packet sizes are optimized for each specific communication scenario while maintaining the flexibility to support diverse A-IoT operational requirements.

[0294] Embodiment A-1-3: Composition of trigger information

[0295] The composition of trigger information can be implemented through two primary alternatives, each offering distinct advantages for different A-IoT communication scenarios.

[0296] Alternative 1: A single shot of an on-demand R2D preamble or a series of periodically transmitted R2D preamble.

[0297] This alternative utilizes either a single on-demand R2D preamble transmission or a series of periodically transmitted R2D preambles. Information carried in the preamble can be expressed in the form of various sequences, formats, or selectable resource location for preamble transmission, providing flexibility in how trigger information is encoded and transmitted. At least one of the following pieces of information can be carried in the R2D preamble.

[0298] Target Device Identity Information:

[0299] The R2D preamble can carry identity information of target A-IoT devices, e.g., a single triggered A-IoT device, a group of triggered A-IoT devices, or all reachable A-IoT devices. Specifically, the identity information specifies a communication mode of unicast (single device) , groupcast (device group) , or broadcast (all reachable devices) . For example, this is achieved through a preconfigured association between a preamble sequence and one or more target A-IoT devices. Optionally, this is achieved through a preconfigured association between a preamble sequence and unicast, groupcast, or broadcast triggering.

[0300] Additionally, the preamble can indicate one more than one target device type of A-IoT devices (i.e., Device 1, 2a, or 2b) . For example, this is achieved through a preconfigured association between a preamble format or preamble location and one or more A-IoT device types.

[0301] Timing Synchronization and Reference Management:

[0302] The preamble serves critical timing synchronization functions by establishing reference time points for scheduled PRDCH reception or scheduled PDRCH transmission.

[0303] A-IoT device utilizes internal counters for slot counting in slotted ALOHA channel access and scheduled timing operations based on reference time units or relative time offsets. The reference time unit corresponds to 3GPP-defined slots or basic time units used for resource scheduling, while relative time offsets are calculated relative to detected RR2D preamble timing.

[0304] Monitoring of a reference time unit:

[0305] For monitoring purposes, each detected preamble represents one count in terms of reference time units, allowing A-IoT devices to track elapsed time based on consecutive preamble detections. In slotted ALOHA implementations, A-IoT devices decrement their slot counter with each detected preamble and transmit triggered information when the counter reaches zero. Similarly, A-IoT devices decrement timing counters and initiate scheduled PRDCH reception or scheduled PDRCH transmission when counters reach zero.

[0306] Each preamble detected by an A-IoT device (e.g., A-IoT device 60a) from a sequence of adjacent preambles is counted as one reference time unit. The reference time unit represents the time interval between consecutive preambles. An A-IoT device (e.g., A-IoT device 60a) can determine the number of elapsed reference time units by counting the number of consecutive preambles detected.

[0307] For an example of slotted ALOHA, the A-IoT device decrements its slot counter by one each time a preamble is detected and transmits triggered information when the slot counter reaches zero. For an example of scheduled PDRCH transmission, the A-IoT device decrements its timing counter by one with each detected preamble and transmits the PDRCH when the timing counter reaches zero.

[0308] Chip Rate and Modulation Information:

[0309] The preamble may carry chip rate information for PRDCH reception or PDRCH transmission. Since PRDCH and PDRCH may employ different modulation schemes, their associated chip rates can differ accordingly. Depending on the modulation schemes adopted in PRDCH and PDRCH, a first chip rate can be derived from R2D preamble associated with PRDCH, and a second chip rate can be derived from the D2R preamble associated with PDRCH. Chip rate information can be derived directly from a R2D preamble or a D2R preamble. Alternatively, chip rate information can be derived through a two-step process where initial chip rate information comes from the preamble and supplementary information is carried in PRDCH control information.

[0310] In an embodiment, the first part of the chip rate information is derived from the preamble, while the second part of the chip rate information is carried in the control information of a PRDCH. An association between the first part of the chip rate information and the second part of the chip rate information can be created through a mapping, such as linking a preamble sequence to control information. The second part of chip rate information includes chip rate information associated with PRDCH and / or chip rate information associated with PDRCH. This approach utilizes preamble sequence to control information mapping to establish associations between different chip rate components.

[0311] A-IoT Procedure and Command Information:

[0312] A preamble can convey information relevant to an A-IoT procedure.

[0313] Information carried in a preamble can be categorized by resource location, sequences, or formats to convey specific A-IoT procedure information, such that an A-IoT device (e.g., A-IoT device 60a) can distinguish one of them during an A-IoT procedure. Different preamble types indicate various operational aspects: specific A-IoT procedures (such as inventory procedures) , initial versus additional procedure rounds, slot counting assistance for slotted ALOHA channel access, and communication targeting modes (unicast, groupcast, or broadcast) . For example, a type of preamble is used to indicate that a specific A-IoT procedure, e.g., an inventory procedure, has been initiated. A type of preamble is used to indicate whether the triggering is for initial round of an A-IoT procedure or an additional round of an A-IoT procedure. A type of preamble is used to assist slot counting in slotted ALOHA channel access during a round of A-IoT procedure.

[0314] A type of preamble is used to indicate whether the triggering targets an A-IoT device (e.g., A-IoT device 60a) (unicast) , a group of A-IoT devices (groupcast) , or all A-IoT devices in proximity (broadcast) . For example, a mapping between a type of preamble and ID (s) associated with one or more than one A-IoT device can be specified in the standard or indicated by a network node (e.g., the network node 40) .

[0315] A type of preamble may be used to indicate a command or a specific command type that has been issued in subsequent PRDCH. For example, a mapping between a type of preamble and a command type (e.g., inventory management (DO-DTT) or command request (DO) ) can be specified in the standard or indicated by a network node (e.g., the network node 40) .

[0316] Random Access Scheme Selection:

[0317] The preamble may provide explicit indication or implicit indication specifying a selected random access scheme through categorized preamble types that specify 1-step, 2-step, 3-step, or 4-step procedures, as well as contention-based versus contention-free access methods.

[0318] Information carried in a preamble can be categorized into various types in terms of selected resource location, sequences or formats, such that an A-IoT device (e.g., A-IoT device 60a) can distinguish one of them during a random-access procedure. For example, a type of preamble indicates whether 1-step, 2-step, 3-step, or 4-step random-access procedure is used.

[0319] A type of preamble indicates whether a contention-based or contention-free random-access scheme is used. The system may include default assumptions where 1-step random access implies contention-free schemes and 4-step random access implies contention-based schemes. For example, for the case of 1-step random access, A-IoT device assumes a contention-free random-access scheme. That is, for the case of 1-step random access, A-IoT device is configured to use a contention-free random-access scheme. Alternatively, for the case of 4-step random access, A-IoT device assumes a contention-based random-access scheme. Alternatively, for a unicast A-IoT procedure, A-IoT device assumes a contention-free random-access procedure, with additional information relevant to contention-free random access being provided as a message portion of trigger information.

[0320] Alternative 2: Combined R2D Preamble and PRDCH Information:

[0321] Alternative 2 illustrates a combination of the R2D preamble and control or data information carried in PRDCH, providing enhanced flexibility and information capacity compared to preamble-only approaches. The information content can be distributed between both components, with complete interchangeability between the R2D preamble and PRDCH data elements based on operational requirements.

[0322] In Alternative 2, content of information provided in the R2D preamble can be any information mentioned in Alternative 1 of this Embodiment. In Alternative 2, content of control or data information carried in PRDCH can be any information mentioned in Alternative 1 of this Embodiment. Additionally, information carried in R2D preamble of Alternative 1 or Alternative 2 can be any control or data information carried in PRDCH, as described in Alternative 2 of this Embodiment. That is, any information carried in the R2D preamble can also be carried in the control or data information of a PRDCH, and vice versa.

[0323] The content of control or data information carried in PRDCH may include at least one of the following parameters relevant to slotted ALOHA channel access. For example, the parameter can be used for an A-IoT device (e.g., A-IoT device 60a) to perform at least one of the following: 1. Determine a location or size of a timing window for slotted ALOHA channel access, such as a starting  slot of the time window and / or a number of slots within the time window. 2. Determine a randomly selected slot location within a timing window for slotted ALOHA channel access. 3. Determine an initial value of a slot counter for down-counting during slotted ALOHA channel access. 4. Determine a frequency location for performing slotted ALOHA channel access.

[0324] Random access scheme indication:

[0325] The content of control or data information carried in PRDCH includes at least one parameter for random access. For example, the parameter enables an A-IoT device (e.g., A-IoT device 60a) to explicitly or implicitly determine a random access procedure, such as 1-step, 2-step, 3-step, or 4-step random access. For example, an explicit indication specifying an adopted random-access scheme is carried in the control or data information. In examples of A-IoT device implicitly determining a random access procedure, the implicit indication may comprise an ID or a resource associated with the A-IoT device. An A-IoT device (e.g., A-IoT device 60a) can assume that 1-step or 2-step random access is applied if a dedicated ID associated with the A-IoT device has been carried in the control or data information or R2D preamble. An A-IoT device (e.g., A-IoT device 60a) can assume that 1-step or 2-step random access is applied if additional resources (e.g., for Msg1 / A transmission in PDRCH) has been granted in the control or data information by a network node (e.g., the network node 40) . An A-IoT device (e.g., A-IoT device 60a) can assume that 1-step or 2-step random access is applied if a resource used for transmitting Msg1 / A is granted in the control or data information.

[0326] For example, the parameter enables an A-IoT device (e.g., A-IoT device 60a) to explicitly or implicitly determine whether a contention-based random-access scheme or contention-free random-access scheme is used.

[0327] For example, an explicit indication specifying an adopted random-access scheme is carried in the control or data information. In examples of A-IoT device implicitly determining a random access procedure, the implicit indication may comprise an ID or a resource associated with the A-IoT device. An A-IoT device (e.g., A-IoT device 60a) can assume that contention-free random access is applied if a device ID or a dedicated ID associated with the A-IoT device has been carried in the control or data information. An A-IoT device (e.g., A-IoT device 60a) can assume that contention-based random access is applied if parameter used for determining a window for performing slotted ALOHA channel access is provided in the control or data information. An A-IoT device (e.g., A-IoT device 60a) can assume that contention-free random access is applied if a dedicated resource used for transmitting Msg1 / A is granted in the control or data information.

[0328] For an A-IoT device (e.g., A-IoT device 60a) , a default random access scheme (e.g., contention-based random access with 4-step procedure) can be specified in the standard or pre-configured by a network node (e.g., the network node 40) . Other random-access schemes can be applied if otherwise specially indicated in the trigger information, e.g., Msg. 1 / A.

[0329] Cast type or communication mode indication:

[0330] The content of control or data information carried in PRDCH may include at least one parameter relevant to a cast type, use case, or traffic type of an A-IoT application, such as inventory service or command service.

[0331] For example, the parameter enables A-IoT devices to determine whether the received triggering (i.e., trigger information) is intended for an A-IoT device (e.g., A-IoT device 60a) (unicast) , a group of A-IoT devices (groupcast) , or all A-IoT devices in proximity (broadcast) . To facilitate this, the control or data information includes an identity (ID) associated with one or more target A-IoT devices, enabling unicast, groupcast, or broadcast reporting of triggered information.

[0332] After determining a cast type, i.e., unicast, groupcast, or broadcast, the triggered A-IoT device (s) can assume a corresponding random-access scheme. For example, · Unicast or groupcast triggered A-IoT device can assume 1-step or 2-step random access. · Unicast or groupcast triggered A-IoT device can assume contention-free random access. · Broadcast or groupcast triggered A-IoT device can assume 3-step or 4-step random access.

[0333] For unicast or groupcast triggered A-IoT device, a network node (e.g., the network node 40) provides additional information in the control or data information regarding a 1-step or 2-step random access scheme. For unicast or groupcast triggered A-IoT device, a network node (e.g., the network node 40) provides additional information in the control or data information regarding a contention-free random access scheme.

[0334] For example, the parameter enables A-IoT devices to determine a use case, traffic type, or service type of an A-IoT application. For example, the parameter enables A-IoT devices to determine requested content of a corresponding use case, traffic type, or service type to be reported in triggered information. For example, the parameter enables A-IoT devices to determine a command type conveyed in the trigger information, e.g., whether it is a device-originated-device-terminated triggered (DO-DTT) command or device-terminated (DT) command.

[0335] The content of control or data information carried in PRDCH includes at least one parameter relevant to contention-free random access. For unicast or groupcast triggering, in addition to a specific ID associated with an A-IoT device (e.g., A-IoT device 60a) or a group of A-IoT devices, the network node provides to the triggered A-IoT device (s) at least one piece of additional control or data information relevant to contention-free random access. The Additional control or data information relevant to contention-free random access can comprise at least one of the following: 1. A specific sequence or format of the D2R preamble being transmitted in triggered information, e.g.,  Msg1 / A / 3. 2. A modulation and coding scheme (MCS) scheme of PDRCH being transmitted in triggered information  in, e.g., Msg1 / A / 3. 3. A time / frequency resource of demodulation reference signal (DM-RS) being transmitted in triggered  information, e.g., Msg1 / A / 3. 4. A scheduled time / frequency resource of the D2R preamble or PDRCH being transmitted in triggered  information, e.g., Msg1 / A / 3. For example, the scheduled time / frequency resource may comprise an exact slot occasion or a range of allowable slot occasions, an explicitly indicated frequency location (e.g., PRB index) , and an implicitly determined frequency location (e.g., same as the frequency location of received trigger information) . 5. Content of data or control information carried in PDRCH of triggered information, e.g., Msg1 / A / 3. 6. An indication specifying 1-step, 2-step, 3-step or 4-step random access. 7. A dedicated ID being transmitted in triggered information, e.g., Msg1 / A / 3.

[0336] Regarding dedicated time / frequency resources scheduled for contention-free devices, an A-IoT device (e.g., A-IoT device 60a) determines a location of contention-free resources based on at least one of the following device features: 1. A device ID of an A-IoT device (e.g., A-IoT device 60a) . 2. A device type of an A-IoT device (e.g., A-IoT device 60a) . 3. An aspect of device capability, e.g., frequency shift capability or counting capability.

[0337] Multiple access scheme:

[0338] The content of control or data information carried in PRDCH includes at least one parameter relevant to a multiple access scheme for triggered information transmission. For example, the parameter can explicitly indicate one or more than one multiple access scheme being adopted by an A-IoT device (e.g., A-IoT device 60a) to perform random access. The multiple access scheme includes TDMA, FDMA, or CDMA.

[0339] The parameter specifies a resource pool, a time window, or a range of slot occasions available for an A-IoT device (e.g., A-IoT device 60a) to choose from when performing random access. The resource pool includes sequences used by a D2R preamble or a set of time / frequency locations used for D2R preamble or PDRCH transmission.

[0340] The parameter provides a scheme or a parameter for an A-IoT device (e.g., A-IoT device 60a) to select a slot occasion or resource location for Msg1 / A / 3 transmission within a resource pool, a time window, or a range of slot occasions.

[0341] A network node (e.g., the network node 40) can indicate a sequence or preamble format of a D2R preamble, e.g., code division multiple access (CDMA) , or a time / frequency location associated with Msg1 / A / 3 transmission, e.g., time division multiple access (TDMA) or frequency division multiple access (FDMA) .

[0342] PRDCH / PDRCH resource scheduling:

[0343] The content of control or data information carried in PRDCH may include at least one parameter relevant to PRDCH / PDRCH resource scheduling. For example, the parameter can provide scheduling information relevant to dynamically or semi-statically scheduled PRDCH / PDRCH. The scheduling information includes at least one of the following: 1. Indication specifying a time / frequency location of scheduled PRDCH reception or PDRCH  transmission. 2. Indication specifying a modulation and coding scheme (MCS) for scheduled PRDCH reception or  PDRCH transmission. 3. Indication specifying an allowable time window for transmission of triggered information, including  D2R preamble and PDRCH. 4. Indication specifying a repetition number in case of repetitive PDRCH transmissions is scheduled.

[0344] Power control:

[0345] The parameter can provide one or more than one power control parameter to indicate transmit power level of the D2R preamble or PDRCH. The power control parameter is only applicable to the device type of Device 2a or 2b. That is, the target A-IoT devices to receive the power control parameter belongs to the device type of Device 2a or 2b. In this case, trigger information can include an ID associated with device type of Device 2a or 2b for targeting A-IoT devices of type Device 2a or 2b.

[0346] Semi-statically scheduled PDRCH:

[0347] For semi-statically scheduled PDRCH, an A-IoT device (e.g., A-IoT device 60a) periodically transmits triggered information. Additional parameters conveyed in the control or data information of PRDCH can include at least one of the following: 1. Periodicity of semi-statically scheduled PDRCH. i. Counting of periodicity of periodically transmitted triggered information can rely on a local  counter of an A-IoT device (e.g., A-IoT device 60a) . The counter is used to count: a. a number of reference time units (e.g., slots) or basic time unit used for resource scheduling. b. a number of detected R2D preambles. 2. Activation or deactivation of semi-statically scheduled PDRCH.

[0348] PDRCH reception:

[0349] The content of control or data information carried in PRDCH includes at least one parameter relevant to performance of PDRCH reception. For example, the parameter can be used for confirming that the network node has successfully received triggered information from an A-IoT device (e.g., A-IoT device 60a) , such as an ACK response.

[0350] For example, the parameter can be used for indicating that the network node does not successfully receive triggered information from an A-IoT device (e.g., A-IoT device 60a) . In this case, the network node can 1. Send a NACK to the A-IoT device in response to previously received triggered information. 2. Re-initiate an A-IoT procedure.

[0351] The re-initiated A-IoT procedure can target one or more dedicated A-IoT device with an associated ID.

[0352] Target destination node of the triggered information:

[0353] The content of control or data information carried in PRDCH includes at least one parameter to indicate a target destination node of the triggered information. The target destination node of the triggered information can be a network node different from the network node that sends the trigger information. An ID associated with the target destination node, i.e., a base station or a UE, can be carried in the triggered information.

[0354] CW signal:

[0355] The content of control or data information carried in PRDCH includes at least one parameter relevant to CW signal. The CW signal is used for an A-IoT device (e.g., A-IoT device 60a) of type Device 1 / 2a to perform backscattered transmission on triggered information. Backscattering is only applicable to device type of Device 1 / 2a. That is, target A-IoT devices to receive CW signal relevant parameter are those of the device type of Device 1 / 2a. In such cases, the trigger information can include an ID associated with the device type of Device 1 / 2a for targeting A-IoT devices of the device type of Device 1 / 2a. The parameter relevant to CW signal includes at least one of the following: 1. A source node of CW signal. 2. A resource location of CW signal. 3. A wave form of CW signal, e.g., single tone or multi-tone.

[0356] Embodiment A-2: Triggered Information Content and Composition

[0357] The embodiment illustrates content and composition of the triggered information sent by an A-IoT device (e.g., A-IoT device 60a) . The triggered information is transmitted by the A-IoT device in response to the received trigger information from the network node. This embodiment encompasses the various forms, resource allocation methods, and sizing considerations for A-IoT device responses.

[0358] Embodiment A-2-1: Triggered Information Format Types:

[0359] Triggered information can be transmitted in multiple formats to accommodate different communication scenarios and device capabilities. The triggered information can be a message, a signal, control or data information in the form of: 1. A Message 1 (Msg1) , 2. A Message 3 (Msg3) , 3. A Message A (MsgA) , 4. A feedback signal, e.g., HARQ-ACK, 5. A report of a feature of an A-IoT device (e.g., A-IoT device 60a) , 6. D2R preamble, or 7. D2R preamble and PDRCH.

[0360] The information may take the form of specific messages including Message 1 (Msg1) , Message 3 (Msg3) , or Message A (MsgA) , depending on the random access procedure being employed. Additionally, triggered information can be formatted as feedback signals such as HARQ-ACK responses, comprehensive reports of A-IoT device features and capabilities, standalone D2R preambles for basic signaling, or combined D2R preamble and PDRCH transmissions for more complex information exchange.

[0361] Embodiment A-2-2: Resource location and Size Determination

[0362] An A-IoT device (e.g., A-IoT device 60a) determine a resource location (frequency location and / or time location) or size used for transmitting triggered information.

[0363] Frequency Location Selection:

[0364] The frequency location of the triggered information can be determined by the A-IoT device based on at least one of the following information or schemes: 1. Explicit resource indication (e.g., a PRB) scheduled by a network node (e.g., the network node 40) in  the trigger information. 2. Implicitly determination based on a frequency location used for CW signal transmission. 3. Implicitly determination based on a frequency location used for the trigger information. 4. A-IoT device’s capability to perform frequency-shifting. 5. The device type of the A-IoT device. 6. The multiple access scheme indicated in the trigger information.

[0365] Time Location Selection:

[0366] A time location of the triggered information can be derived by the A-IoT device from at least one of the following information or schemes: 1. Explicit resource indication in case of scheduled PDRCH transmission or contention-free random  access. The time location can be an exact slot occasion or a range of slot occasions, scheduled by a network node (e.g., the network node 40) in the trigger information. 2. A time location or slot occasion. For contention-based random access, an A-IoT device (e.g., A-IoT  device 60a) can select a time location or slot occasion based on at least one of the following schemes. i. Randomly selection within a time window based on a slotted ALOHA channel access  scheme. ii. Selection based on a slot counter embedded in the A-IoT device. 3. A-IoT device’s capability to perform counting. 4. The device type of an A-IoT device (e.g., A-IoT device 60a) . 5. A priority level of an A-IoT device (e.g., A-IoT device 60a) . 6. The Multiple access scheme indicated in the trigger information.

[0367] Packet size:

[0368] The A-IoT device can determine a packet size of the triggered information carried in the PDRCH based on at least one of the following pieces of information: 1. A received command type, traffic type, or use case of an A-IoT application indicated in trigger  information. 2. A content type of control or data information carried in the PDRCH.

[0369] The content type of control or data information carried in PDRCH can refer to any information mentioned in Alternative 2 of Embodiment A-2-3. That is, the packet size depends on specific information carried in the triggered information. For example, the information includes random access relevant information, such as whether contention-based or contention-free random access is being performed by an A-IoT device (e.g., A-IoT device 60a) . For example, when triggered information contains random access relevant information specifying whether contention-based or contention-free access is being performed, the packet size must accommodate these specific parameters and associated control information.

[0370] Embodiment A-2-3: Composition of Triggered Information

[0371] The composition of triggered information can be implemented through two primary alternatives, each offering different levels of information capacity and flexibility for A-IoT device responses.

[0372] Alternative 1: A D2R preamble-Only Triggered Information.

[0373] This alternative utilizes a standalone D2R preamble to carry triggered information. Information carried in the preamble can be expressed in the form of various preamble sequences, various preamble formats, or selectable resource location of preamble. The D2R preamble serves multiple critical functions in the communication process. At least one type of the following information can be carried in the D2R preamble: 1. Time synchronization: The preamble can be adopted as a reference time point for a network node  (e.g., the network node 40) to receive PDRCH. 2. Chip rate information for determining a chip rate of associated PDRCH received at a network node  (e.g., the network node 40) . 3. Device feature relevant information for an A-IoT device (e.g., A-IoT device 60a) , such as  i. A dedicated ID or device ID associated with the A-IoT device. ii. Device type of the A-IoT device. iii. A capability of the A-IoT device. 4. Random-access relevant information, such as i. A random ID or temporary ID used for contention resolution. ii. A random access scheme adopted by the A-IoT device. iii. A random access message transmitted by the A-IoT device. 5. A-IoT procedure relevant information, including but not limited to: i. A type of A-IoT application carried in the triggered information. For example, the type of A- IoT application may include but not limited to a cast type or traffic type of the A-IoT application in the associated PDRCH. ii. A destination ID of a target network node for receiving triggered information carried in  PDRCH.

[0374] Alternative 2: combined D2R preamble and PDRCH information

[0375] The composition of triggered information can be implemented through a combination of the D2R preamble and control or data information carried in PDRCH.

[0376] The information provided by the D2R preamble can be any information indicated in Alternative 1.

[0377] The content of control or data information carried in PDRCH can be any information indicated in Alternative 1. Additionally, information carried in the D2R preamble of Alternative 1 or Alternative 2 can be any control or data information carried in PDRCH, as described in Alternative 2 of this Embodiment. That is, any information carried in the D2R preamble can also be carried in the control or data information of a PDRCH, and vice versa.

[0378] Random access:

[0379] The content of control or data information carried in PDRCH includes at least one parameter relevant to random access. For example, the parameter can be used for an A-IoT device (e.g., A-IoT device 60a) to indicate a random-access scheme adopted by the A-IoT device. For example, the random-access scheme indicated in the parameter may be at least one of: 1. A 1-step, 2-step, 3-step, or 4-step based random-access scheme; or 2. A contention-based random-access scheme or contention-free random-access scheme.

[0380] For example, for the case of 1-step or 2-step random access, contention-free random-access scheme can be assumed by the A-IoT device and associated network node.

[0381] For the case of 3-step or 4-step random access, contention-based random-access scheme can be assumed by the A-IoT device and associated network node.

[0382] Cast type:

[0383] The content of control or data information carried in PDRCH includes at least one parameter relevant to cast type, use case, or traffic type of an A-IoT application (e.g., inventory service or command service) . For example, the parameter can be used for indicating the information carried in PDRCH is in response to a type of trigger information. The type of trigger information can be a cast type, use case, command type, or traffic type of an A-IoT application.

[0384] For example, the parameter can be used for providing a higher layer message requested by trigger information, such as a value in the tag (i.e., the A-IoT device) during an inventory procedure.

[0385] Device feature:

[0386] The content of control or data information carried in PDRCH includes at least one parameter relevant to a device feature. For example, the device feature can be: 1. An ID, a temporary ID or a dedicated ID, the ID can be used for device identity or contention resolution  during a random-access procedure. 2. A device type of an A-IoT device (e.g., A-IoT device 60a) , such as Device 1, 2a, or 2b. 3. A capability of an A-IoT device (e.g., A-IoT device 60a) .

[0387] For example, capabilities of an A-IoT device may comprise at least one of the following: 1. Ability to perform counting with a counter. 2. Ability to perform frequency shift for D2R signal transmission. 3. Ability to perform charging and R2D signal reception at the same time. 4. Ability to receive single tone CW or multi-tone CW. 5. Ability to perform data encryption / decryption. 6. Ability to perform repetitive PDRCH transmission. 7. Supported charging rate of energy harvesting in battery. 8. Supported bandwidth size or maximum bandwidth size. 9. Supported modulation scheme of PDRCH transmission. 10. Supported capacitance in the capacitor. 11. Supported use cases of A-IoT applications. 12. Supported message size of PDRCH transmission.

[0388] A-IoT procedure:

[0389] The content of control or data information carried in PDRCH includes at least one parameter relevant to an A-IoT procedure. 1. Redundancy indication:

[0390] For example, the parameter may include indication whether the A-IoT device has been triggered in previous round of an A-IoT procedure.

[0391] An indication can be sent to a network node (e.g., the network node 40) , showing that the A-IoT device has been triggered or triggered information has been successfully received by the network node. With such indication, the network node can avoid double triggering the same A-IoT device. In addition, the A-IoT device can save power from monitoring preamble or unnecessary PDRCH transmission.

[0392] Alternatively, the A-IoT device can refrain from transmitting triggered information to a network node (e.g., the network node 40) if i. the A-IoT device has been triggered in previous round of an inventory procedure; or  ii. the A-IoT has received information from the network node that triggered information has been  successfully received by the network node. 2. Power status indication:

[0393] For example, the parameter may include an indication specifying remaining power or remaining time available for the A-IoT device to keep alive. For example, during alive time, the A-IoT device can perform at least one of the following operations : i. Monitoring trigger information. ii. Transmitting triggered information. 3. Device availability indication:

[0394] For example, the parameter may include indication availability of an A-IoT device (e.g., A-IoT device 60a) due to charging. For example, the parameter may indicate: i. Availability of the A-IoT device in the next round of an inventory procedure. ii. Amount of time slots the A-IoT device will be unavailable due to charging. iii. A time zone or a starting slot the A-IoT device will be unavailable due to charging. 4. Time indication:

[0395] For example, the parameter may include indication specifying a timestamp showing the transmission time of the triggered information.

[0396] PRDCH reception:

[0397] The content of control or data information carried in PDRCH includes at least one parameter relevant to performance of PRDCH reception. For example, the parameter can be used for indicating HARQ-ACK in response to received trigger information or scheduled PRDCH.

[0398] CW wave reception:

[0399] The content of control or data information carried in PDRCH includes at least one parameter relevant to performance of CW wave reception. For example, the parameter can be used for indicating received power of a CW wave signal.

[0400] Embodiment A-3: Transmission Conditions for Triggered Information

[0401] A-IoT devices must satisfy specific conditions before transmitting triggered information in response to received trigger information from network nodes. These conditions may ensure proper communication protocol adherence, resource management, and energy efficiency while accommodating the unique operational constraints of A-IoT devices. Conditions for an A-IoT device to transmit triggered information in response to received trigger information may include at least one of the following: 1. The trigger information transmitted by a network node (e.g., the network node 40) has been  successfully received by the A-IoT device. 2. The target device ID, requested by a network node (e.g., the network node 40) , for transmitting  triggered information is associated with the A-IoT device. 3. The target device type, requested by a network node (e.g., the network node 40) , for transmitting  triggered information is associated with the A-IoT device. 4. The capability of the A-IoT device conforms to an operating requirement for an A-IoT procedure. 5. The slot counter for slotted ALOHA channel access reaches zero. 6. A slot location for transmitting triggered information falls within a time window indicated by a network  node (e.g., the network node 40) . 7. The A-IoT device is not in a charging or energy harvesting period. 8. The A-IoT device possesses sufficient energy to perform backscattered transmission or active  transmission. 9. A carrier wave signal is present during the transmission of a triggered D2R signal, particularly if the  type of the A-IoT device is Device 1 / 2a.

[0402] Embodiment B:

[0403] For the case of 1-step, 2-step, 3-step, or 4-step random access, associated messages of corresponding random-access schemes can be generated and constituted according to schemes described in the following embodiments:

[0404] Embodiment B-1: Generation and composition of Msg 1 / A:

[0405] This section details the methods for generating and composing Msg1 / A, which is a crucial initial message transmitted by an A-IoT device (e.g., A-IoT device 60a) during a random access procedure. Msg1 / A plays a vital role in enabling the A-IoT device to initiate communication and provide its identification. The following sub-embodiments outline various aspects related to the identification (ID) carried within the D2R preamble of Msg1 / A, as well as the overall information content.

[0406] Embodiment B-1-1: ID in the D2R preamble associated with Msg1 / A.

[0407] The ID carried in the D2R preamble associated with Msg1 / A can be at least one of the following types: 1. The ID is a random ID, or a temporary ID generated by an A-IoT device (e.g., A-IoT device 60a) . For  example, the ID can be used for contention resolution for contention-based random access. 2. The ID is a dedicated ID provided by a network node (e.g., the network node 40) or a device-specific  ID associated with a device ID of an A-IoT device (e.g., A-IoT device 60a) . For example, the ID can be used for: i. Identification of an A-IoT device or a group of A-IoT devices for an inventory procedure. ii. Identification of an A-IoT device or a group of A-IoT devices for performing contention-free  random access. 3. The ID is a dedicated ID which can be derived from a device feature (e.g., device ID or device type of  an A-IoT device) . In this case, a mapping between a dedicated ID and a device ID or device type of an A-IoT device (e.g., A-IoT device 60a) can be defined in the standard or preconfigured by a network node (e.g., the network node 40) .

[0408] A numerical value of each ID, i.e., ID number, can be categorized according to at least one of the following A-IoT device features. A method for categorizing the IDs can be specified in the standard or preconfigured by a network node (e.g., the network node 40) . The A-IoT device features may comprise a device type, device capability, or a random-access scheme.

[0409] Device type:

[0410] The device type of an A-IoT device can be Device 1, 2a / 2b. More than one value range or group of ID numbers can be preconfigured according to different device types. ID numbers can be partitioned into several groups, with each group corresponding to a specific device type. A network node (e.g., the network node 40) can distinguish device type via received ID from a specific ID group.

[0411] Device capability:

[0412] Device capabilities may comprise the listed capabilities in Embodiment A-2-3. An aspect of device capability of an A-IoT device (e.g., A-IoT device 60a) can be one of them. For example, ID numbers can be partitioned into several groups, with each group corresponding to one of the following device capabilities. 1. Presence or absence of frequency shift capability for backscattered D2R transmission. 2. Presence or absence of an internal counter for slot counting in slotted ALOHA channel access or  timing counting for scheduled D2R transmission. 3. Presence or absence of data encryption / decryption capability. 4. Others

[0413] A network node (e.g., the network node 40) can distinguish an aspect of device capability via received ID from a specific ID group.

[0414] Random-access scheme:

[0415] A numerical value of each ID, i.e., ID number, can be categorized according to a random-access scheme adopted by an A-IoT device (e.g., A-IoT device 60a) . For example, ID numbers can be partitioned into several groups, with each group corresponding to one of the following random-access schemes.  1. 1-step, 2-step, 3-step, or 4-step based random-access. 2. A contention-based random-access scheme or contention-free random-access.

[0416] A network node (e.g., the network node 40) can distinguish a random-access scheme adopted by an A-IoT device (e.g., A-IoT device 60a) via received ID from a specific ID group. For example, different A-IoT devices can perform different kinds of random-access scheme as indicated by the network node.

[0417] The ID can be derived from at least one feature or parameter related to an A-IoT device (e.g., A-IoT device 60a) .

[0418] Alternative 1: The ID is derived according to the device ID of an A-IoT device (e.g., A-IoT device 60a) . Examples of the ID deriving according to the device ID of the A-IoT device is given in the following. 1. The ID is the same as device ID of the A-IoT device. This may apply in the case of contention-free  random access. 2. The ID is derived from a device ID, and the ID has different bit length than the device ID. For example,  i. The ID has a shorter bit length, truncated from the device ID. ii. The ID is derived from a device ID after applying a certain function on the device ID. The final  bit length can be longer than, shorter than, or the same as the device ID after applying the certain function on the device ID. For example, the function can be: a. A data encryption function, e.g., with an authentication key involved. b. A data compression function, e.g., with a compression factor involved. 3. The ID can be derived from a device ID and / or at least one of the following parameters. i. A frequency / time domain information of a slot location used for Msg1 / A transmission. For  example, the slot location can be: a. An index of a slot location selected by the A-IoT device within a time window in slotted  ALOHA channel access; or b. An index of a channel / tone location used by the A-IoT device for Msg1 / A transmission. ii. A device type of an A-IoT device (e.g., A-IoT device 60a) . iii. A command type, traffic type, or use case of an A-IoT application received from the trigger  information. iv. A random access scheme, such as a. 1-step, 2-step, 3-step, or 4-step random access. b. A contention based or contention-free channel access. v. A parameter relevant to data encryption or decryption, e.g., with an authentication key involved.

[0419] Alternative 2: The ID is derived from the device type of an A-IoT device (e.g., A-IoT device 60a) . Examples of the ID deriving according to the device type of the A-IoT device is given in the following. 1. A mapping function between an ID and a device type is created. For example, a one-to-many mapping  between a device type and corresponding ID numbers can be preconfigured in advance. The ID is derived from the device type of the A-IoT device based on the mapping. 2. The ID is generated based on a device type of the A-IoT device and / or at least one of the following  parameters. i. Frequency / time domain information of a slot location used for Msg1 / A transmission, such as a. An index of a slot location selected by the A-IoT device within a time window in slotted  ALOHA channel access; or b. An index of a channel / tone location used by the A-IoT device for Msg1 / A transmission. ii. A command type, traffic type, or use case of an A-IoT application received from the trigger  information. iii. A random access scheme, such as a. A 1-step, 2-step, 3-step, or 4-step random access. b. A contention based or contention-free channel access. iv. A parameter relevant to data encryption or decryption, e.g., with an authentication key involved. 3. A bit length of an ID transmitted by an A-IoT device (e.g., A-IoT device 60a) can be determined based  on at least one of the following schemes: i. A fixed bit length. For example, a. The total bit length is an integer multiple of 16, e.g., 16 bits, 32 bits, etc. b. The bit length includes a fixed length of additional bits being added to bits of an ID  associated with the A-IoT device or an ID associated with a random-access attempt. The additional bits can be used for data encryption or decryption and / or cyclic redundancy check (CRC) check. c. The overall bit length is fixed after adding the additional bits. ii. The bit length depends on at least one of the following: a. A device type of an A-IoT device (e.g., A-IoT device 60a) . b. A command type, traffic type, or use case of an A-IoT application received from the trigger  information. c. A random access scheme, such as · 1-step, 2-step, 3-step, or 4-step random access; or · Contention based or contention-free channel access. d. Activation or deactivation of a data encryption function.

[0420] Embodiment B-1-2: Information generated by an A-IoT device and transmitted on Msg1 / A.

[0421] The content of information carried in Msg1 / A can be any information indicated in Embodiment B-1-1. That is, any information carried in the R2D preamble associated with Msg1 / A can be carried in a message part of Msg1 / A as well, and vice versa. For example, the information carried in Msg1 / A can be an ID with the following features as described in Embodiment B-1-1: 1. A constitution scheme of an ID. 2. An ID categorization scheme. 3. An ID generation scheme. 4. An ID length determination scheme.

[0422] The content of information carried in Msg1 / A can be any information described in Embodiment A-2-3 regarding triggered information. That is, any content of the triggered information mentioned in Embodiment A-2-3 can be in the form of information carried in Msg1 / A as well. For example, the information carried in Msg1 / A can be: 1. Device feature relevant information associated with an A-IoT device (e.g., A-IoT device 60a) , such as  i. A device identity. ii. A device type. iii. A device capability of the A-IoT device. iv. A channel access priority. v. A traffic type or use case. 2. Random-access relevant information. 3. A-IoT procedure relevant information. 4. A-IoT application relevant information. 5. Receiving performance relevant information, such as a detection result of received Msg0 in PRDCH.

[0423] For the case of device-terminated (DT) command, where an A-IoT device (e.g., A-IoT device 60a) receives a command from a network node (e.g., the network node 40) without being triggered to transmit any information, the A-IoT device may report HARQ-ACK in response to received Msg0 in PRDCH. 1. Triggered information requested in Msg0:

[0424] The content of information carried in Msg1 / A can include triggered information requested in Msg0. If the triggered information is carried in Msg1 / A, then a contention-free random-access or 1 / 2-step random access scheme is applied by the A-IoT device. 2. Reception performance of Msg0:

[0425] The content of information carried in Msg1 / A can include reception performance of Msg0. For example, an A-IoT device reports HARQ-ACK in Msg1 in response to received Msg0 in PRDCH. For the case of device-terminated (DT) command, where an A-IoT device (e.g., A-IoT device 60a) receives a command from a network node (e.g., the network node 40) in Msg0 without being triggered to transmit any information, the A-IoT device can response to network node a decoding result of the received command.

[0426] Embodiment B-1-3: Resource location or size associated with Msg1 / A.

[0427] Refer to Embodiment A-2-2 regarding resource location or size used for transmitting triggered information and Embodiment A-2-3 regarding information carried in the triggered information. The resource location or information associated with Msg1 / A can be implemented as the resource location or information associated with triggered information mentioned in Embodiment A-2-2 and Embodiment A-2-3. In this case, triggered information is carried in Msg1 / A.

[0428] Embodiment B-2: Generation and composition of Msg 2 / B:

[0429] This section describes the generation and composition of Msg2 / B, which serves as a response from the network node to the A-IoT device during the random access procedure. Msg2 / B is crucial for acknowledging the A-IoT device's initial transmission and for providing further instructions or resource grants. The following sub-embodiments detail the characteristics of the R2D preamble associated with Msg2, as well as the content it carries.

[0430] Embodiment B-2-1: R2D Preamble Generation for Msg2

[0431] The R2D preamble associated with Msg2 can be generated according to at least one of the following schemes:

[0432] A resource location of the R2D preamble or information carried in R2D preamble associated with trigger information, as mentioned in Embodiment A-1-2 and A-1-3, can also be applied for the R2D preamble associated with Msg2 as well.

[0433] Any function of the R2D preamble associated with trigger information carried in Msg0, as mentioned in Embodiment A-1-3, can be applied to the R2D preamble associated with Msg2.

[0434] A frequency domain resource of the R2D preamble associated with Msg2 can be the same as or different from a frequency domain resource of the R2D preamble associated with Msg0.

[0435] The generation of the R2D preamble associated with Msg2 can be based on one of the following alternatives : 1. Alternative 1:

[0436] The R2D preamble associated with Msg2 can be distinguishable from the R2D preamble associated with Msg0 in terms of at least one of the following: i. A sequence or format adopted by a R2D preamble. ii. A time / frequency location of a R2D preamble.

[0437] An A-IoT device (e.g., A-IoT device 60a) can identify a message type of a message (e.g., Msg0 or Msg2) being received according to the received sequence, format, or time / frequency location of associated R2D preamble. 2. Alternative 2:

[0438] A sequence, format, or time / frequency location of the R2D preamble associated with Msg2 is the same as or related to the sequence, format, or time / frequency location of the D2R preamble associated with Msg1.

[0439] In this case, a link, mapping, or relationship between the R2D preamble associated with Msg2 and the D2R preamble associated with Msg1 during a random-access procedure can be defined in the standard or preconfigured by a network node (e.g., the network node 40) . 3. Alternative 3:

[0440] A sequence, format, or time / frequency location of the R2D preamble associated with Msg2 can be the same as or related to the sequence, format, or time / frequency location of the R2D preamble associated with Msg0.

[0441] In this case, a link, mapping, or relationship between the R2D preamble associated with Msg2 and the R2D preamble associated with Msg0 during a Msg0 triggered random access procedure can be defined in the standard or preconfigured by a network node (e.g., the network node 40) .

[0442] Embodiment B-2-2: Content of Information in Msg2 / B

[0443] The content of information carried in Msg2 / B includes at least one of the following: 1. Confirmation that an ID transmitted in Msg1 / A from an A-IoT device (e.g., A-IoT device 60a) has been  successfully received; 2. A grant of Msg3 resource associated with at least one A-IoT device; 3. Indication specifying a sequence or format of the D2R preamble being adopted for associated Msg3  transmission; 4. Indication specifying a higher layer message being carried in Msg3; and 5. Reception performance of Msg1 / A.

[0444] The content of information carried in Msg2 / B is detailed in the following.

[0445] 1. Confirmation of an ID transmitted in Msg1 / A from an A-IoT device (e.g., A-IoT device 60a) has been  successfully received.

[0446] An identical ID received in Msg1 / A may be transmitted in Msg2 / B associated with the A-IoT device. The A-IoT device can re-transmit Msg1 / A if Msg2 / B cannot be received by the A-IoT device. The A-IoT device can re-transmit Msg1 / A if an identical ID associated with the A-IoT device cannot be detected in Msg2 / B by the A-IoT device. The identical ID transmitted in Msg2 / B can be an ID used for contention resolution or for identification of an A-IoT device (e.g., A-IoT device 60a) . 2. A grant of Msg3 resource associated with at least one A-IoT device.

[0447] A time / frequency resource used for Msg3 transmission can be scheduled in Msg2. Alternatively, a frequency location of Msg3 can be assumed to be the same as Msg1 transmitted by an A-IoT device (e.g., A-IoT device 60a) . A slot location for Msg3 transmission can be defined using an offset relative to the slot location of Msg2. The offset value can be an exact value or a range of offset values with an upper or lower limit. The offset value can be indicated in Msg2 or defined in the standard.

[0448] A slot location of Msg3 transmission can be determined based on availability of a R2D signal detected at an A-IoT device (e.g., A-IoT device 60a) .

[0449] For example, the slot location of Msg3 transmission can be determined by an A-IoT device (e.g., A-IoT device 60a) using information regarding triggering of Msg3 transmission carried in R2D preamble or PRDCH of a R2D signal detected by the A-IoT device. 3. Indication specifying a sequence or format of the D2R preamble being adopted for associated Msg3  transmission.

[0450] For example, a dedicated ID carried in the D2R preamble or PDRCH associated with Msg3 is indicated by a network node (e.g., the network node 40) in Msg2.

[0451] Alternatively, the information carried in the D2R preamble associated with Msg3 is determined by an A-IoT device (e.g., A-IoT device 60a) . The information carried in the D2R preamble associated with Msg1 mentioned in Embodiment B-1 can be applied for the case of Msg3 transmission. 4. Indication specifying a higher layer message being carried in Msg3.

[0452] For example, if the trigger information is carried in Msg2, then it can request triggered information that is to be transmitted in Msg3. That is, Msg2 can act as a triggering message (e.g., with a command of DO-DTT) similar to the role of Msg0 described in Embodiment A-1.

[0453] The target A-IoT device for reporting the triggered information indicated in Msg2 can be one of the following i. An A-IoT device (e.g., A-IoT device 60a) associated with a unicast ID or groupcast ID, which is  determined by the network node. ii. An A-IoT device (e.g., A-IoT device 60a) with an associated ID transmitted in Msg1 detected by  the network node. 5. Reception performance of Msg1 / A.

[0454] For the case of device-originated-device-terminated triggered (DO-DTT) command, where an A-IoT device (e.g., A-IoT device 60a) receives a trigger command (i.e., the trigger information) from a network node (e.g., the network node 40) and transmits requested triggered information in Msg1 / A, the following applies.

[0455] In this case, the network node provides, in Msg 2 / B, information relevant to decoding results of Msg1 / A in response to received Msg1 / A in PDRCH.

[0456] The A-IoT device can re-transmits Msg1 / A if the A-IoT device does not detect Msg2 / B or the A-IoT device receives Msg2 / B with negative-acknowledged (NACKed) Msg1 / A indication.

[0457] Embodiment B-2-3: Skipping 1-Step Random Access or Msg2 / B of 2-Step Random Access

[0458] An 1-step random-access scheme or Msg2 / B of 2-step random access scheme can be absent or skipped (e.g., by falling back to 1-step random) if one of the following conditions is satisfied: 1. An 1-step random-access scheme is indicated or activated. 2. The network node has successfully received triggered information in Msg1 / A. 3. The network node does not successfully receive triggered information in Msg1 / A.

[0459] The conditions are detailed in the following. 1. An 1-step random-access scheme is indicated or activated.

[0460] The 1-step random-access procedure can be predefined in the standard or indicated by a network node (e.g., the network node 40) through Msg0. For 1-step random-access, at least one of the following related operations is accompanied. i. If the trigger information in Msg0 is not correctly received by a target A-IoT device or Msg1  transmitted from a triggered A-IoT device is not correctly received by a network node (e.g., the network node 40) , another triggering (i.e., the trigger information) in Msg0 can be issued by the network node. ii. A contention-free channel access scheme is applied in 1-step random-access. iii. A dedicated unicast or groupcast ID for requesting triggered information is provided in Msg0. iv. A sequence or format of the D2R preamble associated with Msg1, or a time / frequency resource  used for Msg1 transmission is provided in Msg0. 2. The network node has successfully received triggered information in Msg1 / A.

[0461] In this case, an A-IoT device (e.g., A-IoT device 60a) assumes transmitted Msg1 / A is positive-acknowledged (ACKed) if the A-IoT device does not receive a Msg2 / B associated with the A-IoT device within a time window.

[0462] Msg1 / A can be re-transmitted by the A-IoT device if the A-IoT device receives Msg2 / B with negative-acknowledged (NACKed) Msg1 / A indication.

[0463] The time window used for receiving Msg2 / B can be predefined in the standard or preconfigured by the network node. 3. The network node does not successfully receive triggered information in Msg1 / A.

[0464] In this case, an A-IoT device (e.g., A-IoT device 60a) assumes transmitted Msg1 / A is negative-acknowledged (NACKed) if the A-IoT device does not receive a Msg2 / B associated with the A-IoT device within a time window.

[0465] Msg1 / A can be re-transmitted by the A-IoT device if the A-IoT device does not receive Msg2 / B associated with the A-IoT device.

[0466] Embodiment B-2-4: Determining Msg2 / B Resource location and Size

[0467] The resource location or size associated with Msg2 / B can be determined based on at least one of the following.

[0468] A frequency location of the PRDCH associated with Msg2 / B may be consistent with the frequency location of the R2D preamble associated with Msg2 / B as mentioned in Embodiment B-2-1.

[0469] A packet size of information carried in the PRDCH associated with Msg2 / B can be derived from at least one of the following: 1. A command type issued in the trigger information. 2. A traffic type or use case of an A-IoT application requested in the trigger information. 3. A content type of control or data information carried in the PRDCH.

[0470] The content type carried in the PRDCH can be implemented as any information mentioned in Embodiment B-2-2. That is, the packet size depends on specific information carried in Msg2 / B. For example, the packet size depends on whether a contention-based or contention-free random access being initiated by a network node (e.g., the network node 40) .

[0471] Embodiment B-3: Generation and composition of Msg3:

[0472] This section details the methods for generating and composing Msg3 within the random access procedure. Msg3 plays a crucial role in conveying information from the A-IoT device back to the network node. The following sub-embodiments outline specific aspects of Msg3 generation, focusing initially on the D2R preamble.

[0473] Embodiment B-3-1: D2R Preamble Generation for Msg3

[0474] The D2R preamble associated with Msg3 can be generated according to at least one of the following schemes:

[0475] The resource location or information carried in the D2R preamble associated with Msg3 is indicated in Msg2.

[0476] The resource location or information carried in the D2R preamble associated with Msg3 can be implemented as the resource location or information carried in the D2R preamble associated with triggered information carried in Msg1 as mentioned in Embodiment A-2-2 and A-2-3. That is, description regarding the resource location or information carried in the D2R preamble associated with Msg1 can be applied for the D2R preamble associated with Msg3 as well.

[0477] Any purposes or functions of the D2R preamble associated with triggered information carried in Msg1 mentioned in Embodiment A-2-3 can also be applied to the case of the D2R preamble associated with Msg3.

[0478] The frequency domain resource of the D2R preamble associated with Msg3 can be the same as or different from the frequency domain resource of the D2R preamble associated with Msg1.

[0479] Generation of the D2R preamble associated with Msg3 can be performed based on one of the following alternatives : 1. Alternative 1:

[0480] The D2R preamble associated with Msg3 is distinguishable from the D2R preamble associated with Msg1 in terms of at least one of the following: i. A sequence or format adopted by a D2R preamble. ii. A time / frequency location of a D2R preamble.

[0481] A network node (e.g., the network node 40) can identify a message type being received according to the received sequence, format, or time / frequency location of associated D2R preamble. 2. Alternative 2:

[0482] The sequence, format, or time / frequency location of the D2R preamble associated with Msg3 is the same as or related to the sequence, format, or time / frequency location of the R2D preamble associated with Msg2.

[0483] In this scenario, a link, mapping, or relationship between D2R preamble associated with Msg3 and the R2D preamble associated with Msg2 during a random-access procedure can be defined in the standard or preconfigured by a network node (e.g., the network node 40) . 3. Alternative 3:

[0484] A sequence, format, or time / frequency location of the D2R preamble associated with Msg3 is the same as or related to the sequence, format, or time / frequency location of the D2R preamble associated with Msg1.

[0485] In this case, a link, mapping, or relationship between D2R preamble associated with Msg3 and the D2R preamble associated with Msg1 during a random-access procedure can be defined in the standard or preconfigured by a network node (e.g., the network node 40) . 4. Alternative 4:

[0486] The sequence, format, or time / frequency location of the D2R preamble associated with Msg3 can be indicated in Msg2.

[0487] Embodiment B-3-2: Content of Information in Msg:

[0488] The content of information carried in Msg3 can include any information mentioned in Embodiment B-1-2 for being carried in Msg1 can also be carried in Msg3. For example, Msg3 information may comprise:  1. A dedicated ID: The dedicated ID may be derived from a device ID of a A-IoT device, where the A-IoT  device has successfully received an echoed contention resolution ID in Msg2. Alternatively, the dedicated ID may be an ID provided in Msg2 by a network node (e.g., the network node 40) . 2. Triggered information requested by a network node (e.g., the network node 40) : A triggering message  to request the triggered information can be Msg0 or Msg2 sent by a network node (e.g., the network node 40) .

[0489] Reception performance of Msg2:

[0490] Additionally, the content of information carried in Msg3 can include reception performance of Msg2. Specifically, an A-IoT device (e.g., A-IoT device 60a) reports HARQ-ACK in Msg3 in response to received Msg2 in PRDCH. For example, for device-terminated (DT) commands, where an A-IoT device (e.g., A-IoT device 60a) receives a command from a network node (e.g., the network node 40) in Msg 2 without being triggered to transmit other information, the A-IoT device can reports decoding result of Msg2 to the network node.

[0491] Embodiment B-3-3: Determining Msg3 Resource location or Packet Size

[0492] The resource location or packet size associated with Msg3 can be determined based on at least one of the following.

[0493] A frequency location of PDRCH associated with Msg3 is consistent with the frequency location of the D2R preamble associated Msg3, as mentioned in Embodiment B-3-1.

[0494] A time / frequency location or size of PDRCH associated with Msg3 is indicated in the Msg2 as mentioned in Embodiment B-2-2.

[0495] If triggered information is carried in Msg3, a resource location or size used for transmitting triggered information can refer to Embodiment A2-2.

[0496] Embodiment B-4: Generation and composition of Msg4:

[0497] The embodiment involves R2D preamble generation for Msg4 and content of information in Msg4.

[0498] Embodiment B-4-1: R2D Preamble Generation for Msg4

[0499] R2D preamble associated with Msg4 can be generated according to at least one of the following schemes: 1. A frequency domain resource of the R2D preamble associated with Msg4 can be the same as or  different from a frequency domain resource of the R2D preamble associated with Msg0 or Msg2. 2. Regarding generation of the R2D preamble associated with Msg4, one of the following alternatives  can be considered. i. Alternative 1:

[0500] The R2D preamble associated with Msg4 is distinguishable from the R2D preamble associated with Msg0 or Msg2 in terms of at least one of the following: a. A sequence or format adopted by a R2D preamble. b. A time / frequency location of a R2D preamble.

[0501] An A-IoT device (e.g., A-IoT device 60a) can identify a type of subsequent message (s) being received based on the received sequence, format, or time / frequency location of a R2D preamble. ii. Alternative 2:

[0502] A sequence, format, or time / frequency location of the R2D preamble associated with Msg4 is the same as or related to a sequence, format, or time / frequency location of the D2R preamble associated with Msg3.

[0503] In this case, a link, mapping, or relationship between the R2D preamble associated with Msg4 and the D2R preamble associated with Msg3 during a random-access procedure can be defined in the standard or preconfigured by a network node (e.g., the network node 40) . iii. Alternative 3:

[0504] A sequence, format, or time / frequency location of the R2D preamble associated with Msg4 is the same as or related to a sequence, format, or time / frequency location of the R2D preamble associated with Msg0 or Msg2.

[0505] In this case, a link, mapping, or relationship between the R2D preamble associated with Msg4 and the R2D preamble associated with Msg0 or Msg2 during a Msg0 triggered random access procedure can be defined in the standard or preconfigured by a network node (e.g., the network node 40) .

[0506] Embodiment B-4-2: Content of Information in Msg4

[0507] Content of information carried in Msg4 may include at least one of the following: 1. Trigger information for the next round of an A-IoT procedure. i. In this case, Msg4 can act as Msg0 for triggering the next round of the A-IoT procedure. ii. Any information carried in Msg0, as mentioned in Embodiment A-1-3, an also be carried in Msg4. 2. A grant of time / frequency resource for a channel access failure device to perform random access in  the next round of A-IoT procedure. i. In this case, contention-free random access, as mentioned in Embodiment A-1-3, can be applied,  where a unicast or groupcast ID can be provided in Msg4 for targeting one or more channel access failure devices. 3. Reception performance of Msg3. For example, i. For device-originated-device-terminated triggered (DO-DTT) commands, where an A-IoT device  (e.g., A-IoT device 60a) receives a trigger information in Msg0 or Msg2 from a network node (e.g., the network node 40) and transmits triggered information in Msg3, the following applies. In this case, the network node provides decoding results in Msg4 in response to received Msg3 in PDRCH. Msg1 or Msg3 can be re-transmitted by the A-IoT device if Msg4 cannot be detected or if Msg4 with a negative-acknowledged (NACKed) Msg3 indication has been received.

[0508] Embodiment B-4-3: Conditions for Skipping or Falling Back in 3-Step / 4-Step Random Access, and Acknowledgment Procedures

[0509] A 3-step random-access scheme or a Msg4 of 4-step random access scheme can be omitted or skipped (e.g., by falling back to 3-step random access) if one of the following conditions is satisfied:  1. 3-step random-access scheme is indicated or activated. 2. The network node has successfully received triggered information in Msg3. 3. The network node does not successfully receive the requested information in Msg3.

[0510] The conditions are detailed in the following. 1. 3-step random-access scheme is indicated or activated.

[0511] The 3-step random-access procedure can be predefined in the standard or indicated by a network node (e.g., the network node 40) through Msg0 or Msg2. For 3-step random-access, at least one of the following related operations is accompanied. i. If Msg2 is not correctly received by a target A-IoT device or Msg3 transmitted from a triggered  A-IoT device is not correctly received by a network node (e.g., the network node 40) , another trigger information carried in Msg0 or Msg2 can be issued by the network node. ii. Contention-free channel access scheme is applied in 3-step random-access. iii. A dedicated unicast or groupcast ID for requesting triggered information can be provided in Msg0  or Msg2 iv. A sequence or format of the D2R preamble associated with Msg3, or a time / frequency resource  used for Msg3 transmission is provided in Msg0 or Msg2. 2. The network node has successfully received triggered information in Msg3.

[0512] In this case, an A-IoT device (e.g., A-IoT device 60a) assumes transmitted Msg3 is positive-acknowledged (ACKed) if the A-IoT device does not receive a Msg4 associated with the A-IoT device within a time window. The A-IoT device can re-transmit Msg1 / A or Msg3 if receiving a Msg4 with negative-acknowledged (NACKed) Msg3 indication. The time window for receiving Msg4 can be predefined in the standard or preconfigured by the network node. 3. The network node does not successfully receive the requested information in Msg3.

[0513] In such case, an A-IoT device (e.g., A-IoT device 60a) assumes transmitted Msg3 is negative-acknowledged (NACKed) if the A-IoT device does not receive a Msg4 associated with the A-IoT device within a time window. The A-IoT device can re-transmit Msg1 / A or Msg3 when not receiving Msg4 associated with the A-IoT device.

[0514] Embodiment B-4-4: Determining Msg4 Resource location and Size

[0515] A resource location or size associated with Msg4 can be determined based on at least one of the following. 1. A frequency location of PRDCH associated with Msg4 is consistent with a frequency location of an  R2D preamble associated with Msg4 as mentioned in Embodiment B-4-1. 2. The packet size of information carried in PRDCH associated with Msg4 can be derived from content  of information carried in PRDCH as mentioned in Embodiment B-4-2. That is, the packet size depends on specific information carried in Msg4. For example, the packet size depends on whether decoding results of Msg3 or triggering of another round of random access is transmitted in Msg4 by a network node (e.g., the network node 40) .

[0516] Embodiment C: Follow-up Behaviors After Random-Access Channel Failure

[0517] If failing to access the channel after performing a random-access procedure, the A-IoT device automatously retransmits Msg1 / A in the next slot occasion available for Msg1 / A transmission in the same round of random-access procedure. The next slot occasion can be determined according to at least one of the following: 1. Within a resource pool or slot occasions of a time window indicated in the Msg0 that triggers the  current random-access procedure. 2. Within a resource pool or slot occasions of a time window defined for failed access devices, wherein  the time window can be indicated by a network node (e.g., the network node 40) .

[0518] The location of the time window defined for failed access devices to perform additional trial of random access can be explicitly indicated in the Msg0 or can be derived from the location of the time window defined for initial trial of random access.

[0519] Selection of the next slot occasion can be based on at least one of the following schemes: 1. The next slot occasion is randomly selected by the A-IoT device within a time window which is the  same as for selecting a slot occasion during initial trial of random access. 2. The Parameter used for random selection of a slot occasion for initial trial of random access can be  different from the parameter used for random selection of a slot occasion for additional trial of random access. For example, the size of a time window used for initial trial of random access and the size of a time window used for additional trial of random access can be different.

[0520] The A-IoT device waits for the next round of a trigger message carrying trigger information in Msg0 and retransmits Msg1 / A in one of slot occasions of a time window indicated in the trigger information. The size of the time window can be adjusted by a network node (e.g., the network node 40) in different rounds of the trigger information. The random-access scheme can be adjusted by a network node (e.g., the network node 40) in different rounds of the trigger information.

[0521] Embodiment E: A-IoT, UE and gNB:

[0522] With reference to FIG. 12, the UE 100 may include a processor 11a, a memory 12a, and a transceiver 13a. The processor 11a is configured to call and run a computer program stored in the memory 12a, to cause UE 100 in which the processor 11 is installed to execute the disclosed method, steps, and / or functions of a UE. The UE 100 is an example of the UE in the description (e.g., network node in the figures) . The transceiver 13a may include baseband circuitry and radio frequency (RF) circuitry.

[0523] With reference to FIG. 13, the base station 200 is a network device and may include a processor 21a, a memory 22a, and a transceiver 23a. The processor 21a is configured to call and run a computer program stored in the memory 22a, to cause network node 200 in which the processor 11 is installed to execute the method, steps, and / or functions of a base station. The gNB is an example of the base station in the description. The transceiver 23a, may include baseband circuitry and radio frequency (RF) circuitry.

[0524] With reference to FIG. 14, the embodiment of the disclosure also provides a chip 60 that may correspond to an A-IoT device in the embodiments of the disclosure. The chip 60 may implement a corresponding process realized by the A-IoT device in various methods of the embodiments of the disclosure. The chip 60 includes a logical circuit 61, and the logical circuit 61 may call and run a computer program from memory to implement the methods in the embodiments of the present application.

[0525] Optionally, the chip 60 may also include a memory 62. In particular, the logical circuit 61 may call and run the computer program from the memory 62 to implement the methods in the embodiments of the present application.

[0526] Moreover, the memory 62 may be a separate device from the logical circuit 61 or may be integrated into the logical circuit 61.

[0527] Optionally, the chip 60 may further include an input interface 63. Note that the logical circuit 61 may control the input interface 63 to communicate with other devices or chips, specifically, to obtain messages or data sent by other devices or chips.

[0528] Optionally, the chip 60 may further include an output interface 64. Note that the logical circuit 61 may control the output interface 64 to communicate with other devices or chips, specifically, to output messages or data to other devices or chips.

[0529] With reference to FIG. 15, the embodiment of the disclosure also provides a chip 70 that may correspond to a UE in the embodiments of the disclosure. The chip 70 may implement a corresponding process realized by the UE in various methods of the embodiments of the disclosure. The chip 70 includes a processor 71, and the processor 71 may call and run a computer program from memory to implement the methods in the embodiments of the present application.

[0530] Optionally, the chip 70 may also include a memory 72. In particular, the processor 71 may call and run the computer program from the memory 72 to implement the methods in the embodiments of the present application.

[0531] Moreover, the memory 72 may be a separate device from the processor 71 or may be integrated into the processor 71.

[0532] Optionally, the chip 70 may further include an input interface 73. Note that the processor 71 may control the input interface 73 to communicate with other devices or chips, specifically, to obtain messages or data sent by other devices or chips.

[0533] Optionally, the chip 70 may further include an output interface 74. Note that the processor 71 may control the output interface 74 to communicate with other devices or chips, specifically, to output messages or data to other devices or chips.

[0534] With reference to FIG. 16, the embodiment of the disclosure also provides another chip 80 that may correspond to a base station (e.g., CN network entity, network node, radio node, the base station, or gNB) in the description, and the chip 80 may implement the corresponding processes implemented by the base station in the various methods of the embodiments of the disclosure. The chip 80 includes a processor 81, and the processor 81 may call and run a computer program from the memory 82 to implement the methods in the embodiments of the present application.

[0535] Optionally, the chip 80 may further include a memory 82. In particular, the processor 81 may call and run the computer program from the memory 82 to implement the methods in the embodiments of the present application.

[0536] Wherein the memory 82 may be a separate device from the processor 81 or may be integrated into the processor 81.

[0537] Optionally, the chip 80 may also include an input interface 83. In particular, the processor 81 may control the input interface 83 to communicate with other devices or chips, specifically, to obtain messages or data sent by other devices or chips.

[0538] Optionally, the chip may further include an output interface 84. In particular, the processor 81 may control the output interface 84 to communicate with other devices or chips, specifically, to output messages or data to other devices or chips.

[0539] The embodiment of the present disclosure is a combination of techniques / processes that may be adopted in 3GPP specification to create an end product.

[0540] While the present disclosure has been described in connection with what is considered the most practical and preferred embodiments, it is understood that the present disclosure is not limited to the disclosed embodiments but is intended to cover various arrangements made without departing from the scope of the broadest interpretation of the appended claims.

Claims

1.A channel access method for execution by a network node, with backscatter communication enabled device-to-reader signal transmission, the method comprising:determining a time point for transmitting a trigger signal to at least one IoT device;transmitting the trigger signal to the at least one IoT device according to the determined time point;detecting a message carried in each of at least one first device-to-reader IoT signal from the at least one IoT device;determining one or more than one target IoT device in response to the detected message carried in each of the at least one first device-to-reader IoT signal;transmitting a message carried in a first reader-to-device IoT signal to the one or more than one target IoT device;detecting a message carried in one of one or more than one second device-to-reader IoT signal from one of the one or more than one target IoT device; anddetermining whether to transmit a message in a second reader-to-device IoT signal to the one of the one or more than one target IoT device according to a decoding result of the detected message carried in the one of the one or more than one second device-to-reader IoT signal associated with the one of the one or more than one target IoT device.2.The channel access method of claim 1, wherein the network node is a base station or a UE, and if the network node is a UE, the UE receives control information regarding reader-to-device IoT signal transmission or device-to-reader IoT signal transmission from a base station.3.The channel access method of claim 1, wherein the network node determines a time point to transmit the trigger signal to the at least one IoT device according to availability of a carrier wave signal for the at least one IoT device to perform backscatter communication.4.The channel access method of claim 1, wherein the network node determines a time point to transmit the trigger signal to the at least one IoT device according to remaining energy available for the at least one IoT device to perform backscatter communication.5.The channel access method of claim 1, wherein the network node determines a time point to transmit the trigger signal to the at least one IoT device according to a periodicity for periodic trigger signal transmissions.6.The channel access method of claim 1, wherein the network node determines a time point to transmit the trigger signal to the at least one IoT device according to a type of IoT device being requested.7.The channel access method of claim 1, wherein the network node determines a time point to transmit the trigger signal to the at least one IoT device according to a decoding result of the detected message carried in the at least one second device-to-reader IoT signal.8.The channel access method of claim 1, wherein the network node determines a time point to transmit the trigger signal to the at least one IoT device according to a number of transmission occasions for transmission of a message carried in the first device-to-reader IoT signal.9.The channel access method of claim 1, wherein the network node determines a time point to transmit the trigger signal to the at least one IoT device according to a length of a time window for performing a round of a random access procedure.10.The channel access method of claim 9, wherein the length of a time window depends on the number of transmission occasions available for transmission of a message carried in the first device-to-reader IoT signal.11.The channel access method of claim 1, wherein the network node determines a time point to transmit the trigger signal to the at least one IoT device based on whether the at least one IoT device fails in channel access during a previous round of random access procedure.12.The channel access method of claim 1, wherein the trigger signal comprises a paging message, and the paging message includes an indication specifying whether a contention-based random access scheme or a contention-free random access scheme is configured for the at least one IoT device.13.The channel access method of claim 12, wherein a size of the paging message depends on whether the contention-based random access scheme or contention-free random access scheme is triggered.14.The channel access method of claim 1, wherein the trigger signal or the first reader-to-device IoT signal comprises control information, the control information includes a type of information or message being carried in the trigger signal or the first reader-to-device IoT signal.15.The channel access method of claim 1, wherein the trigger signal or the first reader-to-device IoT signal comprises control information, and the control information includes a transport block size (TBS) of a data packet being carried in the trigger signal or the first reader-to-device IoT signal.16.The channel access method of claim 1, wherein the trigger signal comprises a paging message, and the paging message includes an identifier associated with a single IoT device or a group of IoT devices for responding the paging message.17.The channel access method of claim 1, wherein the trigger signal comprises a paging message, and the paging message includes an indication specifying more than one transmission occasion for the at least one IoT device to determine a resource for a message carried in the respective at least one first device-to-reader IoT signal.18.The channel access method of claim 17, wherein the more than one transmission occasion comprises time division multiple access (TDMA) based or frequency division multiple access (FDMA) based resource occasions.19.The channel access method of claim 17, wherein the message carried in one of the at least one first device-to-reader IoT signal includes an ID, the message is transmitted in a resource randomly selected by an IoT device among the more than one transmission occasion, and the ID is an ID randomly generated by the IoT device.20.The channel access method of claim 1, wherein the one or more than one target IoT device is determined based on detectability of one or more than one ID randomly generated by the at least one IoT device, and each of the one or more than one ID is included in a message carried in one of the at least one first device-to-reader IoT signal.21.The channel access method of claim 1, wherein the message carried in the first reader-to-device IoT signal includes one or more than one transmission grant for the determined one or more than one target IoT device to perform corresponding message transmission in the one or more than one second device-to-reader IoT signal.22.The channel access method of claim 21, wherein transmission grant resources scheduled for the determined one or more than one target IoT device is according to a frequency domain multiple access (FDMA) based scheme.23.The channel access method of claim 1, wherein the message carried in the first reader-to-device IoT signal includes one or more than one ID for the determined one or more than one target IoT device, each of the one or more than one ID is an ID generated by an IoT device and transmitted in one of the at least one first device-to-reader IoT signal.24.The channel access method of claim 1, wherein the message carried in the first reader-to-device IoT signal includes one or more than one ID for the determined one or more than one target IoT device, and each of the one or more than one ID is a dedicated ID assigned by the network node for an IoT device.25.The channel access method of claim 1, wherein the network node determines to transmit a message in the second reader-to-device IoT signal with a NACK-based hybrid automatic repeat request (HARQ) feedback in response to a message carried in a second device-to-reader IoT signal associated with an target IoT device if the network node fails in decoding the message carried in the second device-to-reader IoT signal associated with the target IoT device.26.The channel access method of claim 25, wherein the network node transmits another trigger signal after the second reader-to-device IoT signal, and the target IoT device receiving the second reader-to-device IoT signal with a NACK-based HARQ feedback performs an additional channel access by transmitting another first device-to-reader IoT signal upon receiving the another trigger signal transmitted from the network node.27.The channel access method of claim 1, wherein the network node refrains from transmitting a decoding result in response to a message carried in a second device-to-reader IoT signal associated with an target IoT device if the network node successfully decodes the message carried in the second device-to-reader IoT signal associated with the target IoT device.28.The channel access method of claim 27, wherein the network node transmits another trigger signal, and the target IoT device refrains from performing an additional channel access by transmitting another first device-to-reader IoT signal upon receiving the another trigger signal.29.The channel access method of claim 1, wherein the message carried in the second reader-to-device IoT signal includes a request for retransmission of a message carried in a second device-to-reader IoT signal from a target IoT device if the network node fails in decoding the message carried in the second device-to-reader IoT signal associated with the target IoT device.30.The channel access method of claim 1, wherein the message carried in the second reader-to-device IoT signal includes a retransmission of the message carried in the first reader-to-device IoT signal to a target IoT device if the network node fails in decoding a message carried in a second device-to-reader IoT signal associated with the target IoT device.31.A network node comprising:a processor configured to call and run a computer program stored in a memory, to cause a device in which the processor is installed to execute the method of any of claims 1 to 30.32.A chip, comprising:a processor, configured to call and run a computer program stored in a memory, to cause a device in which the chip is installed to execute the method of any of claims 1 to 30.33.A non-transitory computer-readable storage medium, in which a computer program is stored, wherein the computer program causes a computer to execute the method of any of claims 1 to 30.34.A computer program product, comprising a computer program, wherein the computer program causes a computer to execute the method of any of claims 1 to 30.35.A computer program, wherein the computer program causes a computer to execute the method of any of claims 1 to 30.36.A channel access method for execution by an IoT device among at least one IoT device, with backscatter communication enabled device-to-reader signal transmission, the method comprising:receiving a trigger signal from a network node at a time point;transmitting a message carried in one of at least one first device-to-reader IoT signal from the IoT device among the at least one IoT device to the network node;receiving a message carried in a first reader-to-device IoT signal from the network node in response to the transmitted message carried in the one of the at least one first device-to-reader IoT signal; andtransmitting a message carried in one of one or more than one second device-to-reader IoT signal to the network node;determining a decoding result, at the network node, of the message carried in the one of the one or more than one second device-to-reader IoT signal associated with the IoT device according to whether a message carried in a second reader-to-device IoT signal is detected by the IoT device.37.The channel access method of claim 36, wherein the network node is a base station or a UE, and if the network node is a UE, the UE receives control information regarding reader-to-device IoT signal transmission or device-to-reader IoT signal transmission from a base station.38.The channel access method of claim 36, wherein the network node determines a time point to transmit the trigger signal to the at least one IoT device according to availability of a carrier wave signal for the at least one IoT device to perform backscatter communication.39.The channel access method of claim 36, wherein the network node determines a time point to transmit the trigger signal to the at least one IoT device according to remaining energy available for the at least one IoT device to perform backscatter communication.40.The channel access method of claim 36, wherein the network node determines a time point to transmit the trigger signal to the at least one IoT device according to a periodicity for periodic trigger signal transmissions.41.The channel access method of claim 36, wherein the network node determines a time point to transmit the trigger signal to the at least one IoT device according to a type of IoT device being requested.42.The channel access method of claim 36, wherein the network node determines a time point to transmit the trigger signal to the at least one IoT device according to a decoding result of the detected message carried in the at least one second device-to-reader IoT signal.43.The channel access method of claim 36, wherein the network node determines a time point to transmit the trigger signal to the at least one IoT device according to a number of transmission occasions for transmission of a message carried in the first device-to-reader IoT signal.44.The channel access method of claim 36, wherein the network node determines a time point to transmit the trigger signal to the at least one IoT device according to a length of a time window for performing a round of a random access procedure.45.The channel access method of claim 44, wherein the length of a time window depends on the number of transmission occasions available for transmission of a message carried in the first device-to-reader IoT signal.46.The channel access method of claim 36, wherein the network node determines a time point to transmit the trigger signal to the at least one IoT device based on whether the at least one IoT device fails in channel access during a previous round of random access procedure.47.The channel access method of claim 36, wherein the trigger signal comprises a paging message, and the paging message includes an indication specifying whether a contention-based random access scheme or a contention-free random access scheme is configured for the at least one IoT device.48.The channel access method of claim 47, wherein a size of the paging message depends on whether the contention-based random access scheme or contention-free random access scheme is triggered.49.The channel access method of claim 36, wherein the trigger signal or the first reader-to-device IoT signal comprises control information, the control information includes a type of information or message being carried in the trigger signal or the first reader-to-device IoT signal.50.The channel access method of claim 36, wherein the trigger signal or the first reader-to-device IoT signal comprises control information, and the control information includes a transport block size (TBS) of a data packet being carried in the trigger signal or the first reader-to-device IoT signal.51.The channel access method of claim 36, wherein the trigger signal comprises a paging message, and the paging message includes an identifier associated with a single IoT device or a group of IoT devices for responding the paging message.52.The channel access method of claim 36, wherein the trigger signal comprises a paging message, and the paging message includes an indication specifying more than one transmission occasion for the at least one IoT device to determine a resource for a message carried in the respective at least one first device-to-reader IoT signal.53.The channel access method of claim 52, wherein the more than one transmission occasion comprises time division multiple access (TDMA) based or frequency division multiple access (FDMA) based resource occasions.54.The channel access method of claim 52, wherein the message carried in one of the at least one first device-to-reader IoT signal includes an ID, the message is transmitted in a resource randomly selected by an IoT device among the more than one transmission occasion, and the ID is an ID randomly generated by the IoT device.55.The channel access method of claim 36, wherein the one or more than one target IoT device is determined based on detectability of one or more than one ID randomly generated by the at least one IoT device, and each of the one or more than one ID is included in a message carried in one of the at least one first device-to-reader IoT signal.56.The channel access method of claim 36, wherein the message carried in the first reader-to-device IoT signal includes one or more than one transmission grant for the determined one or more than one target IoT device to perform corresponding message transmission in the one or more than one second device-to-reader IoT signal.57.The channel access method of claim 56, wherein transmission grant resources scheduled for the determined one or more than one target IoT device is according to a frequency domain multiple access (FDMA) based scheme.58.The channel access method of claim 36, wherein the message carried in the first reader-to-device IoT signal includes one or more than one ID for the determined one or more than one target IoT device, each of the one or more than one ID is an ID generated by an IoT device and transmitted in one of the at least one first device-to-reader IoT signal.59.The channel access method of claim 36, wherein the message carried in the first reader-to-device IoT signal includes one or more than one ID for the determined one or more than one target IoT device, and each of the one or more than one ID is a dedicated ID assigned by the network node for an IoT device.60.The channel access method of claim 36, wherein the network node determines to transmit a message in the second reader-to-device IoT signal with a NACK-based hybrid automatic repeat request (HARQ) feedback in response to a message carried in a second device-to-reader IoT signal associated with an target IoT device if the network node fails in decoding the message carried in the second device-to-reader IoT signal associated with the target IoT device.61.The channel access method of claim 60, wherein the target IoT device receives another trigger signal after the second reader-to-device IoT signal, and the target IoT device receiving the second reader-to-device IoT signal with a NACK-based HARQ feedback performs an additional channel access by transmitting another first device-to-reader IoT signal upon receiving the another trigger signal transmitted from the network node.62.The channel access method of claim 36, wherein the network node refrains from transmitting a decoding result in response to a message carried in a second device-to-reader IoT signal associated with an target IoT device if the network node successfully decodes the message carried in the second device-to-reader IoT signal associated with the target IoT device.63.The channel access method of claim 62, wherein the target IoT device receives another trigger signal, and the target IoT device refrains from performing an additional channel access by transmitting another first device-to-reader IoT signal upon receiving the another trigger signal.64.The channel access method of claim 36, wherein the message carried in the second reader-to-device IoT signal includes a request for retransmission of a message carried in a second device-to-reader IoT signal from a target IoT device if the network node fails in decoding the message carried in the second device-to-reader IoT signal associated with the target IoT device.65.The channel access method of claim 36, wherein the message carried in the second reader-to-device IoT signal includes a retransmission of the message carried in the first reader-to-device IoT signal to a target IoT device if the network node fails in decoding a message carried in a second device-to-reader IoT signal associated with the target IoT device.66.A device comprising:a processor configured to call and run a computer program stored in a memory, to cause a device in which the processor is installed to execute the method of any of claims 36 to 65.67.A chip, comprising:a processor, configured to call and run a computer program stored in a memory, to cause a device in which the chip is installed to execute the method of any of claims 36 to 65.68.A non-transitory computer-readable storage medium, in which a computer program is stored, wherein the computer program causes a computer to execute the method of any of claims 36 to 65.69.A computer program product, comprising a computer program, wherein the computer program causes a computer to execute the method of any of claims 36 to 65.70.A computer program, wherein the computer program causes a computer to execute the method of any of claims 36 to 65.

Citation Information

Patent Citations

  • Network element selection method, capability indication method and device

    CN117082591A

  • Timing information configuration for passive IoT

    WO2023240585A1

  • REPORTING PASSIVE INTERNET OF THINGS (IoT) DEVICE SIGNAL DECODING TIMES

    WO2023245532A1