Method for judging validity of BLE anchor point, electronic equipment, computer storage medium and program product

Abstract

The invention provides a method for judging validity of a BLE (Bluetooth Low Energy) anchor point, which is executed by electronic equipment and comprises the following steps: receiving a BLE link layer data packet; judging whether the access address in the data packet is a target access address of the current connection or not; in response to the fact that the access address is a target access address of the current connection, verifying the access address; and in response to the verification success, judging that the BLE anchor point corresponding to the data packet is valid. According to the scheme, the BLE anchor point judgment effectiveness is improved in an efficient and reliable mode, and the stability and reliability of BLE communication are improved.

Description

Technical Field

[0001] This disclosure relates to the field of communications, and more specifically to methods performed by electronic devices, electronic devices, and related computer-readable storage media and program products. Background Technology

[0002] Bluetooth Low Energy (BLE) is a short-range wireless communication technology widely used in devices requiring low power consumption and low cost, such as smart bracelets, watches, wireless headphones, medical monitoring devices, and smart home sensors. Compared to traditional Bluetooth, BLE features include, but are not limited to: 1) low power consumption, allowing devices to operate for months or even years on a single coin cell battery; 2) timed communication, enabling both parties to exchange data at fixed time intervals without maintaining a constant connection; and 3) high reliability, ensuring correct data transmission between electronic devices through BLE protocol layer design.

[0003] In existing BLE protocols, each BLE connection is assigned a unique Access Address (AA). The Access Address is typically a 32-bit identifier used to distinguish different connections. When the receiving end detects a packet with the target Access Address corresponding to its current connection, it can assume that the sending end has started transmitting data. Therefore, the time of receiving this packet can be used to determine the start time of the connection event between the two parties, i.e., the Achor Point, and the receiving end's local time can be updated. In other words, the Access Address is the basis for the receiving end to determine whether a BLE packet in the air belongs to it.

[0004] The inventors noted that if the receiver incorrectly identifies the interference signal or noise as its corresponding access address, i.e., an access address mismatch occurs, it will lead to incorrect anchor point judgment, which in turn will cause incorrect receiving window calculation, resulting in problems such as data packet loss or even connection disconnection, and will have a significant negative impact on the performance, responsiveness and power consumption of BLE devices.

[0005] Therefore, there is an urgent need in the existing technology for a solution that can determine the validity of anchor points in an efficient and reliable manner, so as to avoid anchor point judgment errors and a series of problems caused by incorrect access address matching. Summary of the Invention

[0006] The purpose of this disclosure is to provide a technical solution for determining the validity of BLE anchors in an efficient and reliable manner, which can at least solve one or more of the above-mentioned or other problems.

[0007] In one aspect of this disclosure, a method for determining the validity of a BLE anchor point is provided, executed by an electronic device, the method comprising: receiving a BLE link layer data packet; determining whether the access address in the data packet is the target access address of the current connection; verifying the access address in response to the access address being the target access address of the current connection; and determining that the BLE anchor point corresponding to the data packet is valid in response to the successful verification.

[0008] In some examples, the steps of verifying the access address include performing at least one of the following checks on the data packet: RSSI (Received Signal Strength Indicator) check; PDU (Protocol Data Unit) header check; and CRC (Cyclic Redundancy Check).

[0009] In some examples, the RSSI verification includes: obtaining the RSSI of the data packet; and determining that the access address verification has failed in response to the RSSI being lower than a threshold.

[0010] In some examples, the PDU header verification includes: parsing the data packet to obtain the PDU header; checking whether the PDU header has a valid data format; and determining that the access address verification has failed in response to the PDU header not having a valid data format.

[0011] In some examples, the method of this disclosure further includes: determining that the access address verification failed in response to the data packet failing the CRC check.

[0012] In some examples, the method of this disclosure further includes: in response to the verification failure, determining that the BLE anchor corresponding to the data packet is invalid, and continuing to use the previous valid anchor.

[0013] In some examples, in response to the verification failure, the receive window is maintained or expanded.

[0014] In some examples, the anchor is updated in response to a successful verification.

[0015] In some examples, in response to a successful verification, the receive window is maintained or reduced.

[0016] In some examples, the steps of verifying the access address include performing at least two of the following checks on the data packet: RSSI check; PDU header check; and CRC check.

