Methods for radio resource scheduling in ambient IoT communication

Abstract

Describe herein are methods, systems, and apparatuses for scheduling radio resources for ambient internet of things (IoT) devices. A reader may encode a reader-to-device (R2D) transmission comprising one or more device-to-reader (D2R) resource grants that indicate resources for D2R transmissions from one or more ambient internet of things (IoT) devices. The reader may send the R2D transmission to the one or more ambient IoT devices. The reader may receive the D2R transmissions on the resources indicated by the one or more D2R resource grants.

Description

METHODS FOR RADIO RESOURCE SCHEDULING IN AMBIENT IOT COMMUNICATIONTECHNICAL FIELD

[0001] This application relates generally to wireless communication systems, including scheduling of radio resources, and more specifically providing resource grants to ambient IoT devices.BACKGROUND

[0002] Wireless mobile communication technology uses various standards and protocols to transmit data between a base station and a wireless communication device. Wireless communication system standards and protocols can include, for example, 3rd Generation Partnership Project (3GPP) Long Term Evolution (LTE) (e.g., 4G) , 3GPP New Radio (NR) (e.g., 5G) , and Institute of Electrical and Electronics Engineers (IEEE) 802.11 standard for Wireless Local Area Networks (WLAN) (commonly known to industry groups as  ) .

[0003] As contemplated by the 3GPP, different wireless communication systems' standards and protocols can use various radio access networks (RANs) for communicating between a base station of the RAN (which may also sometimes be referred to generally as a RAN node, a network node, or simply a node) and a wireless communication device known as a user equipment (UE) . 3GPP RANs can include, for example, Global System for Mobile communications (GSM) , Enhanced Data Rates for GSM Evolution (EDGE) RAN (GERAN) , Universal Terrestrial Radio Access Network (UTRAN) , Evolved Universal Terrestrial Radio Access Network (E-UTRAN) , and / or Next-Generation Radio Access Network (NG-RAN) .

[0004] Each RAN may use one or more radio access technologies (RATs) to perform communication between the base station and the UE. For example, the GERAN implements GSM and / or EDGE RAT, the UTRAN implements Universal Mobile Telecommunication System (UMTS) RAT or other 3GPP RAT, the E-UTRAN implements LTE RAT (sometimes simply referred to as LTE) , and NG-RAN implements NR RAT (sometimes referred to herein as 5G RAT, 5G NR RAT, or simply NR) . In certain deployments, the E-UTRAN may also implement NR RAT. In certain deployments, NG-RAN may also implement LTE RAT.

[0005] A base station used by a RAN may correspond to that RAN. One example of an E-UTRAN base station is an Evolved Universal Terrestrial Radio Access Network (E-UTRAN) Node B (also commonly denoted as evolved Node B, enhanced Node B, eNodeB, or eNB) . One example of an NG-RAN base station is a next generation Node B (also sometimes referred to as a g Node B or gNB) .

[0006] A RAN provides its communication services with external entities through its connection to a core network (CN) . For example, E-UTRAN may utilize an Evolved Packet Core (EPC) while NG-RAN may utilize a 5G Core Network (5GC) .

[0007] BRIEF DESCRIPTION OF THE SEVERAL VIEWS OF THE DRAWINGS

[0008] To easily identify the discussion of any particular element or act, the most significant digit or digits in a reference number refer to the figure number in which that element is first introduced.

[0009] FIG. 1 is an example table categorizing ambient IoT devices based on capabilities in accordance with some embodiments.

[0010] FIG. 2A illustrates deployment scenario 1 with a first topology (also referred to as Topology 1) in accordance with some embodiments.

[0011] FIG. 2B illustrates deployment scenario 2 with a second topology (also referred to as Topology 2) in accordance with some embodiments.

[0012] FIG. 3 illustrates a table with characteristics of different types of traffic for an ambient IoT device, in accordance with some embodiments.

[0013] FIG. 4 illustrates two example transmission timelines (e.g., first transmission timeline, and second transmission timeline) from ambient IoT communication in accordance with some embodiments.

[0014] FIG. 5 illustrates a typical R2D transmission (downlink (DL) ) in ambient IoT (A-IoT) air interface without Layer-1 (L1) repetition in accordance with some embodiments.

[0015] FIG. 6 illustrates a table with options of multiplexing one or more uplink grant scheduling indications into one or more R2D messages in accordance with some embodiments.

[0016] FIG. 7 illustrates an example R2D transmission with a single D2R resource in the L1 R2D control information and a single R2D command in accordance with some embodiments.

[0017] FIG. 8 illustrates an example R2D transmission with multiple D2R resources in the L2 MAC header in accordance with some embodiments.

[0018] FIG. 9 illustrates an example R2D transmission with a single D2R resource grant 904 in the L1 R2D control information and a single R2D command in accordance with some embodiments.

[0019] FIG. 10 illustrates an example R2D transmission with multiple D2R resource grants in the subheaders in accordance with some embodiments.

[0020] FIG. 11 illustrates an example R2D transmission with a separate indication of D2R resource (s) and correspondence of D2R messages in accordance with some embodiments.

[0021] FIG. 12 illustrates a method for a reader apparatus, according to embodiments herein.

[0022] FIG. 13 illustrates a method for an ambient IoT device, according to embodiments herein.

[0023] FIG. 14 illustrates an example architecture of a wireless communication system, according to embodiments disclosed herein.

[0024] FIG. 15 illustrates a system for performing signaling between a wireless device and a network device, according to embodiments disclosed herein.DETAILED DESCRIPTION

[0025] Various embodiments are described with regard to a UE. However, reference to a UE is merely provided for illustrative purposes. The example embodiments may be utilized with any electronic component that may establish a connection to a network and is configured with the hardware, software, and / or firmware to exchange information and data with the network. Therefore, the UE as described herein is used to represent any appropriate electronic component.

[0026] Additionally, embodiments herein are described with regard to Internet of Things (IoT) devices. In some embodiments, an IoT device may be a UE. Reference to an IoT device is merely provided for illustrative purposes, and the embodiment herein may be utilized with any device that have the capability to collect and exchange data. IoT devices may be embedded with sensors, software, and network connectivity, allowing them to communicate with other devices and systems. IoT devices can vary in size, complexity, and functionality. They can range from small, simple devices such as  temperature sensors and smart home appliances to more complex devices like industrial machinery and autonomous vehicles. IoT devices may also be referred to simply as devices.

[0027] Some IoT devices include ambient IoT devices. An ambient IoT device is a device that is able to harvest energy from ambient sources. For example, some ambient IoT devices may use radio frequency (RF) waves for power. To power such devices using RF, embodiments herein provide enhancements to a wireless communication system framework to introduce a new category of device (s) that is able to harvest energy from ambient sources. An ambient IoT device may be referred to as an RF powered device. An ambient IoT device may also be a UE device.

[0028] Embodiments herein are also describe with regard to a reader or reader device. A reader may request information from an ambient IoT device, collect and process data transmitted by the ambient IoT device, and transmit data to the ambient IoT device. Embodiments herein refer to signaling between the reader and the ambient IoT device. A device-to-reader transmission refers to an uplink transmission from the device to the reader. A reader-to-device transmission refers to a downlink transmission from the reader to the device.

[0029] In recent years, IoT has attracted much attention in the wireless communication world. Most of the existing wireless communication devices are powered by a battery that needs to be replaced or recharged manually. The automation and digitalization of various industries open numbers of new markets using new IoT technologies of supporting battery-less devices with no energy storage capability or devices with energy storage that do not need to be replaced or recharged manually.

[0030] It may be beneficial to integrate ambient IoT devices with 3GPP wireless communication systems to expand their use cases. Ambient IoT devices may be categorized based on their capabilities. One overall objective is to develop a harmonized air interface design with minimized differences (where necessary) for Ambient IoT to enable the ambient IoT devices with different capabilities. For example, FIG. 1 is an example table 102 categorizing ambient IoT devices based on capabilities in accordance with some embodiments.

