WO2025235263A1 - Managing energy and signal monitoring in ambient internet-of-things (aiot) devices - Google Patents

Abstract

A method includes determining a first time period for a device to charge from a first energy level to a second energy level, wherein the first energy level is lower than the second energy level. The method includes determining a second time period for the device to discharge from the second energy level to the first energy level. The method includes charging the device during the first time period. The method includes monitoring for a query command from a reader during the second time period.

Description

MANAGING ENERGY AND SIGNAL MONITORING IN AMBIENT INTERNET- OF-THINGS (AIOT) DEVICES

CROSS-REFERENCE TO RELATED APPLICATIONS

[0001] This application claims priority to U.S. Provisional Application No. 63/645,294, filed on May 10, 2024, which is incorporated herein by reference in its entirety.

BACKGROUND

[0002] Wireless communication networks provide integrated communication platforms and telecommunication services to wireless user devices. Example telecommunication services include telephony, data (e.g., voice, audio, and/or video data), messaging, and/or other services. The wireless communication networks have wireless access nodes that exchange wireless signals with the wireless user devices using one or more wireless network protocols, such as protocols described in various telecommunication standards promulgated by the ETSI Third Generation Partnership Project (3GPP). The wireless communication networks facilitate mobile broadband service using technologies such as orthogonal frequency-division multiple access (OFDMA), multiple input multiple output (MIMO), advanced channel coding, massive MIMO, beamforming, and/or other features.

[0003] Internet-of-Things (loT) technology allows a variety of devices to be wirelessly connected to an loT reader via a communication network. For example, a radio frequency identification (RFID) tag may be wirelessly connected to an RFID reader such that the reader can obtain information from the tag and pass the information to a server for processing. An Ambient loT (AIoT) device is an loT device that supports harvesting energy from the environment, e.g., by backscattering carrier waves external to the AIoT device, to support communications with an AIoT reader. Based on the device’ s power capability, an AIoT device can be classified as a type-1 device or a type-2 device. A type-1 device can have a peak power consumption of about 1 microwatt (pW), whereas a type-2 device can have a peak power consumption of up to a few hundred pW. SUMMARY

[0004] In accordance with one aspect of the present disclosure, a method is provided. The method includes determining a first time period for a device to charge from a first energy level to a second energy level, wherein the first energy level is lower than the second energy level. The method includes determining a second time period for the device to discharge from the second energy level to the first energy level. The method includes charging the device during the first time period. The method includes monitoring for a query command from a reader during the second time period.

[0005] In some implementations, the method further includes switching off a receiver circuit of the device during the first time period.

[0006] In some implementations, the device is fully charged at the second energy level, and the device is fully discharged at the first energy level.

[0007] In some implementations, the method further includes receiving a configuration message from the reader. The configuration message indicates at least one of: a value of the first time period, or a value of the second time period.

[0008] In some implementations, the configuration message further indicates a discharge mode of the device, and wherein the discharge mode is one of a full discharge mode or a partial charge mode.

[0009] In some implementations, the method further includes determining a third time period for the device to charge from a third energy level to the second energy level, wherein the third energy level is lower than the first energy level, and wherein the third time period precedes the first time period and the second time period; and charging the device during the third time period.

[0010] In some implementations, the device is (i) partially discharged at the first energy level, (ii) fully charged at the second energy level, and (iii) fully discharged at the third energy level.

[0011] In some implementations, the method further includes receiving a configuration message from the reader. The configuration message indicates at least one of: a value of the first time period, a value of the second time period, or a value of the third time period.

[0012] In some implementations, the configuration message further includes an offset value, and wherein the first time period is determined based on the offset value. [0013] In some implementations, the device belongs to a group of devices that receives the configuration message in a broadcast. The configuration message further includes an index of the group.

[0014] In some implementations, at least one of the first time period or the second time period is determined based on a configuration parameter value stored in a memory of the device.

[0015] In some implementations, the method further includes: receiving the query command from the reader, wherein the query command includes a trigger for capability reporting; and in response to the trigger, transmitting a capability report message from the device to the reader, wherein the capability report message includes information about a discharge mode supported by the device.

[0016] In some implementations, the method further includes receiving the query command from the reader, wherein the query command includes a timing indicator field and a query process number field; generating a query response based on a value of query process number field; and transmitting the query response to the reader at a time specified by the timing indicator field.

[0017] In some implementations, the query command further includes a query repetition command.

[0018] In accordance with another aspect of the present disclosure, a method is provided. The method includes determining a first time period for a device to charge from a first energy level to a second energy level, wherein the first energy level is lower than the second energy level. The method includes determining a second time period for the device to discharge from the second energy level to the first energy level. The method includes transmitting a query command to the device during the second time period.

[0019] In some implementations, the method further includes transmitting a configuration message to the device. The configuration message indicates at least one of: a value of the first time period, or a value of the second time period.

[0020] In some implementations, the configuration message further indicates a discharge mode of the device. The discharge mode is one of a full discharge mode or a partial charge mode.

[0021] In some implementations, the method further includes determining a third time period for the device to charge from a third energy level to the second energy level. The third energy level is lower than the first energy level. The third time period precedes the first time period and the second time period.

[0022] In some implementations, the method further includes transmitting a configuration message to the device. The configuration message indicates at least one of a value of the first time period, a value of the second time period, or a value of the third time period

[0023] In some implementations, the method further includes broadcasting the configuration message to a plurality of devices.

[0024] In some implementations, the query command includes a trigger for capability reporting. The method further includes receiving a capability report message by the reader from the device. The capability report message includes information of a discharge mode supported by the device.

[0025] In some implementations, the method further includes: transmitting a plurality of configuration messages to a plurality of device groups, wherein each configuration message includes an offset value that is unique to that device group; and transmitting a plurality of query commands respectively to the plurality of device groups. Each query command is transmitted at a time based on the offset value unique to that device group.

[0026] In some implementations, the method further includes transmitting the query command to the device, wherein the query command includes a timing indicator field and a query process number field; and receiving, from the device and at a time indicated by the timing indicator field, a query response associated with a query process number. The query process number is indicated by the query process number field.

[0027] The above methods can be implemented as instructions stored in a memory and executed by one or more processors of an apparatus.

[0028] The details of one or more implementations of these systems and methods are set forth in the accompanying drawings and the description below. Other features, objects, and advantages of these systems and methods will be apparent from the description and drawings, and from the claims. BRIEF DESCRIPTION OF THE FIGURES

[0029] FIG. 1 illustrates a wireless network, according to some implementations.

