Bluetooth broadcast response method and electronic equipment

Abstract

The invention discloses a Bluetooth broadcast response method and electronic equipment. The method comprises the following steps: performing access address verification on a received wireless frame; and if the access address passes the verification, sending a scanning response in a response window specified by a protocol. According to the technical scheme, direct response is allowed in a specific scene with a correct access address, so that a rigid rule that response can be realized only by strictly passing multi-layer mandatory check (such as CRC check and PDU type check) in a traditional Bluetooth protocol is broken, the average time delay of equipment discovery is greatly shortened, and the equipment discovery efficiency is improved. Therefore, the success rate and the real-time performance of the first response in the high-concurrency scanning environment are remarkably improved, and the backoff retry behavior and the channel congestion of the scanning equipment are effectively reduced.

Description

Technical Field

[0001] This invention relates to the field of Bluetooth technology, and more particularly to a Bluetooth broadcast response method and electronic device. Background Technology

[0002] In the existing Bluetooth Low Energy (BLE) standard protocol, the broadcast device's response to a scan request depends entirely on the message validity check result. Its response logic is fixed and rigid: it only responds if the access address, cyclic redundancy check, and protocol data unit type all pass; otherwise, it must discard the message. This either-or response mechanism not only lacks flexibility but also directly leads to performance bottlenecks such as prolonged device discovery time, low first-time success rate, and channel congestion in high-concurrency scanning scenarios. Summary of the Invention

[0003] This invention provides a Bluetooth broadcast response method and an electronic device to solve the problem that existing Bluetooth broadcast response mechanisms cannot respond flexibly and intelligently according to actual application needs due to their reliance on fixed verification rules.

[0004] According to one aspect of the present invention, a Bluetooth broadcast response method is provided, the method comprising:

[0005] Perform access address verification on the received wireless frames;

[0006] If the access address verification passes, a scan response will be sent within the response window specified in the protocol.

[0007] According to another aspect of the present invention, a Bluetooth broadcast response device is provided, the device comprising:

[0008] The access address verification module is used to verify the access address of received wireless frames.

[0009] The response sending module is used to send a scan response within the response window specified in the protocol if the access address verification passes.

[0010] According to another aspect of the present invention, an electronic device is provided, the electronic device comprising:

[0011] At least one processor; and

[0012] A memory communicatively connected to the at least one processor; wherein,

[0013] The memory stores a computer program that can be executed by the at least one processor, the computer program being executed by the at least one processor to enable the at least one processor to perform the Bluetooth broadcast response method according to any embodiment of the present invention.

[0014] According to another aspect of the present invention, a computer-readable storage medium is provided, the computer-readable storage medium storing computer instructions for causing a processor to execute and implement the Bluetooth broadcast response method according to any embodiment of the present invention.

[0015] According to another aspect of the present invention, a computer program product is provided, the computer program product comprising a computer program that, when executed by a processor, implements the Bluetooth broadcast response method according to any embodiment of the present invention.

[0016] The technical solution of this invention verifies the access address of the received wireless frame; if the access address verification passes, a scan response is sent within the response window specified in the protocol. This technical solution breaks the rigid rule in traditional Bluetooth protocols that requires strict multi-layered mandatory verification (such as CRC check, PDU type check, etc.) before a response can be made by allowing direct response in specific scenarios with a correct access address. This significantly shortens the average latency of device discovery, thereby significantly improving the first-response success rate and real-time performance in high-concurrency scanning environments, and effectively reducing the backoff retry behavior of scanning devices and channel congestion.

[0017] It should be understood that the description in this section is not intended to identify key or essential features of the embodiments of the present invention, nor is it intended to limit the scope of the invention. Other features of the invention will become readily apparent from the following description. Attached Figure Description

[0018] To more clearly illustrate the technical solutions in the embodiments of the present invention, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0019] Figure 1 This is a flowchart of a Bluetooth broadcast response method provided in Embodiment 1 of the present invention;

[0020] Figure 2 This is a schematic diagram of the structure of a Bluetooth broadcast response device according to Embodiment 2 of the present invention;

