Methods and apparatuses for charging ambient internet of things devices

Abstract

Embodiments of the present disclosure relate to method and apparatus for charging ambient internet of things devices. A first communication device may: determine whether to charge by receiving a signal from a second communication device; and in response to determining to charge, charge for a duration based on the received signal.

Description

METHODS AND APPARATUSES FOR CHARGING AMBIENT INTERNET OF THINGS DEVICESTECHNICAL FIELD

[0001] Embodiments of the present disclosure generally relate to wireless communication technology, and more particularly to Internet of Things (IoT) technology.BACKGROUND

[0002] A wireless communication system may include one or multiple network communication devices, such as base stations, which may support wireless communication for one or multiple user communication devices, which may be otherwise known as user equipment (UE) , or other suitable terminology. The wireless communication system may support wireless communication with one or multiple user communication devices by utilizing resources of the wireless communication system (e.g., time resources (e.g., symbols, slots, subframes, frames, or the like) ) or frequency resources (e.g., subcarriers, carriers, or the like) . Additionally, the wireless communication system may support wireless communication across various radio access technologies including third generation (3G) radio access technology, fourth generation (4G) radio access technology, fifth generation (5G) (which is also known as new radio (NR) ) 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 embodiments of the present disclosure provide a first communication device. The first communication device may include at least one memory; and at least one processor coupled with the at least one memory and configured to cause the first communication device to: determine whether to charge by receiving a signal from a second communication device; and in response to determining to charge, charge for a duration based on the received signal.

[0005] In some embodiments, the at least one processor is configured to cause the first communication device to determine to charge based on one or more of the following: an energy level of the first communication device being insufficient; the first communication device being in an inactive status; receiving a charging activation command; receiving a charging notification indicating that the second communication device is transmitting the signal; an on-charge duration in a discontinuous charging reception (DCX) cycle; and receiving signaling indicating a time domain resource for the signal, a frequency domain resource for the signal, or both.

[0006] In some embodiments, the at least one processor is further configured to cause the first communication device to determine not to charge based on one or more of the following: a resource for uplink (UL) overlaps a resource for the signal in a time domain; a resource for downlink (DL) overlaps the resource for the signal in the time domain; or UL data is available for transmission and a resource for the UL data overlaps the resource for the signal in the time domain.

[0007] In some embodiments, the at least one processor is further configured to cause the first communication device to in response to determining not to charge, perform one or more of the following: transmitting a UL signal for communication on a UL resource;  receiving a DL signal for communication on a DL resource; or transmitting pending UL data on a resource for the UL data.

[0008] In some embodiments, the at least one processor is further configured to cause the first communication device to, in response to determining not to charge, perform one or more of the following: in the case that a UL resource overlaps a resource for the signal in a time domain, transmitting a UL signal for communication on the UL resource; in the case that a DL resource overlaps the resource for the signal in the time domain, receiving a DL signal for communication on the DL resource; and in the case that UL data is available for transmission and a resource for the UL data overlaps the resource for the signal in the time domain, transmitting the UL data on the resource for the UL data.

[0009] In some embodiments, the at least one processor is configured to cause the first communication device to receive the signal based on a charging configuration. The charging configuration indicates one or more of the following: an absolute radio-frequency channel number (ARFCN) of a carrier frequency on which the signal is received; a bandwidth of a carrier or a bandwidth part (BWP) on which the signal is received; a frequency domain resource for the signal; a time domain resource for the signal; a set of beams for receiving the signal; and a transmission period of the signal in units of beam transmission period.

[0010] In some embodiments, the time domain resource is indicated by one or more of the following: a first time offset associated with a start of the duration; a second time offset associated with an end of the duration; a length of the duration; a third time offset with respect to a timing acquisition signal block (TASB) or a synchronization signal (SS) ; and a DCX cycle, which is indicated by one or more of: a length of the duration in the DCX cycle, a length of the DCX cycle, and a time offset associated with the duration in the DCX cycle.

[0011] In some embodiments, receiving the signal includes one or more of the following: receiving the signal from the first time offset before a paging occasion or from at least the second time offset before the paging occasion; receiving the signal until an end of the duration, or until a start of a next paging occasion, or until an energy level of the first communication device is sufficient, or until the second time offset  before the paging occasion; receiving the signal from the third time offset later than a start or an end of the TASB or the SS; and receiving the signal from the first time offset before a DL reception or a UL transmission or from at least the second time offset before the DL reception or the UL transmission.

[0012] In some embodiments, the DL reception includes receiving a downlink signal for communication, the UL transmission includes transmitting an uplink signal for communication. In some embodiments, the signal is a wireless signal. In some embodiments, the at least one processor is further configured to cause the first communication device to switch to perform the DL reception or the UL transmission after a time offset from the end of the duration or in response to an energy level of the first communication device is sufficient.

[0013] In some embodiments, the at least one processor is further configured to cause the first communication device to report one or more of the following to the second communication device: whether the first communication device is charging or not; an energy status of the first communication device; and an identification of the first communication device.

[0014] In some embodiments, the energy status of the first communication device is reported based on an energy status report configuration. The energy status report configuration indicates one or more of the following: a first energy level threshold for triggering energy status reporting; a second energy level threshold for triggering energy status reporting, wherein the second energy level threshold is higher than the first energy level threshold; a hysteresis value for energy level; a time period for triggering energy status reporting; a reporting periodicity; a threshold for a data volume pending for transmission; a signal condition threshold; a pathloss threshold; a distance threshold; and a value of a prohibit timer.

[0015] In some embodiments, the at least one processor is further configured to cause the first communication device to start a prohibit timer in response to reporting the energy status of the first communication device; and wherein the energy status of the first communication device is reported when the prohibit timer is not running.

[0016] In some embodiments, the at least one processor is further configured to cause  the first communication device to perform one or more of the following: receiving, from the second communication device, a first indication for deactivating or suspending charging; stopping or suspending charging in response to receiving the first indication; receiving, from the second communication device, a second indication for activating or resuming charging; entering into a charging mode in response to receiving the second indication; and receiving, from the second communication device, a third indication indicating support for wireless signal charging or support of an ambient Internet of things (A-IoT) function.

[0017] In some embodiments, the at least one processor is further configured to cause the first communication device to transmit a charging request to the second communication device based on a charging request configuration. The charging request configuration indicates one or more of the following: a first energy level threshold for triggering the charging request; a hysteresis value for energy level; a time period for triggering the charging request; a requesting periodicity; a threshold for a data volume pending for transmission; a signal condition threshold; a pathloss threshold; a distance threshold; beam information for charging; and a value of a prohibit timer.

[0018] In some embodiments, the at least one processor is further configured to cause the first communication device to perform one or more of: starting the prohibit timer in response to transmitting the charging request; transmitting the charging request when the prohibit timer is not running; receiving a charging response from the second communication device in response to the charging request; receiving the signal from a time offset after receiving the charging response or after transmitting the charging request; and receiving the signal at a periodicity and / or for a duration.

[0019] In some embodiments, the at least one processor is further configured to cause the first communication device to: not handling a signal for communication when the first communication device is in a charging mode; allow handling a signal for communication outside the duration when the first communication device is in the charging mode; or allow handling a signal for communication when the first communication device is not in the charging mode.

[0020] In some embodiments, the charging configuration is configured by the second communication device or a core network (CN) entity or is predefined.

[0021] In some embodiments, the energy status report configuration is configured by the second communication device or a CN entity or is predefined.

[0022] Some embodiments of the present disclosure provide a second communication device. The second communication device may include at least one memory; and at least one processor coupled with the at least one memory and configured to cause the second communication device to: determine whether to charge a first communication device; and in response to determining to charge the first communication device, transmit a signal to charge the first communication device in a duration.

[0023] In some embodiments, the at least one processor is further configured to cause the second communication device to receive a message associated with the first communication device from a CN entity or the first communication device, the message including one or more charging requirements for the first communication device.

[0024] In some embodiments, the message indicates one or more of the following: capability information of the first communication device; one or more frequencies for charging the first communication device; a bandwidth range for charging the first communication device; a cycle length for charging the first communication device; a set of beams for charging the first communication device; and a duration length for charging the first communication device.

[0025] In some embodiments, the signal is transmitted based on a charging configuration. The charging configuration indicates one or more of the following: an ARFCN of a carrier frequency on which the signal is transmitted; a bandwidth of a carrier or a BWP on which the signal is transmitted; a frequency domain resource for the signal; a time domain resource for the signal; a set of beams for transmitting the signal; and a transmission period of the signal in units of beam transmission period.

[0026] In some embodiments, the time domain resource is indicated by one or more of the following: a first time offset associated with a start of the duration; a second time offset associated with an end of the duration; a length of the duration; a third time offset with respect to a TASB or an SS; and a DCX cycle, which is indicated by one or more of:a length of the duration in the DCX cycle, a length of the DCX cycle, and a time offset associated with the duration in the DCX cycle.

[0027] In some embodiments, transmitting the signal includes one or more of the following: transmitting the signal from the third time offset after the TASB or the SS; and transmitting the signal from the first time offset before a paging occasion, a DL transmission to the first communication device or a UL reception from the first communication device; or transmitting the signal from at least the second time offset before the paging occasion, the DL transmission to the first communication device or the UL reception from the first communication device.

[0028] In some embodiments, the at least one processor is further configured to cause the second communication device to transmit a postamble at an end of the duration, or transmit a preamble at a start of the duration.

[0029] In some embodiments, the at least one processor is further configured to cause the second communication device to transmit one or more of the following to the first communication device before transmitting the signal: a charging activation command; a charging notification indicating that the second communication device is transmitting the signal; and signaling indicating a time domain resource for the signal, a frequency domain resource for the signal, or both.

[0030] In some embodiments, the at least one processor is further configured to cause the second communication device to receive one or more of the following from the first communication device: an indication indicating whether the first communication device is charging or not; an energy status of the first communication device; and an identification of the first communication device.

[0031] In some embodiments, the at least one processor is further configured to cause the second communication device to perform one or more of the following: transmitting, to the first communication device, a first indication for deactivating or suspending charging; stopping or suspending the transmission of the signal in response to transmitting the first indication; transmitting, to the first communication device, a second indication for activating or resuming charging; and transmitting, to the first communication device, a third indication indicating support for wireless signal charging or support of an A-IoT function.

[0032] In some embodiments, the at least one processor is further configured to cause  the second communication device to receive a charging request from the first communication device.

[0033] In some embodiments, the at least one processor is further configured to cause the second communication device to perform one or more of: transmitting the signal in response to receiving the charging request; transmitting a charging response to the first communication device in response to receiving the charging request; transmitting the signal from a time offset after transmitting the charging response or after receiving the charging request; and transmitting the signal at a periodicity and / or for a duration.

[0034] In some embodiments, the at least one processor is further configured to cause the second communication device to, in response to receiving the indication that the first communication device is not charging or the energy status of the first communication device indicating that an energy level of the first communication device is sufficient, receive a signal for communication from the first communication device or transmit a signal for communication to the first communication device.

[0035] In some embodiments, the at least one processor is further configured to cause the second communication device to transmit one or more configurations of a charging configuration, an energy status report configuration and a charging request configuration to the first communication device; or wherein one or more configurations of the charging configuration, the energy status report configuration and the charging request configuration are predefined.

[0036] In some embodiments, the second communication device is a base station (BS) ; or the second communication device is a device different from the BS; or wherein the second communication device is triggered by the BS to transmit the signal to the first communication device.

[0037] Some embodiments of the present disclosure provide a processor. The processor may include at least one controller coupled with at least one memory and configured to cause the processor to: determine whether to charge by receiving a signal from a second communication device; and in response to determining to charge, charge for a duration based on the received signal.

[0038] Some embodiments of the present disclosure provide a processor. The processor may include at least one controller coupled with at least one memory and configured to cause the processor to: determine whether to charge a first communication device; and in response to determining to charge the first communication device, transmit a signal to charge the first communication device in a duration.

[0039] Some embodiments of the present disclosure provide a method for charging. The method may include: determining whether to charge by receiving a signal from a second communication device; and in response to determining to charge, charging for a duration based on the received signal.

[0040] Some embodiments of the present disclosure provide a method for charging. The method may include: determining whether to charge a first communication device; and in response to determining to charge the first communication device, transmitting a signal to charge the first communication device in a duration.

[0041] Some embodiments of the present disclosure provide an apparatus. According to some embodiments of the present disclosure, the apparatus may include: at least one non-transitory computer-readable medium having stored thereon computer-executable instructions; at least one receiving circuitry; at least one transmitting circuitry; and at least one processor coupled to the at least one non-transitory computer-readable medium, the at least one receiving circuitry and the at least one transmitting circuitry, wherein the at least one non-transitory computer-readable medium and the computer executable instructions may be configured to, with the at least one processor, cause the apparatus to perform a method according to some embodiments of the present disclosure.BRIEF DESCRIPTION OF THE DRAWINGS

[0042] In order to describe the manner in which the advantages and features of the disclosure can be obtained, a description of the disclosure is rendered by reference to specific embodiments thereof, which are illustrated in the appended drawings. These drawings depict only exemplary embodiments of the disclosure and are not therefore to be considered limiting of its scope.

[0043] FIG. 1 illustrates a schematic diagram of a wireless communication system in accordance with some embodiments of the present disclosure;

[0044] FIGs. 2A-2E illustrate exemplary topologies for IoT networks and devices in accordance with some embodiments of the present disclosure;

[0045] FIG. 3 illustrates an exemplary diagram of a charging operation in accordance with some embodiments of the present disclosure;

[0046] FIGs. 4A-4E illustrates examples of charging signals in accordance with some embodiments of the present disclosure;

[0047] FIGs. 5-9 illustrate exemplary procedures for wireless communication in accordance with some embodiments of the present disclosure;

[0048] FIGs. 10 and 11 illustrate flowcharts of wireless communication methods in accordance with some embodiments of the present disclosure;

[0049] FIGs. 12A-12C illustrate block diagrams of exemplary apparatuses in accordance with some embodiments of the present disclosure;

[0050] FIG. 13 illustrates an example of a UE in accordance with some embodiments of the present disclosure;

[0051] FIG. 14 illustrates an example of a processor in accordance with some embodiments of the present disclosure; and

[0052] FIG. 15 illustrates an example of a network equipment (NE) in accordance with some embodiments of the present disclosure.DETAILED DESCRIPTION

[0053] The detailed description of the appended drawings is intended as a description of the preferred embodiments of the present disclosure and is not intended to represent the only form in which the present disclosure may be practiced. It should be understood that the same or equivalent functions may be accomplished by different  embodiments that are intended to be encompassed within the spirit and scope of the present disclosure.

[0054] Reference will now be made in detail to some embodiments of the present disclosure, examples of which are illustrated in the accompanying drawings. To facilitate understanding, embodiments are provided under a specific network architecture (s) and new service scenarios, such as the 3rd generation partnership project (3GPP) 5G NR or 6G, 3GPP LTE, and so on. It is contemplated that along with the developments of network architectures and new service scenarios, all embodiments in the present disclosure are also applicable to similar technical problems; and moreover, the terminologies recited in the present disclosure may change, which should not affect the principles of the present disclosure.