[0030] FIGs. 2A and 2B each illustrate a scenario in which an AIoT reader communicates with an AIoT device, according to some implementations.

[0031] FIGs. 3A and 3B each illustrate a plot showing the power of an AIoT device as the AIoT device switches between charging and discharging, according to some implementations.

[0032] FIG. 4 illustrates a table showing example fields of a configuration message, according to some implementations.

[0033] FIG. 5 illustrates an example procedure in which an AIoT reader configures an AIoT device with a discontinuous charging and signal monitoring (DCSM) mode, according to some implementations.

[0034] FIG. 6 illustrates an example procedure of an AIoT reader querying multiple groups of AIoT devices, according to some implementations.

[0035] FIG. 7 illustrates an example procedure of an AIoT reader querying multiple AIoT devices in parallel multiple querying processes, according to some implementations.

[0036] FIGs. 8A and 8B each illustrate a flowchart of an example method, according to some implementations.

[0037] FIG. 9 illustrates an example user equipment (UE), according to some implementations.

[0038] FIG. 10 illustrates an example access node, according to some implementations.

DETAILED DESCRIPTION

[0039] Some AIoT devices operate largely based on energy harvested from carrier waves present in the environment. An energizer can sometimes be used to broadcast carrier waves to power nearby AIoT devices. Using the harvested energy, an AIoT device can monitor for downlink messages, such as query commands, from an AIoT reader and respond to the received commands accordingly, e.g., by transmitting uplink data in an inventory procedure.

[0040] Currently, an AIoT device does not know when a downlink message will arrive. Accordingly, the AIoT device may be configured to operate in an “always-on” mode, in which the AIoT device keeps its receiver circuitry always available for a potential incoming downlink message. To support operation in the “always-on” mode, the AIoT device typically consumes power in a relatively high rate. Usually, the farther an AIoT device from the energizer, the lower the energy harvesting efficiency of the AIoT device. Accordingly, it is difficult to increase the range of operation of AIoT devices without significantly increasing the deployment cost of the energizer. In addition, keeping an AIoT device in the “always-on” mode may lead to interference with other wireless communication devices. Moreover, the continuous emission of radio waves by an AIoT device may raise concerns about human and environment safety.

[0041] This disclosure provides techniques in view of the problems with current AIoT communications. As described in detail below, one or more implementations provide mechanisms for an AIoT device to determine a time window for energy harvesting without monitoring for downlink messages. Using the disclosed mechanisms, the AIoT device can switch off the receiver circuitry during this time window, which can save power and reduce emission. One or more implementations also allow for multiple AIoT devices to monitor for and process downlink messages from the same AIoT reader in parallel, which can increase communication throughput especially when a large number of AIoT devices are present.

[0042] In the following description, it is assumed that each AIoT device is implemented with a UE and each AIoT reader is implemented with a base station. However, other implementations are also possible. For example, it may be possible to implement an AIoT reader with a UE and implement an AIoT device with a battery-less tag. Further, the description below uses a query command as an example of downlink messages sent from an AIoT reader to an AIoT device, although other types of downlink messages are possible in some implementations. [0043] FIG. 1 illustrates a wireless network 100, according to some implementations. The wireless network 100 includes a UE 102 and a base station 104 connected via one or more channels 106A, 106B across an air interface 108. The UE 102 and base station 104 communicate using a system that supports controls for managing the access of the UE 102 to a network via the base station 104.

[0044] In some implementations, the wireless network 100 may be a Non- Standalone (NS A) network that incorporates Long Term Evolution (LTE) and Fifth Generation (5G) New Radio (NR) communication standards as defined by the Third Generation Partnership Project (3 GPP) technical specifications. For example, the wireless network 100 may be a E-UTRA (Evolved Universal Terrestrial Radio Access)-NR Dual Connectivity (EN-DC) network, or an NR- EUTRA Dual Connectivity (NE-DC) network. In some other implementations, the wireless network 100 may be a Standalone (SA) network that incorporates only 5G NR. Furthermore, other types of communication standards are possible, including future 3 GPP systems (e.g., Sixth Generation (6G)), Institute of Electrical and Electronics Engineers (IEEE) 802.11 technology, or the like. While aspects may be described herein using terminology commonly associated with 5GNR, aspects of the present disclosure can be applied to other systems, such as systems subsequent to 5G (e.g., 6G).

[0045] In the wireless network 100, the UE 102 and any other UE in the system may be, for example, any of laptop computers, smartphones, tablet computers, machine-type devices such as smart meters or specialized devices for healthcare, intelligent transportation systems, or any other wireless device. In network 100, the base station 104 provides the UE 102 network connectivity to a broader network (not shown). This UE 102 connectivity is provided via the air interface 108 in a base station service area provided by the base station 104. In some implementations, such a broader network may be a wide area network operated by a cellular network provider, or may be the Internet. Each base station service area associated with the base station 104 is supported by one or more antennas integrated with the base station 104. The service areas can be divided into a number of sectors associated with one or more particular antennas. Such sectors may be physically associated with one or more fixed antennas or may be assigned to a physical area with one or more tunable antennas or antenna settings adjustable in a beamforming process used to direct a signal to a particular sector.

[0046] The UE 102 includes control circuitry 110 coupled with transmit circuitry 112 and receive circuitry 114. The transmit circuitry 112 and receive circuitry 114 may each be coupled with one or more antennas. The control circuitry 110 may include various combinations of application-specific circuitry and baseband circuitry. The transmit circuitry 112 and receive circuitry 114 may be adapted to transmit and receive data, respectively, and may include radio frequency (RF) circuitry and/or front-end module (FEM) circuitry.

[0047] In various implementations, aspects of the transmit circuitry 112, receive circuitry 114, and control circuitry 110 may be integrated in various ways to implement the operations described herein. The control circuitry 110 may be adapted or configured to perform various operations, such as those described elsewhere in this disclosure related to a UE. For instance, the control circuitry 110 can control UE 102 to switch between monitoring for a query command and harvesting energy.

[0048] The transmit circuitry 112 can perform various operations described in this specification. For example, the transmit circuitry 112 can transmit uplink data in response to a query command. Additionally, the transmit circuitry 112 may transmit using a plurality of multiplexed uplink physical channels. The plurality of uplink physical channels may be multiplexed, e.g., according to time division multiplexing (TDM) or frequency division multiplexing (FDM) along with carrier aggregation. The transmit circuitry 112 may be configured to receive block data from the control circuitry 110 for transmission across the air interface 108.

