Bluetooth Digital Key Pairing for Low-Power Multi-Protocol Access
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Vehicle-side Bluetooth chips cannot support the simultaneous transmission of both RPA and static address broadcasts required by different digital key protocols, leading to increased power consumption due to time-division switching.
Innovation Solution
A method and apparatus for creating Bluetooth digital keys that generate keys based on specific protocols (public or private) supported by the terminal and vehicle systems, ensuring compatibility and low power consumption by maintaining consistent broadcast types across multiple keys.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Adaptability or versatility
If the vehicle-side Bluetooth chip uses time-division switching to send both RPA and static address broadcasts, then multi-protocol coexistence is achieved, but power consumption increases and the chip cannot enter low-power mode
Solution Approach 1:
The patent segments the digital key protocols into two categories: RPA-based protocols (CCC, ICCOA, ICCE) and static address-based protocols. The system selectively activates only the required broadcast type based on the terminal's protocol support, avoiding the need to maintain both broadcast types simultaneously. This segmentation allows the Bluetooth chip to operate in a single mode at a time, enabling low-power operation while still supporting multiple protocols through selective activation.
2Adaptability or versatility
If the vehicle-side Bluetooth chip supports simultaneous transmission of both RPA and static address broadcasts, then multi-protocol compatibility is achieved, but hardware limitations prevent low power consumption
Solution Approach 1:
The patent implements dynamic broadcast type selection based on the terminal device's protocol capabilities. The system determines which broadcast type (RPA or static address) is required and activates only that type, making the Bluetooth chip's broadcast functionality dynamic rather than static. This dynamic approach allows the chip to adapt its operation to match the specific protocol requirements, maintaining multi-protocol compatibility without requiring hardware capable of simultaneous dual-mode operation.
3Use of energy by moving object
If the vehicle-side Bluetooth chip enters low-power mode, then power consumption is reduced, but it cannot send both types of broadcasts required by different protocols
Solution Approach 1:
The patent performs preliminary determination of the required broadcast type before the Bluetooth chip enters low-power mode. The system analyzes the terminal device's protocol support capabilities in advance and pre-selects the appropriate broadcast type (RPA or static address). This preliminary action ensures that when the chip switches to low-power mode, it is already configured to send only the necessary broadcast type, maintaining protocol compatibility support while enabling energy-efficient operation.
Data Source
Figure 1
Figure 2
Figure 3
AI summary
The invention relates to a method and apparatus for creating a Bluetooth digital key, and a storage medium, which are used to solve the problem in the prior art that a vehicle-side Bluetooth chip cannot make multiple Bluetooth digital key protocols coexist while maintaining low power consumption. The method includes: in response to a first event in which a vehicle owner creates a first Bluetooth digital key between a first terminal and a vehicle, generating the first Bluetooth digital key and first Bluetooth pairing information that are based on a first protocol to complete creation of the first Bluetooth digital key between the first terminal and the vehicle; in response to a second event in which the vehicle owner creates a second Bluetooth digital key between a second terminal and the vehicle, generating the second Bluetooth digital key and second Bluetooth pairing information that are based on a second protocol to complete creation of the second Bluetooth digital key between the second terminal and the vehicle. A broadcast type supported by the operating system of the first terminal is different from a broadcast type supported by an operating system of the second terminal. A broadcast type supported by the first Bluetooth digital key is the same as a broadcast type supported by the second Bluetooth digital key.