Method and apparatus for wireless communication

Abstract

Methods and apparatus for wireless communication are provided. In one aspect, a method for wireless communication is performed by a reader device, the method comprising: transmitting a downlink signal and verification information to an environmental Internet of Things device; receiving a unique electronic product code from the environmental Internet of Things device after the environmental Internet of Things device verifies the verification information; and sending a confirmation message to the environmental Internet of Things device in response to successful reception of the electronic product code from the environmental Internet of Things device. 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 methods and systems for improving the communication range, power consumption, and charging time of Ambient Internet of Things (A-IoT) devices, user equipment (UE), and network devices in mobile communications. Background Art

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

[0003] Wireless communication systems can be widely deployed to provide various telecommunication services, such as telephony, video, data, messaging, and broadcasting. A typical wireless communication system may employ multiple-access techniques that can support communication with multiple users by sharing available system resources. Examples of multiple-access techniques 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 multi-access technologies have been adopted in various telecommunication standards to provide a common protocol that enables different wireless devices to communicate at the municipal, national, regional, or even global level. An example of a telecommunication standard is the 5th 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 can be based on the 4th Generation (4G) Long Term Evolution (LTE) standard. 5G NR technology requires further improvement, and these improvements may also be applicable to other multi-access technologies and telecommunication standards that employ these technologies. Summary of the Invention

[0005] The following presents a brief summary of one or more aspects in order to provide a basic understanding of these aspects. This Summary of the Invention is not an extensive overview of all contemplated aspects, nor is it intended to identify key or critical elements of all aspects or to delineate the scope of any or all aspects. The sole purpose of this Summary of the Invention is to present some concepts of one or more aspects in a simplified form as a prelude to the more detailed description that is presented below.

[0006] A method for wireless communication, performed by a reader device, the method comprising: sending a downlink signal and authentication information to an ambient Internet of Things (IoT) device; after the ambient IoT device authenticates the authentication information, receiving a unique electronic product code (EPC) from the ambient IoT device; and sending an acknowledgement message to the ambient IoT device in response to successfully receiving the electronic product code from the ambient IoT device.

[0007] A method for wireless communication, performed by an ambient IoT device, the method comprising: receiving a downlink signal and authentication information from a reader device; authenticating the authentication information; after authenticating the authentication information, sending a unique electronic product code to the reader device; and receiving an acknowledgement message including the electronic product code from the reader device.

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

[0009] To achieve the foregoing and related purposes, one or more aspects include the features that are fully described hereinafter and particularly pointed out in the claims. The following detailed description and the accompanying drawings set forth specific illustrative features of one or more aspects. However, these features are only some of the ways in which the principles of the various aspects may be employed, and the present invention is intended to embrace 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 an access network.

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

[0012] Figure 3 illustrates an exemplary logical architecture of a distributed access network.

[0013] Figure 4 illustrates an exemplary physical architecture of a distributed access network.

[0014] Figure 5 is a schematic diagram showing an exemplary DL-centric time slot.

[0015] Figure 6 is a schematic diagram showing an exemplary UL-centric time slot.

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

[0017] FIG. 7(B) is a schematic diagram showing an example communication link between a gNB and an A-IoT device through a wired cable connection with the UE.

[0018] FIG. 7(C) is a schematic diagram showing an example communication link between a gNB and an A-IoT device through a wireless air interface connection with the UE.

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

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

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

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

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

[0024] Figure 7(I) is a timing diagram depicting a modified 4-step RACH process.

[0025] Figure 7(J) is a timing diagram depicting a modified 2-step RACH process.

[0026] Figure 7(K) is a timing diagram depicting a modified RACH process when the UE acts as a tag reader.

[0027] Figure 7(L) is a timing diagram depicting a modified sidechain process.

[0028] Figure 8(A) is a schematic diagram showing the problem of uncertainty regarding battery power.

[0029] Figure 8(B) is a timing diagram depicting a modified 4-step RACH process regarding power level indication.

[0030] Figure 8(C) is a timing diagram depicting a modified 2-step RACH process regarding power level indication.

[0031] Figure 8(D) is a timing diagram depicting a modified RACH process regarding low power mode.

[0032] Figure 8(E) is a timing diagram depicting a modified RACH process regarding a controllable reflection amplifier.

[0033] Figure 9(A) is a schematic diagram depicting the introduction of a dedicated radio frequency source focused on charging A-IoT devices.

[0034] Figure 9(B) is a timing diagram depicting a modified RACH process regarding the dedicated radio frequency charging source.

[0035] Figure 10(A) is a schematic diagram depicting the implementation of a cooperative device discovery protocol where an A-IoT device helps a gNB or UE discover other A-IoT devices.

[0036] Figure 10(B) is a timing diagram showing the behavior of a UE, gNB, and A-IoT device, and the signal transmission between them in the context of the cooperative device discovery protocol of the A-IoT device.

[0037] Figure 11(A) is a timing diagram showing the behavior among an A-IoT device, gNB, and radio frequency charging source, and the signal transmission between them in the context of the coordinated charging and communication protocol of the A-IoT device.

[0038] Figure 11(B) is a timing diagram showing the behavior among the A-IoT device, gNB, and the RF charging power source, as well as the signal transmission among them in the context of the charging protocol based on the communication requirements of the A-IoT device.

[0039] Figure 12(A) is a timing diagram for the power-aware modulation protocol.

[0040] Figure 12(B) is a timing diagram for the passive wake-up mechanism.

[0041] Figure 13(A) is a timing diagram for the prioritized backscatter mechanism.

[0042] Figure 13(B) is a timing diagram for the battery level reporting mechanism.

[0043] Figure 14(A) is a timing diagram for the charging indication mechanism.

[0044] Figure 14(B) is a timing diagram for the adaptive antenna beamforming mechanism.

[0045] Figure 15(A) is a timing diagram for the solar energy harvesting mechanism.

[0046] Figure 15(B) is a schematic diagram depicting an embodiment of a system for controlling the indoor light intensity based on the power demand of the A-IoT device.

[0047] Figure 15(C) is a timing diagram for the adaptive indoor lighting control mechanism.

[0048] Figure 16 Is a timing diagram for the lighting-based power management mechanism.

[0049] Figure 17 Shows an example communication system with an example communication device and an example network device.

[0050] Figure 18(A) is a flowchart describing the process of handling the battery level uncertainty between the reader device and the A-IoT device.

[0051] Figure 18(B) is a flowchart describing another process of handling the battery level uncertainty between the reader device and the A-IoT device. Detailed Description of the Invention

[0052] The following detailed description in conjunction with the accompanying drawings is intended as a description of various configurations and is not intended to represent the only configuration in which the concepts described in the present invention can be practiced. This detailed description section includes specific details for the purpose of providing a thorough understanding of the various concepts. However, those skilled in the art can practice these concepts without these specific details. In some cases, well-known structures and components are shown in block diagram form to avoid obscuring these concepts.

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

[0054] For example, an element, any part of an element, or any combination of elements can 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 the processing system can execute software. Software should be broadly interpreted as instructions, instruction sets, code, code segments, program code, programs, subprograms, software components, applications, software applications, software packages, routines, subroutines, objects, executable files, execution threads, processes, and functions, etc., regardless of whether it is referred to as software, firmware, middleware, microcode, hardware description language, or otherwise.

[0055] Accordingly, in one or more exemplary aspects, the above-described functionality may be implemented in hardware, software, or any combination thereof. If implemented in software, the functionality may be stored on a computer-readable medium or encoded as one or more instructions or code on a computer-readable medium. A computer-readable medium includes computer storage media. The storage media may be any available medium that can be accessed by a computer. The above computer-readable media may include random access memory (RAM), read-only memory (ROM), electrically erasable programmable ROM (EEPROM), optical disk storage, magnetic disk storage, other magnetic storage devices, combinations of the aforementioned types of computer-readable media, or any other medium that can be used to store computer-executable code in the form of instructions or data structures accessible by a computer, which is only used as an example and is not intended to limit the present invention.

[0056] Figure 1 is a schematic diagram illustrating an exemplary wireless communication system and access network 100. The wireless communication system (which may also be 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)). The BS 102 may include a macro cell (high-power cellular base station) and / or a small cell (low-power cellular base station). The macro cell includes the BS, and the small cell includes a femtocell, a picocell, and a microcell.