[0049] The receive circuitry 114 can perform various operations described in this specification. For instance, the receive circuitry 114 can receive a query command from an AIoT reader. Additionally, the receive circuitry 114 may receive a plurality of multiplexed downlink physical channels from the air interface 108 and relay the physical channels to the control circuitry 110. The plurality of downlink physical channels may be multiplexed, e.g., according to TDM or FDM along with carrier aggregation. The transmit circuitry 112 and the receive circuitry 114 may transmit and receive, respectively, both control data and content data (e.g., messages, images, video, etc.) structured within data blocks that are carried by the physical channels.

[0050] FIG. 1 also illustrates the base station 104. In some implementations, the base station 104 may be a 5G radio access network (RAN), a next generation RAN, a E-UTRAN, a nonterrestrial cell, or a legacy RAN, such as a UTRAN. As used herein, the term “5G RAN” or the like may refer to the base station 104 that operates in an NR or 5G wireless network 100, and the term “E-UTRAN” or the like may refer to a base station 104 that operates in an LTE or 4G wireless network 100. The UE 102 utilizes connections (or channels) 106A, 106B, each of which includes a physical communications interface or layer.

[0051] The base station 104 circuitry may include control circuitry 116 coupled with transmit circuitry 118 and receive circuitry 120. The transmit circuitry 118 and receive circuitry 120 may each be coupled with one or more antennas that may be used to enable communications via the air interface 108. The transmit circuitry 118 and receive circuitry 120 may be adapted to transmit and receive data, respectively, to any UE connected to the base station 104. The receive circuitry 120 may receive a plurality of uplink physical channels from one or more UEs, including the UE 102.

[0052] In FIG. 1, the one or more channels 106 A, 106B are illustrated as an air interface to enable communicative coupling, and can be consistent with cellular communications protocols, such as a 5G protocol, an NR-based access to unlicensed spectrum (NR-U) protocol, and/or any other communications protocol(s). In implementations, the UE 102 may directly exchange communication data with another UE (not shown) via a ProSe interface. The ProSe interface may alternatively be referred to as a sidelink (SL) interface and may include one or more logical channels, including but not limited to a Physical Sidelink Control Channel (PSCCH), a Physical Sidelink Discovery Channel (PSDCH), and a Physical Sidelink Broadcast Channel (PSBCH).

[0053] FIGs. 2A and 2B each illustrate a scenario, 200A and 200B, respectively, in which an AIoT reader communicates with an AIoT device, according to some implementations.

[0054] In scenario 200A of FIG. 2A, AIoT reader 201 communicates with AIoT device 202. To support the communication, AIoT device 202 harvests energy provided by energizer 203, which can be, e.g., an access node configured to broadcast carrier waves. In scenario 200A, AIoT reader 201 and energizer 203 are physically separated.

[0055] In scenario 200B of FIG. 2B, AIoT reader 211 communicates with AIoT device 212. AIoT reader 211 can function as or be physically integrated with an energizer, such as a base station, that broadcasts carrier waves. AIoT device 212 harvests energy from the carrier waves to support the communication with AIoT reader 211.

[0056] FIGs. 3 A and 3B each illustrate a plot, 300A and 300B, respectively, showing the power of an AIoT device as the AIoT device switches between charging and discharging, according to some implementations. The AIoT device in each of FIGs. 3 A and 3B can be similar to AIoT device 202 of FIG. 2A or AIoT device 212 of FIG. 2B. Each of plots 300A and 300B corresponds to a DCSM mode in which the AIoT device periodically switches between (i) a first time period during which the AIoT device harvests energy without monitoring for query commands and (ii) a second time period during which the AIoT device monitors for query commands. A DCSM mode differs from the “always-on” mode in that the AIoT device in DCSM can periodically turn off the receiver circuitry (e.g., receive circuitry 114 of UE 102 in FIG. 1) to not monitor for query commands.

[0057] As illustrated on plot 300A of FIG. 3 A, the power of the AIoT device increases from a first level pl to a second level p2 during a first time period tl, and decreases from the second level p2 to the first level pl during a second time period t2. First time period tl and the immediately following (or immediately preceding) second period t2 together form a cycle, which repeats as time goes on. First time period tl can be referred to as a charging period, and second time period t2 can be referred to as a discharging period.

[0058] In first time period tl of each cycle, the AIoT device switches off its receiver circuitry to stop monitoring for query commands. In second time period t2 of each cycle, the AIoT device switches on its receiver circuitry to monitor for query commands. Accordingly, second time period t2 in plot 300A can also be referred to as a monitoring period.

[0059] In some implementations, the AIoT device is fully discharged at first level pl and fully charged at second level p2. This mode of charging and discharging can be referred to as full- charge-full-discharge (FCFDC). Here, being fully discharged does not necessarily mean the AIoT device has no power at all. Rather, being fully discharged can mean the AIoT device has the same power as an initial state, e.g., reset state, or the power of the AIoT device is below a threshold, e.g., the minimum power required for certain operations. Likewise, being fully charged does not necessarily mean the AIoT device has reached maximum power storage capacity. Rather, being fully charged can mean the power of the AIoT device is above a threshold, e.g., enough to support certain operations.

[0060] Moving to FIG. 3B, as illustrated on plot 300B, the power of the AIoT device increases from a first level pl’ to a second level p2’ during charging period tl, and decreases from the second level p2’ to the first level pl’ during discharging period t2. Similar to scenario of FIG.

3 A, the AIoT device switches off its receiver circuitry during charging period tl and switches on its receiver circuitry during discharging period t2.

[0061] As illustrated on plot 300B, before the AIoT device switches between charging period tl and discharging period t2, the AIoT device is charged during a third time period tO from a third power level pO to the second level p2’. The charging during the third time period tO can be from a fully discharged level pO to a fully charged level p2’, which can happen when the AIoT device is initialized. After the initial charging, the AIoT device can switch between the fully charged power level p2’ and a partially discharged (or partially charged) power level pl’ . This mode of charging and discharging can be referred to as full-charge-partial-discharge (FCPDC).

[0062] Because it takes less time for the AIoT device to charge from power level pl’ to power level p2’ than from power level pO to power level p2’, the length of third time period tO is longer than the length of first time period tl . Accordingly, third time period tO can be referred to as a long charging period and first time period tl can be referred to as a short charging period.

