Method and apparatus for improving beacon reception

Abstract

The present disclosure relates to a system and method for improving performance of an Internet of Things (IoT) device in receiving a beacon signal. The method comprises the steps of receiving a first signal from an access point (AP) of a network environment, extracting a time synchronization value of the AP from the first signal, obtaining a local time synchronization value corresponding to the time synchronization value of the AP, and determining whether a preset condition is met or not. The preset condition may indicate that reception of the first signal is to be interrupted. The method further comprises the steps of obtaining a time synchronization offset value in response to determining that the preset condition is met, adjusting a local time synchronization value based on the time synchronization offset value and the time synchronization value of the AP, and preparing to receive the second signal according to the adjusted local time synchronization value.

Description

Technical Field

[0001] The present disclosure relates generally to signal reception. In particular, example embodiments of the present disclosure relate to systems and methods for improving the performance of Internet of Things (IoT) devices in receiving beacon signals. Background Art

[0002] The IoT system consists of a network of physical objects (called "smart devices" or "IoT devices") embedded with sensors, software, and other technologies that enable connectivity and exchange of data with other devices via the Internet. For example, IoT devices are used in home automation to control lighting, heating and air conditioning, media and security systems, and camera systems.

[0003] IoT devices can periodically receive beacon signals from beacon devices such as access points (APs). Beacon signals carry timing information that helps maintain synchronization between IoT devices and the IoT network. Summary of the invention

[0004] In one aspect, a method is provided. The method includes receiving a first signal from an access point (AP) of a network environment, extracting a time synchronization value of the AP from the first signal, obtaining a local time synchronization value corresponding to the time synchronization value of the AP, and determining whether a preset condition is met. The time synchronization value of the AP may include a timing synchronization function (TSF) value of the AP. The local time synchronization value may include a TSF value read on a local counter. The preset condition may indicate that reception of the first signal is about to be interrupted. The method also includes: in response to determining that the preset condition is met, obtaining a time synchronization offset value, adjusting the local time synchronization value based on the time synchronization offset value and the time synchronization value of the AP, and preparing to receive a second signal according to the adjusted local time synchronization value.

[0005] In one aspect, an Internet of Things (IoT) device is provided. The IoT device includes a processor. The IoT device also includes a memory storing instructions, which, when executed by the processor, configures the IoT device to receive a first signal from an access point (AP) of a network environment, extract a time synchronization value of the AP from the first signal, obtain a local time synchronization value corresponding to the time synchronization value of the AP, and determine whether a preset condition is met. The time synchronization value of the AP may include a timing synchronization function (TSF) value of the AP. The local time synchronization value may include a TSF value read on a local counter. The preset condition indicates that the reception of the first signal is about to be interrupted. In response to determining that the preset condition is met, the instruction further configures the IoT device to obtain a time synchronization offset value, adjust the local time synchronization value based on the time synchronization offset value and the time synchronization value of the AP, and prepare to receive a second signal according to the adjusted local time synchronization value.

[0006] In one aspect, a non-transitory computer-readable storage medium is provided. The computer-readable storage medium includes instructions, which, when executed by a computer, cause the computer to receive a first signal from an access point (AP) of a network environment, extract a time synchronization value of the AP from the first signal, obtain a local time synchronization value corresponding to the AP time synchronization value, and determine whether a preset condition is met. The time synchronization value of the AP may include a timing synchronization function (TSF) value of the AP. The local time synchronization value may include a TSF value read on a local counter. The preset condition indicates that reception of the first signal is about to be interrupted. In response to determining that the preset condition is met, the instruction further causes the computer to obtain a time synchronization offset value, adjust the local time synchronization value based on the time synchronization offset value and the time synchronization value of the AP, and prepare to receive a second signal according to the adjusted local time synchronization value. BRIEF DESCRIPTION OF THE DRAWINGS

[0007] To facilitate identification of any particular element or activity discussed, the most significant digit or digits in a reference number refer to the figure numeral that first introduces that element or activity.

[0008] Figure 1 A block diagram of an Internet of Things (IoT) system is shown, according to some example embodiments.

[0009] Figure 2 A block diagram of an Internet of Things (IoT) device is shown, according to some example embodiments.

[0010] Figure 3 A schematic diagram illustrating data stored in a beacon signal according to some example embodiments.

[0011] Figures 4A-4C A schematic diagram illustrating data received from a beacon signal when reception of the beacon signal is interrupted according to some example embodiments.

[0012] Figure 5 Schematic diagram showing a comparison of a beacon signal while being transmitted and after being fully processed according to some example embodiments.

[0013] Figure 6 A flow chart illustrating operation of an Internet of Things device in preparing to receive a second signal according to some example embodiments.

[0014] Figure 7 A flow chart illustrating operation of an Internet of Things device in determining a time synchronization offset value according to some example embodiments.

[0015] Figure 8 A flow diagram illustrating operation of an Internet of Things device in determining a target transmission time according to some example embodiments. DETAILED DESCRIPTION

[0016] The following description includes systems, methods, techniques, instruction sequences and computer machine program products that embody the illustrative embodiments of the present disclosure. In the following description, for the purpose of explanation, many specific details are set forth to provide an understanding of the various embodiments of the subject matter of the present invention. However, it is apparent to those skilled in the art that the embodiments of the subject matter of the present invention can be implemented without these specific details. Usually, well-known instruction instances, protocols, structures and techniques need not be shown in detail.

[0017] As described above, the IoT device periodically receives beacon signals and synchronizes itself with the AP based on the time synchronization information contained in the beacon signal. When the AP sends out a beacon signal, it can include the AP's current timing synchronization function (TSF) value in the beacon signal. The TSF value represents the timestamp when the beacon signal was sent. The IoT device can then adjust its local TSF value based on the TSF value in the received beacon signal to synchronize with the IoT system. If the completion time after the beacon signal is fully received / processed is known, the adjustment of the local TSF value can be more accurate because the calculation of the local TSF value itself includes the hardware processing time of the beacon signal. On the contrary, if the beacon signal is not fully received / processed, the accuracy of time synchronization will be greatly reduced because the hardware processing time of the beacon signal cannot be calculated.