[0057] The BS102 configured for 4G LTE (collectively referred to as the Evolved Universal Mobile Telecommunications System Terrestrial Radio Access Network (E-UTRAN)) can be connected to the EPC 160 through a backhaul link 132 (such as the SI interface). The BS102 configured for 5G NR (collectively referred to as the Next Generation RAN (NG-RAN)) can be connected to the core network 190 through the backhaul link 184. Among other functions, the BS102 can perform one or more of the following functions: transfer of user data, ciphering and deciphering of radio channels, integrity protection, header compression, mobility control functions (such as 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 trace, RAN Information Management (RIM), paging, positioning, and delivery of warning messages. The BS102 can communicate directly or indirectly with each other (such as by means of the EPC 160 or the core network 190) through the backhaul link 134 (such as the X2 interface). The backhaul link 134 can be wired or wireless.

[0058] BS102 can communicate wirelessly with UE 104. Each BS102 can provide communication coverage for its respective geographical coverage area 110. There may be overlapping geographical coverage areas 110. For example, 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 (HeNB), where the HeNB can provide services to a restricted group called a Closed Subscriber Group (CSG). The communication link 120 between BS102 and UE 104 can include an uplink (UL) (also referred to as a reverse link) transmission from UE 104 to BS102 and / or a downlink (DL) (also referred to as a forward link) transmission from BS102 to UE 104. The communication link 120 can use MIMO antenna technology, including spatial multiplexing, beamforming, and / or transmit diversity. The communication link can pass through one or more carriers. BS102 / UE 104 can use a spectrum with a bandwidth of up to 7 MHz per carrier (such as 5, 10, 15, 20, 100, 400 MHz, etc.), where the carriers are allocated in carrier aggregation (CA) for transmission in each direction, and the total carrier aggregation is up to Yx MHz (x component carriers). The above carriers can be adjacent to each other or not. The allocation of carriers can be asymmetric with respect to DL and UL (for example, more or fewer carriers can be allocated to DL than UL). The component carriers can include a primary component carrier and one or more secondary component carriers. The primary component carrier can be called a Primary Cell (PCell), and the secondary component carrier can be called a Secondary Cell (SCell).

[0059] Some UEs 104 may communicate with each other using device-to-device (D2D) communication links 158. The D2D communication links 158 may use DL / UL WWAN spectrum. The D2D communication links 158 may use one or more sidelink channels, such as physical sidelink broadcast channel (PSBCH), physical sidelink discovery channel (PSDCH), physical sidelink shared channel (PSSCH), and 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 the IEEE 802.11 standard, LTE, or NR.

[0060] The wireless communication system may also include a Wi-Fi access point (AP) 150, where the Wi-Fi AP 150 communicates with a Wi-Fi station (STA) 152 via a communication link 154 in the 5GHz 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.

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

[0062] Base station 102 (whether it is 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 traditional sub-6 GHz spectrum, millimeter wave (mmW) frequencies, and / or near mmW frequencies to communicate with UE 104. When gNB 180 operates at mmW or near mmW frequencies, gNB 180 may be referred to as a mmW base station. Extremely high frequency (EHF) is a part of RF in the electromagnetic spectrum. EHF has a range of 30 GHz to 300 GHz and a wavelength between 1 millimeter and 10 millimeters. Radio waves in this frequency band may be referred to as millimeter waves. Near mmW may extend down to a frequency of 3 GHz with a wavelength of 100 millimeters. The super high frequency (SHF) band extends between 3 GHz and 30 GHz and is also referred to as centimeter waves. Communications using mmW / near mmW radio frequency bands (e.g., 3 GHz - 300 GHz) have extremely high path loss and short distances. MmW base station 180 may utilize beamforming 182 with UE 104 to compensate for the extremely high path loss and short distances.

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

[0064] 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 processes signaling between the UE 104 and the EPC 160. Generally, 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 an IP service 176. The IP service 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 functions for the provision and delivery of MBMS user services. The BM-SC 170 may serve as an entry point for content provider MBMS transmissions, may be used to authorize and initiate MBMS bearer services within a Public Land Mobile Network (PLMN), and may be used to schedule MBMS transmissions. 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 collecting charging information related to evolved MBMS (eMBMS), where the BS 102 belongs to a Multicast Broadcast Single Frequency Network (MBSFN) area for broadcasting a specific service.

[0065] 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 a Unified Data Management (UDM) 196. The AMF 192 is a control node that processes signaling between the UE 104 and the core network 190. Generally, the SMF 194 provides QoS flow and session management. All user Internet Protocol (IP) packets are transported through the UPF 195. The UPF 195 provides UE IP address allocation and other functions. The UPF 195 is connected to an 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.

[0066] The BS can also be referred to as a gNB, Node B (NB), eNB, access point, base 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. BS 102 provides an access point for UE 104 to the EPC 160 or the core network 190. Examples of UE 104 include a cellular phone, smartphone, Session Initiation Protocol (SIP) phone, laptop computer, Personal Digital Assistant (PDA), satellite radio, global positioning system, multimedia device, video device, digital audio player (such as an MP3 player), camera, game console, tablet computer, smart device, wearable device, vehicle, electricity meter, gas pump, large kitchen appliance or small kitchen appliance, medical device, implant, sensor / actuator, display, or any other device with a similar function. Some of the UE 104 can be referred to as IoT devices (such as parking meters, gas pumps, ovens, vehicles, heart monitors, etc.). UE 104 can also be referred to as a station, mobile station, user station, mobile unit, user unit, wireless unit, remote unit, mobile device, wireless device, wireless communication device, remote device, mobile user station, access terminal, mobile terminal, wireless terminal, remote terminal, cell phone, user agent, mobile client, client, or some other suitable term.

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

[0068] Figure 2It is a block diagram of the communication between BS210 and UE 250 in the access network. In the DL, IP packets from the EPC 160 can be provided to the controller / processor 275. The 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, where the RRC layer functions are associated with the broadcast of system information (such as the 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), mobility between radio access technologies (RATs), and measurement configuration for UE measurement reports; PDCP layer functions, where the PDCP layer functions are associated with header compression / decompression, security (encryption, decryption, integrity protection, integrity verification), and handover support functions; RLC layer functions, where the RLC layer functions are associated with the transfer of higher layer Packet Data Units (PDUs), error correction via Automatic Repeat Request (ARQ), concatenation, segmentation, and reassembly of RLC Service Data Units (SDUs), re-segmentation of RLC data PDUs, and re-ordering of RLC data PDUs; and MAC layer functions, where the MAC layer functions are associated with the mapping between logical channels and transport channels, multiplexing of MAC SDUs onto Transport Blocks (TBs), demultiplexing of MAC SDUs from TBs, scheduling information reporting, error correction via Hybrid Automatic Repeat Request (HARQ), priority handling, and logical channel prioritization.

[0069] The transmit (TX) processor 216 and the receive (RX) processor 270 implement the 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), and M-quadrature amplitude modulation (M-QAM). The encoded and modulated symbols can then be divided into parallel streams, and each stream can then be mapped to orthogonal frequency division multiplexing (OFDM) subcarriers, 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 generate a physical channel carrying a stream of time-domain OFDM symbols. The OFDM stream is precoded in space to generate multiple spatial streams. Channel estimates from the channel estimator 274 can be used to determine the encoding / decoding and modulation schemes, as well as for spatial processing. The channel estimates can be derived from the RS transmitted by the UE 250 and / or channel state feedback. 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.

[0070] At the UE 250, each receiver 254RX can receive signals via respective antennas 252. Each receiver 254RX recovers the information modulated onto the RF carrier and provides this 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 streams destined for the UE 250. If there are multiple spatial streams destined for the UE 250, the multiple spatial streams can be combined by the RX processor 256 into a single OFDM symbol stream. The RX processor 256 then uses the Fast Fourier Transform (FFT) to transform the OFDM symbol stream from the time domain to the frequency domain. The frequency domain signal includes separate OFDM symbol streams for the respective subcarriers of the OFDM signal. The symbols and RS on the respective subcarriers are recovered and demodulated by determining the most likely signal constellation points transmitted by the BS 210. These soft decisions can be based on the channel estimates calculated by the channel estimator 258. These soft decisions can then be decoded and deinterleaved to recover the data and control signals originally transmitted by the BS 210 on the physical channels. The above data and control signals can then be provided to the controller / processor 259, where the controller / processor 259 implements layer 3 and layer 2 functions.

[0071] The controller / processor 259 can be associated with a memory 260 that stores program code and data. The memory 260 can 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 the Acknowledge (ACK) and / or Negative Acknowledgment (NACK) protocols to support HARQ operations.

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

[0073] Channel estimates derived from RS or feedback transmitted by the channel estimator 258 from BS210 can be used by the TX processor 268 to select appropriate coding and modulation schemes, and to facilitate spatial processing. The spatial streams generated by the TX processor 268 can be provided to different antennas 252 via separate transmitters 254TX. Each transmitter 254TX can modulate an RF carrier using each spatial stream for transmission. Similar to the description made in conjunction with the receiver functions at UE 250, UL transmission is processed in a similar manner at BS210. Each receiver 218RX receives signals via respective antennas 220. Each receiver 218RX recovers the information modulated onto the RF carrier and provides this information to the RX processor 270.

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

[0075] NR can refer to a radio configured to operate according to a new air interface (such as other than an OFDMA-based air interface) or a fixed transport layer (such as other than IP). NR can utilize OFDM with a cyclic prefix (CP) on both UL and DL, and can include support for half-duplex operation using time division duplexing (TDD). NR can include enhanced mobile broadband (eMBB) services targeted at wide bandwidths (such as above 80 MHz), millimeter wave (mmW) targeted at high carrier frequencies (such as 60 GHz), massive machine type communication (mMTC) for machine type communication (MTC) technologies targeted at non-backward compatible, and / or mission-critical for ultra-reliable low latency communication (URLLC) services.

[0076] 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, a 50 MHz bandwidth is for a 15 kHz sub-carrier spacing (SCS) over a duration of 1 ms). Each radio frame can include 10 subframes (or 10, 20, 40, or 80 NR time slots) with a length of 10 ms. Each time slot can indicate the link direction for data transfer (i.e., DL or UL) and the link direction for each time slot can be dynamically switched. Each time slot can contain DL / UL data as well as DL / UL control data. A more detailed description of the UL and DL time slots for NR can be referred to below Figure 5 and Figure 6 for a more detailed description of the UL and DL time slots used for NR.

[0077] 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 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 handover. In some cases, the DCell may not transmit a Synchronization Signal (SS), and in some cases, the DCell may transmit the 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 to consider for cell selection, access, handover, and / or measurement based on the indicated cell type.

[0078] Figure 3 Illustrate an exemplary logical architecture of a distributed RAN 300 according to aspects of the present invention. The 5G Access Node (AN) 306 may include an Access Node Controller (ANC) 302. The ANC may be the CU of the 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 (the TRP may also be referred to as a BS, NR BS, NB, 5G NB, AP, or some other term). As described above, the TRP may be used interchangeably with "cell".

[0079] TRP 308 can be a DU. The TRP can 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 can be connected to more than one ANC. The TRP can include one or more antenna ports. The TRP can be configured to supply services to the UE independently (such as dynamic selection) or jointly (such as joint transmission).

[0080] 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 transport network performance (such as bandwidth, latency, and / or jitter). The architecture can share features and / or components with LTE. According to an aspect of the present invention, the NG-AN 310 can support dual connectivity with NR. The NG-AN can share a common fronthaul for LTE and NR.

[0081] The architecture can enable cooperation between TRPs 308. For example, cooperation can be preconfigured within and / or across TRPs via the ANC 302. According to an aspect of the present invention, an inter-TRP interface may not be required / absent.

[0082] According to an aspect of the present invention, a dynamic configuration of separated logical functions can exist within the architecture of the distributed RAN 300. The PDCP, RLC, and MAC protocols can be adaptively located at the ANC or the TRP.

[0083] Figure 4 Illustrate an exemplary physical architecture of a distributed RAN 400 according to an aspect of the present invention. The 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 (such as offloaded to Advanced Wireless Service (AWS)). The Centralized RAN Unit (C-RU) 404 can host one or more ANC functions. Optionally, the C-RU can locally host core network functions. The C-RU can have a distributed deployment. The C-RU can be closer to the network edge. The DU 406 can host one or more TRPs. The DU can be located at the edge of a network with RF capabilities.

[0084] Figure 5FIG. 500 is a schematic diagram of a DL-centric exemplary time slot. A DL-centric time slot may include a control portion 502. The control portion 502 may be present in the initial or start 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, as Figure 5 shown, the control portion 502 may be a Physical Downlink Control Channel (PDCCH). The DL-centric time slot may also include a DL data portion 504. The DL data portion 504 may sometimes be referred to as the payload of the DL-centric time slot. The DL data portion 504 may include communication resources for communicating DL data from a scheduling entity (such as a UE or BS) to a subordinate entity (such as a UE). In some configurations, the DL data portion 504 may be a Physical Downlink Shared Channel (PDSCH).

[0085] 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 other information, such as information about a Random Access Channel (RACH) procedure, a scheduling request, and / or various other suitable types of information.

[0086] As 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 can sometimes be referred to as a gap, guard period, guard interval, and / or various other suitable terms. This separation provides time for the switch-over from DL communication (such as a reception operation performed by a subordinate entity, such as a UE) to UL communication (such as a transmission operation performed by a subordinate entity, such as a UE). Those skilled in the art will understand that the foregoing is merely an example of a DL-centric time slot, and alternative structures with similar characteristics can exist without departing from the aspects described in the present invention.

[0087] Figure 6 FIG. 600 is a schematic diagram of an UL-centric exemplary time slot. The UL-centric time slot can include a control portion 602. The control portion 602 can be present in the initial or start portion of the UL-centric time slot. Figure 6 The control portion 602 in Figure 5 can be similar to the control portion 502 described above with reference to

[0088] As Figure 6 shown, the end of the control portion 602 can be separated in time from the start of the UL data portion 604. This time separation can sometimes be referred to as a gap, guard period, guard interval, and / or various other suitable terms. This separation provides time for the switch-over from DL communication (such as a reception operation performed by a scheduling entity) to UL communication (such as a transmission operation performed by a scheduling entity). The UL-centric time slot can also include a common UL portion 606. Figure 6 The common UL portion 606 in Figure 5The described common UL part 506. The common UL part 606 may additionally or alternatively include information about a Channel Quality Indicator (CQI), a Sounding Reference Signal (SRS), and various other suitable types of information. Those skilled in the art will understand that the foregoing is merely an example of a UL-centric time slot, and alternative structures with similar characteristics may exist without departing from the aspects described in the present invention.

[0089] In some cases, two or more subordinate entities (such as UEs) may communicate with each other using sidelink signals. Practical applications of such sidelink communication may include public safety, proximity service, UE-to-network relay, Vehicle-To-Vehicle (V2V) communication, Internet of Everything (IoE) communication, IoT communication, mission-critical mesh, and / or various other suitable applications. Generally, a sidelink signal may refer to a signal that communicates 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 a BS), even though the scheduling entity may be used for scheduling and / or control purposes. In some examples, sidelink signals may communicate using licensed spectrum (different from wireless local area networks that typically use unlicensed spectrum).

[0090] FIG. 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, UE 704 is connected to base station 702 located in cell 706.

