An internet of things communication method and apparatus

Abstract

The embodiment of the application provides a kind of Internet of Things communication method and device, it is related to communication field, can save the power consumption of Internet of Things equipment, adapt to the demand of massive Internet of Things system, guarantee the efficient and stable operation of communication system.The method is applied to Internet of Things equipment, comprising: receiving synchronization signal;At first time, start first timer, the duration of first timer is determined according to first offset value, first time is equal to or later than the end time of synchronization signal;When first timer expires, detect beacon signal in first window, the start time of first window is first timer expiration time;In the case where beacon signal is detected in first window, receive PRDCH;In the case where beacon signal is not detected in first window, enter sleep state.

Description

Technical Field

[0001] This application relates to the field of communications, and more particularly to an Internet of Things (IoT) communication method and apparatus. Background Technology

[0002] In the Ambient Internet of Things (A-IoT) system, the communication transmission method between the reader and the IoT device is defined. The channel through which the reader sends data to the device is called the R2D channel (Reader to Device, similar to the downlink channel in a cellular communication system), and the channel through which the device sends data to the reader is called the D2R channel (Device to Reader, similar to the uplink channel in a cellular communication system). For the R2D channel, IoT devices (such as Device2b / C, the device type defined in 3GPP Release 20 for extreme capabilities and complex scenarios) exhibit extreme power consumption constraints during wake-up and data reception (i.e., wake-up and data reception are relatively power-intensive, but IoT devices (such as Device2b / C) are strictly required to minimize power consumption, hence the so-called extreme power consumption constraint). This poses a significant challenge to the long-term battery life of IoT devices in scenarios with dense outdoor deployments.

[0003] Currently, by using downlink synchronization signals and downlink control information (such as L1-Header), the device can pre-filter the data before it is fully decoded (PRDCH), providing a key basis for IoT devices to judge transmission correlation in advance and avoid invalid wake-ups, thereby saving power consumption of IoT devices.

[0004] However, the aforementioned filtering mechanism suffers from a fundamental inefficiency. When the Reader frequently sends downlink transmissions in intensive scenarios, the device needs to perform complete PRDCH decoding or L1-Header decoding and verification (e.g., Rel 19 requires PRDCH decoding, or Rel 20 requires L1-Header decoding). This "decode first, then identify" mechanism means that the device needs to decode the PRDCH or L1-Header when processing irrelevant transmissions (which account for the vast majority) and valid transmissions, resulting in high power consumption for IoT devices and failing to meet the design goal of extremely low power consumption. Summary of the Invention

[0005] This application provides an Internet of Things (IoT) communication method and apparatus that can save power consumption of IoT devices, adapt to the needs of massive IoT systems, and ensure the efficient and stable operation of the communication system.

[0006] To achieve the above objectives, the embodiments of this application adopt the following technical solutions:

[0007] In a first aspect, an Internet of Things (IoT) communication method is provided, applied to IoT devices, comprising: receiving a synchronization signal; starting a first timer at a first moment, the duration of the first timer being determined based on a first offset value, the first moment being equal to or later than the end moment of the synchronization signal; when the first timer times out, detecting a beacon signal in a first window, the start moment of the first window being the timeout moment of the first timer; if a beacon signal is detected in the first window, receiving data from a physical reader to the device channel PRDCH; if no beacon signal is detected in the first window, entering a sleep state.

[0008] Based on the method provided in this application, IoT devices can detect beacon signals in a first window. If a beacon signal is detected, they can receive the PRDCH; if no beacon signal is detected, they can go into sleep mode, saving power. This eliminates the need for each IoT device to perform PRDCH decoding, adapting to the needs of massive IoT systems and ensuring the efficient and stable operation of the communication system.

[0009] In one possible implementation, before receiving the synchronization signal, the method further includes: receiving a broadcast message, the broadcast message including at least one of a first offset set, a total number of groups, and information of a first function; wherein the first offset set includes N offset values, the N offset values ​​are time offset values ​​relative to a first time moment, and the N time offset values ​​include the first offset value; wherein N is an integer greater than or equal to 1; the total number of groups is used to indicate the number of IoT device groups assigned by the reader; and the first function is used to map IoT devices to the first offset value.

[0010] In this way, a set of system parameters (i.e., the first offset set, the total number of groups, and the information of the first function) are broadcast on the network side. After receiving the system parameters, the device can determine a time offset value (e.g., the first offset value) from the first offset set based on the first function (e.g., a hash function), the number of groups, and its own device identifier. This time offset value is the time offset value corresponding to the group to which the device belongs (i.e., the time offset value corresponding to the device itself). This enables a "group self-homing" mechanism, where the device determines the time offset value corresponding to its own group through "self-computation". Compared to the method of "explicitly allocating" groups to a massive number of devices and mapping them to specific offset values ​​(e.g., read / write devices explicitly allocating groups and offsets to each device through signaling), which results in high signaling overhead and management complexity, the "group self-homing" mechanism can reduce signaling overhead and management complexity, save device power consumption, and has high network scalability.

[0011] In one possible implementation, when a beacon signal is detected in the first window, receiving the PRDCH from the physical reader / writer via the device channel includes: starting a second timer when a beacon signal is detected in the first window. The duration of the second timer is determined based on the difference between a second offset value and a first offset value, and a preset duration. The second offset value is the largest time offset value in the first offset set. At the timeout of the second timer, the main decoder is woken up, and the PRDCH is received in the second window. The start time of the second window is determined based on the timeout of the second timer. It should be noted that when the second timer times out (i.e., at the timeout of the second timer), the beacon listening window of the last group (i.e., the beacon listening window of the group corresponding to the largest time offset value (second offset value) in the first offset set) has also ended; that is, the beacon listening windows of all groups have ended. Therefore, when the second timer times out or after the second timer times out, the Reader performs data transmission (i.e., sends the PRDCH), which avoids the problem of mutual interference between the beacon signal and the PRDCH.

[0012] In one possible implementation, the difference between any two distinct offset values ​​among the N offset values ​​is greater than the sum of the IoT device's maximum timing error and the wireless channel delay spread. This ensures that the listening windows of different groups do not overlap, avoiding confusion and false wake-ups.

[0013] In one possible implementation, the first function includes at least one of a hash function, a bit extraction operation function, a direct modulo operation function, a CRC check operation function, and a segmented mapping function. For example, the bit extraction operation function can be used to directly extract the last few bits of the device global ID (e.g., a 64-bit Device_Global_ID) as an index (e.g., the last 4 bits when the device global ID is 16). This method is simple to calculate and has low power consumption. Similarly, the CRC check operation function can be used to calculate the CRC value of the device global ID and then take the modulo of N (or take the modulo of N and add one). This method avoids group congestion caused by ID allocation patterns.

[0014] In one possible implementation, the method further includes: after receiving a broadcast message, obtaining the device identifier of the IoT device; performing a hash operation on the device identifier based on a hash function and the total number of groups to obtain a first index; and querying from a first offset set according to the first index to obtain a first offset value. In this way, the device determines the time offset value corresponding to its own group through a "self-calculation" method. Compared to the method of "explicitly assigning" groups to massive numbers of devices and mapping them to specific offset values ​​on the network side (e.g., read / write devices explicitly assigning groups and offsets to each device via signaling), which results in high signaling overhead and management complexity, the "group self-homing" mechanism can reduce signaling overhead and management complexity, save device power consumption, and has high network scalability.

[0015] In one possible implementation, the beacon signal does not contain information that needs to be digitally decoded; the information that does need to be digitally decoded includes the device identifier and / or a cyclic redundancy check (CRC) code. This simplifies the decoding of the beacon signal and saves power.

[0016] In one possible implementation, the beacon signal is modulated differently from the PRDCH. This ensures that the device can clearly distinguish between the wake-up beacon signal and "data" (such as the PRDCH) within the listening window.

[0017] In one possible implementation, receiving the physical reader / writer's device channel (PRDCH) includes: decoding the device identifier and a first CRC code in the PRDCH; calculating a second CRC code based on the device identifier in the PRDCH; if the first CRC code and the second CRC code are different, entering a sleep state; if the first CRC code and the second CRC code are the same, determining whether the IoT device's device identifier is the same as the device identifier carried in the PRDCH; if the IoT device's device identifier is different from the device identifier carried in the PRDCH, entering a sleep state; if the IoT device's device identifier is the same as the device identifier carried in the PRDCH, continuing to decode the PRDCH and executing the target task (e.g., collecting temperature, image, sound, etc.). This allows for accurate identification of the target device, avoiding the problem of high power consumption caused by invalid wake-ups.

[0018] Secondly, an IoT communication method is provided for a reader / writer, comprising: sending a synchronization signal; starting a first timer at a first moment, the duration of which is determined based on a first offset value, the first moment being equal to or later than the end moment of the synchronization signal; when the first timer times out, sending a beacon signal in a first window, the start moment of which is the timeout moment of the first timer; and after sending the beacon signal, sending the physical reader / writer to the device channel PRDCH.

[0019] In one possible implementation, before sending the synchronization signal, the method further includes: sending a broadcast message, the broadcast message including at least one of a first offset set, a total number of groups, and information of a first function; wherein the first offset set includes N offset values, the N offset values ​​are time offset values ​​relative to a first time moment, and the N time offset values ​​include the first offset value; wherein N is an integer greater than or equal to 1; the total number of groups is used to indicate the number of IoT device groups assigned by the reader; and the first function is used to map IoT devices to the first offset value.

[0020] In one possible implementation, after sending the beacon signal, the physical reader is sent to the device channel PRDCH, including: after sending the beacon signal, starting a second timer, the duration of which is determined based on the difference between a second offset value and a first offset value and a preset duration, the second offset value being the largest time offset value in the first offset set; and at the timeout of the second timer, sending the PRDCH in a second window, the start time of which is determined based on the timeout of the second timer.

[0021] In one possible implementation, the difference between any two distinct offset values ​​among the N offset values ​​is greater than the sum of the maximum timing error of the IoT device and the wireless channel delay spread.