[0018] However, there may be situations where a beacon signal cannot be received in its entirety. For example, an Internet of Things (IoT) device may proactively skip a portion of a beacon signal to reduce its power consumption (e.g., when it determines from the data field in the beacon signal that there are no data packets (or data packets) to receive). As another example, an IoT device may preempt the communication of a current beacon signal for a higher priority coexistence signal.

[0019] The present disclosure provides a system and method for predetermining the average hardware processing time when processing a complete beacon signal. When only a portion of the beacon signal is processed, the average hardware processing time is used to calibrate the local TSF value. The target beacon transmission time (TBTT) can also be calculated based on the calibrated local TSF value, and the IoT device can prepare to receive the next beacon signal according to the TBTT. The present disclosure potentially has at least the following advantages:

[0020] 1. By processing only part of the beacon signal, the power consumption of IoT devices can be reduced.

[0021] 2. Upon receiving beacon signals, IoT devices can switch to communications with higher priority without losing time synchronization with the AP.

[0022] Figure 1A block diagram of an Internet of Things (IoT) system is shown according to some example embodiments. The IoT system 100 may include an IoT server 102, a network (e.g., the Internet 104), an access point 106, an air (AIR) interface 108, IoT devices 110 and 112, IoT sensors 114 and 116, a mobile device 118, and a monitoring device 120.

[0023] The IoT server 102 serves as the backbone of the IoT system 100, managing data and coordinating communications between other devices in the IoT system. The IoT server 102 collects, processes, and stores data sent from the IoT devices 110 and 112 and the IoT sensors 114 and 116. It also performs tasks such as device management, data analysis, and security enforcement to ensure smooth operations and gain valuable insights from the collected data. For example, the IoT server 102 can receive instructions from the monitoring device 120 via the Internet 104 and manage the IoT device 110 to perform a specific task in accordance with the instructions.

[0024] The Internet 104 is a network that allows devices in the IoT system 100 to communicate and exchange data. The Internet 104 provides a path for data to be transmitted from the IoT devices 110 and 112 and the IoT sensors 114 and 116 to the IoT server 102, and vice versa. The Internet 104 also enables remote management, data analysis, and over-the-air upgrades of the IoT devices. It should be noted that the Internet 104 can be used in combination with other types of networks, or replaced by other types of networks.

[0025] Access point 106 acts as a bridge between devices (e.g., IoT devices 110 and 112 and IoT sensors 114 and 116) and Internet 104. It enables devices to connect to Internet 104 wirelessly, such as Wi-Fi, and facilitates data transmission between these devices and IoT server 102.

[0026] The air interface 108 refers to the radio frequency spectrum used for wireless communication between the access point 106 and the IoT devices 110 and 112 and the IoT sensors 114 and 116. It consists of standards, protocols, and technologies that define data formatting and wireless transmission. For example, the air interface 108 can adopt a Wi-Fi network under the IEEE 802.11 standard. Alternatively or additionally, the air interface 108 can adopt Bluetooth, ZigBee, Z-Wave, LPWAN, RFID, NFC, etc.

[0027] IoT devices 110 and 112 are physical devices, such as appliances, machines, or gadgets, that are equipped with the hardware and software required to perform specific tasks. They interact with IoT sensors 114 and 116 and communicate with IoT server 102 through access point 106 and the Internet 104.

[0028] IoT sensors 114 and 116 are devices or modules that detect changes in the environment or system and convert these changes into data that can be understood and used by IoT devices 110 and 112 or IoT server 102. These sensors can monitor various parameters such as temperature, humidity, pressure, light, motion or other environmental factors.

[0029] Mobile device 118 is a portable device that can interact with the IoT system, such as a smartphone or tablet. It can be used to remotely monitor, control, or configure IoT devices 110 and 112. It communicates with IoT server 102 via the Internet 104, allowing users to interact with IoT system 100 from anywhere.

[0030] The monitoring device 120 is a device specifically designed to observe and display information from the IoT system. This can be a dedicated display that displays data collected by the IoT sensors 114 and 116, or it can be a computer used by a system administrator to manage the IoT system 100. It provides real-time or historical data visualization, allowing for effective system monitoring and troubleshooting.

[0031] In some embodiments, access point 106 may periodically broadcast a beacon signal. The beacon signal may be received by devices in IoT system 100, such as IoT devices 110 and 112, IoT sensors 114 and 116, and / or mobile device 118. The beacon signal carries time synchronization information that allows IoT devices 110 and 112 to align their internal clocks with access point 106. This synchronization ensures that all devices in the network use the same time reference, thereby improving coordination and efficient communication. The beacon signal also serves as a presence indicator, letting IoT devices 110 and 112 know that access point 106 is within range and operational. In addition, it provides necessary network-related information such as service set identifier (SSID), supported data rates, and other parameters required for IoT devices to effectively connect and communicate with the network.

[0032] In energy-constrained environments and / or when IoT devices 110 and 112 are running on batteries, using beacon signals for time synchronization can also help reduce power consumption. For example, IoT devices 110 and 112 can enter a power-saving mode when not sending or receiving data and wake up in synchronization with beacon signals (e.g., waking up at a predetermined target beacon transmission time (TBTT)). Details about the data stored in the beacon signals can be found at Figure 3and the corresponding description.

[0033] It should be noted that the present disclosure is not limited to an IoT system having a Wi-Fi network under the IEEE 802.11 standard. Instead, the present disclosure can be used in any other same or different type of system having the same or different type of network environment. Such applications are within the scope of protection of the present disclosure.

[0034] Figure 2 1 is a block diagram illustrating an Internet of Things (IoT) device according to some example embodiments. The IoT device 110 (or IoT device 112) may include a physical layer (PHY) 202, a medium access control (MAC) receive (RX) analyzer 204, an RX buffer 206, a timing synchronization function (TSF) hardware (HW) analyzer module 208, and a TSF local counter 216. The TSF hardware analyzer module 208 may also include a TSF analyzer and controller 210, a TSF access point (AP) buffer 212, and a TSF local buffer 214.