[0091] A-IoT devices typically have limitations in terms of 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 limitations in the activation power threshold. Increasing the transmit power can achieve the required range but may interfere with nearby base stations. Additionally, the activation threshold of some devices depends on the activation threshold of the rectifier in the radio frequency energy harvester, which results in uncertainty when the base station discovers the device within the cell, especially when the device has a low battery or no battery.

[0092] The increasing use of Internet of Things (IoT) devices has brought challenges in power management. Due to cost, environmental, and security factors, manually replacing or charging batteries has become impractical. Existing technologies such as barcodes and Radio-frequency Identification (RFID) also face limitations in terms of read range and interference. Therefore, new IoT technologies are needed that can support battery-less devices or devices with energy storage without manual intervention. The goal is to create solutions within the 3rd Generation Partnership Project (3GPP) system that can handle a large number of connections and device densities while reducing complexity and power consumption, thus opening up new markets and adding value in the value chain.

[0093] The present invention provides a method and system for improving the communication range, power consumption, and charging time of A-IoT devices. The disclosure includes a technique for increasing the transmit power to achieve the required range while minimizing interference to nearby base stations. The disclosure also includes a technique for optimizing the device activation threshold based on the activation threshold of the rectifier in the radio frequency energy harvester, thereby reducing the uncertainty of the base station discovering the device within the cell. In addition, the disclosure includes a technique for reducing the device charging time, especially when using radio frequency energy.

[0094] It should be noted 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 Pro, Fifth Generation (5G), NR, Internet of Things (IoT), and NarrowBand Internet of Things (NB-IoT), Industrial Internet of Things (IIoT), and Sixth Generation (6G), the concepts, solutions, and any variants / derivatives thereof proposed can be implemented, applied, and realized in other types of radio access technologies, networks, and network topologies. Therefore, the scope of the present invention is not limited to the examples described herein.

[0095] System Topology