[0017] In some examples, the steps of verifying the access address include performing RSSI verification, PDU header verification, and CRC verification on the data packet.

[0018] In another aspect of this disclosure, an electronic device is provided, comprising: at least one processor; and a memory storing computer-executable instructions, wherein the computer-executable instructions, when executed by the at least one processor, perform the method according to this disclosure.

[0019] In another aspect of this disclosure, a non-volatile computer-readable storage medium is provided storing computer-executable instructions, wherein the computer-executable instructions, when executed by at least one processor, perform the method according to this disclosure.

[0020] In another aspect of this disclosure, a computer program product is provided, including computer-executable instructions, wherein the computer-executable instructions are configured to, when executed by at least one processor, cause the at least one processor to perform the method according to this disclosure.

[0021] By way of example and not limitation, the advantages provided by this disclosure may include one or more of the following advantages and / or other advantages:

[0022] 1) Improve the existing technology of BLE that relies solely on the access address to determine the anchor point by proposing a multi-verification mechanism, which greatly improves the effectiveness of BLE anchor point determination;

[0023] 2) Effectively avoids errors in determining the receiving time point (anchor point) and incorrect narrowing of the receiving window due to misjudgment of the access address, thus solving the pain point problem of easy disconnection of BLE connections; and

[0024] 3) Provides a balance mechanism between power consumption and stability. Users can choose to prioritize low power consumption or high reliability based on the application scenario, and flexibly combine the multiple verification mechanisms disclosed herein.

[0025] It should be understood that the technical problems and advantages listed above are merely examples and not limitations of this disclosure. Furthermore, this disclosure is not limited to technical solutions that simultaneously solve all of the above-mentioned technical problems; the technical solutions of this disclosure can be implemented to solve one or more of the above-mentioned or other technical problems, and to provide one or more of the above-mentioned or other advantages. Attached Figure Description

[0026] Figure 1 A schematic diagram of a BLE packet structure according to the prior art is shown;

[0027] Figure 2 A schematic flowchart illustrating the process of determining the first anchor point in the first connection event according to existing technology;

[0028] Figure 3 A schematic flowchart illustrating the BLE window expansion process performed in a subsequent connection event according to existing technology;

[0029] Figure 4 A schematic timing diagram illustrating the BLE access address error matching process according to the prior art is shown.

[0030] Figure 5 A schematic flowchart illustrating a method for determining the validity of a BLE anchor point according to an embodiment of the present disclosure is shown.

[0031] Figure 6 A schematic flowchart illustrating a method for determining the validity of a BLE anchor point according to another embodiment of this disclosure; and

[0032] Figure 7 A schematic block diagram of an electronic device according to an embodiment of the present disclosure is shown. Detailed Implementation

[0033] The present disclosure will be described in detail below with reference to the accompanying drawings and specific embodiments. It should be understood that the embodiments shown in the drawings and described below are merely illustrative and are not intended to limit the present disclosure.

[0034] In the context of this disclosure, unless otherwise specifically stated, ordinal numbers such as "first," "second," etc., are used only to distinguish different elements and not to specify their order.

[0035] The inventors discovered that Bluetooth Low Energy (BLE) devices cause errors in receiving window calculation due to incorrect matching of access addresses (e.g., data packets from noise or other devices), resulting in data packet loss or even connection loss.

[0036] Therefore, a core issue facing BLE in practical use is how to avoid incorrectly matched access addresses leading to incorrect receive window calculations, which could result in packet loss or even connection termination.

[0037] Figure 1 A schematic diagram of a BLE packet structure according to the prior art is shown. Figure 1 The BLE packet structure 100 shown includes a preamble 102, access address 104, PDU header 106, PDU payload 108, Message Integrity Check (MIC) 110, and Cyclic Redundancy Check (CRC) 112. It should be understood that... Figure 1The BLE packet structure 100 shown is an encrypted packet including the MIC field 110, but the scheme of this disclosure can also be applied to non-encrypted packets that do not include the MIC field without departing from the scope of this disclosure. As a non-limiting example, the access address 104 is typically a 32-bit identifier that can be used to distinguish different BLE connections. It should be understood that... Figure 1 The BLE packet structure shown is for illustrative purposes only and is not a limitation. The principles of this disclosure can be applied to different packet structures of existing or future versions of the BLE protocol or other similar protocols.