[0035] PHY 202 is the first and most basic layer for networking and is responsible for the actual transmission and reception of data over the network medium (e.g., air interface 108). PHY 202 transmits data from IoT device 110 to the network medium and receives data sent from the network medium to IoT device 110. In transmission, PHY 202 converts digital data into signals (electrical, optical, or radio frequency). In reception, PHY 202 converts these signals back into digital data. PHY 202 also establishes bit synchronization, which ensures that the sender and receiver are consistent in interpreting when one bit ends and another begins.

[0036] The MAC reception analyzer 204 is used to analyze the MAC header of the received signal (e.g., the MAC header 302). Taking the beacon signal as an example, the first 24 or 28 bytes (192 or 224 bits) of the beacon signal correspond to the MAC header, and the 8 bytes (64 bits) immediately following the MAC header correspond to the TSF value. When the MAC reception analyzer 204 identifies that the received signal is a beacon signal (e.g., by checking the frame control field of the MAC header), it starts writing the portion corresponding to the TSF value of the AP into the RX buffer 206 (e.g., from the 25th byte to the 32nd byte, or from the 29th byte to the 36th byte, depending on the length of the MAC header). For details about the data stored in the beacon signal, see Figure 3 When the MAC receive analyzer 204 finishes writing the TSF value to the RX buffer 206 , the MAC receive analyzer 204 may send a control signal to the TSF analyzer and controller 210 of the TSF hardware analyzer module 208 .

[0037] After receiving a control signal indicating that the TSF value has been received and fully written to the RX buffer 206, the TSF analyzer and controller 210 may read the value stored in the RX buffer 206 and write it to the TSF access point buffer 212. The TSF analyzer and controller 210 may also read the count on the TSF local counter 216 and write it to the TSF local buffer 214. Specifically, the value stored in the TSF access point buffer 212 corresponds to the TSF value of the AP (e.g., access point 106) when it sends out a beacon signal. The value stored in the TSF local buffer 214 corresponds to the TSF value of the IoT device 110 after it processes the AP's TSF value. The difference between the values ​​stored in the TSF access point buffer 212 and the TSF local buffer 214 may be calculated and used to correct the TSF value of the IoT device 110 or to estimate the target beacon transmission time (TBTT). The hardware processing time may be used to further calibrate the TSF value or TBTT. Detailed information on the hardware processing time calculation may be found in Figure 7 and its description. In a variation of the above method, the TSF analyzer and controller 210 can read the count on the TSF local counter 216 immediately before the MAC receive analyzer 204 starts reading the TSF value of the beacon signal. Unlike the above method, the count read in this variation corresponds to the TSF value of the IoT device 110 before processing the TSF value of the AP. Compared to the above method, this variation generates two interrupts: one before the TSF is read and one after the TSF is read, while the above method only generates one interrupt. However, compared to the above method, this variation can more directly calculate the start time of the TSF value (e.g., TSF_START_LOCAL, in Figure 5 and Figure 8 Both methods are protected within the scope of the present disclosure.

[0038] Figure 3 Schematic diagram showing data stored in a beacon signal according to some example embodiments. Figure 3 As shown, the beacon signal may include a MAC header 302, a TSF 304, a traffic indication map (TIM) element 306, a frame check sequence (FCS) 308, and other parts not labeled in the figure.

[0039] The MAC header 302 may include a 2-byte frame control field, a 2-byte duration / ID field, three 6-byte address fields, and a 2-byte sequence control field. Optionally, the MAC header 302 may include a 4-byte high throughput (HT) control field. Depending on whether the HT control field is present, the MAC header 302 may be 24 bytes or 28 bytes long.

[0040] TSF 304 is an 8-byte field representing the number of microseconds that have passed since the access point (eg, access point 106) began operation. The value of this field corresponds to the value of the TSF timer of the access point when the first bit of the beacon signal is transmitted.

[0041] The TIM element 306 may include an element ID field, a length field, a transmission traffic indication message (DTIM) count field, a DTIM period field, a bitmap control field, and a partial virtual bitmap field. The bitmap control field is 1 byte (8 bits) in length. The first bit of the bitmap control field is a traffic buffer map (TBM) bit, which is used to indicate whether the access point has buffered a broadcast data packet or a multicast data packet. If the TBM bit is set to 1, it indicates that the AP has buffered a broadcast data packet or a multicast data packet. If the bit is set to 0, it indicates that there is no buffered broadcast data packet or multicast data packet at the AP. The last 7 bits of the bitmap control field indicate the starting offset of the partial virtual bitmap. These 7 bits indicate the starting position of the partial virtual bitmap of the site, and the setting of the partial virtual bitmap is searched from the starting position. Therefore, when a site (e.g., IoT devices 110 and 112, IoT sensors 114 and 116) receives a beacon signal, it can check the TBM bit in the bitmap control field of the received beacon signal. If the bit is 1, the station understands that the AP may have buffered the broadcast or multicast data packet and remains awake to receive it. If the bit is 0, the station can further check the partial virtual bitmap after controlling the value of the remaining 7 bits of the offset bitmap field. It should be noted that the term data packet refers to a unicast data packet, a broadcast data packet, or a multicast data packet in the present disclosure. Alternatively, a data packet refers only to a unicast data packet, and a broadcast data packet and a multicast data packet are referred to as a broadcast packet and a multicast packet, respectively.

[0042] In some examples, the access point assigns an association ID (AID) to each station. The partial virtual bitmap field indicates a bit sequence of whether the associated station has buffered data at the access point. Specifically, each bit in the partial virtual bitmap field corresponds to the AID of the associated station. If the bit is set to 1, it indicates that the AP has buffered the unicast data packet of the station with the corresponding AID. If the bit is set to 0, it indicates that the station does not have a buffered unicast data packet at the AP. Therefore, when the station receives a beacon signal and detects that the TBM bit in the bitmap control field of the received beacon signal is 0, it can further check the partial virtual bitmap field of the received beacon signal to see whether the data packet is buffered for the station or for other stations. If the bit in the partial virtual bitmap field corresponding to the AID of the station is 1, the station knows that it has data waiting to be received at the AP and remains awake to receive it. If the bit is 0, the station can return to energy saving mode.