[0096] Figure 7(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 Figure 7(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 amount of work required for any gNB specification change 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).

[0097] Figure 7(C) is schematic diagram 720, showing an example of a communication link between a gNB and an A-IoT device connected via a wireless air interface to a user equipment. As shown in Figure 7(C), a wireless air interface is established between the gNB and the user equipment 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 specifications can be determined according to the use case and its corresponding requirements.

[0098] Receiver architecture

[0099] Figure 7(D) is schematic diagram 730, showing the first type of A-IoT device. The design goals of Device A are power consumption (≤1 microwatt or ≤10 microwatts) and complexity during transmission / reception, and its goal is to be comparable to UHF RFID 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 loss, and requires a remote carrier source to transmit positioning signals.

[0100] The architecture of Device A includes the following components:

[0101] A low pass filter (LPF) for suppressing adjacent sub-carrier interference (ASCI) and adjacent carrier interference (ACI);

[0102] An envelope detector (ED) for supporting signals based on On-Off Keying (OOK);

[0103] An analog to digital converter (ADC) for digital baseband processing;

[0104] A digital baseband (DBB) for sequence matching;

[0105] A modulator (switch) controlled by the incoming signal for adding payload data for OOK modulation;

[0106] A radio frequency energy harvester for converting radio frequency signals into an energy source.

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

[0108] The architecture of Device B includes the following components:

[0109] LPF, for suppressing ASCI and ACI;

[0110] ED, for supporting OOK-based signals;

[0111] ADC, for digital baseband processing;

[0112] DBB, for sequence matching;

[0113] A modulator controlled by the incoming signal, for adding payload data to OOK modulation;

[0114] A radio frequency energy harvester, for converting radio frequency signals into an energy source;

[0115] Additional energy harvesters for different types of environmental energy sources, such as radio frequency radio, solar energy, thermal energy, and piezoelectric energy;

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

[0117] A reflection amplifier, for amplifying the signal input to the tag and the signal backscattered to the reader.

[0118] Figure 7(F) is schematic diagram 734, showing the third type of A-IoT device. The design goal of Device C is the power consumption during transmission / reception (≤1 mW to ≤10 mW), and the complexity goal is much lower than that of NarrowBand Internet of Things (NB-IoT). Device C has energy storage, independent signal generation, and an active radio frequency component for transmission. It also has mobility management capabilities, at least for cell selection / reselection.

[0119] The architecture of Device C includes the following components:

[0120] LPF, for suppressing ASCI and ACI;

[0121] ED, for supporting OOK-based signals;

[0122] ADC, for digital baseband processing;

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

[0124] A radio frequency energy harvester, for converting radio frequency signals into an energy source;

[0125] Additional energy harvesters for different types of environmental energy, such as radio frequency, solar, thermal, and piezoelectric energy;

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

[0127] A low-noise amplifier (LNA) and a power amplifier (PA) for amplifying received and transmitted signals.

[0128] New air interface

[0129] Figure 7(G) is schematic diagram 740, showing an example communication link via the air interface between a UE (e.g., UE 744) and an A-IoT device (e.g., A-IoT device 746). The present disclosure presents 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. The command outlines basic communication parameters, such as the tag rate, the tag data encoding method, and the total available duration.

[0130] Once the A-IoT device has harvested sufficient energy, it is activated and listens 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. It then transmits the sequence during the selected duration, preceded by a known preamble sequence.

[0131] In response to the A-IoT transmission, the UE decodes the received preamble sequence and sends an acknowledgment back to the A-IoT within a predetermined duration, aligned with the system configuration for the A-IoT device.

[0132] Figure 7(H) is schematic diagram 750, showing an example communication process between a reader device and an A-IoT device based on a selected duration. The User Equipment to Ambient IoT Device (U2A) communication link uses modulation schemes such as Amplitude Shift Keying (ASK) or On-Off Keying (OOK) for Pulse Interval Encoding (PIE) of 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 control signals or commands specifying the control parameters of the A-IoT device.

[0133] The Ambient IoT Device to User Equipment (A2U) communication link uses ASK or Phase Shift Keying (PSK) modulation. The A-IoT encodes backscattered data using FM0 baseband or Miller modulation, controlled by the UE or gNB via the A2U link. The A2U link signal transmission starts with one of two Miller subcarrier preambles, depending on the command or control signal. The A-IoT uses backscatter modulation, changing the reflection coefficient of its antenna to transmit data. The A2U link transmits Electronic Product Code (EPC) and Protocol-Control (PC) information.

[0134] Modified 4-step RACH

[0135] Considering that the A-IoT device can only perform ASK or OOK modulation and backscatter communication, and the DL signal can be a Primary Synchronization Signal (PSS), a Secondary Synchronization Signal (SSS), and a Low Power Wake-Up Signal (LP-WUS) based on OOK, the modified 4-step RACH process can be as follows:

[0136] 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 the "inquiry command" for the A-IoT device. For example, the LP-WUS, which is specifically designed to wake up the device from a low-power state, can be particularly useful for the A-IoT device. When one of these signals is detected, the A-IoT device wakes up and prepares for further communication.

[0137] 2. Preamble sequence transmission (Msg1): After receiving the DL signal, the A-IoT device generates a random 16-bit number (RN16) and backscatters it to the gNB or UE reader using ASK or OOK modulation. This is similar to an RFID tag sending the RN16 to the reader in response to an inquiry command.

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

[0139] 4. RRC connection request (Msg3): Once the A-IoT device receives the acknowledgment, it sends its EPC to the gNB or UE reader via backscatter communication using ASK or OOK modulation. This EPC is the unique identifier of the A-IoT device, similar to the unique identifier of an RFID tag.

[0140] 5. Contention resolution (Msg4): The gNB or UE reader sends a contention resolution message to the A-IoT device, acknowledging the A-IoT device's EPC and completing the RACH procedure. This step ensures that the A-IoT device has been correctly identified and there is no contention with other A-IoT devices. The contention resolution message can include the A-IoT device's EPC so that the device knows the message is for it.

[0141] This modified 4-step RACH procedure is more closely aligned with the RFID protocol, where the A-IoT device acts as an RFID tag and the gNB or UE reader acts as an RFID reader.

[0142] Figure 7(I) is a timing diagram 760, which describes the modified 4-step RACH procedure. In this figure, 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.

[0143] Modified Two-Step RACH

[0144] This subsection clarifies the proposed modifications to the two-step RACH procedure, aiming to accommodate the characteristics of A-IoT devices. The modifications are aligned with the RFID protocol and take into account the ASK or OOK modulation and backscatter communication capabilities of A-IoT devices.

[0145] The procedure consists of two main phases:

[0146] 1. Downlink signal transmission and preamble transmission (Msg1): The gNB or UE reader initiates the procedure by transmitting a DL signal accompanied by RN16 to the A-IoT device. The DL signal can be PSS, SSS, or LP-WUS, serving as the "query command" for the A-IoT device. For example, the gNB can send a DL signal (PSS) accompanied by RN16 (10111100 0011 1110). After receiving this signal, the A-IoT device uses it to charge its battery.

[0147] 2. Random access response and contention resolution (Message 2): In the subsequent phase, the A-IoT device verifies the received RN16 based on its tag ID. After successful matching, the A-IoT device uses backscatter communication with ASK or OOK modulation to send back RN16 and its unique EPC to the gNB or UE reader. For example, if RN16 aligns with the tag ID of the A-IoT device, the device backscatters RN16 (1011 1100 0011 1110) and its EPC (e.g., 0000 1010 1111 0000). After successfully receiving the EPC, the gNB or UE reader completes the RACH procedure by sending a final confirmation message to the A-IoT device.

[0148] This modification to the two-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.

[0149] Figure 7(J) is a timing diagram 770 that depicts a modified two-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 indicate the communication between the two participants, while the annotations provide additional details about the behavior of each participant at each step of the procedure.

[0150] This schematic diagram is consistent with the modified two-step RACH process designed by mimicking the RFID protocol. The A-IoT device acts as an RFID tag, and the gNB or UE reader acts as an RFID reader. Importantly, 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 provides a high-level overview of the process and serves as a basis for further detailed specifications based on specific implementation requirements.

[0151] Modified RACH Process (UE acts as tag reader)

[0152] Figure 7(K) is the timing diagram 780, which depicts a modified RACH process where the UE acts as a tag reader. As shown in Figure 7(K), this modification allows the UE to communicate as a reader with the A-IoT device acting as a tag.

[0153] 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 is equivalent to the "Query" in the RFID protocol. The modified preamble can be sent through 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 can start with a specific bit pattern followed by the unique identifier of the UE.

[0154] The behavior of the UE will involve generating the preamble and transmitting it via the PRACH. The UE needs to ensure that the preamble can be detected by the tags, which may require changing the format or power level of the preamble.

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

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

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

[0158] The behavior of the UE will involve listening for the RN16 on the PUSCH, verifying the RN16, and transmitting the confirmation message via PDCCH.

[0159] 4. Data Transmission (EPC): After receiving the confirmation 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 confirmation message. The unique identifier can be sent via PUSCH.

[0160] The behavior of the A-IoT device will involve listening for the confirmation message on the PDCCH, extracting the command from the confirmation message, and transmitting its unique identifier via PUSCH.

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

[0162] Of course, based on the provided context, Figure 7(K) shows what a part of the technical report might look like using a PlantUML sequence diagram.

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

[0164] Modified Sidelink Procedure

[0165] Figure 7(L) is a sequence diagram 790 that describes the modified sidelink procedure. This approach allows the UE to interact with an A-IoT device acting as an RFID tag as an RFID reader.

[0166] 1. Discovery Signal (Query): The UE (acting as a reader) sends a discovery signal to all tags in its vicinity. This is equivalent to the "query" in the RFID protocol. The discovery signal can be sent via the Physical Sidelink Control Channel (PSCCH). The signal may 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 unique identifier of the UE.

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

[0168] 2. Discovery Response (RN16): After detecting the discovery signal, each tag generates an RN16 and responds with 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 via the Physical Sidelink Shared Channel (PSSCH).

[0169] The behavior of the A-IoT device will involve listening for the discovery signal on the PSCCH, generating an RN16 after detecting the signal, and transmitting the RN16 via the PSSCH.

[0170] 3. Sidelink Connection Setup (ACK): The UE listens for the response from the tag. After receiving a valid RN16 from the tag, the UE sends a sidelink connection setup message to that tag. This serves as the "acknowledgment message (ACK)" in the RFID protocol. The UE needs to be modified to generate and send this acknowledgment message. The acknowledgment message can be sent via the PSCCH and can contain the RN16 and an instruction to direct the tag to transmit its unique identifier.

[0171] The behavior of the UE will involve listening for the RN16 on the PSSCH, verifying the RN16, and transmitting the acknowledgment message via the PSCCH.

[0172] 4. Data Transmission (EPC): After receiving the acknowledgment 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 acknowledgment message. The unique identifier can be sent via the PSSCH.

[0173] The behavior of the A-IoT device will involve listening for the acknowledgment message on the PSCCH, extracting the instruction in the acknowledgment message, and transmitting its unique identifier via the PSSCH.

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

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

[0176] To utilize 5G NR technology for RFID-like communication, the present invention proposes a modified sidelink process. This approach allows the UE acting as an RFID reader to interact with the A-IoT device acting as an RFID tag.

[0177] Battery Charge Uncertainty

[0178] Figure 8(A) is schematic diagram 800, which shows the problem of battery power uncertainty. For device B, the activation threshold of the device depends on the activation threshold of the rectifier in the RF energy harvester. If the device has an amplifier, higher power consumption is required, and RF signal energy harvesting may not be suitable because of its relatively low energy density. This results in uncertainty for the base station to detect device B, especially when the device has low battery power or no battery.

[0179] The uncertainty of device discoverability due to battery power fluctuations poses a significant challenge to the operation of the device and the effectiveness of the entire A-IoT system. Therefore, it is crucial to solve this problem and find solutions to ensure the continuous discoverability and reliable communication of the device, regardless of the battery power of the device.

[0180] Based on the given A-IoT protocol, the following are some potential solutions to ensure the continuous discoverability and reliable communication of the device, regardless of the battery power of the device.

[0181] Power level indication

[0182] Include power level indication in the response of the A-IoT device to the UE. This solution is feasible because it only requires minor changes to the existing communication protocol.

[0183] Figure 8(B) is timing diagram 820, which describes the modified 4-step RACH process regarding power level indication. To include power level indication in the response of the A-IoT device to the UE, the modified 4-step RACH process can be adjusted as follows:

[0184] 1. DL signal transmission and preamble transmission (Message 1): The gNB or UE reader sends a DL signal, which can be PSS, SSS, or LP-WUS, and RN16 to the A-IoT device. This DL signal serves as the "inquiry command" for the A-IoT device. The A-IoT device uses the DL signal to charge its battery.

[0185] 2. Power level indication (Message 2): The A-IoT device measures its current power level and includes this information in its response. The power level indication can be a simple binary value indicating whether the power level is above or below a certain threshold, or it can be a more detailed measurement.

[0186] 3. Random access response and contention resolution (Message 3): After receiving the DL signal and RN16, the A-IoT device checks whether RN16 matches its tag ID. If so, then the A-IoT device sends RN16, its power level indication, and its unique EPC back to the gNB or UE reader using ASK or OOK-modulated backscatter communication.

[0187] 4. Final Confirmation (Message 4): After successfully receiving the EPC and power level indication, the gNB or UE reader completes the RACH procedure by sending a final confirmation to the A-IoT device.

[0188] The modification to the 4-step RACH procedure allows the gNB or UE reader to receive the power level indication from the A-IoT device, which can be used to manage the power level of the A-IoT device and ensure efficient communication.

[0189] In the context of the modified 4-step RACH procedure with power level indication, a timing diagram can be developed to illustrate the behavior of the A-IoT device and the gNB or UE reader, as well as the signaling between them. The timing diagram is shown below:

[0190] 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 information about the behavior of each participant at each step of the procedure.

[0191] Figure 8(C) is the timing diagram 840, which describes the modified 2-step RACH procedure regarding the power level indication. To include the power level indication in the response of the A-IoT device to the UE, the modified 2-step RACH procedure can be adjusted as follows:

[0192] 1. DL Signal Transmission and Preamble Transmission (Message 1): The gNB or UE reader sends a DL signal, which can be a PSS, SSS, or LP-WUS, as well as RN16 to the A-IoT device. This DL signal serves as an "inquiry command" for the A-IoT device. The A-IoT device uses the DL signal to charge its battery.

[0193] 2. Random Access Response, Power Level Indication, and Contention Resolution (Message 2): After receiving the DL signal and RN16, the A-IoT device checks whether RN16 matches its tag ID. If so, then the A-IoT device measures its current power level and includes this power level indication in its response. The A-IoT device uses ASK or OOK-modulated backscatter communication to send RN16, its power level indication, and its EPC back to the gNB or UE reader. Then the gNB or UE reader sends a final confirmation to the A-IoT device, confirming the successful reception of the EPC and power level indication and completing the RACH procedure.

[0194] The modification to the 2-step RACH procedure allows the gNB or UE reader to receive the power level indication from the A-IoT device, which can be used to manage the power level of the A-IoT device and ensure efficient communication.

[0195] 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 information about the behavior of each participant at each step of the process.

[0196] Generally speaking, power level indication may include:

[0197] 1. Signal Strength Indicator: This is a numerical value representing the strength of the received signal. It is usually measured in decibels relative to a reference level (dBm).

[0198] 2. Quality Indicator: This is a measure of signal quality and may be affected by factors such as interference, noise, and distortion. It is usually expressed as the Signal-to-Noise Ratio (SNR) or the Bit Error Rate (BER).

[0199] 3. Binary Indicator: In some cases, the power level indication may be a simple binary value indicating whether the power level is above or below a certain threshold.

[0200] 4. Battery Level: For battery-powered devices such as A-IoT devices, the power level indication can also include a measurement of the remaining battery life. This can help the network make decisions regarding power management and scheduling.

[0201] These measures can help the network or the receiving device make informed decisions regarding resource allocation, power management, and other aspects of communication.

[0202] In the context of the modified 2-step or 4-step RACH process, the gNB or UE reader can configure the power level indication of the A-IoT device as follows:

[0203] 1. DL Signal Transmission and Preamble Transmission (Msg1): The gNB or UE reader sends a DL signal and RN16 to the A-IoT device. This DL signal can also include instructions on how the A-IoT device should measure and report its power level.

[0204] 2. Power Level Indication (Msg2): After receiving the DL signal and RN16, the A-IoT device measures its current power level according to the received instructions and includes this power level indication in its response. This step is specific to the 4-step RACH process.

[0205] 3. Random Access Response and Contention Resolution (Msg2 or Msg3): The A-IoT device sends back the RN16, its power level indication, and its unique EPC to the gNB or UE reader. In the 2-step RACH procedure, the power level indication is included in this step.

[0206] 4. Configuration and Final Acknowledgment (Msg3 or Msg4): After receiving the power level indication, the gNB or UE reader can configure its transmission power, modulation and coding scheme, or scheduling decision according to the indicated power level. Then, the gNB or UE reader sends a final acknowledgment to the A-IoT device, acknowledging the successful reception of the EPC and the power level indication and completing the RACH procedure.

[0207] This modification to the RACH procedure allows the gNB or UE reader to configure the power level indication from the A-IoT device and optimize the communication.

[0208] Low Power Mode

[0209] Introduce a low power mode for A-IoT devices. This solution is feasible and can be achieved with a small number of changes to the device's power management system.

[0210] Introducing a low power mode for A-IoT devices can significantly improve their energy efficiency. This modification, which requires a small number of changes to the device's power management system, not only extends the device's operating life but also provides additional processing time for energy-saving measures and energy harvesting, meeting the diverse needs of different A-IoT device behaviors.

[0211] The modified 2-step or 4-step RACH procedure can adapt to this low power mode as follows:

[0212] 1. DL Signal Transmission and Preamble Transmission (Msg1): The gNB or UE reader sends a DL signal, which may be PSS, SSS, or LP-WUS, and the RN16 to the A-IoT device. This signal acts as an "inquiry command" for the A-IoT device. The A-IoT device uses this signal to charge its battery or store energy for future use.

[0213] 2. Low Power Mode Indication (Msg2): In the 4-step RACH procedure, the A-IoT device measures its current power level. If it is below a certain threshold, the device switches to the low power mode. Depending on the specific behavior of the A-IoT device, it may enter the standby state, reduce the power consumption of non-essential components, or perform other energy-saving measures. This mode also provides the A-IoT device with more processing time to save energy or harvest energy from the environment. Then, the device includes this low power mode indication in its response.

[0214] 3. Random Access Response and Contention Resolution (Msg2 or Msg3): After receiving the DL signal and RN16, the A-IoT device verifies RN16 with its tag ID. If they match, the device sends back RN16, its low-power mode indication, and its unique EPC to the gNB or UE reader. In the 2-step RACH procedure, the low-power mode indication is included in this step.

[0215] 4. Final Confirmation (Msg3 or Msg4): After successfully receiving the EPC and the low-power mode indication, the gNB or UE reader completes the RACH procedure by sending a final confirmation to the A-IoT device.

[0216] Figure 8(D) is a timing diagram 860 depicting the modified RACH procedure regarding the low-power mode. By introducing the low-power mode in the A-IoT device, its energy efficiency can be significantly improved, especially during idle or low-activity periods. This is particularly beneficial for A-IoT devices with different behaviors as it allows for flexible power management strategies that can be customized according to the specific requirements and characteristics of each device.

[0217] 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 information about the behavior of each participant at each step of the process.

[0218] After sending the low-power mode indication to the gNB or UE reader, the A-IoT device enters the low-power mode. Depending on the specific behavior of the A-IoT device, it may enter a standby state, reducing the power consumption of non-essential components, or perform other energy-saving measures. This mode also provides the A-IoT device with more processing time to save energy or harvest energy from the environment.

[0219] Controllable Reflection Amplifier

[0220] The A-IoT device can adjust the power consumption of its reflection amplifier according to its current power level. This solution is feasible, but it requires the device to have a controllable reflection amplifier.

[0221] Adjusting the power consumption of the reflection amplifier in the A-IoT device according to the current power level can significantly improve their energy efficiency. This modification, which requires the device to have a controllable reflection amplifier, can extend the device's operating life and provide additional processing time for energy-saving measures and energy harvesting, meeting the diverse needs of different A-IoT device behaviors.

[0222] The modified 2-step or 4-step RACH procedure can accommodate this controllable reflection amplifier as follows:

[0223] 1. DL signal transmission and preamble transmission (Msg1): The gNB or UE reader sends DL signals, which may be PSS, SSS, or LP-WUS, as well as RN16, to the A-IoT device. This signal serves as the "inquiry command" for the A-IoT device. The A-IoT device uses this signal to charge its battery or store energy for future use.

[0224] 2. Reflection amplifier control indication (Msg2): During the 4-step RACH process, the A-IoT device measures its current power level. If it is below a certain threshold, the device adjusts the power consumption of its reflection amplifier. Depending on the specific behavior of the A-IoT device, it may increase or decrease the power consumption of the reflection amplifier to optimize performance. Then, the device includes this reflection amplifier control indication in its response.

[0225] 3. Random access response and contention resolution (Msg2 or Msg3): After receiving the DL signal and RN16, the A-IoT device verifies the RN16 with its tag ID. If they match, the device sends back the RN16, its reflection amplifier control indication, and its unique EPC to the gNB or UE reader. In the 2-step RACH process, the reflection amplifier control indication is included in this step.

[0226] 4. Final confirmation (Msg3 or Msg4): After successfully receiving the EPC and the reflection amplifier control indication, the gNB or UE reader completes the RACH process by sending a final confirmation to the A-IoT device.

[0227] By integrating a controllable reflection amplifier in the A-IoT device, its energy efficiency can be significantly improved, especially during idle or low-activity periods. This is particularly beneficial for A-IoT devices with different behaviors, as it allows for flexible power management strategies that can be customized according to the specific needs and characteristics of each device.

[0228] In the context of the modified 2-step or 4-step RACH process for A-IoT devices with a controllable reflection amplifier, a timing diagram can be developed to illustrate the behavior of the A-IoT device and the gNB or UE reader, as well as the signaling between them.

[0229] Figure 8(E) is timing diagram 880, which describes the modified RACH process regarding the controllable reflection amplifier. 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 information about the behavior of each participant at each step of the process.

[0230] After sending a reflection amplifier control indication to the gNB or UE reader, the A-IoT device adjusts the power consumption of its reflection amplifier. Depending on the specific behavior of the A-IoT device, it may increase or decrease the power consumption of the reflection amplifier to optimize performance.

[0231] Dedicated RF charging source

[0232] Figure 9(A) is a schematic diagram 900, which describes a scenario of introducing a dedicated RF source to focus on charging A-IoT devices.

[0233] Introducing an RF source dedicated to charging A-IoT devices can significantly improve their energy efficiency. Although this solution requires additional infrastructure, it can significantly increase the power level of A-IoT devices, thereby extending their operating life and providing additional processing time for energy-saving measures and energy harvesting, meeting the diverse needs of different A-IoT device behaviors.

[0234] The modified 2-step or 4-step RACH process can be adapted to the dedicated RF charging source as follows:

[0235] 1. DL signal transmission and preamble transmission (Msg1): The dedicated RF source sends a DL signal, which may be PSS, SSS, or LP-WUS, as well as RN16, to the A-IoT device. This signal serves as the "charging command" for the A-IoT device. The A-IoT device uses this signal to charge its battery or store energy for future use.

[0236] 2. Charging indication (Msg2): In the 4-step RACH process, the A-IoT device measures its current power level. If it is below a certain threshold, the device switches to the charging mode and starts collecting energy from the dedicated RF source. Then, the device includes a charging indication in its response.

[0237] 3. Random access response and contention resolution (Msg2 or Msg3): After receiving the DL signal and RN16 from the dedicated RF source, the A-IoT device verifies the RN16 with its tag ID. If they match, the device sends the RN16, its charging indication, and its unique EPC back to the dedicated RF source. In the 2-step RACH process, the charging indication is included in this step.

[0238] 4. Final confirmation (Msg3 or Msg4): After successfully receiving the EPC and the charging indication, the dedicated RF source completes the RACH process by sending a final confirmation to the A-IoT device.

[0239] During this process, the A-IoT device may not be able to receive signals from both the dedicated RF charging source and the gNB or UE reader simultaneously due to potential interference or resource limitations. Therefore, it may need to switch between the two sources based on its current power level and operational requirements.

[0240] By introducing a dedicated RF charging source, the A-IoT device can significantly improve its energy efficiency, especially during idle or low-activity periods. This is particularly beneficial for A-IoT devices with diverse behaviors as it allows for flexible power management strategies that can be customized according to the specific needs and characteristics of each device.

[0241] In the context of the modified two-step or four-step RACH process for A-IoT devices with a dedicated RF charging source, timing diagrams can be developed to illustrate the behavior of the A-IoT device, the gNB or UE reader, and the dedicated RF charging source, as well as the signaling between them.

[0242] Figure 9(B) is the timing diagram 920, which describes the modified RACH process regarding the dedicated RF charging source. In this timing diagram, the "A-IoT device" participant represents the A-IoT device, the "RF charging source" participant represents the dedicated RF charging source, and the "gNB / UE reader" participant represents the gNB or UE reader. The arrows represent the communication between the three participants, and the annotations provide additional information about the behavior of each participant at each step of the process.

[0243] Intelligent RF Charging Scheduling

[0244] The implementation of an intelligent scheduling system where the RF charging source is only activated during periods of low communication activity can significantly improve the energy efficiency of A-IoT devices. Such a solution requires intelligent scheduling algorithms and coordination with the communication channels, which can significantly boost the power levels of A-IoT devices, thereby extending their operating lifetimes and providing additional processing time for energy-saving measures and energy harvesting to meet the diverse needs of different A-IoT device behaviors.

[0245] The modified two-step or four-step RACH process can be adapted to this intelligent RF charging scheduling as follows:

[0246] 1. DL signal transmission and preamble transmission (Msg1): The dedicated RF source sends a DL signal, which may be PSS, SSS, or LP-WUS, as well as RN16, to the A-IoT device. This signal serves as the "charging command" for the A-IoT device. The A-IoT device uses this signal to charge its battery or store energy for future use.

[0247] 2. Charging Scheduling Indication (Msg2): During the 4-step RACH procedure, the A-IoT device measures its current power level. If it is below a certain threshold, the device switches to the charging mode and starts collecting energy from a dedicated RF source. Then the device includes the charging scheduling indication in its response.

[0248] 3. Random Access Response and Contention Resolution (Msg2 or Msg3): After receiving the DL signal and RN16 from the dedicated RF source, the A-IoT device verifies the RN16 with its tag ID. If they match, the device sends back the RN16, its charging scheduling indication, and its unique EPC to the dedicated RF source. During the 2-step RACH procedure, the charging scheduling indication is included in this step.

[0249] 4. Final Acknowledgment (Msg3 or Msg4): After successfully receiving the EPC and the charging scheduling indication, the dedicated RF source completes the RACH procedure by sending a final acknowledgment to the A-IoT device.

[0250] During this process, due to potential interference or resource limitations, the A-IoT device may not be able to receive signals from the dedicated RF charging source and the gNB or UE reader simultaneously. Therefore, it may need to switch between the two sources according to its current power level and operating requirements.

[0251] By integrating an intelligent RF charging scheduling system, the A-IoT device can significantly improve its energy efficiency, especially during idle or low-activity periods. This is particularly beneficial for A-IoT devices with different behaviors as it allows for flexible power management strategies that can be customized according to the specific needs and characteristics of each device.

[0252] Cooperative Device Discovery

[0253] Figure 10(A) is a diagram 1000 depicting the implementation of the cooperative device discovery protocol, where the A-IoT device helps the gNB or UE discover other A-IoT devices.

[0254] Implementing a cooperative device discovery protocol, where the UE assists the gNB in discovering A-IoT devices that the gNB cannot directly detect, can significantly improve network efficiency and device detection. This solution requires changes to the device discovery protocol and may increase network complexity, but it can improve the network's ability to detect and communicate with A-IoT devices, thereby enhancing the overall performance and reliability of the A-IoT network.

[0255] In the cooperative device discovery protocol, the UE not only communicates with the gNB but also helps discover other A-IoT devices in its vicinity. This can be facilitated through a modified procedure as follows:

[0256] 1. Device Discovery Request (Msg1): The gNB sends a device discovery request to a known UE. This request serves as the "discovery command" for the UE.

[0257] 2. Device Discovery Assistance (Msg2): After receiving the device discovery request, the UE starts a local scan to discover other A-IoT devices that cannot be directly detected by the nearby gNB. Then it prepares a list of discovered devices, including their unique EPCs.

[0258] 3. Device Discovery Response (Msg3): The UE sends the list of discovered A-IoT devices and their EPCs back to the gNB. This response serves as the device discovery indication.

[0259] 4. Acknowledgment (Msg4): After successfully receiving the device discovery indication, the gNB sends an acknowledgment to the UE, completing the cooperative device discovery process.

[0260] By integrating the cooperative device discovery protocol, the UE can significantly improve its network efficiency, especially in densely populated or complex network environments. This is particularly beneficial for A-IoT networks as it allows for flexible device discovery strategies that can help detect and communicate with more devices, even in challenging environments.

[0261] Figure 10(B) is the timing diagram 1020, showing the behavior of the UE, gNB, and A-IoT devices in the context of the cooperative device discovery protocol for A-IoT devices, as well as the signaling between them. In this timing diagram, the "UE" participant represents the user equipment, the "gNB" participant represents the gNB, and the "A-IoT device" participant represents the A-IoT devices that cannot be directly detected by the gNB. The arrows represent the communication between the three participants, and the annotations provide additional information about the behavior of each participant at each step of the process.

[0262] After receiving the device discovery request from the gNB, the UE starts a local scan to discover other A-IoT devices in its vicinity. Then the UE sends the list of discovered A-IoT devices and their EPCs back to the gNB. After successfully receiving the device discovery indication, the gNB sends an acknowledgment to the UE, completing the cooperative device discovery process.

[0263] Coordinating Charging and Communication

[0264] Implementing coordinated charging and communication, where the gNB and dedicated radio frequency charging sources coordinate their operations to ensure efficient charging and communication with A-IoT devices, can significantly improve network efficiency and energy management. This solution requires coordination algorithms and changes to the operations of the gNB and charging sources, but it can improve the network's ability to detect, communicate with, and power A-IoT devices, thereby enhancing the overall performance and reliability of the A-IoT network.

[0265] In coordinating the charging and communication protocols, the gNB and the RF charging source not only communicate with the A-IoT devices independently but also coordinate their operations to optimize device charging and communication. This can be facilitated by a modified process as follows:

[0266] 1. DL signal transmission and preamble transmission (Msg1): The gNB or the RF charging source sends DL signals, which may be PSS, SSS, or LP-WUS, as well as RN16, to the A-IoT devices.

[0267] 2. Charging and communication coordination (Msg2): After receiving the DL signals and RN16, the A-IoT device measures its current power level and communication requirements. Then, the device sends a coordination request to the gNB and the RF charging source, indicating its charging and communication requirements.

[0268] 3. Random access response and contention resolution (Msg3): After receiving the coordination request, the gNB and the RF charging source coordinate their operations to meet the charging and communication requirements of the A-IoT device. Then, the gNB and the RF charging source send a coordination response to the A-IoT device, indicating the coordinated charging and communication plan.

[0269] 4. Acknowledgment (Msg4): After successfully receiving the coordination response, the A-IoT device sends an acknowledgment to the gNB and the RF charging source, completing the coordinated charging and communication process.

[0270] By integrating the coordinated charging and communication protocol, A-IoT devices can significantly improve their network efficiency and energy management, especially in densely populated or network-complex environments. This is particularly beneficial for A-IoT networks as it allows for flexible device charging and communication strategies, which helps optimize device operations even in challenging environments.

[0271] Figure 11(A) is a timing diagram 1100, showing the behavior of an A-IoT device, a gNB, an RF charging source, and the signal transmission between them in the context of the coordinated charging and communication protocol of the A-IoT device.

[0272] Charging Based on Communication Requirements

[0273] Implementing charging based on communication requirements, where the gNB notifies the dedicated RF charging source about the communication requirements of the A-IoT device and the charging source adjusts its charging power accordingly, can significantly improve network efficiency and energy management. This solution, which requires communication between the gNB and the charging source and changes to their operations, can improve the network's ability to power A-IoT devices based on their communication requirements, thereby enhancing the overall performance and reliability of the A-IoT network.

[0274] In a communication - demand - based charging protocol, the gNB and the RF charging source not only communicate independently with the A - IoT devices but also coordinate their operations to optimize device charging based on communication demands. This can be facilitated through the following modification process:

[0275] 1. DL signal transmission and preamble transmission (Msg1): The gNB transmits DL signals, which may be PSS, SSS, or LP - WUS, and RN16 to the A - IoT devices.

[0276] 2. Communication - demand indication (Msg2): After receiving the DL signal and RN16, the A - IoT device measures its current communication demand. Then, the device sends a communication - demand indication to the gNB, indicating its communication demand.

[0277] 3. Communication - demand response and charging adjustment (Msg3): After receiving the communication - demand indication, the gNB notifies the RF charging source about the communication demand of the A - IoT device. The RF charging source then adjusts its charging power accordingly and sends a charging - adjustment response to the A - IoT device.

[0278] 4. Acknowledgment (Msg4): After successfully receiving the charging - adjustment response, the A - IoT device sends an acknowledgment to the gNB and the RF charging source, completing the communication - demand - based charging process.

[0279] By integrating the communication - demand - based charging protocol, A - IoT devices can significantly improve their network efficiency and energy management, especially in densely populated or network - complex environments. This is particularly beneficial for A - IoT networks as it allows for flexible device - charging strategies, which help optimize device operations even in challenging environments.

[0280] Figure 11(B) is the timing diagram 1120, showing the behavior of the A - IoT device, the gNB, the RF charging source, and the signal transfer between them in the context of the communication - demand - based A - IoT device charging protocol.

[0281] Power - aware modulation technology

[0282] Implementing power - aware modulation technology, where the A - IoT device adjusts the modulation type according to its remaining power level, can significantly improve network efficiency and energy management. This solution, which requires changing the modulation technology used by the device, can improve the network's ability to sustain the operation of A - IoT devices, thereby enhancing the overall performance and reliability of the A - IoT network.

[0283] In the power - aware modulation protocol, the A - IoT device not only communicates with the gNB but also adjusts its modulation type during the RACH process. This can be facilitated through the following general RACH process:

[0284] 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 the "query commands" for the A-IoT device.

[0285] 2. Preamble transmission (Msg1): After receiving the DL signal, the A-IoT device generates RN16 and sends it back to the gNB or UE reader. This is done via backscatter communication using ASK or OOK modulation. The modulation type is adjusted according to the remaining power level.

[0286] 3. Random access response (Msg2): The gNB or UE reader sends an acknowledgment signal containing RN16 to the A-IoT device.

[0287] 4. RRC connection request (Msg3): Once the A-IoT device receives the acknowledgment, it sends its EPC to the gNB or UE reader. This is done via backscatter communication using the adjusted modulation type.

[0288] 5. Contention resolution (Msg4): The gNB or UE reader sends a contention resolution message to the A-IoT device, acknowledging the A-IoT device's EPC and completing the RACH procedure.

[0289] By integrating power-aware modulation techniques, A-IoT devices can significantly improve their network efficiency and energy management, especially in power-constrained environments. This is particularly beneficial for A-IoT networks as it allows for flexible power management strategies that help optimize device operation even in challenging environments.

[0290] There are two different ASK modulation examples here that require different power consumptions:

[0291] 1. Binary ASK: This is the simplest form of ASK modulation. In binary ASK, two different amplitudes of the carrier signal are used to represent binary data. The higher amplitude represents binary '1', and the lower amplitude represents binary '0'. This modulation type requires lower power consumption.

[0292] 2. Quadrature ASK: This is a more complex form of ASK modulation. In quadrature ASK, four different amplitudes of the carrier signal are used to represent binary data. Each amplitude can represent two bits of data (00, 01, 10, or 11). Due to the increased complexity, this modulation type requires more power consumption.

[0293] Figure 12(A) is a timing diagram 1200 of a power-aware modulation protocol. 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 information about the behavior of each participant at each step of the process.

[0294] Passive wake-up mechanism

[0295] Implementing a passive wake-up mechanism can significantly improve energy efficiency, where the A-IoT device remains in a low-power sleep mode until it receives a specific signal from the UE. This solution requires changing the device's power management system, which may increase the device's complexity, but has the potential to extend the device's operating life and provide additional processing time for energy-saving measures and energy harvesting.

[0296] The passive wake-up protocol can be outlined by a modified communication process as follows:

[0297] 1. Sleep mode: The A-IoT device remains in a low-power sleep mode to save energy. This mode is maintained until the device receives a specific signal from the UE.

[0298] 2. Wake-up signal reception: Upon receiving a specific signal from the UE, such as LP-WUS, the A-IoT device wakes up and prepares for further communication. LP-WUS serves as the "wake-up command" for the A-IoT device.

[0299] 3. Downlink signal reception: After waking up, the A-IoT device listens for PSS, SSS, or other downlink signals from the UE. These signals serve as the "query command" for the A-IoT device.

[0300] 4. Preamble transmission: After receiving the downlink signal, the A-IoT device generates RN16 and sends it back to the UE. This is done through backscatter communication using ASK or OOK modulation.

[0301] 5. Acknowledgment reception: The UE sends an acknowledgment signal containing RN16 back to the A-IoT device. Upon receiving this acknowledgment, the A-IoT device knows that the UE has successfully received its RN16.

[0302] 6. RRC connection request: Once the A-IoT device receives the acknowledgment, it sends its EPC to the UE. This is done through backscatter communication using ASK or OOK modulation.

[0303] 7. Contention resolution: The UE sends a contention resolution message to the A-IoT device, acknowledging the A-IoT device's EPC and completing the communication process.

[0304] By integrating a passive wake-up mechanism, A-IoT devices can significantly improve their energy efficiency, especially during idle or low-activity periods. This is particularly beneficial for A-IoT devices with diverse behaviors as it allows for flexible power management strategies that can be customized according to the specific needs and characteristics of each device.

[0305] Figure 12(B) is the timing diagram 1220 of the passive wake-up mechanism. In this timing diagram, the "A-IoT device" participant represents the A-IoT device, and the "UE" participant represents the user equipment. 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 process.

[0306] Priority backscattering

[0307] Implementing priority backscattering can significantly improve their energy efficiency and communication reliability, where A-IoT devices prioritize backscattering over other operations when the power level is low. This solution requires complex power management algorithms, which may increase the device complexity, but has the potential to extend the device's operating life and ensure reliable communication under power constraints.

[0308] In the priority backscattering protocol, the A-IoT device not only communicates with the gNB or UE reader but also manages its power consumption based on the remaining power level. This can be facilitated through a modified communication process as follows:

[0309] 1. Power level monitoring: The A-IoT device continuously monitors its remaining power level. When the power level is low, the device switches to an energy-saving mode where it prioritizes backscattering over other operations.

[0310] 2. Downlink signal reception: The A-IoT device listens for PSS, SSS, or other downlink signals from the gNB or UE reader. These signals serve as the "query commands" for the A-IoT device.

[0311] 3. Preamble transmission: After receiving the downlink signal, the A-IoT device generates RN16 and sends it back to the gNB or UE reader. This is done through priority backscattering communication using ASK or OOK modulation.

[0312] 4. Acknowledgment reception: The gNB or UE reader sends an acknowledgment signal containing RN16 back to the A-IoT device. After receiving this acknowledgment, the A-IoT device knows that the gNB or UE reader has successfully received its RN16.

[0313] 5. RRC connection request: Once the A-IoT device receives the acknowledgment, it sends its EPC to the gNB or UE reader. This is done through priority backscattering communication using ASK or OOK modulation.

[0314] 6. Competition resolution: The gNB or UE reader sends a competition resolution message to the A-IoT device to confirm the EPC of the A-IoT device and complete the communication process.

[0315] By integrating priority backscattering, A-IoT devices can significantly improve their energy efficiency and communication reliability, especially under low-power conditions. This is particularly beneficial for A-IoT devices with different behaviors as it allows for flexible power management strategies that can be customized according to the specific needs and characteristics of each device.

[0316] Figure 13(A) is a timing diagram 1300 of the priority backscattering mechanism. 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 information about the behavior of each participant at each step of the process.

[0317] Battery level reporting

[0318] Implementing battery level reporting can significantly improve their energy management and overall network efficiency, where the A-IoT devices include battery level information in the backscattered signal. This solution requires changing the communication protocol, which may increase the complexity of the devices, but has the potential to provide valuable information for power management strategies and decision-making processes.

[0319] In the battery level reporting protocol, the A-IoT devices not only communicate with the gNB or UE reader but also report their remaining battery levels. This can be facilitated through a modified communication process as follows:

[0320] 1. Battery level monitoring: The A-IoT devices continuously monitor their remaining battery levels. The battery level information is prepared to be included in the backscattered signal.

[0321] 2. DL signal reception: The A-IoT devices listen for PSS, SSS, or other downlink signals from the gNB or UE reader. These signals serve as the "query commands" for the A-IoT devices.

[0322] 3. Preamble transmission with battery level information: After receiving the downlink signal, the A-IoT devices generate RN16 and send it back to the gNB or UE reader. This is done through backscatter communication using ASK or OOK modulation. Along with RN16, the A-IoT devices also include the battery level information in the backscattered signal.

[0323] 4. Confirm Signal Reception: The gNB or UE Reader sends a confirmation signal to the A-IoT device, which includes RN16. After receiving this confirmation, the A-IoT device knows that the gNB or UE Reader has successfully received its RN16.

[0324] 5. RRC Connection Request with Battery Level Information: Once the A-IoT device receives the confirmation, it sends its EPC to the gNB or UE Reader. This is done via backscatter communication using ASK or OOK modulation. Along with the EPC, the A-IoT device also includes battery level information in the backscatter signal.

[0325] 6. Contention Resolution: The gNB or UE Reader sends a contention resolution message to the A-IoT device, confirming the A-IoT device's EPC and completing the communication process.

[0326] By integrating battery level reporting, the A-IoT device can significantly improve its energy management and overall network efficiency. This is particularly beneficial for A-IoT devices with different behaviors as it allows for flexible power management strategies that can be customized according to the specific needs and characteristics of each device.

[0327] Figure 13(B) is a timing diagram 1320 of the battery level reporting mechanism. 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 information about the behavior of each participant at each step of the process.

[0328] Charge Indication in gNB Signals

[0329] When the A-IoT device is being charged by a dedicated RF power source, the gNB can include an indication in its signal.

[0330] The implementation of charge indication in gNB signals can significantly enhance energy management and overall network efficiency, where the gNB includes an indication in its signal when the A-IoT device is being charged by a dedicated RF power source. This solution requires changes to the communication protocol, which may increase the complexity of the gNB, but has the potential to provide valuable information for power management strategies and decision-making processes.

[0331] In the charge indication protocol, the gNB not only communicates with the A-IoT device but also indicates the charging status of the device.

[0332] This can be achieved through a modified communication flow as follows:

[0333] 1. Charging status monitoring: The gNB continuously monitors the charging status of the A-IoT device. When the A-IoT device is charged by a dedicated RF charging source, the gNB prepares to include a charging indication in its signal.

[0334] 2. DL signal transmission with charging indication: The gNB sends the PSS, SSS, or other DL signals to the A-IoT device. These signals act as "query commands" for the A-IoT device. In addition to the DL signals, the gNB also includes a charging indication in its signal.

[0335] 3. Charging indication reception and preamble transmission: Upon receiving the DL signal with the charging indication, the A-IoT device identifies its charging status and prepares for further communication. Then, the A-IoT device generates RN16 and sends it back to the gNB. This is done through backscatter communication using ASK or OOK modulation.

[0336] 4. Acknowledgment transmission: The gNB sends an acknowledgment signal back to the A-IoT device, which includes RN16. Upon receiving this acknowledgment, the A-IoT device knows that the gNB has successfully received its RN16.

[0337] 5. RRC connection request: Once the A-IoT device receives the acknowledgment, it can send its EPC to the gNB. This is done through backscatter communication using ASK or OOK modulation.

[0338] 6. Contention resolution: The gNB sends a contention resolution message to the A-IoT device, acknowledging the A-IoT device's EPC and completing the communication process.

[0339] By incorporating the charging indication into the gNB signal, the gNB can significantly enhance its energy management and overall network efficiency. This is particularly beneficial for A-IoT networks with diverse device behaviors, as it allows for flexible power management strategies that can be customized according to the specific needs and characteristics of each device.

[0340] Figure 14(A) is a timing diagram 1400 of the charging indication mechanism. In this timing diagram, the "gNB" participant represents the gNB, and the "A-IoT device" participant represents the A-IoT device. 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 process.

[0341] Adaptive antenna beamforming for charging

[0342] The gNB and the dedicated RF charging source can collaborate to use adaptive antenna beamforming to concentrate the RF energy on the A-IoT device that most needs charging.

[0343] Adaptive antenna beamforming for charging A-IoT devices

[0344] The implementation of adaptive antenna beamforming for charging can significantly enhance energy management and overall network efficiency, where the gNB and dedicated RF charging source cooperate to concentrate RF energy on the A-IoT devices that most need charging. This solution requires changes to the antenna designs and operations of the gNB and charging source, which may increase their complexity, but has the potential to provide targeted and efficient charging for A-IoT devices.

[0345] In the adaptive antenna beamforming protocol, the gNB and dedicated RF charging source work together to optimize the charging process of A-IoT devices. This can be achieved by modifying the charging process as follows:

[0346] 1. Battery level monitoring: The gNB continuously monitors the battery levels of A-IoT devices in the network.

[0347] 2. Charging priority determination: Based on the battery level information, the gNB determines the charging priority for each A-IoT device. Devices with lower battery levels have higher charging priorities.

[0348] 3. Adaptive beamforming coordination: The gNB and dedicated RF charging source collaborate to use adaptive antenna beamforming technology to focus RF energy on the A-IoT devices that most need charging, according to the determined charging priorities.

[0349] 4. Charging process: The A-IoT devices receive the focused RF energy and convert it into electrical energy to charge their batteries.

[0350] 5. Charging status update: The gNB and dedicated RF charging source continuously update the charging status of the A-IoT devices and adjust the adaptive antenna beamforming accordingly.

[0351] By adopting adaptive antenna beamforming for charging, the gNB and dedicated RF charging source can significantly enhance energy management and overall network efficiency. This is particularly beneficial for A-IoT networks with diverse device behaviors, as it allows for flexible power management strategies that can be customized according to the specific needs and characteristics of each device.

[0352] Figure 14(B) is a timing diagram 1420 of an adaptive antenna beamforming mechanism. In this timing diagram, the "gNB" participant represents the gNB, the "RF charging source" participant represents the dedicated RF charging source, and the "A-IoT device" participant represents the A-IoT device. The arrows represent the communication and coordination between the participants.

[0353] Solar energy harvesting

[0354] Implementing solar energy harvesting, where A-IoT devices are equipped with solar panels to harvest energy from indoor light, can significantly enhance their energy management and overall network efficiency. This solution, which requires adding solar panels to A-IoT devices, can significantly extend the battery life of the devices, especially in well-lit environments.

[0355] In the solar energy harvesting protocol, A-IoT devices not only communicate with gNB or UE readers but also continuously harvest energy from indoor light. This can be facilitated through the following modified operational procedures:

[0356] 1. Solar panel installation: Install solar panels on A-IoT devices. These solar panels are capable of converting light energy into electrical energy to power the devices.

[0357] 2. Light energy harvesting: A-IoT devices continuously harvest energy from indoor light through their solar panels. This harvested energy is stored in the device's battery for later use.

[0358] 3. DL signal reception: A-IoT devices listen for PSS, SSS, or other DL signals from gNB or UE readers. These signals serve as "query commands" for A-IoT devices.

[0359] 4. Preamble transmission: After receiving the DL signal, A-IoT devices generate RN16 and send it back to the gNB or UE reader. This is done through backscatter communication using ASK or OOK modulation.

[0360] 5. Acknowledgment of reception: The gNB or UE reader sends an acknowledgment signal containing RN16 to the A-IoT device. After receiving this acknowledgment, the A-IoT device knows that the gNB or UE reader has successfully received its RN16.

[0361] 6. RRC connection request: Once the A-IoT device receives the acknowledgment, it sends its EPC to the gNB or UE reader. This is done through backscatter communication using ASK or OOK modulation.

[0362] 7. Contention resolution: The gNB or UE reader sends a contention resolution message to the A-IoT device, acknowledging the A-IoT device's EPC and completing the communication process.

[0363] By integrating solar energy harvesting, A-IoT devices can significantly enhance their energy management and overall network efficiency. This is particularly beneficial for A-IoT devices in well-lit environments as it allows for flexible power management strategies that can be customized according to the specific needs and characteristics of each device.

[0364] Figure 15(A) is a timing diagram 1500 of a solar energy collection mechanism. 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 information about the behavior of each participant in each step of the process.

[0365] Adaptive indoor lighting control

[0366] Figure 15(B) is a schematic diagram 1520, which describes the implementation of a system for controlling indoor light intensity based on the power demand of the A-IoT device. For example, when the battery level of the device is low, the light intensity can be increased to provide more energy for solar energy collection.

[0367] Implementing adaptive indoor lighting control, where the system controls the indoor light intensity according to the power demand of the A-IoT device, can significantly enhance their energy management and overall network efficiency. This solution, which requires a controllable lighting system and intelligent control algorithms, is moderately feasible but has the potential to provide targeted and efficient energy supply for A-IoT devices, especially those equipped with solar panels for energy collection.

[0368] In the adaptive indoor lighting control protocol, the lighting control system not only provides lighting for the indoor environment but also adjusts the light intensity according to the power demand of the A-IoT device. This can be facilitated by the following modified operation process:

[0369] 1. Battery level monitoring: The lighting control system continuously monitors the battery levels of A-IoT devices in the network.

[0370] 2. Light intensity adjustment: Based on the battery level information, the lighting control system determines the optimal light intensity for each A-IoT device. For example, when the battery level of the device is low, the light intensity can be increased to provide more energy for solar energy collection.

[0371] 3. Solar energy collection: The A-IoT device continuously collects energy from the controlled indoor light through its solar panel. This collected energy is stored in the device's battery for later use.

[0372] 4. DL signal reception: The A-IoT device listens for PSS, SSS, or other DL signals from the gNB or UE reader. These signals serve as the "query commands" for the A-IoT device.

[0373] 5. Preamble transmission: After receiving the DL signal, the A-IoT device generates RN16 and sends it back to the gNB or UE reader. This is done through backscatter communication using ASK or OOK modulation.

[0374] 6. Acknowledgment of Reception: The gNB or UE Reader sends an acknowledgment signal containing RN16 to the A-IoT device. Upon receiving this acknowledgment, the A-IoT device knows that the gNB or UE Reader has successfully received its RN16.

[0375] 7. RRC Connection Request: Once the A-IoT device receives the acknowledgment, it sends its EPC to the gNB or UE Reader. This is done via backscatter communication using ASK or OOK modulation.

[0376] 8. Contention Resolution: The gNB or UE Reader sends a contention resolution message to the A-IoT device, acknowledging the A-IoT device's EPC and completing the communication process.

[0377] By integrating adaptive indoor lighting control, the lighting control system can significantly enhance energy management and overall network efficiency. This is particularly beneficial for A-IoT devices in a controllable lighting system environment, as it allows for flexible power management strategies that can be customized according to the specific needs and characteristics of each device.

[0378] Figure 15(C) is the timing diagram 1540 for the adaptive indoor lighting control mechanism. In this timing diagram, the "Lighting Control System" participant represents the lighting control system, 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 and coordination between the participants, and the annotations provide additional information about the behavior of each participant at each step of the process.

[0379] Lighting-Based Power Management

[0380] Implement a power management strategy that takes into account the availability of sunlight for solar harvesting. For example, when the indoor light is bright, the A-IoT device can perform more power-intensive operations and switch to a low-power mode when the light is dim. This solution is moderately feasible as it requires the installation of light sensors and complex power management algorithms on the device.

[0381] These solutions aim to ensure the continuous discoverability and reliable communication of devices by balancing power consumption and device functionality, regardless of the device's battery level.

[0382] Lighting-Based Power Management of A-IoT Devices

[0383] Implement lighting-based power management, where the power management strategy takes into account the light availability for solar harvesting, which can significantly improve the energy management and overall network efficiency of A-IoT devices. This solution requires the installation of light sensors and complex power management algorithms on the devices, which is moderately feasible but has the potential to provide flexible and efficient power management for A-IoT devices, especially those equipped with solar panels for energy harvesting.

[0384] In the lighting-based power management protocol, the A-IoT device not only communicates with the gNB or UE reader but also adjusts its operations according to the light availability for solar harvesting. This can be facilitated by the following modified operation procedure:

[0385] 1. Light sensor installation and monitoring: Install light sensors on the A-IoT device. These sensors continuously monitor the light availability in the environment.

[0386] 2. Power management strategy implementation: Based on the sensor-based light availability information, the A-IoT device implements a power management strategy. For example, when the indoor light is bright, the device can perform more power-intensive operations and switch to a low-power mode when the light is dim.

[0387] 3. DL reception: The A-IoT device listens for PSS, SSS, or other DL signals from the gNB or UE reader. These signals serve as the "query commands" for the A-IoT device.

[0388] 4. Preamble transmission: After receiving the DL signal, the A-IoT device generates RN16 and sends it back to the gNB or UE reader. This is done through backscatter communication using ASK or OOK modulation.

[0389] 5. Acknowledgment reception: The gNB or UE reader sends an acknowledgment signal containing RN16 to the A-IoT device. After receiving this acknowledgment, the A-IoT device knows that the gNB or UE reader has successfully received its RN16.

[0390] 6. RRC connection request: Once the A-IoT device receives the acknowledgment, it sends its EPC to the gNB or UE reader. This is done through backscatter communication using ASK or OOK modulation.

[0391] 7. Contention resolution: The gNB or UE reader sends a contention resolution message to the A-IoT device, acknowledging the A-IoT device's EPC and completing the communication process.

[0392] By integrating lighting-based power management, A-IoT devices can significantly improve their energy management and overall network efficiency. This is particularly beneficial for A-IoT devices in environments with changing light conditions, as it allows for flexible power management strategies that can be customized according to the specific needs and characteristics of each device.

[0393] Figure 16 It is the timing diagram 1600 for the lighting-based power management mechanism. 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 information about the behavior of each participant at each step of the process.

[0394] These solutions aim to ensure the continuous discoverability and reliable communication of devices by balancing power consumption and device functionality, regardless of the device's battery level.

[0395] In one aspect, the UE includes:

[0396] One or more non-transitory computer-readable media having computer-executable instructions thereon, 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:

[0397] Receive a DL signal containing PSS, SSS, or LP-WUS and RN16 from a base station (BS) if the UE is an A-IoT device and is in the state of receiving the signal.

[0398] Determine the power level of the device based on the received DL signal and verify the received RN16 if the DL signal is successfully decoded and the RN16 is valid.

[0399] Execute a power management strategy based on the determined power level and send RN16 together with EPC to the BS using backscatter communication of ASK or OOK if the power level is determined and the RN16 is verified.

[0400] Transmit a confirmation message to the BS after receiving the final confirmation message from the BS if the final confirmation message includes RN16 and EPC.

[0401] Figure 17FIG. 1700 shows an example communication system in accordance with an embodiment of the present disclosure, which includes an example communication device 1710 and an example network device 1720. The communication device 1710 and the network device 1720 may perform various functions to implement the solutions, techniques, processes, and methods related to user equipment and network devices in mobile communication using on-demand reference signals as described herein, including the scenarios / solutions described above and the processes 1800 and 1900 described below.

[0402] 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 smartwatch, a personal digital assistant, a digital camera, or a computing device, such as a tablet computer, a laptop computer, 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), Narrowband Internet of Things (NB-IoT), or Industrial Internet of Things (IIoT) device, such as a fixed or static device, a home appliance, 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 Figure 17 at least some of the components shown in FIG. 1712, such as a processor 1712. The communication device 1710 may also include one or more other components (e.g., an internal power supply, a display device, and / or a user interface device) that are not relevant to the solutions proposed in the present disclosure. Therefore, for the sake of brevity, these components of the communication device 1710 are neither shown in Figure 17 FIG. 1712 nor described hereinafter.