[0063] For an AIoT device operating in a DCSM mode (e.g., FCFDC or FCPDC), because the AIoT device does not monitor for query commands during the charging period, the charging efficiency can be higher than the charging efficiency of an AIoT device operating in the “always-on” mode. The improved charging efficiency makes it is possible to increase the distance between the AIoT device and the energizer, which can advantageously save AIoT deployment cost and reduce unwanted radio emission near the AIoT device. Typically, the farther an AIoT device from the energizer, the lower the charging speed. As can be seen in FIGs. 3 A and 3B, the charging speed of the AIoT device is lower than the discharging speed in the illustrated example implementations. Other implementations can possibly have different charging speeds as compared to the discharging speeds.

[0064] Also, because the AIoT device monitors for query commands only during the monitoring period, the AIoT reader and the AIoT device can implement a mechanism for the AIoT reader to transmit query commands only when the AIoT device is monitoring for the query commands. This can be realized by making both the AIoT reader and the AIoT device aware of parameters of the lengths of charging and monitoring periods (e.g., tl and t2 for FCFDC, and tO, tl, and t2 for FCPDC).

[0065] In some implementations, the parameters are specified by industry standards, such as 3 GPP standards, and hardcoded in the memories of AIoT readers and devices that comply with the standards. This way, each of the AIoT reader and the AIoT device can access its own memory to determine the charging and monitoring periods and act accordingly. In some alternative implementations, the AIoT reader can send a configuration message, e.g., one dedicated to the AIoT device, to configure the AIoT device with the parameters so the reader and the device are in sync. Some implementations can be a hybrid of the above two: a subset of the parameters are hardcoded, whereas the rest of the parameters are configured via a configuration message.

[0066] With the AIoT reader and the AIoT device both having knowledge of the lengths of charging and monitoring periods of the AIoT device, the AIoT reader can send a query command to the AIoT device at a time when the AIoT device is actively monitoring for query commands and have sufficient power to respond to the query command (e.g., decode the query command and/or transmit query response messages). Likewise, when the AIoT device switches off the receiver circuitry to focus on energy harvesting during the charging period (including both long and short charging periods in case of FCPDC), the AIoT device does not expect the AIoT reader will send query commands.

[0067] FIG. 4 illustrates a table 400 showing example fields of a configuration message, according to some implementations. An AIoT reader can use the fields in table 400 to configure an AIoT device with the parameters of charging and/or monitoring periods. In implementations where the AIoT reader is in communication with a group of AIoT devices, the AIoT reader can broadcast the configuration message to some or all AIoT devices in the group.

[0068] As illustrated, the configuration message has a field of operation mode indicator, which can have a binary value indicating whether the AIoT device is configured to operate under the FCFDC or FCPDC mode. If the AIoT device is configured to operate under the FCFDC mode, the configuration message has a field for charging time and a field for signal monitoring time, which can respectively correspond to the lengths of periods tl and t2 of FIG. 3 A. If the AIoT device is configured to operate under the FCPDC mode, the configuration message has a field for long charging time, a field for signal monitoring time, and a field for short charging time, which can respectively correspond to the lengths of periods tO, tl, and t2 of FIG. 3B.

[0069] In some implementations, an AIoT reader can poll each AIoT device about whether the AIoT device has capability to support the FCFDC mode, the FCPDC mode, or both. The AIoT reader can configure the charging and monitoring parameters according to the report capability, as described below with reference to FIG. 5.

[0070] FIG. 5 illustrates an example procedure 500 in which AIoT reader 501 configures AIoT device 502 with a DCSM mode, according to some implementations. AIoT reader 501 and AIoT device 502 can be similar to those illustrated in FIGs. 2A and 2B. [0071] At 502, AIoT reader 501 polls AIoT device 502 about AIoT device 502’s DCSM mode capability. For example, AIoT reader 501 can send a query command to AIoT device 502. The query command can include a trigger (e.g., a message or a field of a message) for DCSM mode capability reporting.

[0072] At 504, in response to the trigger, AIoT device 502 transmits a DCSM mode capability report to AIoT reader 501. In the report, AIoT device 502 can indicate whether AIoT device 502 supports FCFDC, FCPDC, or both. Based on the report from AIoT device 502, AIoT reader 501 can determine whether to configure AIoT device 502 with FCFDC mode or the FCPDC mode. AIoT reader 501 can then determine the parameters, e.g., lengths of time periods, based on the determined mode.

[0073] At 506, AIoT reader 501 sends another query command including a configuration message to AIoT device 502. In the configuration message, AIoT reader 501 specifies which DCSM mode AIoT device 502 is expected to operate in. For the specified mode, AIoT reader 501 can also provide some or all of the parameters. AIoT reader 501 can use the fields illustrated in FIG. 4 to specify the DCSM mode and the parameters. It is noted that although the configuration message is shown to be included in a query command at 506, it is possible to provide the configuration message to AIoT device 502 in a message other than a query command in some implementations.

[0074] At 508, after configuring AIoT device 502 with the DCSM parameters, AIoT reader 501 can send further query commands when AIoT device 502 is expected to be in monitoring periods. These query commands can be part of, e.g., an inventory procedure, in which AIoT device 502 responds with data stored in or collected by AIoT device 502.

[0075] When an AIoT reader communicates with multiple AIoT devices, the AIoT reader can broadcast the messages/commands sent in the operations at 502, 506, and 508 to the multiple AIoT devices. Upon receiving the broadcast message/command, each AIoT device responds according to the operations at 504. In some implementations, the AIoT devices can be grouped into one or more groups based on, e.g., the type of devices, the location of devices, or the capability of the devices. Each group can be associated with a unique group identifier (ID). The AIoT reader can include the group ID when broadcasting the configuration messages and/or query commands.

[0076] In some implementations where an AIoT reader communicates with multiple groups of AIoT devices, AIoT devices within the same group can receive the same configuration messages and/or query commands, while AIoT devices belonging to different groups can receive different configuration messages and/or query commands. To communicate with the different groups, the AIoT reader can send/broadcast the configuration messages and query commands at different times, each time toward a particular group. To reduce latency when the AIoT reader communicates with multiple groups of AIoT devices, an offset parameter can be used in the configuration messages to enable parallel query command monitoring among the multiple groups. This is described below with reference to FIG. 6.

[0077] FIG. 6 illustrates an example procedure of an AIoT reader querying multiple groups of AIoT devices, illustrated as group #0 to group #3, according to some implementations. In the scenario of FIG. 6, all AIoT devices in the groups are configured with the FCPDC mode, although the procedure applies analogously to devices configured with the FCFDC mode.