[0021] Figure 3 This is a schematic diagram of the structure of an electronic device that implements the Bluetooth broadcast response method of this invention. Detailed Implementation

[0022] To enable those skilled in the art to better understand the present invention, the technical solutions of the present invention will be clearly and completely described below with reference to the accompanying drawings of the embodiments of the present invention. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of the present invention.

[0023] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this invention are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of the invention described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0024] Example 1

[0025] Figure 1 This is a flowchart of a Bluetooth broadcast response method provided in Embodiment 1 of the present invention. This embodiment is applicable to BLE active scanning scenarios with multiple scanning devices operating concurrently. When a broadcast device receives a wireless frame with the correct access address, it can trigger a response. This method can be executed by a Bluetooth broadcast response device, which can be implemented in hardware and / or software and can be configured in an electronic device. Figure 1 As shown in the figure, the Bluetooth broadcast response method provided in this embodiment includes the following steps:

[0026] S110. Perform access address verification on the received wireless frames.

[0027] Among them, a wireless frame can refer to a structured data frame received by the radio frequency module of the broadcasting device and transmitted through the broadcast channel. It is the basic transmission unit of BLE communication. Its structure conforms to the Bluetooth protocol specification and usually includes four parts: a preamble (1 byte, used for frequency synchronization and automatic gain control), an access address (4 bytes, the broadcast channel is fixed at 0x8E89BED6, used for frame identification and filtering), a PDU header, a PDU payload, and a Cyclic Redundancy Check (CRC) field (3 bytes, used for integrity verification).

[0028] Access Address (AA) verification can refer to the process by which a broadcasting device verifies the legality of the access address field in a received radio frame. This is used to determine whether the radio frame belongs to the target device that the broadcasting device needs to process, such as verifying whether the AA of the radio frame matches a preset address (0x8E89BED6).

[0029] In this embodiment of the invention, the radio frequency front end of the broadcasting device can receive wireless frame signals on a preset broadcast channel and obtain a digital bit stream carrying actual data through signal demodulation; then, in the demodulated bit stream, the AA field immediately following the preamble is located and extracted; the AA is compared with the preset target AA (e.g., 0x8E89BED6) for consistency; if the AA does not match, the wireless frame is directly discarded to save system resources and power consumption.

[0030] S120. If the access address verification passes, a scan response is sent within the response window specified in the protocol.

[0031] The response window can refer to the time window specified in the Bluetooth protocol during which a broadcast device must send a response after receiving an uplink wireless frame.

[0032] In this embodiment of the invention, when the broadcasting device determines that the received wireless frame AA verification is successful, it can attempt to respond directly, that is, it can encapsulate the necessary device information, service data, etc. into a scanning response, and send the scanning response out through the radio frequency module within the response window specified in the protocol.

[0033] This technical solution only needs to verify that the access address of the received wireless frame is correct before it can respond directly. It does not need to consider whether the CRC check result, PDU type, etc. are correct. It breaks through the technical limitations of replying to scan responses in traditional Bluetooth protocols, greatly shortens the average latency of device discovery, and thus significantly improves the first response success rate and real-time performance in high-concurrency scanning environments, as well as effectively reduces the backoff retry behavior of scanning devices and channel congestion.

[0034] Furthermore, based on the above embodiments of the invention, sending a scan response within the response window specified in the protocol includes:

[0035] The corresponding target response decision result is determined based on the protocol data unit information in the radio frame;

[0036] If the target response decision is to allow the response, then a scan response is sent within the response window.

[0037] The Protocol Data Unit (PDU) information refers to the data packet payload portion defined in the Bluetooth protocol, which includes information such as PDU type, payload length, sender address, and destination address (i.e., receiver address).

[0038] The target response decision result can refer to the final instruction generated after judging based on preset rules or strategies according to PDU information. It can include two results: allow response or deny response, which are used to control whether or not to send a scan response.

[0039] In this embodiment of the invention, for a wireless frame that has passed the AA verification, it can be further parsed to extract key PDU information such as PDU type, payload length, sender address, and destination address; then, it is analyzed and judged according to pre-configured rules or policies to generate a target response decision result on whether to respond to the currently received wireless frame.