[0043] The FCS 308 is a 4-byte field located at the end of the frame. It is calculated based on all other bits in the frame (including the MAC header and body, but excluding the physical layer preamble and header). When a device sends a frame, it calculates the FCS and includes it in the frame. When a receiving device gets the frame, it performs the same calculation on the received bits and compares the result with the received FCS. If the two values ​​match, the receiving device assumes that the frame was transmitted correctly. If they do not match, the receiving device assumes that an error occurred during transmission and discards the frame.

[0044] Figures 4A-4C A schematic diagram illustrating data received from a beacon signal when reception of the beacon signal is interrupted according to some example embodiments. An interruption in receiving a beacon signal, resulting in the beacon signal not being completely received, is also referred to as an "RX abort" in this disclosure.

[0045] like Figure 4A As shown, MAC header 402 and TSF 404 may correspond to MAC header 302 and TSF 304, respectively. RX abort may occur at any time during reception of a beacon signal. As long as MAC header 402 and TSF 404 have been completely received / processed, the present disclosure may be applicable to maintaining accurate time synchronization between a station and an AP after an RX abort occurs. Figure 4B and Figure 4C These are two example scenarios where RX abort occurs, but they are not limiting. Instead, the present disclosure may also be used in other scenarios.

[0046] refer to Figure 4B, TIM element 406 may be similar to TIM element 306, including a bitmap control field and a partial virtual bitmap field. In some examples, a station (e.g., IoT devices 110 and 112, IoT sensors 114 and 116) may determine that the TBM bit of the bitmap control field and the bits of the partial virtual bitmap corresponding to its AID are both 0. In other words, the station may determine that there are no data packets buffered for the station at the AP, or that the data packets buffered at the AP are not its own station data packets. The station may then generate an interrupt to stop receiving or processing the remainder of the beacon signal in order to reduce its power consumption. For example, the portion of the beacon signal after the TIM element 406, including the FCS, is not received and processed.

[0047] refer to Figure 4C , beacon signal A is broadcast over the air interface. When there is no coexistence signal B, the station receives beacon signal A completely. When there is a coexistence signal B with a higher priority than beacon signal A, RX abort occurs. Specifically, the station preempts the communication of signal A for signal B. The priority used here refers to the reception priority associated with the connection type (also called connectivity type, such as WiFi, Bluetooth and / or cellular connection). However, this is not restrictive.

[0048] For devices that support WiFi, Bluetooth, and / or cellular connections, RX suspension may occur when two or more of these connections have a time conflict and they use or request to use frequency bands that are close in frequency. For example, signal B is related to the Bluetooth connection and signal A is related to the WiFi connection. Both Bluetooth and WiFi connections use the 2.4 GHz frequency band. The Bluetooth connection has a predetermined time sequence and the WiFi connection has a predetermined TBTT. When there is a time conflict, an arbitration mechanism can be triggered to decide which signal to receive based on the priority of the signals. If the station chooses to receive the Bluetooth signal (signal B), it receives the Bluetooth signal according to the predetermined time sequence, which may interrupt the reception of signal A. Similarly, RX suspension may occur when WiFi and cellular connections coexist and have a time conflict. For example, the frequency range of bands 40 and 41 of 4G Long Term Evolution (LTE) and bands N40 and N41 of 5G New Radio (NR) is about 2.4 GHz (the frequency of the band that WiFi connections can use). When cellular connections have a time conflict with WiFi connections, they may interfere with the WiFi connection and similar RX suspension may occur.

[0049] Figure 5 Schematic diagram showing a comparison of a beacon signal during transmission and after full processing according to some example embodiments. Figure 5As shown, the beacon signal as a whole is offset by the hardware processing time (including hardware reception time, calculation time, decoding time, etc.). It can be assumed that the TSF offset value 502 is equal to the FCS offset value 504. In some examples, before reading the first bit of TSF in the beacon signal or after reading the last bit of TSF, the local TSF value ("TSF_AP_LOCAL") of the station (e.g., IoT devices 110 and 112, IoT sensors 114 and 116) can be read from the TSF local counter (e.g., TSF local counter 216) and written to the TSF local buffer (e.g., TSF local buffer 214). The TSF ("TSF_AP") in the beacon signal can be written to the TSF access point buffer (e.g., TSF access point buffer 212). The TSF local buffer and the TSF access point buffer are typically present as registers, but this is not limiting. The TSF offset value 502 ("HW_DELTA", also known as the hardware processing time) can be predetermined based on the fully processed sample beacon signal. Detailed information on determining the TSF offset value 502 can be found in. Figure 7 The start time of the local TSF value ("TSF_START_LOCAL") can be calculated as: TSF_START_LOCAL=TSF_AP_LOCAL-HW_DELTA-TSF_LENGTH_TIME(1) Where TSF_LENGTH_TIME is the quotient of the length of TSF 506 and the beacon transmission rate. For example, if the beacon transmission rate is 1 Mbps, the length of TSF 506 is 8 bytes. TSF_LENGTH_TIME is 64 μs (8*8 / 100000) In the case where the local TSF value is read immediately before processing the TSF in the beacon signal, TSF_LENGTH_TIME in equation (1) can be omitted.

[0050] The difference between the TSF value of the access point and the TSF value of the station can be calculated as: TSF_DELTA=TSF_START_LOCAL–TSF_AP(2)

[0051] The local target beacon transmission time ("TBTT_Beacon_LOCAL"), i.e., the time point at which the current beacon is received without synchronization with the AP, taking into account hardware processing time, can be calculated as: TBTT_Beacon_LOCAL=TSF_START_LOCAL–MACHD_LENGTH_TIME(3) Where MACHD_LENGTH_TIME is the quotient of the length of the MAC header 508 and the beacon transmission rate. For example, if the beacon transmission rate is 1 Mbps, the length of the MAC header 508 is 24 bytes (eg, without the HT control field). MACHD_LENGTH_TIME is 192 μs (24*8 / 1000000).

