Method and apparatus for wireless communication

Abstract

Methods and apparatus for wireless communication are provided. In one aspect, a method for wireless communication performed by a reader device, the method comprising: transmitting a communication initiation signal to an environmental Internet of Things device; receiving charging state information from the environmental Internet of Things device; and adjusting the behavior according to the charging state information. According to the invention, wireless communication can be better carried out.

Description

Technical Field

[0001] The present invention relates to mobile communications, and more particularly to a method and system for improving the communication range, power consumption and charging time of ambient Internet of Things (A-IoT) devices associated with user equipment (UE) and network devices in mobile communications. Background Art

[0002] The statements in this section merely provide background information related to the present invention and do not constitute prior art.

[0003] Wireless communication systems are widely deployed to provide a variety of telecommunication services, such as telephony, video, data, messaging, and broadcasting. Typical wireless communication systems may employ multiple-access technologies that are capable of supporting communications with multiple users by sharing available system resources. Examples of multiple-access technologies include Code Division Multiple Access (CDMA) systems, Time Division Multiple Access (TDMA) systems, Frequency Division Multiple Access (FDMA) systems, Orthogonal Frequency Division Multiple Access (OFDMA) systems, Single-Carrier Frequency Division Multiple Access (SC-FDMA) systems, and Time Division Synchronous Code Division Multiple Access (TD-SCDMA) systems.

[0004] The above-mentioned multiple access technologies have been adopted in various telecommunication standards to provide a common protocol that enables different wireless devices to communicate at a municipal, national, regional, and even global level. An example of a telecommunication standard is the fifth generation (5G) New Radio (NR). 5G NR is part of the continuous mobile broadband evolution released by the Third Generation Partnership Project (3GPP) to meet new requirements associated with latency, reliability, security, scalability (such as with the Internet of Things (IoT)) and other requirements. Some aspects of 5G NR may be based on the fourth generation (4G) Long Term Evolution (LTE) standard. 5G NR technology requires further improvements, which may also be applicable to other multiple access technologies and telecommunication standards that adopt these technologies. Summary of the invention

[0005] The following content presents a brief summary of one or more aspects, with the purpose of providing a basic understanding of these aspects. The present invention summary is not an extensive overview of all considered aspects, and is neither intended to identify the key or important elements of all aspects, nor to outline the scope of any or all aspects. The purpose of the present invention summary is only to present some concepts of one or more aspects in a simplified form, as a preface to the more detailed description that will be presented below.

[0006] The present invention provides a method and device for wireless communication. On the one hand, a method for wireless communication is performed by a reader device. The reader device sends a communication initiation signal to an A-IoT device. The reader device receives charging status information from the A-IoT device. The reader device adjusts behavior according to the charging status information.

[0007] On the other hand, a method for wireless communication is performed by an ambient Internet of Things device, the method comprising: receiving a communication initiation signal from a reader device; determining a charging status of the ambient Internet of Things device; and sending charging status information to the reader device.

[0008] By utilizing the present invention, wireless communication can be better performed.

[0009] To accomplish the foregoing and related purposes, one or more aspects include the features fully described below and particularly pointed out in the claims. The following detailed description and accompanying drawings set forth in detail certain illustrative features of one or more aspects. However, these features are only indicative of some of the various ways in which the principles of the various aspects can be employed, and the present invention is intended to include all such aspects and their equivalents. BRIEF DESCRIPTION OF THE DRAWINGS

[0010] Figure 1 is a schematic diagram illustrating an exemplary wireless communication system and access network.

[0011] Figure 2 is a schematic diagram illustrating communication between a BS and a UE in an access network.

[0012] Figure 3 An exemplary logical architecture of a distributed access network is illustrated.

[0013] Figure 4 An exemplary physical architecture of a distributed access network is illustrated.

[0014] Figure 5 is a schematic diagram showing exemplary time slots centered on DL.

[0015] Figure 6 is a schematic diagram showing exemplary time slots centered around the UL.

[0016] FIG. 7(A) is a schematic diagram showing an example of a wireless communication system including a base station and a UE.

[0017] FIG7(B) is a schematic diagram showing an example of a communication link between a gNB and an A-IoT device connected to a UE via a wired cable.

[0018] FIG7(C) is a schematic diagram showing an example of a communication link between a gNB and an A-IoT device connected to a UE via a wireless air interface.

[0019] FIG7(D) is a schematic diagram showing the first type of A-IoT device.

[0020] FIG7(E) is a schematic diagram showing the second type of A-IoT device.

[0021] FIG7(F) is a schematic diagram showing the third type of A-IoT device.

[0022] FIG7(G) is a schematic diagram showing an example of a communication link between a UE and an A-IoT device via an air interface.

[0023] FIG7(H) is a schematic diagram illustrating an example of a communication process between a UE reader / gNB and an A-IoT device based on a selected duration.

[0024] FIG7(I) is a timing diagram illustrating a modified 4-step RACH procedure.

[0025] FIG7(J) is a timing diagram illustrating a modified 2-step RACH procedure.

[0026] FIG7(K) is a timing diagram illustrating a modified RACH procedure when the UE acts as a tag reader.

[0027] FIG7(L) is a timing diagram describing a modified sidelink process.

[0028] FIG8(A) is a schematic diagram illustrating the problem of charging time.

[0029] FIG8(B) is a schematic diagram illustrating the use of a shortened feedback signal to manage charging time.

[0030] FIG. 9(A) is a timing diagram illustrating a modified 4-step RACH procedure with a shortened feedback signal.

[0031] FIG9(B) is a timing diagram illustrating a modified 2-step RACH procedure with a shortened feedback signal.

[0032] FIG. 9(C) is a timing diagram illustrating a modified RACH procedure when the UE acts as a tag reader with respect to a shortened feedback signal.

[0033] FIG. 9(D) is a timing diagram illustrating a modified side chain process with respect to a shortened feedback signal.

[0034] FIG. 10(A) is a timing diagram describing a modified 4-step RACH procedure regarding the charging state in RN 16.

[0035] FIG10(B) is a timing diagram describing a modified 2-step RACH procedure regarding the charging state in RN16.

[0036] FIG10(C) is a timing diagram describing the modified RACH procedure when a UE in a charging state in RN16 acts as a tag reader.

[0037] FIG10(D) is a timing diagram describing a modified side chain process regarding the charging state in RN16.

[0038] FIG. 11(A) is a timing diagram illustrating a modified 4-step RACH procedure for a scheduled query command.

[0039] FIG11(B) is a timing diagram illustrating a modified 2-step RACH procedure for a scheduled query command.

[0040] FIG. 11(C) is a timing diagram illustrating a modified RACH procedure when the UE acts as a tag reader with respect to a scheduled query command.

[0041] FIG11(D) is a timing diagram describing a modified side chain process regarding a scheduled query command.

[0042] FIG. 12(A) is a timing diagram illustrating a modified 4-step RACH procedure with adaptive ACK timing.

[0043] FIG. 12(B) is a timing diagram illustrating a modified 2-step RACH procedure with respect to adaptive ACK timing.

[0044] FIG. 12(C) is a timing diagram illustrating a modified RACH procedure when the UE acts as a tag reader with respect to adaptive ACK timing.

[0045] FIG. 12(D) is a timing diagram illustrating a modified side chain process with respect to adaptive ACK timing.

[0046] FIG. 13(A) is a timing diagram illustrating a modified 4-step RACH procedure with respect to the charging state in the EPC.

[0047] FIG. 13(B) is a timing diagram illustrating a modified 2-step RACH procedure with respect to the charging state in the EPC.

[0048] FIG. 13(C) is a timing diagram describing a modified RACH procedure when a UE in a charged state in the EPC acts as a tag reader.

[0049] FIG. 13(D) is a timing diagram illustrating a modified side chain process with respect to the charging state in the EPC.

[0050] FIG. 14(A) is a timing diagram illustrating a modified 4-step RACH procedure for multiple RN16 signals.

[0051] FIG. 14(B) is a timing diagram illustrating a modified 2-step RACH procedure for multiple RN16 signals.

[0052] FIG. 14(C) is a timing diagram describing the modified RACH procedure when the UE acts as a tag reader with respect to multiple RN16 signals.

[0053] FIG14(D) is a timing diagram describing a modified sidechain process for multiple RN16 signals.

[0054] FIG15(A) is a timing diagram illustrating a modified 4-step RACH procedure for delayed data transmission.

[0055] FIG15(B) is a timing diagram illustrating a modified 2-step RACH procedure for delayed data transmission.

[0056] FIG. 15(C) is a timing diagram illustrating a modified RACH procedure when the UE acts as a tag reader with respect to delayed data transmission.

[0057] FIG15(D) is a timing diagram illustrating a modified side chain process with respect to delayed data transmission.

[0058] FIG. 16(A) is a timing diagram illustrating a modified 4-step RACH procedure for the power saving protocol.

[0059] FIG16(B) is a timing diagram illustrating a modified 2-step RACH procedure for the power saving protocol.

[0060] FIG. 16(C) is a timing diagram illustrating a modified RACH procedure when a UE acts as a tag reader in relation to the energy saving protocol.

[0061] FIG16(D) is a timing diagram describing a modified side chain process regarding the energy-saving protocol.

[0062] Fig.17 An example communication system including an example communication device and an example network device is shown.

[0063] FIG. 18(A) is a flow chart describing a process for handling charging time by a reader device and an A-IoT device.

[0064] FIG. 18(B) is a flow chart describing another process regarding the reader device and the A-IoT device handling charging time. DETAILED DESCRIPTION

[0065] The specific embodiments described below in conjunction with the accompanying drawings are intended to be descriptions of various configurations, and are not intended to represent the only configurations that can practice the concepts described in the present invention. This specific embodiment part includes specific details, and the purpose is to provide a thorough understanding of various concepts. However, for those skilled in the art, these concepts can also be practiced without these specific details. In some cases, in order to avoid blurring these concepts, known structures and components are shown in block diagram form.

[0066] Several aspects of telecommunication systems will now be presented with reference to various apparatus and methods. The apparatus and methods will be described in the detailed description and illustrated in the accompanying drawings by various blocks, components, circuits, processes, algorithms, etc. (collectively referred to as "elements"). The elements may be implemented using electronic hardware, computer software, or any combination thereof. Whether these elements are implemented in hardware or software depends on the specific application and design constraints imposed on the overall system.

[0067] For example, an element, any part of an element, or any combination of elements may be implemented as a "processing system", where the processing system may include one or more processors. Examples of processors include microprocessors, microcontrollers, graphics processing units (GPUs), central processing units (CPUs), application processors, digital signal processors (DSPs), reduced instruction set computing (RISC) processors, systems on a chip (SoCs), baseband processors, field programmable gate arrays (FPGAs), programmable logic devices (PLDs), state machines, gated logic, discrete hardware circuits, and other suitable hardware configured to perform the various functions described in the present invention. One or more processors in a processing system may execute software. Software shall be construed broadly to mean instructions, instruction sets, codes, code segments, program code, programs, subroutines, software components, applications, software applications, software packages, routines, subroutines, objects, executables, threads of execution, processes, and functions, etc., whether referred to as software, firmware, middleware, microcode, hardware description language, or otherwise.

[0068] Therefore, in one or more exemplary aspects, the above functions can be implemented in hardware, software or any combination thereof. If implemented in software, the functions can be stored on a computer-readable medium, or encoded as one or more instructions or codes on a computer-readable medium. Computer-readable media include computer storage media. The storage medium can be any available medium that can be accessed by a computer. The above-mentioned computer-readable medium may include a random access memory (Random-Access Memory, RAM), a read-only memory (Read-Only Memory, ROM), an electrically erasable programmable read-only memory (Electrically Erasable Programmable ROM, EEPROM), an optical disk storage, a magnetic disk storage, other magnetic storage devices, a combination of computer-readable media of the above types, or any other medium that can be used to store computer executable code in the form of instructions or data structures that can be accessed by a computer, which is used only as an example and is not intended to limit the present invention.

[0069] Figure 1 1 is a schematic diagram illustrating an exemplary wireless communication system and access network 100. The wireless communication system (also referred to as a Wireless Wide Area Network (WWAN)) includes a base station (BS) 102, a user equipment (UE) 104, an evolved packet core (EPC) 160, and another core network 190 (such as a 5G core network (5G Core, 5GC)). BS 102 may include a macro cell (a high-power cellular base station) and / or a small cell (a low-power cellular base station). A macro cell includes a BS, and a small cell includes a femtocell, a picocell, and a microcell.

[0070] BS 102 configured for 4G LTE (collectively referred to as Evolved Universal Mobile Telecommunications System Terrestrial Radio Access Network (E-UTRAN)) can be connected to the EPC 160 interface via a backhaul link 132 (such as an SI interface). BS 102 configured for 5G NR (collectively referred to as Next Generation RAN (NG-RAN)) can be connected to the core network 190 interface via a backhaul link 184. Among other functions, BS 102 may perform one or more of the following functions: transfer of user data, radio channel cipher and decryption, integrity protection, header compression, mobility control functions (e.g., handover, dual connectivity), inter-cell interference coordination, connection setup and release, load balancing, distribution of non-access stratum (NAS) messages, NAS node selection, synchronization, Radio Access Network (RAN) sharing, Multimedia Broadcast Multicast Service (MBMS), subscriber and equipment tracking, RAN Information Management (RIM), paging, positioning, and delivery of warning messages. BS 102 may communicate with each other directly or indirectly (e.g., via EPC 160 or core network 190) via a backhaul link 134 (e.g., an X2 interface). The backhaul link 134 may be wired or wireless.