[0040] Furthermore, based on the above embodiments of the invention, the protocol data unit information includes the protocol data unit type and payload length. Determining the corresponding target response decision result based on the protocol data unit information in the radio frame includes:

[0041] Determine whether the protocol data unit type or payload length is consistent with the corresponding preset field value;

[0042] If so, then the target response decision result is determined to be an acceptable response;

[0043] If not, the target response decision is determined to be a rejection.

[0044] The Protocol Data Unit Type (PDU Type) can refer to the core control field in the PDU header, which is used to identify the PDU function type. The PDU Type includes at least types such as Scan Request (SCAN_REQ) and Scan Response (SCAN_RSP).

[0045] Payload length can refer to the number of bytes in the PDU header used to identify the payload portion of the PDU. For example, the payload length corresponding to SCAN_REQ is fixed at 12 bytes, including a 6-byte scanning device address ScanA and a 6-byte broadcast device address AdvA. It is an important feature to help verify the PDU type.

[0046] The preset field values ​​can refer to pre-configured feature field standard values, including the PDU type value corresponding to SCAN_REQ (such as 0x03) and the 12-byte payload length standard value (including the 6-byte scanning device address ScanA and the 6-byte broadcast device address AdvA), used as a comparison benchmark. It should be noted that the technical solutions of this embodiment are also applicable to extended broadcast scenarios in BLE 5.0 and higher versions. For example, the preset field values ​​can also include the PDU type value corresponding to AUX_SCAN_REQ in extended broadcast, and its response decision principle is similar to that of the traditional broadcast SCAN_REQ described in this embodiment. For the sake of brevity, this embodiment uses traditional broadcast (Legacy ADV) in the BLE 4.2 specification as an example for illustration, but this should not be construed as any limitation on the scope of protection of this patent.

[0047] In this embodiment of the invention, for a wireless frame that has passed the AA verification, the extracted PDU type and payload length can be compared with the corresponding preset field values. If one of the comparison results is consistent, the target response decision result is determined to be an allowed response; if both comparison results are inconsistent, the target response decision result is determined to be a rejected response.

[0048] Furthermore, based on the above embodiments of the invention, the protocol data unit information includes the protocol data unit type and payload length. Determining the corresponding target response decision result based on the protocol data unit information in the radio frame includes:

[0049] Determine whether the protocol data unit type and payload length are consistent with the corresponding preset field values;

[0050] If so, then the target response decision result is determined to be an acceptable response;

[0051] If not, the target response decision is determined to be a rejection.

[0052] In this embodiment of the invention, for a wireless frame that has passed the AA verification, the extracted PDU type and payload length can be compared with the corresponding preset field values. If both comparison results are consistent, the target response decision result is determined to be an allowed response; if any one of the comparison results is inconsistent, or both comparison results are inconsistent, the target response decision result is determined to be a rejected response.

[0053] The embodiments of the present invention implement a dual feature verification mechanism (PDU type + payload length), which significantly improves the reliability of the system while ensuring response efficiency. It is particularly suitable for medium-density device communication scenarios with high real-time requirements and security considerations.

[0054] Furthermore, based on the above embodiments of the invention, the protocol data unit information also includes a sender address and a target address. Determining the corresponding target response decision result based on the protocol data unit information in the radio frame includes:

[0055] If the protocol data unit type or payload length matches the corresponding preset field value, then verify the sender address and the destination address;

[0056] If the sender address verification and / or the destination address verification pass, the destination response decision is determined to be an allowed response; otherwise, the destination response decision is determined to be a rejected response.

[0057] The sender address can refer to the identification address of the scanning device that sends the current wireless frame. It can be a fixed public address or a dynamically changing Resolvable Random Private Address (RPA).

[0058] The target address can refer to the Bluetooth device address in the wireless frame used to specify the expected receiving device for that frame. In the scan request (SCAN_REQ), it specifically refers to the AdvA field, which is the address of the broadcasting device itself.

[0059] In this embodiment of the invention, for a wireless frame that has passed AA verification, if either the extracted PDU type or the payload length matches the corresponding preset field value, then the extracted sender address and target address are further verified for identity security to verify whether the above scanning request comes from a legitimate or trusted device, and whether the scanning request is indeed directed to this device and intends to communicate with this device; if the sender address verification and / or target address verification pass, then the target response decision result is determined to be an allowed response, otherwise the target response decision result is determined to be a rejected response.