[0022] In one possible implementation, the first function includes at least one of a hash function, a bit extraction operation function, a direct modulo operation function, a CRC check operation function, and a segmentation mapping function.

[0023] In one possible implementation, before sending the beacon signal, the method further includes: performing a hash operation on the device identifier of the target device based on a hash function and the total number of groups to obtain a first index; and querying from a first offset set according to the first index to obtain a first offset value.

[0024] In one possible implementation, the beacon signal does not contain information that needs to be digitally decoded, which includes device identification and / or cyclic redundancy check (CRC) codes.

[0025] In one possible implementation, the beacon signal is modulated differently from the PRDCH.

[0026] The second aspect is the implementation on the network device side, which corresponds to the first aspect. The explanations, supplements, and descriptions of the beneficial effects of the first aspect also apply to the second aspect, and will not be repeated here.

[0027] Thirdly, a communication device is provided, comprising a transceiver module and a processing module. The transceiver module is used to receive a synchronization signal; the processing module is used to start a first timer at a first moment, the duration of which is determined based on a first offset value, the first moment being equal to or later than the end moment of the synchronization signal; the transceiver module is also used to detect a beacon signal in a first window when the first timer expires, the start moment of the first window being the timeout moment of the first timer; if a beacon signal is detected in the first window, the transceiver module receives a PRDCH; the processing module is also used to enter a sleep state if no beacon signal is detected in the first window.

[0028] Fourthly, a communication device is provided, comprising a transceiver module. The transceiver module is used to transmit a synchronization signal; a processing module is used to start a first timer at a first moment, the duration of which is determined based on a first offset value, the first moment being equal to or later than the end moment of the synchronization signal; the transceiver module is further used to transmit a beacon signal in a first window when the first timer times out, the start moment of the first window being the timeout moment of the first timer; after transmitting the beacon signal, a PRDCH is transmitted.

[0029] The third and fourth aspects are the implementation on the device side corresponding to the first and second aspects. The explanations, supplements, and descriptions of the beneficial effects of the first and second aspects also apply to the third and fourth aspects, and will not be repeated here.

[0030] Fifthly, a communication device is provided, including a processor. The processor is coupled to a memory and can be used to execute instructions or data in the memory to implement the method in any possible implementation of the first aspect described above. Optionally, the communication device further includes a memory. Optionally, the communication device further includes a communication interface, and the processor is coupled to the communication interface.

[0031] In one implementation, the communication interface can be a transceiver, or an input / output interface.

[0032] In another implementation, the communication device is a chip configured in the terminal. When the communication device is a chip configured in the terminal, the communication interface can be an input / output interface.

[0033] In a sixth aspect, a communication device is provided, including a processor. The processor is coupled to a memory and can be used to execute instructions or data in the memory to implement the method in any possible implementation of the second aspect described above. Optionally, the communication device further includes a memory. Optionally, the communication device further includes a communication interface, and the processor is coupled to the communication interface.

[0034] In one implementation, the communication interface can be a transceiver, or an input / output interface.

[0035] In another implementation, the communication device is a chip configured in the first network device. When the communication device is a chip configured in the first network device, the communication interface can be an input / output interface.

[0036] In a seventh aspect, a processor is provided, comprising: an input circuit, an output circuit, and a processing circuit. The processing circuit is used to receive signals through the input circuit and transmit signals through the output circuit, causing the processor to execute a method in any possible implementation of any aspect.

[0037] In specific implementation, the processor can be one or more chips, the input circuit can be input pins, the output circuit can be output pins, and the processing circuit can be transistors, gate circuits, flip-flops, and various logic circuits. The input signal received by the input circuit can be received and input by, for example, but not limited to, a receiver, and the signal output by the output circuit can be, for example, but not limited to, output to and transmitted by a transmitter. Furthermore, the input circuit and the output circuit can be the same circuit, which is used as both the input circuit and the output circuit at different times. This application does not limit the specific implementation of the processor and various circuits.

[0038] Eighthly, a communication device is provided, including a processor and a memory. The processor is used to read instructions stored in the memory, receive signals via a receiver, and transmit signals via a transmitter to execute the method in any possible implementation of any of the preceding aspects.

[0039] Optionally, there may be one or more processors and one or more memories.

[0040] Ninthly, a computer program product is provided, comprising: a computer program (also referred to as code or instructions) that, when executed, causes a computer to perform a method in any possible implementation of any of the above aspects.

[0041] In a tenth aspect, a computer-readable storage medium is provided that stores a computer program (also referred to as code or instructions) that, when executed on a computer, causes the computer to perform the methods in any possible implementation of any of the above aspects.

[0042] Eleventhly, embodiments of this application provide a chip system including one or more processors for calling and executing instructions stored in memory, causing the methods in any of the above aspects or possible implementations to be executed. The chip system may be composed of chips or may include chips and other discrete devices.

[0043] The chip system may include input circuits or interfaces for transmitting information or data, and output circuits or interfaces for receiving information or data.

[0044] In a twelfth aspect, a communication system is provided, including the aforementioned terminal device (e.g., an Internet of Things device) and network device (e.g., a reader / writer). Optionally, the communication system may also include other devices that communicate with the terminal device and / or network device. Attached Figure Description

[0045] Figure 1 A schematic diagram of a communication system provided in an embodiment of this application;

[0046] Figure 2 A schematic diagram illustrating the provision of a carrier signal to an A-IoT device, as provided in an embodiment of this application;

[0047] Figure 3 A schematic diagram illustrating another method of providing a carrier signal to an A-IoT device, as provided in an embodiment of this application;

[0048] Figure 4 A schematic diagram of an IoT transceiver provided in an embodiment of this application;

[0049] Figure 5 A flowchart illustrating an IoT communication method provided in an embodiment of this application;

[0050] Figure 6 A schematic diagram of a first offset set provided for an embodiment of this application;

[0051] Figure 7 A schematic diagram illustrating the mapping of a first function to a group, provided as an embodiment of this application;

[0052] Figure 8 A schematic diagram of a beacon sending window corresponding to a Reader provided in an embodiment of this application;

[0053] Figure 9 A schematic diagram of a beacon listening window corresponding to a Device provided in an embodiment of this application;

[0054] Figure 10 A schematic diagram of a beacon listening window corresponding to different groups provided in an embodiment of this application;

[0055] Figure 11 A schematic diagram of device processing logic provided for an embodiment of this application;

[0056] Figure 12 A schematic diagram of another device processing logic provided in an embodiment of this application;

[0057] Figure 13 A schematic block diagram of a communication device provided in an embodiment of this application;

[0058] Figure 14 Another schematic block diagram of the communication device provided in the embodiments of this application. Detailed Implementation

[0059] The technical solutions in the embodiments of this application will now be described with reference to the accompanying drawings.

[0060] The technical solutions provided in this application can be applied to various communication systems, such as: Global System for Mobile Communications (GSM) systems, General Packet Radio Service (GPRS), Wireless Local Area Network (WLAN), Long Term Evolution (LTE) systems, LTE Frequency Division Duplex (FDD) systems, LTE Time Division Duplex (TDD) systems, sidelink communication systems, Universal Mobile Telecommunication System (UMTS), Worldwide Interoperability for Microwave Access (WiMAX) communication systems, non-terrestrial network (NTN) communication systems, 5th generation (5G) mobile communication systems, or new radio access technology (NR). Among these, 5G mobile communication systems can include non-standalone (NSA) and / or standalone (SA) networking. The technical solutions provided in this application can also be applied to future communication systems. This application does not limit the scope of these applications.

[0061] Figure 1 This is a schematic diagram of a communication system 100 used in an embodiment of this application. The communication system 100 may include network devices, such as... Figure 1 The Reader 110 shown. The communication system 100 may also include terminal devices, such as... Figure 1 The IoT devices 120 and 130 are shown. The Reader 110 can communicate with the IoT devices 120 and 130 via a wireless channel.

[0062] Optionally, the communication system 100 may also include more or fewer network devices and / or multiple terminal devices.

[0063] In some embodiments, the UE can act as a Reader to communicate with IoT devices.

[0064] Communication between network devices and terminal devices, between network devices, and between terminal devices can be conducted using licensed spectrum, unlicensed spectrum, or both simultaneously. Communication can also be conducted using spectrum below 6 gigahertz (GHz), spectrum above 6 GHz, or both simultaneously. The embodiments of this application do not limit the spectrum resources used for wireless communication.

[0065] In embodiments of this application, the network device can send downlink signals or downlink information to the terminal device, with the downlink information carried on the downlink channel; the terminal device can send uplink signals or uplink information to the network device, with the uplink information carried on the uplink channel. For example, the downlink channel between Reader 110 and IoT device 120 can be a Physical Reader-to-Device channel (PRDCH). The uplink channel between Reader 110 and IoT device 120 can be a Physical Device-to-Reader channel (PDRCH).

[0066] The network equipment in this application can be network-side equipment such as access network equipment and core network equipment. Access network equipment is sometimes also called access node. Access network equipment has wireless transceiver capabilities and is used to communicate with terminal equipment. Access network equipment includes, but is not limited to, readers, base stations, evolved NodeBs (eNodeBs), transmission reception points (TRPs) in the above-mentioned communication systems, next-generation NodeBs (gNBs) in 5G mobile communication systems, access network equipment or modules of access network equipment in open RAN (ORAN) systems, satellites in NTN communication systems, base stations in future mobile communication systems, or access nodes in WiFi systems. Access network equipment can also be modules or units that can implement some of the functions of a base station. Access network equipment can be macro base stations, micro base stations, or indoor stations, relay nodes or donor nodes, or wireless controllers in cloud radio access network (CRAN) scenarios. Optionally, access network equipment can also be servers, wearable devices, or vehicle-mounted equipment, etc. For example, the access network equipment in vehicle-to-everything (V2X) technology can be a roadside unit (RSU). Multiple access network devices in a communication system can be base stations of the same type or different types. Base stations can communicate with terminal devices directly or via relay stations. Terminal devices can communicate with multiple base stations using different access technologies. The embodiments of this application do not limit the specific technology or device form used in the access network equipment. In this application, the access network equipment is referred to as a network device.