[0078] The AIoT devices in each group are configured with a monitoring period (e.g., t2 of FIG. 3B) of 2 time units and a short charging period (e.g., tl of FIG. 3B) of 6 time units in a cycle with a period equal to 8 time units. When no offset value is provided, the start and ending times of a monitoring period within a cycle are the same for all four groups Group #0 to Group #3. This means AIoT devices in group #0 to group #3 all monitor for query commands by default at the same time in the same cycle. On the other hand, the AIoT reader can broadcast a query command to only one group at a time. This means the AIoT reader would need to broadcast query commands to all four groups in four different cycles, which causes latency.

[0079] To reduce the latency problem, the AIoT reader can include an offset value in the configuration message broadcast to each group. Each group calculates the start and ending times of the monitoring period within a cycle using the offset value. For example, group #0 is provided with an offset value of 0 (or provided with no offset value), so the AIoT devices in group #0 start monitoring for query commands according to a default setting, e.g., at the beginning of a cycle. Meanwhile, group #1 is provided with an offset value of 2, so the AIoT devices in group #1 start monitoring for query commands at a moment that is the default setting delayed by 2 time units, i.e., 2 time units after the beginning of a cycle. Likewise, group #2 and group #3 are provided with offset values of 4 and 6, respectively, so the AIoT devices in group #2 and group #3 start monitoring for query commands 4 time units after the beginning of a cycle and 6 time units after the beginning of a cycle, respectively.

[0080] As can be seen in FIG. 6, using the offset value, each group can be configured to monitor for query commands during a period different from other groups. This way, the AIoT reader can broadcast query commands to different groups at different times within the same cycle in a time division multiplexed (TDM) manner. This can reduce the latency in the query procedure.

[0081] An AIoT reader can query multiple AIoT devices (or AIoT device groups) in multiple query processes to conduct, e.g., inventory operations. For example, an AIoT reader can obtain a first item of information from a first AIoT device in a first query process and obtain a second item of information from a second AIoT device in a second query process. One way of performing the multiple query processes is for the AIoT reader to send the first query command, wait for the first query response (e.g., the message in response to the first query command), and then send the second query command after receiving the first query response. However, this approach is time-inefficient because the AIoT reader is idle during the time between the sending of the first query command and the receiving of the first query response. To improve efficiency and reduce latency, a mechanism of performing multiple query processes in parallel is provided and described with reference to FIG. 7.

[0082] FIG. 7 illustrates an example procedure of an AIoT reader querying multiple AIoT devices in parallel multiple querying processes, according to some implementations. The procedure includes operations 700A in which the AIoT reader sends two query commands corresponding to two query processes and operations 700B in which the AIoT reader sends two query repetition commands corresponding to the two query processes.

[0083] In operations 700A, the AIoT reader sends query command 0 to a first AIoT device to perform a first query process. After receiving and decoding query command 0, the first AIoT device sends query response 0 to the AIoT reader. In addition, the AIoT reader sends query command 1 to a second AIoT device to perform a second query process. After receiving and decoding query command 1, the second AIoT device sends query response 1 to the AIoT reader. The first and second query processes are identified by query process IDs 0 and 1, respectively.

[0084] To perform the first and second query processes in parallel, the AIoT reader can include a timing indicator (TI) field and a query process number (QPN) field in the query commands. The QPN field indicates the query process ID of the query process to be performed, whereas the TI field indicates how much time the AIoT device should wait before sending the query response. In general, the QPN field can have M= [log2P] bits, where P is the number of parallel query processes in total, “[ ]” is symbol of the ceiling function, and M is the number of bits of the QPN field. The TI field can be arranged, e.g., immediately preceding the QPN field in a message, but other arrangements are possible.

[0085] For example, in query command 0 to the first AIoT device, the AIoT reader can indicate that the first AIoT device is to perform the query process identified by QPN=0. Also in query command 0, the AIoT reader can indicate that the first AIoT device should wait TI=2 time units before transmitting query response 0. Similarly, in second query command 1 to the second AIoT device, the AIoT reader can indicate that the second AIoT device is to perform the query process identified by QPN=1 and that the second AIoT device should wait TI=2 time units before transmitting query response 1.

[0086] As illustrated, even though query command 0 and query command 1 are sent during the same monitoring window that the first and second AIoT devices have in common, the AIoT reader can schedule the receptions of query responses 0 and 1 such that the two query responses do not overlap in time. Accordingly, the AIoT reader can efficiently perform the first and second query processes with the first and second AIoT devices in parallel without the problem of receiving two query responses that conflict in time.

[0087] In operations 700B, the AIoT reader sends query repetition command (QueryRep) 0 to a first AIoT device to repeat the first query process, and sends QueryRep 1 to a second AIoT device to repeat the second query process. The first and second query processes are identified by query process IDs 0 and 1, respectively.

[0088] Similar to operations 700A, QueryRep 0 and QueryRep 1 each include a TI field and a QPN field. As illustrated, QueryRep 0 uses the TI field and the QPN field to indicate that the first AIoT device should wait TI=2 time units before transmitting query response 0 obtained from repeating query process #1. Similarly, QueryRep 0 uses the TI field and the QPN field to indicate that the second AIoT device should wait TI=2 time units before transmitting query response 1 obtained from repeating query process #1. This way, the AIoT reader can efficiently repeat the first and second query processes with the first and second AIoT devices in parallel without the problem of receiving two query responses that conflict in time.

[0089] FIGs. 8A and 8B each illustrate a flowchart of an example method, 800A and 800B, respectively, according to some implementations. For clarity of presentation, the description that follows generally describes methods 800A and 800B in the context of the other figures in this description. For example, method 800A can be performed by AIoT device 202 of FIG. 2A or AIoT device 212 of FIG. 2B, and method 800B can be performed by AIoT reader 201 of FIG. 2A or AIoT reader 211 of FIG. 2B. It will be understood that each of methods 800A and 800B can be performed, for example, by any suitable system, environment, software, hardware, or a combination of systems, environments, software, and hardware, as appropriate. In some implementations, various steps of each of methods 800A and 800B can be run in parallel, in combination, in loops, or in any order.

[0090] In the example method 800A of FIG. 8 A, at 802, method 800A involves determining a first time period for a device to charge from a first energy level to a second energy level. The first energy level is lower than the second energy level. The first energy level can be a fully discharged level in the FCFDC mode or a partially discharged level in the FCPDC mode. The second energy level can be a fully charged level.

[0091] At 804, method 800A involves determining a second time period for the device to discharge from the second energy level to the first energy level.

[0092] At 806, method 800A involves charging the device during the first time period.

[0093] At 808, method 800A involves monitoring for a query command from a reader during the second time period.

[0094] In some implementations, the method further includes switching off a receiver circuit of the device during the first time period.