[0060] Furthermore, based on the above embodiments of the invention, the protocol data unit information also includes a sender address and a target address. Determining the corresponding target response decision result based on the protocol data unit information in the radio frame includes:

[0061] If the protocol data unit type and payload length are consistent with the corresponding preset field values, then verify the sender address and the destination address;

[0062] If the sender address verification and / or the destination address verification pass, the destination response decision is determined to be an allowed response; otherwise, the destination response decision is determined to be a rejected response.

[0063] In this embodiment of the invention, for a wireless frame that passes AA verification, if the extracted PDU type and payload length all match the corresponding preset field values, then the extracted sender address and target address are further verified for identity security to verify whether the above scanning request comes from a legitimate or trusted device, and whether the scanning request is indeed directed to this device and intends to communicate with this device; if the sender address verification and / or target address verification pass, then the target response decision result is determined to be an allowed response, otherwise the target response decision result is determined to be a rejected response.

[0064] This invention implements a rigorous triple verification mechanism (PDU type + payload length + device identity) to ensure efficient Bluetooth device discovery while establishing a reliable security system. This effectively prevents malicious devices from launching spoofing attacks using CRC error frames, ensuring rapid response from authorized devices while blocking unauthorized access. It achieves an optimal balance between security and response efficiency in complex wireless environments, making it particularly suitable for applications with stringent security and privacy requirements, such as medical devices and access control systems. Furthermore, by verifying both the sender's address and the target address, a precise two-way communication confirmation mechanism is constructed. This not only eliminates privacy and security risks caused by responding to unauthorized devices but also avoids the ineffective waste of channel resources and device power consumption due to responding to incorrect broadcast requests. Thus, it achieves synergistic optimization of security, reliability, and communication efficiency in complex wireless environments.

[0065] Furthermore, based on the above embodiments of the invention, successful sender address verification includes one of the following conditions:

[0066] The sender's address is in the preset whitelist;

[0067] The sender's address can be successfully resolved using the pre-stored peer identity resolution key.

[0068] The preset whitelist can refer to a list of authorized device addresses stored in the broadcast device. Only device addresses in the list can be verified through the sender's address, which is the core configuration for static privacy protection.

[0069] A Remote Identity Resolving Key (Remote IRK) can be a key obtained or distributed from a paired, trusted peer device (such as a scanning device), specifically used to resolve the RPA generated by that peer device in order to verify its true identity.

[0070] In this embodiment of the invention, the process of verifying the sender address may include: querying whether the sender address exists in a preset whitelist, or using a pre-stored Remote IRK to parse the sender address (if it is a random private address) to verify its authenticity; if any of the above conditions are met, the sender address is considered to have passed verification, otherwise it fails.

[0071] Furthermore, based on the above embodiments of the invention, the target address verification is successful under one of the following conditions:

[0072] The target address is the address of this device;

[0073] The target address can be successfully resolved using the pre-stored local identity resolution key.

[0074] The Local Identity Resolution Key (Local IRK) can refer to a key generated and held by the device itself, used to generate and resolve the RPA used by the device to verify whether the target address in the external request is a valid RPA that the device has currently or has used in the past.

[0075] In this embodiment of the invention, the process of verifying the target address may include: checking whether the target address is the address of this device, or using a pre-stored Local IRK to perform a parsing operation on the target address (if it is a random private address) to verify its authenticity; if any of the above conditions are met, the target address is considered to have passed the verification, otherwise it fails.

[0076] Furthermore, based on the above embodiments of the invention, before sending the scan response, it further includes:

[0077] Apply a random transmit time jitter to the scan response, the transmit time jitter not exceeding the preset upper limit of the response window.

[0078] Transmission time jitter refers to a random time offset deliberately introduced before the scan response is sent. Its value is randomly selected within the range of [0, preset upper limit]. The core purpose is to stagger the transmission timing of multiple broadcast devices or multiple responses from the same broadcast device. The preset upper limit refers to a pre-set maximum allowable time offset, which is less than or equal to the total duration of the response window, ensuring that the transmission time after jitter is added does not exceed the protocol-allowed response window.