[0038] In a BLE connection, two devices need to communicate periodically. These devices include a central device (also called the master device) and a peripheral device (also called a slave device). As a non-limiting example, a BLE connection between a master device (mobile phone) and a slave device is an example. During communication, the start time of each connection event (CE) is called the anchor point. The anchor point can be understood as the point at which the master and slave devices exchange information at agreed-upon connection intervals; the anchor point is the time when each connection event begins exchanging information. In this disclosure, the terms "anchor point" and "BLE anchor point" are used interchangeably.

[0039] As a time reference for the occurrence of connection events, the receiving slave device needs to know the precise anchor point of each connection event in order to communicate synchronously with the master device. Specifically, after a successful BLE connection, data transmission between the master and slave devices occurs in the form of periodic connection events. In each connection event, the master device first sends a data packet, and the slave device updates its anchor point and responds upon receiving it. Each connection event begins at an anchor point, which defines the moment when the master device begins sending data within a connection event and provides a time reference for the entire connection event. The slave device must open its receive window at the latest at the anchor point to listen for data sent by the master device.

[0040] Ideally, the receiving end only needs to turn on its receiver at the anchor point to receive data from the other party as agreed in the protocol. However, in reality, the clocks (crystal oscillators) of the master and slave devices are not perfect and may have slight deviations. Over time, these deviations accumulate, leading to misalignment with the anchor point.

[0041] Therefore, to prevent missed data, the receiving end typically opens a receive window (RXWindow) before and after the anchor point. If the time interval between two connection events is short, the receive window can be set narrower; however, if the time interval is long, the receive window needs to be expanded into a wider window. This mechanism is called window widening. See the following reference... Figure 2 and Figure 3 This schematically illustrates the process by which the receiver determines the anchor point and the receiving window according to the BLE specification.

[0042] Figure 2 A schematic flowchart of process 200 for determining the first anchor point in the first connection event according to existing technology is shown, which is performed by the slave device. In step 202, the slave device receives a connection request (CONNECT_REQ) packet sent by the master device. The CONNECT_REQ packet contains connection parameters that determine when the first connection event occurs, including but not limited to the target access address of the current connection, the connection interval (ConnInterval), the transmission window offset (TransmitWindowOffset), and the transmission window size (TransmitWindowSize).

[0043] In step 204, the connection parameters in the CONNECT_REQ packet are parsed from the device.

[0044] In step 206, the slave device calculates the fixed receive window. For example, by parsing the obtained connection parameters, the slave device knows that the master device will send the data packet for the first connection event within the time window of [1.25 ms + TransmitWindowOffset, 1.25 ms + TransmitWindowOffset + TransmitWindowSize] after the end of the CONNECT_REQ packet. It should be understood that the start time of this time window can be called the "theoretical anchor point" at which the first connection event should occur.

[0045] In step 208, the slave device listens for data packets from the master device within the calculated fixed receive window.

[0046] In step 210, the device determines whether a data packet with the access address of the current connection target access address has been received within the fixed receiving window.

[0047] If a data packet that meets the conditions is received within the fixed receiving window, the slave device determines the actual arrival time of the data packet as the first anchor point in step 212.

[0048] In step 214, the slave device performs processing of the current connection event, such as exchanging data with the master device.

[0049] If no data packet meeting the conditions is received within the fixed receive window, the slave device plans to resynchronize at the theoretical anchor point of the next connection event in step 216. That is, steps 208 to 210 are repeated, opening a receive window at the theoretical anchor point of the next connection event to listen for data packets from the master device and determine the access address. It should be understood that the theoretical anchor point of the next connection event can be obtained by adding the connection interval to the theoretical anchor point of the first connection event.

[0050] Then, in step 218, the device waits for the next connection event.

[0051] It should be understood that in the prior art, as long as the access address of the master device data packet received within the fixed receiving window is successfully matched, the slave device will determine the moment when the data packet is successfully received as the anchor point of the first connection event, and use this anchor point as the basis for calculating the time of all subsequent connection events.