[0067] In this application, the means for implementing the functions of a network device can be a network device itself, or a means capable of supporting the network device in implementing those functions, such as a processor, circuit, chip, or chip system. This means can be installed in or connected to the network device. In the technical solutions provided in this application, the example of a network device being used to implement the functions of a network device is used to describe the technical solutions provided in this application.

[0068] The terminal device in this application can be a wireless terminal device capable of receiving network device scheduling and instruction information. The wireless terminal device can be a device providing voice and / or data connectivity to a user, a handheld device with wireless connectivity, or other processing devices connected to a wireless modem. For example, the terminal device can communicate with one or more core networks or the Internet via a radio access network (RAN). The terminal device can also be called a terminal, mobile terminal, etc. Terminal devices can be widely used in various scenarios, such as device-to-device (D2D), vehicle-to-everything (V2X) communication, machine-type communication (MTC), Internet of Things (IoT), ambient IoT (A-IoT), ultra-reliable low-latency communication (URLLC), virtual reality, augmented reality, industrial control, autonomous driving, telemedicine, smart grids, smart furniture, smart offices, smart wearables, smart transportation, smart cities, or satellite communication, etc. The terminal device can be an IoT device. An IoT device can also be called a Device. IoT devices can include A-IoT devices. Terminal devices can also be mobile phones, tablets, computers with wireless transceiver capabilities, wearable devices, vehicles, aircraft (such as drones, helicopters, and airplanes), hot air balloons, ships, robots, robotic arms, or smart home devices, etc. The embodiments of this application do not limit the form of the terminal device.

[0069] In this application, the apparatus for implementing the functions of a terminal device can be the terminal device itself, or any apparatus capable of supporting the terminal device in implementing those functions, such as a processor, circuit, chip, or chip system. This apparatus can be installed in or connected to the terminal device. In the technical solutions provided in this application, the example of a terminal device being used to implement the functions of a terminal device is used to describe the technical solutions provided in this application.

[0070] Network devices and / or terminal devices can be fixed or mobile. They can be deployed on land, including indoors or outdoors, handheld or vehicle-mounted; on water; or in the air on aircraft, balloons, and satellites. This application does not limit the application scenarios of the network devices and terminal devices. They can be deployed in the same or different scenarios; for example, both network devices and terminal devices can be deployed on land simultaneously; or, network devices can be deployed on land and terminal devices on water, etc., and so on.

[0071] It should be understood that network devices and terminal devices can be fixed in location or mobile. Network devices and terminal devices can be deployed on land, including indoors or outdoors, handheld or vehicle-mounted; they can also be deployed on water; and they can also be deployed in the air on aircraft, balloons, and artificial satellites. The embodiments of this application do not limit the application scenarios of the network devices and terminal devices.

[0072] In the embodiments of this application, the functions of the network device can be executed by modules (such as chips) within the network device, or by a control subsystem that includes network device functions. This control subsystem, including network device functions, can be a control center in the aforementioned application scenarios such as smart grids, industrial control, intelligent transportation, and smart cities. Similarly, the functions of the terminal device can be executed by modules (such as chips or modems) within the terminal device, or by a device that includes terminal device functions.

[0073] It should be noted that the solutions in the embodiments of this application can also be applied to other communication systems, and the corresponding names can be replaced by the names of the corresponding functions in other communication systems.

[0074] To facilitate understanding of the embodiments of this application, the terminology used in this application will be briefly explained first. Optionally, the explanation of some terms can also be found in the 3GPP standard protocol.

[0075] 1. IoT: This refers to the Internet of Things, which connects all things. It extends the internet user interface to any object, enabling information exchange and communication between any two objects. This type of communication is also known as MTC (Mechanical, Communication, and Telecommunications).

[0076] More and more IoT devices are being deployed in people's lives. Examples include smart water meters, shared bicycles, and devices for smart cities, environmental monitoring, smart homes, and forest fire prevention—all designed for sensing and data collection. In the future, IoT devices will be ubiquitous, potentially embedded in every piece of clothing, every package, every key, and virtually every offline item will become online thanks to IoT technology.

[0077] However, due to the wide distribution and large number of IoT devices, the process of realizing the Internet of Things has brought considerable challenges to the industry, the most prominent being the power supply issue. Currently, IoT technology is still mainly driven by operators, and IoT modules (the models in IoT devices) use standard cellular protocols to communicate with network devices (such as base stations). Because network devices (such as base stations) need to cover as large an area as possible, IoT modules need to be able to communicate even at a great distance from network devices (such as base stations). This means that IoT modules still consume up to 30mA of current during wireless communication, so current IoT modules still require high-capacity batteries to operate. This also makes it difficult to miniaturize IoT modules, increasing the cost of IoT devices.

[0078] Furthermore, some low-power terminal devices play a crucial role in IoT applications such as medical devices, smart homes, industrial sensors, and wearable devices. However, due to the limited size of these devices, extending their operating time is difficult to achieve simply by increasing battery capacity. Therefore, extending the battery life of terminal devices requires reducing the power consumption of wireless communication. Among these components, the radio transceiver is one of the most power-consuming.

[0079] Therefore, in order to further popularize IoT technology and implant IoT modules into the human body or smaller objects, it is no longer possible to use high-capacity batteries. Instead, smaller batteries or even completely eliminating battery limitations should be used, or a method to reduce the power consumption of radio transceivers should be designed to solve the limitations of IoT devices in terms of cost, size, and power consumption.

[0080] 2. A-IoT Devices: During the 3GPP Release-18 standard discussions, a study on low-power wake-up signal and receiver for NR was approved. Furthermore, A-IoT devices were also discussed at the 3GPP plenary meeting.

[0081] Unlike terminals in traditional cellular communication systems, A-IoT devices consume extremely low power (approximately 1µW to several hundredµW) and are prohibited from using battery power. Instead, they support normal A-IoT communication by harvesting and storing ambient energy (such as radio waves, light energy, kinetic energy, and heat energy). To meet the extremely low power consumption requirements of A-IoT devices, communication can be achieved through the following methods:

[0082] (1) On the R2D channel, the Reader uses OOK modulation to send data, and the A-IOT device uses an envelope detector receiver with extremely low power consumption to receive data.

[0083] (2) On the D2R channel, A-IoT devices can use reflection communication technology. For example, A-IoT devices can use a carrier signal provided by an external carrier source and directly modulate the data to be transmitted onto the external carrier signal and send it to the Reader. Since A-IoT devices do not need to generate their own carrier, power consumption can be greatly reduced.

[0084] A-IoT devices can be divided into active and passive types.

[0085] Among them, an active A-IoT device is an active tag or active terminal that can transmit wireless signals using energy stored in its own energy storage module. Additionally, active A-IoT can also be described in other ways, such as active A-IoT, active A-IoT terminal, active A-IoT terminal device, active IoT, active IoT device, active IoT terminal, active IoT terminal device, active tag, active terminal, active terminal device, etc. This will be used uniformly here and will not be elaborated further below.

[0086] Passive A-IoT devices primarily rely on obtaining energy from external radio frequency signals and communicate through backscattered radio frequency signals, ultimately achieving ultra-low power consumption or even zero power consumption. Additionally, passive A-IoT can also be described in other ways, such as passive A-IoT, passive A-IoT terminal, passive A-IoT terminal device, passive IoT device, passive IoT terminal, passive IoT terminal equipment, passive source tag, battery-free terminal, battery-free device, no-battery terminal, no-battery device, backscatter terminal, backscatter device, etc. These terms are used uniformly here and will not be elaborated upon further.

[0087] Passive A-IoT devices can use a carrier signal provided by an external carrier source and directly modulate the data to be transmitted onto that external carrier signal before sending it to the Reader. The external carrier source can be provided by a network device (e.g., the Reader) or by a third-party device other than the Reader and the A-IoT device. For example, ... Figure 2 As shown, Reader 110 can provide a carrier signal to IoT device (e.g., A-IoT device) 120, and A-IoT device 120 can modulate the carrier signal to obtain a D2R signal and send it to Reader 110. For example, as... Figure 3As shown, a third-party device (e.g., UE 140) can provide a carrier signal to the A-IOT device 120, which can modulate the carrier signal to obtain a D2R signal and send it to the Reader 110.

[0088] 3. IoT transceiver: In this application, the IoT transceiver can be a transceiver for an IoT device.

[0089] For example, such as Figure 4 As shown, an IoT transceiver may include modules such as an envelope detector, a main decoder, a reflection modulator, and a processor. The envelope detector receives modulated signals (e.g., On-Off Keying (OOK) modulated signals) via an antenna, demodulates the modulated signals, and then transmits them to the processor. The envelope detector is used for its simple circuitry and extremely low power consumption, making it suitable for wake-up reception. The main decoder is used for CRC verification, channel decoding (e.g., PRDCH decoding), and protocol parsing. It can handle complex coding and error correction, and is compatible with normal data transmission. The reflection modulator can be used to modulate OOK modulated signals, etc., and transmit them via an antenna.

[0090] 4. OOK: It uses high and low levels to reflect the modulation method of different bits.

[0091] For example, OOK can modulate bit "1" to a high level and bit "0" to a low level. It should be understood that, as a possible alternative, OOK can modulate bit "0" to a high level and bit "1" to a low level, and this application does not limit this.

[0092] 5. Synchronization signal: A key signal used to coordinate the timing and data alignment of equipment, systems or communication processes. It can provide a clock reference, identify the start and end of data, ensure coordination between the transmitting and receiving ends, and avoid data corruption or loss.

[0093] Synchronization signals may include, for example, the R2D timing acquisition signal (R-TAS) in the 3GPP communication standard.

[0094] 6. R-TAS: This is a key synchronization signal in R2D transmission in scenarios such as Ambient IoT. It is specifically used for timing calibration and transmission start positioning between the device and the reader. Its signal composition and core functions are as follows:

[0095] R-TAS consists of two parts: the start indicator part (SIP) and the clock acquisition part (CAP).