[0071] BS 102 can communicate wirelessly with UE 104. Each BS 102 can provide communication coverage for a respective geographic coverage area 110. There may be overlapping geographic coverage areas 110, for example, a small cell 102' can have a coverage area 110' that overlaps with the coverage area 110 of one or more macro base stations 102. A network that includes both small cells and macro cells can be called a heterogeneous network. A heterogeneous network can also include a home evolved Node B (eNB) (Home eNB, HeNB), where the HeNB can provide services to a restricted group called a closed subscriber group (CSG). The communication link 120 between BS 102 and UE 104 can include an uplink (UL) (also called a reverse link) transmission from UE 104 to BS 102 and / or a downlink (DL) (also called a forward link) transmission from BS 102 to UE 104. The communication link 120 may use MIMO antenna technology, including spatial multiplexing, beamforming and / or transmit diversity. The communication link may pass through one or more carriers. BS102 / UE 104 may use a spectrum with a bandwidth of up to 7 MHz (e.g., 5, 10, 15, 20, 100, 400 MHz, etc.) per carrier, where the carriers are allocated in carrier aggregation (CA) for transmission in each direction, where the carrier aggregation is up to Yx MHz (x component carriers) in total. The above carriers may be adjacent to each other or may not be adjacent to each other. The allocation of carriers may be asymmetric with respect to DL and UL (e.g., more or fewer carriers may be allocated to DL than to UL). A component carrier may include a primary component carrier and one or more secondary component carriers. The primary component carrier may be referred to as a primary cell (PCell) and the secondary component carrier may be referred to as a secondary cell (SCell).

[0072] Some UEs 104 may communicate with each other using a device-to-device (D2D) communication link 158. The D2D communication link 158 may use DL / UL WWAN spectrum. The D2D communication link 158 may use one or more sidelink channels, such as a physical sidelink broadcast channel (PSBCH), a physical sidelink discovery channel (PSDCH), a physical sidelink shared channel (PSSCH), and a physical sidelink control channel (PSCCH). D2D communication may be through various wireless D2D communication systems, such as FlashLinQ, WiMedia, Bluetooth, ZigBee, Wi-Fi based on IEEE 802.11 standards, LTE, or NR.

[0073] The wireless communication system may also include a Wi-Fi access point (AP) 150, wherein the Wi-Fi AP 150 communicates with a Wi-Fi station (STA) 152 via a communication link 154 in a 5 GHz unlicensed frequency spectrum. When communicating in the unlicensed spectrum, the STA 152 / AP 150 may perform a clear channel assessment (CCA) before communicating to determine whether the channel is available.

[0074] The small cell 102' may operate in a licensed and / or unlicensed spectrum. When operating in an unlicensed spectrum, the small cell 102' may employ NR and use the same 5 GHz unlicensed spectrum as the 5 GHz unlicensed spectrum used by the Wi-Fi AP 150. The small cell 102' employing NR in the unlicensed spectrum may increase the coverage of the access network and / or improve the capacity of the access network.