[0031] In certain wireless systems, a first Am-IoT device type (Type-1 104) is configured for about 1 micro Watt (μW) peak power consumption, has energy storing, has an initial sampling frequency offset (SFO) up to 10x parts-per-million (ppm) , and  provides neither downlink (DL) nor uplink (UL) amplification in the device. Further, the Type-1 Am-IoT device’s UL transmission is backscattered on a carrier wave provided externally, and uplink transmission is not generated internally by the device.

[0032] In certain such systems, a second Am-IoT device type (Type-2a 106 or Type 2b 108) is configured for less than or equal to a few hundred μW peak power consumption, has energy storage, has an initial SFO up to 10x ppm, and provides DL and / or UL amplification in the device. Further, the Type-2a Am-IoT device’s UL transmission may be generated internally by the device, or be backscattered on a carrier wave provided externally.

[0033] In some embodiments, the coverage design target for ambient IoT device may be a maximum distance of 10-50 m with device indoors. In some embodiments, the ambient IoT devices may use different types of topologies (e.g., UE as intermediate node under NW control) , with no RRC states, no mobility (i.e., at least no cell selection / re-selection-like function) , no HARQ, no ARQ. The different topologies may benefit from signaling to control the carrier wave.

[0034] Further, because these devices have such low complexities, they may not have a very accurate clock. Accordingly, there may be an signaling issue involving timing / frequency drifting. For a D2R transmission with a long duration, the timing / frequency drifting may be significant due to up to the up to 10x ppm sampling frequency offset (SFO) .

[0035] FIG. 2A and FIG. 2B illustrate two topologies for ambient IoT devices. The topologies represent deployment scenarios with the following characteristics. Specifically, FIG. 2A illustrates deployment scenario 1 with a first topology 202 (also referred to as Topology 1) in accordance with some embodiments. The base station 204 and coexistence characteristics of the first topology 202 is a micro-cell and co-site. As shown, the base station 204 is located indoor with the ambient IoT device 206. The illustrated base station 204 forms an indoor micro-cell. Such a topology may be able to be implemented in a large warehouse.

[0036] However, in some deployment scenarios there may be a limitation where the base station cannot be indoors. For example, FIG. 2B illustrates deployment scenario 2 with a second topology 208 (also referred to as Topology 2) in accordance with some embodiments. As shown, in the second topology 208, a UE 210 may serve as an intermediate node under network control (e.g., base station 212) . The base station 212  and coexistence characteristics of the second topology 208 is a macro-cell and co-site. The location of the intermediate node (e.g., UE 210) is indoor with the ambient IoT device 214. The intermediate node can relay information from the base station 212 to the ambient IoT device 214, and from the ambient IoT device 214 to the the base station 212.

[0037] FIG. 3 illustrates a table 302 with characteristics of different types of traffic for an ambient IoT device, in accordance with some embodiments. As shown, the types of traffic may include device-terminated (DT) type traffic 304, device-originated-device-terminated triggered transmission (DO-DTT) type traffic 306, and device originated-autonomous (DO-A) type traffic 308. Independently, there may be two kinds of lower layer mechanisms for uplink transmission: backscattered on a carrier wave provided externally; and generated internally by the device (supported by high-tier device Type 2b) .

[0038] An example use case for the DT type traffic 304 may be a command use case. As shown, the DT type traffic 304 may include signaling from the reader to the tag. Further the DT type traffic 304 may not need a carrier wave.

[0039] An example use case for the device-originated-device-terminated triggered transmission (DO-DTT) type traffic 306 may be an inventory use case. As shown, the signaling may be bidirectional, including a trigger from the reader to the tag and a response from the tag to the reader. Additionally, as shown, the ambient IoT device may use a carrier wave for a backscatter transmission.

[0040] An example use case for the DO-Atype traffic 308 may be a sensor use case. For example, a smoke detection sensor may be capable of transmitting a signal autonomously. The DO-Atype traffic 308 may include signaling from the tag to the reader. Additionally, as shown, the ambient IoT device may use a carrier wave for a backscatter transmission.

[0041] Resource scheduling for ambient IoT devices may include the following characteristics. Physical device-to-reader data channel (PDRCH) may be a channel for uplink from the ambient IoT device to the reader. Physical reader-to-device data channel (PRDCH) may be a channel for downlink from the reader to the ambient IoT device. Scheduling information of PDRCH transmission may be provided by a corresponding PRDCH.

[0042] In some embodiments, RRC connection management is not supported. How the resource configuration is provided to the device may be further developed.

[0043] In some embodiments, an ambient IoT paging message may indicate information from which the device can determine resources to be used for response (device-to-reader (D2R) message) . Further development is needed regarding how (e.g., implicit / explicit / configured / preconfigured) and what resources (dedicated and / or shared) are provided to the device.

[0044] FIG. 4 illustrates two example transmission timelines (e.g., first transmission timeline 402, and second transmission timeline 404) from ambient IoT communication in accordance with some embodiments. The ambient IoT communication may be DT (with response) or DO-DTT.

[0045] As shown in the first transmission timeline 402, a reader may send a reader-to-device (R2D) transmission 406 to the device. The device transmits a device-to reader (D2R) transmission 408 to the reader. In the first transmission timeline 402, the device transmission timing is confined between a minimum time period 410 (TR2D, min) and a maximum time period 412 (TR2D, max) . In such embodiments, the device may be configured with the minimum time period 410 and the maximum time period 412, and then the device can determine when to schedule the D2R transmission 408 between those periods.

[0046] As shown in the second transmission timeline 404, the reader may send an R2D transmission 414 to the device, and the device may send a D2R transmission 416 to the reader. In the second transmission timeline 404, the reader may directly schedule the D2R transmission 416 at time TR2D (>TR2D, min) . TR2D may be greater thanTR2D, min.

[0047] In either case (e.g., first transmission timeline 402 and second transmission timeline 404) , the D2R transmission is somehow scheduled by R2D transmission (in the form of relative timing) . However, there are uplink (D2R) scheduling issues for ambient IoT devices that should be addressed.

[0048] For example, it is unclear how the scheduling is done. In some embodiments, independent D2R scheduling or R2D-D2R associated scheduling may be used. While in legacy new radio (NR) Uu design, uplink grants to individual UE are allocated by a network node (e.g., gNB) with Downlink Control Information (DCI) or Radio Resource Control (RRC) signaling independently from user plane (UP) transmissions, the ambient IoT system’s transaction nature may lend itself to the allocation of uplink grant being  associated with a downlink transmission. The ambient IoT device may be only expected to respond with one triggering R2D message. Accordingly, R2D-D2R may be used in some embodiments.

[0049] Further, the effectiveness of the scheduling should be considered. From the reader perspective, there is a cost-effective problem with ambient IoT scheduling. This is because the ambient IoT devices may be in one of the three states. Case 1 may refer to a state where the ambient IoT device is in proximity, and able to transmit and receive. Case 2 may refer to a state where the ambient IoT device is not in proximity (therefore, unable to receive R2D transmission) . Case 3 may refer to a state where the ambient IoT device is in proximity, but unable to transmit and receive (e.g., ambient IoT device lacks enough stored energy for transmission / reception, or is unable to receive R2D transmission for some other reason) .

[0050] Scheduling may only succeed in Case 1 where the device us able to respond. In the other cases, the R2D transmission and the associated uplink grant would be wasted. If the R2D transmission and the associated uplink grant fails, the reader may not be sure how to differentiate the remaining two cases (e.g., case 2 and case 3) . The reader may re-schedule another grant (along with R2D message again) to check if the intended device may be in case 3 previously, but is able to transfer to case 1 after energy harvesting.