[0096] SIP is used to indicate the start position of R2D transmission. For example, SIP can contain two OFDM symbols. The first OFDM symbol uses a 1:1 on / off ratio for device power threshold detection, helping the device sense the signal and adjust its own power adaptation. The second OFDM symbol uses a 1:3 on / off ratio to accurately mark the transmission start point through a special signal pattern, enabling the device to clearly identify the start time of data transmission.

[0097] CAP is used to determine the OOK chip length and calculate key parameters (such as the M value). The M value indicates the number of chips contained in an OFDM symbol and provides a basic parameter for clock synchronization of subsequent data transmissions. The actual transmission length of CAP is related to the M value (the larger the M value, the smaller the CAP length).

[0098] R-TAS is the core of R2D transmission timing assurance. In low-power, short-data-transmission scenarios such as AmbientIoT, devices and readers can first complete the transmission start positioning and clock parameter calibration through R-TAS to ensure the accuracy of subsequent data channel transmission timing, such as the physical reader-to-device channel (PRDCH), and avoid problems such as data misalignment and parsing failure.

[0099] 7. PRDCH: The physical layer data transmission channel for R2D links defined in 3GPP Rel 19, used to carry downlink data / control information sent by the Reader to the Device.

[0100] Rel 20 follows the Rel 19 definition of PRDCH, but the difference is that PRDCH can include a physical layer header (Layer 1 Header, L1-Header). The L1-Header is a fixed prefix for PRDCH physical layer data packets, carrying physical layer control information, and is used by devices to quickly parse transmission parameters and verify integrity.

[0101] Currently, IoT devices (such as Device2b / C) exhibit extreme power consumption constraints in wake-up and data reception. This poses a significant challenge to long-term battery life in scenarios with dense outdoor deployment of IoT devices.

[0102] Currently, by using downlink synchronization signals and downlink control information (such as L1-Header), the device can pre-filter the data before it is fully decoded (PRDCH), providing a key basis for IoT devices to judge transmission correlation in advance and avoid invalid wake-ups, thereby saving power consumption of IoT devices.

[0103] However, the aforementioned filtering mechanism suffers from fundamental inefficiency. When the Reader frequently sends downlink transmissions in intensive scenarios, the device needs to perform complete PRDCH decoding or L1-Header decoding and verification (e.g., Rel 19 requires PRDCH decoding, or Rel 20 requires L1-Header decoding). This "decode first, then identify" mechanism means that the device needs to decode PRDCH or L1-Header when processing both irrelevant (the vast majority) and valid transmissions, resulting in high power consumption for IoT devices and failing to meet the design goal of extreme low power consumption. Device power may be rapidly consumed in processing massive amounts of irrelevant transmissions, leading to insufficient battery life and a series of serious consequences, such as service interruptions and soaring network maintenance costs.

[0104] This application provides an IoT communication method and apparatus that can save power consumption of IoT devices, adapt to the needs of massive IoT systems, avoid the rapid consumption of device power on processing massive amounts of irrelevant transmissions, avoid a series of serious consequences caused by insufficient device battery life, and ensure the efficient and stable operation of the communication system.

[0105] The technical solutions of the embodiments of this application will now be described with reference to the accompanying drawings. In the description of this application, unless otherwise stated, "at least one" refers to one or more, and "multiple" refers to two or more. Furthermore, to facilitate a clear description of the technical solutions of the embodiments of this application, the terms "first," "second," etc., are used in the embodiments of this application to distinguish identical or similar items with substantially the same function and effect. Those skilled in the art will understand that the terms "first," "second," etc., do not limit the quantity or execution order, and that "first," "second," etc., do not necessarily imply differences.

[0106] It should be understood that the technical terms used in this application are for illustrative purposes only and not as limiting. For example, as technology evolves, technical terms may also change, and other technical terms with the same technical meaning should also apply to this application. For ease of understanding, the IoT communication provided by the embodiments of this application will be described in detail below with reference to the accompanying drawings.

[0107] like Figure 5 As shown, this application provides an Internet of Things (IoT) communication method, using a terminal device (IoT device) as the Device and a network device as the Reader as an example, including:

[0108] 501. The Reader sends a broadcast message, and the Device receives the broadcast message accordingly. The broadcast message includes at least one of the following: a first offset set, the total number of groups, and information about a first function.

[0109] That is, the Reader can broadcast system parameters, which include at least one of the following: the first offset set, the total number of groups, and information about the first function.

[0110] The first offset set can include N discrete and unique offset values, such as { , ,..., }. Where N is an integer greater than or equal to 1. These N offset values ​​are time offset values ​​(or timing offset values) relative to the first moment. That is, each of these N offset values ​​corresponds to a precise and uniform starting reference point (also called a reference point), such as the first moment.

[0111] In one possible design, the first moment can be the end moment of the synchronization signal (e.g., the R-TAS signal), that is, the precise end moment of the CAP transmission in the R-TAS signal (denoted as ). Wherein, CAP receive end time = CAP start time + CAP time domain length. The CAP start time is also the SIP end time, and the SIP receive end time = SIP start time + SIP time domain length.