[0052] Once the first anchor point is determined, the anchor points for all subsequent connection events can theoretically be calculated from the device's perspective: Subsequent anchor point = Previous anchor point + Connection interval * Number of connection intervals elapsed, where the connection interval is a parameter set by the master device in the CONNECT_REQ packet. However, for subsequent connection events, due to factors such as master device clock drift, the error in anchor point calculation will gradually accumulate, eventually leading to incorrect listening timing by the slave device and connection interruption. Therefore, in each connection event, as long as the slave device successfully receives a data packet from the master device (i.e., a data packet with the access address of the target access address of the current connection), the slave device will update and calibrate its anchor point using the actual arrival time of this packet. To cope with clock drift, the slave device can calculate a window expansion amount as needed, thereby opening the receive window in advance and extending the listening time to ensure that data packets from the master device can be captured even with clock deviations. The calculation of the expansion window is usually related to factors such as the clock accuracy of both parties and the connection interval.

[0053] Figure 3 A schematic flowchart is shown of a BLE window extension process 300 performed in a subsequent connection event according to the prior art, which is executed by the slave device.

[0054] In step 302, the slave device calculates the theoretical anchor point of the current event based on the previous anchor point and the connection interval. For example, the slave device can deduce the theoretical anchor point of the current connection event based on the anchor point of the previous successful communication and the connection interval, that is, the theoretical anchor point of the current event = the previous anchor point + the connection interval * the number of connection intervals passed.

[0055] In step 304, the window expansion is calculated. To compensate for clock drift, the slave device can calculate the window widening. Generally, the longer the time since the previous anchor point, the greater the accumulated potential error, and the larger the required window widening.

[0056] In step 306, listen for master device data packets within the calculated extended window.

[0057] In step 308, the device determines whether it has received a data packet whose access address is the target access address of the current connection.

[0058] If a data packet with the access address of the current connection is received, the slave device updates the theoretical anchor point of the current event with the actual arrival time of the data packet in step 310.

[0059] In step 312, the slave device performs processing of the current connection event, such as exchanging data with the master device.

[0060] If no data packet meeting the conditions is received within the fixed receive window, the slave device plans to resynchronize at the theoretical anchor point of the next connection event in step 314. That is, steps 302 to 308 above are repeated, and an extended receive window is opened at the theoretical anchor point of the next connection event to listen for data packets from the master device and determine the access address.

[0061] Then, in step 316, the device waits for the next connection event.

[0062] For more details on window widening performed under the BLE protocol, please refer to BLE Spec BLUETOOTH CORESPECIFICATION Version 6.1 | Vol 6, Part B, 4.2.4 Window widening, which is incorporated herein by reference in its entirety.

[0063] from Figure 2 The process of determining the first anchor point in the first connection event is shown below. Figure 3 As shown in the BLE window expansion process above, the anchor time of the current connection event provides a time reference for the window expansion operation, which is crucial for executing the correct window expansion operation. However, as... Figure 2 Steps 210 and 212 in the process and Figure 3 As shown in steps 308 and 310, in the prior art, when a data packet with an access address that is the current connection target address is detected, the actual arrival time of the data packet is directly used as the first anchor point, or the actual arrival time of the data packet is used to directly update the theoretical anchor point of the current event.

[0064] The inventors discovered that incorrect matching of access addresses may lead to misjudgment of the anchor time of the current connection event, which in turn causes a series of problems in window expansion operations.

[0065] In practical applications, the receiver may mistakenly identify a certain interference signal or noise as its own access address AA. This situation is called access address mismatch.

[0066] False matches primarily originate from two sources. One is interference packets, such as packets from other BLE devices in the air, where a bit sequence at a certain position happens to match the device's access address. The other is noise, such as random noise in the radio environment that accidentally contains a bit sequence matching the device's access address, which could mislead the receiver into believing it has detected the correct target access address currently being connected to.

[0067] The inventors noted that such access address mismatches would cause several problems. First, once a mismatch occurs, the receiver will treat the incorrect time as the anchor point. Second, the receiver system will assume it has received a packet, thus believing it has clocked with the master device and narrowing its receive window. As a result, when the correct BLE packet sent by the master device arrives, it will be missed because the receive window is too small. More seriously, if the receiver misses multiple packets in succession, it will eventually lead to a connection loss.