[0051] However, it is not efficient to schedule a dedicated grant to each intended device as that may be too wasteful with power and signaling overhead. Some embodiments may address this by multiplexing potential responses in a single scheduled uplink grant to reduce waste. To maximize the chance of not wasting the scheduled uplink grant, the intended ambient IoT device set may be larger (e.g., a R2D message targets “any” devices in reader coverage) . However, it is also troubling to schedule shared grant to multiple intended devices due to risk of collisions. The greater the number of devices that are sent the uplink grant the greater the risk of collisions.

[0052] Accordingly, it may be beneficial for an approach to be balanced to avoid too much waste and limit the risk of collisions. Embodiments herein may provide a scheduling signaling design to provide flexibility and efficiency for an ambient IoT reader to schedule a responding D2R transmission.

[0053] FIG. 5 illustrates a typical R2D transmission 502 (downlink (DL) ) in ambient IoT (A-IoT) air interface without Layer-1 (L1) repetition. The R2D transmission 502 is sent by the reader to the ambient IoT device. As shown, the R2D transmission 502 may  include a preamble 504, L1 R2D control information 506, upper layer payload 508, mid-amble 510, upper layer payload 512, Cyclic Redundancy Check (CRC) 514, and postamble 516.

[0054] As shown, upper layer payload 508, mid-amble 510, and upper layer payload 512 may further include L2 Medium Access Control (MAC) Headers 518, MAC Control Elements (CEs) 520, and MAC layer R2D content 522. The MAC layer R2D content 522 may include subheaders 524 and R2D messages 526. It is unclear currently where and how to indicate D2R grants. Further, it is unclear which grant is to be used by which device to respond to which R2D message. Some embodiments herein provide details related to scheduling of D2R transmission and the relationship to R2D message contents. Further, some embodiments describe device behavior relate to grant selection (e.g., whether / how to decide grant if multiple grants are matched) .

[0055] Additionally, it is currently unclear what to do if an uplink grant fails (e.g., “unused” or “collision” ) . Some embodiments herein specify reader and / or device behavior in regards of rescheduling.

[0056] As shown in FIG. 5, one or more D2R grant (s) may be included in different portions of the R2D transmission 502. The potential placements of the D2R resource indication can be in any of following. In some embodiments, the D2R grant (s) may be indicated in L1 R2D control information. Such embodiments may allow for the ambient IoT device to quickly obtain the grant without decoding upper layer messages, but the L1 R2D control information 506 placement may be size limited by physical layer constraints. In some embodiments, the grant (s) may be indicated in the L2 MAC header 518. In some embodiments, the grant (s) may be indicated in a L2 MAC CE (e.g., MAC CEs 520) . In some embodiments, the grant (s) may be indicated in a L2 MAC sub-header (e.g., subheaders 524) corresponding to an upper layer R2D message.

[0057] Further, FIG. 6 illustrates a table 602 with options of multiplexing one or more uplink grant scheduling indications into one or more R2D messages in accordance with some embodiments. All four potential combinations of grant allocation plus multiplexing R2D message may be useful.

[0058] One grant (e.g., one D2R transmission opportunity) for a single R2D message may be suitable for a unicast command to a single device. One grant (e.g., one D2R transmission opportunity) for multiple R2D messages may be suitable for case where reader has a downlink grant big enough to multiplex downlink messages. This may  reduce wasteful grants by assuming the majority of intended device will not respond. Multiple D2R transmission opportunities for a single R2D messages may be suitable for single inventory message (Msg 0 or Paging to trigger a group of devices to access) . Multiple D2R transmission opportunities for multiple R2D messages may be suitable for Routing Area (RA) procedure Msg 2, confirming multiple Random IDs in received Msg 1 (s) and schedule multiple Msg 3 (s) in one R2D transmission.

[0059] FIGS. 7-10 illustrate four examples of a simple indication of D2R resource grant (s) with unambiguous R2D message correspondence. FIG. 7 illustrates an example R2D transmission 702 with a single D2R resource 704 in the L1 R2D control information 706 and a single R2D command in accordance with some embodiments. In the illustrated embodiment, a single D2R resource 704 may be placed in L1 R2D control information 706. Further, in the illustrated embodiment there is a single downlink ambient IoT command 708 (to one intended ambient IoT device ID) encapsulated in the R2D transmission 702. The device with ambient IoT Device ID can use the D2R resource from the scheduled grant (D2R resource 704) to send confirmation and / or a response of the downlink ambient IoT command 708.

[0060] FIG. 8 illustrates an example R2D transmission 802 with multiple D2R resources 804 in the L2 MAC header 806 in accordance with some embodiments. In the illustrated embodiment, shared grant (s) (e.g., D2R resources 804) in consecutive or non-consecutive slots may be indicated is in the L2 MAC header 806. Further, in the illustrated embodiment there is a single ambient IoT Paging message 808 included in a single D2R transmission. The device (s) may send RA Msg 1 in an uplink grant chosen with a slotted aloha algorithm among the shared grants. Note that the number of grants may be larger or smaller than the number of responding devices, so collisions may occur.

[0061] FIG. 9 illustrates an example R2D transmission 902 with a single D2R resource grant 904 in the L1 R2D control information 906 and a single R2D command in accordance with some embodiments. A single grant (e.g., D2R resource 904) may be indicated in L1 R2D control information 906. Additionally, in the illustrated embodiment, multiple R2D commands 908 for different devices (or for the same device) may be multiplexed in the same R2D transmission 902. The devices, if able to receive the R2D transmission 902, will send a command response in the scheduled D2R grant. Because there is a single D2R resource for multiple commands, collisions may occur if  multiple devices are able to respond. In that case, the reader may reschedule. For example, the reader may send another R2D transmission with more grants.

[0062] FIG. 10 illustrates an example R2D transmission 1002 with multiple D2R resource grants in the subheaders in accordance with some embodiments. Each D2R resource scheduling grants (one or more grants) may be paired directly with the R2D message in each of MAC sub-header associated with the message. For example, in the illustrated embodiment, subheader-1 1004 includes a single D2R resource 1006 (to one intended ambient IoT device ID) that corresponds to R2D message-1 1008. The device with ambient IoT Device ID can use the D2R resource from the scheduled grant (D2R resource 1006) to send confirmation and / or a response to the R2D message-1 1008. As shown, the subheaders (e.g., subheader-n 1010) may include multiple D2R resources 1012. The multiple D2R resources 1012 may correspond to the associated R2D message (e.g., R2D message-n 1014) . The multiple D2R resource grants 1012 may allow multiple devices to respond to the R2D message-n 1014. Such embodiments may multiplex multiple R2D message and D2R grant combinations together in a single R2D transmission 1002.

[0063] FIG. 11 illustrates an example R2D transmission 1102 with a separate indication of D2R resource (s) and correspondence of D2R messages in accordance with some embodiments. In some embodiments, indication (s) of UL grant (s) can be either in L1 R2D control information 1104, L2 MAC header 1106, or as a L2 MAC CE. An indication of correspondence of R2D message can be indicated in subheader or L2 MAC CE, but the indication of correspondence may be in a different location from where the grants are indicated. Such an indication may be used to establish the correspondence between a grant and a message or command. In some embodiments, a single consecutive number of N grants that may be placed in L1 R2D control, and there may be M R2D messages included in a single R2D transmission. N may larger, equal, or smaller than M.

[0064] For example, in the illustrated embodiment, multiple consecutive resources 1108 within [TR2D, min TR2D, max] are sent by the reader to the ambient IoT devices in the L1 R2D control information 1104. Each of the D2R resources is indexed. The index may correspond to an index of a subheader, and the subheader may indicate a corresponding R2D message to respond to for the D2R resource. An ambient IoT device may determine the index of the R2D, use the D2R index to determine the subheader and may use the subheader to determine a R2D message.