[0112] For example, such as Figure 6 As shown, the first offset set can include N offset values, such as { , ,..., The reference point (starting reference point) for these offset values ​​can be... .

[0113] Or, the first moment can be later than For example, the first moment can be later than The time offset ranges from tens of nanoseconds to a few microseconds. After receiving the CAP signal, the device can achieve precise synchronization with the Reader's downstream clock reference. In physical implementation, the time offset value (e.g., The meaning of ) is the duration of the "gap" period inserted after the Reader sends the CAP signal. During this period, the duration is... After a certain silence period, the Reader begins sending the PRDCH. In this way, group information can be implicitly conveyed through different silence period lengths. That is, different groups can correspond to different silence periods.

[0114] In some embodiments, the design of the first offset set may follow one or more possible implementations to ensure the robustness and flexibility of the scheme.

[0115] In one possible implementation, an offset value in the first offset set (e.g., ) can be set to 0 (i.e., zero offset), that is With the first moment (e.g., The time offset between ) is 0, that is and This refers to the same point in time (the same instant), meaning the PRDCH (e.g., the L1 control header) is sent immediately after the CAP. The communication channel corresponding to this zero offset (i.e.,...) The corresponding communication channel can be used for broadcasting or is compatible with scenarios that do not require group filtering, meaning that all groups can receive data from the communication channel corresponding to zero offset.

[0116] In one possible implementation, any two distinct offset values ​​in the first offset set (e.g., and The difference between these values ​​is greater than the sum of the Device's maximum timing error and the wireless channel delay spread. The maximum timing error of the IoT device can refer to the maximum timing error that the IoT device may have after CAP calibration. This ensures that the listening windows of different groups do not overlap, avoiding confusion and false wake-ups.

[0117] In this application embodiment, the offset value can also be called the offset amount, the first offset set can also be called the timing offset set, the timing offset set, the offset value list, etc., and this application does not make specific limitations.

[0118] The total number of groups indicates the number of IoT device groups (group count) allocated by the reader. The number of IoT device groups allocated by the reader is less than or equal to the number of offset values ​​in the first offset set, i.e., the number of IoT device groups is less than or equal to N.

[0119] It should be noted that the number of offset values ​​in the first offset set, excluding the zero offset, determines the maximum number of groups that the system (e.g., the reader / writer) can divide. For example, if the number of offset values ​​in the first offset set, excluding the zero offset, is 16, then the system can support a maximum of 16 different device groups distinguished by time offset values.

[0120] The information for the first function may include its name and parameters. The first function can be used to map all IoT devices in a group of IoT devices to an offset value (e.g., a first offset value) in a first offset set. The first function can also be used to map different IoT device groups to different offset values ​​in the first offset set. An IoT device group may include one or more IoT devices.

[0121] For example, assume the reader / writer is assigned groups 1, 2, and 3; group 1 may include Devices 1-5, group 2 may include Devices 6-10, and group 3 may include Devices 11-15. The first offset set includes N (e.g., N is greater than 3) offset values, such as { , ,..., The reference point for these N offset values ​​is For example, Figure 7 As shown, the first function can map group 1 (Device1-Device5, i.e., device 1-device 5) to offset value 1 in the first offset set (e.g., ...). ), mapping group 2 (Device6-Device10, i.e., device 6-device 10) to offset value 2 in the first offset set (e.g., ), mapping group 3 (Device11-Device15, i.e., device 11-device 15) to offset value 3 in the first offset set (e.g., That is, group 1 (Device1-Device5 in it) can correspond to an offset value of 1 (e.g., Group 2 (Device6-Device10 in the group) can correspond to an offset value of 2 (e.g., Group 3 (Device11-Device15 in the group) can correspond to an offset value of 3 (e.g., Of course, the reader can assign more groups, such as group 4, ..., group N, etc., which are not limited here.

[0122] For example, the first function includes at least one of a hash function (e.g., Hash_Group), a bit extraction operation function, a direct modulo operation function, a CRC check operation function, and a segmentation mapping function.

[0123] Among them, the bit extraction function is used to directly extract the last few bits of the device global ID (e.g., the last 4 bits when the device global ID is 16) as an index. This method is simple to calculate and has low power consumption. The direct modulo operation function can directly take the device ID value modulo the total number of groups (e.g., N) without hash transformation (or take the modulo of N and add one). The CRC check operation function is used to calculate the CRC value of the device global ID and then take the modulo of N (or take the modulo of N and add one). This method can avoid group congestion caused by ID allocation rules more effectively than direct bit extraction. The segmented mapping function is used to directly find the corresponding offset value according to the numerical range of the device global ID (e.g., numbers 0-1000 are classified as the first group).

[0124] The aforementioned system parameters (i.e., the information on the first offset set, the total number of groups, and the first function) can be predefined by the Reader. After defining the system parameters, the Reader can periodically broadcast the system parameters on a common channel that all devices can receive (e.g., a zero-offset channel with Δt0=0).

[0125] Accordingly, the Device can perform the following operations:

[0126] When the device is powered on for the first time, it can enter the "initial configuration" mode. In the "initial configuration" mode, the device can keep listening on a common channel (e.g., a zero-offset channel with Δt0=0) until it successfully receives the complete system parameters (e.g., information on the first offset set, the total number of groups, and the first function) broadcast by the read / write device.

[0127] Once a device successfully receives system parameters, it can immediately obtain its own device identifier (e.g., a 64-bit Device_Global_ID). For example, the device can load the device identifier from its non-volatile memory. This device identifier can be a globally unique ID, meaning it can uniquely identify the device. This globally unique ID can be a permanent identifier programmed at the factory or assigned upon network registration. It is absolutely unique across the entire network or globally.

[0128] The following example, using the first function as a hash function, illustrates the steps executed by the Device:

[0129] After successfully receiving system parameters and obtaining its own device identifier, the device can perform a self-computation step: based on a hash function and the total number of groups, a hash operation is performed on the device identifier to obtain a first index; the device then queries the first offset set according to the first index to obtain the first offset value. The first index indicates the offset value corresponding to the group the device belongs to (e.g., the first offset value). That is, the first index is a group index. For example, the first index can be the sequence number / number of different offset values ​​in the first offset set. For instance, the first offset value in the first offset set (e.g., the first offset value). The corresponding index can be 1, the second offset value in the first offset set (e.g., The corresponding index can be 2, and so on.

[0130] Devices in different groups can correspond to different group indices. For example, with Figure 7 In the example shown, group 1 (Device1-Device5) can correspond to index 1, and index 1 can indicate an offset value of 1 (e.g., Group 2 (Device6-Device10 in the group) can correspond to index 2, and index 2 can indicate an offset value of 2 (e.g., Group 3 (Device11-Device15) can correspond to index 3, and index 3 can indicate an offset value of 3 (e.g., ).

[0131] Optionally, during the hash operation, the Device can use a modulo operation to obtain the first index.

[0132] For example, the calculation formula for the first index (e.g., index k) can be as shown in formula (1).

[0133] k = Hash_Group(Device_Global_ID) % N formula (1);

[0134] In formula (1), k is an integer greater than or equal to 0.

[0135] Alternatively, the formula for calculating the first index (e.g., index k) can be as shown in formula (2).

[0136] k = Hash_Group(Device_Global_ID) % N+1 formula (2);

[0137] In formula (2), k is an integer greater than or equal to 1.

[0138] The device can immediately query the first offset set based on the calculated index k to find the offset value corresponding to index k (the first offset value). For example, it could be the k-th offset value in the first offset set (e.g., Δt). k ).

[0139] The device can store the initial offset value. For example, the initial offset value can be stored in local non-volatile memory. After storage, the device completes its initial configuration and can switch to an ultra-low-power filter monitoring mode, ready to execute subsequent R2D transfer filtering processes.

[0140] This application provides a "group self-homing" mechanism, which broadcasts a set of system parameters (i.e., a first offset set, the total number of groups, and information about a first function) on the network side. After receiving the system parameters, the Device can determine a time offset value (e.g., a first offset value) from the first offset set based on the first function (e.g., a hash function), the number of groups, and its own device identifier. This time offset value is the time offset value corresponding to the Device's group (i.e., the time offset value corresponding to the Device itself). In this way, the "group self-homing" mechanism can be implemented, that is, the Device determines the time offset value corresponding to its own group through a "self-calculation" method. Compared with the method of "explicitly allocating" groups to a large number of devices and mapping them to specific offset values ​​(e.g., read and write devices explicitly allocating groups and offsets to each device through signaling), which causes high signaling overhead and management complexity, the "group self-homing" mechanism can reduce signaling overhead and management complexity, save device power consumption, and has high network scalability (even if a batch of Devices is added, no additional signaling overhead is required, and the newly added batch of Devices can accurately determine the time offset value corresponding to their respective groups based on the "group self-homing" mechanism). Correspondingly, the read / write device can also determine the group and offset value corresponding to any target device at any time through symmetric calculation, and then determine the wake-up time slot of the target device based on the corresponding offset value, thus achieving efficient and automated load balancing.

[0141] 502. The Reader sends a synchronization signal, and the Device receives the synchronization signal accordingly.

[0142] For example, the synchronization signal could be R-TAS.

[0143] It is understandable that the Reader can send an R-TAS before sending the PRDCH. This allows the Device to complete basic timing awareness through the R-TAS, thereby ensuring the correct reception of service data in the subsequent PRDCH and guaranteeing the accuracy of subsequent data transmission timing.

[0144] Optionally, the Reader can determine the target parameters before sending the R-TAS and PRDCH. These target parameters include the group index (e.g., index k) corresponding to the target device of this transmission (the target device corresponding to the PRDCH to be sent) and the unique offset value corresponding to that group index (e.g., ...). ).

[0145] The Reader can perform calculations similar to those on the device side (e.g., hash calculations) based on the device identifier of the target device and the number of groups in this transmission to obtain the value of the group index (e.g., index k). For example, k can be calculated according to formula (1). Based on the group index (e.g., index k), the Reader can obtain the unique offset value corresponding to the group index from the first offset set (e.g., ...). ).

[0146] Optionally, the Reader can prepare the PRDCH to be sent later before sending the R-TAS.

[0147] Optionally, before sending the R-TAS, the Reader can also prepare the contents of the L1-Header (L1 control header), which includes at least the short Device ID of the target device and calculates a separate C-CRC (Control Header Check Sequence) for it. The short Device ID is a temporary or local identifier used by the device within a specific communication range (such as within the current reader coverage area or the current group).

[0148] Accordingly, the device (or its low-power front-end) can continuously monitor the downlink channel to search for the R-TAS signal. Once the R-TAS is detected, the device will be woken up to the "synchronization" state. In this state, the device can receive and process the SIP and CAP portions of the R-TAS to obtain a precise downlink chip-level timing reference point (CPS). And calibrate its local clock.

[0149] 503. The Reader sends a beacon signal, and the Device receives the beacon signal accordingly.

[0150] After the Reader sends a synchronization signal, it can determine the time to send the beacon signal based on the offset value corresponding to the target device (e.g., the first offset value).

[0151] In some embodiments, at a first moment, the Reader may start a first timer, the duration of which is determined based on an offset value (e.g., a first offset value) corresponding to the target device. The first moment is equal to or later than the end moment of the synchronization signal. After the first timer times out, the Reader may send a beacon signal in a first window, the start moment of which is the timeout moment of the first timer, and the length of the first window may be preset. On the Reader side, the first window may be referred to as the beacon sending window.

[0152] For example, taking the first moment as the end time of the CAP of the R-TAS signal as an example, such as Figure 8As shown, at the end of the CAP time of the R-TAS signal, the Reader can immediately begin a silent period (waiting period). The duration of this silent period (waiting period) can be the duration of the first timer, which can be the first offset value corresponding to the target device (e.g., ...). That is, during the first timer run, the Reader can be considered to be in a state with a duration of... The silent period (waiting period) begins. After the silent period ends, the first window starts. The Reader can send beacon signals within the beacon sending window. The start time of the beacon sending window can be the end time of the silent period, and the length of the beacon sending window can be preset. For example, the Reader can send a beacon signal at the end time of the silent period (i.e., the start time of the beacon sending window, which is also the timeout of the first timer).

[0153] Among them, the beacon signal is a short, unique, and easily detectable physical layer signal by an envelope detector. The beacon signal can be detected at specific times (e.g., ) appears (i.e., Reader in Sending beacon signals can indicate The Device in the corresponding group (e.g., Group_i) enters a low-power standby state and is ready to receive data at a later common time.

[0154] For example, with Figure 7 Taking the situation shown as an example, if the beacon signal is in Appearance (i.e., Reader in) Sending a beacon signal can instruct Devices 1-5 in Group 1 to enter a low-power standby state; if the beacon signal is in Appearance (i.e., Reader in) Sending a beacon signal can instruct Devices 6-10 in Group 2 to enter a low-power standby state; if the beacon signal is in Appearance (i.e., Reader in) Sending a beacon signal can instruct Device11-Device15 in group 3 to enter a low-power standby state.

[0155] The beacon signal itself may not contain any information that needs to be digitally decoded. Information that needs to be digitally decoded may include, for example, a device identifier (ID) and / or a cyclic redundancy check (CRC) code. The information of the beacon signal can be derived from the time it was transmitted (…). The beacon signal carries the signal pattern. The beacon signal can be used to wake up devices in the same group as the target device, prevent devices in other groups (other than the target device's group) from being woken up, resolve wake-up conflicts between groups, and save power consumption for most devices in other groups.

[0156] Optionally, the modulation scheme of the beacon signal (e.g., a dual-pulse OOK mode of a specific duration) can be different from the modulation scheme of the L1 control head and / or PRDCH to ensure that the device can clearly distinguish between the beacon signal and "data" (L1 control head and / or PRDCH) within the listening window.

[0157] The beacon signal can also be called a wake-up signal or wake-up beacon signal, and this application does not limit it.

[0158] Accordingly, after the Device receives the R-TAS signal, completes synchronization, and calibrates the clock, it can determine the time (e.g., time window) to receive the beacon signal based on its own corresponding offset value (i.e., the offset value corresponding to its own group (e.g., the first offset value)).

[0159] In some embodiments, at a first moment, the Device may start a first timer (or counter). The first timer may be a software timer based on a calibrated clock. The duration of the first timer is determined based on the Device's own offset value (e.g., a first offset value). The first moment is equal to or later than the end moment of the synchronization signal. After the first timer times out, the Reader may send a beacon signal in a first window. The start moment of the first window is the timeout moment of the first timer, and the length of the first window may be preset. On the Device side, the first window may be called the beacon receiving window. That is, the Device can determine its own corresponding beacon receiving window based on its own offset value (e.g., the first offset value) and detect the beacon signal within its corresponding beacon receiving window.

[0160] For example, such as Figure 9 As shown, at the end of the R-TAS signal, the Device can start the first timer. The duration of the first timer can be based on the device's corresponding time offset value (e.g., ...). The duration is determined, for example, the duration of the first timer can be... When the first timer times out, the beacon listening window (first window) corresponding to the Device begins. Within this window, the Device can activate the envelope detector and beacon detection logic to attempt to detect the beacon signal. For example, the beacon listening window corresponding to the Device could be... .in, + ,in, This refers to the length of the beacon listening window, which can be a relatively short preset duration.

[0161] If the device successfully detects a beacon signal within its corresponding beacon listening window, it can immediately enter a low-power standby state. If the device does not detect a valid beacon signal within its corresponding beacon listening window, it can enter a sleep state, i.e., shut down the receiving front-end and decoding logic, entering an ultra-low-power state. This is because if the device does not detect a valid beacon signal within its corresponding beacon listening window, it indicates that the data transmission is not for itself (its own group) but may be for another group; therefore, it can enter a sleep state to save power.

[0162] It should be understood that in ultra-low power state (sleep state), the device can shut down the receiver front-end and decoding logic. However, to avoid missing possible synchronization signals (R-TAS), the device can intermittently activate the receiver front-end (envelope detector) to listen for synchronization signals. In standby state, the device's receiver front-end is completely off, and the decoding logic remains off. An internal high-precision digital timer can run to count down. Because no external RF signals need to be processed, the real-time current of the device in standby state is typically lower and much more stable than that of the device in the intermittently activated ultra-low power state.

[0163] For example, with Figure 7 For example, as shown in the figure. Figure 10 As shown, assuming the target device for this transmission is Device1, the offset value corresponding to the group to which Device1 belongs can be... The reader can operate within the beacon transmission window (the start time of this beacon transmission window = the first moment + ...). That is, the start time of the beacon transmission window is from the first moment onwards. At the time following the initial beacon signal, Devices 1 through 5 in Group 1 can send a beacon signal within their corresponding beacon listening window (the start time of this beacon listening window = the first time + ...). That is, the start time of the beacon's listening window is from the first moment onwards. The beacon signal is monitored at the following time. Since the beacon transmission window overlaps with the beacon listening windows corresponding to Devices 1-5 in Group 1, Devices 1-5 in Group 1 can detect the beacon signal and thus enter a low-power standby state. Devices 6-10 in Group 2 (i.e., Devices 6-10) monitor the beacon signal at their corresponding beacon listening windows (the start time of this beacon listening window = the first time + ...). That is, the start time of the beacon's listening window is from the first moment onwards. No beacon signal will be detected within the timeframe after the initial timeframe, and Devices 11-15 in Group 3 (i.e., Devices 11-15) will not be detected within their corresponding beacon listening windows (the start time of which is equal to the first timeframe + ...). That is, the start time of the beacon's listening window is from the first moment onwards. Within a certain timeframe (after which no beacon signal will be detected), Devices 6-10 in Group 2 and Devices 11-15 in Group 3 can immediately shut down the receiving front-end and decoding logic, returning to an ultra-low power state.

[0164] The following is through Figure 11 Explain the device's processing logic. For example... Figure 11 As shown, when a device in sleep mode (hibernation mode) detects R-TAS, it can detect beacon signals within its corresponding beacon listening window. If the device successfully detects a beacon signal within its corresponding beacon listening window, it can immediately enter a low-power standby state. If the device does not detect a beacon signal within its corresponding beacon listening window, it can enter hibernation mode to save power.

[0165] 504. The Reader sends the PRDCH, and the Device receives the PRDCH accordingly.

[0166] After sending a beacon signal, the Reader does not immediately begin sending a PRDCH. Instead, it waits until a predefined data transmission start point is reached before transmitting data (i.e., sending the PRDCH). This predefined data transmission start point only begins after the beacon listening windows of all groups have ended. This avoids potential conflicts caused by longer data packets (PRDCH) from preceding groups (groups with earlier beacon listening windows) interfering with subsequent groups (groups with later beacon listening windows) listening for beacon signals. In other words, it avoids the problem of mutual interference between beacon signals and PRDCH.

[0167] In some embodiments, after the Reader sends a beacon signal, a second timer can be started. The duration of the second timer can be determined based on the difference between a second offset value and a first offset value, plus a preset duration. The second offset value is the largest time offset value in the first offset set. That is, the duration of the second timer can be the difference between the largest time offset value in the first offset set and the offset value corresponding to the target device (e.g., the first offset value), plus the preset duration. The preset duration can be the first duration (e.g., ...). ). This is a delay time reserved to avoid beacon signal interference. The Reader can send the PRDCH when the second timer times out or after the second timer has expired. For example, the timeout point of the second timer can be the starting point of the PRDCH transmission (e.g., ...). ).

[0168] For example, , ,..., .

[0169] It should be noted that when the second timer times out (i.e., at the moment the second timer expires), the beacon listening window of the last group (i.e., the beacon listening window of the group corresponding to the largest time offset value (second offset value) in the first offset set) has also ended, meaning that the beacon listening windows of all groups have ended. Therefore, when the second timer times out or after the second timer expires, the Reader performs data transmission (i.e., sends the PRDCH), which can avoid the problem of mutual interference between the beacon signal and the PRDCH.

[0170] PRDCH may include L1-Header, or PRDCH may not include L1-Header.

[0171] Accordingly, upon detecting a beacon signal, the device will not immediately begin receiving the PRDCH. Instead, it will wait until a predefined data transmission start point is reached before receiving data (i.e., receiving the PRDCH). The predefined data transmission start point will only begin after the beacon listening windows of all groups have ended.

[0172] In some embodiments, when the device detects a beacon signal, a second timer (also called a wake-up timer) can be started. The duration of the second timer can be determined based on the difference between a second offset value and a first offset value, plus a preset duration. The second offset value is the largest time offset value in the first offset set. That is, the duration of the second timer can be the difference between the largest time offset value in the first offset set and the offset value corresponding to the target device (e.g., the first offset value), plus the preset duration. The preset duration can be the first duration (e.g., ...). Alternatively, the preset duration can be a first duration (e.g., ) and second duration (e.g., The difference between the two timers. When the second timer times out or after the second timer has expired, the Reader can send the PRDCH. For example, the timeout point of the second timer can be the start point of the PRDCH transmission (e.g., ...). ).

[0173] If the second timer times out, the Device in standby mode can wake up the main decoder and receive the PRDCH sent by the Reader in its corresponding data transmission listening window (second window). The start time of the data transmission listening window corresponding to the Device can be the timeout time of the second timer (e.g., ...). ).

[0174] For example,

[0175] in, This is the early wake-up time reserved for processing the beginning part of the PRDCH. That is, relative to the moment when the Reader finishes sending the PRDCH, the Device in standby state can wake up the main decoder in advance to prepare for successfully receiving the PRDCH sent by the Reader.

[0176] In some embodiments, the PRDCH includes an L1-Header. The device can first decode the L1-Header to obtain the device identifier (the identifier of the target device, such as Received_Device_ID) and the CRC code (a first CRC code, such as Received_C-CRC). Then, the device calculates the CRC locally (a second CRC, such as Computed_C-CRC) based on the identifier of the target device (such as Received_Device_ID). If the second CRC (such as...) If the first CRC code is different from the second CRC code, the device determines that the L1-Header data is corrupted and can perform "early termination" (i.e., stop receiving PRDCH). The device can then shut down the main decoder and enter a sleep state (i.e., enter an ultra-low power state).

[0177] If the CRC check passes (i.e., the first CRC code matches the second CRC code), the device can determine the identity of the target device (e.g., Received_Device_ID) and its own device identifier (e.g., ...). Are they the same? If If it determines that it is not the target device, it can perform "early termination" (i.e., stop receiving PRDCH). The device can shut down the main decoder and enter a sleep state (i.e., enter an ultra-low power state).

[0178] if Once the device identifies itself as the target device, it can continue decoding the PRDCH (the device continues decoding subsequent PRDCH data payloads based on optional control information in the L1-Header). After the PRDCH decoding is complete (or based on the status command in the L1-Header), the device can execute the corresponding task (target task). After the task is executed, it can return to the ultra-low power state.

[0179] The following is through Figure 12 Explain the device's processing logic. For example... Figure 12 As shown, a device entering low-power standby mode can perform L1-Header decoding and CRC check. If the CRC check fails (i.e., the first CRC code is different from the second CRC code), the device can enter sleep mode to save power. If the CRC check passes (i.e., the first CRC code is the same as the second CRC code), the device can perform ID verification (i.e., determine whether the target device's identifier is the same as the device's own identifier). If the ID verification succeeds (i.e., the target device's identifier is the same as the device's own identifier), the device determines that it is the target device and can continue decoding the PRDCH. If the ID verification fails (i.e., the target device's identifier is different from the device's own identifier), the device determines that it is not the target device and can enter sleep mode to save power.

[0180] In some embodiments, the PRDCH does not include an L1-Header. After receiving the PRDCH, the Device can decode the data payload. If the PRDCH decoding fails, or the target device identifier carried in the data payload is different from or does not match the Device's own device identifier, the Device can shut down the main decoder and enter a sleep state (i.e., enter an ultra-low power state). If the PRDCH decoding is successful and the target device identifier carried in the data payload is the same as or matches the Device's own device identifier (or it is confirmed to be a relevant broadcast, i.e., a system announcement or service group instruction that the Device should process), then "final success" is executed (i.e., the Device has successfully received the data). Subsequently, the Device can execute the corresponding task (target task) according to the instructions of the PRDCH. After the task is completed, it can return to the ultra-low power state.

[0181] The method provided in this application embodiment can decompose the wake-up identification process of IoT devices into two filtering stages with different purposes and progressively increasing power consumption, including a first-stage filtering (group filtering stage) and a second-stage filtering (individual identification / filtering stage).

[0182] The first-stage filtering (group filtering stage) can include steps 502-503, which filters out the vast majority of irrelevant devices (those not in the target group) with minimal power consumption, preventing them from performing subsequent high-power operations. A large number of devices only need to activate ultra-low-power beacon detection logic within the beacon listening window corresponding to the time offset of their respective groups. They are only woken up when a beacon signal is detected, and their main digital decoder is activated to perform higher-power processing; if no beacon signal is detected, the wake-up process can be prematurely terminated, and they can enter a sleep state. This allows a large number of non-target group devices to prematurely terminate the wake-up process at a low cost, thereby significantly reducing the overall network's energy consumption from ineffective wake-ups.

[0183] The second-stage filtering (individual identification / filtering stage) may include step 504, which aims to accurately identify the target device from among the few devices (i.e., devices in the target device's group) that have passed the first-stage group filtering (i.e., those that received the beacon signal). Devices entering the second-stage filtering (i.e., those that received the beacon signal) are awakened and their main digital decoders are activated to perform higher-power processing. This stage includes two cases (or two paths) depending on the transmission configuration:

[0184] Case (Path) 1: PRDCH includes an L1 control header. In this case (path), the device decodes an L1 control header containing the target ID and a separate CRC, and completes efficient individual identification (i.e., determines whether it is the target device) by verifying this L1 header.

[0185] Case (Path) 2: The PRDCH does not include the L1 control header. This case (path) is used for broadcasting or compatibility with legacy mechanisms (such as Rel-19). In this case (path), the device will skip the L1 header decoding, directly decode the entire PRDCH data payload, and attempt to find the target device's identifier within the payload in order to compare (match) it with its own device identifier to determine whether it is the target device.

[0186] In this way, the two-stage filtering architecture can solve the problem of high power consumption caused by invalid wake-ups in scenarios with dense deployment of IoT devices.

[0187] This application addresses the power bottleneck of high-power digital decoding (decoding the L1 control header or the complete PRDCH data payload) required for device ID (target device identifier) ​​identification. It utilizes the arrival time of the beacon signal as an implicit group identifier, relying only on the basic clock counting capability necessary for the device to process R-TAS (especially the CAP section) for timing detection. This mechanism transforms the group filtering operation from high-power "digital decoding and CRC check" to ultra-low-power "timing detection," achieving pre-filtering of groups before the main digital decoder is activated.

[0188] This application embodiment divides downlink transmission into Phase 1 (beacon signal transmission / listening phase) and Phase 2 (PRDCH transmission phase). PRDCH transmission only begins at the common transmission start point after all beacon slots in all groups have ended. This thorough temporal separation design enhances the robustness of group filtering and greatly reduces the risk of cross-group interference and false wake-ups caused by transmission duration.

[0189] This application embodiment broadcasts system parameters (e.g., information about the first offset set, the total number of groups, and the first function) on the network side. After receiving the system parameters, the Device can determine the time offset value corresponding to its group based on the system parameters. This enables a "group self-homing" mechanism, whereby the Device determines its own time offset value for its group through "self-computation." Compared to the method of explicitly assigning groups to a massive number of devices and mapping them to specific offset values ​​(e.g., the read / write device explicitly assigns a group and offset to each device via signaling), which results in high signaling overhead and management complexity, the "group self-homing" mechanism reduces signaling overhead and management complexity, saves device power consumption, and has high network scalability (even with the addition of a batch of Devices, no additional signaling overhead is required; the newly added batch of Devices can accurately determine their respective time offset values ​​based on the "group self-homing" mechanism). Correspondingly, the read / write device can also determine the group and offset value corresponding to any target device at any time through symmetric calculation, and then determine the wake-up time slot of the target device based on the corresponding offset value, achieving efficient and automated load balancing.

[0190] Optionally, the method provided in this application embodiment can also be applied to massive IoT firmware over-the-air (OTA) updates, emergency broadcast systems (EBS), and multi-tenant / multi-application scenarios.

[0191] With the explosive growth of IoT devices (such as Device 2b / C) in dense outdoor environments, the network needs to efficiently and in batches manage and maintain tens of thousands of devices logically belonging to different groups. However, traditional downlink paging or addressing mechanisms face significant challenges in handling such "group communication." Broadcasting OTA update commands would wake up all devices (regardless of whether they need updating), resulting in huge and unnecessary "group wake-up" power consumption. Using one-to-one addressing would require the network to send thousands of individual downlink wake-up signals to thousands of devices within the group, which is extremely inefficient and prone to signaling storms. Accurate and timely group wake-up is crucial for improving the maintainability and reliability of massive IoT systems.

[0192] By using the "first offset set" set in this application embodiment, the network can ensure that only specific batches of devices that need updating (e.g., assigned via a "group self-attribution hash mechanism" or "explicit allocation") are included. "All v1.1 firmware devices" at the corresponding time (e.g., At a specific time, alarms are activated, while all other unrelated devices remain in deep sleep due to the mismatch in time windows. In public safety or disaster early warning scenarios, this efficient group filtering capability can help the network immediately and accurately wake up alarm devices in specific areas or of specific types (such as Group_Fire_Alarms) without interfering with or delaying the normal operation of unrelated devices, ensuring low latency and high reliability of the alarm system.

[0193] It should be understood that Figures 1 to 12 The flowcharts or scene diagrams shown are for illustrative purposes only and are not intended to limit the embodiments of this application to the examples illustrated. In fact, those skilled in the art can interpret the embodiments based on... Figures 1 to 12 The examples in the document can be transformed into equivalent ways to obtain more implementations.

[0194] The above text combined Figures 1 to 12 This application describes in detail the Internet of Things (IoT) communication method provided in its embodiments. The following will combine... Figures 13 to 14 The device embodiments of this application are described in detail below. It should be understood that the communication device of this application embodiment can execute the various methods of the foregoing embodiments of this application, that is, the specific working processes of the various products below can be referred to the corresponding processes in the foregoing method embodiments.

[0195] In the embodiments described above, the terminal device may execute some or all of the steps in each embodiment; the network device may execute some or all of the steps in each embodiment. These steps or operations are merely examples, and the embodiments of this application may also perform other operations or variations thereof. Furthermore, the steps may be executed in different orders as presented in the embodiments, and it is not necessary to execute all the operations in the embodiments of this application. Moreover, the sequence number of each step does not imply the order of execution; the execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application.

[0196] Figure 13 This is a schematic block diagram of a communication device provided in an embodiment of this application. Figure 13 As shown, the communication device 1300 may include a communication module 1320. The communication module 1320 can implement corresponding communication functions, which can be internal communication functions of the communication device 1300 or communication functions between the communication device 1300 and other devices. Optionally, the communication module 1320 may also be referred to as a communication interface or transceiver module. Optionally, the communication device 1300 further includes a processing module 1310. The processing module 1310 can implement corresponding processing functions.

[0197] Optionally, the communication device 1300 further includes a storage module, which can be used to store instructions and / or data; the processing module 1310 can read the instructions and / or data in the storage module so that the communication device 1300 can implement the aforementioned method embodiments.

[0198] In one possible design, the communication device 1300 may correspond to the terminal device (e.g., an IoT device) in the above method embodiments, or a component (such as a circuit, chip, or chip system) configured in the terminal device. The communication device 1300 can be used to perform the steps or processes performed by the terminal device in any of the above method embodiments.

[0199] For example, the communication module 1320 is used to receive synchronization signals;

[0200] The processing module 1310 is used to start a first timer at a first moment. The duration of the first timer is determined according to a first offset value. The first moment is equal to or later than the end moment of the synchronization signal.

[0201] The communication module 1320 is also used to detect a beacon signal in the first window when the first timer expires, wherein the start time of the first window is the time when the first timer expires; and to receive a PRDCH when the beacon signal is detected in the first window.

[0202] The processing module 1310 is also used to enter a sleep state if no beacon signal is detected in the first window.

[0203] The above are merely examples; for detailed steps or procedures, please refer to the descriptions in the foregoing embodiments.

[0204] In one possible design, the communication device 1300 may correspond to the network device in the above method embodiments, or to a component (such as a circuit, chip, or chip system) configured in the network device. The communication device 1300 can be used to perform the steps or processes performed by the network device in any of the above method embodiments.

[0205] For example, the communication module 1320 is used to send a synchronization signal;

[0206] The processing module 1310 is used to start a first timer at a first moment. The duration of the first timer is determined according to a first offset value. The first moment is equal to or later than the end moment of the synchronization signal.

[0207] The communication module 1320 is also used to send a beacon signal in the first window when the first timer expires, the start time of the first window being the time when the first timer expires; after sending the beacon signal, it sends a PRDCH.

[0208] The above are merely examples; for detailed steps or procedures, please refer to the descriptions in the foregoing embodiments.

[0209] Figure 14 This is another schematic block diagram of the communication device 1400 provided in the embodiments of this application. The communication device 1400 may be a chip, chip system, or processor, etc., used by a terminal device or network device to implement the above-described methods. The communication device 1400 can be used to implement the methods described in the above-described method embodiments; for details, please refer to the descriptions in the above-described method embodiments.

[0210] like Figure 14 As shown, the communication device 1400 may include one or more processors 1410, which may also be referred to as processing units or processing modules, and can implement certain control functions. The processor 1410 may be a general-purpose processor or a dedicated processor, such as a baseband processor or a central processing unit. The baseband processor can be used to process communication protocols and communication data, while the central processing unit can be used to control the communication device 1400 (e.g., a base station, baseband chip, user, user chip), execute software programs, and process data from the software programs.

[0211] In an alternative design, the processor 1410 may also store instructions and / or data that can be executed by the processor 1410 to cause the communication device 1400 to perform the methods described in the above method embodiments.

[0212] In another alternative design, the communication device 1400 may include a communication interface 1420 for implementing receiving and transmitting functions. For example, the communication interface 1420 may be a transceiver circuit, interface, interface circuit, or transceiver. The transceiver circuit, interface, interface circuit, or transceiver for implementing receiving and transmitting functions may be separate or integrated. The aforementioned transceiver circuit, interface, interface circuit, or transceiver may be used for reading and writing code / data, or it may be used for transmitting or relaying signals.

[0213] Optionally, the communication device 1400 may include one or more memories 1430, which may store instructions that can be executed on the processor 1410, causing the communication device 1400 to perform the methods described in the above method embodiments. Optionally, the memories 1430 may also store data. Optionally, the processor 1410 may also store instructions and / or data. The processor 1410 and the memories 1430 may be provided separately or integrated together.

[0214] It should be understood that, in one possible design, the steps in the method embodiments provided in this application can be implemented by integrated logic circuits in the processor's hardware or by instructions in software form. The steps of the methods disclosed in the embodiments of this application can be directly implemented by a hardware processor, or implemented by a combination of hardware and software modules in the processor. The software modules can reside in random access memory, flash memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, registers, or other mature storage media in the art. This storage medium is located in memory, and the processor reads information from the memory and, in conjunction with its hardware, completes the steps of the above method. To avoid repetition, detailed descriptions are not provided here.

[0215] In one implementation, the communication device 1400 may correspond to the terminal device in the above method embodiments and may be used to execute the various steps and / or processes executed by the terminal device in the above method embodiments. The processor 1410 may be used to execute instructions stored in the memory 1430, and when the processor 1410 executes the instructions stored in the memory, the processor 1410 is used to execute the various steps and / or processes of the above method embodiments corresponding to the terminal device.

[0216] In another implementation, the communication device 1400 may correspond to the network device in the above method embodiments and may be used to execute the various steps and / or processes executed by the network device in the above method embodiments. The processor 1410 may be used to execute instructions stored in the memory 1430, and when the processor 1410 executes the instructions stored in the memory, the processor 1410 is used to execute the various steps and / or processes of the above method embodiments corresponding to the network device.

[0217] It should be understood that the aforementioned processing device can be one or more chips. For example, the processing device can be a field-programmable gate array (FPGA), an application-specific integrated circuit (ASIC), a system-on-chip (SoC), a central processor unit (CPU), a network processor (NP), a digital signal processor (DSP), a microcontroller unit (MCU), a programmable logic device (PLD), or other integrated chips.

[0218] It is understood that the memory in the embodiments of this application can be volatile memory or non-volatile memory, or may include both volatile and non-volatile memory. The non-volatile memory can be read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), or flash memory. The volatile memory can be random access memory (RAM), which is used as an external cache. By way of example, but not limitation, many forms of RAM are available, such as static random access memory (SRAM), dynamic random access memory (DRAM), synchronous dynamic random access memory (SDRAM), double data rate synchronous dynamic random access memory (DDR SDRAM), enhanced synchronous dynamic random access memory (ESDRAM), synchronous linked dynamic random access memory (SLDRAM), and direct rambus RAM (DR RAM). It should be noted that the memory used in the systems and methods described herein is intended to include, but is not limited to, these and any other suitable types of memory.

[0219] According to the method provided in the embodiments of this application, this application also provides a chip system, which includes one or more processors for calling and executing instructions stored in memory, thereby causing the method described in the embodiments of this application to be executed. The chip system may be composed of chips or may include chips and other discrete devices.

[0220] The chip system may include input circuits or interfaces for transmitting information or data, and output circuits or interfaces for receiving information or data.

[0221] According to the method provided in the embodiments of this application, this application also provides a communication system, which includes the aforementioned network device and terminal device (e.g., IoT device).

[0222] According to the method provided in the embodiments of this application, this application also provides a computer program product, which includes: computer program code, which, when run on a computer, causes the computer to execute the various steps or processes executed by the network device or terminal device in any of the foregoing method embodiments.

[0223] According to the method provided in the embodiments of this application, this application also provides a computer-readable storage medium storing program code, which, when run on a computer, causes the computer to execute the various steps or processes executed by the network device or terminal device in any of the foregoing method embodiments.

[0224] The computer-readable storage medium may be the aforementioned volatile memory or non-volatile memory, or it may include both volatile memory and non-volatile memory.

[0225] In the embodiments of this application, the terms and English abbreviations are exemplary examples given for ease of description and should not be construed as limiting the application in any way. This application does not preclude the possibility of defining other terms that can achieve the same or similar functions in existing or future agreements.

[0226] In the above embodiments, implementation can be achieved, in whole or in part, through software, hardware, firmware, or any combination thereof. When implemented in software, it can be implemented, in whole or in part, as a computer program product. The computer program product includes one or more computer instructions. When these computer instructions are loaded and executed on a computer, all or part of the processes or functions described in the embodiments of this application are generated.

[0227] In the several embodiments provided in this application, it should be understood that the disclosed systems, apparatuses, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between apparatuses or units may be electrical, mechanical, or other forms.

[0228] It should be understood that in the various embodiments of this application, the sequence number of each process does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application.

[0229] In summary, the above description is merely a preferred embodiment of the technical solution of this application and is not intended to limit the scope of protection of this application. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of protection of this application.

Claims

1. An Internet of Things (IoT) communication method, characterized in that, Applied to IoT devices, including: Receive synchronization signal; At the first moment, the first timer is started, the duration of which is determined based on the first offset value, and the first moment is equal to or later than the end moment of the synchronization signal; When the first timer expires, a beacon signal is detected in the first window, and the start time of the first window is the time when the first timer expires. If the beacon signal is detected in the first window, the physical reader receives data to the device channel PRDCH. If the beacon signal is not detected in the first window, it enters a sleep state; Before receiving the synchronization signal, the method further includes: Receive a broadcast message, the broadcast message including at least one of a first offset set, the total number of groups, and information about a first function; The first offset set includes N offset values, which are time offset values ​​relative to the first time point, and the N time offset values ​​include the first offset value; where N is an integer greater than or equal to 1. The total number of groups is used to indicate the number of IoT device groups assigned to the reader; The first function is used to map the IoT device to the first offset value.

2. The method according to claim 1, characterized in that, The step of receiving the physical reader to the device channel PRDCH when the beacon signal is detected in the first window includes: When the beacon signal is detected in the first window, a second timer is started. The duration of the second timer is determined based on the difference between the second offset value and the first offset value and a preset duration. The second offset value is the largest time offset value in the first offset set. At the timeout of the second timer, the main decoder is woken up and the PRDCH is received in the second window. The start time of the second window is determined according to the timeout of the second timer.

3. The method according to claim 1 or 2, characterized in that, The difference between any two distinct offset values ​​among the N offset values ​​is greater than the sum of the maximum timing error and the wireless channel delay spread of the IoT device.

4. The method according to claim 1 or 2, characterized in that, The first function includes at least one of the following: a hash function, a bit extraction operation function, a direct modulo operation function, a CRC check operation function, and a segmentation mapping function.

5. The method according to claim 4, characterized in that, The method further includes: After receiving the broadcast message, obtain the device identifier of the IoT device; Based on the hash function and the total number of groups, a hash operation is performed on the device identifier to obtain the first index; The first offset value is obtained by querying the first offset set based on the first index.

6. The method according to claim 1 or 2, characterized in that, The beacon signal does not contain information that needs to be digitally decoded, which includes device identification and / or cyclic redundancy check (CRC) code.

7. The method according to claim 1 or 2, characterized in that, The modulation method of the beacon signal is different from that of the PRDCH.

8. The method according to claim 1 or 2, characterized in that, The receiving physical reader-to-device channel (PRDCH) includes: Decode the device identifier and the first CRC code in the PRDCH; Calculate the second CRC code based on the device identifier in the PRDCH; If the first CRC code is different from the second CRC code, it enters a sleep state; If the first CRC code is the same as the second CRC code, determine whether the device identifier of the IoT device is the same as the device identifier carried in the PRDCH; If the device identifier of the IoT device is different from the device identifier carried in the PRDCH, it enters a sleep state. If the device identifier of the IoT device is the same as the device identifier carried in the PRDCH, continue decoding the PRDCH and execute the target task.

9. An Internet of Things (IoT) communication method, characterized in that, Applications in readers and writers include: Send synchronization signal; At the first moment, the first timer is started, the duration of which is determined based on the first offset value, and the first moment is equal to or later than the end moment of the synchronization signal; When the first timer expires, a beacon signal is sent in the first window, and the start time of the first window is the time when the first timer expires. After sending the beacon signal, the physical reader / writer is sent to the device channel PRDCH; Before sending the synchronization signal, the method further includes: Send a broadcast message, the broadcast message including at least one of a first offset set, the total number of groups, and information about a first function; The first offset set includes N offset values, which are time offset values ​​relative to the first time point, and the N time offset values ​​include the first offset value; where N is an integer greater than or equal to 1. The total number of groups is used to indicate the number of IoT device groups assigned to the reader; The first function is used to map the IoT device to the first offset value.

10. The method according to claim 9, characterized in that, After sending the beacon signal, sending the physical reader to the device channel PRDCH includes: After sending the beacon signal, a second timer is started. The duration of the second timer is determined based on the difference between the second offset value and the first offset value and a preset duration. The second offset value is the largest time offset value in the first offset set. At the timeout of the second timer, the PRDCH is sent in the second window, the start time of which is determined based on the timeout of the second timer.

11. The method according to claim 9 or 10, characterized in that, The difference between any two distinct offset values ​​among the N offset values ​​is greater than the sum of the maximum timing error and the wireless channel delay spread of the IoT device.

12. The method according to claim 9 or 10, characterized in that, The first function includes at least one of the following: a hash function, a bit extraction operation function, a direct modulo operation function, a CRC check operation function, and a segmentation mapping function.

13. The method according to claim 12, characterized in that, Before sending the beacon signal, the method further includes: Based on the hash function and the total number of groups, a hash operation is performed on the device identifier of the target device to obtain the first index; The first offset value is obtained by querying the first offset set based on the first index.

14. The method according to claim 9 or 10, characterized in that, The beacon signal does not contain information that needs to be digitally decoded, which includes device identification and / or cyclic redundancy check (CRC) code.

15. The method according to claim 9 or 10, characterized in that, The modulation method of the beacon signal is different from that of the PRDCH.

16. A communication device, characterized in that, The device includes at least one processor coupled to a memory storing a program or instructions, the processor executing the program or instructions to cause the communication device to perform the method as described in any one of claims 1 to 15.

17. A computer-readable storage medium having a computer program or instructions stored thereon, characterized in that, When the computer program or instructions are executed, they cause the computer to perform the method as described in any one of claims 1-15.

18. A communication system, characterized in that, This includes the Internet of Things (IoT) device in the method of any one of claims 1-8, and the reader / writer in the method of any one of claims 9-15.

Images