[0052] The target beacon transmission time (“TBTT_Beacon”) for the next beacon signal can be calculated as: TBT_Beacon = TBT_Beacon_LOCAL + TSF_DELTA + beacon interval (4) The beacon interval is a preset value indicating how often the AP sends a beacon signal. For example, the beacon interval may be 100 TU or approximately 102.4 ms.

[0053] It should be noted that equation (4) is based on the assumption that there is no transmission time or delay on the air interface when the beacon signal is broadcast at TBTT. If the beacon signal is not broadcast at TBTT, or the delay on the air interface is taken into account, equation (4) should be updated accordingly. For example, if the beacon signal is not broadcast at TBTT (e.g., due to delay), TBTT_Beacon can be calculated as: in is an operator that rounds the number inside down to the nearest integer.

[0054] It should be noted that although the present disclosure addresses the offset caused by hardware processing time, the offset caused by other reasons such as air transmission time, network traffic, propagation delay, clock drift, etc. can also be resolved by the same or similar method as the present method. Such applications or modifications are also protected by the present disclosure.

[0055] Figure 6 A flowchart illustrating the operation of an IoT device in preparing to receive a second signal according to some example embodiments. Method 600 may be embodied in computer-readable instructions executed by one or more processors, such that the operations of method 600 may be performed in part or in whole by functional components of IoT device 110 (or IoT device 112); therefore, the following is referred to by way of example. Figure 6 The method 600 is described. However, it should be understood that at least some operations of the method 600 may be deployed on various other hardware configurations besides the IoT device 110. Furthermore, the operations of the method 600 may be partially omitted or performed in any order.

[0056] In operation 602, the IoT device 110 may receive a first signal from an access point (AP) of a network environment. The first signal may be a beacon signal. The network environment may be a Wi-Fi network under the IEEE 802.11 standard. Alternatively or additionally, the network environment may be Bluetooth, ZigBee, Z-Wave, LPWAN, RFID, NFC, etc.

[0057] In operation 604, the IoT device 110 can extract the time synchronization value of the AP from the first signal. In some examples, the time synchronization value of the AP is an 8-byte TSF value immediately following the MAC header. Specifically, when the MAC reception analyzer (e.g., the MAC reception analyzer 204) identifies that the first signal is a beacon signal (e.g., by checking the frame control field of the MAC header), it starts writing a portion corresponding to the TSF value of the AP to the RX buffer (e.g., the RX buffer 206).

[0058] In operation 606, the IoT device 110 may obtain a local synchronization value corresponding to the time synchronization value of the AP. In some examples, the IoT device 110 may read a count on a TSF local counter (e.g., TSF local count 216). It should be noted that operation 606 and operation 604 may be performed concurrently or in any order. For example, the local synchronization value is obtained immediately before or after extracting the time synchronization value of the AP from the first signal.

[0059] In operation 608, the IoT device 110 may determine whether a preset condition is satisfied. The preset condition may indicate that reception of the first signal is to be interrupted. For example, the preset condition includes determining that no data packets are to be received (e.g., see Figure 4B ) and / or determining that another signal will preempt communication of the first signal (see, for example, Figure 4C ).

[0060] To determine that no data packets are to be received as an example of a preset condition, the IoT device 110 may determine whether the data field of the beacon signal indicates that no data packets for the IoT device are buffered at the AP. Specifically, the first signal includes a TIM element. The TIM element includes a bitmap control field and a partial virtual bitmap field. The bitmap control field contains a TBM bit (i.e., the first bit) indicating whether a data packet (i.e., a broadcast data packet or a multicast data packet) is buffered at the access point. If the TBM bit is set to 1, it indicates that the AP has buffered the data packet. If the TBM bit is set to 0, the partial virtual bitmap field (and the remaining 7 bits of the bitmap control field) may be further checked to determine whether the AP has a buffered data packet (i.e., a unicast data packet). Specifically, the access point assigns an association ID (AID) to each station. The partial virtual bitmap field is a bit sequence indicating whether the associated station has buffered a data packet at the access point. Each bit in the partial virtual bitmap field corresponds to the AID of the associated station. If the bit is set to 1, it indicates that the AP has a buffered frame for the station corresponding to the AID. If the bit is set to 0, it indicates that there are no data packets buffered at the AP for this station.

[0061] Taking the precondition of determining that the coexisting signal will preempt the communication of the current signal as an example, the IoT device 110 may determine whether the coexisting signal has a higher priority than the current signal. Detailed information about this scenario can be found at Figure 4C and its description.

[0062] In response to determining that a preset condition is met (for example, when the TBM bit is 1 or the bit in the partial virtual bitmap field corresponding to the AID of the IoT device 110 is 1, when the priority of the coexistence signal is higher than the priority of the first signal), method 600 can proceed to operation 614; otherwise, method 600 can proceed to operation 610.

[0063] In operation 610 , the IoT device 110 may completely receive the first signal.

[0064] In operation 612, the IoT device 110 may determine a time synchronization offset value corresponding to the first signal. The time synchronization offset value is the difference between an actual time point at which the first signal is completely received and processed and a theoretical time point calculated without considering signal processing time and air transmission time. The time synchronization offset value is determined when the first signal is completely and uninterruptedly received.

[0065] In operation 614, the IoT device 110 may obtain a time synchronization offset value. The time synchronization offset value is obtained based on an average signal processing time corresponding to at least one sample signal. Detailed information on determining a time synchronization offset value based on a signal processing time may be found in Figure 7and its description.

[0066] In operation 616, the IoT device 110 may adjust the local time synchronization value based on the time synchronization offset value and the time synchronization value of the AP. For details on the adjustment, see formulas (1)-(2) and their descriptions.

[0067] In operation 618, the IoT device 110 may prepare to receive the second signal according to the adjusted local time synchronization value. For details, see formula (3), (4) or (3), (5) and their descriptions.