[0403] 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 cell, 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 a 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 Figure 17At least some of the components shown, such as processor 1722. Network device 1720 may also include one or more other components that are not relevant to the solutions proposed in the present disclosure (e.g., an internal power supply, a display device, and / or a user interface device). Therefore, for the sake of brevity, these components of network device 1720 are neither shown in Figure 17 nor described hereinafter.

[0404] In one aspect, each of 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, even though the singular term "a processor" is used herein to refer to processor 1712 and processor 1722, in certain embodiments according to the present disclosure, each of processor 1712 and processor 1722 may include multiple processors, while in other embodiments, it includes a single processor. In another aspect, each of processor 1712 and processor 1722 may be implemented in the form of hardware (and, optionally, firmware) that includes electronic components such as, 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, which are configured and arranged to achieve a specific purpose according to the present disclosure. In other words, in at least some embodiments, processor 1712 and processor 1722 are special-purpose machines that are specifically designed, arranged, and configured to perform specific tasks of autonomous reliability enhancement included in devices (e.g., represented by communication device 1710) and networks (e.g., represented by network device 1720) according to various embodiments of the present disclosure.

[0405] In some embodiments, the communication device 1710 may further include a transceiver 1716 coupled to the processor 1712, capable of wirelessly transmitting and receiving data. In some embodiments, the communication device 1710 may further include a memory 1714 coupled to the processor 1712, accessible by the processor 1712 and storing data therein. In some embodiments, the network device 1720 may further include a transceiver 1726 coupled to the processor 1722, capable of wirelessly transmitting and receiving data. In some embodiments, the network device 1720 may further include a memory 1724 coupled to the processor 1722, accessible by the processor 1722 and storing data therein. Thus, the communication device 1710 and the network device 1720 can communicate wirelessly via their respective transceivers 1716 and 1726. For better understanding, the following provides a description of the operations, functions, and capabilities of the communication device 1710 and the network device 1720, which is provided in the context of a mobile communication environment, where the communication device 1710 is implemented as a communication device or UE, and the network device 1720 is implemented as a network node of a communication network.