[0079] In this embodiment of the invention, a preset upper limit value for transmission time jitter can be obtained, and then a random time offset within the range of [0, preset upper limit value] can be generated by a random number generator, i.e., transmission time jitter. Subsequently, the broadcasting device will transmit the scan response based on the transmission timing superimposed with the transmission time jitter within the response window specified by the protocol.

[0080] This invention, by introducing controlled random time jitter before sending the scan response, can effectively avoid data packet collisions caused by multiple broadcast devices responding simultaneously under the same channel conditions. This design not only significantly improves communication reliability in high-density deployment scenarios, but also ensures full compliance with protocol specifications by strictly limiting the jitter range within the response window. Furthermore, the random nature of the jitter gives the system good anti-collision capabilities, achieving channel utilization optimization and overall communication success rate improvement while maintaining backward compatibility.

[0081] Furthermore, based on the above embodiments, this embodiment can set the following three response strategies with different levels of stringency:

[0082] ①Relaxed strategy: The request and response can be triggered directly as long as the AA verification passes;

[0083] ② Medium Strategy: Based on the lenient strategy, if the PDU type and / or payload length match the preset field value, a request response is triggered; otherwise, the response is rejected.

[0084] ③ Strict policy: If the sender address checksum and / or destination address checksum pass, the request response is triggered; otherwise, the response is rejected, provided that the medium policy is met.

[0085] Understandably, different levels of pre-defined response strategies can be set according to the different application scenarios. For example, a lenient strategy can be used to ensure response speed for high-density scanning scenarios (such as exhibitions and stadiums), a medium strategy can be used to balance speed and accuracy for regular scenarios (such as shopping mall price tags), and a strict strategy can be used to balance security and compliance for privacy-sensitive scenarios (such as medical devices and access control). Specific examples are as follows:

[0086] Taking a shopping mall shopping guide scenario as an example, in a high-concurrency environment where about 30 devices are scanning electronic price tags simultaneously during peak weekend hours, this solution, by configuring a medium strategy, enables intelligent scanning response even when CRC check fails due to data packet collision. This allows multiple scanning devices to receive a response in the first round of scanning, significantly reducing the time for the first display of product information from 400-600 milliseconds in traditional solutions to 120-180 milliseconds, effectively improving the customer's "first screen experience" and shopping efficiency.

[0087] Taking a smart factory inspection scenario as an example, in an industrial environment where multiple gateways actively scan several sensors, a strict strategy combined with a whitelist mechanism is adopted, enabling soft fault tolerance only for authorized gateways. This configuration significantly improves the initial discovery success rate of authorized gateways under interference conditions while ensuring that unauthorized devices cannot trigger a response, achieving a perfect balance between device discovery stability and system privacy and security in complex industrial environments.

[0088] Taking large-scale events as an example, in extremely high-density scenarios such as stadium events where tens of thousands of mobile phones scan coupons simultaneously, by enabling a relaxed strategy to prioritize response speed, the coupon redemption rate was significantly improved within the first minute. Backend statistics showed that the number of scan retries decreased by more than 50%, effectively solving the channel congestion problem when a large number of users access the network at the same time, and greatly improving the promotion effect of the event.

[0089] Taking medical equipment scenarios as an example, in the privacy-sensitive environment of doctors scanning medical equipment with tablets in the ward, a strict strategy is adopted, combined with IRK parsing and a whitelist dual verification mechanism, to ensure that only trusted doctor tablets can receive a response when CRC verification fails, while unfamiliar scanning devices are handled in accordance with traditional standards. This not only ensures the timely response of medical equipment, but also meets the strict requirements of the medical industry for data privacy and compliance.

