Methods and apparatuses for bidirectional ambient IoT communication
A-IoT readers manage resource allocation and failure detection to facilitate effective bidirectional communication in IoT systems, addressing resource provision and failure detection challenges.
Patent Information
- Application Number
- PCT/CN2024/130467
- Authority / Receiving Office
- WO · WO
- Patent Type
- Applications
- Current Assignee / Owner
- Filing Date
- 2024-11-07
- Publication Date
- 2025-08-21
AI Technical Summary
Current technologies face challenges in providing resources for bidirectional ambient Internet of Things (IoT) communication, supporting performance requirements of IoT devices, and determining communication failures in such systems.
A-IoT readers request and determine resources for device-to-reader transmissions, decide on the type of random access for IoT devices, and implement timers to detect communication failures, with support from core networks and base stations.
Enables efficient bidirectional communication by allocating necessary resources and detecting failures, ensuring reliable operation of ambient IoT devices.
Smart Images

Figure CN2024130467_21082025_PF_FP_ABST
Abstract
Description
METHODS AND APPARATUSES FOR BIDIRECTIONAL AMBIENT IOT COMMUNICATIONTECHNICAL FIELD
[0001] The present disclosure relates to wireless communications, and more specifically to methods and apparatuses for bidirectional ambient internet of things (A-IoT) communication.BACKGROUND
[0002] A wireless communications system may include one or multiple network communication devices, such as base stations (BSs) , which may support wireless communications for one or multiple user communication devices, which may be otherwise known as user equipment (UE) , or other suitable terminology. The wireless communications system may support wireless communications with one or multiple user communication devices by utilizing resources of the wireless communication system (e.g. time-domain resources (e.g. symbols, slots, subframes, frames, or the like) or frequency-domain resources (e.g. subcarriers, carriers, or the like) . Additionally, the wireless communications system may support wireless communications across various radio access technologies including third generation (3G) radio access technology, fourth generation (4G) radio access technology, fifth generation (5G) radio access technology, among other suitable radio access technologies beyond 5G (e.g. sixth generation (6G) ) .SUMMARY
[0003] An article "a" before an element is unrestricted and understood to refer to "at least one" of those elements or "one or more" of those elements. The terms "a, " "at least one, " "one or more, " and "at least one of one or more" may be interchangeable. As used herein, including in the claims, "or" as used in a list of items (e.g. a list of items prefaced by a phrase such as "at least one of" or "one or more of" or "one or both of" ) indicates an inclusive list such that, for example, a list of at least one of A, B, or C means A or B or C or AB or AC or BC or ABC (i.e., A and B and C) . Also, as used herein, the phrase "based on" shall not be construed as a reference to a closed set of conditions. For example, an example step that is described as "based on condition A" may be based on both a condition A and a condition B without departing from the scope of the present disclosure. In other words, as used herein, the phrase "based on" shall be construed in the same manner as the phrase "based at least in part on. Further, as used herein, including in the claims, a "set" may include one or more elements.
[0004] Some implementations of the present disclosure provide a first ambient internet of things (A-IoT) reader. The first A-IoT reader includes at least one memory; and at least one processor coupled to the at least one memory and configured to cause the first A-IoT reader to: transmit, to an A-IoT device, a first message including information related to a first resource used for device to reader (D2R) transmission; and receive a D2R transmission of the A-IoT device from a second A-IoT reader, wherein the D2R transmission is transmitted from the A-IoT device to the second A-IoT reader via the first resource.
[0005] In some implementations of the first A-IoT reader described herein, the at least one processor is further configured to cause the first A-IoT reader to receive the information related to the first resource from the second A-IoT reader.
[0006] In some implementations of the first A-IoT reader described herein, the at least one processor is further configured to cause the first A-IoT reader to: receive a resource set or resource configuration information from the second A-IoT reader; and determine the first resource based on the resource set or the resource configuration information.
[0007] In some implementations of the first A-IoT reader described herein, the at least one processor is further configured to cause the first A-IoT reader to transmit a request to the second A-IoT reader, and wherein the request includes information for indicating that the request is associated with one or more A-IoT devices.
[0008] In some implementations of the first A-IoT reader described herein, the at least one processor is further configured to cause the first A-IoT reader to transmit the information related to the first resource to the second A-IoT reader.
[0009] In some implementations of the first A-IoT reader described herein, the first resource is one of the following: a common resource used for MSG1 transmission of 3-step contention-based random access (CBRA) ; a common resource used for MSG1 transmission of 2-step CBRA; or a dedicated resource used for MSG1 transmission of contention-free random access (CFRA) ; and the first message is a paging message, and the MSG1 transmission is a first D2R transmission from the A-IoT device during random access; or wherein the first resource is a dedicated resource used for MSG3 transmission of 3-step CBRA, the first message is MSG2 of 3-step CBRA, the MSG3 transmission is a second D2R transmission from the A-IoT device during random access, and the MSG2 is a first reader to device (R2D) transmission to the A-IoT device during random access; or wherein the first resource is a dedicated resource used for a command response transmission, and the first message is one of the following: MSG4 of 3-step CBRA, wherein the MSG4 is a second R2D transmission to the A-IoT device during random access; MSG2 of 2-step CBRA; or MSG2 of CFRA.
[0010] In some implementations of the first A-IoT reader described herein, the first or second D2R transmission from the A-IoT device or the first or second R2D transmission to the A-IoT device includes an ID of the A-IoT device.
[0011] In some implementations of the first A-IoT reader described herein, the paging message includes at least one of the following: identifier (ID) information of one or more A-IoT devices including the A-IoT device; an A-IoT group ID; a type of random access, wherein the type of random access includes 3-step CBRA, 2-step CBRA or CFRA; or a first indicator for indicating that a command response will be sent by the A-IoT device.
[0012] In some implementations of the first A-IoT reader described herein, the first indicator is a type of a command, and the command is a read command, a write command or a disable command.
[0013] In some implementations of the first A-IoT reader described herein, the at least one processor is further configured to cause the first A-IoT reader to transmit a second message to the second A-IoT reader, and wherein the second message includes at least one of the following: identifier (ID) information of one or more A-IoT devices including the A-IoT device; an A-IoT group ID; a type of random access that can be used by the one or more A-IoT devices, wherein the type of random access includes 3-step CBRA, 2-step CBRA or CFRA; information for indicating that a command response will be sent by the one or more A-IoT devices; or an approximate number of the one or more A-IoT devices.
[0014] In some implementations of the first A-IoT reader described herein, the at least one processor is further configured to cause the first A-IoT reader to receive information related to the second A-IoT reader from a core network (CN) or a base station (BS) , wherein the information related to the second A-IoT reader includes at least one of the following: an ID of the second A-IoT reader; or a certain area from which the D2R transmission of the A-IoT device is to be received.
[0015] In some implementations of the first A-IoT reader described herein, the at least one processor is further configured to cause the first A-IoT reader to receive, from the second A-IoT reader, a cause value indicating no resource available in the second A-IoT reader, wherein the cause value is further associated with an ID of the A-IoT device.
[0016] In some implementations of the first A-IoT reader described herein, the at least one processor is further configured to cause the first A-IoT reader to: start a first timer; and consider that the A-IoT device communication is failed, if no response is received from the A-IoT device via the second A-IoT reader before the first timer expires or if no response is received from at least a threshold of all A-IoT devices via the second A-IoT reader before the first timer expires.
[0017] In some implementations of the first A-IoT reader described herein, the at least one processor is further configured to cause the first A-IoT reader to transmit a threshold to the second A-IoT reader, and wherein the threshold is used by the second A-IoT reader to determine whether the A-IoT communication is successfully completed based on the threshold.
[0018] In some implementations of the first A-IoT reader described herein, the at least one processor is further configured to cause the first A-IoT reader to receive a third message from the second A-IoT reader, and wherein the third message includes at least one of the following: a proximity location of the A-IoT device; an energy status report of the A-IoT device; or a cause value of a communication failure of the A-IoT device.
[0019] In some implementations of the first A-IoT reader described herein, the cause value includes one of the following: no response is received from the A-IoT device; the A-IoT device is far; no response is received from the A-IoT device due to the second A-IoT reader moving; or no response is received from the A-IoT device due to low energy of the A-IoT device.
[0020] Some implementations of the present disclosure provide a processor of a first ambient internet of things (A-IoT) reader for wireless communication, comprising at least one controller coupled with at least one memory and configured to cause the processor to: transmit, to an A-IoT device, a first message including information related to a first resource used for device to reader (D2R) transmission; and receive a D2R transmission of the A-IoT device from a second A-IoT reader, wherein the D2R transmission is transmitted from the A-IoT device to the second A-IoT reader via the first resource
[0021] Some implementations of the present disclosure provide a method performed by a first ambient internet of things (A-IoT) reader. The method includes: transmitting, to an A-IoT device, a first message including information related to a first resource used for device to reader (D2R) transmission; and receiving a D2R transmission of the A-IoT device from a second A-IoT reader, wherein the D2R transmission is transmitted from the A-IoT device to the second A-IoT reader via the first resource.
[0022] Some implementations of the present disclosure provide a second ambient internet of things (A-IoT) reader. The second A-IoT reader includes at least one memory; and at least one processor coupled to the at least one memory and configured to cause the second A-IoT reader to: receive a device to reader (D2R) transmission from an A-IoT device via a first resource used for D2R transmission; and transmit the D2R transmission of the A-IoT device to a first A-IoT reader, wherein information related to the first resource is transmitted by the first A-IoT reader to the A-IoT device.
[0023] In some implementations of the second A-IoT reader described herein, the at least one processor is further configured to cause the second A-IoT reader to transmit the information related to the first resource to the first A-IoT reader.
[0024] In some implementations of the second A-IoT reader described herein, the at least one processor is further configured to cause the second A-IoT reader to transmit a resource set or resource configuration information to the first A-IoT reader, and wherein the resource set or the resource configuration information is used by the first A-IoT reader to determine the first resource.
[0025] In some implementations of the second A-IoT reader described herein, the at least one processor is further configured to cause the second A-IoT reader to receive a request from the first A-IoT reader, and wherein the request includes information for indicating that the request is associated with one or more A-IoT devices.
[0026] In some implementations of the second A-IoT reader described herein, the at least one processor is further configured to cause the second A-IoT reader to receive the information related to the first resource from the first A-IoT reader.
[0027] In some implementations of the second A-IoT reader described herein, the first resource is one of the following: a common resource used for MSG1 transmission of 3-step contention-based random access (CBRA) ; a common resource used for MSG1 transmission of 2-step CBRA; a dedicated resource used for MSG1 transmission of contention-free random access (CFRA) ; a dedicated resource used for MSG3 transmission of 3-step CBRA; or a dedicated resource used for a command response transmission, wherein the MSG1 transmission is a first D2R transmission from the A-IoT device during random access, and the MSG3 transmission is a second D2R transmission from the A-IoT device during random access.
[0028] In some implementations of the second A-IoT reader described herein, the first or second D2R transmission from the A-IoT device includes an ID of the A-IoT device.
[0029] In some implementations of the second A-IoT reader described herein, the at least one processor is further configured to cause the second A-IoT reader to receive a second message from the first A-IoT reader, and wherein the second message includes at least one of the following: identifier (ID) information of one or more A-IoT devices including the A-IoT device; an A-IoT group ID; a type of random access that can be used by the one or more A-IoT devices, wherein the type of random access includes 3-step CBRA, 2-step CBRA or CFRA; information for indicating that a command response will be sent by the one or more A-IoT devices; or an approximate number of the one or more A-IoT devices.
[0030] In some implementations of the second A-IoT reader described herein, the at least one processor is further configured to cause the second A-IoT reader to transmit, to the first A-IoT reader, a cause value indicating no resource available in the second A-IoT reader, wherein the cause value is further associated with an ID of the A-IoT device.
[0031] In some implementations of the second A-IoT reader described herein, the at least one processor is further configured to cause the second A-IoT reader to: receive a threshold from the first A-IoT reader; and determine whether the A-IoT communication is successfully completed based on the threshold.
[0032] In some implementations of the second A-IoT reader described herein, the at least one processor is further configured to cause the second A-IoT reader to: start a second timer; and consider that the A-IoT device communication is failed, if no response is received from the A-IoT device before the second timer expires or if no response is received from at least a threshold of all A-IoT devices before the second timer expires.
[0033] In some implementations of the second A-IoT reader described herein, the at least one processor is further configured to cause the second A-IoT reader to transmit a third message to the first A-IoT reader, and wherein the third message includes at least one of the following: a proximity location of the A-IoT device; an energy status report of the A-IoT device; or a cause value of a communication failure of the A-IoT device.
[0034] In some implementations of the second A-IoT reader described herein, the cause value includes one of the following: no response is received from the A-IoT device; the A-IoT device is far; no response is received from the A-IoT device due to the second A-IoT reader moving; or no response is received from the A-IoT device due to low energy of the A-IoT device.
[0035] Some implementations of the present disclosure provide a processor of a second ambient internet of things (A-IoT) reader for wireless communication, comprising at least one controller coupled with at least one memory and configured to cause the processor to: receive a device to reader (D2R) transmission from an A-IoT device via a first resource used for D2R transmission; and transmit the D2R transmission of the A-IoT device to a first A-IoT reader, wherein information related to the first resource is transmitted by the first A-IoT reader to the A-IoT device.
[0036] Some implementations of the present disclosure provide a method performed by a second ambient internet of things (A-IoT) reader. The method includes: receiving a device to reader (D2R) transmission from an A-IoT device via a first resource used for D2R transmission; and transmitting the D2R transmission of the A-IoT device to a first A-IoT reader, wherein information related to the first resource is transmitted by the first A-IoT reader to the A-IoT device.
[0037] Some implementations of the present disclosure provide an ambient internet of things (A-IoT) device. The A-IoT device includes at least one memory; and at least one processor coupled to the at least one memory and configured to cause the A-IoT device to: receive, from a first A-IoT reader, a first message including information related to a first resource used for device to reader (D2R) transmission; and transmit a D2R transmission to a second A-IoT reader via the first resource, wherein the D2R transmission from the A-IoT device is forwarded by the second A-IoT reader to the first A-IoT reader.
[0038] In some implementations of the A-IoT device described herein, the first resource is one of the following: a common resource used for MSG1 transmission of 3-step contention-based random access (CBRA) ; a common resource used for MSG1 transmission of 2-step CBRA; or a dedicated resource used for MSG1 transmission of contention-free random access (CFRA) ; and the first message is a paging message, and the MSG1 transmission is a first D2R transmission from the A-IoT device during random access; or wherein the first resource is a dedicated resource used for MSG3 transmission of 3-step CBRA, the first message is MSG2 of 3-step CBRA, the MSG3 transmission is a second D2R transmission from the A-IoT device during random access, and the MSG2 transmission is a first reader to device (R2D) transmission to the A-IoT device during random access; or wherein the first resource is a dedicated resource used for a command response transmission, and the first message is one of the following: MSG4 of 3-step CBRA, wherein the MSG4 is a second R2D transmission to the A-IoT device during random access; MSG2 of 2-step CBRA; or MSG2 of CFRA.
[0039] In some implementations of the A-IoT device described herein, the first or second D2R transmission from the A-IoT device or the first or second R2D transmission to the A-IoT device includes an ID of the A-IoT device.
[0040] In some implementations of the A-IoT device described herein, the paging message includes at least one of the following: identifier (ID) information of one or more A-IoT devices including the A-IoT device; an A-IoT group ID; a type of random access, wherein the type of random access includes 3-step CBRA, 2-step CBRA or CFRA; or a first indicator for indicating that a command response will be sent by the A-IoT device.
[0041] In some implementations of the A-IoT device described herein, the first indicator is a type of a command, and the command is a read command, a write command or a disable command.
[0042] Some implementations of the present disclosure provide a processor of an ambient internet of things (A-IoT) device for wireless communication, comprising at least one controller coupled with at least one memory and configured to cause the processor to: receive, from a first A-IoT reader, a first message including information related to a first resource used for device to reader (D2R) transmission; and transmit a D2R transmission to a second A-IoT reader via the first resource, wherein the D2R transmission from the A-IoT device is forwarded by the second A-IoT reader to the first A-IoT reader.
[0043] Some implementations of the present disclosure provide a method performed by an ambient internet of things (A-IoT) device. The method includes: receiving, from a first A-IoT reader, a first message including information related to a first resource used for device to reader (D2R) transmission; and transmitting a D2R transmission to a second A-IoT reader via the first resource, wherein the D2R transmission from the A-IoT device is forwarded by the second A-IoT reader to the first A-IoT reader.BRIEF DESCRIPTION OF THE DRAWINGS
[0044] Figure 1A illustrates scenarios of bidirectional A-IoT communication in accordance with aspects of the present disclosure.
[0045] Figure 1 illustrates an example of a wireless communications system in accordance with aspects of the present disclosure.
[0046] Figure 2 illustrates an example of a user equipment (UE) 200 in accordance with aspects of the present disclosure.
[0047] Figure 3 illustrates an example of a processor 300 in accordance with aspects of the present disclosure.
[0048] Figure 4 illustrates an example of a network equipment (NE) 400 in accordance with aspects of the present disclosure.
[0049] Figures 5-7 illustrate flowcharts related to bidirectional A-IoT communication in accordance with aspects of the present disclosure.
[0050] Figures 8-11 illustrate schematic diagrams of bidirectional A-IoT communication in accordance with aspects of the present disclosure.DETAILED DESCRIPTION
[0051] In recent years, IoT has attracted much attention in the wireless communication world, where the IoT device has smaller size, lower complexity, lower power consumption and huger number (e.g. tens or even hundreds of billion IoT devices) than the existing UE.
[0052] As used herein, the term "ambient IoT device" or "A-IoT device" can typically refer to battery less devices with no energy storage capability, or devices with energy storage that do not need to be replaced or recharged manually, where the energy is provided through the harvesting of radio waves, light, motion, heat, or any other power source that could be seen suitable. For simplicity, these devices are named as A-IoT devices. In other words, the A-IoT device is an IoT device powered by energy harvesting, with limited energy storage capability.
[0053] For A-IoT communication, there may be one or more A-IoT readers, where one A-IoT reader is responsible for transmitting downlink (DL) signal and / or content to the A-IoT devices (R2D) , while other A-IoT reader (s) is responsible for receiving uplink (UL) signal and / or content from the A-IoT devices (D2R) . For example, A-IoT readers and A-IoT devices are defined the following scenarios, i.e. Scenario 1 and Scenario 2 as illustrated by Figure 1A.
[0054] Figure 1A illustrates scenarios of bidirectional A-IoT communication in accordance with aspects of the present disclosure.
[0055] - In Scenario 1, R1 is an A-IoT reader transmitting an R2D transmission (or an R2D signal) to an A-IoT device (i.e. D as shown in Figure 1A, e.g. a UE) , and R2 is an A-IoT reader receiving a D2R transmission (or a D2R signal) from the A-IoT device, where both R1 and R2 are BSs.
[0056] - In Scenario 2, R1 is an A-IoT reader transmitting an R2D transmission or signal to an A-IoT device (i.e. D as shown in Figure 1A, e.g. a UE) , and R2 is an A-IoT reader receiving a D2R transmission or signal from the A-IoT device, where both R1 and R2 are intermediate nodes between a BS and the A-IoT device.
[0057] Currently, to support bidirectional A-IoT communication between an A-IoT reader and an A-IoT device, the following issues have not been solved:
[0058] - Issue 1: How to provide one or more resources used for a D2R transmission?
[0059] - Issue 2: How to support the performance requirement of an A-IoT device?
[0060] - Issue 3: How to determine a failure of an A-IoT device communication?
[0061] Embodiments of the present disclosure aim to resolve the abovementioned issues. To support the bidirectional A-IoT communication, some embodiments of the present disclosure design a solution in which an A-IoT reader (e.g. R1 as shown in Figures 1A and 8-11) requests another A-IoT reader (e.g. R2 as shown in Figures 1A and 8-11) to provide the resource used for D2R transmission. For instance, the request may include ID (s) of the A-IoT device (s) or a group ID of the A-IoT device (s) , a type of random access and an indicator indicating that a command response will be sent by the A-IoT device (e.g. D as shown in Figures 1A and 8-11) . Some other embodiments of the present disclosure design a solution in which R1 determines the resource used for D2R transmission and sends the determination and the corresponding type of random access to R2. In some embodiments, a CN or a BS may provide information related to R2 (e.g. R2 information) to R1, e.g. via an inventory request message.
[0062] To support the performance requirement of an A-IoT device, some embodiments of the present disclosure design a solution in which an A-IoT reader (e.g. R1 as shown in Figures 1A and 8-11) decides the type of random access for an A-IoT device (e.g. D as shown in Figures 1A and 8-11) . If another A-IoT reader (e.g. R2 as shown in Figures 1A and 8-11) cannot provide the resource used for D2R transmission, it provides a cause value indicating that the resource used for D2R transmission is not available in R2. Some other embodiments of the present disclosure design a solution in which R2 decides the type of random access for an A-IoT device. In such case, R1 may provide the approximate number of A-IoT devices to R2, while R2 sends the type of random access to R1. In some embodiments, an A-IoT paging message includes the type of random access and an indicator indicating that a command response will be sent by the A-IoT device.
[0063] To determine a failure of A-IoT device communication, some embodiments of the present disclosure design a solution in which an A-IoT reader (e.g. R1 as shown in Figures 1A and 8-11) starts a timer when sending a paging message to an A-IoT device (e.g. D as shown in Figures 1A and 8-11) to determine the failure of A-IoT device communication. In such case, another A-IoT reader (e.g. R2 as shown in Figures 1A and 8-11) may send a notification to R1 to indicate the proximity location and / or energy status of the A-IoT device. Some other embodiments of the present disclosure design a solution in which R2 starts a timer when receiving an indication from R1, where the value of the timer may be received from R1 or determined by R2 itself. If the failure of A-IoT device communication is determined, R2 may send a new cause value to R1.
[0064] In the embodiments of the present disclosure, "an A-IoT reader" may also be named as "a reader for A-IoT communication" or the like. For example, an A-IoT reader may be a BS, a NE, an intermediate node between the BS and a UE, or an intermediate node between the NE and a UE. In some cases, the intermediate node between the BS (or NE) and a UE may also be a UE. "An A-IoT device" may also be named as "a device for A-IoT communication" or the like. For example, an A-IoT device is a UE. More details of the embodiments of the present disclosure will be illustrated in the following text in combination with the appended drawings.
[0065] Figure 1 illustrates an example of a wireless communications system 100 in accordance with aspects of the present disclosure. The wireless communications system 100 may include one or more NE 102, one or more UE 104, and a core network (CN) 106. The wireless communications system 100 may support various radio access technologies. In some implementations, the wireless communications system 100 may be a 4G network, such as an LTE network or an LTE-Advanced (LTE-A) network. In some other implementations, the wireless communications system 100 may be a NR network, such as a 5G network, a 5G-Advanced (5G-A) network, or a 5G ultrawideband (5G-UWB) network. In other implementations, the wireless communications system 100 may be a combination of a 4G network and a 5G network, or other suitable radio access technology including Institute of Electrical and Electronics Engineers (IEEE) 802.11 (Wi-Fi) , IEEE 802.16 (WiMAX) , IEEE 802.20. The wireless communications system 100 may support radio access technologies beyond 5G, for example, 6G. Additionally, the wireless communications system 100 may support technologies, such as time division multiple access (TDMA) , frequency division multiple access (FDMA) , or code division multiple access (CDMA) , etc.
[0066] The one or more NE 102 may be dispersed throughout a geographic region to form the wireless communications system 100. One or more of the NE 102 described herein may be or include or may be referred to as a network node, a base station (BS) , a network element, a network function, a network entity, a radio access network (RAN) , a NodeB, an eNodeB (eNB) , a next-generation NodeB (gNB) , or other suitable terminology. An NE 102 and a UE 104 may communicate via a communication link, which may be a wireless or wired connection. For example, an NE 102 and a UE 104 may perform wireless communication (e.g. receive signaling, transmit signaling) over a Uu interface.
[0067] An NE 102 may provide a geographic coverage area for which the NE 102 may support services for one or more UEs 104 within the geographic coverage area. For example, an NE 102 and a UE 104 may support wireless communication of signals related to services (e.g. voice, video, packet data, messaging, broadcast, etc. ) according to one or multiple radio access technologies. In some implementations, an NE 102 may be moveable, for example, a satellite associated with a non-terrestrial network (NTN) . In some implementations, different geographic coverage areas associated with the same or different radio access technologies may overlap, but the different geographic coverage areas may be associated with different NE 102.
[0068] The one or more UE 104 may be dispersed throughout a geographic region of the wireless communications system 100. A UE 104 may include or may be referred to as a remote unit, a mobile device, a wireless device, a remote device, a subscriber device, a transmitter device, a receiver device, or some other suitable terminology. In some implementations, the UE 104 may be referred to as a unit, a station, a terminal, or a client, among other examples. Additionally, or alternatively, the UE 104 may be referred to as an Internet-of-Things (IoT) device, an Internet-of-Everything (IoE) device, or machine-type communication (MTC) device, among other examples.
[0069] A UE 104 may be able to support wireless communication directly with other UEs 104 over a communication link. For example, a UE 104 may support wireless communication directly with another UE 104 over a device-to-device (D2D) communication link. In some implementations, such as vehicle-to-vehicle (V2V) deployments, vehicle-to-everything (V2X) deployments, or cellular-V2X deployments, the communication link may be referred to as a sidelink. For example, a UE 104 may support wireless communication directly with another UE 104 over a PC5 interface.
[0070] An NE 102 may support communications with the CN 106, or with another NE 102, or both. For example, an NE 102 may interface with other NE 102 or the CN 106 through one or more backhaul links (e.g. S1, N2, or network interface) . In some implementations, the NE 102 may communicate with each other directly. In some other implementations, the NE 102 may communicate with each other or indirectly (e.g. via the CN 106. In some implementations, one or more NE 102 may include subcomponents, such as an access network entity, which may be an example of an access node controller (ANC) . An ANC may communicate with the one or more UEs 104 through one or more other access network transmission entities, which may be referred to as a radio heads, smart radio heads, or transmission-reception points (TRPs) .
[0071] The CN 106 may support user authentication, access authorization, tracking, connectivity, and other access, routing, or mobility functions. The CN 106 may be an evolved packet core (EPC) , or a 5G core (5GC) , which may include a control plane entity that manages access and mobility (e.g. a mobility management entity (MME) , an access and mobility management functions (AMF) ) and a user plane entity that routes packets or interconnects to external networks (e.g. a serving gateway (S-GW) , a Packet Data Network (PDN) gateway (P-GW) , or a user plane function (UPF) ) . In some implementations, the control plane entity may manage non-access stratum (NAS) functions, such as mobility, authentication, and bearer management (e.g. data bearers, signal bearers, etc. ) for the one or more UEs 104 served by the one or more NE 102 associated with the CN 106.
[0072] The CN 106 may communicate with a packet data network over one or more backhaul links (e.g. via an S1, N2, or another network interface) . The packet data network may include an application server. In some implementations, one or more UEs 104 may communicate with the application server. A UE 104 may establish a session (e.g. a protocol data unit (PDU) session, or the like) with the CN 106 via an NE 102. The CN 106 may route traffic (e.g. control information, data, and the like) between the UE 104 and the application server using the established session (e.g. the established PDU session) . The PDU session may be an example of a logical connection between the UE 104 and the CN 106 (e.g. one or more network functions of the CN 106) .
[0073] In the wireless communications system 100, the NEs 102 and the UEs 104 may use resources of the wireless communications system 100 (e.g. time resources (e.g. symbols, slots, subframes, frames, or the like) or frequency resources (e.g. subcarriers, carriers) ) to perform various operations (e.g. wireless communications) . In some implementations, the NEs 102 and the UEs 104 may support different resource structures. For example, the NEs 102 and the UEs 104 may support different frame structures. In some implementations, such as in 4G, the NEs 102 and the UEs 104 may support a single frame structure. In some other implementations, such as in 5G and among other suitable radio access technologies, the NEs 102 and the UEs 104 may support various frame structures (i.e., multiple frame structures) . The NEs 102 and the UEs 104 may support various frame structures based on one or more numerologies.
[0074] One or more numerologies may be supported in the wireless communications system 100, and a numerology may include a subcarrier spacing and a cyclic prefix. A first numerology (e.g. μ=0) may be associated with a first subcarrier spacing (e.g. 15 kHz) and a normal cyclic prefix. In some implementations, the first numerology (e.g. μ=0) associated with the first subcarrier spacing (e.g. 15 kHz) may utilize one slot per subframe. A second numerology (e.g. μ=1) may be associated with a second subcarrier spacing (e.g. 30 kHz) and a normal cyclic prefix. A third numerology (e.g. μ=2) may be associated with a third subcarrier spacing (e.g. 60 kHz) and a normal cyclic prefix or an extended cyclic prefix. A fourth numerology (e.g. μ=3) may be associated with a fourth subcarrier spacing (e.g. 120 kHz) and a normal cyclic prefix. A fifth numerology (e.g. μ=4) may be associated with a fifth subcarrier spacing (e.g. 240 kHz) and a normal cyclic prefix.
[0075] A time interval of a resource (e.g. a communication resource) may be organized according to frames (also referred to as radio frames) . Each frame may have a duration, for example, a 10 millisecond (ms) duration. In some implementations, each frame may include multiple subframes. For example, each frame may include 10 subframes, and each subframe may have a duration, for example, a 1 ms duration. In some implementations, each frame may have the same duration. In some implementations, each subframe of a frame may have the same duration.
[0076] Additionally or alternatively, a time interval of a resource (e.g. a communication resource) may be organized according to slots. For example, a subframe may include a number (e.g. quantity) of slots. The number of slots in each subframe may also depend on the one or more numerologies supported in the wireless communications system 100. For instance, the first, second, third, fourth, and fifth numerologies (i.e., μ=0, μ=1, μ=2, μ=3, μ=4) associated with respective subcarrier spacings of 15 kHz, 30 kHz, 60 kHz, 120 kHz, and 240 kHz may utilize a single slot per subframe, two slots per subframe, four slots per subframe, eight slots per subframe, and 16 slots per subframe, respectively. Each slot may include a number (e.g. quantity) of symbols (e.g. OFDM symbols) . In some implementations, the number (e.g. quantity) of slots for a subframe may depend on a numerology. For a normal cyclic prefix, a slot may include 14 symbols. For an extended cyclic prefix (e.g. applicable for 60 kHz subcarrier spacing) , a slot may include 12 symbols. The relationship between the number of symbols per slot, the number of slots per subframe, and the number of slots per frame for a normal cyclic prefix and an extended cyclic prefix may depend on a numerology. It should be understood that reference to a first numerology (e.g. μ=0) associated with a first subcarrier spacing (e.g. 15 kHz) may be used interchangeably between subframes and slots.
[0077] In the wireless communications system 100, an electromagnetic (EM) spectrum may be split, based on frequency or wavelength, into various classes, frequency bands, frequency channels, etc. By way of example, the wireless communications system 100 may support one or multiple operating frequency bands, such as frequency range designations FR1 (410 MHz –7.125 GHz) , FR2 (24.25 GHz –52.6 GHz) , FR3 (7.125 GHz –24.25 GHz) , FR4 (52.6 GHz –114.25 GHz) , FR4a or FR4-1 (52.6 GHz –71 GHz) , and FR5 (114.25 GHz –300 GHz) . In some implementations, the NEs 102 and the UEs 104 may perform wireless communications over one or more of the operating frequency bands. In some implementations, FR1 may be used by the NEs 102 and the UEs 104, among other equipment or devices for cellular communications traffic (e.g. control information, data) . In some implementations, FR2 may be used by the NEs 102 and the UEs 104, among other equipment or devices for short-range, high data rate capabilities.
[0078] FR1 may be associated with one or multiple numerologies (e.g. at least three numerologies) . For example, FR1 may be associated with a first numerology (e.g. μ=0) , which includes 15 kHz subcarrier spacing; a second numerology (e.g. μ=1) , which includes 30 kHz subcarrier spacing; and a third numerology (e.g. μ=2) , which includes 60 kHz subcarrier spacing. FR2 may be associated with one or multiple numerologies (e.g. at least 2 numerologies) . For example, FR2 may be associated with a third numerology (e.g. μ=2) , which includes 60 kHz subcarrier spacing; and a fourth numerology (e.g. μ=3) , which includes 120 kHz subcarrier spacing.
[0079] Figure 2 illustrates an example of a UE 200 in accordance with aspects of the present disclosure. The UE 200 may include a processor 202, a memory 204, a controller 206, and a transceiver 208. The processor 202, the memory 204, the controller 206, or the transceiver 208, or various combinations thereof or various components thereof may be examples of means for performing various aspects of the present disclosure as described herein. These components may be coupled (e.g. operatively, communicatively, functionally, electronically, electrically) via one or more interfaces.
[0080] The processor 202, the memory 204, the controller 206, or the transceiver 208, or various combinations or components thereof may be implemented in hardware (e.g. circuitry) . The hardware may include a processor, a digital signal processor (DSP) , an application-specific integrated circuit (ASIC) , or other programmable logic device, or any combination thereof configured as or otherwise supporting a means for performing the functions described in the present disclosure.
[0081] The processor 202 may include an intelligent hardware device (e.g. a general-purpose processor, a DSP, a CPU, an ASIC, an FPGA, or any combination thereof) . In some implementations, the processor 202 may be configured to operate the memory 204. In some other implementations, the memory 204 may be integrated into the processor 202. The processor 202 may be configured to execute computer-readable instructions stored in the memory 204 to cause the UE 200 to perform various functions of the present disclosure.
[0082] The memory 204 may include volatile or non-volatile memory. The memory 204 may store computer-readable, computer-executable code including instructions when executed by the processor 202 cause the UE 200 to perform various functions described herein. The code may be stored in a non-transitory computer-readable medium such the memory 204 or another type of memory. Computer-readable media includes both non-transitory computer storage media and communication media including any medium that facilitates transfer of a computer program from one place to another. A non-transitory storage medium may be any available medium that may be accessed by a general-purpose or special-purpose computer.
[0083] In some implementations, the processor 202 and the memory 204 coupled with the processor 202 may be configured to cause the UE 200 to perform one or more of the functions described herein (e.g. executing, by the processor 202, instructions stored in the memory 204) . For example, the processor 202 may support wireless communication at the UE 200 in accordance with examples as disclosed with respect to Figure 7. The UE 200 may be configured to support: a means for receiving, from a first A-IoT reader, a first message including information related to a first resource used for D2R transmission; and a means for transmitting a D2R transmission to a second A-IoT reader via the first resource, wherein the D2R transmission from the A-IoT device is forwarded by the second A-IoT reader to the first A-IoT reader.
[0084] The controller 206 may manage input and output signals for the UE 200. The controller 206 may also manage peripherals not integrated into the UE 200. In some implementations, the controller 206 may utilize an operating system such as or other operating systems. In some implementations, the controller 206 may be implemented as part of the processor 202.
[0085] In some implementations, the UE 200 may include at least one transceiver 208. In some other implementations, the UE 200 may have more than one transceiver 208. The transceiver 208 may represent a wireless transceiver. The transceiver 208 may include one or more receiver chains 210, one or more transmitter chains 212, or a combination thereof. The means for receiving abovementioned in the processor 202 or the means for transmitting in the processor 202 may be implemented via at least one transceiver 208.
[0086] A receiver chain 210 may be configured to receive signals (e.g. control information, data, packets) over a wireless medium. For example, the receiver chain 210 may include one or more antennas for receive the signal over the air or wireless medium. The receiver chain 210 may include at least one amplifier (e.g. a low-noise amplifier (LNA) ) configured to amplify the received signal. The receiver chain 210 may include at least one demodulator configured to demodulate the receive signal and obtain the transmitted data by reversing the modulation technique applied during transmission of the signal. The receiver chain 210 may include at least one decoder for decoding the processing the demodulated signal to receive the transmitted data.
[0087] A transmitter chain 212 may be configured to generate and transmit signals (e.g. control information, data, packets) . The transmitter chain 212 may include at least one modulator for modulating data onto a carrier signal, preparing the signal for transmission over a wireless medium. The at least one modulator may be configured to support one or more techniques such as amplitude modulation (AM) , frequency modulation (FM) , or digital modulation schemes like phase-shift keying (PSK) or quadrature amplitude modulation (QAM) . The transmitter chain 212 may also include at least one power amplifier configured to amplify the modulated signal to an appropriate power level suitable for transmission over the wireless medium. The transmitter chain 212 may also include one or more antennas for transmitting the amplified signal into the air or wireless medium.
[0088] Figure 3 illustrates an example of a processor 300 in accordance with aspects of the present disclosure. The processor 300 may be an example of a processor configured to perform various operations in accordance with examples as described herein. The processor 300 may include a controller 302 configured to perform various operations in accordance with examples as described herein. The processor 300 may optionally include at least one memory 304, which may be, for example, an L1 / L2 / L3 cache. Additionally, or alternatively, the processor 300 may optionally include one or more arithmetic-logic units (ALUs) 306. One or more of these components may be in electronic communication or otherwise coupled (e.g. operatively, communicatively, functionally, electronically, electrically) via one or more interfaces (e.g. buses) .
[0089] The processor 300 may be a processor chipset and include a protocol stack (e.g. a software stack) executed by the processor chipset to perform various operations (e.g. receiving, obtaining, retrieving, transmitting, outputting, forwarding, storing, determining, identifying, accessing, writing, reading) in accordance with examples as described herein. The processor chipset may include one or more cores, one or more caches (e.g. memory local to or included in the processor chipset (e.g. the processor 300) or other memory (e.g. random access memory (RAM) , read-only memory (ROM) , dynamic RAM (DRAM) , synchronous dynamic RAM (SDRAM) , static RAM (SRAM) , ferroelectric RAM (FeRAM) , magnetic RAM (MRAM) , resistive RAM (RRAM) , flash memory, phase change memory (PCM) , and others) .
[0090] The controller 302 may be configured to manage and coordinate various operations (e.g. signaling, receiving, obtaining, retrieving, transmitting, outputting, forwarding, storing, determining, identifying, accessing, writing, reading) of the processor 300 to cause the processor 300 to support various operations in accordance with examples as described herein. For example, the controller 302 may operate as a control unit of the processor 300, generating control signals that manage the operation of various components of the processor 300. These control signals include enabling or disabling functional units, selecting data paths, initiating memory access, and coordinating timing of operations.
[0091] The controller 302 may be configured to fetch (e.g. obtain, retrieve, receive) instructions from the memory 304 and determine subsequent instruction (s) to be executed to cause the processor 300 to support various operations in accordance with examples as described herein. The controller 302 may be configured to track memory address of instructions associated with the memory 304. The controller 302 may be configured to decode instructions to determine the operation to be performed and the operands involved. For example, the controller 302 may be configured to interpret the instruction and determine control signals to be output to other components of the processor 300 to cause the processor 300 to support various operations in accordance with examples as described herein. Additionally, or alternatively, the controller 302 may be configured to manage flow of data within the processor 300. The controller 302 may be configured to control transfer of data between registers, arithmetic logic units (ALUs) , and other functional units of the processor 300.
[0092] The memory 304 may include one or more caches (e.g. memory local to or included in the processor 300 or other memory, such RAM, ROM, DRAM, SDRAM, SRAM, MRAM, flash memory, etc. In some implementations, the memory 304 may reside within or on a processor chipset (e.g. local to the processor 300) . In some other implementations, the memory 304 may reside external to the processor chipset (e.g. remote to the processor 300) .
[0093] The memory 304 may store computer-readable, computer-executable code including instructions that, when executed by the processor 300, cause the processor 300 to perform various functions described herein. The code may be stored in a non-transitory computer-readable medium such as system memory or another type of memory. The controller 302 and / or the processor 300 may be configured to execute computer-readable instructions stored in the memory 304 to cause the processor 300 to perform various functions. For example, the processor 300 and / or the controller 302 may be coupled with or to the memory 304, the processor 300, the controller 302, and the memory 304 may be configured to perform various functions described herein. In some examples, the processor 300 may include multiple processors and the memory 304 may include multiple memories. One or more of the multiple processors may be coupled with one or more of the multiple memories, which may, individually or collectively, be configured to perform various functions herein.
[0094] The one or more ALUs 306 may be configured to support various operations in accordance with examples as described herein. In some implementations, the one or more ALUs 306 may reside within or on a processor chipset (e.g. the processor 300) . In some other implementations, the one or more ALUs 306 may reside external to the processor chipset (e.g. the processor 300) . One or more ALUs 306 may perform one or more computations such as addition, subtraction, multiplication, and division on data. For example, one or more ALUs 306 may receive input operands and an operation code, which determines an operation to be executed. One or more ALUs 306 be configured with a variety of logical and arithmetic circuits, including adders, subtractors, shifters, and logic gates, to process and manipulate the data according to the operation. Additionally, or alternatively, the one or more ALUs 306 may support logical operations such as AND, OR, exclusive-OR (XOR) , not-OR (NOR) , and not-AND (NAND) , enabling the one or more ALUs 306 to handle conditional operations, comparisons, and bitwise operations.
[0095] The processor 300 may support wireless communication in accordance with examples as disclosed herein.
[0096] In some implementations, the processor 300 may be configured to support a means for performing operations of a first A-IoT reader as described with respect to Figure 5. The processor 300 may be configured to or operable to support: a means for transmitting, to an A-IoT device, a first message including information related to a first resource used for D2R transmission; and a means for receiving a D2R transmission of the A-IoT device from a second A-IoT reader, wherein the D2R transmission is transmitted from the A-IoT device to the second A-IoT reader via the first resource.
[0097] In some implementations, the processor 300 may be configured to support a means for performing operations of a second A-IoT reader as described with respect to Figure 6. The processor 300 may be configured to or operable to support: a means for receiving a D2R transmission from an A-IoT device via a first resource used for D2R transmission; and a means for transmitting the D2R transmission of the A-IoT device to a first A-IoT reader, wherein information related to the first resource is transmitted by the first A-IoT reader to the A-IoT device.
[0098] In some implementations, the processor 300 may be configured to support a means for performing operations of an A-IoT device as described with respect to Figure 7. The processor 300 may be configured to or operable to support: a means for receiving, from a first A-IoT reader, a first message including information related to a first resource used for D2R transmission; and a means for transmitting a D2R transmission to a second A-IoT reader via the first resource, wherein the D2R transmission from the A-IoT device is forwarded by the second A-IoT reader to the first A-IoT reader.
[0099] It should be appreciated by persons skilled in the art that the components in exemplary processor 300 may be changed, for example, some of the components in exemplary processor 300 may be omitted or modified or new component (s) may be added to exemplary processor 300, without departing from the spirit and scope of the disclosure. For example, in some embodiments, the processor 300 may not include the ALUs 306.
[0100] Figure 4 illustrates an example of a NE 400 in accordance with aspects of the present disclosure. The NE 400 may include a processor 402, a memory 404, a controller 406, and a transceiver 408. The processor 402, the memory 404, the controller 406, or the transceiver 408, or various combinations thereof or various components thereof may be examples of means for performing various aspects of the present disclosure as described herein. These components may be coupled (e.g. operatively, communicatively, functionally, electronically, electrically) via one or more interfaces.
[0101] The processor 402, the memory 404, the controller 406, or the transceiver 408, or various combinations or components thereof may be implemented in hardware (e.g. circuitry) . The hardware may include a processor, a digital signal processor (DSP) , an application-specific integrated circuit (ASIC) , or other programmable logic device, or any combination thereof configured as or otherwise supporting a means for performing the functions described in the present disclosure.
[0102] The processor 402 may include an intelligent hardware device (e.g. a general-purpose processor, a DSP, a CPU, an ASIC, an FPGA, or any combination thereof) . In some implementations, the processor 402 may be configured to operate the memory 404. In some other implementations, the memory 404 may be integrated into the processor 402. The processor 402 may be configured to execute computer-readable instructions stored in the memory 404 to cause the NE 400 to perform various functions of the present disclosure.
[0103] The memory 404 may include volatile or non-volatile memory. The memory 404 may store computer-readable, computer-executable code including instructions when executed by the processor 402 cause the NE 400 to perform various functions described herein. The code may be stored in a non-transitory computer-readable medium such the memory 404 or another type of memory. Computer-readable media includes both non-transitory computer storage media and communication media including any medium that facilitates transfer of a computer program from one place to another. A non-transitory storage medium may be any available medium that may be accessed by a general-purpose or special-purpose computer.
[0104] In some implementations, the processor 402 and the memory 404 coupled with the processor 402 may be configured to cause the NE 400 to perform one or more of the functions described herein (e.g. executing, by the processor 402, instructions stored in the memory 404) . For example, the processor 402 may support wireless communication at the NE 400 in accordance with examples as disclosed herein. For example, the NE 400 may be configured to support a means for performing the operations as described with respect to Figures 5 and 6 as described below.
[0105] In some implementations, the NE 400 may be a first A-IoT reader as described with respect to Figure 5. The NE 400 may be configured to support: a means for transmitting, to an A-IoT device, a first message including information related to a first resource used for D2R transmission; and a means for receiving a D2R transmission of the A-IoT device from a second A-IoT reader, wherein the D2R transmission is transmitted from the A-IoT device to the second A-IoT reader via the first resource.
[0106] In some implementations, the NE 400 may be a second A-IoT reader as described with respect to Figure 6. The NE 400 may be configured to support: a means for receiving a D2R transmission from an A-IoT device via a first resource used for D2R transmission; and a means for transmitting the D2R transmission of the A-IoT device to a first A-IoT reader, wherein information related to the first resource is transmitted by the first A-IoT reader to the A-IoT device.
[0107] The controller 406 may manage input and output signals for the NE 400. The controller 406 may also manage peripherals not integrated into the NE 400. In some implementations, the controller 406 may utilize an operating system such as or other operating systems. In some implementations, the controller 406 may be implemented as part of the processor 402.
[0108] In some implementations, the NE 400 may include at least one transceiver 408. In some other implementations, the NE 400 may have more than one transceiver 408. The transceiver 408 may represent a wireless transceiver. The transceiver 408 may include one or more receiver chains 410, one or more transmitter chains 412, or a combination thereof. The means for receiving or the means for transmitting abovementioned in the processor 402 may be implemented via at least one transceiver 408.
[0109] A receiver chain 410 may be configured to receive signals (e.g. control information, data, packets) over a wireless medium. For example, the receiver chain 410 may include one or more antennas for receive the signal over the air or wireless medium. The receiver chain 410 may include at least one amplifier (e.g. a low-noise amplifier (LNA) ) configured to amplify the received signal. The receiver chain 410 may include at least one demodulator configured to demodulate the receive signal and obtain the transmitted data by reversing the modulation technique applied during transmission of the signal. The receiver chain 410 may include at least one decoder for decoding the processing the demodulated signal to receive the transmitted data.
[0110] A transmitter chain 412 may be configured to generate and transmit signals (e.g. control information, data, packets) . The transmitter chain 412 may include at least one modulator for modulating data onto a carrier signal, preparing the signal for transmission over a wireless medium. The at least one modulator may be configured to support one or more techniques such as amplitude modulation (AM) , frequency modulation (FM) , or digital modulation schemes like phase-shift keying (PSK) or quadrature amplitude modulation (QAM) . The transmitter chain 412 may also include at least one power amplifier configured to amplify the modulated signal to an appropriate power level suitable for transmission over the wireless medium. The transmitter chain 412 may also include one or more antennas for transmitting the amplified signal into the air or wireless medium.
[0111] It should be appreciated by persons skilled in the art that the components in exemplary NE 400 may be changed, for example, some of the components in exemplary NE 400 may be omitted or modified or new component (s) may be added to exemplary NE 400, without departing from the spirit and scope of the disclosure. For example, in some embodiments, the NE 400 may not include the controller 406.
[0112] Figure 5 illustrates a flowchart related to bidirectional A-IoT communication in accordance with aspects of the present disclosure. The operations of the method may be implemented by an A-IoT reader (denoted as a first A-IoT reader, e.g. R1 as shown in Figures 8-11) as described herein. In some implementations, the first A-IoT reader may execute a set of instructions to control the function elements of the first A-IoT reader to perform the described functions. In some implementations, aspects of operations 502 and 504 may be performed by NE 400 as described with reference to Figure 4. Each of 502 and 504 may be performed in accordance with examples as described herein. Specific examples are described in the embodiments of Figures 8-11 as follows.
[0113] At 502, the method may include transmitting, by a first A-IoT reader to an A-IoT device (e.g. D as shown in Figures 8-11) , a message (denoted as a first message) including information related to a resource used for D2R transmission (denoted as a first resource) . For example, the first message is a paging message, MSG2, or MSG4 transmitted from R1 to D as shown in Figures 8-11.
[0114] At 504, the method may include receiving a D2R transmission of the A-IoT device by the first A-IoT reader from another A-IoT reader (denoted as a second A-IoT reader, e.g. R2 as shown in Figures 8-11) . The D2R transmission may be transmitted from the A-IoT device to the second A-IoT reader via the first resource. The second A-IoT reader is responsible for forwarding the D2R transmission from the A-IoT device to the first A-IoT reader.
[0115] In some implementations, the first A-IoT reader may receive the information related to the first resource from the second A-IoT reader, e.g. via a resource response message in the embodiments of Figures 8 and 9.
[0116] In some other implementations, the first A-IoT reader may receive a resource set or resource configuration information from the second A-IoT reader (e.g. via an interface setup response message in the embodiments of Figures 10 and 11) , and determine the first resource based on the resource set or the resource configuration information.
[0117] In some implementations, the first A-IoT reader may transmit a request (e.g. an interface setup request in the embodiments of Figures 10 and 11) to the second A-IoT reader. The request may include information (e.g. an indicator) for indicating that the request is associated with one or more A-IoT devices.
[0118] In some implementations, the first A-IoT reader may transmit the information related to the first resource to the second A-IoT reader, e.g. in the embodiments of Figures 10 and 11.
[0119] In some implementations of the method, the first resource is one of the following:
[0120] (1) a common resource used for MSG1 transmission of 3-step CBRA;
[0121] (2) a common resource used for MSG1 transmission of 2-step CBRA; or
[0122] (3) a dedicated resource used for MSG1 transmission of CFRA. The MSG1 transmission is a first (or initial) D2R transmission from the A-IoT device during random access. For example, the first D2R transmission from the A-IoT device includes an ID of the A-IoT device.
[0123] In these implementations, the common resource also refers to shared resource.
[0124] In these implementations, the first message is a paging message. In some embodiments, the paging message includes at least one of the following:
[0125] (1) ID information of one or more A-IoT devices including the A-IoT device;
[0126] (2) an A-IoT group ID;
[0127] (3) a type of random access, e.g. which may include 3-step CBRA, 2-step CBRA or CFRA; or
[0128] (4) information (denoted as a first resource) for indicating that a command response will be sent by the A-IoT device. For example, the first indicator is a type of a command, and the command may be a read command, a write command or a disable command.
[0129] In some other implementations of the method, the first resource is a dedicated resource used for MSG3 transmission of 3-step CBRA, and the first message is MSG2 of 3-step CBRA. The MSG3 transmission is a second D2R transmission (i.e. a D2R transmission subsequent to the initial D2R transmission) from the A-IoT device during random access. The MSG2 is a first (or initial) R2D transmission to the A-IoT device during random access. In some embodiments, the second D2R transmission from the A-IoT device or the first R2D transmission to the A-IoT device includes an ID of the A-IoT device.
[0130] In some additional implementations of the method, the first resource is a dedicated resource used for a command response transmission, and the first message is one of the following:
[0131] (1) MSG4 of 3-step CBRA, wherein the MSG4 is a second R2D transmission (i.e. a R2D transmission subsequent to the initial R2D transmission) to the A-IoT device during random access; for example, the second R2D transmission to the A-IoT device includes an ID of the A-IoT device;
[0132] (2) MSG2 of 2-step CBRA; or
[0133] (3) MSG2 of CFRA.
[0134] In some implementations, the first A-IoT reader may transmit another message (denoted as a second message, e.g. a resource request in the embodiments of Figures 8 and 9) to the second A-IoT reader. The second message may include at least one of the following:
[0135] (1) ID information of one or more A-IoT devices including the A-IoT device;
[0136] (2) an A-IoT group ID;
[0137] (3) a type of random access that can be used by the one or more A-IoT devices, e.g. the type of random access may include 3-step CBRA, 2-step CBRA or CFRA;
[0138] (4) information for indicating that a command response will be sent by the one or more A-IoT devices; or
[0139] (5) an approximate number of the one or more A-IoT devices.
[0140] In some implementations, the first A-IoT reader may receive information related to the second A-IoT reader (e.g. via an inventory request) from a CN or a BS. The information related to the second A-IoT reader (denoted as R2 information) may include at least one of the following:
[0141] (1) an ID of the second A-IoT reader, e.g. if the second A-IoT reader is a BS, the ID is a node ID of the BS, or if the second A-IoT reader is a UE, the ID is a UE ID; or
[0142] (2) a certain area from which the D2R transmission of the A-IoT device is to be received (e.g. a scope of receiving A-IoT reader) .
[0143] In some implementations, the first A-IoT reader may receive, from the second A-IoT reader, a cause value indicating no resource available in the second A-IoT reader, e.g. via a resource failure message in the embodiments of Figures 8 and 9. The cause value may be further associated with an ID of the A-IoT device.
[0144] In some implementations, the first A-IoT reader may start a timer (denoted as a first timer) , e.g. in the embodiments of Figures 8 and 10. If no response is received from the A-IoT device via the second A-IoT reader before the first timer expires or if no response is received from at least a threshold of all A-IoT devices via the second A-IoT reader before the first timer expires, the first A-IoT reader may consider that the A-IoT device communication is failed.
[0145] In some implementations, the first A-IoT reader may transmit a threshold to the second A-IoT reader. The threshold may be used by the second A-IoT reader to determine whether the A-IoT communication is successfully completed based on the threshold.
[0146] In some implementations, the first A-IoT reader may receive a third message (denoted as a third message, e.g. a reader notification or a device communication failure in the embodiments of Figures 8-11) from the second A-IoT reader. The third message may include at least one of the following:
[0147] (1) a proximity location of the A-IoT device;
[0148] (2) an energy status report of the A-IoT device; or
[0149] (3) a cause value of a communication failure of the A-IoT device. For instance, the cause value includes one of the following:
[0150] a) no response is received from the A-IoT device, e.g. R2 doesn't receive the D2R transmission from the A-IoT device;
[0151] b) the A-IoT device is far, e.g. the proximity location of the A-IoT device is far;
[0152] c) no response is received from the A-IoT device due to the second A-IoT reader moving, e.g. R2 moves and doesn't receive the D2R transmission from the A-IoT device; or
[0153] d) no response is received from the A-IoT device due to low energy of the A-IoT device, e.g. the A-IoT device is without enough energy to send the D2R transmission.
[0154] Figure 6 illustrates another flowchart related to bidirectional A-IoT communication in accordance with aspects of the present disclosure. The operations of the method may be implemented by an A-IoT reader (denoted as a second A-IoT reader e.g. R2 as shown in Figures 8-11) as described herein. In some implementations, the second A-IoT reader may execute a set of instructions to control the function elements of the second A-IoT reader to perform the described functions. In some implementations, aspects of operations 602 and 604 may be performed by NE 400 as described with reference to Figure 4. Each of 602 and 604 may be performed in accordance with examples as described herein. Specific examples are described in the embodiments of Figures 8-11 as follows.
[0155] At 602, the method may include receiving a D2R transmission by a second A-IoT reader from an A-IoT device via a resource used for D2R transmission (e.g. the first resource in the embodiments of Figure 5) . This resource used for D2R transmission may include the same or similar elements as those in the first resource as described in the embodiments of Figure 5. For example, this resource is one of the following:
[0156] (1) a common resource used for MSG1 transmission of 3-step CBRA;
[0157] (2) a common resource used for MSG1 transmission of 2-step CBRA;
[0158] (3) a dedicated resource used for MSG1 transmission of CFRA;
[0159] (4) a dedicated resource used for MSG3 transmission of 3-step CBRA; or
[0160] (5) a dedicated resource used for a command response transmission, wherein the MSG1 transmission is a first D2R transmission from the A-IoT device during random acces. The first D2R transmission may include an ID of the A-IoT device. The MSG3 transmission is a second D2R transmission from the A-IoT device during random access. The second D2R transmission may include an ID of the A-IoT device.
[0161] At 604, the method may include transmitting the D2R transmission of the A-IoT device by the second A-IoT reader to another A-IoT reader (e.g. the first A-IoT reader as described in the embodiments of Figure 5) . Information related to the resource used for D2R transmission may be transmitted by the first A-IoT reader to the A-IoT device.
[0162] In some implementations, the second A-IoT reader may transmit the information related to the first resource to the first A-IoT reader, e.g. via a resource response message in the embodiments of Figures 8 and 9.
[0163] In some implementations, the second A-IoT reader may transmit a resource set or resource configuration information to the first A-IoT reader, e.g. via an interface setup response message in the embodiments of Figures 10 and 11. The resource set or the resource configuration information may be used by the first A-IoT reader to determine the first resource.
[0164] In some implementations, the second A-IoT reader may receive a request from the first A-IoT reader, e.g. via an interface setup request message in the embodiments of Figures 10 and 11. The request includes information (e.g. an indicator) for indicating that the request is associated with one or more A-IoT devices.
[0165] In some implementations, the second A-IoT reader may receive the information related to the first resource from the first A-IoT reader, e.g. in the embodiments of Figures 10 and 11.
[0166] In some implementations, the second A-IoT reader may receive a message (e.g. the second message in the embodiments of Figure 5) from the first A-IoT reader. The message may include the same or similar elements as those in the second message as described in the embodiments of Figure 5. For instance, the message is a resource request message in the embodiments of Figures 8 and 9.
[0167] In some implementations, the second A-IoT reader may transmit, to the first A-IoT reader, a cause value indicating no resource available in the second A-IoT reader, , e.g. via a resource failure message in the embodiments of Figures 8 and 9. The cause value may be further associated with an ID of the A-IoT device.
[0168] In some implementations, the second A-IoT reader may receive a threshold from the first A-IoT reader; and determine whether the A-IoT communication is successfully completed based on the threshold.
[0169] In some implementations, the second A-IoT reader may start a timer (denoted as a second timer) . If no response is received from the A-IoT device before the second timer expires or if no response is received from at least a threshold of all A-IoT devices before the second timer expires, the second A-IoT reader may consider that the A-IoT device communication is failed.
[0170] In some implementations, the second A-IoT reader may transmit a message (e.g. the third message in the embodiments of Figure 5) to the first A-IoT reader. The message may include the same or similar elements as those in the third message as described in the embodiments of Figure 5. For instance, the message may include at least one of the following: (1) a proximity location of the A-IoT device; (2) an energy status report of the A-IoT device; or (3) a cause value of a communication failure of the A-IoT device.
[0171] Figure 7 illustrates an additional flowchart related to bidirectional A-IoT communication in accordance with aspects of the present disclosure. The operations of the method may be implemented by an A-IoT device (e.g. D as shown in Figures 8-11) as described herein. In some implementations, the A-IoT device may execute a set of instructions to control the function elements of the A-IoT device to perform the described functions. In some implementations, aspects of operations 702 and 704 may be performed by UE 200 as described with reference to Figure 2. Each of 702 and 704 may be performed in accordance with examples as described herein. Specific examples are described in the embodiments of Figures 8-11 as follows.
[0172] At 702, the method may include receiving, by an A-IoT device from an A-IoT reader (e.g. the first A-IoT reader as described in the embodiments of Figure 5) , a message (e.g. the first message as described in the embodiments of Figure 5) including information related to a resource used for D2R transmission (e.g. the first resource as described in the embodiments of Figure 5) . This resource used for D2R transmission may include the same or similar elements as those in the first resource as described in the embodiments of Figure 5. This message may include the same or similar elements as those in the first message as described in the embodiments of Figure 5. For example, the message is a paging message, MSG2, or MSG4 transmitted from R1 to D as shown in Figures 8-11.
[0173] At 704, the method may include transmitting a D2R transmission by the A-IoT device to another A-IoT reader (e.g. the second A-IoT reader as described in the embodiments of Figure 5) via the resource used for D2R transmission, wherein the D2R transmission from the A-IoT device is forwarded by the another A-IoT reader to the A-IoT reader.
[0174] It should be noted that the method described in any of Figures 5-7 describes possible implementations, and that the operations and the steps may be rearranged or otherwise eliminated or modified and that other implementations are possible, without departing from the spirit and scope of the disclosure.
[0175] Figures 8-11 illustrate schematic diagrams of bidirectional A-IoT communication in accordance with aspects of the present disclosure. Details described in all other embodiments of the present disclosure are applicable for the embodiments shown in Figures 8-11.
[0176] In the embodiments of Figures 8-11, R1 is an A-IoT reader responsible for R2D transmission to the A-IoT device, R2 is an A-IoT reader responsible for D2R transmission from the A-IoT device, D is an A-IoT device, and CN is an access and mobility management function (AMF) or an A-IoT management function (AIMF) . The AIMF includes the following functionalities:
[0177] - A-IoT device data processing, e.g. gathering the raw data of the A-IoT device, filtering and cleaning the raw data, and putting the raw data in a usable format for processing.
[0178] - Device management, e.g. monitoring, managing, control and coordination of the A-IoT devices and / or A-IoT readers, where the A-IoT reader is a device that reads and writes data to A-IoT devices using radio frequency wave. For example, the AIMF initiates inventory procedure to identify individual A-IoT devices, command procedure to communication with an identified A-IoT device to perform an operation of the A-IoT device, such as reading (read data from the A-IoT device) , writing (write data to the A-IoT device) , or disabling (disable the A-IoT device temporarily or permanently) , or A- IoT reader configuration procedure, such as the configuration of the radio frequency receiver sensitivity, or radio frequency transmit power.
[0179] - Service management, e.g. receiving queries from the external entities, and filtering the results from the data retrieved from the A-IoT devices and / or A-IoT readers.
[0180] In some embodiments of Figure 8 (denoted as Embodiment 1) , R1 decides both a type of random access for an A-IoT device (i.e. D) and a failure of A-IoT device communication, and R2 determines a resource used for D2R transmission. In Embodiment 1, operations 801 to 816 may be performed.
[0181] Embodiment 1
[0182] At 801, CN may send an inventory request to R1, to find a single A-IoT device, multiple A-IoT devices, a group of A-IoT devices or all A-IoT devices. In some embodiments, the CN may send other messages different from the inventory request to R1 at 801.
[0183] For example, the inventory request may include information of the one or more A-IoT devices, such as ID information of the one or more A-IoT devices, or an A-IoT device group ID.
[0184] In some embodiments, the inventory request may include information related to R2 (denoted as R2 information) . The R2 information may be used by R1 to determine which A-IoT reader will receive a D2R transmission of the one or more A-IoT devices. A D2R transmission of an A-IoT device is the transmission from the A-IoT device to the A-IoT reader.
[0185] - In one example, the R2 information is a node ID of R2 (if R2 is a BS or a NE) , or a UE ID of R2 (if R2 is a UE) .
[0186] - In another example, the R2 information is a scope of receiving A-IoT reader, where the scope of receiving A-IoT reader is a certain area from which a D2R transmission of one or more A-IoT devices is to be received. For example, the scope of receiving A-IoT reader includes multiple node IDs, where each node ID is associated with an A-IoT reader. For example, the scope of receiving A-IoT reader includes multiple UE IDs, where each UE ID is associated with an A-IoT reader.
[0187] In some cases, the R2 information is pre-configured at R1, e.g. by means of an operation administration and maintenance (OAM) . That is, in these cases, the inventory request doesn't need to include the R2 information.
[0188] In some cases, if R1 is a UE, the R2 information is received from the BS, e.g. via an RRC reconfiguration message. In these cases, the inventory request doesn't need to include the R2 information.
[0189] At 802, R1 may send an inventory response to CN, to indicate that the inventory is successfully initiated.
[0190] At 803, R1 may send a resource request to R2, to obtain a resource used for D2R transmission by the one or more A-IoT devices, e.g. including D as shown in Figure 8.
[0191] In some embodiments, the resource request may include one or more A-IoT device IDs, where each A-IoT device ID is associated with an A-IoT device.
[0192] - In one example, the A-IoT device ID is an access stratum temporary ID used to indicate that the data transmission or radio resource assignment is targeted to a specific A-IoT device. In this case, the A-IoT device ID may be allocated by R1.
[0193] - In another example, the A-IoT device ID is the same as the A-IoT device identification received from CN at 801.
[0194] - In another example, the A-IoT device ID is a temporary ID used to identify the A-IoT device between R1 and R2. For example, the A-IoT device ID is a UE XnAP ID allocated by R1.
[0195] In some other embodiments, the resource request may include an A-IoT group ID, where an A-IoT group contains a group of A-IoT devices.
[0196] In some additional embodiments, the resource request may include the type of random access, which indicates the random access procedure used for the A-IoT device to access the network for data transmission. For example, the type of random access includes one of the following:
[0197] (1) 3-step CBRA, where the random access procedure includes: 1) an MSG1 sent from the A-IoT device to the A-IoT reader, and the MSG1 includes a random ID generated by the A-IoT device, 2) an MSG2 sent from the A-IoT reader to the A-IoT device in order to respond with the successfully received random ID, and 3) an MSG3 sent from the A-IoT device to the A-IoT reader carrying upper layer data (e.g. upper layer A-IoT device identification) . The random access procedure may further include an MSG4 sent from the A-IoT reader to the A-IoT device carrying the command information.
[0198] (2) 2-step CBRA, where the random access procedure includes an MSG1 sent from the A-IoT device to the A-IoT reader via a common resource, and the MSG1 includes upper layer data and a random ID generated by the A-IoT device. The random access procedure may further include an MSG2 sent from the A-IoT reader to the A-IoT device to respond with the successfully received random ID.
[0199] (3) CFRA, where the random access procedure includes an MSG1 sent from the A-IoT device to the A-IoT reader via a dedicated resource, and the MSG1 includes upper layer data. The random access procedure may further include an MSG2 sent from the A-IoT reader to the A-IoT device to respond with the successfully received MSG1.
[0200] In some additional embodiments, the resource request may include an indicator indicating that a command response will be sent by the A-IoT device. For example, the indicator is the type of command, e.g. read, write, disable.
[0201] - In some cases, the type of random access and / or the indicator are associated with an A-IoT device ID. In these cases, each A-IoT device may have its own type of random access and / or indicator.
[0202] - In some cases, the type of random access and / or the indicator are associated with multiple A-IoT device IDs. In these cases, the multiple A-IoT devices may have the same type of random access and / or indicator.
[0203] - In some cases, the type of random access and / or the indicator are associated with an A-IoT group ID. In these cases, the A-IoT devices within the A-IoT group may have the same type of random access and / or indicator.
[0204] After 803, R2 may send a resource response (at 804A, which is optional) or a resource failure message (at 804B, which is optional) to R1, to indicate the resource allocation result.
[0205] In some cases, if R2 successfully allocate the resource for one or more A-IoT devices, it may send a resource response to R1, where the resource response includes the resource used for D2R transmission by the A-IoT device.
[0206] - In one example, the resource is a common resource used for MSG1 transmission of 3-step CBRA by multiple A-IoT devices. For example, the common resource is a set of access occasions for multiple A-IoT devices, where the access occasion is an opportunity of time and / or frequency resource for the A-IoT device to transmit the MSG1 of 3-step CBRA.
[0207] - In another example, the resource is a common resource used for MSG1 transmission of 2-step CBRA by multiple A-IoT devices. For example, the common resource is a set of access occasions for multiple A-IoT devices, where the access occasion is an opportunity of time and / or frequency resource for the A-IoT device to transmit the MSG1 of 2-step CBRA.
[0208] - In another example, the resource is a dedicated resource used for MSG3 transmission of 3-step CBRA by one A-IoT device. For example, the resource is a time and / or frequency resource for the A-IoT device to transmit the MSG3 of 3-step CBRA.
[0209] - In another example, the resource is a dedicated resource used for MSG1 transmission of CFRA by one A-IoT device. For example, the resource is a time and / or frequency resource for the A-IoT device to transmit the MSG1 of CFRA.
[0210] - In another example, the resource is a dedicated resource used for command response transmission by one A-IoT device. For example, the resource is a time and / or frequency resource for the A-IoT device to transmit the command response.
[0211] In some cases, if the resource is a dedicated resource and there are multiple A-IoT device IDs received in the resource request at 803, the resource should be associated with one A-IoT device ID.
[0212] In some cases, if the resource is a common resource and there are multiple A-IoT device IDs received in the resource request at 803, the resource may be associated with some A-IoT device IDs within the received multiple A-IoT device IDs, indicating that the resource is common for the given A-IoT devices. Otherwise, if the resource is not associated with any A-IoT device ID, it indicates that the resource is common for all A-IoT devices received in the resource request.
[0213] In some cases, if the A-IoT group ID is received in the resource request at 803, the resource is a common resource for all A-IoT devices.
[0214] In some cases, if R2 cannot allocate any resource for one or more A-IoT devices received in the resource request at 803, the resource response includes a list of A-IoT device IDs indicating that the corresponding A-IoT devices are failed to allocate resource by R2. In addition, the resource response may further include a cause value indicating the reason of resource allocation failure, e.g. no resource available.
[0215] In some cases, if R2 cannot allocate any resource for all A-IoT devices received in the resource request at 803, R2 may send a resource failure message to R1. The resource failure message may include a cause value indicating the reason of resource allocation failure, e.g. no resource available.
[0216] After 804A or 804B, R1 may send a paging message to the A-IoT device (e.g. D) (at 805B) and start a timer (at 805A) , e.g. a first timer.
[0217] In some embodiments, the paging message includes one or more A-IoT device IDs to identify one or more A-IoT devices, or an A-IoT group ID to identify a group of A-IoT devices.
[0218] In some embodiments, the paging message may include the resource used for MSG1 transmission by the A-IoT device, where the resource is received at 804A. For example, the resource may be a common resource used for MSG1 transmission of 3-step CBRA, a common resource used for MSG1 transmission of 2-step CBRA, or a dedicated resource used for MSG1 transmission of CFRA.
[0219] In some embodiments, the paging message may further include an indicator indicating the type of random access, e.g. 3-step CBRA, 2-step CBRA, or CFRA.
[0220] In some embodiments, the paging message may further include an indicator indicating that a command response will be sent by the A-IoT device (s) . For example, the indicator is the type of command, e.g. read, write, disable.
[0221] - In some cases, if there is no D2R transmission of the A-IoT device from R2 before the first timer (which is started at 805A) expires in R1, R1 should consider that the A-IoT device communication is failed.
[0222] - In some cases, if there is no enough D2R transmissions from R2 for at least one threshold of all A-IoT devices before the first timer expires in R1, R1 should consider that the A-IoT device communication is failed. Otherwise, if R1 receives one or more D2R transmissions from R2 for at least one threshold of all A-IoT devices before the first timer expires, R1 should consider that the A-IoT device communication is successfully completed. For example, the threshold is 99%, and if R1 receives one or more D2R transmissions from R2 for 99%of all A-IoT devices before the first timer expires, R1 should consider that the A-IoT device communication is successfully completed.
[0223] In Embodiment 1, operations 806 to 811 are for 3-step CBRA, while operations 812 to 814 are for 2-step CBRA or CFRA. In some embodiments, only operations 806 to 811 for 3-step CBRA are performed. In some other embodiments, only operations 812 to 814 for 2-step CBRA are performed. In some additional embodiments, only operations 812 to 814 for CFRA are performed.
[0224] The following operations 806 to 811 are for 3-step CBRA, and they are not needed for 2-step CBRA or CFRA.
[0225] At 806, the A-IoT device (i.. D) may select a resource from the received common resource used for MSG1 transmission of 3-step CBRA and send an MSG1 to R2 via the selected resource.
[0226] For example, the MSG1 may include a random ID generated by the A-IoT device. The MSG1 may include the A-IoT device ID to identify the A-IoT device.
[0227] At 807, R2 may forward the MSG1 to R1.
[0228] At 808, R1 may send an MSG2 to the A-IoT device to respond with the successfully received random ID.
[0229] For example, the MSG2 may include the A-IoT device ID to identify the A-IoT device. The MSG2 may include the dedicated resource used for MSG3 transmission by the A-IoT device, where the dedicated resource is received at 804A.
[0230] At 809, the A-IoT device may send an MSG3 to R2 via the dedicated resource received at 808.
[0231] For example, the MSG3 includes upper layer data generated by the A-IoT device. The MSG3 may include the A-IoT device ID to identify the A-IoT device.
[0232] At 810, R2 may forward the MSG3 to R1.
[0233] At 811 (which is optional) , R1 may send an MSG4 to the A-IoT device carrying the command information.
[0234] In some embodiments, the MSG4 may include the A-IoT device ID to identify the A-IoT device. The MSG4 may include the dedicated resource used for command response transmission by the A-IoT device. For example, the dedicated resource is received in at 804. For example, R1 may request R2 to provide the dedicated resource used for command response transmission by the A-IoT device, and R2 may provide the resource by performing operations 803 and 804 (i.e. 804A or 804B) again.
[0235] The following operations 812 to 814 are for 2-step CBRA or CFRA, and they are not needed for 3-step CBRA.
[0236] At 812, the A-IoT device may send an MSG1 to R2.
[0237] In some embodiments, the MSG1 may include the A-IoT device ID to identify the A-IoT device.
[0238] - In one example, if the random access is 2-step CBRA, the A-IoT device selects a resource from the received common resource used for MSG1 transmission of 2-step CBRA and sends the MSG1 to R2 via the selected resource. The MSG1 includes upper layer data and a random ID generated by the A-IoT device.
[0239] - In another example, if the random access is CFRA, the A-IoT device sends the MSG1 to R2 via the dedicated resource used for MSG1 transmission of CFRA, where the dedicated resource is received at 804A. The MSG1 includes upper layer data.
[0240] At 813, R2 may forward the MSG1 to R1.
[0241] At 814 (which is optional) , R1 may send an MSG2 to the A-IoT device.
[0242] In some embodiments, the MSG2 may include the A-IoT device ID to identify the A-IoT device. The MSG2 may include the dedicated resource used for command response transmission by the A-IoT device, where the dedicated resource is received at 804A.
[0243] - In one example, if the random access is 2-step CBRA, the MSG2 is sent by R1 to respond with the successfully received random ID.
[0244] - In another example, if the random access is CFRA, the MSG2 is sent by R1 to respond with the successfully received MSG1.
[0245] At 815, R1 may send an inventory report to CN including the inventory results towards the A-IoT device. The inventory result may include one or multiple A-IoT device IDs.
[0246] At 816 (which is optional) , R2 may send a reader notification to R1, to transfer the A-IoT device related information.
[0247] - In one example, if R2 determines the location of the A-IoT device is far (e.g. not near) , R2 sends the reader notification to R1 including the proximity location of the A-IoT device.
[0248] - In another example, if R2 receives the energy status report from the A-IoT device, R2 sends the reader notification to R1 including the energy status report of the A-IoT device.
[0249] In Embodiment 1, the operation 816 is optional, and it can be performed by R2 at anytime, e.g. before any previous operation. For example, the operation 816 can be performed by R2 before the operation 806.
[0250] In some embodiments of Figure 9 (denoted as Embodiment 2) , R1 decides a type of random access for the A-IoT device, while R2 determines a failure of A-IoT device communication, and R2 determines a resource used for D2R transmission. In Embodiment 2, operations 901 to 918 may be performed.
[0251] Embodiment 2
[0252] Operation 901 in Embodiment 2 is the same as operation 801 in Embodiment 1.
[0253] Operation 902 in Embodiment 2 is the same as operation 802 in Embodiment 1.
[0254] Operation 903 in Embodiment 2 is the same as operation 803 in Embodiment 1.
[0255] Operations 904A and 904B in Embodiment 2 are the same as operations 804A and 804B in Embodiment 1, respectively.
[0256] At 905, R1 may send a paging message to the A-IoT device (i.e. D) . The detailed descriptions of the paging message are the same as those of the paging message defined in operation 805B in Embodiment 1.
[0257] At 906, R1 may send an initial triggering notification to R2, to indicate the initiation of paging to the A-IoT device.
[0258] In some embodiments, the initial triggering notification may include one or more A-IoT device IDs to identify one or more A-IoT devices, or an A-IoT group ID to identify a group of A-IoT devices.
[0259] In some embodiments, the initial triggering notification may include the type of random access by the A-IoT device. The detailed descriptions of the type of random access are the same as those defined in operation 803 in Embodiment 1.
[0260] In some embodiments, the initial triggering notification may include a threshold, which is used by R2 to determine whether the A-IoT communication is successfully completed.
[0261] In some embodiments, the initial triggering notification may include the time to wait, which indicates the maximum allowed waiting times of receiving D2R transmission from the A-IoT device (s) .
[0262] - In one example, the time to wait indicates the maximum allowed waiting times of receiving MSG1 transmission from the A-IoT device (s) , for 3-step CBRA, 2-step CBRA or CFRA.
[0263] - In another example, the time to wait indicates the maximum allowed waiting times of receiving MSG3 transmission from the A-IoT device (s) , for 3-step CBRA.
[0264] - In another example, the time to wait indicates the maximum allowed waiting times of receiving command response transmission from the A-IoT device (s) for 3-step CBRA, 2-step CBRA or CFRA.
[0265] At 907, R2 may start a timer, e.g. a second timer.
[0266] The second timer may be used to by R2 to determine if the A-IoT device communication is failed.
[0267] - In one example, if there is no MSG3 of 3-step CBRA from the A-IoT device (s) before the second timer expires, R2 should consider that the A-IoT device communication is failed.
[0268] - In another example, if there is no MSG1 of 3-step CBRA, 2-step CBRA or CFRA from the A-IoT device (s) before the second timer expires, R2 should consider that the A-IoT device communication is failed.
[0269] - In another example, if there is no command response transmission by the A-IoT device (s) for 3-step CBRA, 2-step CBRA or CFRA, R2 should consider that the A-IoT device communication is failed.
[0270] - In another example, if there is no enough D2R transmission for at least the threshold of all A-IoT devices before the second timer expires, R2 should consider the A-IoT device communication is failed. Otherwise, if there is enough D2R transmissions for at least the threshold of all A-IoT devices before the second timer expires, R2 should consider the A-IoT device communication is successfully completed. The threshold may be received at 906 or determined by R2 itself.
[0271] In some cases, the value of the second timer is determined by R2 itself.
[0272] In some cases, the value of the second timer is the time to wait received at 906.
[0273] If R2 determines the A-IoT device communication is failed, it performs operation 918.
[0274] The following operations 908 to 913 are for 3-step CBRA, while operations 914 to 916 are for 2-step CBRA or CFRA.
[0275] Operations 908 in Embodiment 2 is the same as operation 806 in Embodiment 1.
[0276] Operations 909 in Embodiment 2 is the same as operation 807 in Embodiment 1.
[0277] Operations 910 in Embodiment 2 is the same as operation 808 in Embodiment 1.
[0278] Operations 911 in Embodiment 2 is the same as operation 809 in Embodiment 1.
[0279] Operations 912 in Embodiment 2 is the same as operation 810 in Embodiment 1.
[0280] Operations 913 in Embodiment 2 is the same as operation 811 in Embodiment 1.
[0281] The operations 908 to 913 are for 3-step CBRA, and they are not needed for 2-step CBRA or CFRA.
[0282] Operations 914 in Embodiment 2 is the same as operation 812 in Embodiment 1.
[0283] Operations 915 in Embodiment 2 is the same as operation 813 in Embodiment 1.
[0284] Operations 916 in Embodiment 2 is the same as operation 814 in Embodiment 1.
[0285] The operations 914 to 916 are for 2-step CBRA or CFRA, and they are not needed for 3-step CBRA.
[0286] Operations 917 in Embodiment 2 is the same as operation 815 in Embodiment 1.
[0287] At 918 (which is optional) , R2 may send a device communication failure message to R1, including a cause value indicating the cause of A-IoT device communication failure.
[0288] - In one example, the cause value is "No response from the A-IoT device" , which indicates that R2 doesn't receive the D2R transmission (e.g. MSG1 of 3-step CBRA, 2-step CBRA or CFRA, or the MSG3 of 3-step CBRA) from the A-IoT device, or R2 doesn't receive enough D2R transmission for at least the threshold of all A-IoT device.
[0289] - In another example, the cause value is "A-IoT device is FAR, " which indicates that the proximity location of the A-IoT device is far (e.g. not near) .
[0290] - In another example, the cause value is "No response from the A-IoT device due to a reader moving, " which indicates that R2 moves and doesn't receive the D2R transmission (e.g. MSG1 of 3-step CBRA, 2-step CBRA or CFRA, or the MSG3 of 3-step CBRA) , from the A-IoT device.
[0291] - In another example, the cause value is "No response from the A-IoT device due to low energy, " which indicates that the A-IoT device is without enough energy to send the D2R transmission (e.g. MSG1 of 3-step CBRA, 2-step CBRA or CFRA, or the MSG3 of 3-step CBRA) .
[0292] In Embodiment 2, the operation 918 is optional, and it can be performed by R2 at anytime, e.g. before any previous operation. For example, the operation 918 can be performed by R2 before the operation 908.
[0293] In some embodiments of Figure 8 (denoted as Embodiment 3) , R2 decides the type of random access for the A-IoT device while R1 determines the failure of A-IoT device communication, and R2 determines the resource used for D2R transmission. In Embodiment 3, operations 801 to 816 may be performed.
[0294] Embodiment 3
[0295] Operation 801 in Embodiment 3 is the same as operation 801 in Embodiment 1.
[0296] Operation 802 in Embodiment 3 is the same as operation 802 in Embodiment 1.
[0297] At 803, R1 may send a resource request to R2, to obtain a resource used for D2R signal transmission by the A-IoT device.
[0298] In some embodiments, the resource request may include one or more A-IoT device IDs, where each A-IoT device ID is associated with an A-IoT device.
[0299] - In one example, the A-IoT device ID is an access stratum temporary ID used to indicate that the data transmission or radio resource assignment is targeted to a specific A-IoT device. In this case, the A-IoT device ID may be allocated by R1.
[0300] - In another example, the A-IoT device ID is the same as the A-IoT device identification received from CN at 801.
[0301] - In another example, the A-IoT device ID is a temporary ID used to identify the A-IoT device between R1 and R2. For example, the A-IoT device ID is a UE XnAP ID allocated by R1.
[0302] In some embodiments, the resource request may include an A-IoT group ID, where an A-IoT group contains a group of A-IoT devices.
[0303] In some embodiments, the resource request may include an indicator indicating that a command response will be sent by the A-IoT device. For example, the indicator is the type of command, e.g. read, write, disable.
[0304] In some embodiments, the resource request may include an approximate number of A-IoT devices, which is to be used by R2 to determine the type of random access of the A-IoT device.
[0305] After 803, R2 may send a resource response (at 804A, which is optional) or a resource failure message (at 804B, which is optional) to R1, to indicate the resource allocation result.
[0306] In some cases, if R2 successfully allocate resource for one or more A-IoT devices, it may send a resource response to R1, where the resource response includes the resource used for D2R transmission by the A-IoT device. The detailed descriptions of the resource used for D2R transmission by the A-IoT device are the same as those defined in operation 804A in Embodiment 1.
[0307] In some embodiments, the resource response may include the type of random access of the A-IoT device. The detailed descriptions of the type of random access are the same as those defined in operation 803 in Embodiment 1.
[0308] - In one example, the type of random access is associated with one or more A-IoT device IDs, indicating that the corresponding one or more A-IoT devices are with the same type of random access.
[0309] - In another example, the type of random access is associated with the A-IoT group ID, indicating that the A-IoT devices within the group are with the same type of random access.
[0310] - In another example, the type of random access is not associated with any A-IoT device ID, indicating that all the A-IoT devices received at 803 are with the same type of random access.
[0311] In some cases, if R2 cannot allocate resource for one or more A-IoT devices received in the resource request at 803, the resource response includes a list of A-IoT device IDs indicating the corresponding A-IoT devices are failed to allocate resource by R2. In addition, the resource response may further include a cause value indicating the reason of resource allocation failure, e.g. no resource available.
[0312] In some cases, if R2 cannot allocate resource for all A-IoT devices received in the resource request at 803, R2 may send a resource failure message to R1. The resource failure message may include a cause value indicating the reason of resource allocation failure, e.g. no resource available.
[0313] Operation 805 in Embodiment 3 is the same as operation 805 in Embodiment 1.
[0314] In Embodiment 3, operations 806 to 811 are for 3-step CBRA, while operations 812 to 814 are for 2-step CBRA or CFRA.
[0315] Operation 806 in Embodiment 3 is the same as operation 806 in Embodiment 1.
[0316] Operation 807 in Embodiment 3 is the same as operation 807 in Embodiment 1.
[0317] Operation 808 in Embodiment 3 is the same as operation 808 in Embodiment 1.
[0318] Operation 809 in Embodiment 3 is the same as operation 809 in Embodiment 1.
[0319] Operation 810 in Embodiment 3 is the same as operation 810 in Embodiment 1.
[0320] Operation 811 in Embodiment 3 is the same as operation 811 in Embodiment 1.
[0321] The operations 806 to 811 are for 3-step CBRA, and they are not needed for 2-step CBRA or CFRA.
[0322] Operation 812 in Embodiment 3 is the same as operation 812 in Embodiment 1.
[0323] Operation 813 in Embodiment 3 is the same as operation 813 in Embodiment 1.
[0324] Operation 814 in Embodiment 3 is the same as operation 814 in Embodiment 1.
[0325] The operations 812 to 814 are for 2-step CBRA or CFRA, and they are not needed for 3-step CBRA.
[0326] Operation 815 in Embodiment 3 is the same as operation 815 in Embodiment 1.
[0327] Operation 816 in Embodiment 3 is the same as operation 816 in Embodiment 1.
[0328] In some embodiments of Figure 9 (denoted as Embodiment 4) , R2 decides both the type of random access for the A-IoT device and the failure of A-IoT device communication, and R2 determines the resource used for D2R transmission. In Embodiment 4, operations 901 to 918 may be performed.
[0329] Embodiment 4
[0330] Operation 901 in Embodiment 4 is the same as operation 801 in Embodiment 3.
[0331] Operation 902 in Embodiment 4 is the same as operation 802 in Embodiment 3.
[0332] Operation 903 in Embodiment 4 is the same as operation 803 in Embodiment 3.
[0333] Operation 904 in Embodiment 4 is the same as operation 804 in Embodiment 3.
[0334] At 905, R1 may send a paging message to the A-IoT device. The detailed descriptions of the paging message are the same as those of the paging message defined in operation 805 in Embodiment 1.
[0335] At 906, R1 may send an initial triggering notification to R2, to indicate the initiation of Paging to the A-IoT device.
[0336] In some embodiments, the initial triggering notification may include one or more A-IoT device IDs to identify one or more A-IoT devices, or an A-IoT group ID to identify a group of A-IoT devices.
[0337] In some embodiments, the initial triggering notification may include the type of random access by the A-IoT device. The detailed descriptions of the type of random access are the same as those defined in operation 803 in Embodiment 1.
[0338] In some embodiments, the initial triggering notification may include a threshold, which is used by R2 to determine whether the A-IoT communication is successfully completed.
[0339] In some embodiments, the initial triggering notification may include the time to wait, which indicates the maximum allowed waiting times of receiving D2R transmission by the A-IoT device.
[0340] - In one example, the time to wait indicates the maximum allowed waiting times of receiving MSG1 transmission by the A-IoT device, for 3-step CBRA, 2-step CBRA or CFRA.
[0341] - In another example, the time to wait indicates the maximum allowed waiting times of receiving MSG3 transmission by the A-IoT device, for 3-step CBRA.
[0342] - In another example, the time to wait indicates the maximum allowed waiting times of receiving command response transmission by the A-IoT device (s) for 3-step CBRA, 2-step CBRA or CFRA.
[0343] At 907, R2 may start a timer, e.g. a second timer.
[0344] The second timer may be used to by R2 to determine if the A-IoT device communication is failed.
[0345] - In one example, if there is no MSG3 of 3-step CBRA from the A-IoT device (s) before the second timer expires, R2 should consider that the A-IoT device communication is failed.
[0346] - In another example, if there is no MSG1 of 3-step CBRA, 2-step CBRA or CFRA from the A-IoT device (s) before the second timer expires, R2 should consider that the A-IoT device communication is failed.
[0347] - In another example, if there is no command response transmission by the A-IoT device (s) for 3-step CBRA, 2-step CBRA or CFRA, R2 should consider that the A-IoT device communication is failed.
[0348] - In another example, if there is no enough D2R transmission for at least the threshold of all A-IoT devices before the second timer expires, R2 should consider that the A-IoT device communication is failed. Otherwise, if there is enough D2R transmissions for at least the threshold of all A-IoT devices before the second timer expires, R2 should consider the A-IoT device communication is successfully completed. The threshold may be received at 906 or determined by R2 itself.
[0349] In some cases, the value of the second timer is determined by R2 itself.
[0350] In some cases, the value of the second timer is the time to wait received at 906.
[0351] If R2 determines the A-IoT device communication is failed, it performs operation 918.
[0352] The following operations 908 to 913 are for 3-step CBRA, while operations 914 to 916 are for 2-step CBRA or CFRA.
[0353] Operations 908 in Embodiment 4 is the same as operation 806 in Embodiment 3.
[0354] Operations 909 in Embodiment 4 is the same as operation 807 in Embodiment 3.
[0355] Operations 910 in Embodiment 4 is the same as operation 808 in Embodiment 3.
[0356] Operations 911 in Embodiment 4 is the same as operation 809 in Embodiment 3.
[0357] Operations 912 in Embodiment 4 is the same as operation 810 in Embodiment 3.
[0358] Operations 913 in Embodiment 4 is the same as operation 811 in Embodiment 3.
[0359] The operations 908 to 913 are for 3-step CBRA, and they are not needed for 2-step CBRA or CFRA.
[0360] Operations 914 in Embodiment 4 is the same as operation 812 in Embodiment 3.
[0361] Operations 915 in Embodiment 4 is the same as operation 813 in Embodiment 3.
[0362] Operations 916 in Embodiment 4 is the same as operation 814 in Embodiment 3.
[0363] The operations 914 to 916 are for 2-step CBRA or CFRA, and they are not needed for 3-step CBRA.
[0364] Operation 917 in Embodiment 4 is the same as operation 815 in Embodiment 3.
[0365] At 918, R2 may send a device communication failure message to R1, including a cause value indicating the cause of A-IoT device communication failure.
[0366] - In one example, the cause value is "No response from the A-IoT device" , which indicates that R2 doesn't receive the D2R transmission (e.g., MSG1 of 3-step CBRA, 2-step CBRA or CFRA or the MSG3 of 3-step CBRA) from the A-IoT device, or R2 doesn't receive enough D2R transmission for at least the threshold of all A-IoT devices.
[0367] - In another example, the cause value is "A-IoT device is FAR" , which indicates that the proximity location of the A-IoT device is FAR (e.g. Not Near) .
[0368] - In another example, the cause value is "No response from the A-IoT device due to reader moving" , which indicates that R2 moves and doesn't receive the D2R transmission (e.g. MSG1 of 3-step CBRA, 2-step CBRA or CFRA, or the MSG3 of 3-step CBRA) , from the A-IoT device.
[0369] - In another example, the cause value is "No response from the A-IoT device due to low energy" , which indicates that the A-IoT device is without enough energy to send the D2R transmission (e.g. MSG1 of 3-step CBRA, 2-step CBRA or CFRA, or the MSG3 of 3-step CBRA) .
[0370] In Embodiment 4, the operation 918 is optional, and it can be performed by R2 at anytime, e.g. before any previous operation. For example, the operation 918 can be performed by R2 before the operation 908.
[0371] In the embodiments of Figure 10 (denoted as Embodiment 5) , R1 decides the resource for D2R transmission and the failure of A-IoT device communication. In Embodiment 5, operations 1 to 16 may be performed.
[0372] Embodiment 5
[0373] Operation 1 in Embodiment 5 is the same as operation 801 in Embodiment 1.
[0374] Operation 2 in Embodiment 5 is the same as operation 802 in Embodiment 1.
[0375] At operation 3, R1 may send an interface setup request to R2, to request A-IoT resource set in R2.
[0376] In some embodiments, the interface setup request may include an indicator, indicating the Request concerns an A-IoT.
[0377] - In one example, the interface setup request is an Xn Setup Request message, if R1 and R2 are BSs.
[0378] - In another example, the interface setup request is a UE Information Request Sidelink message, if R1 and R2 are UEs.
[0379] At operation 4, R2 may send an interface setup response to R1, containing the A-IoT resource set in R2.
[0380] - In one example, the interface setup response is an Xn Setup Response message, if R1 and R2 are BSs.
[0381] - In another example, the interface setup response is a UE Information Response Sidelink message, if R1 and R2 are UEs.
[0382] In some embodiments, R1 may obtain the A-IoT resource set using other procedures, e.g. before operation 1.
[0383] After operation 4, R1 may send a paging message to the A-IoT device (at operation 5B) and start a timer (at operation 5A) , e.g. a first timer.
[0384] In some embodiments, the paging message includes one or more A-IoT device IDs to identify one or more A-IoT devices, or an A-IoT group ID to identify a group of A-IoT devices.
[0385] In some embodiments, the paging message may include the resource used for MSG1 transmission by the A-IoT device, where the resource for D2R transmission is determined by R1 based on the received A-IoT resource set from R2. For example, the resource for D2R transmission may be a common resource used for MSG1 transmission of 3-step CBRA, a common resource used for MSG1 transmission of 2-step CBRA, or a dedicated resource used for MSG1 transmission of CFRA.
[0386] In some embodiments, the paging message may further include an indicator indicating the type of random access, e.g. 3-step CBRA, 2-step CBRA, or CFRA.
[0387] In some embodiments, the paging message may include an indicator indicating a command response will be sent by the A-IoT device (s) . For example, the indicator is the type of command, e.g. read, write, disable.
[0388] In some cases, if there is no D2R transmission of the A-IoT device from R2 before the first timer expires in R1, R1 should consider the A-IoT device communication is failed.
[0389] In some cases, if there is no enough D2R transmissions from R2 for at least a threshold of all A-IoT devices before the first timer expires in R1, R1 should consider the A-IoT device communication is failed. Otherwise, if R1 receives D2R transmissions from R2 for at least a threshold of all A-IoT devices before the first timer expires, R1 should consider the A-IoT device communication is successfully completed. For example, the threshold may be 99%.
[0390] The following operations 6 to 11 are for 3-step CBRA, while operations 12 to 14 are for 2-step CBRA or CFRA.
[0391] In some embodiments, the determined resource used for D2R transmission by R1 based on the received A-IoT resource set may be sent from R1 to R2, which is not shown in Figure 10. In addition, R2 may reject the determined resource used for D2R transmission.
[0392] Operation 6 in Embodiment 5 is the same as operation 806 in Embodiment 1.
[0393] Operation 7 in Embodiment 5 is the same as operation 807 in Embodiment 1.
[0394] At operation 8, R1 may send an MSG2 to the A-IoT device to respond with the successfully received random ID.
[0395] In some embodiments, the MSG2 may include the A-IoT device ID to identify the A-IoT device.
[0396] In some embodiments, the MSG2 may include the dedicated resource used for MSG3 transmission by the A-IoT device, where the dedicated resource is determined by R1 based on the received A-IoT resource set from R2.
[0397] Operation 9 in Embodiment 5 is the same as operation 809 in Embodiment 1.
[0398] Operation 10 in Embodiment 5 is the same as operation 810 in Embodiment 1.
[0399] At operation 11 (which is optional) , R1 may send an MSG4 to the A-IoT device carrying the command information.
[0400] In some embodiments, the MSG4 may include the A-IoT device ID to identify the A-IoT device.
[0401] In some embodiments, the MSG4 may include the dedicated resource used for command response transmission by the A-IoT device, where the dedicated resource is determined by R1 based on the received A-IoT resource set from R2.
[0402] The operations 6 to 11 are for 3-step CBRA, and they are not needed for 2-step CBRA or CFRA.
[0403] Operation 12 in Embodiment 5 is the same as operation 812 in Embodiment 1.
[0404] Operation 13 in Embodiment 5 is the same as operation 813 in Embodiment 1.
[0405] At operation 14, (which is optional) , R1 may send an MSG2 to the A-IoT device.
[0406] In some embodiments, the MSG2 may include the A-IoT device ID to identify the A-IoT device.
[0407] In some embodiments, the MSG2 may include the dedicated resource used for command response transmission by the A-IoT device, where the dedicated resource is determined by R1 based on the received A-IoT resource set from R2.
[0408] - In one example, if the random access is 2-step CBRA, the MSG2 is sent by R1 to respond with the successfully received random ID.
[0409] - In another example, if the random access is CFRA, the MSG2 is sent by R1 to respond with the successfully received MSG1.
[0410] The operations 12 to 14 are for 2-step CBRA or CFRA, and they are not needed for 3-step CBRA.
[0411] Operation 15 in Embodiment 5 is the same as operation 815 in Embodiment 1.
[0412] Operation 16 in Embodiment 5 is the same as operation 816 in Embodiment 1.
[0413] In the embodiments of Figure 11 (denoted as Embodiment 6) , R1 decides the resource for D2R transmission while R2 determines the failure of A-IoT device communication. In Embodiment 6, operations 111 to 128 may be performed.
[0414] Embodiment 6
[0415] Operation 111 in Embodiment 6 is the same as operation 1 in Embodiment 5.
[0416] Operation 112 in Embodiment 6 is the same as operation 2 in Embodiment 5.
[0417] Operation 113 in Embodiment 6 is the same as operation 3 in Embodiment 5.
[0418] Operation 114 in Embodiment 6 is the same as operation 4 in Embodiment 5.
[0419] At 115, R1 may send a paging message to the A-IoT device (i.e. D) . The detailed descriptions of the paging message are the same as those of the paging message defined in operation 5B in Embodiment 5.
[0420] At 116, R1 may send an initial triggering notification to R2, to indicate the initiation of paging to the A-IoT device.
[0421] In some embodiments, the initial triggering notification may include one or more A-IoT device IDs to identify one or more A-IoT devices, or an A-IoT group ID to identify a group of A-IoT devices.
[0422] In some embodiments, the initial triggering notification may include the type of random access by the A-IoT device. The detailed descriptions of the type of random access are the same as those defined in operation 803 in Embodiment 1.
[0423] In some embodiments, the initial triggering notification may include the time to wait, which indicates the maximum allowed waiting times of receiving D2R transmission by the A-IoT device (s) .
[0424] - In one example, the time to wait indicates the maximum allowed waiting times of receiving MSG1 transmission by the A-IoT device (s) , for 3-step CBRA, 2-step CBRA or CFRA.
[0425] - In another example, the time to wait indicates the maximum allowed waiting times of receiving MSG3 transmission by the A-IoT device (s) , for 3-step CBRA.
[0426] - In another example, the time to wait indicates the maximum allowed waiting times of receiving command response transmission by the A-IoT device (s) for 3-step CBRA, 2-step CBRA or CFRA.
[0427] At 117, R2 may start a timer, e.g. a second timer.
[0428] The second timer may be used to by R2 to determine if the A-IoT device communication is failed.
[0429] - In one example, if there is no MSG3 of 3-step CBRA from the A-IoT device (s) before the second timer expires, R2 should consider that the A-IoT device communication is failed.
[0430] - In another example, if there is no MSG1 of 3-step CBRA, 2-step CBRA or CFRA from the A-IoT device (s) before the second timer expires, R2 should consider that the A-IoT device communication is failed.
[0431] - In another example, if there is no command response transmission by the A-IoT device (s) for 3-step CBRA, 2-step CBRA or CFRA, R2 should consider that the A-IoT device communication is failed.
[0432] In some cases, the value of the second timer is determined by R2.
[0433] In some cases, the value of the second timer is the time to wait received at 116.
[0434] If R2 determines the A-IoT device communication is failed, it performs operation 128.
[0435] The following operations 118 to 123 are for 3-step CBRA, while operation 124 to 126 are for 2-step CBRA or CFRA.
[0436] Operations 118 in Embodiment 6 is the same as operation 6 in Embodiment 5.
[0437] Operations 119 in Embodiment 6 is the same as operation 7 in Embodiment 5.
[0438] Operations 120 in Embodiment 6 is the same as operation 8 in Embodiment 5.
[0439] Operations 121 in Embodiment 6 is the same as operation 9 in Embodiment 5.
[0440] Operations 122 in Embodiment 6 is the same as operation 10 in Embodiment 5.
[0441] Operations 123 in Embodiment 6 is the same as operation 11 in Embodiment 5.
[0442] The operations 118 to 123 are for 3-step CBRA, and they are not needed for 2-step CBRA or CFRA.
[0443] Operations 124 in Embodiment 6 is the same as operation 12 in Embodiment 5.
[0444] Operations 125 in Embodiment 6 is the same as operation 13 in Embodiment 5.
[0445] Operations 126 in Embodiment 6 is the same as operation 14 in Embodiment 5.
[0446] The operations 124 to 126 are for 2-step CBRA or CFRA, and they are not needed for 3-step CBRA.
[0447] Operations 127 in Embodiment 6 is the same as operation 15 in Embodiment 5.
[0448] At 128 (which is optional) , R2 may send a device communication failure message to R1, including a cause value indicating the cause of A-IoT device communication failure.
[0449] - In one example, the cause value is "No response from the A-IoT device" , which indicates that R2 doesn't receive the D2R transmission (e.g. MSG1 of 3-step CBRA, 2-step CBRA or CFRA, or the MSG3 of 3-step CBRA) , from the A-IoT device, or R2 doesn't receive enough D2R transmission for at least the threshold of all A-IoT devices.
[0450] - In another example, the cause value is "A-IoT device is FAR" , which indicates that the proximity location of the A-IoT device is FAR (e.g. Not Near) .
[0451] - In another example, the cause value is "No response from the A-IoT device due to reader moving" , which indicates that R2 moves and doesn't receive the D2R transmission (e.g. MSG1 of 3-step CBRA, 2-step CBRA or CFRA, or the MSG3 of 3-step CBRA) , from the A-IoT device.
[0452] - In another example, the cause value is "No response from the A-IoT device due to low energy" , which indicates that the A-IoT device is without enough energy to send the D2R transmission (e.g. MSG1 of 3-step CBRA, 2-step CBRA or CFRA, or the MSG3 of 3-step CBRA) .
[0453] In Embodiment 6, the operation 128 is optional, and it can be performed by R2 at anytime, e.g. before any previous operation. For example, the operation 128 can be performed by R2 before the operation 118.
[0454] The description herein is provided to enable a person having ordinary skill in the art to make or use the disclosure. Various modifications to the disclosure will be apparent to a person having ordinary skill in the art, and the generic principles defined herein may be applied to other variations without departing from the scope of the disclosure. Thus, the disclosure is not limited to the examples and designs described herein but is to be accorded the broadest scope consistent with the principles and novel features disclosed herein.
Claims
1.A first ambient internet of things (A-IoT) reader, comprising:at least one memory; andat least one processor coupled to the at least one memory and configured to cause the first A-IoT reader to:transmit, to an A-IoT device, a first message including information related to a first resource used for device to reader (D2R) transmission; andreceive a D2R transmission of the A-IoT device from a second A-IoT reader, wherein the D2R transmission is transmitted from the A-IoT device to the second A-IoT reader via the first resource.2.The first A-IoT reader of Claim 1, wherein the at least one processor is further configured to cause the first A-IoT reader to receive the information related to the first resource from the second A-IoT reader.3.The first A-IoT reader of Claim 1, wherein the at least one processor is further configured to cause the first A-IoT reader to:receive a resource set or resource configuration information from the second A-IoT reader; anddetermine the first resource based on the resource set or the resource configuration information.4.The first A-IoT reader of Claim 1 or Claim 3, wherein the at least one processor is further configured to cause the first A-IoT reader to transmit a request to the second A-IoT reader, and wherein the request includes information for indicating that the request is associated with one or more A-IoT devices.5.The first A-IoT reader of Claim 1 or Claim 3, wherein the at least one processor is further configured to cause the first A-IoT reader to transmit the information related to the first resource to the second A-IoT reader.6.The first A-IoT reader of Claim 1, wherein the first resource is one of the following:a common resource used for MSG1 transmission of 3-step contention-based random access (CBRA) ;a common resource used for MSG1 transmission of 2-step CBRA; ora dedicated resource used for MSG1 transmission of contention-free random access (CFRA) ; andthe first message is a paging message, and the MSG1 transmission is a first D2R transmission from the A-IoT device during random access; orwherein the first resource is a dedicated resource used for MSG3 transmission of 3-step CBRA, the first message is MSG2 of 3-step CBRA, the MSG3 transmission is a second D2R transmission from the A-IoT device during random access, and the MSG2 is a first reader to device (R2D) transmission to the A-IoT device during random access; orwherein the first resource is a dedicated resource used for a command response transmission, and the first message is one of the following:MSG4 of 3-step CBRA, wherein the MSG4 is a second R2D transmission to the A-IoT device during random access;MSG2 of 2-step CBRA; orMSG2 of CFRA.7.The first A-IoT reader of Claim 6, wherein the first or second D2R transmission from the A-IoT device or the first or second R2D transmission to the A-IoT device includes an ID of the A-IoT device.8.The first A-IoT reader of Claim 6, wherein the paging message includes at least one of the following:identifier (ID) information of one or more A-IoT devices including the A-IoT device;an A-IoT group ID;a type of random access, wherein the type of random access includes 3-step CBRA, 2-step CBRA or CFRA; ora first indicator for indicating that a command response will be sent by the A-IoT device.9.The first A-IoT reader of Claim 8, wherein the first indicator is a type of a command, and the command is a read command, a write command or a disable command.10.The first A-IoT reader of Claim 1, wherein the at least one processor is further configured to cause the first A-IoT reader to transmit a second message to the second A-IoT reader, and wherein the second message includes at least one of the following:identifier (ID) information of one or more A-IoT devices including the A-IoT device;an A-IoT group ID;a type of random access that can be used by the one or more A-IoT devices, wherein the type of random access includes 3-step CBRA, 2-step CBRA or CFRA;information for indicating that a command response will be sent by the one or more A-IoT devices; oran approximate number of the one or more A-IoT devices.11.The first A-IoT reader of Claim 1, wherein the at least one processor is further configured to cause the first A-IoT reader to receive information related to the second A-IoT reader from a core network (CN) or a base station (BS) , wherein the information related to the second A-IoT reader includes at least one of the following:an ID of the second A-IoT reader; ora certain area from which the D2R transmission of the A-IoT device is to be received.12.The first A-IoT reader of Claim 1, wherein the at least one processor is further configured to cause the first A-IoT reader to receive, from the second A-IoT reader, a cause value indicating no resource available in the second A-IoT reader, wherein the cause value is further associated with an ID of the A-IoT device.13.The first A-IoT reader of Claim 1, wherein the at least one processor is further configured to cause the first A-IoT reader to:start a first timer; andconsider that the A-IoT device communication is failed, if no response is received from the A-IoT device via the second A-IoT reader before the first timer expires or if no response is received from at least a threshold of all A-IoT devices via the second A-IoT reader before the first timer expires.14.The first A-IoT reader of Claim 1, wherein the at least one processor is further configured to cause the first A-IoT reader to transmit a threshold to the second A-IoT reader, and wherein the threshold is used by the second A-IoT reader to determine whether the A-IoT communication is successfully completed based on the threshold.15.The first A-IoT reader of Claim 1, wherein the at least one processor is further configured to cause the first A-IoT reader to receive a third message from the second A-IoT reader, and wherein the third message includes at least one of the following:a proximity location of the A-IoT device;an energy status report of the A-IoT device; ora cause value of a communication failure of the A-IoT device.16.The first A-IoT reader of Claim 15, wherein the cause value includes one of the following:no response is received from the A-IoT device;the A-IoT device is far;no response is received from the A-IoT device due to the second A-IoT reader moving; orno response is received from the A-IoT device due to low energy of the A-IoT device.17.A second ambient internet of things (A-IoT) reader, comprising:at least one memory; andat least one processor coupled to the at least one memory and configured to cause the second A-IoT reader to:receive a device to reader (D2R) transmission from an A-IoT device via a first resource used for D2R transmission; andtransmit the D2R transmission of the A-IoT device to a first A-IoT reader, wherein information related to the first resource is transmitted by the first A-IoT reader to the A-IoT device.18.The second A-IoT reader of Claim 17, wherein the at least one processor is further configured to cause the second A-IoT reader to transmit the information related to the first resource to the first A-IoT reader.19.A processor of a first ambient internet of things (A-IoT) reader for wireless communication, comprising:at least one controller coupled with at least one memory and configured to cause the processor to:transmit, to an A-IoT device, a first message including information related to a first resource used for device to reader (D2R) transmission; andreceive a D2R transmission of the A-IoT device from a second A-IoT reader, wherein the D2R transmission is transmitted from the A-IoT device to the second A-IoT reader via the first resource.20.A method performed by a first ambient internet of things (A-IoT) reader, comprising:transmitting, to an A-IoT device, a first message including information related to a first resource used for device to reader (D2R) transmission; andreceiving a D2R transmission of the A-IoT device from a second A-IoT reader, wherein the D2R transmission is transmitted from the A-IoT device to the second A-IoT reader via the first resource.
Citation Information
Patent Citations
Device and method of communication
WO2024159533A1
Paging transmission and reception
WO2024222105A1
Cited By
Data transmission method and device
CN120935858A
Data transmission method and apparatus
CN120935858B
Ambient internet-of-things devices and methods of operation of same
US20250348694A1