[0065] For example, the subheader-1 1110 may include an index to indicate a device to respond to the downlink command-1 1112 and to send response in the uplink grant-1. Further, multiple indexes (e.g., m-2, m-1, m) may be included in a subheader (e.g., subheader-m 1114) to indicate the device (s) responding to a downlink command (e.g., downlink command-N 1116) , and the devices can send a D2R response in one of the uplink grants m-2, m-1 or m, as the command may be targeted for a group.

[0066] In some embodiments, the reader may associate a D2R grant with a Device identifier (ID) , not a downlink message (e.g., R2D command) . The uplink (D2R) grants scheduled in downlink (R2D) (PRDCH) may be associated directly with particular Device ID (s) or no device ID at all. In such embodiments, scheduled resources may not be linked to any R2D message that a device is to respond to, although the uplink grant could still be sent together with a R2D message or the R2D message may be sent separate from the uplink grant. The device can use the uplink grant to send anything. The grant is not limited to a response to a particular R2D message.

[0067] Such embodiments may have some advantages. Associating a D2R grant with a device ID rather than a R2D message, may allow a resource allocation message as a separate message transmitted in PRDCH than a transmission for the downlink command / inventory. This may also be used for DO-Atraffic which does not need to explicitly respond to any trigger message.

[0068] There may also be some disadvantages to associating a D2R grant with a device ID rather than a R2D message. The reader may not be prepared for the potential uplink messages to be expected in a scheduled UL grant, because the device with the matching device ID may response to multiple different R2D message in a single grant. Accordingly, the allocated uplink grant may not be big enough. Further, some of the grants associated with certain device ID (s) may always be wasted. This may not be a problem if the grant is not associated with any device ID (e.g., any device can use the grant scheduled) .

[0069] The reader may provide details of the D2R resources indicated in the R2D transmission. The following describes details of the resource indications (e.g., D2R resource 704, D2R resources 804, D2R resource 904, D2R resources 1006, D2R resources 1012, resources 1108) of the R2D transmission. Each radio resource in PDRCH may be represented by one or more of the following. The D2R resource indication in the R2D transmission may include a time offset. The time offset may relate  a timing to the allocation signaling in PRDCH. The D2R resource indication in the R2D transmission may include a frequency (offset) . An offset may be indicated if the transmission is not right in the default space (e.g., center) of a channel bandwidth. The D2R resource indication in the R2D transmission may include a time duration. The time duration may indicate how long the resource lasts in the time domain (e.g., a slot, a subframe) . The D2R resource indication in the R2D transmission may include a frequency-domain size (e.g., a number of resource blocks) . The D2R resource indication in the R2D transmission may include a Modulation and Coding Scheme (MCS) .

[0070] The D2R resource indication in the R2D transmission may include additional parameters to indicate further constrains of the resource usage. For instance, devices IDs that are allowed to use this resource may be indicated. A threshold and / or counter may be indicated to limit the resource grant to a certain period.

[0071] The uplink allocation may be in the form of a single radio resource or multiple resource (e.g., a resource set) . The size of the scheduled D2R resource may be based on the expected response to R2D message.

[0072] The downlink transmission timing may be provided as a reference to uplink grant. For other information, embodiments may use a dynamic indication in the R2D transmission or a static configuration or pre-configuration. In some embodiments, all other information about the resources are indicated dynamically. In some embodiments, all other information about the resources are indicated statically or are pre-configured. Such embodiments may present an issue in that the constraint of information can be (permanently) stored in a device memory. As device may go through ON / OFF cycle frequently, the information in volatile memory may not be retained. In some embodiments, some of the other information about the resources may be indicated dynamically, while other information about the resources may be indicated statically or pre-configured. These embodiments may employ an approach that uses a combination of static and dynamic configurations for the resource information.

[0073] In some embodiments, the following can be included in a static configuration for a resource or a resource set. A default value for resource parameters (e.g., time offset, frequency (offset) , time duration, frequency-domain size, MCS, devices IDs, threshold, counter) may be statically configured or preconfigured. For example, the resource size in time may be fixed as a slot. Default resource or default resource set may be statically configured or preconfigured so that there is no need to indicate it in each R2D  transmission if the default one is to be used. There may be a statically configured or preconfigured table for resources. For instance, some embodiments may include a pre-defined table for all (default) resource sets to be used for D2R response. In some embodiments, a different table entry may be associated with a downlink message type (e.g., “command” or “inventory” ) , different device types, and / or different device ID (s) (e.g., a prefix or a range of device ID may be used to determined which table to use) .

[0074] In some embodiments, some resource parameters may be optimized for dynamic configuration for a resource or a resource set. In some embodiments, time offset may be omitted if it is exactly equal to TR2D, min. In some embodiments, frequency offset may be omitted if there is a default D2R subchannel to be used; or if there is a configured, preconfigured, or fixed relationship between R2D frequency and D2R frequency. In some embodiments, time length can be omitted if this is a fixed length (e.g., one slot) . In some embodiments, for multiplex consecutive resources (e.g., in time domain) : a) begin and end may be indicated, or b) begin and total number resources may be indicated. In some embodiments, these parameters can be indicated by only the delta part when compared to the default values already pre-configured in device memory (e.g., NVM memory) .

[0075] For example, the default resource and resource sets may be static and the index to point to a resource or a resource set among multiple default configurations is provided in downlink signaling (L1 / L2) may be dynamically set. In another example, the default resource and resource sets may be static, and a delta offset related to the default resource or resource set is provided in DL signaling (L1 / L2) may be dynamically set.

[0076] If there are grants to multiple resources, the device may use grant selection rules to determine which resource to use. The following may be used for grant selection rules for the embodiments herein. In some embodiments, the algorithm to choose one among multiple resources can be fixed (as specified rule in the 3GPP specification) , or can be provided in a configuration or pre-configuration. The following provide algorithms and rules for ambient IoT device grant selection in accordance with some embodiments.

[0077] In some embodiments, if multiple candidate resources are indicated explicitly or implicitly in a R2D transmission to be used to respond a single R2D message, the device may randomly select one resource to transmit its triggered response. In some embodiments, if multiple candidate resources are indicated explicitly or implicitly in a R2D transmission to be used to respond a single R2D message, the device may select a  resource based on its device ID, (e.g., deviceID mod N, N is the number of multiple choices) . In some embodiments, if multiple candidate resources are indicated explicitly or implicitly in a R2D transmission to be used to respond a single R2D message, each resource may be associated with a threshold, and the device may only use the resource after threshold condition is passed. For example, a random number generator provides a number exceeding the threshold.

[0078] In some embodiments, by default, if the number of uplink resources is equal to the number of R2D messages multiplexed, then the correspondence indication can be omitted by assuming the response for each message will take the uplink resource sequentially. For example, the first resource / slot may be for responding the first message, the 2nd resource may be for responding the 2nd message, etc. The ambient IoT device may follow this rule to choose the grant.