[0090] It should be noted that when N scanning devices send SCAN_REQ almost simultaneously within a broadcast cycle, causing packet collisions, the traditional solution will not respond due to CRC check failure, forcing the scanning devices to undergo multiple backoff retries (average ≥ 2 times). However, with the response strategy of this embodiment, the broadcast device will still reply with SCAN_RSP after confirming that the AA is correct and the key fields in the protocol header (PDU type / payload length) are reliable. This allows most scanning devices to receive a response on the first attempt, significantly reducing the average number of attempts to close to 1. This directly achieves a significant reduction in the average first packet response latency, an effective reduction in the number of retransmissions, and a significant alleviation of wireless channel congestion.

[0091] Example 2

[0092] Figure 2 This is a schematic diagram of a Bluetooth broadcast response device provided in Embodiment 2 of the present invention. Figure 2 As shown, the device includes:

[0093] Access address verification module 21 is used to verify the access address of received wireless frames;

[0094] The response sending module 22 is used to send a scan response within the response window specified in the protocol if the access address verification passes.

[0095] Furthermore, based on the above embodiments of the invention, the response sending module 22 includes:

[0096] The decision unit is used to determine the corresponding target response decision result based on the protocol data unit information in the radio frame.

[0097] The response sending unit is used to send a scan response within the response window if the target response decision result is an allowable response.

[0098] Furthermore, based on the above embodiments of the invention, the protocol data unit information includes the protocol data unit type and payload length, and the response sending unit is specifically used for:

[0099] Determine whether the protocol data unit type or payload length is consistent with the corresponding preset field value;

[0100] If so, then the target response decision result is determined to be an acceptable response;

[0101] If not, the target response decision is determined to be a rejection.

[0102] Furthermore, based on the above embodiments of the invention, the protocol data unit information includes the protocol data unit type and payload length, and the response sending unit is specifically used for:

[0103] Determine whether the protocol data unit type and payload length are consistent with the corresponding preset field values;

[0104] If so, then the target response decision result is determined to be an acceptable response;

[0105] If not, the target response decision is determined to be a rejection.

[0106] Furthermore, based on the above embodiments of the invention, the protocol data unit information also includes the sender address and the destination address, and the response sending unit is further used for:

[0107] If the protocol data unit type or payload length matches the corresponding preset field value, then verify the sender address and the destination address;

[0108] If the sender address verification and / or the destination address verification pass, the destination response decision is determined to be an allowed response; otherwise, the destination response decision is determined to be a rejected response.

[0109] Furthermore, based on the above embodiments of the invention, the protocol data unit information also includes the sender address and the destination address, and the response sending unit is further used for:

[0110] If the protocol data unit type and payload length are consistent with the corresponding preset field values, then verify the sender address and the destination address;

[0111] If the sender address verification and / or the destination address verification pass, the destination response decision is determined to be an allowed response; otherwise, the destination response decision is determined to be a rejected response.

[0112] Furthermore, based on the above embodiments of the invention, successful sender address verification includes one of the following conditions:

[0113] The sender's address is in the preset whitelist;

[0114] The sender's address can be successfully resolved using the pre-stored peer identity resolution key.

[0115] Furthermore, based on the above embodiments of the invention, the target address verification is successful under one of the following conditions:

[0116] The target address is the address of this device;

[0117] The target address can be successfully resolved using the pre-stored local identity resolution key.

[0118] Furthermore, based on the above embodiments of the invention, the Bluetooth broadcast response device further includes:

[0119] The jitter addition module is used to apply a random transmit time jitter to the scan response before sending the scan response. The transmit time jitter does not exceed the preset upper limit of the response window.

[0120] The Bluetooth broadcast response device provided in the embodiments of the present invention can execute the Bluetooth broadcast response method provided in any embodiment of the present invention, and has the corresponding functional modules and beneficial effects of executing the method.

[0121] Example 3

[0122] Figure 3 A schematic diagram of an electronic device 30 that can be used to implement embodiments of the present invention is shown. The electronic device is intended to represent various forms of digital computers, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. The electronic device can also represent various forms of mobile devices, such as personal digital processors, cellular phones, smartphones, wearable devices (e.g., helmets, glasses, watches, etc.), and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely illustrative and are not intended to limit the implementation of the invention described and / or claimed herein.