[0406] FIG. 18(A) is a flowchart 1800 for processing the uncertainty of the battery levels of the reader device and the A-IoT device. The process involves interactions among the gNB, the UE (e.g., UE 744), and the A-IoT device (e.g., A-IoT device 746).

[0407] At block 1802, the reader device may send a DL signal and authentication information to the A-IoT device (e.g., A-IoT device 746). The reader device may be the UE 744 or the gNB.

[0408] Then, at block 1804, after the A-IoT device 746 has authenticated the authentication information, the reader device, e.g., the UE 744, may receive a unique EPC from the A-IoT device 746.

[0409] Finally, at block 1806, the reader device may send an acknowledgement message to the A-IoT device 746 in response to successfully receiving the EPC from the A-IoT device 746.

[0410] In some embodiments, the DL signal may include at least one of PSS, SSS, or LP-WUS, and the authentication information includes RN16.

[0411] In some embodiments, the process may further include: receiving a power level indication from the A-IoT device 746. In some embodiments, the power level indication and the EPC may be received in a single response from the A-IoT device 746, or in separate responses from the A-IoT device 746.

[0412] In some embodiments, the power level indication may include at least one of the following: a signal strength indicator for indicating the strength of the signal received by the A-IoT device; a quality indicator for indicating the quality of the signal; a binary indicator for indicating whether the power level of the A-IoT device is above or below a threshold; or a battery level indicator for indicating the remaining battery life of the A-IoT device.