[0055] In recent years, IoT has attracted much attention in the wireless communication world. It is expected that further reductions of size, complexity, and power consumption of IoT devices can enable the deployment of tens or even hundreds of billions of IoT devices for various applications and provide added value across the entire value chain.

[0056] As used herein, the term "ambient IoT device" or "AIoT device" can refer to a device without batteries or with limited energy storage capabilities. For an AIoT device, energy can be provided by harvesting radio waves, light, motion, heat, or any other suitable source. AIoT device can also be called a zero-power terminal, a near-zero power terminal, a passive IoT device, an ambient backscatter communication (AmBC) device, tag, etc. Compared with low-power and wide-coverage services, such as narrow band (NB) IoT, enhanced machine type communication (eMTC) , AIoT is to be designed with ultra-low complexity and ultra-low power consumption, and is orders of magnitude lower than the existing 3GPP technologies. Hence, it is suitable for more application scenarios.

[0057] Considering the limited energy storage capability, an ambient IoT device may not have enough energy to perform data or signaling transmission or reception. The present disclosure provides various methods and apparatuses for charging an ambient IoT device. The proposed solutions can guarantee charging efficiency and reliability.

[0058] FIG. 1 illustrates a schematic diagram of wireless communication system 100 in accordance with some embodiments of the present disclosure.

[0059] The wireless communication system 100 may include one or more NEs 102 (e.g., one or more BSs) , one or more UEs 104, and a CN 106. The wireless communication system 100 may support various radio access technologies. In some implementations, the wireless communication 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 communication system 100 may be a NR network, such as a 5G network, a 5G-Advanced (5G-A) network, or a 5G ultra-wideband (5G-UWB) network. In other implementations, the wireless communication 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) , and IEEE 802.20. The wireless communication system 100 may support radio access technologies beyond 5G, for example, 6G. Additionally, the wireless communication system 100 may support technologies, such as time division multiple access (TDMA) , frequency division multiple access (FDMA) , or code division multiple access (CDMA) , etc.

[0060] The one or more NEs 102 may be dispersed throughout a geographic region to form the wireless communication system 100. One or more of the NEs 102 described herein may be or include or may be referred to as a network node, a base station, 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.

[0061] 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 112 associated with the same or different radio access technologies may overlap, but the different geographic coverage areas may be associated with a different NE 102.

[0062] The one or more UEs 104 may be dispersed throughout a geographic region of the wireless communication 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.

[0063] 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 114 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.

[0064] An NE 102 may support communication with the CN 106, or with another NE 102, or both. For example, an NE 102 may interface with another NE 102 or the CN 106 through one or more backhaul links (e.g., S1, N2, N3 or another 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 NEs 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 radio heads, smart radio heads, or transmission-reception points (TRPs) .

[0065] 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 (AMF) ) functions 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 NEs 102 associated with the CN 106.

[0066] The CN 106 may communicate with a packet data network over one or more backhaul links (e.g., via an S1, N2, N3, 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) .

[0067] In the wireless communication system 100, the NEs 102 and the UEs 104 may use resources of the wireless communication 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 communication) . 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.

[0068] In some embodiments, the NEs 102 may include one or more relay nodes, integrated access and backhaul (IAB) nodes or wireless access backhaul (WAB) nodes which can provide wireless access services for UEs 104. A relay node (or an IAB node or a WAB node) can directly connect to a BS or hop through one or more relay nodes (or one or more IAB or WAB nodes) before reaching the BS.

[0069] One or more numerologies may be supported in the wireless communication 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. A sixth numerology (e.g., μ =5) may be associated with a sixth subcarrier spacing (e.g., 480 kHz) and a normal cyclic prefix. A seventh numerology (e.g., μ=6) may be associated with a seventh subcarrier spacing (e.g., 960 kHz) and a normal cyclic prefix. For ambient IoT communication, additional numerologies (e.g., μ=-1 or μ =-2) may be introduced corresponding to 7.5 kHz or 3.75 kHz respectively.

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