[0123] like Figure 3As shown, the electronic device 30 includes at least one processor 31 and a memory, such as a read-only memory (ROM) 32 or a random access memory (RAM) 33, communicatively connected to the at least one processor 31. The memory stores computer programs executable by the at least one processor. The processor 31 can perform various appropriate actions and processes based on the computer program stored in the ROM 32 or loaded from storage unit 38 into the RAM 33. The RAM 33 can also store various programs and data required for the operation of the electronic device 30. The processor 31, ROM 32, and RAM 33 are interconnected via a bus 34. An input / output (I / O) interface 35 is also connected to the bus 34.

[0124] Multiple components in electronic device 30 are connected to I / O interface 35, including: input unit 36, such as keyboard, mouse, etc.; output unit 37, such as various types of monitors, speakers, etc.; storage unit 38, such as disk, optical disk, etc.; and communication unit 39, such as network card, modem, wireless transceiver, etc. Communication unit 39 allows electronic device 30 to exchange information / data with other devices through computer networks such as the Internet and / or various telecommunications networks.

[0125] Processor 31 can be a variety of general-purpose and / or special-purpose processing components with processing and computing capabilities. Some examples of processor 31 include, but are not limited to, a central processing unit (CPU), a graphics processing unit (GPU), various special-purpose artificial intelligence (AI) computing chips, various processors running machine learning model algorithms, a digital signal processor (DSP), and any suitable processor, controller, microcontroller, etc. Processor 31 performs the various methods and processes described above, such as the Bluetooth broadcast response method.

[0126] In some embodiments, the Bluetooth broadcast response method may be implemented as a computer program tangibly contained in a computer-readable storage medium, such as storage unit 38. In some embodiments, part or all of the computer program may be loaded and / or installed on electronic device 30 via ROM 32 and / or communication unit 39. When the computer program is loaded into RAM 33 and executed by processor 31, one or more steps of the Bluetooth broadcast response method described above may be performed. Alternatively, in other embodiments, processor 31 may be configured to perform the Bluetooth broadcast response method by any other suitable means (e.g., by means of firmware).

[0127] Various embodiments of the systems and techniques described above herein can be implemented in digital electronic circuit systems, integrated circuit systems, field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), application-specific standard products (ASSPs), systems-on-a-chip (SoCs), payload-programmable logic devices (CPLDs), computer hardware, firmware, software, and / or combinations thereof. These various embodiments may include implementations in one or more computer programs that can be executed and / or interpreted on a programmable system including at least one programmable processor, which may be a dedicated or general-purpose programmable processor, capable of receiving data and instructions from a storage system, at least one input device, and at least one output device, and transmitting data and instructions to the storage system, the at least one input device, and the at least one output device.

[0128] In some embodiments, the Bluetooth broadcast response method may be implemented as a computer program, which is implicitly included in a computer program product. When executed by a processor, the computer program implements the Bluetooth broadcast response method of the present invention. The computer program product can be understood as a software product that primarily implements its solution through a computer program. The computer program used to implement the method of the present invention may be written in any combination of one or more programming languages. These computer programs may be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing device, such that when executed by the processor, the computer program causes the functions / operations specified in the flowcharts and / or block diagrams to be implemented. The computer program may be executed entirely on a machine, partially on a machine, partially on a remote machine as a standalone software package, or entirely on a remote machine or server.

[0129] In the context of this invention, a computer-readable storage medium can be a tangible medium that may contain or store a computer program for use by or in conjunction with an instruction execution system, apparatus, or device. A computer-readable storage medium may include, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination thereof. Alternatively, a computer-readable storage medium may be a machine-readable signal medium. More specific examples of machine-readable storage media include electrical connections based on one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fibers, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof.

[0130] To provide interaction with a user, the systems and techniques described herein can be implemented on an electronic device having: a display device (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor) for displaying information to the user; and a keyboard and pointing device (e.g., a mouse or trackball) through which the user provides input to the electronic device. Other types of devices can also be used to provide interaction with the user; for example, feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user can be received in any form (including sound input, voice input, or tactile input).