[0413] In some embodiments, the DL signal may include instructions for measuring and reporting the power level of the A-IoT device 746.

[0414] In some embodiments, the process may further include: configuring at least one of the transmission power, modulation and coding scheme, or scheduling decision based on the received power level indication. In some embodiments, the power level indication may include a low power mode indication.

[0415] In some embodiments, the authentication information may be transmitted together with the DL signal.

[0416] In some embodiments, the process may further include: receiving the authentication information from the A-IoT device 746; and sending an acknowledgement message containing the authentication information to the A-IoT device 746.

[0417] FIG. 18(B) is another flowchart 1850 for processing the reader device and the A-IoT device regarding battery level uncertainty.

[0418] At block 1852, the A-IoT device, such as the A-IoT device 746, may receive the DL signal and the authentication information from the reader device. The reader device may be a UE, such as the UE 744, or a gNB.

[0419] Then, at block 1854, the A-IoT device 746 may verify the authentication information.

[0420] Subsequently, at block 1856, after verifying the authentication information, the A-IoT device 746 may send a unique EPC to the reader device.

[0421] Finally, at block 1858, the A-IoT device 746 may receive an acknowledgement message containing the EPC from the reader device.

[0422] In some embodiments, the DL signal may include at least one of PSS, SSS, or LP-WUS, and the authentication information may include RN16.