[0071] 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 communication 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., orthogonal frequency-division multiplexing (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.

[0072] In the wireless communication 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 communication 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 communication 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 communication 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.

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

[0074] A UE 104 may include computing devices, such as desktop computers, laptop computers, personal digital assistants (PDAs) , tablet computers, smart televisions (e.g., televisions connected to the Internet) , set-top boxes, game consoles, security systems (including security cameras) , vehicle on-board computers, network devices (e.g., routers, switches, and modems) , or the like. According to some embodiments of the present disclosure, a UE 104 may include a portable wireless communication device, a smart phone, a cellular telephone, a flip phone, a device having a subscriber identity module, a personal computer, a selective call receiver, or any other device that is capable of sending and receiving communication signals on a wireless network. In some embodiments of the present disclosure, a UE 104 includes wearable devices, such as smart watches, fitness bands, optical head-mounted displays, or the like. Moreover, a UE 104 may be referred to as a subscriber unit, a mobile, a mobile station, a user, a terminal, a mobile terminal, a wireless terminal, a fixed terminal, a subscriber station, a user terminal, or a device, or described using other terminology used in the art. A UE 104 may communicate with an NE 102 (e.g., a BS) via UL communication signals. An NE 102 may communicate with a UE 104 via DL communication signals.

[0075] In some embodiments of the present disclosure, an NE 102 and a UE 104 may communicate over licensed spectrums, whereas in some other embodiments, an NE 102 and a UE 104 may communicate over unlicensed spectrums. The present disclosure is not intended to be limited to the implementation of any particular wireless communication system architecture or protocol. Persons skilled in the art should understand that as technology develops and advances, the terminologies described in the present disclosure may change, but should not affect or limit the principles and spirit of the present disclosure.

[0076] In recent years, IoT has attracted much attention in the wireless  communication world. More "things" are expected to be interconnected to improve productivity efficiency and increasing comforts of life. It is expected that further reductions of size, complexity, and power consumption of IoT devices can enable the deployment of tens or even hundreds of billions of IoT devices for various applications and provide added value across the entire value chain. However, it is impossible to power all IoT devices by batteries that need to be replaced or recharged manually, which leads to high maintenance costs, serious environmental issues, and even safety hazards in some use cases (for example, wireless sensors in the electric power and petroleum industries) .

[0077] Most existing wireless communication devices are powered by batteries that need to be replaced or recharged manually. The automation and digitalization of various industries will open up numerous new markets requiring new IoT technologies supporting battery-less devices with no energy storage capability or devices with energy storage that do not need to be replaced or recharged manually. The form factors of such devices must be reasonably small to bring about the validity of target use cases. In some embodiments of the present disclosure, as will be described later, it is proposed that a capacitor may be used to support limited energy storage capability, and that the energy of such IoT devices is provided by the harvesting of radio waves, light, motion, heat, and / or any other power source (s) that may be deemed suitable.

[0078] Considering the limited size and complexity required by practical applications for battery-less devices with no energy storage capability or devices with limited energy storage that do not need to be replaced or recharged manually, the output power of an energy harvester may be, for example, from 1 μW to a few hundreds μW. For example, embodiments of the present disclosure may support ambient IoT devices having the following characteristics:

[0079] i. about 1 μW peak power consumption, energy storage, initial sampling frequency offset (SFO) up to 10X ppm, and neither DL nor UL amplification in the device. The device’s UL transmission may be backscattered on a carrier wave provided externally.

[0080] ii. ≤ a few hundred μW peak power consumption, energy storage, initial SFO up to 10X ppm, and both DL and / or UL amplification in the device. The device’s UL transmission may be generated internally by the device, or be backscattered on a carrier wave provided externally.

[0081] Furthermore, embodiments of the present disclosure may support traffic types, such as device-originated (DO) , device-terminated (DT) , device-originated to autonomous (DO-A) and device-originated to device-terminated triggered (DO-DTT) . In addition, embodiments of the present disclosure may support various use cases, including but not limited to indoor inventory, indoor command, indoor sensors, indoor positioning, outdoor inventory, outdoor sensors, outdoor positioning and outdoor command.

[0082] For convenience, some embodiments of the present disclosure may be described with respect to ambient IoT or ambient IoT devices (e.g., an ambient IoT tag) , and it should be appreciated by persons skilled in the art that these embodiments can also be applied to other IoT devices.

[0083] FIGs. 2A-2E illustrate exemplary topologies for IoT networks and devices in accordance with some embodiments of the present disclosure. In these exemplary topologies, the ambient IoT device may be provided with a carrier wave from another node (s) either inside or outside the topology. The links in each topology may be bidirectional or unidirectional.

[0084] Although elements in each topology such as the BS, UE, assisting node, or intermediate node are described in the singular, the plural is also contemplated. The mixture of indoor and outdoor placements of such nodes is regarded as a network implementation choice. Consideration would need to be taken of potential impact on device or node complexity. In the connectivity topologies, this does not imply the existence of multi-hop assisting or intermediate nodes.

[0085] In FIG. 2A, an ambient IoT device can directly and bidirectionally communicate with a BS. The communication between the BS and the ambient IoT device includes ambient IoT data and / or signaling. This topology includes the possibility that the BS transmitting to the ambient IoT device is different than the BS receiving from the ambient IoT device.

[0086] In FIG. 2B, an ambient IoT device can communicate bidirectionally with an intermediate node between the IoT device and a BS. The intermediate node can be a relay, an IAB node, a WAB node, a UE, a repeater, a UE-type reader, etc., which is  capable of ambient IoT. The intermediate node may transfer ambient IoT data and / or signaling between the BS and the ambient IoT device.

[0087] In FIG. 2C, an ambient IoT device can transmit data / signaling to a BS and can receive data / signaling from an assisting node (i.e., for DL assistance) . The assisting node may receive the data / signaling from the BS. In this topology, the assisting node can be a relay, an IAB node, a WAB node, a UE, a repeater, a UE-type reader, etc., which is capable of ambient IoT.

[0088] In FIG. 2D, an ambient IoT device can receive data / signaling from a BS and can transmit data / signaling to the assisting node (i.e., for UL assistance) . The assisting node may transmit the data / signaling to the BS. In this topology, the assisting node can be a relay, an IAB node, a WAB node, a UE, a repeater, a UE-type reader, etc., which is capable of ambient IoT.

[0089] In FIG. 2E, an ambient IoT device can communicate bidirectionally with a UE. The communication between the UE and the ambient IoT device includes ambient IoT data and / or signaling.

[0090] Embodiments of the present disclosure provide various methods for charging an (ambient) IoT device. For example, considering the limited energy storage capability, an ambient IoT device may not have enough energy to perform data or signaling transmission or reception, including for example, to handle a paging message, to transmit a paging response, and to perform subsequent transmissions or receptions. For example, when a BS receives a paging request from a CN entity (e.g., an AMF) , the BS may transmit a paging message to an IoT device. However, the IoT device may have too little power to receive or respond to the paging message. For example, the IoT device may respond to the paging message but may not have sufficient power to perform subsequent transmissions or receptions. Embodiments of the present disclosure provide various charging mechanisms to solve such problem while guaranteeing charging efficiency and reliability. In some embodiments, such charging may be under the control of a RAN (e.g., a BS) . More details on the embodiments of the present disclosure will be illustrated in the following text in combination with the appended drawings.

[0091] For the sake of convenience, in the context of the present disclosure, DL transmission in IoT communication can refer to the transmission from an IoT reader (e.g., the BS in the topology of FIG. 2A, the intermediate node in the topology of FIG. 2B, or the assisting node, the BS or the UE in the topologies of FIGs. 2C-2E) to an IoT device (e.g., a tag) ; and UL transmission in IoT communication can refer to the transmission from an IoT device (e.g., a tag) to an IoT reader. The DL and UL links in IoT communication can refer to R2D (reader to device) and D2R (device to reader) links, respectively. In addition, for the sake of convenience, the physical channel for R2D transmission may be referred to as a physical reader to device channel (PRDCH) and the physical channel for D2R transmission may be referred to as a physical device to reader channel (PDRCH) . It should be understood that other appropriate terms may be used.

[0092] In some embodiments of the present disclosure, for R2D transmission, a R2D timing acquisition signal (e.g., a R2D preamble) may be included at least for timing acquisition and for indicating the start of the R2D transmission in the time domain. For D2R transmission, a D2R timing acquisition signal (e.g., D2R preamble) may be included at least for timing acquisition and for indicating the start of the D2R transmission in the time domain. In some embodiments of the present disclosure, another necessary component (s) such as midamble, postamble, periodic sync signal, control fields, guard period, may be included in D2R or D2R transmission.

[0093] Various methods for charging an (ambient) IoT device are proposed in the present disclosure. For example, a charging node (e.g., the BS in the topology of FIG. 2A, or the BS or intermediate node in the topology of FIG. 2B, or the assisting node, the BS or the UE in the topologies of FIGs. 2C-2E) may charge the IoT device based on configuration or assistant information, energy status report or a charge request. In some examples, the charge request may be from the IoT device or a CN entity. A charging node may dynamically, semi-statically, or statically charge an IoT device. The charging node may provide a signal, a radio wave, or a channel used for charging the IoT device. For simplicity, the signal, radio wave, or channel used for charging can be referred to as a charging signal in the context of the present disclosure. It should be noted that a charging signal may not necessarily be a signal dedicated to charging. For example, an IoT device can harvest a communication signal and use it  for charging. A charging signal may include a communication signal or any other signals that can be used for charging the device. On the other hand, a non-charging signal refers to a signal, a radio wave, or a channel not dedicated to charging. For example, a non-charging signal can include a signal for communication, measurement, or the like. The charging signal and communication signal may or may not on the same carrier frequency. And the resources of a charging signal and a communication signal may or may not be the same, or they may or may not overlap on the same carrier frequency. If the resources of a charging signal and a communication signal do not overlap and a device does not charge, the device does not receive the charging signal. If the resources of a charging signal and a communication signal overlap and a device does not charge, the device may receive a signal and does not charge by the received signal if charging is not needed, but perform signal processing, such as decoding or demodulation.

[0094] FIG. 3 illustrates an exemplary diagram of a charging operation at an ambient IoT device in accordance with some embodiments of the present disclosure. The ambient IoT device may operate in a charging mode (or a charging state) or a non-charging mode (e.g., not in a charging mode or state) .

[0095] As shown in FIG. 3, when the ambient IoT device is not in the charging mode, the ambient IoT device does not charge, but can handle a non-charging signal, during a charging duration. The ambient IoT device can handle a non-charging signal outside the charging duration (e.g., in a non-charging duration) when the ambient IoT device is not in the charging mode. In the context of the present disclosure, handling a signal can include receiving, transmitting, or decoding the signal for communication or measurement and any other operations that can be performed on a signal.

[0096] As shown in FIG. 3, when the ambient IoT device is in the charging mode, the ambient IoT device can charge and does not handle a non-charging signal, at least in the charging duration. In some embodiments, when the ambient IoT device is in the charging mode, the ambient IoT device does not handle a non-charging signal outside the charging duration (see "option 1" in FIG. 3) . In other words, in option 1, the ambient IoT device does not expect to handle a non-charging signal when the ambient IoT device is in the charging mode, regardless of whether it is outside or during the  charging duration. For example, if the resource for data transmission or reception overlaps the charging resource in the time domain, the ambient IoT device in the charging mode does not perform the transmission or reception on the resource for data transmission or reception (e.g., on a physical uplink channel such as PDRCH or a physical downlink channel such as PRDCH) on the overlapped resource in the serving cell. In some embodiments, when the ambient IoT device is in the charging mode, the ambient IoT device can handle a non-charging signal outside the charging duration (see "option 2" in FIG. 3) .

[0097] In some embodiments of the present disclosure, by default, a charging node (e.g., a BS) may transmit a charging signal to an (ambient) IoT device for a period of time before paging the device.

[0098] In the context of the present disclosure, a cell or serving cell may be replaced by a carrier or vice versa.

[0099] In some embodiments, the charging node may transmit a charging signal to an (ambient) IoT device for a period of time based on an indication from the CN or BS. For example, the indication indicates the charging node (e.g., a BS) to start communicating with a device (s) . For example, the indication indicates the charging node (e.g., a BS) to start charging for a device (s) .

[0100] In some embodiments, the charging node may transmit a charging signal to an (ambient) IoT device for a period of time based on the time length between the last charging procedure for the device. For example, if the time length is above a threshold, the charging node may transmit a charging signal to the (ambient) IoT device before transmitting the first message to the device.

[0101] In some embodiments of the present disclosure, a charging node (e.g., a BS, an intermediate node or the like) may transmit a charging signal to an (ambient) IoT device based on assistant information. The assistant information may include one or more charging requirements. The assistant information may be transmitted to the charging node by the IoT device or a CN entity (e.g., an AMF) or may be predetermined or predefined (e.g., in a standard (s) ) . For example, the assistant information may indicate the frequency, bandwidth, charging duration length, charging cycle length or  beams used for charging the IoT device. In some embodiments, the IoT device may receive a charging signal based on a charging configuration, which may be configured by a BS, an intermediate node, a CN entity (e.g., an AMF) or an IoT reader, or predetermined or predefined (e.g., in a standard (s) ) . In some embodiments, a BS may inform an (ambient) IoT device that it transmits a charging signal.

[0102] FIG. 5 illustrates exemplary procedure 500 for wireless communication in accordance with some embodiments of the present disclosure. Details described in all of the foregoing embodiments of the present disclosure are applicable for the embodiments shown in FIG. 5. In the example of FIG. 5, it is assumed that a BS is the charging node, that is, the BS provides a charging signal to an (ambient) IoT device. Exemplary procedure 500 can be applied to various topologies in an IoT network including, for example, the topologies of FIGs. 2A-2E.

[0103] Referring to FIG. 5, in some embodiments, BS 520 may transmit an indication (denoted as indication #A) indicating support for wireless signal charging or support of an A-IoT function. For example, BS 520 may indicate that it does not support charging functionality for (ambient) IoT devices. For example, BS 520 may indicate that its cell (s) is barred for A-IoT devices. IoT devices (e.g., IoT device 510) can access, select or reselect a cell based on indication #A.

[0104] In some embodiments, indication #A may be transmitted in common, group-common or dedicated signaling. In some embodiments, indication #A may be carried in Layer 1 (L1) signaling. For example, BS 520 may transmit indication #Avia a short message. Short Messages can be transmitted on a downlink physical channel (e.g., PDRCH) . The channel may be scrambled using a radio network temporary identifier (RNTI) with or without an associated paging message. In some embodiments, the notification may be carried in Layer 2 (L2) signaling or Layer 3 (L3) signaling. For example, BS 520 may transmit the notification via a control plane message (e.g., in SIB1, master information block (MIB) , or any SIB other than SIB1) or via an MAC control element (CE) .

[0105] In some embodiments, BS 520 may further transmit a barred indication (denoted as indication #B) to indicate whether its cell (s) is barred for a legacy UE. In some embodiments, indication #A and indication #B may be merged into a signal  indication.

[0106] At 511, BS 520 receives a message from CN entity 530 (e.g., an AMF) . The message may be dedicated to a certain type of communication device, for example, an (ambient) IoT device, such as a tag. For example, the message may be associated with IoT device 510. In some embodiments, the message may be a paging message or a message from an application.

[0107] In some embodiments, the message may indicate capability information or assistant information of IoT device 510. For example, the message may indicate that IoT device 510 supports charging by harvesting radio waves (e.g., charging signals) . In some embodiments, the capability information or assistant information may be provided by IoT device 510 to CN entity 530 via BS 520 or another BS. In some embodiments, the capability information or assistant information may be provided by another CN entity (e.g., unified data management or application function) to CN entity 530.

[0108] In some embodiments, the message (or the assistant information) may include one or more charging requirements for IoT device 510. For example, the message may indicate one or more of the following: (1) one or more frequencies for charging IoT device 510; (2) a bandwidth range for charging IoT device 510; (3) a cycle length for charging IoT device 510; (4) a set of beams for charging IoT device 510; and (5) a duration length for charging IoT device 510. For example, information (5) may denote a time length required for charging an IoT device. In one example, information (5) may denote the minimum time length to charge, i.e., the minimum charge time required to activate an IoT device. In another example, information (5) may denote the maximum time length to charge, i.e., the minimum charge time required to activate or power on an IoT device. In yet another example, information (5) may denote an average time length to charge, i.e., the average charge time required to activate an IoT device. For example, a charging signal may be provided periodically and information (3) may denote the charging periodicity and information (5) may denote a required charging time length in one period.

[0109] At 513, BS 520 may determine whether to charge IoT device 510. For example, in response to receiving the message at 511 or other conditions that are  described in the context of the present disclosure and conceivable to persons skilled in the art, BS 520 may determine to charge IoT device 510. For example, BS 520 may determine to charge IoT device 510 on demand, periodically, or dynamically (e.g., in one shot) . In response to determining to charge IoT device 510, BS 520 may, at 515, transmit a charging signal to IoT device 510. The charging signal may be transmitted in a charging duration. The details of the charging signal and the charging duration will be described in the following text.

[0110] In some embodiments, BS 520 may transmit the charging signal based on a charging configuration. For example, the charging configuration may indicate one or more of the following: an ARFCN of a carrier frequency on which the charging signal is transmitted; a bandwidth of a carrier or a BWP on which the charging signal is transmitted; a frequency domain resource for the charging signal; a time domain resource for the charging signal; a set of beams for transmitting the charging signal; and a transmission period of the charging signal in units of beam transmission period. IoT device 510 may receive the charging signal based on the charging configuration. That is, from the perspective of an IoT device, the charging configuration may indicate the resource for receiving the charging signal.

[0111] For example, in some embodiments, BS 520 may transmit a charging signal on a set of beams (e.g., a subset of beams among all beams actually configured by the BS) . In some embodiments, an IoT device may support beam identification.

[0112] For example, referring to FIG. 4C, a BS may transmit a charging signal on beams B1 and B3 and may not transmit a charging signal on beams B2 and B4. The following pseudo-code shows an example for configuring the set of beams for transmitting the charging signal.

[0113] In the above example, the parameter "Charging-B-subset" indicates a subset of beams used to transmit a charging radio wave. If this field is absent, an IoT device may assume that the beam set includes all actually transmitted beams configured by the  BS (e.g., via a system information block (SIB) ) . In some embodiments, the configuration may indicate the transmission period (or cycle) of the charging signal, which may be, for example, in units of beam transmission period.

[0114] Various methods can be employed to indicate the frequency and time domain resources for the charging signal. For example, the frequency domain resource for a charging signal may be a frequency domain offset between downlink timing signaling and the overall resource block grid in number of subcarriers. For example, the time domain resource may be indicated by one or more of the following: a first time offset (denoted as TO #1) associated with a start of the charging duration; a second time offset (denoted as TO #2) associated with an end of the charging duration; a length of the charging duration; a third time offset (denoted as TO #3) with respect to a TASB or an SS;and a DCX cycle, which is indicated by one or more of: a length of the charging duration in the DCX cycle, a length of the DCX cycle, and a time offset (denoted as TO #4) associated with the charging duration in the DCX cycle. Details of the time domain resource will be described in the following text.

[0115] In some embodiments, the charging configuration may be predefined (e.g., in a standard (s) ) . In some embodiments, the charging configuration may be transmitted by BS 520, CN entity 530, another BS or another CN entity to IoT device 510. For example, a BS may transmit a charging configuration to IoT device 510 via control plane message (e.g., a SIB or a paging message) . For example, a CN entity may transmit a charging configuration to IoT device 510 via a NAS message. IoT device 510 may store the charging configuration. IoT device 510 may update the stored charging configuration. In some embodiments, the charging configuration may be transmitted via an application layer message by an IoT reader.

[0116] In some embodiments, BS 520 may determine a paging occasion (s) for IoT device 510. A paging message for IoT device 510 can be transmitted in such a paging occasion. In some embodiments, the paging occasions may be periodical. For example, the paging occasions may be determined based on an ID of IoT device 510 (e.g., tag ID) . For example, an IoT device (e.g., an ambient IoT tag) can be identified by a device ID (e.g., a tag ID) assigned by, for example, a manufacturer, factory, vendor, or network operator. The paging occasions may be determined according to the same  or different methods for a legacy UE. In some embodiments, the paging occasions may not be periodical. For example, BS 520 may transmit a paging message to IoT device 510 when there is a demand. For example, a BS may (e.g., by default) transmit a charging signal to an IoT device for a period before paging the device.

[0117] In some embodiments, BS 520 may determine charging occasions based on paging occasions for IoT device 510. BS 520 may determine a dynamic or semi-static charging occasion (s) based on a paging occasion (s) for IoT device 510. For example, BS 520 may determine a charging occasion based on an offset and a paging occasion (s) .

[0118] For example, referring to FIG. 4A, 417 may denote a paging occasion. BS 520 may determine a charging occasion based on one or more of: offset 411, offset 413 and length 415 of on-charge duration. Offset 411 is associated with the start of the on-charge duration, that is, indicates a time offset of the start of the on-charge duration relative to a paging occasion (e.g., the start of the paging occasion) . In some examples, the paging occasion should be a valid / available paging occasion. Offset 411 can be in units of slots or other time units. Offset 413 is associated with the end of the on-charge duration, that is, indicates a time offset of the end of the on-charge duration relative to a paging occasion (e.g., the start of the paging occasion) . Offset 413 can be in units of slots or other time units. Length 415 denotes the time length of the on-charge duration and can be in units of slots or other time units. One or more of offset 411, offset 413 and length 415 may be configured by BS 520 or a CN entity to IoT device 510 or be predefined.

[0119] Referring back to FIG. 5, at 515, BS 520 may transmit a charging signal within the on-charge duration as shown in FIG. 4A. For example, BS 520 may transmit the charging signal from offset 411 before a paging occasion. For example, BS 520 may transmit the charging signal from at least offset 413 before a paging occasion. For example, the charging signal may be transmitted throughout the entire on-charge duration or within a part of on-charge duration.

[0120] At 517, IoT device 510 may determine whether to charge by receiving a signal (e.g., a charging signal from BS 520) . IoT device 510 may determine to charge or not to charge under various conditions, the details of which will be described later. In response to determining to charge, IoT device 510 may receive the charging signal in a  charging duration. For example, IoT device 510 may receive the charging signal from TO #1 before a paging occasion or from at least TO #2 before the paging occasion. For example, IoT device 510 may receive the charging signal until an end of the charging duration, or until a start of a next paging occasion, or until the energy level of IoT device 510 is sufficient, or until TO #2 before the paging occasion. For example, IoT device 510 may receive the charging signal from TO #1 before a paging occasion to the end of the charging duration, or to TO #2 before the paging occasion, or until the energy level of IoT device 510 is sufficient. For example, IoT device 510 may receive the charging signal from TO #1 before a paging occasion to the start of a next paging occasion.

[0121] In some embodiments, BS 520 may transmit a charging signal based on a time offset and TASB / SS. A TASB may include a downlink synchronization signal or other synchronization signal. The timing acquisition signal (e.g., R2D preamble) may be used at least for timing acquisition. The time offset may indicate a time gap between a charging signal block and the TASB / SS. For example, BS 520 may transmit a charging signal from the time offset after a TASB or an SS. For example, an offset value of "ms5" means that the first burst of charging signal block is transmitted 5ms later than the TASB / SS, an offset value of "ms10" means that the first burst of charging signal block is transmitted 10ms later than the TASB / SS, and so on. In some examples, if this time offset is not configured, an IoT device may consider that the time offset is a default value (e.g., zero) or a predefined value. In some embodiments, if no timing acquisition signal is received, the received signal may be considered to be used for charging.

[0122] For example, referring to FIG. 4B, 425 may denote a TASB or an SS. BS 520 may determine a charging occasion based on an offset with respect to 425, such as offset 421 or offset 423. Offset 421 is associated with the start of 425. Offset 423 is associated with the end of 425. Offset 423 or offset 425 may be configured by BS 520 or a CN entity to IoT device 510 or be predefined.

[0123] Referring back to FIG. 5, at 515, BS 520 may transmit a charging signal within the on-charge duration as shown in FIG. 4B. For example, BS 520 may transmit the charging signal from offset 423 later than the start of a TASB or an SS (e.g., the  beginning of the burst of a beam) . For example, BS 520 may transmit the charging signal from offset 421 later than the end of a TASB or an SS (e.g., the end of the burst of a beam) . At 517, in response to determining to charge, IoT device 510 may receive the charging signal in a charging duration. For example, IoT device 510 may receive the charging signal from TO #3 later than the start or the end of the TASB or the SS. For example, IoT device 510 may receive the charging signal until the energy level of IoT device 510 is sufficient.

[0124] In some embodiments, BS 520 may transmit a charging signal periodically. This is beneficial for a mobile terminated (MT) IoT device in a data transmission procedure, or a mobile originated (MO) IoT device to receive the charging signal (if needed) . For example, IoT device 510 may be configured with a DCX and thus may periodically perform charging by harvesting charging signals (e.g., radio waves) .

[0125] For example, the DCX configuration may indicate a DCX cycle by one or more of:a length of the charging duration in the DCX cycle, a length of the DCX cycle, and a time offset (e.g., TO #4) associated with the charging duration in the DCX cycle. The DCX configuration may be predefined (e.g., in a standard (s) ) or transmitted by BS 520, CN entity 530, another BS or another CN entity to IoT device 510.

[0126] For example, referring to FIG. 4D, a DCX configuration (or a charging configuration) may indicate one or more of:

[0127] - an "on-charge duration" which refers to the duration where an IoT device can receive the charging signal for harvesting energy; (For example, the device does not expect to communicate with an IoT reader in this duration. )

[0128] - a "DCX cycle" (or a DCX period) which refers to the periodic repetition of the on-charge-duration followed by, for example, a possible communication duration (e.g., "opportunity for DCX" as shown in FIG. 4D, which can be a data transmission or reception duration) ; (For example, the device expects to communicate with an IoT reader in this communication period, that is to say, the device does not expect to charge in the period. )

[0129] - a "time-offset" which refers to an offset of a charging resource (e.g., the "on-charge duration" ) with respect to a specific time instance in the time domain and may  define, for example, the subframe where the DCX cycle starts, wherein in some embodiments, the time instance may be a system frame number (SFN) or an absolute reference time based on a time clock; and

[0130] - a "slot-time-offset" which refers to a slot-level offset (or delay) before starting the on-charge duration, wherein in some embodiments, the "slot-time-offset may be a predefined value (e.g., zero) .

[0131] Referring back to FIG. 5, at 515, BS 520 may transmit a charging signal periodically within the on-charge duration as shown in FIG. 4D. At 517, in response to determining to charge, IoT device 510 may receive the charging signal based on the charging configuration (e.g., the DCX configuration) . For example, IoT device 510 may determine the charging occasions based on the charging configuration. For example, if [ (SFN × 10) + subframe number] modulo "DCX cycle" = "time-offset" , IoT device 510 may determine the start of the charging duration (e.g., the on-charge duration as shown in FIG. 4D) after "slot-time-offset" from the start of the subframe. For example, if [ (clock number × 60) + minute number] modulo "DCX cycle" = "time-offset" , wherein "clock number" represents the value of hours in a day, "minute number" represents the value of minutes, and the unit of "DCX cycle" and "time-offset" is minute, the start of the charging duration can be determined as "slot-time-offset" seconds after the time indicated by "clock number" and "minute number" . For example, if [ (A× B) + C] modulo "DCX cycle" = "time-offset" , wherein "A" represents the value of a first time instance in a period, "C" represents the value of a second time instance, "B" represents the conversion factor between the unit of A and the unit of C, and "DCX cycle" and "time-offset" has the same unit as "C" , the start of the charging duration can be determined as the time instance indicated by "A" and "C" .

[0132] In some embodiments, BS 520 may not transmit a charging signal periodically. For example, BS 520 may aperiodically transmit a charging signal. BS 520 may dynamically transmit the charging signal to IoT device 510. For example, when BS 520 determines that IoT device 510 needs to be charged, BS 520 may dynamically indicate IoT device 510 to receive a charging signal. For example, BS 520 may transmit signaling indicating the time domain resource for the charging signal, the frequency domain resource for the charging signal, or both. For example, the signaling may indicate a start time point of the charging, the duration of the charging  or both. IoT device 510 may receive the charging signal based on the signaling. In some embodiments, the signaling may be carried in a downlink physical channel (e.g., PRDCH) . In some embodiments, BS 520 determines that IoT device 510 needs to be charged in response to receiving a charging request or an energy status report from IoT device 510 or according to the implementation at BS 520. This dynamic charging is beneficial for IoT devices without enough energy during a data transmission procedure.

[0133] For example, referring to FIG. 4E, signaling 451 may indicate the resource for a charging signal. In response to receiving signaling 451, an IoT device may receive the charging signal at the corresponding resource as indicated by signaling 451. In some embodiments, signaling 451 may be downlink control information (DCI) .

[0134] Referring back to FIG. 5, in some embodiments, BS 520 may dynamically transmit a charging signal for a period time before a DL transmission or a UL reception. For example, before BS 520 transmits the first message, e.g., an inventory request or a paging message to IoT device 510, a charging signal is transmitted.

[0135] For example, referring to FIG. 4A, 417 may denote a DL transmission (e.g., a PRDCH) or a UL reception (e.g., a PDRCH) . In some embodiments, BS 520 may transmit a charging signal to IoT device 510 from offset 411 before 417. In some embodiments, BS 520 may transmit a charging signal to IoT device 510 from at least offset 413 before 417. In some embodiments, BS 520 may transmit a postamble at an end of the on-charge duration. In some embodiments, BS 520 may transmit a preamble at a start of the on-charge duration. The preamble may be different from the R2D preamble. The postamble may be different from the R2D postamble. That is, a preamble, a postamble or both may be added to the charging signal for identifying the start or the end of the charging signal. One or more of offset 411 and offset 413 may be configured by a BS or a CN entity to IoT device 510 or be predefined. In some embodiments, BS 520 may not transmit the preamble and postamble during a charging signal transmitting procedure. If IoT device 510 does not detect a R2D preamble from the received signal, the received signal is assumed to be used for charging. If IoT device 510 detects a R2D preamble from the received signal, the signal is assumed to be used for communication.

[0136] Referring back to FIG. 5, at 517, in response to determining to charge, IoT  device 510 may receive the charging signal in a charging duration. For example, IoT device 510 may receive the charging signal from TO #1 before a DL reception or a UL transmission or from at least the TO #2 before the DL reception or the UL transmission. For example, IoT device 510 may receive the charging signal until an end of the charging duration or until the energy level of IoT device 510 is sufficient. In some embodiments, IoT device 510 may switch to perform the DL reception or the UL transmission after a time offset (e.g., TO #2) from the end of the charging duration or in response to the energy level of IoT device 510 being sufficient.

[0137] In some embodiments, IoT device 510 may determine to charge under certain conditions and then receive the charging signal from BS 520 as described above. For example, IoT device 510 may determine to charge in response to one or more of the following conditions:

[0138] - an energy level of IoT device 510 being insufficient;

[0139] - IoT device 510 being in an inactive status;

[0140] - receiving a charging activation command;

[0141] - receiving a charging notification indicating that BS 520 is transmitting the charging signal;

[0142] - an on-charge duration in a DCX cycle; and

[0143] - receiving signaling indicating a time domain resource for the charging signal.

[0144] In some embodiments, IoT device 510 may determine whether its energy level is sufficient or not based on certain criteria (e.g., one or more thresholds) or its implementation. The criteria may be configured by the network (e.g., by a BS or a CN entity) or be predefined. In some embodiments, triggering conditions for energy status reporting, which will be described later, may apply here. That is, IoT device 510 may determine whether or not its energy level is sufficient in a manner similar to determining whether or not a trigger condition for energy status reporting is met.

[0145] In some embodiments, IoT device 510 may switch to an inactive status in response to receiving an indication indicating the end of communication from an IoT reader (e.g., BS 520) . In some embodiments, IoT device 510 may determine to be in  inactive status if it has completed a communication procedure with the IoT reader. In some embodiments, IoT device 510 may determine to be in inactive status based on the expiration of a data inactivity status. For example, IoT device 510 may determine whether to enter a charging mode based on the expiration of a data inactivity status. IoT device 510 may determine the data inactivity status based on a data inactivity timer. For example, IoT device 510 may start or restart a data inactivity timer if any media access control (MAC) entity transmits a MAC service data unit (SDU) for a logical channel such as a dedicated traffic channel (DTCH) logical channel, a dedicated control channel (DCCH) logical channel or a common control channel (CCCH) logical channel. In response to the expiry of the data inactivity timer, the MAC entity may indicate the expiry of the data inactivity timer to an upper layer (s) or a lower layer (s) . Then, the upper layer (s) or the lower layer (s) may switch to a charging mode.

[0146] For example, IoT device 510 may determine to charge in response to any one of the above listed conditions being met. For example, IoT device 510 may determine to charge in response to its energy level being insufficient and the timing satisfying the on-charge duration of the DCX cycle. For example, IoT device 510 may determine to charge in response to receiving a charging activation command and the timing satisfying the on-charge duration of the DCX cycle. Details of the charging activation command will be described later. For example, IoT device 510 may determine to charge in response to the device being in an inactive status and the reception of a charging notification indicating that BS 520 is transmitting the charging signal. Any other combinations of the above listed conditions can also apply.

[0147] In some embodiments, IoT device 510 may be in a charging mode when it receives the charging signal in the charging duration. In such case, IoT device 510 may not expect to handle a non-charging signal (e.g., a communication signal) , at least during the charging duration. For example, IoT device 510 may not expect to receive, decode, demodulate, or transmit signaling or data during the charging duration. For example, if a UL or DL resource for IoT device 510 (e.g., a dynamic UL grant (s) , a specific configured grant (s) or a dynamic DL assignment) overlaps the resource for the charging signal in the time domain, IoT device 510 may deprioritize the transmission or reception over the overlapping resource in the serving cell.

[0148] In some embodiments, IoT device 510 may determine not to charge under certain conditions (e.g., any condition as described below or conceivable to persons skilled in the art or any combinations thereof) and then may not need a charging signal on the carrier frequency. In such a case, IoT device 510 may stay in a non-charging mode. For example, if the energy level of IoT device 510 is sufficient, IoT device 510 may not charge even if BS 520 is transmitting a charging signal to IoT device 510 (e.g., during an on-charge duration of a DCX cycle) . For example, IoT device 510 may not need a charging signal if its energy level is sufficient. As described above, IoT device 510 may determine whether its energy level is sufficient or not based on certain criteria or its implementation. The criteria may be configured by the network (e.g., by a BS or a CN entity) or be predefined. In some embodiments, triggering conditions for energy status reporting may apply here.

[0149] For example, if a resource for UL overlaps a resource for the charging signal in the time domain, IoT device 510 may determine not to charge. For example, if a resource for DL overlaps the resource for the charging signal in the time domain, IoT device 510 may determine not to charge. For example, if UL data is available for transmission and a resource for the UL data overlaps the resource for the charging signal in the time domain, IoT device 510 may determine not to charge. In response to determining not to charge, IoT device 510 may transmit a UL signal for communication on the UL resource, receive a DL signal for communication on the DL resource, or transmit pending UL data on the resource for the UL data.

[0150] However, when BS 520 transmits a charging signal to IoT device 510, BS 520 may assume that IoT device 510 receives the charging signal (e.g., in a charging mode) before receiving an indication that indicates otherwise (i.e., indicating that IoT device 510 is not charging or not in the charging mode) . In addition, BS 520 may not transmit a DL physical channel (e.g., PRDCH) to IoT device 510 or receive a UL physical channel (e.g., PDRCH) from IoT device 510 during the transmission of the charging signal.

[0151] In some embodiments, in response to determining not to charge, IoT device 510 may perform one or more of the following:

[0152] - in the case that a UL resource overlaps the resource for the charging signal in the  time domain, transmitting a UL signal for communication on the UL resource;

[0153] - in the case that a DL resource overlaps the resource for the charging signal in the time domain, receiving a DL signal for communication on the DL resource; and

[0154] - in the case that UL data is available for transmission and a resource for the UL data overlaps the resource for the charging signal in the time domain, transmitting the UL data on the resource for the UL data.

[0155] The UL resource may be a dynamical UL resource or a configured resource received by IoT device 510. The DL resource may be indicated by a DL assignment received by IoT device 510.

[0156] In some embodiments, at 519 (denoted by a dotted arrow as an option) , IoT device 510 may transmit a charging-related indication to BS 520. For example, IoT device 510 may report whether IoT device 510 is charging or not. For example, IoT device 510 may report its energy status (e.g., via an energy status report) . For example, IoT device 510 may report whether charging is needed. IoT device 510 can initiate a random access procedure to transmit the indication. For example, if its energy is sufficient (e.g., the energy level being full or above a certain threshold) , IoT device 510 may transmit, to BS 520, an indication indicating whether its energy is sufficient or charging is needed. For example, if IoT device 510 powers on after charging for a period, IoT device 510 may transmit, to BS 520, an indication indicating its energy status, or indicating whether it is charging or whether charging is needed.

[0157] For example, if IoT device 510 is charging or determines to charge, IoT device 510 may report to BS 520 that it is charging. When BS 520 transmits a charging signal, BS 520 may assume that IoT device 510 is charging before receiving an indication that indicates otherwise. BS 520 may not transmit a non-charging signal (e.g., a communication signal) to IoT device 510 (e.g., for decoding) if it considers that IoT device 510 is charging. For example, if IoT device 510 is not charging (e.g., not receiving the charging signal) or determines not to charge, IoT device 510 may report to BS 520 that it is not charging. For example, IoT device 510 may indicate that it does not need a signal for charging. In such a case, IoT device 510 can perform transmission and reception with BS 520 during the charging duration. If a UL or DL resource for IoT device 510 (e.g., a dynamic UL grant (s) , a specific configured grant (s)  or a dynamic DL assignment) overlaps the resource for the charging signal in the time domain, IoT device 510 can perform transmission or reception over the overlapped resource in the serving cell.

[0158] In some embodiments, at 521 (denoted by a dotted arrow as an option) , BS 520 may transmit a paging message to IoT device 510, for example, in response to a corresponding paging message from CN entity 530. Alternative, BS 520 may not transmit such a paging message to IoT device 510 if BS 520 has received the indication at 519 or any other indications from IoT device 510. That is, these indications can be seen as an equivalent of a paging response. In some embodiments, such indications may include an identification of IoT device 510 (e.g., a tag ID) .

[0159] In some embodiments, BS 520 may transmit a notification indicating the transmission status of the charging signal (e.g., transmitting or not transmitting the charging signal) to IoT device 510 (not shown in FIG. 2) . This is beneficial for a BS to dynamically transmit a charging signal in a power saving manner. It is also beneficial for IoT devices to switch to receive the charging signal when needed.

[0160] In some embodiments, the notification message may be common, group-common or dedicated signaling. In some embodiments, the notification may be carried in L1 signaling. For example, BS 520 may transmit a charge indication on a downlink physical channel. The channel may be scrambled using an RNTI. In some examples, the value of the indication being a certain value (e.g., 1) means that a charging signal is transmitting or to be transmitted or an IoT device can perform charging. In some embodiments, the notification may be carried in L2 signaling or L3 signaling. For example, BS 520 may transmit the notification via a control plane message (e.g., an SIB) or via an MAC CE. For example, the control plane message may use a bit to indicate the notification. The notification may be carried over a PRDCH.

[0161] It should be appreciated by persons skilled in the art that the sequence of the operations in exemplary method 500 may be changed and some of the operations in exemplary method 500 may be eliminated or modified, without departing from the spirit and scope of the disclosure.

[0162] Although the charging node in the embodiments described with respect to FIG. 5 is a BS, it should be noted that the charging node can be another node, for example, an intermediate node as shown in the topology of FIG. 2B. In such a scenario, the charging functionality may be provided under the control of the network. For example, a BS may notify the another node (e.g., the intermediate node) to transmit the charging signal to an IoT device. For example, the BS and the charging node may coordinate to charge the IoT device. For example, they may negotiate the charging configuration for the IoT device. Either the BS or the charging node can determine the charging configuration and transmit it to the IoT device.

[0163] FIG. 6 illustrates exemplary procedure 600 for wireless communication in accordance with some embodiments of the present disclosure. Details described in all of the foregoing embodiments of the present disclosure are applicable for the embodiments shown in FIG. 6. In the example of FIG. 6, it is assumed that node 640 is not a BS and provides a charging signal to an (ambient) IoT device. Exemplary procedure 600 can be applied to various topologies in an IoT network including, for example, the topologies of FIGs. 2B-2E. For example, node 640 may be the intermediate node in the topology of FIG. 2B, or the assisting node in the topologies of FIGs. 2C and 2D or the UE in the topology of FIG. 2E.

[0164] Referring to FIG. 6, at 611, node 640 and BS 620 may coordinate with each other to determine a charging configuration for IoT device 610. Node 640 or BS 620 may determine the charging configuration for IoT device 610 according to the foregoing embodiments.

[0165] In some embodiments, node 640 may receive information related to IoT device 610 from BS 620. For example, the information may include assistant information or capability information of IoT device 510 as described in the foregoing embodiments. Node 640 may determine the charging configuration for IoT device 610 based on the information. Node 640 may determine the charging configuration for IoT device 610 according to the foregoing embodiments. Node 640 may transmit the determined charging configuration to IoT device 610 at 613 (denoted by a dotted arrow as an option) . Alternatively, node 640 may transmit the determined charging configuration to BS 620, which may transmit the charging configuration (which can be the same or  different from the one received from node 640) to IoT device 610 at 615 (denoted by a dotted arrow as an option) .

[0166] In some embodiments, BS 620 may receive charging-related information from node 640. BS 620 may determine the charging configuration for IoT device 610 based on the information. BS 620 may determine the charging configuration for IoT device 610 according to the foregoing embodiments. BS 620 may transmit the determined charging configuration to IoT device 610 at 615 (denoted by a dotted arrow as an option) . Alternatively, BS 620 may transmit the determined charging configuration to node 640, which may transmit the charging configuration (which can be the same or different from the one received from BS 620) to IoT device 610 at 613 (denoted by a dotted arrow as an option) .

[0167] At 617, BS 620 may notify or trigger node 640 to transmit a charging signal to IoT device 610. At 619, node 640 may transmit the charging signal to IoT device 610. The descriptions regarding the transmission of the charging signal in FIG. 5 can apply here. The operations performed by BS 520 in FIG. 5 can be applied to node 640. IoT device 610 may determine whether to charge. The operations performed by IoT device 510 in FIG. 5 can be applied to IoT device 610.

[0168] In some embodiments, BS 620 or node 640 may transmit a notification to IoT device 610 to indicate whether a charging signal is being or to be transmitted to IoT device 610 or not. For example, in response to triggering node 640 to provide the charging signal, BS 620 may inform IoT device 610 that a charging signal is being transmitted to IoT device 610.

[0169] It should be appreciated by persons skilled in the art that the sequence of the operations in exemplary method 600 may be changed and some of the operations in exemplary method 600 may be eliminated or modified, without departing from the spirit and scope of the disclosure.

[0170] In some embodiments, an IoT reader (e.g., a BS) may transmit a command to an IoT device to activate or deactivate charging. The command may specify which charging occasion (s) in a time window is skipped for charging. The command may be transmitted by dedicated, common or group-common signaling. The command  may be transmitted by L1, L2 or L3 signaling.

[0171] The activation or deactivation can occur at any time or under any circumstances that are applicable. For example, an IoT reader (e.g., a BS) may suspend or resume the transmission of the charging signal to an IoT device even if the charging configuration is configured for the IoT device. For example, even if an IoT reader (e.g., a BS) periodically transmits a charging signal to an IoT device, the IoT reader (e.g., a BS) can deactivate the charging to prioritize data transmission.

[0172] FIG. 7 illustrates exemplary procedure 700 for activating and deactivating charging in accordance with some embodiments of the present disclosure. Details described in all of the foregoing embodiments of the present disclosure are applicable for the embodiments shown in FIG. 7. Exemplary procedure 700 can be applied to various topologies in an IoT network including, for example, the topologies of FIGs. 2A-2E.

[0173] Referring to FIG. 7, at 711, IoT reader 750 may transmit, to IoT device 710, an indication to deactivate or suspend charging. According to this indication, a charging signal is not expected to be received from IoT reader 750 at IoT device 710.

[0174] In some embodiments, this deactivation indication may include a plurality of indicators, each of which corresponds to a charging occasion. For example, the deactivation indication may be a bitmap with each bit corresponding to a charging occasion in a DCX cycle. In this way, one deactivation indication can deactivate one or more charging occasions.

[0175] For example, assuming that the bitmap includes 3 bits, respectively denoted as bit #0, bit #1 and bit #2, bit #0 may correspond to a nth charging occasion after the reception of the indication, bit #1 may correspond to a n+1th charging occasion after the reception of the indication and bit #2 may correspond to a n+2th charging occasion after the reception of the indication. The value of n may be configured, predetermined of predefined. Bit value 0 may denote deactivation while bit value 1 may denote activation, or vice versa. Bit #0 may be the most significant bit (MSB) and bit #2 may be the least significant bit (LSB) , or bit #0 may be the LSB and bit #2 may be the MSB.

[0176] At 713, in response to receiving the deactivation indication, IoT device 710 may stop or suspend charging. In some embodiments, in response to receiving the indication, IoT device 710 may perform or prioritize data transmission, reception, or measurement which overlaps the charging duration in the same serving cell. In some embodiments, in response to receiving the indication, IoT device 710 may leave the charging mode. Alternatively, IoT device 710 may not charge in the charging duration but remain in the charging mode.

[0177] At 715, IoT reader 750 may transmit, to IoT device 710, another indication to activate or resume charging. According to this indication, a charging signal is expected to be received from IoT reader 750 at IoT device 710. IoT reader 750 may transmit a charging signal to IoT device 710. A non-charging signal (e.g., a communication signal) is not expected to be received from or transmitted to IoT device 710, at least within the charging duration.

[0178] At 717, in response to receiving the activation indication, IoT device 710 may enter into a charging mode. For example, IoT device 710 may perform charging according to the charging configuration. For example, IoT device 710 may deprioritize the data transmission or measurement, at least during the charging duration.

[0179] It should be appreciated by persons skilled in the art that the sequence of the operations in exemplary method 700 may be changed and some of the operations in exemplary method 700 may be eliminated or modified, without departing from the spirit and scope of the disclosure.

[0180] In some embodiments, an IoT reader (e.g., a BS) can monitor the energy status of an (ambient) IoT device by an energy status report from the device. For example, an IoT reader (e.g., a BS) can configure an energy status measurement, monitoring or reporting for an (ambient) IoT device. The IoT device may transmit an energy status report to the IoT reader (e.g., a BS) based on the configuration. The energy status report can be presented in various forms. For example, the report may indicate the remaining energy of the device in units of joules, watts, or volts. Alternatively, the report may simply indicate whether its energy is sufficient or not.

[0181] Energy status reporting is beneficial for an MT-IoT device (e.g., in a data  transmission procedure) and an MO-IoT device. An IoT device can timely report its energy status for charging. This can also help an IoT reader (e.g., a BS) to determine whether to charge an IoT device or to perform transmission or reception with the device.

[0182] In general, an IoT device is configured to be allowed to report its energy status. In some examples, an IoT device is allowed by default to report its energy status. In some embodiments, an IoT device may transmit an energy status report:

[0183] - if an IoT reader (e.g., a BS) configures the IoT device to transmit its energy status report to the IoT reader (e.g., a BS) ;

[0184] - if there is an available UL resource for an initial transmission (for example, the IoT device may transmit the report regardless of whether there is data in a user plane layer (e.g., packet data convergence protocol (PDCP) or radio link control (RLC) or MAC layer) pending for transmission) ; and

[0185] - if there is an available UL resource (e.g., UL grant) for an initial transmission and there is data pending for transmission (initial, retransmission or both) . For example, the IoT device may transmit the report together with the pending data to be transmitted.

[0186] In some embodiments, an IoT device may report its energy status based on an energy status report configuration. The energy status report configuration can be configured by any types of IoT reader, such as a BS or an intermediate node, or by a network node, such as a CN entity, or be predefined (e.g., in a standard (s) ) . The energy status report configuration may include various criteria for triggering energy status reporting. Examples of such triggering criteria will be described in the following text.

[0187] FIG. 8 illustrates exemplary procedure 800 for energy status reporting in accordance with some embodiments of the present disclosure. Details described in all of the foregoing embodiments of the present disclosure are applicable for the embodiments shown in FIG. 8. Exemplary procedure 800 can be applied to various topologies in an IoT network including, for example, the topologies of FIGs. 2A-2E.

[0188] Referring to FIG. 8, at 811 (denoted by a dotted arrow as an option) , IoT reader  850 may transmit an energy status report configuration to IoT device 810. In some other embodiments, the energy status report configuration may be configured by another entity or be predefined. In some embodiments, the energy status report configuration may be configured by a control plane message. For example, the configuration may be transmitted via a SIB or a radio resource control (RRC) reconfiguration message.

[0189] In some embodiments, the energy status report configuration may indicate one or more of the following:

[0190] (a) a first energy level threshold (denoted as TH #1) for triggering energy status reporting;

[0191] (b) a second energy level threshold (denoted as TH #2) for triggering energy status reporting, wherein TH #2 is higher than TH #1;

[0192] (c) a hysteresis value for energy level;

[0193] (d) a time period for triggering energy status reporting;

[0194] (e) a reporting periodicity;

[0195] (f) a threshold for data volume pending for transmission;

[0196] (g) a signal condition threshold;

[0197] (h) a pathloss threshold;

[0198] (i) a distance threshold; and

[0199] (j) a value of a prohibit timer.

[0200] IoT device 810 may trigger energy status reporting or transmit an energy status report based on the energy status report configuration, for example, based on one or more parameters indicated by the energy status report configuration. The following are some examples for evaluating whether a trigger condition is met or not.

[0201] For example, IoT device 810 may report its energy status when its energy level is equal to or lower than TH #1 (denoted as condition (1) ) . For example, during a data transmission procedure, IoT device 810 may trigger energy status reporting (e.g., transmit an energy status report) if its energy level is equal to or lower than TH #1.

[0202] For example, IoT device 810 may report its energy status when its energy level is equal to or higher than TH #2 (denoted as condition (2) ) . For example, when the device is fully charged, the device may trigger energy status reporting (e.g., transmit an  energy status report) .

[0203] For example, parameter (c) may be used by IoT device 810 to enter or leave a report-triggered status. In some examples, parameter (c) may include two hysteresis values (denoted as Hysteresis #1 and Hysteresis #2) that are separate for TH #1 and TH #2. In some examples, TH #1 and TH #2 may share the same hysteresis value (i.e., Hysteresis #1 = Hysteresis#2) . For example, IoT device 810 may enter a report-triggered status (e.g., IoT device 810 may trigger energy status reporting or transmit an energy status report) when measured energy level –Hysteresis #1 <= TH #1 (denoted as condition (3) ) and may leave the report-triggered status when measured energy level + Hysteresis #1 > TH #1 (denoted as condition (4) ) . For example, IoT device 810 may enter a report-triggered status (e.g., IoT device 810 may trigger energy status reporting or transmit an energy status report) when measured energy level –Hysteresis #2 >= TH #2 (denoted as condition (5) ) and may leave the report-triggered status when measured energy level + Hysteresis #2 < TH #2 (denoted as condition (6) ) .

[0204] For example, when condition (1) , (2) , (3) or (5) is fulfilled for a certain period of time (e.g., parameter (d) ) , IoT device 810 may trigger energy status reporting or transmit an energy status report.

[0205] For example, IoT device 810 may periodically trigger energy status reporting or transmit an energy status report according to parameter (e) .

[0206] For example, IoT device 810 may trigger energy status reporting or transmit an energy status report if the data volume at the device is greater than or equal to parameter (f) . The data volume may be the buffer size of the data pending for transmission (e.g., only for initial transmission, or only for retransmission, or for both initial transmission and retransmission) .

[0207] For example, IoT device 810 may trigger energy status reporting or transmit an energy status report if the signal condition is lower than or equal to parameter (g) . The signal condition may be the reference signal receiving power (RSRP) , reference signal receiving quality (RSRQ) , reference signal strength indicator (RSSI) or signal to interference noise ratio (SINR) of a measurement signal of a carrier. When IoT reader 850 is a BS, the carrier may refer to a carrier of IoT reader 850 which serves IoT device  810.

[0208] For example, IoT device 810 may trigger energy status reporting or transmit an energy status report if the pathloss of the serving cell is higher than or equal to parameter (h) . For example, IoT device 810 may trigger energy status reporting or transmit an energy status report if the distance between IoT device 810 and a BS of the serving cell or IoT reader 850 is greater than or equal to parameter (i) .

[0209] At 813, IoT device 810 may transmit an energy status report to IoT reader 850 based on the energy status report configuration. In some embodiments, the report simply indicates whether the energy level is sufficient or not. In some embodiments, the report indicates the remaining energy. The unit of the energy level may be at least one of:

[0210] - J, which indicates the unit for the energy of electricity;

[0211] - W or dBm, which indicates the unit for the energy of power and wherein X (dBm) = 10×log10 (X mW / 1mW) or P (mW) = 1mW×10 (P (dBm)  / 10) ; or

[0212] - V, which indicates the unit for the energy of voltage.

[0213] In some embodiments, IoT device 810 may transmit the report via a random access (RA) procedure. In some embodiments, if there is an available UL resource (e.g., UL grant) , IoT device 810 may transmit the report using the UL resource. In some embodiments, if there is an available UL resource (e.g., UL grant) and there is data pending for transmission, IoT device 810 may transmit the report with the pending data using the UL resource. If the resource is not enough to accommodate the report and data, IoT device 810 may prioritize the transmission for the report.

[0214] In some embodiments, IoT device 810 may report the energy status report to IoT reader 850 based on a report prohibit timer. For example, in response to initiating the transmission of an energy status report or in response to transmitting the energy status report, IoT device 810 may start a prohibit timer based on, for example, parameter (j) . If the prohibit timer is not running, IoT device 810 may transmit an energy status report; otherwise, IoT device 810 does not transmit the report and may wait for the timer to expire.

[0215] In some embodiments, the energy status report may be transmitted in an MAC CE. In some examples, the MAC CE for the energy status report may have a higher transmission priority than data from the traffic logical channel. In some examples, the MAC CE for the energy status report may have a higher or lower transmission priority than data from the control logical channel. In some examples, the MAC CE for the energy status report may have a higher or lower transmission priority than the MAC CE for buffer status report. In some examples, the MAC CE for the energy status report may have a higher or lower transmission priority than the MAC CE for UE ID (e.g., a random value or a RNTI) . In some examples, the MAC CE for the energy status report may have a higher or lower transmission priority than the MAC CE for the timing advance report.

[0216] In some examples, if the energy level satisfies condition (1) or (3) , the MAC CE for the energy status report may have a higher transmission priority than data from any logical channel, except data from the UL CCCH. Otherwise, the MAC CE for the energy status report may have a lower transmission priority than data from any logical channel.

[0217] In some examples, if the energy level satisfies condition (2) or (5) , the MAC CE for the energy status report may have a higher transmission priority than data from any logical channel, except data from the UL CCCH. Otherwise, the MAC CE for the energy status report may have a lower transmission priority than data from any logical channel.

[0218] It should be appreciated by persons skilled in the art that the sequence of the operations in exemplary method 800 may be changed and some of the operations in exemplary method 800 may be eliminated or modified, without departing from the spirit and scope of the disclosure.

[0219] In some embodiments, an IoT reader (e.g., a BS or an intermediate node) may transmit a charging signal in response to a charging request from an (ambient) IoT device. For example, an IoT device may transmit a charging request to an IoT reader based on a charging request configuration. In some examples, the IoT reader may transmit a response to the IoT device to acknowledge the charging request. In some examples, the IoT reader may transmit a charging signal to the IoT device in response  to the reception of the charging request. The charging signal may be transmitted according to a charging configuration as described above. For example, the charging signal may be transmitted from a time offset after the charging request or the response. For example, the charging signal may be transmitted at a periodicity and / or for a certain duration.

[0220] The charging request configuration can be configured by any types of IoT reader, such as a BS or an intermediate node, or by a network node, such as a CN entity, or predefined (e.g., in a standard (s) ) . Parameters in the energy status report configuration may be applied to the charging request configuration. In some embodiments, the charging request configuration may indicate one or more of the following:

[0221] (1) an energy level threshold (denoted as TH #3) for triggering the charging request;

[0222] (2) a hysteresis value (denoted as Hysteresis #3) for energy level;

[0223] (3) a time period for triggering the charging request;

[0224] (4) a requesting periodicity;

[0225] (5) a threshold for a data volume pending for transmission;

[0226] (6) a signal condition threshold;

[0227] (7) a pathloss threshold;

[0228] (8) a distance threshold;

[0229] (9) beam information for charging; and

[0230] (10) a value of a prohibit timer.

[0231] An IoT device may trigger a charging request or transmit a charging request based on the charging request configuration, for example, based on one or more parameters indicated by the charging request configuration. The following are some examples for evaluating whether a trigger condition is met or not.

[0232] For example, the IoT device may transmit a charging request when its energy level is equal to or lower than TH #3 (denoted as condition (a) ) . For example, Hysteresis #3 may be used by the IoT device to enter or leave a request-triggered status. For example, the IoT device may enter a request-triggered status (e.g., the IoT device may trigger a charging request or transmit a charging request) when measured energy level –Hysteresis #3 <= TH #3 (denoted as condition (b) ) and may leave the request- triggered status when measured energy level + Hysteresis #3 > TH #3 (denoted as condition (c) ) . For example, when condition (a) or (b) is fulfilled for a certain period of time (e.g., parameter (3) ) , the IoT device may trigger or transmit a charging request. For example, the IoT device may periodically trigger or transmit a charging request according to parameter (4) . For example, the IoT device may trigger or transmit a charging request if the data volume at the device is greater than or equal to parameter (5) . For example, the IoT device may trigger or transmit a charging request if the signal condition is lower than or equal to parameter (6) . For example, the IoT device may trigger or transmit a charging request if the pathloss of the serving cell is higher than or equal to parameter (7) . For example, the IoT device may trigger or transmit a charging request if the distance between the IoT device and a BS of the serving cell or an IoT reader is greater than or equal to parameter (8) . For example, the IoT device may transmit a charging request based on parameter (9) . For example, the IoT device may transmit a charging request on a beam indicated by the beam information.

[0233] In some embodiments, the IoT device may trigger or transmit a charging request based on a request prohibit timer. For example, in response to initiating the transmission of a charging request or in response to transmitting a charging request, the IoT device may start a prohibit timer based on, for example, parameter (10) . If the prohibit timer is not running, the IoT device may transmit a charging request; otherwise, the IoT device does not transmit the request and may wait for the timer to expire.

[0234] FIG. 9 illustrates exemplary procedure 900 for transmitting a charging request in accordance with some embodiments of the present disclosure. Details described in all of the foregoing embodiments of the present disclosure are applicable for the embodiments shown in FIG. 9. Exemplary procedure 900 can be applied to various topologies in an IoT network including, for example, the topologies of FIGs. 2A-2E.

[0235] Referring to FIG. 9, at 911 (denoted by a dotted arrow as an option) , IoT reader 950 may transmit a charging request configuration to IoT device 910. The charging request configuration may be transmitted via a control plane message (e.g., in SIB1, MIB, or any SIB other than SIB1) or via an NAS message. In some examples, IoT reader 950 may receive the charging request configuration from another node (not shown in FIG. 9) . For example, the another node may be a network node, such as a  BS or a CN entity.

[0236] In some examples, IoT reader 950 may transmit a notification indicating the transmission status of a charging signal (i.e., transmitting or not transmitting) . This notification may be indicated by broadcast. The charging signal may be transmitted by broadcast.

[0237] At 913, IoT device 910 may transmit a charging request to IoT reader 950. In some examples, the charging request may indicate a preferred beam (s) for receiving the charging signal. The charging request may be transmitted based on the charging request configuration. For example, IoT device 910 may transmit the charging request when a trigger condition as specified in the charging request configuration is met. For example, IoT reader 950 may trigger or transmit a charging request if the current charging signal is not transmitted via a beam preferred by IoT device 910. The charging request may include information related to the preferred beam (s) .

[0238] In some embodiments, the charging request may be transmitted via MSG1 or MSGA or on a physical channel (e.g., PDRCH) .

[0239] For example, if MSG1 is used for transmitting the charging request, which is associated to a subset of physical random access channel (PRACH) resources, the charging request configuration may include information related to a resource for the charging request. For example, the information may include one or more of the following information:

[0240] - ra-PreambleIndex, indicating a random access preamble index (s) for the charging request. For example, "ra-PreambleIndex" may include one or more RA preamble index ranging from a start RA preamble index (e.g., "ra-PreambleStartIndex" as specified in 3GPP specifications) .

[0241] - ra-occationsC, indicating the configuration of dedicated random access channel (RACH) occasions for the charging request.

[0242] - c-RequestPeriod, indicating the period of the charging request, which can be in units of random access periods.

[0243] IoT device 910 may select a preamble (denoted as preamble #A) if there is more than one preamble. IoT device 910 may determine a PRACH occasion. IoT device 910 may transmit a preamble (e.g., preamble #A) on a PRACH occasion as a  charging request.

[0244] MSGA-based solution is similar to the MSG1-based solution. For example, the charging request configuration may include corresponding information related to the resource for the charging request.

[0245] If the charging request is transmitted on a physical channel (e.g., PDRCH) , the charging request may be included in a control plane message, physical layer signaling, an MAC sub-header or an MAC CE. In some embodiments, at least one bit (e.g., 1 bit) can be used to indicate the charging request. For example, bit value "1" may indicate the need for charging and bit value "0" may indicate no need to charge; or vice versa. In some embodiments, a preamble (denoted as preamble #B) may be transmitted together with the charging request message on the physical channel (e.g., PDRCH) or on a separate physical channel (e.g., PDRCH) .

[0246] In some examples, IoT device 910 may transmit the charging request according to a prohibit timer. For example, when the prohibit timer is not running, IoT device 910 can transmit the charging request. For example, IoT device 910 may deliver the charging request to a physical layer for transmission, and then start the timer in response to the delivery.

[0247] In some embodiments, IoT reader 950 may acknowledge the charging request. For example, at 915 (denoted by a dotted arrow as an option) , IoT reader 950 may transmit a response to IoT device 910. The response may include a preamble ID (e.g., ID of preamble #Aor preamble #B) . In some examples, if the charging request is transmitted via MSG1, the response may be transmitted via MSG2; if the charging request is transmitted via MSGA, the response may be transmitted via MSGB; otherwise, the response may be transmitted on a physical channel (e.g., PRDCH) .

[0248] In some embodiments, if the random access procedure was initiated for charging request and the contention resolution is successful, the MAC entity of IoT device 910 may indicate the reception of an acknowledgement for the charging request to upper layers. For example, if the tag contention resolution identity in the MAC CE corresponding to the response matches the CCCH SDU transmitted in the PDRCH indicating the charging request, the MAC entity of IoT device 910 may consider this  contention resolution successful. The tag contention resolution identity is transmitted in the PRDCH. In some embodiments, a preamble and / or postamble may be transmitted on the PRDCH.

[0249] At 917, IoT reader 950 may transmit a charging signal to IoT device 910 in response to receiving the charging request. The charging signal may be transmitted according to a charging configuration as described above. For example, the charging signal may be transmitted at a periodicity and / or for a certain duration. For example, the charging signal may be transmitted one shot for a certain duration. For example, the charging signal may be transmitted from a time offset after receiving the charging request or transmitting the response.

[0250] IoT device 910 may receive the charging signal accordingly, for example, according to the charging configuration. For example, IoT device 910 may receive the charging signal at a periodicity and / or for a certain duration. For example, IoT device 910 may receive the charging signal from a time offset after transmitting the charging request or receiving the response. For example, IoT device 910 may receive the charging signal for a certain duration.

[0251] In some examples, IoT reader 950 may transmit the charging signal by broadcast. For example, IoT reader 950 may transmit the charging signal on all transmit beams. In some examples, IoT reader 950 may transmit the charging signal in a dedicate manner to IoT device 910. For example, IoT reader 950 may transmit the charging signal on a beam selected or preferred by IoT device 910.

[0252] It should be appreciated by persons skilled in the art that the sequence of the operations in exemplary method 900 may be changed and some of the operations in exemplary method 900 may be eliminated or modified, without departing from the spirit and scope of the disclosure.

[0253] FIG. 10 illustrates a flowchart of method 1000 for wireless communication in accordance with some embodiments of the present disclosure. Details described in all of the foregoing embodiments of the present disclosure are applicable for the embodiments shown in FIG. 10. In some examples, method 1000 may be performed by an IoT device (e.g., an ambient IoT device, such as a tag) . In some embodiments,  the IoT device may execute a set of instructions to control the functional elements of the IoT device to perform the described functions or operations. In some examples, a processor or controller of an IoT device may cause the IoT device to perform method 1000.

[0254] At 1011, a first communication device may determine whether to charge by receiving a signal from a second communication device. At 1013, in response to determining to charge, the first communication device may charge for a duration based on the received signal.

[0255] In some embodiments, the first communication device may determine to charge based on one or more of the following: an energy level of the first communication device being insufficient; the first communication device being in an inactive status; receiving a charging activation command; receiving a charging notification indicating that the second communication device is transmitting the signal; an on-charge duration in a DCX cycle; and receiving signaling indicating a time domain resource for the signal, a frequency domain resource for the signal, or both.

[0256] In some embodiments, the first communication device may determine not to charge based on one or more of the following: a resource for UL overlaps a resource for the signal in a time domain; a resource for DL overlaps the resource for the signal in the time domain; or UL data is available for transmission and a resource for the UL data overlaps the resource for the signal in the time domain.

[0257] In some embodiments, the first communication device may, in response to determining not to charge, perform one or more of the following: transmitting a UL signal for communication on a UL resource; receiving a DL signal for communication on a DL resource; or transmitting pending UL data on a resource for the UL data.

[0258] In some embodiments, the first communication device may, in response to determining not to charge, perform one or more of the following: in the case that a UL resource overlaps a resource for the signal in a time domain, transmitting a UL signal for communication on the UL resource; in the case that a DL resource overlaps the resource for the signal in the time domain, receiving a DL signal for communication on the DL resource; and in the case that UL data is available for transmission and a resource  for the UL data overlaps the resource for the signal in the time domain, transmitting the UL data on the resource for the UL data.

[0259] In some embodiments, the first communication device may receive the signal based on a charging configuration. The charging configuration indicates one or more of the following: an ARFCN of a carrier frequency on which the signal is received; a bandwidth of a carrier or a BWP on which the signal is received; a frequency domain resource for the signal; a time domain resource for the signal; a set of beams for receiving the signal; and a transmission period of the signal in units of beam transmission period.

[0260] In some embodiments, the time domain resource is indicated by one or more of the following: a first time offset associated with a start of the duration; a second time offset associated with an end of the duration; a length of the duration; a third time offset with respect to a timing acquisition signal block (TASB) or a synchronization signal (SS) ; and a DCX cycle, which is indicated by one or more of: a length of the duration in the DCX cycle, a length of the DCX cycle, and a time offset associated with the duration in the DCX cycle.

[0261] In some embodiments, receiving the signal includes one or more of the following: receiving the signal from the first time offset before a paging occasion or from at least the second time offset before the paging occasion; receiving the signal until an end of the duration, or until a start of a next paging occasion, or until an energy level of the first communication device is sufficient, or until the second time offset before the paging occasion; receiving the signal from the third time offset later than a start or an end of the TASB or the SS; and receiving the signal from the first time offset before a DL reception or a UL transmission or from at least the second time offset before the DL reception or the UL transmission.

[0262] In some embodiments, the first communication device may switch to perform the DL reception or the UL transmission after a time offset from the end of the duration or in response to an energy level of the first communication device is sufficient.

[0263] In some embodiments, the first communication device may report one or more of the following to the second communication device: whether the first communication  device is charging or not; an energy status of the first communication device; and an identification of the first communication device.

[0264] In some embodiments, the energy status of the first communication device is reported based on an energy status report configuration. The energy status report configuration indicates one or more of the following: a first energy level threshold for triggering energy status reporting; a second energy level threshold for triggering energy status reporting, wherein the second energy level threshold is higher than the first energy level threshold; a hysteresis value for energy level; a time period for triggering energy status reporting; a reporting periodicity; a threshold for a data volume pending for transmission; a signal condition threshold; a pathloss threshold; a distance threshold; and a value of a prohibit timer.

[0265] In some embodiments, the first communication device may start a prohibit timer in response to reporting the energy status of the first communication device; and wherein the energy status of the first communication device is reported when the prohibit timer is not running.

[0266] In some embodiments, the first communication device may perform one or more of the following: receiving, from the second communication device, a first indication for deactivating or suspending charging; stopping or suspending charging in response to receiving the first indication; receiving, from the second communication device, a second indication for activating or resuming charging; entering into a charging mode in response to receiving the second indication; and receiving, from the second communication device, a third indication indicating support for wireless signal charging or support of an ambient Internet of things (A-IoT) function.

[0267] In some embodiments, the first communication device may transmit a charging request to the second communication device based on a charging request configuration. The charging request configuration indicates one or more of the following: a first energy level threshold for triggering the charging request; a hysteresis value for energy level; a time period for triggering the charging request; a requesting periodicity; a threshold for a data volume pending for transmission; a signal condition threshold; a pathloss threshold; a distance threshold; beam information for charging; and a value of a prohibit timer.

[0268] In some embodiments, the first communication device may perform one or more of: starting the prohibit timer in response to transmitting the charging request; transmitting the charging request when the prohibit timer is not running; receiving a charging response from the second communication device in response to the charging request; receiving the signal from a time offset after receiving the charging response or after transmitting the charging request; and receiving the signal at a periodicity and / or for a duration.

[0269] In some embodiments, the first communication device may perform: not handling a signal for communication when the first communication device is in a charging mode; allow handling a signal for communication outside the duration when the first communication device is in the charging mode; or allow handling a signal for communication when the first communication device is not in the charging mode.

[0270] In some embodiments, the charging configuration is configured by the second communication device or a CN entity or is predefined.

[0271] In some embodiments, the energy status report configuration is configured by the second communication device or a CN entity or is predefined.

[0272] It should be appreciated by persons skilled in the art that the sequence of the operations in exemplary method 1000 may be changed and some of the operations in exemplary method 1000 may be eliminated or modified, without departing from the spirit and scope of the disclosure.

[0273] FIG. 11 illustrates a flowchart of method 1100 for wireless communication in accordance with some embodiments of the present disclosure. Details described in all of the foregoing embodiments of the present disclosure are applicable for the embodiments shown in FIG. 11. In some examples, method 1100 may be performed by an IoT reader, for example, an NE (e.g., NE 102 in FIG. 1) , a BS, a relay node, an IAB node, a WAB network, a UE (e.g., UE 104 in FIG. 1) , a repeater, or a UE-type reader. In some embodiments, the IoT reader may execute a set of instructions to control the functional elements of the IoT reader to perform the described functions or operations. In some examples, a processor or controller of the IoT reader may cause the IoT reader to perform method 1100.

[0274] At 1111, a second communication device may determine whether to charge a first communication device. At 1113, in response to determining to charge the first communication device, the second communication device may transmit a signal to charge the first communication device in a duration.

[0275] In some embodiments, the second communication device may receive a message associated with the first communication device from a CN entity or the first communication device, the message including one or more charging requirements for the first communication device.

[0276] In some embodiments, the message indicates one or more of the following: capability information of the first communication device; one or more frequencies for charging the first communication device; a bandwidth range for charging the first communication device; a cycle length for charging the first communication device; a set of beams for charging the first communication device; and a duration length for charging the first communication device.

[0277] In some embodiments, the signal is transmitted based on a charging configuration. The charging configuration indicates one or more of the following: an ARFCN of a carrier frequency on which the signal is transmitted; a bandwidth of a carrier or a BWP on which the signal is transmitted; a frequency domain resource for the signal; a time domain resource for the signal; a set of beams for transmitting the signal; and a transmission period of the signal in units of beam transmission period.

[0278] In some embodiments, the time domain resource is indicated by one or more of the following: a first time offset associated with a start of the duration; a second time offset associated with an end of the duration; a length of the duration; a third time offset with respect to a TASB or an SS; and a DCX cycle, which is indicated by one or more of:a length of the duration in the DCX cycle, a length of the DCX cycle, and a time offset associated with the duration in the DCX cycle.

[0279] In some embodiments, transmitting the signal includes one or more of the following: transmitting the signal from the third time offset after the TASB or the SS; and transmitting the signal from the first time offset before a paging occasion, a DL transmission to the first communication device or a UL reception from the first  communication device; or transmitting the signal from at least the second time offset before the paging occasion, the DL transmission to the first communication device or the UL reception from the first communication device.

[0280] In some embodiments, the second communication device may transmit a postamble at an end of the duration, or transmit a preamble at a start of the duration.

[0281] In some embodiments, the second communication device may transmit one or more of the following to the first communication device before transmitting the signal: a charging activation command; a charging notification indicating that the second communication device is transmitting the signal; and signaling indicating a time domain resource for the signal, a frequency domain resource for the signal, or both.

[0282] In some embodiments, the second communication device may receive one or more of the following from the first communication device: an indication indicating whether the first communication device is charging or not; an energy status of the first communication device; and an identification of the first communication device.

[0283] In some embodiments, the second communication device may perform one or more of the following: transmitting, to the first communication device, a first indication for deactivating or suspending charging; stopping or suspending the transmission of the signal in response to transmitting the first indication; transmitting, to the first communication device, a second indication for activating or resuming charging; and transmitting, to the first communication device, a third indication indicating support for wireless signal charging or support of an A-IoT function.

[0284] In some embodiments, the second communication device may receive a charging request from the first communication device.

[0285] In some embodiments, the second communication device may perform one or more of: transmitting the signal in response to receiving the charging request; transmitting a charging response to the first communication device in response to receiving the charging request; transmitting the signal from a time offset after transmitting the charging response or after receiving the charging request; and transmitting the signal at a periodicity and / or for a duration.

[0286] In some embodiments, the second communication device may, in response to receiving the indication that the first communication device is not charging or the energy status of the first communication device indicating that an energy level of the first communication device is sufficient, receive a signal for communication from the first communication device or transmit a signal for communication to the first communication device.

[0287] In some embodiments, the second communication device may transmit one or more configurations of a charging configuration, an energy status report configuration and a charging request configuration to the first communication device; or wherein one or more configurations of the charging configuration, the energy status report configuration and the charging request configuration are predefined.

[0288] In some embodiments, the second communication device is a base station (BS) ; or wherein the second communication device is triggered by the BS to transmit the signal to the first communication device.

[0289] It should be appreciated by persons skilled in the art that the sequence of the operations in exemplary method 1100 may be changed and some of the operations in exemplary method 1100 may be eliminated or modified, without departing from the spirit and scope of the disclosure.

[0290] FIG. 12A illustrates a block diagram of exemplary apparatus 1200A according to some embodiments of the present disclosure. As shown in FIG. 12A, the apparatus 1200A may include at least one processor 1206 and at least one transceiver 1202 coupled to the processor 1206. The apparatus 1200A may be an IoT device (e.g., an ambient IoT tag) or an IoT reader (e.g., an NE, a BS, an IAB node, a WAB node, a relay node, a UE, a repeater or a UE-type reader) .

[0291] Although in this figure, elements such as the at least one transceiver 1202 and processor 1206 are described in the singular, the plural is contemplated unless a limitation to the singular is explicitly stated. In some embodiments of the present disclosure, the transceiver 1202 may be divided into two devices, such as a receiving circuitry and a transmitting circuitry. In some embodiments of the present disclosure, the apparatus 1200A may further include an input device, a memory, and / or other  components.

[0292] In some embodiments of the present disclosure, the apparatus 1200A may be an IoT device. The transceiver 1202 and the processor 1206 may interact with each other so as to perform the operations with respect to the IoT device or the first communication device described in the foregoing embodiments such as FIGs. 10 and 11. In some embodiments of the present disclosure, the apparatus 1200A may be an IoT reader. The transceiver 1202 and the processor 1206 may interact with each other so as to perform the operations with respect to the IoT reader or the second communication device described in the foregoing embodiments such as FIGs. 10 and 11.

[0293] In some embodiments of the present disclosure, the apparatus 1200A may further include at least one non-transitory computer-readable medium.

[0294] For example, in some embodiments of the present disclosure, the non-transitory computer-readable medium may have stored thereon computer-executable instructions to cause the processor 1206 to implement the method with respect to the IoT device or the first communication device as described above. For example, the computer-executable instructions, when executed, cause the processor 1206 interacting with transceiver 1202 to perform the operations with respect to the first communication device described in FIGs. 10 and 11.

[0295] In some embodiments of the present disclosure, the non-transitory computer-readable medium may have stored thereon computer-executable instructions to cause the processor 1206 to implement the method with respect to the IoT reader or the second communication device as described above. For example, the computer-executable instructions, when executed, cause the processor 1206 interacting with transceiver 1202 to perform the operations with respect to the second communication device described in FIGs. 10 and 11.

[0296] FIG. 12B illustrates a block diagram of exemplary apparatus 1200B according to some embodiments of the present disclosure. The apparatus 1200B may be an IoT device (e.g., an ambient IoT tag) . As shown in FIG. 12B, the apparatus 1200B may include the following components:

[0297] - Antenna, which could be either shared or separate for radio frequency (RF) energy harvester and receiver / transmitter.

[0298] - Matching network, which is to match impedance between antenna and other components (including RF energy harvester and receiver related blocks) .

[0299] - RF energy harvester, which can include rectifier performing RF signal (alternating current (AC) ) to direct current (DC) conversion.

[0300] - Energy storage (e.g., capacitor) , which stores harvested energy from RF energy harvester.

[0301] - Power management unit (PMU) , which manages storing energy to energy storage from energy harvester and suppling power to active component blocks which needs power supply.

[0302] - Digital baseband processor (BB) logic, which includes functional blocks like encoder, decoder, controller, etc.

[0303] - Memory, which can include two types of memory: 1) non-volatile memory (NVM) such as EEPROM for permanently storing device ID, etc.; and 2) registers for temporarily keeping any information required for its operation only while energy is available in energy storage.

[0304] - Clock generator, which provides required clock signal (s) .

[0305] - Reception related blocks, including for example:

[0306] ● RF band pass filter (BPF) for improving selectivity, which may not exist.

[0307] ● RF Envelope Detector, which converts RF signal to baseband.

[0308] ● BB lower pass filter (LPF) , which can filter out harmonics and high frequency components to improve input signal quality to comparator. This may not exist.

[0309] ● Comparator, which determines high / low of input signal.

[0310] - Transmission related blocks

[0311] ● Backscatter modulator, which switches impedance to modulate backscattered signal with transmit signal from BB logics.

[0312] FIG. 12C illustrates a block diagram of exemplary apparatus 1200C according to some embodiments of the present disclosure. The apparatus 1200C may be an IoT device (e.g., an ambient IoT tag) . As shown in FIG. 12C, the apparatus 1200C may include the following components:

[0313] - Antenna, which could be either shared or separate for RF energy harvester (if present) and receiver / transmitter.

[0314] - Matching network, which is to match impedance between antenna and other components (including RF energy harvester (if present) and receiver related blocks) .

[0315] - Energy harvester, which may include a RF energy harvester and an energy harvester for signals other than RF, or only include one of the harvester.

[0316] - Energy storage (e.g., capacitor) , which stores harvested energy from energy harvester.

[0317] - PMU, which manages storing energy to energy storage from energy harvester and suppling power to active component blocks which needs power supply.

[0318] - Digital BB logic, which includes functional blocks like encoder, decoder, controller, etc.

[0319] - Memory, which can include two types of memory: 1) non-volatile memory (NVM) such as EEPROM for permanently storing device ID, etc.; and 2) registers for temporarily keeping any information required for its operation only while energy is available in energy storage.

[0320] - Clock generator, which provides required clock signal (s) .

[0321] - Reflection amplifier, which can amplify reflected backscattered signal.

[0322] - Reception related blocks

[0323] ● RF BPF filter for improving selectivity. This may not exist.

[0324] ● Low noise amplifier (LNA) for improving signal strength and sensitivity of the receiver. This may not exist.

[0325] ● RF envelope detector (RF-ED) , which detects envelope from RF signal.

[0326] ● BB amplifier, which amplifies BB signal to improve signal strength.

[0327] ● BB LPF, which can filter out harmonics and high frequency components to improve input signal quality to comparator or analog-to-digital converter (ADC) . This may not exist.

[0328] ● Comparator or N-bit ADC

[0329] - Transmission related blocks

[0330] ● Backscatter modulator, which switches impedance to modulate backscattered signal with transmit signal from BB logics.

[0331] ● Large frequency shifter (e.g., tens of MHz) for shifting backscattered signal from one frequency (e.g., FDD-DL frequency) to another frequency (e.g., FDD-UL frequency) . This may not exist.

[0332] FIG. 13 illustrates an example of a UE 1300 in accordance with aspects of the present disclosure. The UE 1300 may include a processor 1302, a memory 1304, a controller 1306, and a transceiver 1308. The processor 1302, the memory 1304, the controller 1306, or the transceiver 1308, 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.

[0333] The processor 1302, the memory 1304, the controller 1306, or the transceiver 1308, 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.

[0334] The processor 1302 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 1302 may be configured to operate the memory 1304. In some other implementations, the memory 1304 may be integrated into the processor 1302. The processor 1302 may be configured to execute computer-readable instructions stored in the memory 1304 to cause the UE 1300 to perform various functions of the present disclosure.

[0335] The memory 1304 may include volatile or non-volatile memory. The memory 1304 may store computer-readable, computer-executable code including instructions when executed by the processor 1302 cause the UE 1300 to perform various functions described herein. The code may be stored in a non-transitory computer-readable medium such as the memory 1304 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.

[0336] In some implementations, the processor 1302 and the memory 1304 coupled with the processor 1302 may be configured to cause the UE 1300 to perform one or more of the functions described herein (e.g., executing, by the processor 1302, instructions stored in the memory 1304) . For example, the processor 1302 may support wireless communication at the UE 1300 in accordance with examples as disclosed herein. For example, the UE 1300 may be configured to support means for performing the operations as described with respect to FIG. 11.

[0337] For example, the UE 1300 may be configured to support: a means for  determining whether to charge a first communication device; and a means for transmitting a signal to charge the first communication device in a duration in response to determining to charge the first communication device.

[0338] The controller 1306 may manage input and output signals for the UE 1300. The controller 1306 may also manage peripherals not integrated into the UE 1300. In some implementations, the controller 1306 may utilize an operating system such as  or other operating systems. In some implementations, the controller 1306 may be implemented as part of the processor 1302.

[0339] In some implementations, the UE 1300 may include at least one transceiver 1308. In some other implementations, the UE 1300 may have more than one transceiver 1308. The transceiver 1308 may represent a wireless transceiver. The transceiver 1308 may include one or more receiver chains 1310, one or more transmitter chains 1312, or a combination thereof.

[0340] A receiver chain 1310 may be configured to receive signals (e.g., control information, data, or packets) over a wireless medium. For example, the receiver chain 1310 may include one or more antennas for receive the signal over the air or wireless medium. The receiver chain 1310 may include at least one amplifier (e.g., a low-noise amplifier (LNA) ) configured to amplify the received signal. The receiver chain 1310 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 1310 may include at least one decoder for decoding the processing the demodulated signal to receive the transmitted data.

[0341] A transmitter chain 1312 may be configured to generate and transmit signals (e.g., control information, data, or packets) . The transmitter chain 1312 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 1312 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 1312 may also include one or more antennas for transmitting the amplified signal into the air or wireless medium.

[0342] It should be appreciated by persons skilled in the art that the components in exemplary UE 1300 may be changed, for example, some of the components in exemplary UE 1300 may be omitted or modified or a new component (s) may be added to exemplary UE 1300, without departing from the spirit and scope of the disclosure. For example, in some embodiments, the UE 1300 may not include the controller 1306.

[0343] FIG. 14 illustrates an example of a processor 1400 in accordance with aspects of the present disclosure. The processor 1400 may be an example of a processor configured to perform various operations in accordance with examples as described herein. The processor 1400 may include a controller 1402 configured to perform various operations in accordance with examples as described herein. The processor 1400 may optionally include at least one memory 1404, which may be, for example, an L1 / L2 / L3 cache. Additionally, or alternatively, the processor 1400 may optionally include one or more arithmetic-logic units (ALUs) 1406. 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) .

[0344] The processor 1400 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 1400) 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) .

[0345] The controller 1402 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 1400 to cause the processor 1400 to support various operations in accordance with examples as described herein. For example, the controller 1402 may operate as a control unit of the processor 1400, generating control signals that manage the operation of various components of the processor 1400. These control signals include enabling or disabling functional units, selecting data paths, initiating memory access, and coordinating timing of operations.

[0346] The controller 1402 may be configured to fetch (e.g., obtain, retrieve, receive) instructions from the memory 1404 and determine a subsequent instruction (s) to be executed to cause the processor 1400 to support various operations in accordance with examples as described herein. The controller 1402 may be configured to track memory address of instructions associated with the memory 1404. The controller 1402 may be configured to decode instructions to determine the operation to be performed and the operands involved. For example, the controller 1402 may be configured to interpret the instruction and determine control signals to be output to other components of the processor 1400 to cause the processor 1400 to support various operations in accordance with examples as described herein. Additionally, or alternatively, the controller 1402 may be configured to manage flow of data within the processor 1400. The controller 1402 may be configured to control transfer of data between registers, ALUs, and other functional units of the processor 1400.

[0347] The memory 1404 may include one or more caches (e.g., memory local to or included in the processor 1400 or other memory, such RAM, ROM, DRAM, SDRAM, SRAM, MRAM, flash memory, etc. In some implementations, the memory 1404 may reside within or on a processor chipset (e.g., local to the processor 1400) . In some other implementations, the memory 1404 may reside external to the processor chipset (e.g., remote to the processor 1400) .

[0348] The memory 1404 may store computer-readable, computer-executable code including instructions that, when executed by the processor 1400, cause the processor 1400 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 1402 and / or the processor 1400 may be configured to execute  computer-readable instructions stored in the memory 1404 to cause the processor 1400 to perform various functions. For example, the processor 1400 and / or the controller 1402 may be coupled with or to the memory 1404, the processor 1400, the controller 1402, and the memory 1404 may be configured to perform various functions described herein. In some examples, the processor 1400 may include multiple processors and the memory 1404 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.

[0349] The one or more ALUs 1406 may be configured to support various operations in accordance with examples as described herein. In some implementations, the one or more ALUs 1406 may reside within or on a processor chipset (e.g., the processor 1400) . In some other implementations, the one or more ALUs 1406 may reside external to the processor chipset (e.g., the processor 1400) . One or more ALUs 1406 may perform one or more computations such as addition, subtraction, multiplication, and division on data. For example, one or more ALUs 1406 may receive input operands and an operation code, which determines an operation to be executed. One or more ALUs 1406 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 1406 may support logical operations such as AND, OR, exclusive-OR (XOR) , not-OR (NOR) , and not-AND (NAND) , enabling the one or more ALUs 1406 to handle conditional operations, comparisons, and bitwise operations.

[0350] The processor 1400 may support wireless communication in accordance with examples as disclosed herein.

[0351] For example, the processor 1400 may be configured to support means for performing the operations as described with respect to FIG. 10. For example, the processor 1400 may be configured to or operable to support: a means for determining whether to charge by receiving a signal from a second communication device; and a means for charging for a duration based on the received signal in response to determining to charge.

[0352] For example, the processor 1400 may be configured to support means for  performing the operations as described with respect to FIG. 11. For example, the processor 1400 may be configured to or operable to support: a means for determining whether to charge a first communication device; and a means for transmitting a signal to charge the first communication device in a duration in response to determining to charge the first communication device.

[0353] It should be appreciated by persons skilled in the art that the components in exemplary processor 1400 may be changed, for example, some of the components in exemplary processor 1400 may be omitted or modified or a new component (s) may be added to exemplary processor 1400, without departing from the spirit and scope of the disclosure. For example, in some embodiments, the processor 1400 may not include the ALUs 1406.

[0354] FIG. 15 illustrates an example of an NE 1500 in accordance with aspects of the present disclosure. The NE 1500 may include a processor 1502, a memory 1504, a controller 1506, and a transceiver 1508. The processor 1502, the memory 1504, the controller 1506, or the transceiver 1508, 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.

[0355] The processor 1502, the memory 1504, the controller 1506, or the transceiver 1508, or various combinations or components thereof may be implemented in hardware (e.g., circuitry) . The hardware may include a processor, a DSP, an 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.

[0356] The processor 1502 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 1502 may be configured to operate the memory 1504. In some other implementations, the memory 1504 may be integrated into the processor 1502. The processor 1502 may be configured to execute computer-readable instructions stored in the memory 1504 to cause the NE 1500 to perform various functions of the present disclosure.

[0357] The memory 1504 may include volatile or non-volatile memory. The memory 1504 may store computer-readable, computer-executable code including instructions when executed by the processor 1502 cause the NE 1500 to perform various functions described herein. The code may be stored in a non-transitory computer-readable medium such as the memory 1504 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.

[0358] In some implementations, the processor 1502 and the memory 1504 coupled with the processor 1502 may be configured to cause the NE 1500 to perform one or more of the functions described herein (e.g., executing, by the processor 1502, instructions stored in the memory 1504) . For example, the processor 1502 may support wireless communication at the NE 1500 in accordance with examples as disclosed herein. For example, the NE 1500 may be configured to support means for performing the operations as described with respect to FIG. 11.

[0359] For example, the NE 1500 may be configured to support: a means for determining whether to charge a first communication device; and a means for transmitting a signal to charge the first communication device in a duration in response to determining to charge the first communication device.

[0360] The controller 1506 may manage input and output signals for the NE 1500. The controller 1506 may also manage peripherals not integrated into the NE 1500. In some implementations, the controller 1506 may utilize an operating system such as  or other operating systems. In some implementations, the controller 1506 may be implemented as part of the processor 1502.

[0361] In some implementations, the NE 1500 may include at least one transceiver 1508. In some other implementations, the NE 1500 may have more than one transceiver 1508. The transceiver 1508 may represent a wireless transceiver. The transceiver 1508 may include one or more receiver chains 1510, one or more transmitter chains 1512, or a combination thereof.

[0362] A receiver chain 1510 may be configured to receive signals (e.g., control information, data, or packets) over a wireless medium. For example, the receiver chain 1510 may include one or more antennas for receive the signal over the air or wireless medium. The receiver chain 1510 may include at least one amplifier (e.g., an LNA) configured to amplify the received signal. The receiver chain 1510 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 1510 may include at least one decoder for decoding the processing the demodulated signal to receive the transmitted data.

[0363] A transmitter chain 1512 may be configured to generate and transmit signals (e.g., control information, data, or packets) . The transmitter chain 1512may 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 AM, FM, or digital modulation schemes like PSK or QAM. The transmitter chain 1512 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 1512 may also include one or more antennas for transmitting the amplified signal into the air or wireless medium.

[0364] It should be appreciated by persons skilled in the art that the components in exemplary NE 1500 may be changed, for example, some of the components in exemplary NE 1500 may be omitted or modified or a new component (s) may be added to exemplary NE 1500, without departing from the spirit and scope of the disclosure. For example, in some embodiments, the NE 1500 may not include the controller 1506.

[0365] Those having ordinary skill in the art would understand that the operations or steps of the methods described in connection with the aspects disclosed herein may be embodied directly in hardware, in a software module executed by a processor, or in a combination of the two. A software module may reside in RAM memory, flash memory, ROM memory, EPROM memory, EEPROM memory, registers, a hard disk, a removable disk, a CD-ROM, or any other form of storage medium known in the art. Additionally, in some aspects, the operations or steps of the methods may reside as one  or any combination or set of codes and / or instructions on a non-transitory computer-readable medium, which may be incorporated into a computer program product.

[0366] While this disclosure has been described with specific embodiments thereof, it is evident that many alternatives, modifications, and variations may be apparent to those skilled in the art. The disclosure is not limited to the examples and designs described herein but is to be accorded with the broadest scope consistent with the principles and novel features disclosed herein. For example, various components of the embodiments may be interchanged, added, or substituted in other embodiments. Also, all of the elements of each figure are not necessary for the operation of the disclosed embodiments. For example, one of ordinary skill in the art of the disclosed embodiments would be enabled to make and use the teachings of the disclosure by simply employing the elements of the independent claims. Accordingly, embodiments of the disclosure as set forth herein are intended to be illustrative, not limiting. Various changes may be made without departing from the spirit and scope of the disclosure.

[0367] In this document, the terms "includes, " "including, " or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that includes a list of elements does not include only those elements but may include other elements not expressly listed or inherent to such process, method, article, or apparatus. An element proceeded by "a, " "an, " or the like does not, without more constraints, preclude the existence of additional identical elements in the process, method, article, or apparatus that includes the element. Also, the term "another" is defined as at least a second or more. The term "having" or the like, as used herein, is defined as "including. " Expressions such as "A and / or B" or "at least one of A and B" may include any and all combinations of words enumerated along with the expression. For instance, the expression "A and / or B" or "at least one of A and B" may include A, B, or both A and B. The wording "the first, " "the second" or the like is only used to clearly illustrate the embodiments of the present disclosure, but is not used to limit the substance of the present disclosure.

Claims

1.A first communication device, comprising:at least one memory; andat least one processor coupled with the at least one memory and configured to cause the first communication device to:determine whether to charge by receiving a signal from a second communication device; andin response to determining to charge, charge for a duration based on the received signal.2.The first communication device of claim 1, wherein the at least one processor is configured to cause the first communication device to determine to charge based on one or more of the following:an energy level of the first communication device being insufficient;the first communication device being in an inactive status;receiving a charging activation command;receiving a charging notification indicating that the second communication device is transmitting the signal;an on-charge duration in a discontinuous charging reception (DCX) cycle; andreceiving signaling indicating a time domain resource for the signal, a frequency domain resource for the signal, or both.3.The first communication device of claim 1, wherein the at least one processor is configured to cause the first communication device to receive the signal based on a charging configuration, and the charging configuration indicates one or more of the following:an absolute radio-frequency channel number (ARFCN) of a carrier frequency on which the signal is received;a bandwidth of a carrier or a bandwidth part (BWP) on which the signal is received;a frequency domain resource for the signal;a time domain resource for the signal;a set of beams for receiving the signal; anda transmission period of the signal in units of beam transmission period.4.The first communication device of claim 3, wherein the time domain resource is indicated by one or more of the following:a first time offset associated with a start of the duration;a second time offset associated with an end of the duration;a length of the duration;a third time offset with respect to a timing acquisition signal block (TASB) or a synchronization signal (SS) ; anda discontinuous charging reception (DCX) cycle, which is indicated by one or more of: a length of the duration in the DCX cycle, a length of the DCX cycle, and a time offset associated with the duration in the DCX cycle.5.The first communication device of claim 1, wherein the at least one processor is further configured to cause the first communication device to switch to perform the DL reception or the UL transmission after a time offset from the end of the duration or in response to an energy level of the first communication device is sufficient.6.The first communication device of claim 1, wherein the at least one processor is further configured to cause the first communication device to report one or more of the following to the second communication device:whether the first communication device is charging or not;an energy status of the first communication device; andan identification of the first communication device.7.The first communication device of claim 6, wherein the energy status of the first communication device is reported based on an energy status report configuration, and the energy status report configuration indicates one or more of the following:a first energy level threshold for triggering energy status reporting;a second energy level threshold for triggering energy status reporting, wherein the second energy level threshold is higher than the first energy level threshold;a hysteresis value for energy level;a time period for triggering energy status reporting;a reporting periodicity;a threshold for a data volume pending for transmission;a signal condition threshold;a pathloss threshold;a distance threshold; anda value of a prohibit timer.8.The first communication device of claim 1, wherein the at least one processor is further configured to cause the first communication device to transmit a charging request to the second communication device based on a charging request configuration, and the charging request configuration indicates one or more of the following:a first energy level threshold for triggering the charging request;a hysteresis value for energy level;a time period for triggering the charging request;a requesting periodicity;a threshold for a data volume pending for transmission;a signal condition threshold;a pathloss threshold;a distance threshold;beam information for charging; anda value of a prohibit timer.9.The first communication device of claim 1, wherein the at least one processor is further configured to cause the first communication device to:not handling a signal for communication when the first communication device is in a charging mode;allow handling a signal for communication outside the duration when the first communication device is in the charging mode; orallow handling a signal for communication when the first communication device is not in the charging mode.10.A second communication device, comprising:at least one memory; andat least one processor coupled with the at least one memory and configured to cause the second communication device to:determine whether to charge a first communication device; andin response to determining to charge the first communication device, transmit a signal to charge the first communication device in a duration.11.The second communication device of claim 10, wherein the at least one processor is further configured to cause the second communication device to receive a message associated with the first communication device from a core network (CN) entity or the first communication device, the message comprising one or more charging requirements for the first communication device.12.The second communication device of claim 10, wherein the signal is transmitted based on a charging configuration, and the charging configuration indicates one or more of the following:an absolute radio-frequency channel number (ARFCN) of a carrier frequency on which the signal is transmitted;a bandwidth of a carrier or a bandwidth part (BWP) on which the signal is transmitted;a frequency domain resource for the signal;a time domain resource for the signal;a set of beams for transmitting the signal; anda transmission period of the signal in units of beam transmission period.13.The second communication device of claim 10, wherein the at least one processor is further configured to cause the second communication device to transmit one or more of the following to the first communication device before transmitting the signal:a charging activation command;a charging notification indicating that the second communication device is transmitting the signal ; andsignaling indicating a time domain resource for the signal , a frequency domain resource for the signal, or both.14.The second communication device of claim 10, wherein the at least one processor is further configured to cause the second communication device to receive one or more of the following from the first communication device:an indication indicating whether the first communication device is charging or not;an energy status of the first communication device; andan identification of the first communication device.15.The second communication device of claim 10, wherein the at least one processor is further configured to cause the second communication device to perform one or more of the following:transmitting, to the first communication device, a first indication for deactivating or suspending charging;stopping or suspending the transmission of the signal in response to transmitting the first indication;transmitting, to the first communication device, a second indication for activating or resuming charging; andtransmitting, to the first communication device, a third indication indicating support for wireless signal charging or support of an ambient Internet of things (A-IoT) function.16.The second communication device of claim 10, wherein the at least one processor is further configured to cause the second communication device to receive a charging request from the first communication device.17.The second communication device of claim 14, wherein the at least one processor is further configured to cause the second communication device to, in response to receiving the indication that the first communication device is not charging or the energy status of the first communication device indicating that an energy level of the first communication device is sufficient, receive a signal for communication from the first communication device or transmit a signal for communication to the first communication device.18.The second communication device of claim 10, wherein the at least one processor is further configured to cause the second communication device to transmit one or more configurations of a charging configuration, an energy status report configuration and a charging request configuration to the first communication device; or wherein one or more configurations of the charging configuration, the energy status report configuration and the charging request configuration are predefined.19.A processor, comprising:at least one controller coupled with at least one memory and configured to cause the processor to:determine whether to charge by receiving a signal from a second communication device; andin response to determining to charge, charge for a duration based on the received signal.20.A method for charging, comprising:determining whether to charge by receiving a signal from a second communication device; andin response to determining to charge, charging for a duration based on the received signal.

Images