[0068] Optionally, in operation 620 , the IoT device 110 may enter or re-enter a power saving mode.

[0069] Figure 7 A flow chart illustrating the operation of an IoT device in determining a time synchronization offset value according to some example embodiments. Method 700 may be embodied in computer-readable instructions for execution by one or more processors, such that the operations of method 700 may be performed in part or in whole by functional components of IoT device 110 (or IoT device 112); therefore, method 700 is described below with reference thereto by way of example. However, it should be understood that at least some of the operations of method 700 may be deployed on various other hardware configurations in addition to IoT device 110. Furthermore, the operations of method 700 may be partially omitted or performed in any order.

[0070] In operation 702, the IoT device 110 may receive at least one sample signal from an AP. In some examples, each of the at least one sample signal is a fully processed beacon signal. The at least one sample signal may be processed sequentially, collectively, or independently.

[0071] In operation 704, the IoT device 110 may determine at least one signal processing time, wherein each signal processing time corresponds to one of the at least one sample signal. Specifically, the signal processing time is determined as a difference between a time when the beacon signal is completely received (e.g., when the last bit of the beacon signal is received via the air interface) and a time when the beacon signal is completely processed (e.g., when the last bit of the frame check sequence (FCS) of the beacon signal is completely processed).

[0072] In operation 706, the IoT device 110 may determine a time synchronization offset value (e.g., HW_DELTA) based on at least one signal processing time. For example, when at least one sample signal is processed sequentially, the time synchronization offset value is calculated by applying a filter to at least one signal processing time. The filter may include a moving average filter, an alpha filter, an alpha-beta filter, a Kalman filter, a median filter, a Wiener filter, an adaptive filter. Alternatively, the time synchronization offset value is an average value of at least one signal processing time when the at least one sample signal is processed independently.

[0073] Optionally, in operation 708 , the IoT device 110 may receive a second signal from the AP. Operation 708 may be a subsequent operation after operations 618 and 620 .

[0074] Optionally, in operation 710 , the IoT device 110 may determine a signal processing time corresponding to the second signal.

[0075] Optionally, in operation 712, the IoT device 110 may update the time synchronization offset value according to the signal processing time corresponding to the second signal. For example, the IoT device 110 applies the same or different filters to the signal processing time corresponding to the second signal and the time synchronization offset value to generate an updated time synchronization offset value.

[0076] Figure 8 A flowchart illustrating the operation of an IoT device in determining a target transmission time according to some example embodiments. Method 800 may be embodied in computer-readable instructions for execution by one or more processors, such that the operations of method 800 may be performed in part or in whole by functional components of IoT device 110 (or IoT device 112); therefore, the following is referred to by way of example. Figure 8 The method 800 is described. However, it should be understood that at least some operations of the method 800 may be deployed on various other hardware configurations besides the IoT device 110. In addition, the operations of the method 800 may be partially omitted or performed in any order.

[0077] In operation 802, the IoT device 110 may determine a time synchronization offset value HW_DELTA. For details on determining HW_DELTA, see Figure 7 and its description.

[0078] In operation 804, the IoT device 110 may determine the local time synchronization value of the AP TSF_AP_LOCAL TSF_AP_LOCAL may be read from a TSF local counter (eg, TSF local counter 216).

[0079] In operation 806, the IoT device 110 may obtain a data transmission speed of the first signal. The data transmission speed may be obtained through a PHY layer (eg, PHY 202). For example, the data transmission speed is 1 Mbps.

[0080] In operation 808, the IoT device 110 determines the data transmission time TSF_LENGTH_TIME of the time synchronization value (TSF value) according to the data length of the AP time synchronization value and the data transmission speed of the first signal. In some examples, the length of the AP time synchronization value (TSF value) is 8 bytes, and the data transmission time TSF_LENGTH_TIME is 64 μs (8*8 / 100000). In the case where the local TSF value is obtained immediately before reading the TSF value in the beacon signal, operation 808 can be omitted.

[0081] In operation 810, the IoT device 110 determines the start time of the local time synchronization value TSF_START_LOCAL based on the data transmission time, the time synchronization offset value, and the local time synchronization value of the AP. For detailed information on the determination of TSF_START_LOCAL, please refer to formula (1) and its description. In the case where the local TSF value is obtained immediately before reading the TSF value in the beacon signal, TSF_LENGTH_TIME can be omitted from equation (1).

[0082] In operation 812, the IoT device 110 determines the data transmission time MACHD_LENGTH_TIME of the header according to the data length of the header and the data transmission speed of the first signal. For example, the data transmission rate is 1 Mbps, and the length of the MAC header is 24 bytes (for example, without the HT control field). MACHD_LENGTH_TIME is 192 μs (24*8 / 1000000).

[0083] In operation 814, the IoT device 110 determines a first target transmission time TBTT_BEACON_LOCAL associated with the first signal according to the start time of the local time synchronization value and the data transmission time of the header. For details on determining TBTT_BEACON_LOCAL, see formula (3) and its description.

[0084] In operation 816, the IoT device 110 determines / calculates the second target transmission time TBTT_BEACON based on the first target transmission time, the start time of the local time synchronization value, the AP's time synchronization value (TSF value), and the beacon interval. For details on determining TBTT_BEACON, see formula (4) and its description.

[0085] If the delay on the air interface is taken into account, that is, the beacon signal is not received at TBTT, the IoT device 110 can calculate the second target transmission time TBTT_BEACON according to TSF_AP, beacon interval and TSF_DELTA. The calculation details can be found in formula (5).

[0086] In operation 818 , the IoT device 110 prepares to receive the second signal at the second target transmission time.