[0068] Figure 4 An exemplary timing diagram 400 is shown for a BLE access address error matching process according to the prior art. Figure 4 In the process, at time t1, the central device 402 sends a normal packet with a normal access address AA to the peripheral device 404. Based on this normal packet, the peripheral device 404 completes correct synchronization with the central device at time t6. At time t2, the peripheral device 404 receives an interference packet with an incorrect access address AA. As a non-limiting example, as mentioned above, the source of the interference packet could be, for example, other BLE devices or noise in the air. However, since the access address AA carried by the interference packet is the same as the access address AA carried by the normal packet, according to the prior art, the peripheral device 404 cannot determine that the source of the interference packet is problematic, and will mistakenly believe that the interference packet comes from the central device 402.

[0069] Therefore, at time 408, peripheral device 404 misjudged the situation, incorrectly updating the anchor point based on the reception time of the interference packet and correspondingly shrinking the RX window. At time t3, when central device 402 sent the next real packet to peripheral device 404, an RX window error occurred at peripheral device 404, causing it to miss the real packet due to the shrunken RX window. Furthermore, after missing multiple real packets, a connection loss occurred between central device 402 and peripheral device 404 at time t4.

[0070] Accordingly, the inventors have creatively proposed the technical solution of this disclosure in order to determine the validity of anchor points in an efficient and reliable manner, and to solve one or more of the above-mentioned or other problems.

[0071] Figure 5 A schematic flowchart of a method 500 for determining the validity of a BLE anchor point according to an embodiment of the present disclosure is shown. The method 500 is performed by an electronic device. The method 500 includes: in step 502, receiving a BLE link layer data packet; in step 504, determining whether the access address in the data packet is the target access address of the current connection; in step 506, in response to the access address being the target access address, verifying the access address; and in step 508, in response to the successful verification, determining that the BLE anchor point corresponding to the data packet is valid.

[0072] Unlike the BLE protocol specifications and conventional practices in Bluetooth communication, the solution disclosed herein, upon receiving a BLE packet and determining that the access address carried in the packet is the correct target access address—that is, the access address corresponding to the current BLE connection of the device—does not assume the packet originates from the corresponding master device. Instead, it further verifies the access address carried in the packet. This achieves a more reliable method for determining the validity of the BLE anchor point.

[0073] In some embodiments, the step of verifying the access address includes performing at least one of the following verifications on the data packet: RSSI verification, PDU header verification, and CRC verification. In a further embodiment, the data packet may be subjected to double verification including two of the following verification methods: RSSI verification, PDU header verification, and CRC verification, or optionally triple verification including all three.

[0074] In a further embodiment, the RSSI verification includes: obtaining the RSSI of the data packet; and determining that the access address verification has failed in response to the RSSI being lower than a threshold.

[0075] In a further embodiment, the PDU header verification includes: parsing the data packet to obtain the PDU header; checking whether the PDU header has a valid data format; and determining that the access address verification fails in response to the PDU header not having a valid data format.

[0076] In a further embodiment, the method further includes determining that the access address verification failed in response to the data packet failing the CRC check.

[0077] In some embodiments, in response to the verification failure, it is determined that the BLE anchor point corresponding to the data packet is invalid, and the previous valid anchor point is used.

[0078] In some embodiments, the receive window may be maintained or reduced in response to a successful verification. For example, if the device received a valid anchor point in the previous connection interval, the receive window is maintained; otherwise, the receive window is reduced.

[0079] In some embodiments, in response to the verification failure, the receive window is maintained or expanded.

[0080] In some embodiments, upon receiving the target access address, the anchor point corresponding to the packet with the target access address is not immediately identified as a valid anchor point, but the following multiple verifications are performed.

[0081] 1) RSSI verification. For example, if the signal strength received this time is much smaller than that of the previous normal packet (or below the set threshold), it can be considered a false match caused by noise, and the anchor point will not be updated.

[0082] 2) PDU header verification. For example, according to the BLE protocol, the access address is followed by the PDU header (e.g., 2 bytes). Its content can be checked for validity (e.g., whether the data format is valid). If it is found to be inconsistent with the protocol specifications, it can be determined as an incorrect match.

[0083] 3) CRC check. For example, a CRC check (cyclic redundancy check) can be performed on the complete data packet according to the BLE protocol. In some embodiments, the CRC check specified by the BLE protocol is reused, and only packets that pass the CRC check are considered to be usable for determining a valid anchor point.