[0095] In some implementations, the device is fully charged at the second energy level, and the device is fully discharged at the first energy level.

[0096] In some implementations, the method further includes receiving a configuration message from the reader. The configuration message indicates at least one of: a value of the first time period, or a value of the second time period.

[0097] In some implementations, the configuration message further indicates a discharge mode of the device, and wherein the discharge mode is one of a full discharge mode or a partial charge mode.

[0098] In some implementations, the method further includes determining a third time period for the device to charge from a third energy level to the second energy level, wherein the third energy level is lower than the first energy level, and wherein the third time period precedes the first time period and the second time period; and charging the device during the third time period. [0099] In some implementations, the device is (i) partially discharged at the first energy level, (ii) fully charged at the second energy level, and (iii) fully discharged at the third energy level.

[0100] In some implementations, the method further includes receiving a configuration message from the reader. The configuration message indicates at least one of a value of the first time period, a value of the second time period, or a value of the third time period.

[0101] In some implementations, the configuration message further includes an offset value, and wherein the first time period is determined based on the offset value.

[0102] In some implementations, the device belongs to a group of devices that receives the configuration message in a broadcast. The configuration message further includes an index of the group.

[0103] In some implementations, at least one of the first time period or the second time period is determined based on a configuration parameter value stored in a memory of the device.

[0104] In some implementations, the method further includes: receiving the query command from the reader, wherein the query command includes a trigger for capability reporting; and in response to the trigger, transmitting a capability report message from the device to the reader, wherein the capability report message includes information about a discharge mode supported by the device.

[0105] In some implementations, the method further includes receiving the query command from the reader, wherein the query command includes a timing indicator field and a query process number field; generating a query response based on a value of query process number field; and transmitting the query response to the reader at a time specified by the timing indicator field.

[0106] In some implementations, the query command further includes a query repetition command.

[0107] In the example method 800B of FIG. 8B, at 852, method 800B involves determining a first time period for a device to charge from a first energy level to a second energy level. The first energy level is lower than the second energy level. The first energy level can be a fully discharged level in the FCFDC mode or a partially discharged level in the FCPDC mode. The second energy level can be a fully charged level. [0108] At 854, method 800B involves determining a second time period for the device to discharge from the second energy level to the first energy level.

[0109] At 856, method 800B involves transmitting a query command to the device during the second time period.

[0110] In some implementations, the method further includes transmitting a configuration message to the device. The configuration message indicates at least one of: a value of the first time period, or a value of the second time period.

[OHl] In some implementations, the configuration message further indicates a discharge mode of the device. The discharge mode is one of a full discharge mode or a partial charge mode.

[0112] In some implementations, the method further includes determining a third time period for the device to charge from a third energy level to the second energy level. The third energy level is lower than the first energy level. The third time period precedes the first time period and the second time period.

[0113] In some implementations, the method further includes transmitting a configuration message to the device. The configuration message indicates at least one of: a value of the first time period, a value of the second time period, or a value of the third time period.

[0114] In some implementations, the method further includes broadcasting the configuration message to a plurality of devices.

[0115] In some implementations, the query command includes a trigger for capability reporting. The method further includes receiving a capability report message by the reader from the device. The capability report message includes information of a discharge mode supported by the device.

[0116] In some implementations, the method further includes: transmitting a plurality of configuration messages to a plurality of device groups, wherein each configuration message includes an offset value that is unique to that device group; and transmitting a plurality of query commands respectively to the plurality of device groups. Each query command is transmitted at a time based on the offset value unique to that device group.

[0117] In some implementations, the method further includes transmitting the query command to the device, wherein the query command includes a timing indicator field and a query process number field; and receiving, from the device and at a time indicated by the timing indicator field, a query response associated with a query process number. The query process number is indicated by the query process number field.

[0118] FIG. 9 illustrates an example UE 900, according to some implementations. The UE 900 may be similar to and substantially interchangeable with UE 102 of FIG. 1.

[0119] The UE 900 may be any mobile or non-mobile computing device, such as, for example, mobile phones, computers, tablets, industrial wireless sensors (for example, microphones, pressure sensors, thermometers, motion sensors, accelerometers, inventory sensors, electric voltage/current meters, etc.), video devices (for example, cameras, video cameras, etc.), wearable devices (for example, a smart watch), relaxed-IoT devices.

[0120] The UE 900 may include processors 902, RF interface circuitry 904, memory/storage 906, user interface 908, sensors 910, driver circuitry 912, power management integrated circuit (PMIC) 914, one or more antenna(s) 916, and battery 918. The components of the UE 900 may be implemented as integrated circuits (ICs), portions thereof, discrete electronic devices, or other modules, logic, hardware, software, firmware, or a combination thereof. The block diagram of FIG. 9 is intended to show a high-level view of some of the components of the UE 900. However, some of the components shown may be omitted, additional components may be present, some components may physically be combined or further separated unto multiple components, and different arrangement of the components shown may occur in other implementations.

[0121] The components of the UE 900 may be coupled with various other components over one or more interconnects 920, which may represent any type of interface, input/output, bus (local, system, or expansion), transmission line, trace, optical connection, etc. that allows various circuit components (on common or different chips or chipsets) to interact with one another.

[0122] The processors 902 may include processor circuitry such as, for example, baseband processor circuitry (BB) 922A, central processor unit circuitry (CPU) 922B, and graphics processor unit circuitry (GPU) 922C. The processors 902 may include any type of circuitry or processor circuitry that executes or otherwise operates computer-executable instructions, such as program code, software modules, or functional processes from memory/storage 906 to cause the UE 900 to perform operations as described herein. [0123] In some implementations, the baseband processor circuitry 922A may access a communication protocol stack 924 in the memory/storage 906 to communicate over a 3 GPP compatible network. In general, the baseband processor circuitry 922A may access the communication protocol stack to: perform user plane functions at a physical (PHY) layer, medium access control (MAC) layer, radio link control (RLC) layer, packet data convergence protocol (PDCP) layer, service data adaptation protocol (SDAP) layer, and PDU layer; and perform control plane functions at a PHY layer, MAC layer, RLC layer, PDCP layer, RRC layer, and a non-access stratum layer. In some implementations, the PHY layer operations may additionally/altematively be performed by the components of the RF interface circuitry 904. The baseband processor circuitry 922A may generate or process baseband signals or waveforms that carry information in 3 GPP-compatible networks. In some implementations, the waveforms for NR may be based cyclic prefix orthogonal frequency division multiplexing (OFDM) “CP-OFDM” in the uplink or downlink, and discrete Fourier transform spread OFDM “DFT-S-OFDM” in the uplink.