[0079] In some embodiments, if an ambient IoT device found its device ID or random ID match the trigger of multiple R2D messages, and there are different uplink resources scheduled corresponding to those different D2R messages indicated, the device can choose the very first uplink resource; or the access stratum (AS) layer can decide which message to respond (e.g., a unique match is prioritized over a prefix / mask match.

[0080] There may be situations where rescheduling (e.g., sending another R2D message with another resource grant) may be triggered. There are four possible outcome of a scheduled uplink grant. Case 1 may be when the is used, and the R2D message is received correctly. Case 2 may be when the grant unused (wasted) . Case 3 may be when the grant is used, and R2D message is received correctly but the device indicates it has more data to send (e.g., the uplink grant is not big enough) . Case 4 may be when the grant used, but a collision is detected.

[0081] In Case 2, 3, and 4, rescheduled grants are needed to complete the exchange. These cases trigger rescheduling. Note that there may not be AS layer retransmission, so rescheduling means the transaction is to be re-initiated by the reader. To allow the Case 3 to be triggered, the device may send an indication to reader to solicit a grant. For example, the device may explicitly indicate that there is more data that it needs to send. For instance, the device may use a 1-bt indication in the D2R transmission to indicate that another grant is needed. In other embodiments, an implicit approach may be used. For example, the device may use the length field in MAC header to indicate the total size of D2R message. If the reader determines that the total size of the D2R is larger than the  actual data included in the MAC PDU, the reader may conclude that the device has more information to send.

[0082] Based on the determinization that additional information is to be sent by the device, the reader may trigger rescheduling (e.g., the transaction is re-initiated by the reader) . The reader may send another R2D message with a resource grant for the additional data. In some embodiments, the rescheduling may associate the D2R grant with the device ID, not a downlink message as previously discussed. This may allow the reader to send the uplink grant allocation without sending a R2D message again.

[0083] It is also possible that in Case 1, rescheduling is triggered because the reader wants to get more results. For example, for inventory there may be a desire for rescheduling because potential intended devices were not available at the last round of transmissions. Such a rescheduling may also be deemed as a “new” procedure with new grants. This type of rescheduling may be combined with Case 4 triggers to generate a single new R2D transmission to trigger a response.

[0084] For rescheduling, uplink grant allocation may be handled differently based on the case. For example, for handling case 2 (e.g., wasted / unused uplink grant) , if the associated uplink grant corresponding to a R2D message remains unused; or if at least a certain portion of multiple associate uplink grants of a R2D message remain unused and no collision is detected in the grant used; then the reader may resend such a R2D message (with rescheduled corresponding UL grant) after a Back-off period. The back-off time may be set to be long enough to allow device (s) to conduct energy harvesting to be in an ON state. Different device types (1, 2a, or 2b) may be associated with different back off timer settings. The reader may resend the R2D message at a time based on the device type.

[0085] For case 4 where a collision is detected in at least one uplink grant corresponding to a R2D message, then it may be clear to the reader that one more try can help get some meaningful response. Accordingly, the reader may send another R2D message, and along with the R2D message in the next round the reader may allocate more grants than the number of grants where collision was detected in the last round to mitigate collisions. In some embodiments the reader may increase the number of grants linearly. For example, the reader may increment the number of grants by a step size in each round if collision is detected in the prior round. In some embodiments the reader may increase the number of grants Exponentially. For example, the reader may double  the number of grants each round if collision is detected in the prior round. The reader can dedicate an uplink grant to each R2D message or even each potential responding device ID to resolve collisions.

[0086] In some embodiments, reader implementation may be up to network implementation. At least for UE reader (Topology 2) , some of the above mechanism may rely on certain Uu configuration (e.g., in RRC signaling) . For example, the network node may send a reader UE backoff time configurations, a ratio of unused resource in a group of allocated resource to trigger backoff, an indication of collision resolution method (e.g., linear increase or exponential increase) , and associated parameters (e.g., step size, scale factor) .

[0087] FIG. 12 illustrates a method 1200 for a reader apparatus, according to embodiments herein. The illustrated method 1200 includes encoding 1202 a R2D transmission comprising: one or more D2R resource grants that indicate resources for D2R transmissions from one or more ambient IoT devices, and one or more R2D messages for the one or more ambient IoT devices. The method 1200 further includes sending 1204 the R2D transmission to the one or more ambient IoT devices. The method 1200 further includes receiving 1206 the D2R transmissions on the resources indicated by the one or more D2R resource grants.

[0088] In some embodiments of the method 1200, the one or more D2R resource grants are indicated to be used by one or more of the ambient IoT devices to respond to one particular R2D message included in R2D transmission.

[0089] In some embodiments of the method 1200, the one or more D2R resource grants are indicated in one or more fields included in the R2D transmission, wherein the one or more fields comprise at least one of L1 R2D control information, L2 MAC header, L2 MAC Control element, and L2 MAC subheader.

[0090] In some embodiments of the method 1200, the D2R resource grant can be indicated as a single D2R resource grant to be used by one or more of the ambient-IoT devices.

[0091] In some embodiments of the method 1200, the D2R resource grants comprise one or more shared grants in consecutive or non-consecutive slots to be used by one or more of the ambient-IoT devices.

[0092] In some embodiments of the method 1200, the one or more D2R resource grants are located in MAC subheaders, and

[0093] wherein each of the one or more D2R resource grants is paired directly with a R2D message corresponding to each of the MAC sub-headers.

[0094] In some embodiments of the method 1200, the one or more D2R resource grants include index values, and wherein subheaders of the R2D transmission include the index values to indicate which of the resources that an ambient IoT device should use when responding to a corresponding downlink command.

[0095] In some embodiments of the method 1200, the D2R resource grants are associated directly with device IDs.

[0096] In some embodiments of the method 1200, a first parameter of the resources is indicated dynamically and a second parameter of the resources is indicated statically.

[0097] In some embodiments, the method 1200 further comprises sending a second R2D message based on an indication in the D2R transmissions that at least one of the ambient IoT devices has more data to send.

[0098] In some embodiments, the method 1200 further comprises determining that one of the D2R resource grants remains unused, and resending the R2D transmission after a back-off period, wherein the back-off period is based on an ambient IoT device type.

[0099] In some embodiments, the method 1200 further comprises detecting a collision between the D2R transmissions, allocating additional grants, and sending a second R2D transmission with the additional grants.

[0100] In some embodiments, the method 1200 further comprises receiving, from a network node, a configuration for at least one of a back-off time, a ratio of unused resources in a group of allocated resources to trigger back-off, and an indication of whether the reader apparatus should increase additional grants linearly or exponentially in case of collisions.

[0101] FIG. 13 illustrates a method 1300 for an ambient IoT device, according to embodiments herein. The illustrated method 1300 includes receiving 1302 a R2D transmission from a reader. The method 1300 further includes decoding 1304 the R2D transmission, wherein the R2D transmission comprises: one or more D2R resource grants that indicate resources for D2R transmissions, and one or more R2D messages. The method 1300 further includes determining 1306 which of the one or more R2D messages to respond to, and which resources to use for a D2R transmission. The method 1300  further includes sending 1308 the D2R transmission on one of the resources indicated by the one or more D2R resource grants.

[0102] In some embodiments of the method 1300, the one or more D2R resource grants are indicated to be used by one or more of the ambient IoT devices to respond to one particular R2D message included in R2D transmission.

[0103] In some embodiments of the method 1300, the one or more D2R resource grants are indicated in one or more fields included in the R2D transmission, wherein the one or more fields comprise at least one of L1 R2D control information, L2 MAC header, L2 MAC Control element, and L2 MAC subheader.

[0104] In some embodiments of the method 1300, the D2R resource grant can be indicated as a single D2R resource grant to be used by one or more of the ambient-IoT devices.

[0105] In some embodiments of the method 1300, the D2R resource grants comprise one or more shared grants in consecutive or non-consecutive slots to be used by one or more of the ambient-IoT devices.

[0106] In some embodiments of the method 1300, the one or more D2R resource grants are located in MAC subheaders, and wherein each of the one or more D2R resource grants is paired directly with a R2D message corresponding to each of the MAC sub-headers.

[0107] In some embodiments of the method 1300, the one or more D2R resource grants include index values, and wherein subheaders of the R2D transmission include the index values to indicate which of the resources that an ambient IoT device should use when responding to a corresponding downlink command.

[0108] In some embodiments of the method 1300, the D2R resource grants are associated directly with device IDs.

[0109] In some embodiments of the method 1300, a first parameter of the resources is indicated dynamically and a second parameter of the resources is indicated statically.

[0110] In some embodiments, the method 1300 further comprises including an indication in the D2R transmissions that there is more data to send, and receiving a second R2D message based on the indication with additional resources.

[0111] In some embodiments, the method 1300 further comprises randomly selecting one of the resources to send the D2R transmission.

[0112] In some embodiments, the method 1300 further comprises selecting one of the resources based on a device ID to send the D2R transmission.

[0113] In some embodiments of the method 1300, each of the resources is associated with a threshold condition, and the resources can only be used after the threshold condition is passed.

[0114] FIG. 14 illustrates an example architecture of a wireless communication system 1400, according to embodiments disclosed herein. The following description is provided for an example wireless communication system 1400 that operates in conjunction with the LTE system standards and / or 5G or NR system standards as provided by 3GPP technical specifications.

[0115] As shown by FIG. 14, the wireless communication system 1400 includes UE 1402 and UE 1404 (although any number of UEs may be used) . In this example, the UE 1402 and the UE 1404 are illustrated as smartphones (e.g., handheld touchscreen mobile computing devices connectable to one or more cellular networks) , but may also comprise any mobile or non-mobile computing device configured for wireless communication.

[0116] The UE 1402 and UE 1404 may be configured to communicatively couple with a RAN 1406. In embodiments, the RAN 1406 may be NG-RAN, E-UTRAN, etc. The UE 1402 and UE 1404 utilize connections (or channels) (shown as connection 1408 and connection 1410, respectively) with the RAN 1406, each of which comprises a physical communications interface. The RAN 1406 can include one or more base stations (such as base station 1412 and base station 1414) that enable the connection 1408 and connection 1410.

[0117] In this example, the connection 1408 and connection 1410 are air interfaces to enable such communicative coupling, and may be consistent with RAT (s) used by the RAN 1406, such as, for example, an LTE and / or NR.

[0118] In some embodiments, the UE 1402 and UE 1404 may also directly exchange communication data via a sidelink interface 1416. The UE 1404 is shown to be configured to access an access point (shown as AP 1418) via connection 1420. By way of example, the connection 1420 can comprise a local wireless connection, such as a connection consistent with any IEEE 802.11 protocol, wherein the AP 1418 may comprise a router. In this example, the AP 1418 may be connected to another network (for example, the Internet) without going through a CN 1424.

[0119] In embodiments, the UE 1402 and UE 1404 can be configured to communicate using orthogonal frequency division multiplexing (OFDM) communication signals with each other or with the base station 1412 and / or the base station 1414 over a multicarrier communication channel in accordance with various communication techniques, such as, but not limited to, an orthogonal frequency division multiple access (OFDMA) communication technique (e.g., for downlink communications) or a single carrier frequency division multiple access (SC-FDMA) communication technique (e.g., for uplink and ProSe or sidelink communications) , although the scope of the embodiments is not limited in this respect. The OFDM signals can comprise a plurality of orthogonal subcarriers.

[0120] In some embodiments, all or parts of the base station 1412 or base station 1414 may be implemented as one or more software entities running on server computers as part of a virtual network. In addition, or in other embodiments, the base station 1412 or base station 1414 may be configured to communicate with one another via interface 1422. In embodiments where the wireless communication system 1400 is an LTE system (e.g., when the CN 1424 is an EPC) , the interface 1422 may be an X2 interface. The X2 interface may be defined between two or more base stations (e.g., two or more eNBs and the like) that connect to an EPC, and / or between two eNBs connecting to the EPC. In embodiments where the wireless communication system 1400 is an NR system (e.g., when CN 1424 is a 5GC) , the interface 1422 may be an Xn interface. The Xn interface is defined between two or more base stations (e.g., two or more gNBs and the like) that connect to 5GC, between a base station 1412 (e.g., a gNB) connecting to 5GC and an eNB, and / or between two eNBs connecting to 5GC (e.g., CN 1424) .

[0121] The RAN 1406 is shown to be communicatively coupled to the CN 1424. The CN 1424 may comprise one or more network elements 1426, which are configured to offer various data and telecommunications services to customers / subscribers (e.g., users of UE 1402 and UE 1404) who are connected to the CN 1424 via the RAN 1406. The components of the CN 1424 may be implemented in one physical device or separate physical devices including components to read and execute instructions from a machine-readable or computer-readable medium (e.g., a non-transitory machine-readable storage medium) .

[0122] In embodiments, the CN 1424 may be an EPC, and the RAN 1406 may be connected with the CN 1424 via an S1 interface 1428. In embodiments, the S1 interface  1428 may be split into two parts, an S1 user plane (S1-U) interface, which carries traffic data between the base station 1412 or base station 1414 and a serving gateway (S-GW) , and the S1-MME interface, which is a signaling interface between the base station 1412 or base station 1414 and mobility management entities (MMEs) .

[0123] In embodiments, the CN 1424 may be a 5GC, and the RAN 1406 may be connected with the CN 1424 via an NG interface 1428. In embodiments, the NG interface 1428 may be split into two parts, an NG user plane (NG-U) interface, which carries traffic data between the base station 1412 or base station 1414 and a user plane function (UPF) , and the S1 control plane (NG-C) interface, which is a signaling interface between the base station 1412 or base station 1414 and access and mobility management functions (AMFs) .

[0124] Generally, an application server 1430 may be an element offering applications that use internet protocol (IP) bearer resources with the CN 1424 (e.g., packet switched data services) . The application server 1430 can also be configured to support one or more communication services (e.g., VoIP sessions, group communication sessions, etc. ) for the UE 1402 and UE 1404 via the CN 1424. The application server 1430 may communicate with the CN 1424 through an IP communications interface 1432.

[0125] FIG. 15 illustrates a system 1500 for performing signaling 1534 between a wireless device 1502 and a network device 1518, according to embodiments disclosed herein. The system 1500 may be a portion of a wireless communications system as herein described. The wireless device 1502 may be, for example, a UE of a wireless communication system. The network device 1518 may be, for example, a base station (e.g., an eNB or a gNB) of a wireless communication system.

[0126] The wireless device 1502 may include one or more processor (s) 1504. The processor (s) 1504 may execute instructions such that various operations of the wireless device 1502 are performed, as described herein. The processor (s) 1504 may include one or more baseband processors implemented using, for example, a central processing unit (CPU) , a digital signal processor (DSP) , an application specific integrated circuit (ASIC) , a controller, a field programmable gate array (FPGA) device, another hardware device, a firmware device, or any combination thereof configured to perform the operations described herein.

[0127] The wireless device 1502 may include a memory 1506. The memory 1506 may be a non-transitory computer-readable storage medium that stores instructions 1508  (which may include, for example, the instructions being executed by the processor (s) 1504) . The instructions 1508 may also be referred to as program code or a computer program. The memory 1506 may also store data used by, and results computed by, the processor (s) 1504.

[0128] The wireless device 1502 may include one or more transceiver (s) 1510 that may include radio frequency (RF) transmitter circuitry and / or receiver circuitry that use the antenna (s) 1512 of the wireless device 1502 to facilitate signaling (e.g., the signaling 1534) to and / or from the wireless device 1502 with other devices (e.g., the network device 1518) according to corresponding RATs.

[0129] The wireless device 1502 may include one or more antenna (s) 1512 (e.g., one, two, four, or more) . For embodiments with multiple antenna (s) 1512, the wireless device 1502 may leverage the spatial diversity of such multiple antenna (s) 1512 to send and / or receive multiple different data streams on the same time and frequency resources. This behavior may be referred to as, for example, multiple input multiple output (MIMO) behavior (referring to the multiple antennas used at each of a transmitting device and a receiving device that enable this aspect) . MIMO transmissions by the wireless device 1502 may be accomplished according to precoding (or digital beamforming) that is applied at the wireless device 1502 that multiplexes the data streams across the antenna (s) 1512 according to known or assumed channel characteristics such that each data stream is received with an appropriate signal strength relative to other streams and at a desired location in the spatial domain (e.g., the location of a receiver associated with that data stream) . Certain embodiments may use single user MIMO (SU-MIMO) methods (where the data streams are all directed to a single receiver) and / or multi user MIMO (MU-MIMO) methods (where individual data streams may be directed to individual (different) receivers in different locations in the spatial domain) .

[0130] In certain embodiments having multiple antennas, the wireless device 1502 may implement analog beamforming techniques, whereby phases of the signals sent by the antenna (s) 1512 are relatively adjusted such that the (joint) transmission of the antenna (s) 1512 can be directed (this is sometimes referred to as beam steering) .

[0131] The wireless device 1502 may include one or more interface (s) 1514. The interface (s) 1514 may be used to provide input to or output from the wireless device 1502. For example, a wireless device 1502 that is a UE may include interface (s) 1514 such as microphones, speakers, a touchscreen, buttons, and the like in order to allow for  input and / or output to the UE by a user of the UE. Other interfaces of such a UE may be made up of transmitters, receivers, and other circuitry (e.g., other than the transceiver (s) 1510 / antenna (s) 1512 already described) that allow for communication between the UE and other devices and may operate according to known protocols (e.g.,  and the like) .

[0132] The wireless device 1502 may include a resource scheduling module 1516. The resource scheduling module 1516 may be implemented via hardware, software, or combinations thereof. For example, the resource scheduling module 1516 may be implemented as a processor, circuit, and / or instructions 1508 stored in the memory 1506 and executed by the processor (s) 1504. In some examples, the resource scheduling module 1516 may be integrated within the processor (s) 1504 and / or the transceiver (s) 1510. For example, the resource scheduling module 1516 may be implemented by a combination of software components (e.g., executed by a DSP or a general processor) and hardware components (e.g., logic gates and circuitry) within the processor (s) 1504 or the transceiver (s) 1510.

[0133] The resource scheduling module 1516 may be used for various aspects of the present disclosure, for example, aspects of FIGS. 1-12.

[0134] The network device 1518 may include one or more processor (s) 1520. The processor (s) 1520 may execute instructions such that various operations of the network device 1518 are performed, as described herein. The processor (s) 1520 may include one or more baseband processors implemented using, for example, a CPU, a DSP, an ASIC, a controller, an FPGA device, another hardware device, a firmware device, or any combination thereof configured to perform the operations described herein.

[0135] The network device 1518 may include a memory 1522. The memory 1522 may be a non-transitory computer-readable storage medium that stores instructions 1524 (which may include, for example, the instructions being executed by the processor (s) 1520) . The instructions 1524 may also be referred to as program code or a computer program. The memory 1522 may also store data used by, and results computed by, the processor (s) 1520.

[0136] The network device 1518 may include one or more transceiver (s) 1526 that may include RF transmitter circuitry and / or receiver circuitry that use the antenna (s) 1528 of the network device 1518 to facilitate signaling (e.g., the signaling 1534) to and / or from  the network device 1518 with other devices (e.g., the wireless device 1502) according to corresponding RATs.

[0137] The network device 1518 may include one or more antenna (s) 1528 (e.g., one, two, four, or more) . In embodiments having multiple antenna (s) 1528, the network device 1518 may perform MIMO, digital beamforming, analog beamforming, beam steering, etc., as has been described.

[0138] The network device 1518 may include one or more interface (s) 1530. The interface (s) 1530 may be used to provide input to or output from the network device 1518. For example, a network device 1518 that is a base station may include interface (s) 1530 made up of transmitters, receivers, and other circuitry (e.g., other than the transceiver (s) 1526 / antenna (s) 1528 already described) that enables the base station to communicate with other equipment in a core network, and / or that enables the base station to communicate with external networks, computers, databases, and the like for purposes of operations, administration, and maintenance of the base station or other equipment operably connected thereto.

[0139] The network device 1518 may include a resource scheduling module 1532. The resource scheduling module 1532 may be implemented via hardware, software, or combinations thereof. For example, the resource scheduling module 1532 may be implemented as a processor, circuit, and / or instructions 1524 stored in the memory 1522 and executed by the processor (s) 1520. In some examples, the resource scheduling module 1532 may be integrated within the processor (s) 1520 and / or the transceiver (s) 1526. For example, the resource scheduling module 1532 may be implemented by a combination of software components (e.g., executed by a DSP or a general processor) and hardware components (e.g., logic gates and circuitry) within the processor (s) 1520 or the transceiver (s) 1526.

[0140] The resource scheduling module 1532 may be used for various aspects of the present disclosure, for example, aspects of FIGS. 1-12.

[0141] Embodiments contemplated herein include an apparatus comprising means to perform one or more elements of the method 1200. This apparatus may be, for example, an apparatus of a UE (such as a wireless device 1502 that is a UE, as described herein) .

[0142] Embodiments contemplated herein include one or more non-transitory computer-readable media comprising instructions to cause an electronic device, upon execution of the instructions by one or more processors of the electronic device, to  perform one or more elements of the method 1200. This non-transitory computer-readable media may be, for example, a memory of a UE (such as a memory 1506 of a wireless device 1502 that is a UE, as described herein) .

[0143] Embodiments contemplated herein include an apparatus comprising logic, modules, or circuitry to perform one or more elements of the method 1200. This apparatus may be, for example, an apparatus of a UE (such as a wireless device 1502 that is a UE, as described herein) .

[0144] Embodiments contemplated herein include an apparatus comprising: one or more processors and one or more computer-readable media comprising instructions that, when executed by the one or more processors, cause the one or more processors to perform one or more elements of the method 1200. This apparatus may be, for example, an apparatus of a UE (such as a wireless device 1502 that is a UE, as described herein) .

[0145] Embodiments contemplated herein include a signal as described in or related to one or more elements of the method 1200.

[0146] Embodiments contemplated herein include a computer program or computer program product comprising instructions, wherein execution of the program by a processor is to cause the processor to carry out one or more elements of the method 1200. The processor may be a processor of a UE (such as a processor (s) 1504 of a wireless device 1502 that is a UE, as described herein) . These instructions may be, for example, located in the processor and / or on a memory of the UE (such as a memory 1506 of a wireless device 1502 that is a UE, as described herein) .

[0147] Embodiments contemplated herein include an apparatus comprising means to perform one or more elements of the method 1300. This apparatus may be, for example, an apparatus of a base station (such as a network device 1518 that is a base station, as described herein) .

[0148] Embodiments contemplated herein include one or more non-transitory computer-readable media comprising instructions to cause an electronic device, upon execution of the instructions by one or more processors of the electronic device, to perform one or more elements of the method 1300. This non-transitory computer-readable media may be, for example, a memory of a base station (such as a memory 1522 of a network device 1518 that is a base station, as described herein) .

[0149] Embodiments contemplated herein include an apparatus comprising logic, modules, or circuitry to perform one or more elements of the method 1300. This  apparatus may be, for example, an apparatus of a base station (such as a network device 1518 that is a base station, as described herein) .

[0150] Embodiments contemplated herein include an apparatus comprising: one or more processors and one or more computer-readable media comprising instructions that, when executed by the one or more processors, cause the one or more processors to perform one or more elements of the method 1300. This apparatus may be, for example, an apparatus of a base station (such as a network device 1518 that is a base station, as described herein) .

[0151] Embodiments contemplated herein include a signal as described in or related to one or more elements of the method 1300.

[0152] Embodiments contemplated herein include a computer program or computer program product comprising instructions, wherein execution of the program by a processing element is to cause the processing element to carry out one or more elements of the method 1300. The processor may be a processor of a base station (such as a processor (s) 1520 of a network device 1518 that is a base station, as described herein) . These instructions may be, for example, located in the processor and / or on a memory of the base station (such as a memory 1522 of a network device 1518 that is a base station, as described herein) .

[0153] For one or more embodiments, at least one of the components set forth in one or more of the preceding figures may be configured to perform one or more operations, techniques, processes, and / or methods as set forth herein. For example, a baseband processor as described herein in connection with one or more of the preceding figures may be configured to operate in accordance with one or more of the examples set forth herein. For another example, circuitry associated with a UE, base station, network element, etc. as described above in connection with one or more of the preceding figures may be configured to operate in accordance with one or more of the examples set forth herein.

[0154] Any of the above described embodiments may be combined with any other embodiment (or combination of embodiments) , unless explicitly stated otherwise. The foregoing description of one or more implementations provides illustration and description, but is not intended to be exhaustive or to limit the scope of embodiments to the precise form disclosed. Modifications and variations are possible in light of the above teachings or may be acquired from practice of various embodiments.

[0155] Embodiments and implementations of the systems and methods described herein may include various operations, which may be embodied in machine-executable instructions to be executed by a computer system. A computer system may include one or more general-purpose or special-purpose computers (or other electronic devices) . The computer system may include hardware components that include specific logic for performing the operations or may include a combination of hardware, software, and / or firmware.

[0156] It should be recognized that the systems described herein include descriptions of specific embodiments. These embodiments can be combined into single systems, partially combined into other systems, split into multiple systems or divided or combined in other ways. In addition, it is contemplated that parameters, attributes, aspects, etc. of one embodiment can be used in another embodiment. The parameters, attributes, aspects, etc. are merely described in one or more embodiments for clarity, and it is recognized that the parameters, attributes, aspects, etc. can be combined with or substituted for parameters, attributes, aspects, etc. of another embodiment unless specifically disclaimed herein.

[0157] It is well understood that the use of personally identifiable information should follow privacy policies and practices that are generally recognized as meeting or exceeding industry or governmental requirements for maintaining the privacy of users. In particular, personally identifiable information data should be managed and handled so as to minimize risks of unintentional or unauthorized access or use, and the nature of authorized use should be clearly indicated to users.

[0158] Although the foregoing has been described in some detail for purposes of clarity, it will be apparent that certain changes and modifications may be made without departing from the principles thereof. It should be noted that there are many alternative ways of implementing both the processes and apparatuses described herein. Accordingly, the present embodiments are to be considered illustrative and not restrictive, and the description is not to be limited to the details given herein, but may be modified within the scope and equivalents of the appended claims.

Claims

1.A method for a reader apparatus, the method comprising:encoding a reader-to-device (R2D) transmission comprising:one or more device-to-reader (D2R) resource grants that indicate resources for D2R transmissions from one or more ambient internet of things (IoT) devices, andone or more R2D messages for the one or more ambient IoT devices;sending the R2D transmission to the one or more ambient IoT devices; andreceiving the D2R transmissions on the resources indicated by the one or more D2R resource grants.2.The method of claim 1, wherein the one or more D2R resource grants are indicated to be used by one or more of the ambient IoT devices to respond to one particular R2D message included in R2D transmission.3.The method of claim 1, wherein the one or more D2R resource grants are indicated in one or more fields included in the R2D transmission, wherein the one or more fields comprise at least one of layer 1 (L1) R2D control information, layer 2 (L2) Medium Access Control (MAC) header, L2 MAC Control element, and L2 MAC subheader.4.The method of claim 1, wherein the D2R resource grant can be indicated as a single D2R resource grant to be used by one or more of the ambient-IoT devices.5.The method of claim 1, wherein the D2R resource grants comprise one or more shared grants in consecutive or non-consecutive slots to be used by one or more of the ambient-IoT devices.6.The method of claim 1, wherein the one or more D2R resource grants are located in Medium Access Control (MAC) subheaders, andwherein each of the one or more D2R resource grants is paired directly with a R2D message corresponding to each of the MAC sub-headers.7.The method of claim 1, wherein the one or more D2R resource grants include index values, andwherein subheaders of the R2D transmission include the index values to indicate which of the resources that an ambient IoT device should use when responding to a corresponding downlink command.8.The method of claim 1, wherein the D2R resource grants are associated directly with device identifiers (IDs) .9.The method of claim 1, wherein a first parameter of the resources is indicated dynamically and a second parameter of the resources is indicated statically.10.The method of claim 1, further comprising sending a second R2D message based on an indication in the D2R transmissions that at least one of the ambient IoT devices has more data to send.11.The method of claim 1, further comprising:determining that one of the D2R resource grants remains unused; andresending the R2D transmission after a back-off period, wherein the back-off period is based on an ambient IoT device type.12.The method of claim 1, further comprising:detecting a collision between the D2R transmissions;allocating additional grants; andsending a second R2D transmission with the additional grants.13.The method of claim 1, further comprising receiving, from a network node, a configuration for at least one of a back-off time, a ratio of unused resources in a group of allocated resources to trigger back-off, and an indication of whether the reader apparatus should increase additional grants linearly or exponentially in case of collisions.14.A method for an ambient internet of things (IoT) device, the method comprising:receiving a reader-to-device (R2D) transmission from a reader;decoding the R2D transmission, wherein the R2D transmission comprises:one or more device-to-reader (D2R) resource grants that indicate resources for D2R transmissions, andone or more R2D messages;determining which of the one or more R2D messages to respond to, and which resources to use for a D2R transmission;sending the D2R transmission on one of the resources indicated by the one or more D2R resource grants.15.The method of claim 14, wherein the one or more D2R resource grants are indicated to be used by one or more of the ambient IoT devices to respond to one particular R2D message included in R2D transmission.16.The method of claim 14, wherein the one or more D2R resource grants are indicated in one or more fields included in the R2D transmission, wherein the one or more fields comprise at least one of layer 1 (L1) R2D control information, layer 2 (L2) Medium Access Control (MAC) header, L2 MAC Control element, and L2 MAC subheader.17.The method of claim 14, wherein the D2R resource grant can be indicated as a single D2R resource grant to be used by one or more of the ambient-IoT devices.18.The method of claim 14, wherein the D2R resource grants comprise one or more shared grants in consecutive or non-consecutive slots to be used by one or more of the ambient-IoT devices.19.The method of claim 14, wherein the one or more D2R resource grants are located in Medium Access Control (MAC) subheaders, andwherein each of the one or more D2R resource grants is paired directly with a R2D message corresponding to each of the MAC sub-headers.20.The method of claim 14, wherein the one or more D2R resource grants include index values, andwherein subheaders of the R2D transmission include the index values to indicate which of the resources that an ambient IoT device should use when responding to a corresponding downlink command.21.The method of claim 14, wherein the D2R resource grants are associated directly with device identifiers (IDs) .22.The method of claim 14, wherein a first parameter of the resources is indicated dynamically and a second parameter of the resources is indicated statically.23.The method of claim 14, further comprising:including an indication in the D2R transmissions that there is more data to send; andreceiving a second R2D message based on the indication with additional resources.24.The method of claim 14, further comprising randomly selecting one of the resources to send the D2R transmission.25.The method of claim 14, further comprising selecting one of the resources based on a device identifier (ID) to send the D2R transmission.26.The method of claim 14, wherein each of the resources is associated with a threshold condition, and the resources can only be used after the threshold condition is passed.27.An apparatus comprising means to perform the method of any of claim 1 to claim 26.28.A computer-readable media comprising instructions to cause an electronic device, upon execution of the instructions by one or more processors of the electronic device, to perform the method of any of claim 1 to claim 26.29.A computer-readable media comprising instructions to cause an electronic device, upon execution of the instructions by one or more processors of the electronic device, to perform the method of any of claim 1 to claim 26.30.An apparatus comprising logic, modules, or circuitry to perform the method of any of claim 1 to claim 26.31.A system for providing wireless communication comprising means to perform the method of any of claim 1 to claim 26.32.A baseband processor for a user equipment (UE) that is configured to cause the UE to perform one or more elements of the method of any of claims 1-26.

Images