[0087] It should be clear that the IoT device 110 uses the method 800 to prepare to receive the second signal at the determined / calculated second target transmission time (or target reception time if delay is taken into account), rather than controlling the AP to broadcast the second signal at the second target transmission time. Example 1. A method comprising: receiving a first signal from an access point (AP) of a network environment; Extracting a time synchronization value of the AP from the first signal; Acquire a local time synchronization value corresponding to the time synchronization value of the AP; determining whether a preset condition is satisfied, the preset condition indicating that reception of the first signal is to be interrupted; and In response to determining that the preset condition is satisfied, Get the time synchronization offset value; adjusting the local time synchronization value according to the time synchronization offset value and the time synchronization value of the AP; and Prepare to receive a second signal according to the adjusted local time synchronization value. 2. The method according to example 1, wherein the preset condition comprises: It is determined that no data packets are to be received. 3. The method of example 2, wherein the determining that no data packets are to be received comprises: identifying a traffic indication map (TIM) element from the first signal; Extracting a bitmap control value and a portion of a virtual bitmap value from the TIM element; and It is determined based on the bitmap control value and the partial virtual bitmap value that no data packets are to be received. 4. The method according to example 1, wherein the preset condition comprises: A determination is made that a third signal will preempt communication of the first signal. 5. The method of any one of Examples 1-4, wherein the time synchronization offset value is generated by the following operations, comprising: receiving at least one sample signal from the AP; determining at least one signal processing time, each signal processing time corresponding to one of the at least one sample signal; and The time synchronization offset value is determined according to the at least one signal processing time. 6. The method according to example 5, further comprising: receiving the second signal from the AP; determining a signal processing time corresponding to the second signal; and The time synchronization offset value is updated according to a signal processing time corresponding to the second signal. 7. The method of any one of Examples 5-6, wherein the at least one sample signal is received in its entirety. 8. The method according to any one of Examples 1-7, further comprising: In response to determining that the preset condition is satisfied, remaining data in the first signal is skipped. 9. The method according to any one of Examples 1-8, further comprising: In response to determining that the preset condition is not satisfied, receiving the first signal completely; Determining the time synchronization offset value; Adjusting a local time synchronization value according to the time synchronization value of the AP and the time synchronization offset value; and Prepare to receive the second signal according to the local time synchronization value and the time synchronization value of the AP. 10. The method of any of Examples 1-9, wherein preparing to receive the second signal according to the adjusted local time synchronization value comprises: determining a data length of a header in the first signal; acquiring a data transmission speed of the first signal; determining a first target transmission time associated with the first signal based on a data transmission speed of the first signal, the adjusted local time synchronization value, and a data length of a header in the first signal; determining a second target transmission time according to the first target transmission time, the adjusted local time synchronization value, and the time synchronization value of the AP; and Prepare to receive the second signal at the second target transmission time. 11. An Internet of Things (IoT) device, comprising: Processor; and A memory storing instructions, when the processor executes the instructions, configures the Internet of Things device to: receiving a first signal from an access point (AP) of a network environment; Extracting a time synchronization value of the AP from the first signal; Obtain a local time synchronization value corresponding to the AP's time synchronization value; determining whether a preset condition is satisfied, the preset condition indicating that reception of the first signal will be interrupted; and In response to determining that the preset condition is satisfied, Get the time synchronization offset value; adjusting the local time synchronization value based on the time synchronization offset value and the time synchronization value of the AP; and Prepare to receive a second signal according to the adjusted local time synchronization value. 12. The IoT device of Example 11, wherein the preset condition comprises: It is determined that no data packets are to be received. 13. The IoT device of example 12, wherein determining that no data packets are to be received comprises the instructions further configuring the IoT device to: identifying a traffic indication map (TIM) element from the first signal; Extracting a bitmap control value and a portion of a virtual bitmap value from the TIM element; and It is determined based on the bitmap control value and the partial virtual bitmap value that no data packets are to be received. 14. The IoT device of Example 11, wherein the preset condition comprises: A determination is made that a third signal will preempt communication of the first signal. 15. The IoT device of any one of Examples 11-14, wherein the time synchronization offset value is generated by: receiving at least one sample signal from the AP; determining at least one signal processing time, each signal processing time corresponding to one of the at least one sample signal; and The time synchronization offset value is determined according to the at least one signal processing time. 16. The IoT device of example 15, wherein the instructions further configure the IoT device to: receiving the second signal from the AP; determining a signal processing time corresponding to the second signal; and The time synchronization offset value is updated according to a signal processing time corresponding to the second signal. 17. An IoT device according to any of Examples 15-16, wherein the at least one sample signal is received in its entirety. 18. The IoT device of any of Examples 11-17, wherein the instructions further configure the IoT device to: In response to determining that the preset condition is satisfied, remaining data in the first signal is skipped. 19. The IoT device of any of Examples 11-18, wherein, in preparation for receiving the second signal according to the adjusted local time synchronization value, the instructions further configure the IoT device to: determining a data length of a header in the first signal; acquiring a data transmission speed of the first signal; determining a target transmission time associated with the first signal based on a data transmission speed of the first signal, the adjusted local time synchronization value, and a data length of a header in the first signal; determining a second target transmission time according to the first target transmission time, the adjusted local time synchronization value, and the time synchronization value of the AP; and Prepare to receive the second signal at the second target transmission time. 20. A non-transitory computer-readable storage medium comprising instructions which, when executed by a computer, cause the computer to: receiving a first signal from an access point (AP) of a network environment; Extracting a time synchronization value of the AP from the first signal; Obtaining a local time synchronization value corresponding to the time synchronization value of the AP; determining whether a preset condition is satisfied, the preset condition indicating that reception of the first signal is to be interrupted; and In response to determining that the preset condition is satisfied, Get the time synchronization offset value; adjusting the local time synchronization value based on the time synchronization offset value and the time synchronization value of the AP; and Prepare to receive a second signal according to the adjusted local time synchronization value. in conclusion

[0088] The present disclosure provides a system and method for predetermining the average hardware processing time when processing an entire beacon signal. When only a portion of the beacon signal is processed, the average hardware processing time is used to calibrate the local TSF value. The target beacon transmission time (TBTT) can also be calculated based on the calibrated local TSF value, and the IoT device can be ready to receive the next beacon signal based on the TBTT. The present disclosure potentially has at least the following advantages: 1. By processing only a portion of the beacon signal, the power consumption of the IoT device can be reduced. 2. When receiving a beacon signal, the IoT device can switch to a communication with a higher priority without losing time synchronization with the AP.