[0124] The memory/storage 906 may include one or more non -transitory, computer-readable media that includes instructions (for example, communication protocol stack 924) that may be executed by one or more of the processors 902 to cause the UE 900 to perform various operations described herein. The memory/storage 906 include any type of volatile or nonvolatile memory that may be distributed throughout the UE 900. In some implementations, some of the memory/storage 906 may be located on the processors 902 themselves (for example, LI and L2 cache), while other memory/storage 906 is external to the processors 902 but accessible thereto via a memory interface. The memory/storage 906 may include any suitable volatile or non-volatile memory such as, but not limited to, dynamic random access memory (DRAM), static random access memory (SRAM), erasable programmable read only memory (EPROM), electrically erasable programmable read only memory (EEPROM), Flash memory, solid-state memory, or any other type of memory device technology.

[0125] The RF interface circuitry 904 may include transceiver circuitry and radio frequency front module (RFEM) that allows the UE 900 to communicate with other devices over a radio access network. The RF interface circuitry 904 may include various elements arranged in transmit or receive paths. These elements may include, for example, switches, mixers, amplifiers, filters, synthesizer circuitry, control circuitry, etc. [0126] In the receive path, the RFEM may receive a radiated signal from an air interface via antenna(s) 916 and proceed to filter and amplify (with a low-noise amplifier) the signal. The signal may be provided to a receiver of the transceiver that downconverts the RF signal into a baseband signal that is provided to the baseband processor of the processors 902.

[0127] In the transmit path, the transmitter of the transceiver up-converts the baseband signal received from the baseband processor and provides the RF signal to the RFEM. The RFEM may amplify the RF signal through a power amplifier prior to the signal being radiated across the air interface via the antenna(s) 916. In various implementations, the RF interface circuitry 904 may be configured to transmit/receive signals in a manner compatible with NR access technologies.

[0128] The antenna(s) 916 may include one or more antenna elements to convert electrical signals into radio waves to travel through the air and to convert received radio waves into electrical signals. The antenna elements may be arranged into one or more antenna panels. The antenna(s) 916 may have antenna panels that are omnidirectional, directional, or a combination thereof to enable beamforming and multiple input, multiple output communications. The antenna(s) 916 may include microstrip antennas, printed antennas fabricated on the surface of one or more printed circuit boards, patch antennas, phased array antennas, etc. The antenna(s) 916 may have one or more panels designed for specific frequency bands including bands in FR1 or FR2.

[0129] The user interface 908 includes various input/output (VO) devices designed to enable user interaction with the UE 900. The user interface 908 includes input device circuitry and output device circuitry. Input device circuitry includes any physical or virtual means for accepting an input including, inter alia, one or more physical or virtual buttons (for example, a reset button), a physical keyboard, keypad, mouse, touchpad, touchscreen, microphones, scanner, headset, or the like. The output device circuitry includes any physical or virtual means for showing information or otherwise conveying information, such as sensor readings, actuator position(s), or other like information. Output device circuitry may include any number or combinations of audio or visual display, including, inter alia, one or more simple visual outputs/indicators (for example, binary status indicators such as light emitting diodes “LEDs” and multi -character visual outputs), or more complex outputs such as display devices or touchscreens (for example, liquid crystal displays “LCDs,” LED displays, quantum dot displays, projectors, etc.), with the output of characters, graphics, multimedia objects, and the like being generated or produced from the operation of the UE 900.

[0130] The sensors 910 may include devices, modules, or subsystems whose purpose is to detect events or changes in its environment and send the information (sensor data) about the detected events to some other device, module, subsystem, etc. Examples of such sensors include, inter alia, inertia measurement units including accelerometers, gyroscopes, or magnetometers; microelectromechanical systems or nanoelectromechanical systems including 3-axis accelerometers, 3-axis gyroscopes, or magnetometers; level sensors; temperature sensors (for example, thermistors); pressure sensors; image capture devices (for example, cameras or lensless apertures); light detection and ranging sensors; proximity sensors (for example, infrared radiation detector and the like); depth sensors; ambient light sensors; ultrasonic transceivers; microphones or other like audio capture devices; etc.

[0131] The driver circuitry 912 may include software and hardware elements that operate to control particular devices that are embedded in the UE 900, attached to the UE 900, or otherwise communicatively coupled with the UE 900. The driver circuitry 912 may include individual drivers allowing other components to interact with or control various input/output (EO) devices that may be present within, or connected to, the UE 900. For example, driver circuitry 912 may include a display driver to control and allow access to a display device, a touchscreen driver to control and allow access to a touchscreen interface, sensor drivers to obtain sensor readings of sensors 910 and control and allow access to sensors 910, drivers to obtain actuator positions of electro-mechanic components or control and allow access to the electro-mechanic components, a camera driver to control and allow access to an embedded image capture device, audio drivers to control and allow access to one or more audio devices.

[0132] The PMIC 914 may manage power provided to various components of the UE 900. In particular, with respect to the processors 902, the PMIC 914 may control power-source selection, voltage scaling, battery charging, or DC-to-DC conversion.

[0133] In some implementations, the PMIC 914 may control, or otherwise be part of, various power saving mechanisms of the UE 900. A battery 918 may power the UE 900, although in some examples the UE 900 may be mounted deployed in a fixed location, and may have a power supply coupled to an electrical grid. The battery 918 may be a lithium ion battery, a metal-air battery, such as a zinc-air battery, an aluminum-air battery, a lithium-air battery, and the like. In some implementations, such as in vehicle-based applications, the battery 918 may be a typical lead-acid automotive battery.

[0134] FIG. 10 illustrates an example access node 1000 (e.g., abase station or gNB), according to some implementations. The access node 1000 may be similar to and substantially interchangeable with base station 104. The access node 1000 may include processors 1002, RF interface circuitry 1004, core network (CN) interface circuitry 1006, memory/storage circuitry 1008, and one or more antenna(s) 1010.

[0135] The components of the access node 1000 may be coupled with various other components over one or more interconnects 1012. The processors 1002, RF interface circuitry 1004, memory/storage circuitry 1008 (including communication protocol stack 1014), antenna(s) 1010, and interconnects 1012 may be similar to like-named elements shown and described with respect to FIG. 9. For example, the processors 1002 may include processor circuitry such as, for example, baseband processor circuitry (BB) 1016A, central processor unit circuitry (CPU) 1016B, and graphics processor unit circuitry (GPU) 1016C.