[0423] In some embodiments, the process may include: sending a power level indication to the reader device. In some embodiments, the power level indication and the EPC may be sent to the reader device in a single response or in separate responses.

[0424] In some embodiments, the power level indication may include at least one of the following: a signal strength indicator for indicating the strength of the signal received by the A-IoT device 746; a quality indicator for indicating the quality of the signal; a binary indicator for indicating whether the power level of the A-IoT device 746 is above or below a threshold; or a battery charge indicator for indicating the remaining battery life of the A-IoT device 746.

[0425] In some embodiments, the process may include: measuring the power level of the A-IoT device 746; and reporting the power level according to an instruction received in the DL signal.

[0426] In some embodiments, the process may include: measuring the current power level of the A-IoT device 746; switching to a low power mode when the current power level is below a threshold; and including a low power mode indication in the power level indication.

[0427] In some embodiments, transmitting the authentication information, the power level indication, and the EPC to the reader device may include backscatter communication using ASK or OOK modulation.

[0428] In some embodiments, the process may include: collecting energy through a lighting energy harvester; and storing the collected energy in the battery of the A-IoT device 746. In some embodiments, the energy collection is controlled by a lighting control system that: monitors the battery charge of the A-IoT device 746; and determines the optimal light intensity of the A-IoT device 746 based on the monitored battery charge.

[0429] It should be understood that the specific order or hierarchy of the blocks in the process / flowchart of the present invention is an example of an exemplary method. Therefore, it should be understood that the specific order or hierarchy of the blocks in the process / flowchart can be rearranged based on design preferences, and some blocks can be further combined or omitted. The appended 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.

[0430] The foregoing description is provided to enable a person of ordinary skill in the art to make and use various aspects of the present invention described herein. Persons of ordinary skill in the art can readily make various modifications to these aspects and can apply the general principles defined in the present invention to other aspects. Accordingly, the claims are not intended to be limited to the aspects shown in the present invention, but should be accorded the full scope consistent with the language of the claims. Herein, unless specifically stated otherwise, reference to an element in the singular is not intended to mean “one and only one” but rather “one or more.” The word “exemplary” is used herein to mean “serving as an example, instance, or illustration.” Any aspect described herein as “exemplary” is not necessarily to be construed as preferred or advantageous over other aspects. Unless specifically stated otherwise, the term “some” means 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 “any combination of A, B, C, or any thereof” include any combination of A, B, and / or C and may include multiple As, multiple Bs, or multiple Cs. 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 “any combination of A, B, C, or any thereof” may be only A, only B, only C, A and B, A and C, B and C, or A and B and C, where any of these combinations may include one or more of A, B, or C. All structural and functional equivalents of the elements of the various aspects of the present invention known or later coming to be known to persons of ordinary skill in the art are expressly incorporated herein by reference and are intended to be covered by the claims. In addition, the disclosures of the present invention are not intended to be dedicated to the public regardless of whether such disclosure is explicitly recited in the claims. The words “module,” “mechanism,” “element,” “device,” etc. are not intended to be substitutes for the word “means.” Thus, an element should not be construed as a means-plus-function element unless the phrase “means for” is used to expressly recite the element in the claim.

Claims

1. A method for wireless communication, performed by a reader device, the method comprising: Send downlink signals and verification information to environmental IoT devices; After the ambient IoT device verifies the verification information, receiving a unique electronic product code from the ambient IoT device; as well as A confirmation message is sent to the ambient IoT device in response to successfully receiving the electronic product code from the ambient IoT device.

2. The method for wireless communication according to claim 1, wherein: The downlink signal includes at least one of a primary synchronization signal, a secondary synchronization signal or a low-power wake-up signal, and the verification information includes a random 16-bit number RN16.

3. The method for wireless communication according to claim 1, wherein: Further including: A power level indication is received from the ambient IoT device.

4. The method for wireless communication according to claim 3, wherein: The power level indication and the electronic product code are received from the ambient IoT device in a single response or are received from the ambient IoT device in separate responses.

5. The method for wireless communication according to claim 3, wherein: The power level indication includes at least one of the following: A signal strength indicator, used to indicate the strength of the signal received by the IoT device in the environment; A quality indicator, used to indicate the quality of the signal; A binary indicator indicating whether the power level of the ambient IoT device is above or below a threshold; or A battery level indicator to indicate the remaining battery life of the ambient IoT device.

6. The method for wireless communication according to claim 3, wherein: The downlink signal includes instructions for measuring and reporting the power level of the ambient IoT device.

7. The method for wireless communication according to claim 3, wherein: Further including: At least one of a transmission power, a modulation and coding scheme, or a scheduling decision is configured based on the received power level indication.

8. The method for wireless communication according to claim 3, wherein: The power level indication includes a low power mode indication.

9. The method for wireless communication according to claim 1, wherein: The verification information is transmitted together with the downlink signal.

10. The method for wireless communication according to claim 1, wherein: Further including: receiving the verification information from the ambient IoT device; and A confirmation message containing the verification information is sent to the environmental IoT device.

11. A method for wireless communication, performed by an ambient IoT device, the method comprising: receiving a downlink signal and verification information from a reader device; verifying the verification information; After verifying the authentication information, sending a unique electronic product code to the reader device; and A confirmation message including the electronic product code is received from the reader device.

12. The method for wireless communication according to claim 11, wherein: The downlink signal includes at least one of a primary synchronization signal, a secondary synchronization signal or a low-power wake-up signal, and the verification information includes a random 16-bit number RN16.

13. The method for wireless communication according to claim 11, wherein: Further including: A power level indication is sent to the reader device.

14. The method for wireless communication according to claim 13, wherein: The power level indication and the electronic product code are sent to the reader device in a single response or in separate responses.

15. The method for wireless communication according to claim 13, wherein: The power level indication includes at least one of the following: A signal strength indicator, used to indicate the strength of the signal received by the IoT device in the environment; A quality indicator, used to indicate the quality of the signal; A binary indicator indicating whether the power level of the ambient IoT device is above or below a threshold; or A battery level indicator to indicate the remaining battery life of the ambient IoT device.

16. The method for wireless communication according to claim 13, wherein: Further including: Measure the power levels of IoT devices in the environment; and The power level is reported according to instructions received in the downlink signal.

17. The method for wireless communication according to claim 13, wherein: Further including: Measure the current power level of the IoT devices in the environment; Switching to a low power consumption mode when the current power level is below a threshold; and The power level indication includes a low power consumption mode indication.

18. The method for wireless communication according to claim 13, wherein: Transmitting the authentication information, the power level indication, and the electronic product code to the reader device includes backscatter communications using amplitude keying or on-off keying modulation.

19. The method for wireless communication according to claim 11, wherein: Further including: Harvesting energy through lighting energy harvesters; as well as The harvested energy is stored in the battery of the ambient IoT device.

20. The method for wireless communication according to claim 19, wherein: This energy harvesting is controlled by a lighting control system where: Monitor the battery level of IoT devices in the environment; and The optimal light intensity for IoT devices in the environment is determined based on the monitored battery power.

21. 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 20.

22. 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 20.

Images