[0084] In this way, the method disclosed herein greatly reduces the probability of false matching through triple verification and significantly improves the effectiveness of anchor point determination through enhanced access address verification.

[0085] After the triple verification disclosed herein, the slave device's response mechanism is to adjust the window size. However, in existing technologies, CRC verification is only used to determine whether the received packet is correct, and then decides whether to send an ACK or perform other operations. In the existing mechanism, the slave device only uses AA to determine and adjust the receive window size. This solution adjusts the window size through CRC verification, and the adjustment mechanism for this window size is different.

[0086] It should be understood that, based on this disclosure, those skilled in the art can combine or apply one or more of the above three verification methods in different ways without departing from the scope of this disclosure.

[0087] Figure 6A schematic flowchart of a method 600 for determining the validity of a BLE anchor point according to another embodiment of this disclosure is shown. Method 600 is executed by a receiving end. In step 602, a receiving window is started.

[0088] In step 604, it is determined whether the target access address of the current connection has been detected. If no target access address is detected, the process returns to step 602 and continues to listen for incoming BLE packets.

[0089] If so, proceed to step 606 to obtain the Received Signal Strength Indicator (RSSI) value of the received packet. In step 608, determine whether the RSSI value is lower than a preset threshold or significantly lower than the RSSI value of the last correctly received packet. It should be understood that the threshold or the criterion for determining "significantly lower" can be selected or set by those skilled in the art based on the actual application environment and requirements, without departing from the scope of this disclosure. If the determination at 608 is yes, then in step 610, determine that the access address verification has failed and discard the access address.

[0090] If the determination at step 608 is negative, proceed to step 612 to determine if the PDU header is valid. It should be understood that, as a non-limiting example, depending on the scenario, the validity of the PDU header can be determined based on the BLE protocol, a proprietary protocol, or other protocols, without departing from the scope of this disclosure. If the determination at 612 is positive, proceed to step 614 to determine if the CRC checksum of the received packet is correct. If positive, proceed to step 616 to determine the time of the received packet as a valid anchor point and update the receive window. If the determination at 612 or 614 is negative, proceed to step 610 to determine that the access address verification has failed and discard the access address AA.

[0091] As a non-limiting example, the solution disclosed herein can solve the problem of incorrect access address matching in different scenarios.

[0092] In an example scenario of noise misjudgment, the slave device opens its receive window at the anchor point and detects an access address. The RSSI value is -106 dBm, while the previous normal packet was -60 dBm. According to the scheme of this disclosure, due to the excessively large RSSI difference, the slave device system can classify it as noise, not update the anchor point, and expand the receive window to increase the reception success rate.

[0093] In an example scenario of misinterpreting data packets from other devices, an access address is detected from a device, and its RSSI is normal. However, upon inspection of the PDU header, its format is found to be inconsistent with expectations. Therefore, according to the scheme of this disclosure, it is determined to be an invalid anchor point, the previous anchor point is reused, and the receive window is expanded to increase the reception success rate.

[0094] In an example scenario where CRC check fails, the device detects the target access address and the PDU header format is correct, but the CRC check fails. According to the solution disclosed in this disclosure, this is determined to be an invalid anchor point, the anchor point is not updated, erroneous synchronization is avoided, and the receiving window is expanded to increase the reception success rate.

[0095] In summary, the solution disclosed herein avoids various problems such as BLE connection drops, improving the stability and reliability of BLE communication. Users can flexibly choose whether to enable verification or different verification methods based on their preference for low power consumption or high stability in their application scenarios.

[0096] As a non-limiting example, the solutions disclosed herein are applicable to improving the stability and reliability of BLE in various technical scenarios, including but not limited to smartwatches / wristbands, where long-term stable connections are required to avoid poor user experience due to misjudgments; medical devices, where reliability requirements are extremely high and frequent disconnections are not allowed; in-vehicle Bluetooth, where there are many interference signals inside the vehicle, and the solutions disclosed herein can significantly improve BLE stability; and wireless headphones, where stable BLE communication is still required in noisy environments.