[0075] The base station 102 (whether a small cell 102' or a large cell (e.g., a macro base station)) may include an eNB, a gNodeB (gNB), or other types of base stations. Some base stations, such as gNB 180, may operate in the traditional sub-6 GHz spectrum, millimeter wave (mmW) frequencies, and / or near-mmW frequencies to communicate with the UE 104. When the gNB 180 operates at mmW or near-mmW frequencies, the gNB 180 may be referred to as a mmW base station. Extremely high frequency (EHF) is a portion of the RF in the electromagnetic spectrum. EHF has a range of 30 GHz to 300 GHz and a wavelength between 1 mm and 10 mm. Radio waves in the frequency band may be referred to as millimeter waves. Near mmW can extend down to frequencies of 3 GHz with a wavelength of 100 mm. The super high frequency (SHF) band extends between 3 GHz and 30 GHz and is also called centimeter waves. Communications using mmW / near mmW radio frequency bands (eg, 3 GHz-300 GHz) have extremely high path loss and short range. The mmW base station 180 may utilize beamforming 182 with the UE 104 to compensate for the extremely high path loss and short range.

[0076] The base station 180 may transmit beamformed signals in one or more transmit directions 108a to the UE 104. The UE 104 may receive beamformed signals from the base station 180 in one or more receive directions 108b. The UE 104 may also transmit beamformed signals to the base station 180 in one or more transmit directions. The base station 180 may receive beamformed signals from the UE 104 in one or more receive directions. The base station 180 / UE 104 may perform beam training to determine the best receive and transmit directions for each base station 180 / UE 104. The transmit and receive directions for the base station 180 may be the same or different. The transmit and receive directions for the UE 104 may be the same or different.

[0077] The EPC 160 may include a Mobility Management Entity (MME) 162, other MMEs 164, a serving gateway 166, an MBMS gateway 168, a Broadcast Multicast Service Center (BM-SC) 170, and a Packet Data Network (PDN) Gateway 172. The MME 162 may communicate with a Home Subscriber Server (HSS) 174. The MME 162 is a control node that handles signaling between the UE 104 and the EPC 160. Typically, the MME 162 provides bearer and connection management. All user Internet Protocol (IP) packets are transferred through the serving gateway 166, which itself is connected to the PDN Gateway 172. The PDN Gateway 172 provides UE IP address allocation and other functions. The PDN Gateway 172 and the BM-SC 170 are connected to the IP Service 176. The IP services 176 may include the Internet, an intranet, an IP Multimedia Subsystem (IMS), a Packet-Switched Streaming Service (PSS), and / or other IP services. The BM-SC 170 may provide functionality for provisioning and delivery of MBMS user services. The BM-SC 170 may serve as an entry point for content provider MBMS delivery, may be used to authorize and initiate MBMS bearer services within a Public Land Mobile Network (PLMN), and may be used to schedule MBMS delivery. The MBMS Gateway 168 may be used to allocate MBMS traffic to the BS 102, and may be responsible for session management (start / end) and collection of charging information related to the evolved MBMS (eMBMS), where the BS 102 belongs to a Multicast Broadcast Single Frequency Network (MBSFN) area that broadcasts specific services.

[0078] The core network 190 may include an access and mobility management function (AMF) 192, other AMFs 193, a location management function (LMF) 198, a session management function (SMF) 194, and a user plane function (UPF) 195. The AMF 192 may communicate with the Unified Data Management (UDM) 196. The AMF 192 is a control node that handles signaling between the UE 104 and the core network 190. Typically, the SMF 194 provides QoS flow and session management. All user Internet protocol (IP) packets are transmitted through the UPF 195. The UPF 195 provides UE IP address allocation and other functions. The UPF 195 is connected to the IP service 197. The IP service 197 may include the Internet, an intranet, an IP multimedia subsystem (IMS), a PS streaming service, and / or other IP services.

[0079] The BS may also be referred to as a gNB, Node B (NB), eNB, access point, basic transceiver station, radio base station, radio transceiver, transceiver function, Basic Service Set (BSS), Extended Service Set (ESS), transmit reception point (TRP), or some other suitable term. The BS 102 provides an access point to the EPC 160 or core network 190 for the UE 104. Examples of UE 104 include a cellular phone, a smart phone, a Session Initiation Protocol (SIP) phone, a laptop, a Personal Digital Assistant (PDA), a satellite radio, a global positioning system, a multimedia device, a video device, a digital audio player (such as an MP3 player), a camera, a game console, a tablet, a smart device, a wearable device, a vehicle, an electric meter, a gas pump, a large or small kitchen appliance, a medical device, an implant, a sensor / actuator, a display, or any other device with similar functions. Some of the UEs 104 may be referred to as IoT devices (e.g., parking meters, gas pumps, ovens, vehicles, heart monitors, etc.) UE 104 may also be referred to as a station, a mobile station, a user station, a mobile unit, a user unit, a wireless unit, a remote unit, a mobile device, a wireless device, a wireless communication device, a remote device, a mobile user station, an access terminal, a mobile terminal, a wireless terminal, a remote terminal, a handset, a user agent, a mobile client, a client, or some other suitable terminology.

[0080] Although the present invention may be described with reference to 5G NR, the present invention may be applicable to other similar fields, such as LTE, LTE-A, CDMA, GSM or other wireless / radio access technologies.

[0081] Figure 22 is a block diagram of BS 210 and UE 250 communicating in an access network. In the DL, IP packets from EPC 160 may be provided to controller / processor 275. Controller / processor 275 implements layer 3 and layer 2 functions. Layer 3 includes the Radio Resource Control (RRC) layer, and layer 2 includes the Packet Data Convergence Protocol (PDCP) layer, the Radio Link Control (RLC) layer, and the Medium Access Control (MAC) layer. The controller / processor 275 provides: RRC layer functions, wherein the RRC layer functions are associated with broadcasting of system information (such as Master Information Block (MIB), System Information Block (SIB)), RRC connection control (such as RRC connection paging, RRC connection establishment, RRC connection modification, and RRC connection release), inter-Radio Access Technology (RAT) mobility, and measurement configuration for UE measurement reporting; PDCP layer functions, wherein the PDCP layer functions are associated with header compression / decompression, security (ciphering, deciphering, integrity protection, integrity verification), and handover support functions; RLC layer functions, wherein the RLC layer functions are associated with transfer of higher layer Packet Data Unit (PDU), error correction through Automatic Repeat Request (ARQ), RLC Service Data Unit (SDU) The MAC layer functions are associated with the concatenation, segmentation and reassembly of RLC data PDU (SDU), the re-segmentation of RLC data PDU and the reordering of RLC data PDU; and MAC layer functions, wherein the MAC layer functions are associated with the mapping between logical channels and transport channels, the multiplexing of MAC SDU onto transport blocks (TB), the demultiplexing of MAC SDU from TB, scheduling information reporting, error correction through hybrid automatic repeat request (HARQ), priority processing and logical channel prioritization.

[0082] The transmit (TX) processor 216 and the receive (RX) processor 270 implement layer 1 functions associated with various signal processing functions. Layer 1 (including the physical (PHY) layer) may include error detection on the transmission channel, forward error correction (FEC) encoding / decoding of the transmission channel, interleaving, rate matching, mapping to the physical channel, modulation / demodulation of the physical channel, and MIMO antenna processing. The TX processor 216 processes the mapping to the signal constellation based on various modulation schemes (such as binary phase-shift keying (BPSK), quadrature phase-shift keying (QPSK), M-phase-shift keying (M-PSK), M-quadrature amplitude modulation (M-QAM)). The coded and modulated symbols can then be divided into parallel streams, each of which can then be mapped to an Orthogonal Frequency Division Multiplexing (OFDM) subcarrier, multiplexed with a Reference Signal (RS) (such as a pilot) in the time domain and / or frequency domain, and then combined using an Inverse Fast Fourier Transform (IFFT) to produce a physical channel carrying a time domain OFDM symbol stream. The OFDM stream is spatially precoded to produce multiple spatial streams. Channel estimates from the channel estimator 274 can be used to determine the coding and modulation schemes, as well as for spatial processing. Channel estimates can be derived from RS and / or channel state feedback transmitted by the UE 250. Each spatial stream can then be provided to a different antenna 220 via a separate transmitter 218TX. Each transmitter 218TX can modulate an RF carrier using each spatial stream for transmission.

[0083] At the UE 250, each receiver 254RX can receive a signal through each antenna 252. Each receiver 254RX recovers the information modulated onto the RF carrier and provides the information to the RX processor 256. The TX processor 268 and the RX processor 256 implement layer 1 functions associated with various signal processing functions. The RX processor 256 can perform spatial processing on the information to recover any spatial stream to the UE 250. If there are multiple spatial streams to the UE 250, the multiple spatial streams can be combined into a single OFDM symbol stream by the RX processor 256. The RX processor 256 then converts the OFDM symbol stream from the time domain to the frequency domain using a Fast Fourier Transform (FFT). The frequency domain signal includes separate OFDM symbol streams for each subcarrier of the OFDM signal. The symbols and RS on each subcarrier are recovered and demodulated by determining the most likely signal constellation point transmitted by the BS 210. These soft decisions can be based on the channel estimates calculated by the channel estimator 258. These soft decisions may then be decoded and deinterleaved to recover the data and control signals originally transmitted on the physical channel by BS 210. The data and control signals may then be provided to controller / processor 259, which implements layer 3 and layer 2 functions.

[0084] The controller / processor 259 may be associated with a memory 260 that stores program codes and data. The memory 260 may be referred to as a computer readable medium. In the UL, the controller / processor 259 provides demultiplexing between transport and logical channels, packet reassembly, decryption, header decompression, and control signal processing to recover IP packets from the EPC 160. The controller / processor 259 is also responsible for error detection using an Acknowledgement (ACK) and / or Negative Acknowledgment (NACK) protocol to support HARQ operations.

[0085] Similar to the functions described in conjunction with DL transmission of BS210, the controller / processor 259 provides: RRC layer functions, wherein the RRC layer functions are associated with acquisition of system information (such as MIB, SIB), RRC connection and measurement reporting; PDCP layer functions, wherein the PDCP layer functions are associated with header compression / decompression and security (encryption, decryption, integrity protection, integrity verification); RLC layer functions, wherein the RLC layer functions are associated with transfer of higher layer PDUs, error correction through ARQ, concatenation, segmentation and reassembly of RLC SDUs, re-segmentation of RLC data PDUs and reordering of RLC data PDUs; and MAC layer functions, wherein the MAC layer functions are associated with mapping between logical channels and transport channels, multiplexing of MAC SDUs onto TBs, demultiplexing of MAC SDUs from TBs, scheduling information reporting, error correction through HARQ, priority processing and logical channel prioritization.

[0086] The channel estimate derived from the RS or feedback transmitted by the channel estimator 258 from the BS 210 can be used by the TX processor 268 to select the appropriate codec and modulation scheme, and to facilitate spatial processing. The spatial stream generated by the TX processor 268 can be provided to different antennas 252 via separate transmitters 254TX. Each transmitter 254TX can modulate the RF carrier using each spatial stream for transmission. Similar to the description of the receiver function at the UE 250, UL transmission is processed in a similar manner at the BS 210. Each receiver 218RX receives a signal through each antenna 220. Each receiver 218RX recovers the information modulated onto the RF carrier and provides the information to the RX processor 270.

[0087] The controller / processor 275 may be associated with a memory 276 that stores program codes and data. The memory 276 may be referred to as a computer readable medium. In the UL, the controller / processor 275 provides demultiplexing between transport and logical channels, packet reassembly, decryption, header decompression, control signal processing to recover IP packets from the UE 250. The IP packets from the controller / processor 275 may be provided to the EPC 160. The controller / processor 275 is also responsible for error detection using ACK and / or NACK protocols to support HARQ operations.

[0088] NR may refer to a radio configured to operate according to a new air interface (e.g., in addition to an OFDMA-based air interface) or a fixed transport layer (e.g., in addition to IP). NR may utilize OFDM with a cyclic prefix (CP) on both UL and DL, and may include support for half-duplex operation using time division duplexing (TDD). NR may include mission critical features such as Enhanced Mobile Broadband (eMBB) services targeting wide bandwidths (e.g., above 80 MHz), mmW targeting high carrier frequencies (e.g., 60 GHz), Massive Machine Type Communication (mMTC) targeting non-backward compatible Machine Type Communication (MTC) technologies, and / or Ultra-Reliable Low Latency Communication (URLLC) services targeting.

[0089] A single component carrier bandwidth of 100 MHz can be supported. In one example, an NR resource block (RB) can span 12 subcarriers, where the 12 subcarriers have a subcarrier bandwidth of 60 KHz over a duration of 0.25 ms or a bandwidth of 30 KHz over a duration of 0.5 ms (similarly, 50 MHz bandwidth is used for a 15 kHz subcarrier spacing (SCS) over a duration of 1 ms). Each radio frame may include 10 subframes (or 10, 20, 40, or 80 NR time slots) of length 10 ms. Each time slot may indicate the link direction (i.e., DL or UL) used for data transmission and the link direction for each time slot may be dynamically switched. Each time slot may contain DL / UL data and DL / UL control data. Please refer to the following Figure 5 and Figure 6 The UL and DL time slots for NR are described in more detail.

[0090] The NR RAN may include a central unit (CU) and a distributed unit (DU). The NR BS (such as gNB, 5G NB, NB, Transmission Reception Point (TRP), AP) may correspond to one or more BSs. The NR cell may be configured as an access cell (ACell) or a data-only cell (DCell). For example, the RAN (such as a CU or DU) may configure the above cells. The DCell may be a cell for carrier aggregation or dual connectivity and may not be used for initial access, cell selection / reselection, or switching. In some cases, the DCell may not transmit a synchronization signal (SS), and in some cases, the DCell may transmit an SS. The NR BS may transmit a DL signal to the UE to indicate the cell type. Based on the cell type indication, the UE may communicate with the NR BS. For example, the UE may determine the NR BS based on the indicated cell type to consider cell selection, access, switching, and / or measurement.

[0091] Figure 3 An exemplary logical architecture of a distributed RAN 300 according to aspects of the present invention is illustrated. A 5G access node (AN) 306 may include an access node controller (ANC) 302. The ANC may be the CU of a distributed RAN. The backhaul interface to the Next Generation Core Network (NG-CN) 304 may terminate at the ANC. The backhaul interface to an adjacent next generation access node (NG-AN) 310 may terminate at the ANC. The ANC may include one or more TRPs 308 (TRPs may also be referred to as BSs, NR BSs, NBs, 5G NBs, APs, or some other terms). As described above, TRPs may be used interchangeably with "cells."

[0092] The TRP 308 may be a DU. The TRP may be connected to one ANC (ANC 302) or more than one ANC (not illustrated). For example, for RAN sharing, Radio as a Service (RaaS), and service-specific ANC deployments, the TRP may be connected to more than one ANC. The TRP may include one or more antenna ports. The TRP may be configured to independently (e.g., dynamically selected) or jointly (e.g., jointly transmitted) supply services to the UE.

[0093] The logical architecture of the distributed RAN 300 can be used to illustrate the fronthaul definition. The architecture can be defined to support fronthaul solutions across different deployment types. For example, the architecture can be based on transmission network performance (such as bandwidth, latency and / or jitter). The architecture can share features and / or components with LTE. According to aspects of the present invention, the NG-AN310 can support dual connectivity with NR. The NG-AN can share a common fronthaul for LTE and NR.

[0094] The architecture may enable collaboration between TRPs 308. For example, collaboration may be provisioned within and / or across TRPs via ANC 302. According to aspects of the invention, an inter-TRP interface may not be required / existent.

[0095] According to aspects of the present invention, dynamic configuration of separate logical functions may exist within the architecture of the distributed RAN 300. PDCP, RLC, MAC protocols may be adaptively located at the ANC or TRP.

[0096] Figure 4 An exemplary physical architecture of a distributed RAN 400 according to aspects of the present invention is illustrated. A centralized core network unit (C-CU) 402 can host core network functions. The C-CU can be centrally deployed. To handle peak capacity, C-CU functions can be offloaded (e.g., to Advanced Wireless Service (AWS)). A centralized RAN unit (C-RU) 404 can host one or more ANC functions. Optionally, the C-RU can host core network functions locally. The C-RU can have a distributed deployment. The C-RU can be closer to the edge of the network. The DU 406 can host one or more TRPs. The DU can be located at the edge of the network with RF functions.

[0097] Figure 55 is a schematic diagram of an exemplary DL-centric time slot. The DL-centric time slot may include a control portion 502. The control portion 502 may be present in an initial or starting portion of the DL-centric time slot. The control portion 502 may include various scheduling information and / or control information corresponding to various portions of the DL-centric time slot. In some configurations, such as Figure 5 As shown, the control portion 502 can be a physical downlink control channel (Physical DL Control Channel, PDCCH). The DL-centric time slot can also include a DL data portion 504. The DL data portion 504 can sometimes be referred to as the payload of the DL-centric time slot. The DL data portion 504 can include communication resources for communicating DL data from a scheduling entity (such as a UE or a BS) to a subordinate entity (such as a UE). In some configurations, the DL data portion 504 can be a physical downlink shared channel (Physical DL Shared Channel, PDSCH).

[0098] The DL-centric time slot may also include a common UL portion 506. The common UL portion 506 may sometimes be referred to as a UL burst, a common UL burst, and / or various other suitable terms. The common UL portion 506 may include feedback information corresponding to various other portions of the DL-centric time slot. For example, the common UL portion 506 may include feedback information corresponding to the control portion 502. Non-limiting examples of feedback information may include ACK signals, NACK signals, HARQ indicators, and / or various other suitable types of information. The common UL portion 506 may include additional or further information, such as information about a random access channel (RACH) process, a scheduling request, and various other suitable types of information.

[0099] like Figure 5As shown, the end of the DL data portion 504 can be separated in time from the start of the common UL portion 506. This time separation may sometimes be referred to as a gap, a guard period, a guard interval, and / or various other suitable terms. This separation provides time for a switch-over from DL communications (e.g., a reception operation performed by a subordinate entity (e.g., a UE)) to UL communications (e.g., a transmission performed by a subordinate entity (e.g., a UE)). It will be appreciated by those skilled in the art that the foregoing is merely an example of a DL-centric time slot, and that alternative structures having similar features may exist without necessarily departing from the aspects described herein.

[0100] Figure 6 600 is a diagram of an exemplary UL-centric timeslot. The UL-centric timeslot may include a control portion 602. The control portion 602 may be present in an initial or starting portion of the UL-centric timeslot. Figure 6 The control part 602 in the above reference Figure 5 The control portion 502 described is similar. The UL-centric time slot may also include a UL data portion 604. The UL data portion 604 may sometimes be referred to as the payload of the UL-centric time slot. The UL portion may refer to communication resources used to communicate UL data from a subordinate entity (such as a UE) to a scheduling entity (such as a UE or a BS). In some configurations, the control portion 602 may be a physical uplink control channel (PUCCH).

[0101] like Figure 6 As shown, the end of the control portion 602 can be separated in time from the beginning of the UL data portion 604. This time separation may sometimes be referred to as an interval, a guard period, a guard gap, and / or various other suitable terms. The separation provides time for switching from DL communications (such as reception operations performed by the scheduling entity) to UL communications (such as transmissions performed by the scheduling entity). The UL-centric timeslot may also contain a common UL portion 606. Figure 6 The common UL portion 606 in the embodiment may be similar to the above reference Figure 5The common UL portion 506 described herein. The common UL portion 606 may additionally or additionally include information about a channel quality indicator (CQI), a sounding reference signal (SRS), and various other suitable types of information. It will be appreciated by those skilled in the art that the foregoing is merely an example of a UL-centric time slot, and that alternative structures having similar features may exist without necessarily departing from the aspects described herein.

[0102] In some cases, two or more subordinate entities (such as UEs) can use sidelink signals to communicate with each other. The actual applications of such sidelink communications may include public safety, proximity services, UE-to-network relays, vehicle-to-vehicle (V2V) communications, Internet of Everything (IoE) communications, IoT communications, mission-critical meshes, and / or various other suitable applications. Generally, a sidelink signal may refer to a signal that is communicated from one subordinate entity (such as UE1) to another subordinate entity (such as UE2) without relaying the communication through a scheduling entity (such as a UE or BS), even if the scheduling entity may be used for scheduling and / or control purposes. In some examples, a sidelink signal may use a licensed spectrum to communicate (unlike wireless local area networks that typically use unlicensed spectrum).

[0103] 7(A) is a schematic diagram 700 showing an example of a wireless communication system including a base station and a UE. In this example, a UE 704 is connected to a base station 702 located in a cell 706.

[0104] A-IoT devices often have limitations in communication range, power consumption, and charging time. For example, the maximum coverage range of some devices is less than the maximum distance requirement for indoor use cases due to the activation power threshold. Increasing the transmit power can achieve the desired range, but may interfere with nearby base stations. In addition, the activation threshold of some devices depends on the activation threshold of the rectifier in the RF energy harvester, which causes uncertainty when the base station discovers the device in the cell, especially when the device has low battery or no battery.

[0105] The increasing number of IoT devices brings challenges in power management, and manually replacing or charging batteries becomes impractical due to cost, environmental and safety factors. Existing technologies such as barcodes and Radio Frequency Identification (RFID) also face limitations in read range and interference. Therefore, new IoT technologies are needed that can support battery-free devices or devices with energy storage without manual intervention. The goal is to create a solution within the 3GPP system that can handle a large number of connections and device density while reducing complexity and power consumption, thereby opening up new markets and adding value in the value chain.

[0106] The present disclosure provides methods and systems for improving the communication range, power consumption, and charging time of A-IoT devices. The disclosure includes techniques for increasing the transmit power to achieve the desired range while minimizing interference to nearby base stations. The disclosure also includes techniques for optimizing the device activation threshold based on the activation threshold of the rectifier in the RF energy harvester, thereby reducing the uncertainty of the base station discovering the device in the cell. In addition, the disclosure also includes techniques for reducing the charging time of the device, especially when using RF energy.

[0107] It is worth noting that although the description provided herein may be in the context of certain radio access technologies, networks and network topologies such as Long Term Evolution (LTE), LTE-Advanced, LTE-Advanced Professional, Fifth Generation (5G), New Radio (NR), Internet of Things (IoT) and Narrowband Internet of Things (NB-IoT), Industrial Internet of Things (IIoT) and Sixth Generation (6G), the proposed concepts, schemes and any variants / derivatives thereof may be implemented, applied and performed in other types of radio access technologies, networks and network topologies. Therefore, the scope of the present disclosure is not limited to the examples described.

[0108] System topology

[0109] FIG7(B) is a schematic diagram 710 showing an example of a communication link between a gNB and an A-IoT device connected to a UE via a wired cable. The present invention introduces a new A-IoT communication system topology. As shown in FIG7(B), the gNB establishes a connection with the UE or UE reader via a wired cable. This configuration eliminates the need for a new air interface between the gNB and the A-IoT device, and instead introduces a new air interface between the UE reader and the A-IoT device. Therefore, the workload required for any gNB specification changes is significantly reduced. In this setup, the gNB can access the A-IoT device through the UE reader, which acts as an intermediate node between the device and the base station (gNB).

[0110] FIG7(C) is a schematic diagram 720 showing an example of a communication link between a gNB and an A-IoT device connected to a UE via a wireless air interface. As shown in FIG7(C), a wireless air interface is established between the gNB and the UE or UE reader. This air interface utilizes the NR-Uu interface to minimize specification changes on the UE side. A new air interface needs to be established between the UE and the A-IoT device, and its specification can be determined based on the use case and its corresponding requirements.

[0111] Receiver Architecture

[0112] FIG7(D) is a schematic diagram 730 showing a first type of A-IoT device. Device A is designed with specific goals in terms of power consumption (≤1 microwatt or ≤10 microwatts) and complexity during transmission / reception, with the goal of being comparable to UHFRFID ISO18000-6C (EPC C1G2). Device A has no energy storage or independent signal generation / amplification capabilities and relies on backscatter transmission. It requires a backscatter activation power threshold, experiences reflection losses, and requires a remote carrier source to transmit the positioning signal.

[0113] The architecture of device A includes the following components:

[0114] A low pass filter (LPF) is used to suppress adjacent sub-carrier interference (ASCI) and adjacent carrier interference (ACI);

[0115] Envelope detector (ED) to support On-Off Keying (OOK) based signals;

[0116] Analog to digital converter (ADC), used for digital baseband processing;

[0117] Digital baseband (DBB), used for sequence matching;

[0118] A modulator (switch) controlled by the incoming signal to add payload data to the OOK modulation;

[0119] RF energy harvester converts RF signals into energy.

[0120] FIG7(E) is a schematic diagram 732 showing a second type of A-IoT device. Device B is designed to be between device A and device C in terms of power and complexity. It has energy storage but no independent signal generation, relying on backscatter transmission. The stored energy can be used for signal amplification. Device B also requires a backscatter activation power threshold, experiences reflection losses, and requires a remote carrier source to transmit the positioning signal.

[0121] The architecture of device B includes the following components:

[0122] LPF, used to inhibit ASCI and ACI;

[0123] ED, to support OOK-based signals;

[0124] ADC, for digital baseband processing;

[0125] DBB, for sequence matching;

[0126] A modulator controlled by the incoming signal to add payload data to the OOK modulation;

[0127] RF energy harvester, which converts RF signals into energy;

[0128] Additional energy harvesters are used for different types of ambient energy sources, such as RF radio, solar, thermal, and piezoelectric energy;

[0129] Energy storage, such as capacitors and solid-state batteries; and

[0130] The reflection amplifier is used to amplify the input signal to the tag and the backscattered signal towards the reader.

[0131] FIG7(F) is a schematic diagram 734 showing a third type of A-IoT device. Device C is designed with a power consumption target of ≤1mW to ≤10mW during transmission / reception and a complexity target much lower than NarrowBand IoT (NB-IoT). Device C has energy storage, independent signal generation, and active RF components for transmission. It also has mobility management capabilities, at least for cell selection / reselection.

[0132] The architecture of device C includes the following components:

[0133] LPF is used to inhibit ASCI and ACI;

[0134] ED is used to support OOK-based signals;

[0135] ADC is used for digital baseband processing;

[0136] DBB is used for synchronization, payload decoding, and cyclic redundancy check (CRC);

[0137] RF energy harvesters are used to convert RF signals into energy;

[0138] Additional energy harvesters are used for different types of ambient energy sources, such as RF radio, solar, thermal, and piezoelectric energy;

[0139] Energy storage, such as capacitors and solid-state batteries; and

[0140] Low-noise amplifiers (LNA) and power amplifiers (PA) are used to amplify received and transmitted signals.

[0141] New air interface

[0142] 7(G) is a schematic diagram 740 showing an example communication link between a UE, such as UE 744, and an A-IoT device, such as A-IoT device 746, over an air interface. The present invention provides an innovative air interface for communication between a UE and an A-IoT device. The communication process is initiated when the UE powers the A-IoT device and transmits a command. This command outlines basic communication parameters such as tag rate, tag data encoding method, and total duration available.

[0143] Once the A-IoT device has collected enough energy, it can be activated and listen for commands from the UE. After decoding the command, the A-IoT device randomly selects a duration from the available range and generates a random sequence. This sequence is then transmitted for the selected duration, preceded by a known preamble sequence.

[0144] In response to the A-IoT transmission, the UE decodes the received preamble sequence and sends an acknowledgment message back to the A-IoT within a predetermined duration according to the system configuration of the A-IoT rate.

[0145] 7(H) is a schematic diagram 750 illustrating an example communication process between a reader device and an A-IoT device based on a selected duration. The communication link from the UE to the A-IoT device (User Equipment to Ambient IoT Device, U2A) uses a modulation scheme such as Amplitude Shift Keying (ASK) or OOK to facilitate pulse interval encoding (PIE) for data transmission. The U2A link includes two preambles: a long U2A preamble for initial transmission and a short U2A preamble for subsequent signals. The UE transmits the long U2A preamble and a control signal or command specifying the control parameters of the A-IoT device.

[0146] The A-IoT device to UE (Ambient IoT Device to User Equipment, A2U) communication link uses ASK or phase shift keying (PSK) modulation. A-IoT uses FM0 baseband or Miller modulation to encode backscattered data, which is controlled by the UE or gNB through the A2U link. The A2U link signal transmission starts with one of the two Miller subcarrier preambles, depending on the command or control signal. A-IoT uses backscatter modulation to change the reflection coefficient of its antenna to transmit data. The A2U link transmits Electronic Product Code (EPC) and Protocol-Control (PC) information.

[0147] Modified 4-step random access channel (RACH)

[0148] Considering that A-IoT devices can only perform ASK (Amplitude Shift Keying) or OOK (On-Off Keying) modulation and backscatter communication, and the downlink (DL) signal can be the Primary Synchronization Signal (PSS), the Secondary Synchronization Signal (SSS), and the OOK-based Low Power Wake-Up Signal (LP-WUS), the modified 4-step RACH process can be as follows:

[0149] 1. DL signal reception: The A-IoT device listens for PSS, SSS, or LP-WUS from the gNB or UE reader. These signals serve as "inquiry commands" for the A-IoT device. For example, LP-WUS, which is specifically designed to wake up the device from a low-power state, may be particularly useful for A-IoT devices. Upon detecting one of these signals, the A-IoT device wakes up and prepares for further communication.

[0150] 2. Preamble transmission (Msg1): After receiving the DL signal, the A-IoT device generates a random 16-bit number (RN16) and backscatters it back to the gNB or UE reader. This can be done through backscatter communication using ASK or OOK modulation. This is similar to how an RFID tag sends RN16 to the reader in response to a query command.

[0151] 3. Random Access Response (Msg2): The gNB or UE reader sends an acknowledgment message containing RN16 to the A-IoT device. This acknowledgment can be sent on a specific DL channel that the A-IoT device is programmed to monitor. Upon receiving this acknowledgment, the A-IoT device knows that the gNB or UE reader has successfully received its RN16.

[0152] 4.RRC Connection Request (Msg3): Once the A-IoT device receives the confirmation, it can send its EPC to the gNB or UE reader via backscatter communication using ASK or OOK modulation. This EPC is a unique identifier for the A-IoT device, similar to the unique identifier of an RFID tag.

[0153] 5. Conflict Resolution (Msg4): The gNB or UE reader sends a conflict resolution message to the A-IoT device, confirming the EPC of the A-IoT device and completing the RACH process. This step ensures that the A-IoT device has been correctly identified and there is no conflict with other A-IoT devices. The conflict resolution message may include the EPC of the A-IoT device so that the device knows that the message is intended for it.

[0154] This modified 4-step RACH process is more in line with the RFID protocol, with the A-IoT device acting as an RFID tag and the gNB or UE reader acting as an RFID reader.

[0155] FIG7(I) is a timing diagram 760 depicting the modified 4-step RACH procedure. In this diagram, the "A-IoT Device" participant represents the A-IoT device and the "gNB / UE Reader" participant represents the gNB or UE reader. The arrows represent the communication between the two participants and the annotations provide additional information about the behavior of each participant at each step of the procedure.

[0156] Modified 2-step RACH

[0157] This section describes the proposed modification of the 2-step RACH procedure to accommodate the characteristics of A-IoT devices. The modification is consistent with the RFID protocol and takes into account the ability of A-IoT devices to perform ASK or OOK modulation and backscatter communication.

[0158] The process consists of two main stages:

[0159] 1. Downlink signal transmission and preamble transmission (Message 1): The gNB or UE reader initiates the process by sending a DL signal along with RN16 to the A-IoT device. The DL signal can be PSS, SSS, or LP-WUS, which serves as a "query command" for the A-IoT device. For example, the gNB can send a DL signal (PSS) along with RN16 (1011 1100 0011 1110). After receiving this signal, the A-IoT device uses it to charge its battery.

[0160] 2. Random Access Response and Collision Resolution (Message 2): In the subsequent stage, the A-IoT device verifies the received RN16 with its tag ID. After a successful match, the A-IoT device transmits the RN16 and its unique EPC back to the gNB or UE reader through backscatter communication using ASK or OOK modulation. For example, if the RN16 matches the tag ID of the A-IoT device, the device responds by backscattering RN16 (1011 1100 0011 1110) and its EPC (e.g., 0000 1010 1111 0000). The gNB or UE reader completes the RACH process by sending a final confirmation message to the A-IoT device after successfully receiving the EPC.

[0161] This modification to the 2-step RACH procedure brings it closer to the RFID protocol, positioning the A-IoT device as an RFID tag and the gNB or UE reader as an RFID reader. However, this is a simplified representation and may not cover all aspects of the NR and RFID protocols.

[0162] FIG7(J) is a timing diagram 770 depicting the modified 2-step RACH procedure. In this timing diagram, the "A-IoT Device" participant represents the A-IoT device and the "gNB / UE Reader" participant represents the gNB or UE reader. The arrows represent the communication between the two participants and the annotations provide additional details about the behavior of each participant at each step of the procedure.

[0163] This diagrammatic representation is consistent with the modified 2-step RACH process. The A-IoT device acts as an RFID tag and the gNB or UE reader plays the role of the RFID reader. It is important to note that this is a simplified model and may not cover all aspects of the NR and RFID protocols. Real-world implementations may require additional measures to manage errors, retransmissions, and security considerations. This timing diagram serves as a high-level overview of the process and provides a basis for further elaboration based on specific implementation requirements.

[0164] Modified RACH procedure (UE acts as a tag reader)

[0165] 7(K) is a timing diagram 780 depicting a modified RACH procedure where the UE acts as a tag reader. As shown in FIG7(K), this modification allows the UE to communicate as a reader with an A-IoT device that acts as a tag.

[0166] 1. Preamble (Query): The UE (acting as a reader) initiates the process by sending a modified RACH preamble. This preamble is broadcast to all tags in its vicinity. This acts as a "query" in the RFID protocol. The modified preamble can be sent over the Physical Random Access Channel (PRACH). The preamble may contain a specific sequence or pattern that the tags are programmed to recognize. For example, the preamble may start with a specific bit pattern followed by the UE's unique identifier.

[0167] The UE's behavior will involve generating a preamble and transmitting it over the PRACH. The UE needs to ensure that the preamble can be detected by the tag, which may require changing the format or power level of the preamble.

[0168] 2. Response (RN16): After detecting the preamble, each tag generates and responds with RN16. This will be similar to the RACH response in the current process. The tag needs to have the ability to generate and transmit RN16, which is not a feature of traditional RFID tags. This will require modifications to the tag's firmware and possibly hardware. The response can be sent over PUSCH.

[0169] The behavior of the A-IoT device will involve listening to the preamble on the PRACH, generating RN16 after detecting the preamble, and transmitting RN16 over the PUSCH.

[0170] 3. Connection Setup (ACK): The UE listens for a response from the tag. Upon receiving a valid RN16 from the tag, the UE sends a modified connection setup message to the tag. This is equivalent to an "ACK" in the RFID protocol. The UE needs to be modified to generate and send this ACK message. The ACK message can be sent over the PDCCH and can contain the RN16 and a command instructing the tag to transmit its unique identifier.

[0171] The UE's behavior will involve listening to RN16 on PUSCH, verifying RN16, and transmitting an ACK message via PDCCH.

[0172] 4. Data transmission (EPC): After receiving the ACK message, the tag responds with its unique identifier. This will be similar to the EPC in the RFID protocol. The tag needs to be modified to store its unique identifier and transmit it after receiving the ACK message. The unique identifier can be sent over PUSCH.

[0173] The behavior of the A-IoT device will involve listening to the ACK message on the PDCCH, extracting the command in the ACK message, and transmitting its unique identifier over the PUSCH.

[0174] This will require significant changes to the UE and tags, including hardware and firmware modifications.

[0175] Based on the context provided, Figure 7(K) shows what a portion of a technical report might look like, including a PlantUML sequence diagram.

[0176] The proposed 5G NR RACH procedure modification allows the UE as a reader to communicate with the A-IoT device as a tag.

[0177] Modified Sidechain Process

[0178] 7(L) is a timing diagram 790 that illustrates the modified sidechain process. This approach allows the UE to act as an RFID reader and the A-IoT device to interact as an RFID tag.

[0179] 1. Discovery signal (Query): The UE (as a reader) sends a discovery signal to all tags in its vicinity. This is equivalent to "query" in the RFID protocol. The discovery signal can be sent over the Physical Sidelink Control Channel (PSCCH). The signal can contain a specific sequence or pattern that the tag is programmed to recognize. For example, the signal can start with a specific bit pattern, followed by the UE's unique identifier.

[0180] The UE's behavior will involve generating a discovery signal and transmitting it over the PSCCH. The UE needs to ensure that the signal can be detected by the tag, which may require changing the format or power level of the signal.

[0181] 2. Discovery Response (RN16): After detecting the discovery signal, each tag generates RN16 and responds to it. This will be similar to the discovery response in the current sidelink process. The tag needs to be modified to generate and transmit this RN16. The response can be sent over the Physical Sidelink Shared Channel (PSSCH).

[0182] The behavior of the A-IoT device will involve listening for discovery signals on the PSCCH, generating RN16 upon detection of the signal, and transmitting RN16 over the PSSCH.

[0183] 3. Sidelink Connection Setup (ACK): The UE listens for a response from the tag. Upon receiving a valid RN16 from the tag, the UE sends a Sidelink Connection Setup message to the tag. This is equivalent to an "ACK" in the RFID protocol. The UE needs to be modified to generate and send this ACK message. The ACK message can be sent over the PSCCH and can contain the RN16 and a command instructing the tag to transmit its unique identifier.

[0184] The UE's behavior will involve listening to RN16 on PSSCH, verifying RN16, and transmitting an ACK message over PSCCH.

[0185] 4. Data Transmission (EPC): After receiving the ACK message, the tag responds with its unique identifier. This will be similar to the EPC in the RFID protocol. The tag needs to be modified to store its unique identifier and transmit it after receiving the ACK message. The unique identifier can be sent over the PSSCH.

[0186] The behavior of the A-IoT device will involve listening for an ACK message on the PSCCH, extracting the command in the ACK message, and transmitting its unique identifier over the PSSCH.

[0187] This will require significant changes to the UE and tags, including hardware and firmware modifications.

[0188] Figure 7(L) shows a part of the technical report, which contains the PlantUML sequence diagram.

[0189] In order to leverage the power of 5G NR for RFID-like communications, this invention proposes a modified sidechain process. This approach allows the UE to act as an RFID reader and the A-IoT device to interact as an RFID tag.

[0190] Charging time

[0191] FIG8(A) is a schematic diagram 800 illustrating the charging time issue. When deploying A-IoT devices, one of the devices (device B) stores the harvested RF energy using a small capacitor or battery. This storage allows enough energy to accumulate for reporting, and the activation threshold is optimized to less than -30dBm. This threshold is determined by the rectifier activation threshold in the RF energy harvester.

[0192] However, if device B has an amplifier that requires higher power consumption (about 100uW or more), then RF signal energy harvesting may not be suitable due to its relatively low energy density. Alternative solutions such as energy storage with solar panels may be used.

[0193] Assuming device B has no battery or a low battery and is located 54 meters away from the base station (-38dBm), using an RF energy harvester to support the LNA and 1ms power-on time will require a charging time of 2.5 seconds. This is significantly longer than the 4ms required using a 1cm2 solar panel and indoor light.

[0194] Until device B is fully charged to make the 1ms transmission, it cannot be reached by the base station. This increases the uncertainty of the base station discovering device B within the cell, which is a significant concern for reliable communication.

[0195] By reducing the power-on time from 1ms to 0.1ms, the RF charging time is reduced by 90% from 2524ms to 252ms. This allows the tag to send a quick signal to the base station indicating that it needs more charging time to complete a full payload transfer. However, this quick signal may not contain complete information, leading to potential communication problems.

[0196] The following table summarizes the charging time for different power-on times:

[0197] Boot time (ms) Time for charging by light (ms) Charging time by RF (ms) 0.1 0.4 252 0.5 2 1262 1 (baseline) 4 2524 5 20 12619 10 40 25238

[0198] These findings highlight the challenges of energy harvesting and charging time for A-IoT devices. In particular, the significant charging time required when using RF energy harvesting, as well as issues with device accessibility during charging, raise concerns about the practical deployment of such devices.

[0199] Shortened feedback signal

[0200] FIG8(B) is a schematic diagram 820 showing the use of shortened feedback signals to manage charging time. The A-IoT device can use shortened feedback signals to communicate its charging status to the gNB or UE reader. This approach is the most feasible because it has minimal changes to existing systems. This approach allows the gNB or UE reader to quickly determine the charging status of the A-IoT device and adjust its communication schedule accordingly.

[0201] In this approach, an A-IoT device can generate a unique, shorter signal to represent its charging status. This signal can be a binary string of a specific length, with each bit or group of bits representing a different aspect of the charging status, such as charging status, battery level, and estimated time to fully charge.

[0202] For example, the charge state can be represented as an 8-bit binary string divided into different parts:

[0203] Charging status (2 bits): 00 represents not charged, 01 represents charging, and 10 represents fully charged.

[0204] Battery Level (3 bits): Binary representation of the battery level, divided into 8 levels, where 000 represents 0% (empty) and 111 represents 100% (full).

[0205] Time required to fully charge (3 bits): A binary representation of the estimated time required to fully charge, divided into 8 levels, where 000 represents 0 minutes and 111 represents the maximum threshold, such as 120 minutes.

[0206] This shorter charging status message can be sent as a response to a wake-up signal from a gNB or UE reader, indicating that the device is ready for further communication. Upon receiving this message, the gNB or UE reader can adjust its communication schedule accordingly. This approach allows for efficient communication while ensuring accurate communication of the energy status of the A-IoT device.

[0207] The implementation of shorter charging status messages is incorporated into various processes as follows:

[0208] 9(A) is a timing diagram 900 depicting a modified 4-step RACH procedure with a shortened feedback signal. In the modified 4-step RACH procedure, the A-IoT device may send a shorter charging status message instead of RN16 after receiving a DL signal from a gNB or UE reader.

[0209] 9(B) is a timing diagram 920 depicting a modified 2-step RACH procedure with a shortened feedback signal. In the modified 2-step RACH procedure, the A-IoT device may send a shorter charging status message in response to the DL signal.

[0210] 9(C) is a timing diagram 940 describing a modified RACH procedure for a shortened feedback signal when the UE acts as a tag reader. In the modified RACH procedure when the UE acts as a tag reader, the A-IoT device may send a shorter charging status message in response to the preamble of the UE reader.

[0211] 9(D) is a timing diagram 960 describing a modified side chain process with shortened feedback signals. In the modified side chain process, the A-IoT device may send a shorter charging status message in response to the discovery signal of the UE reader.

[0212] In all of these processes, the gNB or UE reader needs to be modified to extract the charge status from the shorter charge status message and adjust its communication schedule accordingly.

[0213] The conditions under which an A-IoT device chooses to send a shorter charging status message or RN16 are for efficient communication. These conditions can vary depending on the specific implementation of the communication protocol and the characteristics of the A-IoT device itself.

[0214] Send shorter charging status messages

[0215] A-IoT devices can send shorter charging status messages under the following conditions:

[0216] 1. Low Energy Level: When the energy level of the device is too low for backscatter communication, the device sends shorter charging status messages, thereby informing the gNB or UE reader that it needs more time to charge.

[0217] 2. Charging Status Change: If the charging status of the device changes, such as when it starts charging or is fully charged, the device sends a shorter charging status message to inform the gNB or UE reader of this change.

[0218] Send RN16

[0219] A-IoT devices can send RN16 under the following conditions:

[0220] 1. Sufficient energy level: If the device’s energy level is sufficient for backscatter communication, it sends RN16 as part of the normal communication process.

[0221] 2. No change in charging status: If the charging status of the device has not changed and it is not currently charging or is fully charged, the device sends RN16.

[0222] These conditions ensure that A-IoT devices communicate their energy status efficiently, allowing the gNB or UE reader to adjust its communication schedule accordingly. However, these are generalized conditions and the specific conditions may vary depending on the specific implementation of the communication protocol and the characteristics of the A-IoT device.

[0223] Incorporating charging status information into the RN16 signal sent by the A-IoT device to the gNB or UE reader is another possible solution. However, this approach requires modifying the signal generation of the A-IoT device. It enables the gNB or UE reader to receive the charging status of the A-IoT device early in the communication process.

[0224] FIG. 10(A) is a timing diagram 1000 depicting a modified 4-step RACH procedure with respect to charging status in RN16. In the modified 4-step RACH procedure, the A-IoT device may use a portion of the RN16 signal to indicate its charging status. For example, the first few bits of RN16 may be used to indicate different charging states. This would require changes to the signal generation of the A-IoT device to include the charging status in RN16.

[0225] FIG10(B) is a timing diagram 1020 depicting a modified 2-step RACH procedure with respect to charging status in RN16. In the modified 2-step RACH procedure, the A-IoT device may include its charging status in RN16 when responding to a DL signal. This would require changes to the signal generation of the A-IoT device to include the charging status in RN16.

[0226] FIG10(C) is a timing diagram 1040 regarding charging status in RN16, describing a modified RACH procedure where the UE acts as a tag reader. In the modified RACH procedure, the UE acts as a tag reader and the A-IoT device can include its charging status in the RN16 when responding to the preamble. This will require changes to the signal generation of the A-IoT device to include the charging status in the RN16.

[0227] FIG10(D) is a timing diagram 1060 describing a modified side chain process regarding charging status in RN16. In the modified side chain process, the A-IoT device may include its charging status in the discovery response when responding to the discovery signal. This would require changing the signal generation of the A-IoT device to include the charging status in the discovery response.

[0228] In all of these processes, the gNB or UE reader will need to be modified to extract the charge status from the RN16 or discovery response and adjust its communication schedule accordingly.

[0229] The A-IoT device will send its charging status based on the following conditions:

[0230] Wake-up signal received: The device sends its charging status in response to a wake-up signal from the gNB or UE reader. This signal causes the device to wake up from a low-power state and prepare for communication.

[0231] Insufficient energy for communication: If the device’s energy level is too low for backscatter communication, it can send its charging status to inform the gNB or UE reader that more time is needed to charge.

[0232] Charging status changes: If the charging status changes, for example when it starts charging or is fully charged, the device can send its charging status to inform the gNB or UE reader of this change.

[0233] If A-IoT sends charging status:

[0234] Early termination of protocol: Charging status is sent as early termination of the protocol. The A-IoT device signals to the gNB that it needs more time to charge. It does not continue with the protocol, such as sending its EPC.

[0235] Continue charging: After sending the charging status, the A-IoT device continues to harvest energy and charge its battery until a sufficient charge level is reached.

[0236] If A-IoT does not send charging status:

[0237] Completing the protocol: If the A-IoT device does not send its charging status, this indicates that it has enough charge to communicate. It continues with the protocol, including waiting for an acknowledgement (ACK) from the gNB.

[0238] Send EPC: After receiving the ACK, the A-IoT device sends its EPC to the gNB.

[0239] Prepare for further communication: After sending the EPC, the A-IoT device prepares for further communication, such as data exchange with the gNB.

[0240] The charging status usually includes the following information:

[0241] Charging Status: This indicates whether the device is currently charging, fully charged, or not charging.

[0242] Battery Level: This represents the current charge of the device's battery or energy storage.

[0243] Time to Full Charge: If the device is currently charging, this provides an estimate of how long it will take to reach full charge.

[0244] To provide a concrete example, the state of charge can be represented as a binary string divided into different parts. Each part represents a different aspect of the charge state:

[0245] Charging status (2 bits): 00 means not charging, 01 means charging, and 10 means fully charged.

[0246] Battery level (6 bits): Binary representation of the battery level, expressed as a percentage, where 000000 represents 0% and 111111 represents 100%.

[0247] Time required to fully charge (8 bits): Binary representation of the time required to fully charge in minutes, where 00000000 represents 0 minutes and 11111111 represents 255 minutes.

[0248] A typical charging status might look something like this: 0110010110101110. Here, 01 means the device is charging, 100101 means the battery level is 37%, and 10101110 means the estimated time to fully charge is 174 minutes.

[0249] After receiving the charging status, the gNB or UE reader may take the following actions:

[0250] Adjust communication schedule: Based on the received charging status, the gNB or UE reader can adjust its communication schedule. For example, if the charging status indicates that the A-IoT device needs another 30 minutes to be fully charged, the gNB can reschedule further communication with the device to 30 minutes later, thereby improving the efficiency of the communication process.

[0251] Confirmation of Receipt: The gNB or UE reader can send a confirmation message to the A-IoT device to confirm the receipt of the charging status and, if applicable, initiate further communication.

[0252] Monitoring A-IoT devices: If the charging status information indicates that the device is still charging, the gNB or UE reader may continue to monitor the signal of the A-IoT device. This allows the gNB to be ready for communication once the device is fully charged.

[0253] Perform other tasks: If the charging status information indicates that the A-IoT device needs more time to charge, the gNB or UE reader may switch to perform other tasks, such as communicating with other A-IoT devices that are ready to communicate or processing received data.

[0254] These examples illustrate how a gNB or UE reader can adapt its behavior based on the charging status information received from an A-IoT device. However, the specific reaction will depend on the specific implementation of the communication protocol and the characteristics of the gNB or UE reader.

[0255] Scheduled query commands

[0256] The gNB or UE reader can schedule its query commands based on the known charging time of the A-IoT device. This solution is feasible but requires the gNB or UE reader to effectively manage the communication schedule. It minimizes the possibility that the gNB or UE reader attempts to communicate with an A-IoT device that is still charging.

[0257] Example 1: Scheduling based on charging time

[0258] Assume that the gNB has a list of A-IoT devices with their corresponding power-on and charging times. For example, A-IoT device 1 has a power-on time of 0.5 ms and takes 1262 ms to charge via RF, while A-IoT device 2 has a power-on time of 5 ms and takes 12619 ms to charge via RF. The gNB can schedule its query command to communicate with device 1 after 1262 ms and with device 2 after 12619 ms. This ensures that the communication attempt is consistent with the device's ready state, thereby improving the efficiency of the communication process.

[0259] Example 2: Adjusting the schedule based on the charging status

[0260] In another scenario, the gNB receives a shorter charging status message from the A-IoT device indicating that the device requires 25238 milliseconds (assuming the device is powered on for 10 milliseconds and is charging via RF) to fully charge. The gNB can adjust its communication schedule and postpone the next query command to the device by 25238 milliseconds. This allows the device enough time to charge while ensuring that the gNB does not attempt to communicate with a device that is still charging.

[0261] These examples illustrate how a gNB or UE reader can adjust its communication schedule based on the known charging time of an A-IoT device. The exact schedule will depend on the specific implementation of the communication protocol and the characteristics of the A-IoT device.

[0262] The query command to implement the schedule based on the known charging time can be incorporated into the modified process as follows:

[0263] 11(A) is a timing diagram 1100 depicting a modified 4-step RACH procedure for a scheduled query command. In the modified 4-step RACH procedure, a gNB or UE reader may schedule its DL signal based on the known charging time of an A-IoT device.

[0264] 11(B) is a timing diagram 1120 depicting a modified 2-step RACH procedure for a scheduled query command. In the modified 2-step RACH procedure, the gNB or UE reader can schedule its DL signal and RN16 based on the known charging time of the A-IoT device.

[0265] 11(C) is a timing diagram 1140 describing a modified RACH procedure for a scheduled query command, where the UE acts as a tag reader. In the modified RACH procedure, the UE reader can schedule its preamble based on the known charging time of the A-IoT device.

[0266] 11(D) is a timing diagram 1160 describing a modified side chain process with respect to a scheduled query command. In the modified side chain process, the UE reader may schedule its discovery signal based on the charging time of the known A-IoT device.

[0267] In all of these processes, the gNB or UE reader needs to be modified to extract the charging status from the shorter charging status message and adjust its communication schedule accordingly. The gNB or UE reader also needs to manage its communication schedule based on the known charging time of the A-IoT device.

[0268] Adaptive ACK Timing

[0269] The gNB or UE reader can adjust the timing of its ACK based on the charging status of the A-IoT device. This solution is feasible but requires the gNB or UE reader to have the ability to adjust its signal timing. It enables the gNB or UE reader to postpone further communication with an A-IoT device that needs more charging time.

[0270] Example 1: Adjust ACK timing based on charging status

[0271] Consider an A-IoT device that is being charged and sends a short charging status message to the gNB indicating that it will take 1262 milliseconds (corresponding to a device with a power-on time of 0.5 milliseconds to charge via RF) to fully charge. Upon receiving this message, the gNB can adjust the timing of its ACK so that it is sent 1262 milliseconds later. This ensures that the ACK is sent when the device is ready for further communication, thereby increasing the efficiency of the communication process.

[0272] Example 2: Deferring communication based on charging status

[0273] In another scenario, the gNB receives a shorter charging status message from the A-IoT device indicating that it requires 25238 milliseconds (corresponding to a device with a 10 millisecond power-on time to charge via RF) to fully charge. The gNB can defer the next ACK to the device by 25238 milliseconds. This provides the device with sufficient time to charge while ensuring that the gNB does not attempt to communicate with a device that is still charging.

[0274] These examples illustrate how a gNB or UE reader can adjust the timing of its ACKs based on the charge state of the A-IoT device. The exact timing will depend on the specific implementation of the communication protocol and the characteristics of the A-IoT device. However, successful implementation of this strategy requires the gNB or UE reader to have the ability to dynamically adjust its signal timing.

[0275] Implementing adaptive ACK timing based on charge state can be incorporated into the modified process as follows:

[0276] 12(A) is a timing diagram 1200 illustrating a modified 4-step RACH procedure with adaptive ACK timing. In the modified 4-step RACH procedure, a gNB or UE reader may adjust the timing of its ACK signal based on the charging status information received from an A-IoT device.

[0277] 12(B) is a timing diagram 1220 depicting a modified 2-step RACH procedure with adaptive ACK timing. In the modified 2-step RACH procedure, the gNB or UE reader may adjust the timing of its ACK signal based on the charging status information received from the A-IoT device.

[0278] 12(C) is a timing diagram 1240 depicting a modified RACH procedure with adaptive ACK timing when a UE acts as a tag reader. In the modified RACH procedure when the UE acts as a tag reader, the UE reader may adjust the timing of its ACK signal based on the charging status information received from the A-IoT device.

[0279] 12(D) is a timing diagram 1260 depicting a modified side chain process with adaptive ACK timing. In the modified side chain process, the UE reader may adjust the timing of its ACK signal based on the charging status information received from the A-IoT device.

[0280] In all these processes, the gNB or UE reader needs to be modified to extract the charging status from the shorter charging status message and adjust the timing of its ACK signal accordingly. The gNB or UE reader also needs to manage its communication schedule according to the charging status of the A-IoT device.

[0281] Charge status in EPC

[0282] The A-IoT device can include its charging status in the EPC signal it sends to the gNB or UE reader. This solution is moderately feasible and requires changes to the signal generation of the A-IoT device. It allows the gNB or UE reader to know the charging status of the A-IoT device immediately upon receiving the EPC.

[0283] Another possible solution is to incorporate the charging status of the A-IoT device into the EPC signal it sends to the gNB or UE reader. This strategy, while moderately feasible, requires changes to the signal generation process of the A-IoT device. It enables the gNB or UE reader to understand the charging status of the A-IoT device immediately upon receiving the EPC.

[0284] Example 1: Charge status in EPC signal

[0285] Consider an A-IoT device that is currently being charged and needs to send an EPC signal to the gNB. The device includes its charging status in the EPC signal, indicating that it will take 1262 milliseconds (corresponding to a device with a power-on time of 0.5 milliseconds to charge via RF) to fully charge. After receiving this EPC signal, the gNB can understand the charging status of the device and adjust its communication schedule accordingly.

[0286] Example 2: Adjusting communications based on EPC signals

[0287] In another scenario, the gNB receives an EPC signal from an A-IoT device that contains a charging status indicating that it will take 25238 milliseconds (corresponding to a device with a 10 millisecond power-on time charging via RF) to fully charge. The gNB can defer the next communication with the device for 25238 milliseconds. This allows the device sufficient time to charge while ensuring that the gNB does not attempt to communicate with a device that is still charging.

[0288] These examples illustrate that including the charge status in the EPC signal can allow a gNB or UE reader to adjust its communication schedule based on the charge status of the A-IoT device. The specific implementation will depend on the specific changes made to the signal generation process of the A-IoT device.

[0289] The implementation of incorporating the state of charge into the EPC signal can be incorporated into the modified process as follows:

[0290] 13(A) is a timing diagram 1300 depicting a modified 4-step RACH procedure with respect to charging status in the EPC. In the modified 4-step RACH procedure, the A-IoT device may include its charging status in the EPC signal in its response to a DL signal from a gNB or UE reader.

[0291] 13(B) is a timing diagram 1320 depicting a modified 2-step RACH procedure with respect to charging status in the EPC. In the modified 2-step RACH procedure, the A-IoT device may include its charging status in the EPC signal in its response to the DL signal and RN16 from the gNB or UE reader.

[0292] 13(C) is a timing diagram 1340 depicting a modified RACH procedure with respect to charging status in the EPC when a UE acts as a tag reader. In the modified RACH procedure with the UE acting as a tag reader, the A-IoT device may include its charging status in the EPC signal in its response to the preamble from the UE reader.

[0293] 13(D) is a timing diagram 1360 depicting a modified side chain process regarding charging status in the EPC. In the modified side chain process, the A-IoT device may include its charging status in the EPC signal in its response to the discovery signal from the UE reader.

[0294] In all of these processes, the gNB or UE reader needs to be modified to extract the charging status from the EPC signal and adjust its communication schedule accordingly. The A-IoT device also needs to be modified to include its charging status in the EPC signal it sends.

[0295] Multiple RN16 signals

[0296] If an A-IoT device needs more charging time, it can send multiple RN16 signals in quick succession. This solution is moderately feasible but can result in signal collisions if not managed properly. It clearly indicates to the gNB or UE reader that the A-IoT device needs more charging time.

[0297] Example 1: Sending multiple RN16 signals

[0298] Consider an A-IoT device that is charging and needs more time to fully charge. Instead of sending a single RN16 signal, the device sends multiple RN16 signals in quick succession. The gNB, upon receiving these signals, can understand that the device needs more charging time. Therefore, the gNB can adjust its communication schedule to provide more charging time to the device.

[0299] Assume that this device has a power-up time of 0.5 milliseconds, so, based on the table provided earlier, it will require 1262 milliseconds to charge via RF. To indicate this, the device sends multiple RN16 signals in rapid succession. Upon receiving these signals, the gNB understands that the device will require approximately 1262 milliseconds of additional charging time. Therefore, the gNB can adjust its communication schedule to provide the device with this additional charging time.

[0300] Example 2: Managing signal conflicts

[0301] In another scenario, multiple A-IoT devices in the network are low on power and send multiple RN16 signals in rapid succession. The gNB or UE reader needs to carefully manage these signals to avoid signal collisions. This can be achieved by implementing collision avoidance strategies such as random backoff, where each A-IoT device waits a random amount of time before resending its RN16 signal.

[0302] Assume that one device has a power-on time of 5 ms and takes 12619 ms to charge via RF, and another device has a power-on time of 10 ms and takes 25238 ms to charge via RF. Both devices send multiple RN16 signals in rapid succession to indicate their charging times. The gNB or UE reader needs to manage these signals carefully to avoid signal collisions. This can be achieved by implementing a collision avoidance strategy, such as random backoff, where each A-IoT device waits a random amount of time before resending its RN16 signal.

[0303] These examples illustrate how an A-IoT device can use multiple RN16 signals to indicate that more charging time is needed. The specific implementation will depend on the specific characteristics of the A-IoT device and the strategy implemented by the gNB or UE reader to manage potential signal conflicts.

[0304] Implementing the transmission of multiple RN16 signals to indicate extended charging time can be incorporated into the modified process as follows:

[0305] 14(A) is a timing diagram 1400 depicting a modified 4-step RACH procedure with respect to multiple RN16 signals. In the modified 4-step RACH procedure, an A-IoT device may send multiple RN16 signals in rapid succession in response to a DL signal from a gNB or UE reader.

[0306] 14(B) is a timing diagram 1420 depicting a modified 2-step RACH procedure with respect to multiple RN16 signals. In the modified 2-step RACH procedure, the A-IoT device may send multiple RN16 signals in rapid succession in response to a DL signal and RN16 from a gNB or UE reader.

[0307] 14(C) is a timing diagram 1440 describing a modified RACH process for multiple RN16 signals when the UE acts as a tag reader. In the modified RACH process, the UE acts as a tag reader, and the A-IoT device can send multiple RN16 signals in rapid succession in response to the preamble from the UE reader.

[0308] 14(D) is a timing diagram 1460 describing a modified side chain process with respect to multiple RN16 signals. In the modified side chain process, the A-IoT device may send multiple RN16 signals in quick succession in response to a discovery signal from a UE reader.

[0309] In all of these processes, the gNB or UE reader needs to be modified to infer the charging status from multiple RN16 signals and adjust its communication schedule accordingly. The A-IoT device also needs to be modified to send multiple RN16 signals when more charging time is needed.

[0310] Charge state backscatter

[0311] The A-IoT device can backscatter a specific signal pattern to the gNB or UE reader to indicate its charging status. This solution is moderately feasible but requires changes to the backscatter capabilities of the A-IoT device. It provides a way for the A-IoT device to communicate its charging status directly to the gNB or UE reader.

[0312] Example 1: Backscattered charge status

[0313] Consider an A-IoT device that is charging and needs to communicate its charging status to the gNB. Instead of sending a regular signal, the device backscatters a specific signal pattern that represents its charging status. Upon receiving this backscattered signal, the gNB can decode the pattern and understand the charging status of the device.

[0314] Example 2: Modifying backscatter capabilities

[0315] In another case, an A-IoT device is designed with enhanced backscatter capabilities, enabling it to backscatter different signal patterns corresponding to different charging states. For example, a certain pattern may indicate that the device is fully charged, while another pattern may indicate that the device needs more charging time. This enables the device to efficiently communicate its charging status directly to the gNB or UE reader.

[0316] Data transmission delay

[0317] The gNB or UE reader can delay data transmission with the A-IoT device until the device is fully charged. This solution is moderately feasible but requires the gNB or UE reader to effectively manage its data transmission schedule. It ensures that the A-IoT device has enough energy for data transmission.

[0318] Example 1: Delayed data transfer

[0319] Consider an A-IoT device that is charging and needs to transmit data to the gNB. Instead of initiating the data transmission immediately, the gNB waits until the device is fully charged before transmitting. This ensures that the device has enough energy for the data transmission, preventing potential energy depletion in the process.

[0320] Assume that this device has a power-up time of 0.5 milliseconds, so, according to the table provided earlier, it takes 1262 milliseconds to charge via RF. After receiving the communication request from the device, the gNB will delay data transmission until the device is fully charged. This means that the gNB will wait for approximately 1262 milliseconds before initiating data transmission. This ensures that the device has enough energy for data transmission, thereby preventing potential energy depletion in the process.

[0321] Example 2: Managing Data Transfer Schedules

[0322] In another scenario, the gNB effectively manages its data transmission schedule to ensure efficient communication with multiple A-IoT devices. For example, the gNB can prioritize data transmission with devices that are fully charged and delay transmission with devices that are still charging. This allows the gNB to ensure efficient data transmission while ensuring that the devices are fully charged.

[0323] Assume that a device with a 5 ms power-on time takes 12619 ms to charge via RF, while another device with a 10 ms power-on time takes 25238 ms. The gNB can schedule data transmission with the first device to occur after 12619 ms and data transmission with the second device to occur after 25238 ms. This allows the gNB to ensure efficient data transmission while ensuring that the devices are fully charged.

[0324] These examples illustrate that delaying data transmission until the A-IoT device is fully charged can ensure efficient communication. The specific implementation will depend on the specific strategy adopted by the gNB or UE reader to manage its data transmission schedule. However, successfully implementing this strategy requires comprehensive understanding of the charging status of the A-IoT device and the ability to effectively manage the data transmission schedule.

[0325] Delaying data transfer until the A-IoT device is fully charged can be incorporated into the modified process as follows:

[0326] 15(A) is a timing diagram 1500 illustrating a modified 4-step RACH procedure for delayed data transmission. In the modified 4-step RACH procedure, a gNB or UE reader may delay data transmission with an A-IoT device until it is fully charged.

[0327] 15(B) is a timing diagram 1520 depicting a modified 2-step RACH procedure with respect to delayed data transmission. In the modified 2-step RACH procedure, the gNB or UE reader may delay data transmission with the A-IoT device until it is fully charged.

[0328] 15(C) is a timing diagram 1540 depicting a modified RACH procedure for delayed data transmission when the UE acts as a tag reader. In the modified RACH procedure when the UE acts as a tag reader, the UE reader may delay data transmission with the A-IoT device until it is fully charged.

[0329] 15(D) is a timing diagram 1560 depicting a modified sidelink process with respect to delayed data transmission. In the modified sidelink process, the UE reader may delay data transmission with the A-IoT device until it is fully charged.

[0330] In all of these processes, the gNB or UE reader needs to be modified to receive the charging status and delay the data transmission until the A-IoT device is fully charged. The A-IoT device also needs to be modified to send its charging status while it is still charging.

[0331] Energy Efficiency Agreement

[0332] Implementing energy-efficient protocols in RFID systems can significantly reduce the energy consumption of each tag. For example, strategies such as the Tag-Ordering Polling Protocol (TOP) can minimize the energy consumption during polling by organizing the tags in an optimal order. This approach allows a trade-off between energy and time, where the energy consumption of each tag is reduced at the expense of longer protocol execution time. The feasibility of this solution may be low due to the need for significant changes in the protocol design.

[0333] Example 1: Implementing TOP

[0334] Consider an RFID system with multiple A-IoT devices that need to communicate with a gNB or UE reader. By implementing TOP, the gNB or UE reader organizes the tags in an optimal order, allowing the devices to communicate in a more energy-efficient manner. This reduces the energy consumption of each tag, thereby reducing the charging time of the A-IoT device.

[0335] Consider an RFID system with 100 A-IoT devices that need to communicate with a gNB or UE reader. Without energy efficiency protocols, assume that each device consumes 10 microwatts of power when communicating. Therefore, the total power consumption is 1000 microwatts.

[0336] By implementing TOP, the gNB or UE reader organizes the tags in the best order, potentially reducing the power consumption of each tag by 20%. This means that each device now consumes only 8 microwatts of power when communicating, reducing the total power consumption to 800 microwatts. A 20% reduction in power consumption per tag results in a significant reduction in the charging time of A-IoT devices.

[0337] Example 2: Balancing the energy and time trade-off

[0338] In another case, RFID systems are designed to balance the trade-off between energy and time. By implementing an energy-efficient protocol such as TOP, the system can minimize the energy consumption of each tag, although this will increase the cost of protocol execution time. This allows the system to maintain energy efficiency while ensuring that A-IoT devices have enough energy to communicate.

[0339] By implementing an energy-efficient protocol such as TOP, the system can minimize the power consumption of each tag to 8 microwatts, as shown in the previous example. However, this comes at the cost of increasing the protocol execution time. Assume that the protocol execution time increases by 30% due to more energy-efficient communication. Despite the longer execution time, the system maintains energy efficiency while ensuring that the A-IoT devices have enough power for communication.

[0340] The process by which a gNB or UE reader determines the order in which to communicate with A-IoT devices to minimize overall energy consumption can be achieved through various strategies, such as prioritizing devices based on their charge state, distance from the reader, or data communication needs. Here are some examples:

[0341] Example 1: Prioritize based on charging status

[0342] The gNB or UE reader can prioritize communication with devices that are fully charged or nearly fully charged. This will allow these devices to communicate efficiently while using minimal additional energy. Devices that are still charging are positioned lower in the order, allowing them more time to charge before communicating.

[0343] Example 2: Distance-based priority

[0344] The gNB or UE reader can also prioritize devices based on their distance from the reader. Devices that are closer to the reader generally require less energy to communicate, so prioritizing these devices minimizes overall energy consumption. Devices that are farther away and require more energy to communicate are placed lower in the order.

[0345] Example 3: Prioritize based on data communication needs

[0346] The gNB or UE reader can also consider the data communication needs of the devices when determining the optimal order. Devices with smaller data packets and less energy required to transmit can be prioritized. Devices with larger data packets and more energy required to transmit are lower in the order.

[0347] In all of these strategies, the goal is to minimize the overall energy consumption of the system by optimizing the communication sequence of the devices. The specific implementation will depend on the specific characteristics of the device and the strategy adopted by the gNB or UE reader.

[0348] TOP can coexist with the Aloha protocol in RFID systems. The Aloha protocol, especially SlottedAloha, is commonly used for tag identification in RFID systems. However, when multiple tags respond at the same time, it may cause collisions.

[0349] TOP can be integrated with the Aloha protocol to reduce collisions and improve energy efficiency. Here is how to do it:

[0350] Step 1: Initial Identification Using Aloha

[0351] The gNB or UE reader uses the time-sharing Aloha protocol for initial tag identification. During this process, each A-IoT device randomly selects a time slot to avoid collision.

[0352] Step 2: Use TOP to sort the tags

[0353] After the initial identification is complete, the gNB or UE reader uses TOP to sort the tags according to criteria such as charging status, distance or data communication needs. The gNB or UE reader then communicates with the tags according to this order.

[0354] Step 3: Communicate with the sorted tags

[0355] The gNB or UE reader communicates with the A-IoT devices according to the order determined in step 2. Since the order is known, the devices do not need to randomly select the time slots to respond, which reduces the chance of collision and improves energy efficiency.

[0356] Step 4: Repeat the process

[0357] This process repeats periodically to update the tag order and adapt to new tags or changes in the status of existing tags.

[0358] By integrating TOP with the Aloha protocol, RFID systems can maintain the tag identification advantages provided by Aloha while improving energy efficiency and reducing collisions through TOP. This coexistence allows for efficient management of multiple A-IoT devices and ensures effective communication with each device.

[0359] Implementing an energy-saving protocol like TOP during the modification process can be done as follows:

[0360] 16(A) is a timing diagram 1600 depicting a modified 4-step RACH procedure for the power saving protocol. In the modified 4-step RACH procedure, the gNB or UE reader may use TOP to sort the A-IoT devices according to their charging status before initiating communication.

[0361] 16(B) is a timing diagram 1620 depicting a modified 2-step RACH procedure with respect to the power saving protocol. In the modified 2-step RACH procedure, the gNB or UE reader may use TOP to sort the A-IoT devices according to their charging status before initiating communication.

[0362] 16(C) is a timing diagram 1640 depicting a modified RACH procedure for the power saving protocol, where the UE acts as a tag reader. In the modified RACH procedure where the UE acts as a tag reader, the UE reader may use TOP to sort the A-IoT devices according to their charging status before initiating communication.

[0363] 16(D) is a timing diagram 1660 describing a modified side chain process with respect to the energy saving protocol. In the modified side chain process, the UE reader may use TOP to sort the A-IoT devices according to their charging status before initiating communication.

[0364] In all these processes, the gNB or UE reader needs to be modified to implement the Aloha protocol for initial identification and TOP sorting of the A-IoT device. The A-IoT device also needs to be modified to respond to the Aloha protocol and communicate its charging status.

[0365] In a first aspect, a UE includes:

[0366] one or more non-transitory computer-readable media having computer-executable instructions embedded therein, and at least one processor coupled to the one or more non-transitory computer-readable media and configured to execute the computer-executable instructions to:

[0367] A DL signal is received from a base station (BS) if the UE is in a state ready for communication.

[0368] Determines a unique, shorter signal representing its charging status if a DL signal is received. The charging status is represented as a binary string of a specific length, with each bit or group of bits representing a different aspect of the charging status, such as charging status, battery level, and estimated time to full charge.

[0369] If a DL signal is received, a modification of the 4-step RACH procedure is performed. The modification involves sending a shorter charge status message instead of RN16 after receiving a DL signal from the BS.

[0370] If the charging status is determined, a shorter charging status message is transmitted to the BS in response to the DL signal.

[0371] In a second aspect, a UE includes:

[0372] one or more non-transitory computer-readable media having computer-executable instructions embedded therein, and at least one processor coupled to the one or more non-transitory computer-readable media and configured to execute the computer-executable instructions to:

[0373] A wake-up signal is received from a base station (BS), indicating that the device is ready for further communication.

[0374] Determines a unique, shorter signal representing its charging status if a wake-up signal is received. The charging status can be represented as an 8-bit binary string divided into different parts: charging status, battery level and time required to fully charge.

[0375] If a charging status message is received, a modification of the communication schedule is performed. The modification involves adjusting the communication schedule according to the received charging status message.

[0376] If the charging status is determined, a shorter charging status message is transmitted to the BS in response to the wake-up signal from the BS. This approach allows efficient communication while ensuring accurate communication of the energy status of the A-IoT device.

[0377] Fig.17 An example communication system 1700 consistent with an embodiment of the present invention is shown, which includes an example communication device 1710 and an example network device 1720. The communication device 1710 and the network device 1720 can perform various functions to implement the schemes, techniques, processes and methods described herein for network energy saving using on-demand reference signals for UE and network devices in mobile communications, including the scenarios / schemes described above and the processes 1800 and 1900 described below.

[0378] The communication device 1710 may be part of an electronic device, which may be a UE, such as a portable or mobile device, a wearable device, a wireless communication device, or a computing device. For example, the communication device 1710 may be implemented in a smartphone, a smart watch, a personal digital assistant, a digital camera, or a computing device such as a tablet, a laptop, or a notebook computer. The communication device 1710 may also be part of a machine-type device, which may be an Internet of Things (IoT), a Narrowband Internet of Things (NB-IoT), or an Industrial Internet of Things (IIoT) device, such as a fixed or static device, a home device, a wired communication device, or a computing device. For example, the communication device 1710 may be implemented in a smart thermostat, a smart refrigerator, a smart door lock, a wireless speaker, or a home control center. Alternatively, the communication device 1710 may be implemented in the form of one or more integrated circuit (IC) chips, such as, but not limited to, one or more single-core processors, one or more multi-core processors, one or more reduced-instruction set computing (RISC) processors, or one or more complex-instruction-set-computing (CISC) processors. The communication device 1710 may include Fig.17 The communication device 1710 may also include one or more other components not related to the solution proposed by the present invention (e.g., an internal power supply, a display device, and / or a user interface device). Therefore, for the sake of simplicity, these components of the communication device 1710 are not shown in FIG. Fig.17 It is not shown in the figure and is not described below.

[0379] The network device 1720 may be part of a network device, which may be a network node, such as a satellite, a base station, a small base station, a router, or a gateway. For example, the network device 1720 may be implemented in an eNodeB in an LTE network, a gNB in ​​a 5G / NR, IoT, NB-IoT, or IIoT network, or a satellite or base station in a 6G network. Alternatively, the network device 1720 may be implemented in the form of one or more IC chips, such as, but not limited to, one or more single-core processors, one or more multi-core processors, or one or more RISC or CISC processors. The network device 1720 may include Fig.17 1720, such as processor 1722. Network device 1720 may also include one or more other components not related to the solution proposed by the present invention (e.g., internal power supply, display device and / or user interface device), so for the sake of simplicity, these components of network device 1720 are not shown in FIG. Fig.17 It is not shown in the figure and is not described below.

[0380] In one aspect, processor 1712 and processor 1722 may be implemented in the form of one or more single-core processors, one or more multi-core processors, or one or more CISC processors. That is, although the singular term "a processor" may be used in the present invention to refer to processor 1712 and processor 1722, in certain embodiments according to the present invention, processor 1712 and processor 1722 may include multiple processors, while in other embodiments, processor 1712 and processor 1722 may include a single processor. In another aspect, processor 1712 and processor 1722 may be implemented in the form of hardware (and, optionally, firmware), including, for example, but not limited to, one or more transistors, one or more diodes, one or more capacitors, one or more resistors, one or more inductors, one or more memristors, and / or one or more variable capacitors, these electronic components are configured and arranged to achieve specific purposes according to the present invention. In other words, in at least some embodiments, processor 1712 and processor 1722 are special-purpose machines specifically designed, arranged, and configured to perform specific tasks in accordance with various embodiments of the present invention, including autonomous reliability enhancement in devices (e.g., as represented by communication device 1710) and networks (e.g., as represented by network device 1720).

[0381] In some embodiments, the communication device 1710 may also include a transceiver 1716 coupled to the processor 1712, capable of wirelessly transmitting and receiving data. In some embodiments, the communication device 1710 may also include a memory 1714 coupled to the processor 1712, capable of being accessed by the processor 1712 and storing data therein. In some embodiments, the network device 1720 may also include a transceiver 1726 coupled to the processor 1722, capable of wirelessly transmitting and receiving data. In some embodiments, the network device 1720 may also include a memory 1724 coupled to the processor 1722, capable of being accessed by the processor 1722 and storing data therein. Therefore, the communication device 1710 and the network device 1720 may perform wireless communication via the transceiver 1716 and the transceiver 1726, respectively. For better understanding, the following description of the operations, functions and capabilities of the communication device 1710 and the network device 1720 is provided in a mobile communication environment where the communication device 1710 is implemented as or as a communication device or UE and the network device 1720 is implemented as or as a network node of a communication network.

[0382] 18(A) is a flow chart 1800 of processing regarding charging time of a reader device and an A-IoT device. This process involves interaction between a gNB, a UE (e.g., UE 744), and an A-IoT device (e.g., A-IoT device 746).

[0383] In step 1802, the reader device may send a communication initiation signal to the A-IoT device. The reader device may be a UE 744 or a gNB.

[0384] Then, at step 1804, a reader device such as UE 744 may receive charging status information from the A-IoT device.

[0385] Finally, at step 1806, the reader device may adjust behavior based on the charging status information.

[0386] In some embodiments, the charging status information may be included in the RN16 received from the A-IoT device, or in a charging status message that is shorter than the RN16.

[0387] In some embodiments, the communication initiation signal may include a downlink signal, and the process may further include: sending RN16 to the A-IoT device together with the downlink signal. In some embodiments, the downlink signal may include one of the following: PSS, SSS, or LP-WUS.

[0388] In some embodiments, the communication initiation signal may include a RACH preamble, and the process may further include: monitoring RN16 or a charging status message on a PUSCH.

[0389] In some embodiments, the communication initiation signal may include a discovery signal on a physical sidelink control channel (PSCCH), and the process may further include: listening to RN16 or a charging status message on a physical sidelink shared channel (PSSCH).

[0390] In some embodiments, the charging status message may include a binary string that includes multiple parts, each of which is used to indicate: charging status, indicating whether the A-IoT device is currently charging, fully charged, or not charging; battery level, representing the current charge of the battery or energy storage of the A-IoT device; and time required to fully charge. In some embodiments, RN16 includes multiple bits that indicate the charging status, battery level, and time required to fully charge.

[0391] In some embodiments, the adjustment behavior may include at least one of: adjusting the communication schedule; sending a confirmation message to the A-IoT device to confirm receipt of the charging status information; initiating further communication; monitoring signals from the A-IoT device; or performing other tasks.

[0392] FIG. 18(B) is another flow chart 1850 for processing regarding charging time of a reader device and an A-IoT device.

[0393] At step 1852, an A-IoT device, such as A-IoT device 746, may receive a communication initiation signal from a reader device. The reader device may be a UE (e.g., UE 744) or a gNB.

[0394] Then, at step 1854, the A-IoT device 746 may determine the charging status of the A-IoT device.

[0395] Finally, at step 1856, the A-IoT device 746 may send charging status information to the reader device.

[0396] In some embodiments, the charging status information may be included in the RN16, or in a charging status message that is shorter than the RN16.

[0397] In some embodiments, when the energy level of the A-IoT device is insufficient for backscatter communication, the A-IoT device may send a charging status message; when the energy level is sufficient for backscatter communication, the A-IoT device may send RN16.

[0398] In some embodiments, when the charging status of the A-IoT device changes, the A-IoT device may send a charging status message; when the charging status of the A-IoT device does not change, the A-IoT device may send RN16.

[0399] In some embodiments, the communication initiation signal may include a downlink signal received from the reader device along with the RN 16. In some embodiments, the downlink signal may include one of the following: PSS, SSS, or LP-WUS.

[0400] In some embodiments, the communication initiation signal may include a RACH preamble, and the process may further include: monitoring the preamble on the PRACH; generating a charging status message or incorporating the charging status information into the RN16.

[0401] In some embodiments, the communication initiation signal may include a discovery signal received on the PSCCH, and the process may further include: monitoring the discovery signal on the PSCCH; generating a charging status message or incorporating the charging status information into the RN16.

[0402] In certain embodiments, the A-IoT device may send the RN16 or charging status message via backscatter communication using ASK or OOK modulation.

[0403] In some embodiments, the charging status message may include a binary string comprising multiple parts, each part being used to indicate: the charging status, indicating whether the A-IoT device is currently charging, fully charged, or not charging; the battery level, representing the current level of the battery or energy storage of the A-IoT device; and the time required to be fully charged; and RN16 includes multiple bits, respectively indicating the charging status, battery level, and time required to be fully charged.

[0404] It is understood that the specific order or hierarchy of blocks in the process / flowchart of the present invention is an example of an exemplary method. It should therefore be understood that the specific order or hierarchy of blocks in the process / flowchart can be rearranged based on design preferences, and some blocks can be further combined or omitted. The attached method claims the elements presented by the various blocks in an exemplary order, but this does not mean that the present invention is limited to the specific order or hierarchy presented.

[0405] The previous description is provided to enable those skilled in the art to realize the various aspects described in the present invention. Those skilled in the art can easily make various modifications to these aspects, and can apply the general principles defined in the present invention to other aspects. Therefore, the claims are not intended to be limited to the aspects shown in the present invention, but should be given the full scope consistent with the claim language description. Wherein, unless otherwise specified, it is not intended to mean "one and only one" when referring to the singular element, but to mean "one or more". The word "exemplary" is used in the present invention to refer to "used as an example, example or illustration". Any aspect of the present invention described as "exemplary" is not necessarily understood to be preferred or advantageous over other aspects. Unless otherwise specified, the term "some" refers to one or more. Combinations such as "at least one of A, B or C", "one or more of A, B or C", "at least one of A, B and C", "one or more of A, B and C" and "A, B, C or any combination thereof" include any combination of A, B and / or C, and may include multiple A, multiple B, or multiple C. Specifically, combinations such as "at least one of A, B, or C," "one or more of A, B, or C," "at least one of A, B and C," "one or more of A, B, and C," and "A, B, C, or any combination thereof" may include only A, only B, only C, A and B, A and C, B and C, or A, B, and C, any of which may include one or more of A, B, or C. All structural and functional equivalents of the elements of the various aspects described in the present invention that are known or will become known to those skilled in the art may be expressly included in the present invention by reference and are intended to be covered by the claims. In addition, the content disclosed in the present invention is not intended to be donated to the public, regardless of whether such disclosure is explicitly stated in the claims. The words "module," "mechanism," "element," "device," etc. may not be substitutes for the word "means." Thus, unless an element in a claim is explicitly stated using the phrase "means for...", the element should not be understood as a functional limitation (means plus function).

Claims

1. A method for wireless communication, performed by a reader device, the method comprising: Sending a communication initiation signal to the environmental IoT device; receiving charging status information from the ambient IoT device; as well as Behavior is adjusted based on this charging status information.

2. The method for wireless communication according to claim 1, wherein: The charging status information is included in a random 16-bit number RN16 received from the ambient IoT device, or in a charging status message shorter than the RN16.

3. The method for wireless communication according to claim 2, wherein: The communication initiation signal includes a downlink signal, and further includes: The RN16 is sent to the environmental IoT device together with the downlink signal.

4. The method for wireless communication according to claim 3, wherein: The downlink signal includes one of the following: Master synchronization signal; Auxiliary synchronization signal; or Low power wake-up signal.

5. The method for wireless communication according to claim 2, wherein: The communication initiation signal includes a random access channel preamble code, and the method further includes: The RN16 or the charging status message is monitored on the physical uplink shared channel.

6. The method for wireless communication according to claim 2, wherein: The communication initiation signal includes a discovery signal on a physical sidelink control channel, and the method further includes: Monitor the RN16 or the charging status message on the physical side link shared channel.

7. The method for wireless communication according to claim 2, wherein: The charging status message includes a binary string, which includes multiple parts, each part is used to indicate: Charging status, indicating whether the ambient IoT device is currently charging, fully charged, or not charging; Battery level, which represents the current charge of the battery or energy storage of the Ambient IoT Device; and The time required to fully charge the battery; and / or The RN16 includes a plurality of bits, which respectively indicate the charging status, the battery level and the time required for full charging.

8. The method for wireless communication according to claim 1, wherein: Adjusting this behavior includes at least one of the following: Adjust communication schedule; Sending a confirmation signal to the environmental IoT device to confirm receipt of the charging status information; Initiate further communications; Monitor signals from IoT devices in the environment; or Perform other tasks.

9. A method for wireless communication, performed by an ambient IoT device, the method comprising: receiving a communication initiation signal from a reader device; Determine the charging status of IoT devices in the environment; as well as Charging status information is sent to the reader device.

10. The method for wireless communication according to claim 9, wherein: The charging status information is contained in a random 16-bit number RN16, or in a charging status message shorter than RN16.

11. The method of claim 10, wherein: When the energy level of the ambient IoT device is insufficient for backscatter communication, the ambient IoT device sends the charging status message; and When the energy level is sufficient for backscatter communication, the ambient IoT device sends the RN16.

12. The method for wireless communication according to claim 10, wherein: When the charging state of the environmental Internet of Things device changes, the environmental Internet of Things device sends the charging state message; as well as When the charging status of the environmental IoT device does not change, the environmental IoT device sends the RN16.

13. The method for wireless communication according to claim 10, wherein: The communication initiation signal includes a downlink signal received from the reader device together with the RN 16 .

14. The method for wireless communication according to claim 13, wherein: The downlink signal includes one of the following: Master synchronization signal; Auxiliary synchronization signal; or Low power wake-up signal.

15. The method for wireless communication according to claim 10, wherein: The communication initiation signal includes a random access channel preamble code, and the method further includes: monitoring the preamble on a physical random access channel; and Generate the charging status message or incorporate the charging status information into the RN16.

16. The method for wireless communication according to claim 10, wherein: The communication initiation signal includes a discovery signal received on a physical sidelink control channel, and the method further includes: monitoring the discovery signal on the physical sidelink control channel; and Generate the charging status message or incorporate the charging status information into the RN16.

17. The method for wireless communication according to claim 10, wherein: The ambient IoT device sends the RN16 or the charging status message via backscatter communication using amplitude keying or on-off keying modulation.

18. The method for wireless communication according to claim 10, wherein: The charging status message contains a binary string, which contains multiple parts, each part is used to indicate: Charging status, indicating whether the ambient IoT device is currently charging, fully charged, or not charging; Battery level, which represents the current charge of the battery or energy storage of the Ambient IoT Device; and The time required to fully charge the battery; and / or The RN16 includes a plurality of bits, which respectively indicate the charging status, the battery level and the time required for full charging.

19. A device for wireless communication, comprising: A processor, the processor being configured to execute the method for wireless communication according to any one of claims 1 to 18.

20. A memory storing program instructions, wherein when the program instructions are executed by a processor, the processor executes the method for wireless communication according to any one of claims 1 to 18.

Images