Claims

1. A method, characterized in that include: receiving a first signal from an access point (AP) of a network environment; Extracting a time synchronization value of the AP from the first signal; Acquire a local time synchronization value corresponding to the time synchronization value of the AP; determining whether a preset condition is satisfied, the preset condition indicating that reception of the first signal is to be interrupted; and In response to determining that the preset condition is satisfied, Get the time synchronization offset value; adjusting the local time synchronization value according to the time synchronization offset value and the time synchronization value of the AP; and Prepare to receive a second signal according to the adjusted local time synchronization value.

2. The method according to claim 1, characterized in that The preset conditions include: It is determined that no data packets are to be received.

3. The method according to claim 2, characterized in that The determining that no data packets are to be received comprises: identifying a traffic indication map (TIM) element from the first signal; Extracting a bitmap control field value and a partial virtual bitmap value from the TIM element; and It is determined based on the bitmap control field value and the partial virtual bitmap value that no data packets are to be received.

4. The method according to claim 1, characterized in that The preset conditions include: A determination is made that a third signal will preempt communication of the first signal.

5. The method according to claim 1, characterized in that The time synchronization offset value is generated by the following operations, including: receiving at least one sample signal from the AP; determining at least one signal processing time, each signal processing time corresponding to one of the at least one sample signal; and The time synchronization offset value is determined according to the at least one signal processing time.

6. The method according to claim 5, characterized in that Also includes: receiving the second signal from the AP; determining a signal processing time corresponding to the second signal; and The time synchronization offset value is updated according to a signal processing time corresponding to the second signal.

7. The method according to claim 5, characterized in that The at least one sample signal is received in its entirety.

8. The method according to claim 1, characterized in that: Also includes: In response to determining that the preset condition is satisfied, remaining data in the first signal is skipped.

9. The method according to claim 1, characterized in that: Also includes: In response to determining that the preset condition is not satisfied, receiving the first signal completely; Determining the time synchronization offset value; Adjusting a local time synchronization value according to the AP's time synchronization value and the time synchronization offset value; and Prepare to receive the second signal according to the local time synchronization value and the time synchronization value of the AP Number.

10. The method according to claim 1, characterized in that Preparing to receive the second signal according to the adjusted local time synchronization value includes: determining a data length of a header in the first signal; acquiring a data transmission speed of the first signal; determining a first target transmission time associated with the first signal based on a data transmission speed of the first signal, the adjusted local time synchronization value, and a data length of a header in the first signal; determining a second target transmission time according to the first target transmission time, the adjusted local time synchronization value, and the time synchronization value of the AP; and Prepare to receive the second signal at the second target transmission time.

11. An Internet of Things (IoT) device, characterized in that: include: processor; and A memory storing instructions, when the processor executes the instructions, configures the Internet of Things device to: receiving a first signal from an access point (AP) of a network environment; Extracting a time synchronization value of the AP from the first signal; Obtaining a local time synchronization value corresponding to the time synchronization value of the AP; determining whether a preset condition is satisfied, the preset condition indicating that reception of the first signal is to be interrupted; and In response to determining that the preset condition is satisfied, Get the time synchronization offset value; adjusting the local time synchronization value based on the time synchronization offset value and the time synchronization value of the AP; and Prepare to receive a second signal according to the adjusted local time synchronization value.

12. The Internet of Things device according to claim 11, characterized in that: The preset conditions include: It is determined that no data packets are to be received.

13. The Internet of Things device according to claim 12, characterized in that: The determining that no data packets are to be received includes the instructions further configuring the IoT device to: identifying a traffic indication map (TIM) element from the first signal; Extracting a bitmap control field value and a partial virtual bitmap value from the TIM element; and It is determined based on the bitmap control field value and the partial virtual bitmap value that no data packets are to be received.

14. The Internet of Things device according to claim 11, characterized in that: The preset conditions include: A determination is made that a third signal will preempt communication of the first signal.

15. The Internet of Things device according to claim 11, characterized in that: The time synchronization offset value is generated by the following operations, including: receiving at least one sample signal from the AP; determining at least one signal processing time, each signal processing time corresponding to one of the at least one sample signal; and The time synchronization offset value is determined according to the at least one signal processing time.

16. The Internet of Things device according to claim 15, characterized in that: The instructions further configure the IoT device to: receiving the second signal from the AP; determining a signal processing time corresponding to the second signal; and The time synchronization offset value is updated according to a signal processing time corresponding to the second signal.

17. The Internet of Things device according to claim 15, characterized in that: The at least one sample signal is received in its entirety.

18. The Internet of Things device according to claim 11, characterized in that: The instructions further configure the IoT device to: In response to determining that the preset condition is satisfied, remaining data in the first signal is skipped.

19. The Internet of Things device according to claim 11, characterized in that: In order to prepare to receive the second signal according to the adjusted local time synchronization value, the instructions further configure the IoT device to: determining a data length of a header in the first signal; acquiring a data transmission speed of the first signal; determining a target transmission time associated with the first signal based on a data transmission speed of the first signal, the adjusted local time synchronization value, and a data length of a header in the first signal; determining a second target transmission time according to the first target transmission time, the adjusted local time synchronization value, and the time synchronization value of the AP; and Prepare to receive the second signal at the second target transmission time.

20. A non-transitory computer-readable storage medium comprising instructions that, when executed by a computer, cause the computer to: receiving a first signal from an access point (AP) of a network environment; Extracting a time synchronization value of the AP from the first signal; Obtaining a local time synchronization value corresponding to the time synchronization value of the AP; determining whether a preset condition is satisfied, the preset condition indicating that reception of the first signal is to be interrupted; and In response to determining that the preset condition is satisfied, Get the time synchronization offset value; adjusting a local time synchronization value according to the time synchronization offset value and the time synchronization value of the AP; and Prepare to receive a second signal according to the adjusted local time synchronization value.

Images