[0097] In one aspect of this disclosure, an electronic device is provided, comprising: at least one processor; and a memory storing computer-executable instructions, wherein the computer-executable instructions, when executed by the at least one processor, perform the method according to this disclosure.

[0098] As a non-restrictive example, Figure 7 A schematic block diagram of an electronic device 700 according to one embodiment of the present disclosure is shown. By way of example and not limitation, the electronic device 700 may include one or more processors 702, volatile memory 704, such as random access memory (RAM), non-volatile memory (NVM) 706, input / output devices 708, and a bus 710. It should be understood that... Figure 7The electronic components shown can be integrated into one or more chips or modules including a microcontroller unit (MCU), a system-on-a-chip (SoC), etc. Volatile memory 704 and / or non-volatile memory 706 may store computer instructions that, when executed by the one or more processors, cause the one or more processors to perform any of the methods according to this disclosure.

[0099] In another aspect of this disclosure, a non-volatile computer-readable storage medium is provided storing computer-executable instructions, wherein the computer-executable instructions, when executed by at least one processor, perform the method according to this disclosure.

[0100] In another aspect of this disclosure, a computer program product is provided, including computer-executable instructions, wherein the computer-executable instructions are configured to, when executed by at least one processor, cause the at least one processor to perform the method according to this disclosure.

[0101] While various embodiments of various aspects of this disclosure have been described for the purposes of this disclosure, they should not be construed as limiting the teachings of this disclosure to these embodiments. Features disclosed in one specific embodiment are not limited to that embodiment, but can be combined with features disclosed in different embodiments. For example, one or more features and / or functions of a product according to this disclosure described in one embodiment can also be applied individually, in combination, or holistically to another embodiment. Furthermore, various embodiments of various aspects of this disclosure can be implemented independently or in different combinations. Those skilled in the art will understand that many more possible alternative implementations and variations exist, and various changes and modifications can be made to the above structure without departing from the scope of protection of this disclosure.

Claims

1. A method for determining the validity of a BLE anchor point, executed by an electronic device, the method comprising: Receive BLE link layer data packets; Determine whether the access address in the data packet is the target access address of the current connection; In response to the fact that the access address is the target access address of the current connection, the access address is verified; as well as In response to the successful verification, the BLE anchor point corresponding to the data packet is determined to be valid.

2. The method according to claim 1, characterized in that, The step of verifying the access address includes performing at least one of the following verifications on the data packet: RSSI verification; PDU header verification; and CRC check.

3. The method according to claim 2, characterized in that, The RSSI verification includes: Obtain the RSSI of the data packet; and If the RSSI is lower than the threshold, the access address verification is determined to have failed.

4. The method according to claim 2, characterized in that, The PDU header verification includes: Parse the data packet to obtain the PDU header; Check whether the PDU header has a valid data format; and If the PDU header does not have a valid data format, the access address verification is deemed to have failed.

5. The method according to claim 2, characterized in that, Also includes: In response to the data packet failing the CRC check, it is determined that the access address check has failed.

6. The method according to claim 1, further comprising: In response to the verification failure, the BLE anchor point corresponding to the data packet is determined to be invalid, and the previous valid anchor point is used.

7. The method according to claim 1, further comprising: In response to the verification failure, maintain the receiving window or expand the receiving window.

8. The method according to claim 1, further comprising: In response to the successful verification, the anchor point is updated.

9. The method according to claim 1, further comprising: In response to a successful verification, either maintain the receiving window or reduce the receiving window.

10. The method according to claim 2, characterized in that, The steps for verifying the access address include performing at least two of the following verifications on the data packet: RSSI verification; PDU header verification; and CRC check.

11. The method according to claim 10, characterized in that, The steps for verifying the access address include performing RSSI verification, PDU header verification, and CRC verification on the data packet.

12. An electronic device, comprising: At least one processor; as well as A memory storing computer-executable instructions, wherein the computer-executable instructions, when executed by the at least one processor, perform the method according to any one of claims 1 to 11.

13. A non-volatile computer-readable storage medium storing computer-executable instructions, wherein the computer-executable instructions, when executed by at least one processor, perform the method according to any one of claims 1 to 11.

14. A computer program product comprising computer-executable instructions, wherein the computer-executable instructions are configured, when executed by at least one processor, to cause the at least one processor to perform the method according to any one of claims 1 to 11.

Images