[0136] The CN interface circuitry 1006 may provide connectivity to a core network, for example, a 5th Generation Core network (5GC) using a 5GC -compatible network interface protocol such as carrier Ethernet protocols, or some other suitable protocol. Network connectivity may be provided to/from the access node 1000 via a fiber optic or wireless backhaul. The CN interface circuitry 1006 may include one or more dedicated processors or FPGAs to communicate using one or more of the aforementioned protocols. In some implementations, the CN interface circuitry 1006 may include multiple controllers to provide connectivity to other networks using the same or different protocols.

[0137] As used herein, the terms “access node,” “access point,” or the like may describe equipment that provides the radio baseband functions for data and/or voice connectivity between a network and one or more users. These access nodes can be referred to as BS, gNBs, RAN nodes, eNBs, NodeBs, RSUs, TRxPs or TRPs, and so forth, and can include ground stations (e.g., terrestrial access points) or satellite stations providing coverage within a geographic area (e.g., a cell). As used herein, the term “NG RAN node” or the like may refer to an access node 1000 that operates in an NR or 5G system (for example, a gNB), and the term “E-UTRAN node” or the like may refer to an access node 1000 that operates in an LTE or 4G system (e.g., an eNB). According to various implementations, the access node 1000 may be implemented as one or more of a dedicated physical device such as a macrocell base station, and/or a low power (LP) base station for providing femtocells, picocells or other like cells having smaller coverage areas, smaller user capacity, or higher bandwidth compared to macrocells.

[0138] In some implementations, all or parts of the access node 1000 may be implemented as one or more software entities running on server computers as part of a virtual network, which may be referred to as a CRAN and/or a virtual baseband unit pool (vBBUP). In V2X scenarios, the access node 1000 may be or act as a “Road Side Unit.” The term “Road Side Unit” or “RSU” may refer to any transportation infrastructure entity used for V2X communications. An RSU may be implemented in or by a suitable RAN node or a stationary (or relatively stationary) UE, where an RSU implemented in or by a UE may be referred to as a “UE-type RSU,” an RSU implemented in or by an eNB may be referred to as an “eNB-type RSU,” an RSU implemented in or by a gNB may be referred to as a “gNB-type RSU,” and the like.

[0139] Various components may be described as performing a task or tasks, for convenience in the description. Such descriptions should be interpreted as including the phrase “configured to.” Reciting a component that is configured to perform one or more tasks is expressly intended not to invoke 35 U.S.C. § 112(f) interpretation for that component.

[0140] Although the embodiments above have been described in considerable detail, numerous variations and modifications will become apparent to those skilled in the art once the above disclosure is fully appreciated. It is intended that the following claims be interpreted to embrace all such variations and modifications.

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

Claims

CLAIMS We Claim:

1. A method comprising: determining a first time period for a device to charge from a first energy level to a second energy level, wherein the first energy level is lower than the second energy level; determining a second time period for the device to discharge from the second energy level to the first energy level; charging the device during the first time period; and monitoring for a query command from a reader during the second time period.

2. The method of claim 1, further comprising switching off a receiver circuit of the device during the first time period.

3. The method of claim 1, wherein the device is fully charged at the second energy level, and the device is fully discharged at the first energy level.

4. The method of claim 1, further comprising receiving a configuration message from the reader, wherein the configuration message indicates at least one of: a value of the first time period, or a value of the second time period.

5. The method of claim 4, wherein the configuration message further indicates a discharge mode of the device, and wherein the discharge mode is one of a full discharge mode or a partial charge mode.

6. The method of claim 1, further comprising: determining a third time period for the device to charge from a third energy level to the second energy level, wherein the third energy level is lower than the first energy level, and wherein the third time period precedes the first time period and the second time period; and charging the device during the third time period.

7. The method of claim 6, wherein the device is (i) partially discharged at the first energy level, (ii) fully charged at the second energy level, and (iii) fully discharged at the third energy level.

8. The method of claim 6, further comprising receiving a configuration message from the reader, wherein the configuration message indicates at least one of: a value of the first time period, a value of the second time period, or a value of the third time period.

9. The method of claim 8, wherein the configuration message further comprises an offset value, and wherein the first time period is determined based on the offset value.

10. The method of claim 8, wherein the device belongs to a group of devices that receives the configuration message in a broadcast, and wherein the configuration message further comprises an index of the group.

11. The method of claim 1, further comprising: receiving the query command from the reader, wherein the query command comprises a trigger for capability reporting; and in response to the trigger, transmitting a capability report message from the device to the reader, wherein the capability report message comprises information about a discharge mode supported by the device.

12. The method of claim 1, further comprising: receiving the query command from the reader, wherein the query command comprises a timing indicator field and a query process number field; generating a query response based on a value of query process number field; and transmitting the query response to the reader at a time specified by the timing indicator field.

13. A method comprising: determining a first time period for a device to charge from a first energy level to a second energy level, wherein the first energy level is lower than the second energy level; determining a second time period for the device to discharge from the second energy level to the first energy level; and transmitting a query command to the device during the second time period.

14. The method of claim 13, further comprising transmitting a configuration message to the device, wherein the configuration message indicates at least one of: a value of the first time period, or a value of the second time period.

15. The method of claim 14, wherein the configuration message further indicates a discharge mode of the device, and wherein the discharge mode is one of a full discharge mode or a partial charge mode.

16. The method of claim 13 further comprising: determining a third time period for the device to charge from a third energy level to the second energy level, wherein the third energy level is lower than the first energy level, and wherein the third time period precedes the first time period and the second time period.

17. The method of claim 16, further comprising transmitting a configuration message to the device, wherein the configuration message indicates at least one of: a value of the first time period, a value of the second time period, or a value of the third time period.

18. The method of claim 13, further comprising broadcasting the configuration message to a plurality of devices.

19. The method of claim 13, wherein the query command comprises a trigger for capability reporting, and wherein the method further comprises: receiving a capability report message by the reader from the device, wherein the capability report message comprises information of a discharge mode supported by the device.

20. The method of claim 13, further comprising: transmitting a plurality of configuration messages to a plurality of device groups, wherein each configuration message comprises an offset value that is unique to that device group; and transmitting a plurality of query commands respectively to the plurality of device groups, wherein each query command is transmitted at a time based on the offset value unique to that device group.

21. A user equipment (UE) comprising: memory; a transceiver; and a processor coupled to the memory and configured to, when executing instructions stored in the memory, cause the UE to to perform the method of any of claims 1-20.

22. One or more processors configured to execute instructions that cause an apparatus to perform the method of any of claims 1-20.