[0131] The systems and technologies described herein can be implemented in computing systems that include backend components (e.g., as data servers), or computing systems that include middleware components (e.g., application servers), or computing systems that include frontend components (e.g., user computers with graphical user interfaces or web browsers through which users can interact with implementations of the systems and technologies described herein), or any combination of such backend, middleware, or frontend components. The components of the system can be interconnected via digital data communication of any form or medium (e.g., communication networks). Examples of communication networks include local area networks (LANs), wide area networks (WANs), blockchain networks, and the Internet.

[0132] A computing system can include clients and servers. Clients and servers are generally located far apart and typically interact through communication networks. The client-server relationship is created by computer programs running on the respective computers and having a client-server relationship with each other. The server can be a cloud server, also known as a cloud computing server or cloud host, which is a hosting product within the cloud computing service system to address the shortcomings of traditional physical hosts and VPS services, such as high management difficulty and weak business scalability.

[0133] It should be understood that the various forms of processes shown above can be used, with steps reordered, added, or deleted. For example, the steps described in this invention can be executed in parallel, sequentially, or in different orders, as long as the desired result of the technical solution of this invention can be achieved, and this is not limited herein.

[0134] The specific embodiments described above do not constitute a limitation on the scope of protection of this invention. Those skilled in the art should understand that various modifications, combinations, sub-combinations, and substitutions can be made according to design requirements and other factors. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of this invention should be included within the scope of protection of this invention.

Claims

1. A Bluetooth broadcast response method, characterized in that, The method includes: Perform access address verification on the received wireless frames; If the access address verification passes, a scan response is sent within the response window specified in the protocol.

2. The method according to claim 1, characterized in that, Sending the scan response within the response window specified in the protocol includes: The corresponding target response decision result is determined based on the protocol data unit information in the wireless frame; If the target response decision result is an allow response, then the scan response is sent within the response window.

3. The method according to claim 2, characterized in that, The protocol data unit information includes the protocol data unit type and payload length. Determining the corresponding target response decision result based on the protocol data unit information in the radio frame includes: Determine whether the protocol data unit type or the payload length is consistent with the corresponding preset field value; If so, then the target response decision result is determined to be a permissible response; If not, the target response decision result is determined to be a rejection response.

4. The method according to claim 2, characterized in that, The protocol data unit information includes the protocol data unit type and payload length. Determining the corresponding target response decision result based on the protocol data unit information in the radio frame includes: Determine whether the protocol data unit type and the payload length are both consistent with the corresponding preset field values; If so, then the target response decision result is determined to be a permissible response; If not, the target response decision result is determined to be a rejection response.

5. The method according to claim 3, characterized in that, The protocol data unit information also includes the sender address and the target address. The step of determining the corresponding target response decision result based on the protocol data unit information in the radio frame includes: If the protocol data unit type or the payload length matches the corresponding preset field value, then verify the sender address and the destination address; If the sender address verification and / or the target address verification pass, the target response decision result is determined to be an allowed response; otherwise, the target response decision result is determined to be a rejected response.

6. The method according to claim 4, characterized in that, The protocol data unit information also includes the sender address and the target address. The step of determining the corresponding target response decision result based on the protocol data unit information in the radio frame includes: If the protocol data unit type and the payload length are both consistent with the corresponding preset field values, then verify the sender address and the target address; If the sender address verification and / or the target address verification pass, the target response decision result is determined to be an allowed response; otherwise, the target response decision result is determined to be a rejected response.

7. The method according to claim 5 or 6, characterized in that, The sender address verification is successful if one of the following conditions is met: The sender address exists in a preset whitelist; The sender's address can be successfully resolved using the pre-stored peer identity resolution key.

8. The method according to claim 5 or 6, characterized in that, The target address verification is successful if one of the following conditions is met: The target address is the address of this device; The target address can be successfully resolved using the pre-stored local identity resolution key.

9. The method according to claim 1, characterized in that, Before sending the scan response, the following is also included: A random transmission time jitter is applied to the scan response, the transmission time jitter not exceeding a preset upper limit value of the response window.

10. An electronic device, characterized in that, The electronic device includes: At least one processor; and A memory communicatively connected to the at least one processor; wherein, The memory stores a computer program that can be executed by the at least one processor to enable the at least one processor to perform the Bluetooth broadcast response method according to any one of claims 1-9.

Images