Control method, device and storage medium of digital key

Abstract

This application discloses a control method, device, and storage medium for a digital key. The application relates to the field of Bluetooth communication technology. The control method for the digital key includes: in response to detecting a Bluetooth establishment event, constructing a first Bluetooth connection parameter request command based on a target supervision timeout parameter, wherein the Bluetooth establishment event indicates that a Bluetooth communication link has been established between the target device and the target digital key; and sending the first Bluetooth connection parameter request command to the target digital key, so that the target digital key establishes communication with the target device based on the target supervision timeout parameter. This application can improve the stability of the Bluetooth connection between the digital key and the target device.

Description

Technical Field

[0001] This application relates to the field of Bluetooth communication technology, and in particular to a control method, device and storage medium for a digital key. Background Technology

[0002] Occasionally, when a user uses a terminal device as a digital key, accidental locking may occur. For example, if the user moves around the target device but has not left the effective operating area, the target device may lock. This is because the BLE connection of the terminal device has been unexpectedly interrupted, causing Bluetooth communication to be lost. Summary of the Invention

[0003] The main purpose of this application is to provide a control method, device and storage medium for a digital key, which aims to solve the technical problem of Bluetooth digital keys being prone to disconnection.

[0004] To achieve the above objectives, this application provides a method for controlling a digital key, the method comprising:

[0005] In response to the detection of a Bluetooth establishment event, a first Bluetooth connection parameter request instruction is constructed based on the target supervision timeout parameter, wherein the Bluetooth establishment event indicates that the target device and the target digital key have established a Bluetooth communication link; The first Bluetooth connection parameter request instruction is sent to the target digital key so that the target digital key establishes communication with the target device based on the target supervision timeout parameter.

[0006] In one embodiment, after sending the first Bluetooth connection parameter request instruction to the target digital key, the process includes: In response to the second Bluetooth connection parameter request instruction sent by the target digital key, the first supervision timeout parameter corresponding to the second Bluetooth connection parameter request instruction is obtained; Based on the first supervision timeout parameter or the target supervision timeout parameter, construct and send a Bluetooth connection parameter response command to the target digital key.

[0007] In one embodiment, before constructing and sending a Bluetooth connection parameter response command to the target digital key based on the first supervision timeout parameter or the target supervision timeout parameter, the method further includes: Determine that the first supervision timeout parameter is less than a preset threshold; and / or, The compliance check performed for the target monitoring timeout parameter has been confirmed as passed.

[0008] In one embodiment, after sending the first Bluetooth connection parameter request instruction to the target digital key, the process includes: In response to the Bluetooth connection parameter update command sent by the target digital key, the second supervision timeout parameter corresponding to the Bluetooth connection parameter update command is obtained; If the second supervision timeout parameter is less than a preset threshold, a safe time window is determined, wherein the safe time window does not coincide with the set request-intensive period. Within the security time window, a first Bluetooth connection parameter request instruction is constructed and sent to the digital key based on the target supervision timeout parameter.

[0009] In one embodiment, after sending the first Bluetooth connection parameter request instruction to the digital key corresponding to the Bluetooth establishment event, the process includes: In response to a device control command sent by the target digital key, a third Bluetooth connection parameter request command for adjusting the Bluetooth connection interval is constructed, and the third Bluetooth connection parameter request command is sent to the target digital key; and / or, In response to the device control command sent by the target digital key, a physical layer mode request command for adjusting the physical layer mode is constructed, and the physical layer mode request command is sent to the target digital key.

[0010] In one embodiment, constructing the third Bluetooth connection parameter request instruction for adjusting the Bluetooth connection interval includes: constructing the third Bluetooth connection parameter request instruction based on a target Bluetooth connection interval, wherein the target Bluetooth connection interval is less than the original Bluetooth connection interval; and / or, The physical layer mode request instruction for constructing and adjusting the physical layer mode includes: constructing the physical layer mode request instruction based on the target physical layer mode, wherein the level of the target physical layer mode is lower than the level of the original physical layer mode.

[0011] In one embodiment, after sending the third Bluetooth connection parameter request instruction to the target digital key, the method further includes: in response to a device control instruction execution completion event or a preset timeout event, constructing a fourth Bluetooth connection parameter request instruction to restore the original Bluetooth connection interval, and sending the fourth Bluetooth connection parameter request instruction to the target digital key, so that the target digital key and the target device resume Bluetooth communication based on the original Bluetooth connection interval; and / or, After sending the physical layer mode request instruction to the target digital key, the method further includes: in response to the execution completion event or preset timeout event of the device control instruction, constructing a second physical layer mode request instruction to restore the original physical layer mode, and sending the second physical layer mode request instruction to the target digital key, so that the target digital key and the target device can resume Bluetooth communication based on the original physical layer mode.

[0012] In one embodiment, the target device includes at least one of the following: vehicle, home appliance, smart wearable device, smart access control device, building control terminal, park gate device, shared device terminal, charging pile device, smart locker, industrial intelligent control terminal, Internet of Things gateway device, self-service terminal, security monitoring device, and office equipment.

[0013] In addition, to achieve the above objectives, this application also provides a digital key control device, which includes: a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the computer program is configured to implement the steps of the digital key control method as described above.

[0014] In addition, to achieve the above objectives, this application also provides a storage medium, which is a computer-readable storage medium, on which a program for implementing a digital key control method is stored, and the program for implementing the digital key control method is executed by a processor to implement the steps of the digital key control method as described above.

[0015] This application provides a control method for a digital key. Firstly, in response to the detection of a Bluetooth establishment event, a first Bluetooth connection parameter request command is constructed based on a target supervision timeout parameter. The Bluetooth establishment event indicates that the target device and the target digital key have established a Bluetooth communication link. The first Bluetooth connection parameter request command is sent to the target digital key, enabling the target digital key to establish communication with the target device based on the target supervision timeout parameter. In other words, this application, by actively sending a first Bluetooth connection parameter request command carrying a target supervision timeout parameter to the digital key after the Bluetooth communication link with the digital key is established, enables the digital key and the target device to establish communication based on a more robust target supervision timeout parameter. This overcomes the technical defect of easy disconnection caused by the use of fragile supervision timeout parameters in the digital key of the terminal device, and improves the stability of the Bluetooth connection between the digital key and the target device. Attached Figure Description

[0016] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0017] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, for those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0018] Figure 1This is a flowchart illustrating an embodiment of the digital key control method of this application. Figure 2 This is a schematic diagram of the overall process of digital key connection provided in Embodiment 10 of the digital key control method of this application; Figure 3 A flowchart illustrating the compliance verification of the monitoring timeout parameter provided in Embodiment 10 of the control method for the digital key of this application; Figure 4 A schematic diagram of the delay renegotiation anti-collision process provided in Embodiment 10 of the control method for digital keys in this application; Figure 5 A schematic diagram of the communication process for a remote parking scenario provided in Embodiment 10 of the control method for the digital key of this application; Figure 6 This is a schematic diagram of the vehicle controller architecture provided in Embodiment 10 of the digital key control method of this application; Figure 7 This is a schematic diagram of the hardware structure involved in the embodiment of the digital key control device of this application.

[0019] The purpose, features, and advantages of this application will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0020] It should be understood that the specific embodiments described herein are only used to explain the technical solutions of this application and are not intended to limit this application.

[0021] To better understand the technical solution of this application, a detailed description will be provided below in conjunction with the accompanying drawings and specific implementation methods.

[0022] Currently, occasional connection anomalies occur when users use terminal devices as digital keys, resulting in accidental locking. For example, if a user moves around the target device but hasn't left its effective operating area, the target device may lock. Analysis of the signaling at each stage of Bluetooth communication between the terminal and target devices reveals that the terminal device's own protocol leads to a bias in its link parameter configuration throughout the BLE connection lifecycle, negatively impacting connection stability and potentially causing disconnection between the terminal and target devices.

[0023] The main solution of this application is: in response to the detection of a Bluetooth establishment event, a first Bluetooth connection parameter request instruction is constructed based on the target supervision timeout parameter; the Bluetooth establishment event indicates that the target device and the target digital key have established a Bluetooth communication link; the first Bluetooth connection parameter request instruction is sent to the target digital key so that the target digital key establishes communication with the target device based on the target supervision timeout parameter.

[0024] This application, after establishing a Bluetooth communication link with the digital key, actively sends a first Bluetooth connection parameter request command carrying a target supervision timeout parameter to the digital key, enabling the digital key and the target device to establish communication based on a more robust target supervision timeout parameter. This overcomes the technical defect that the terminal device's digital key is prone to disconnection due to the use of a fragile supervision timeout parameter, and improves the stability of the Bluetooth connection between the digital key and the target device.

[0025] It should be noted that the executing entity in this embodiment can be a target device, or a computing service device with data processing, network communication, and program execution functions, such as a tablet computer, personal computer, or mobile phone, or a control device with a digital key capable of performing the above functions. This embodiment does not specifically limit this. The following uses the target device as the executing entity as an example to describe this embodiment and the following embodiments.

[0026] Based on this, Embodiment 1 of this application proposes a digital key control method, please refer to... Figure 1 The control method for the target digital key includes steps S10-S20: Step S10: In response to the detection of a Bluetooth establishment event, a first Bluetooth connection parameter request instruction is constructed based on the target supervision timeout parameter. The Bluetooth establishment event indicates that the target device and the target digital key have established a Bluetooth communication link.

[0027] In this embodiment, the Bluetooth establishment event refers to the event in which the target device and the target digital key establish a link layer connection and achieve physical channel connectivity via the Bluetooth protocol. It signifies that a Bluetooth communication link capable of data interaction and parameter negotiation has been successfully established between the target device and the target digital key. The target supervision timeout parameter is a pre-set supervision timeout parameter of the target device to improve the stability of the Bluetooth connection; it is a robust value conforming to the Bluetooth protocol specification. The first Bluetooth connection parameter request command is a link layer command constructed by the target device to request the target digital key to use the target supervision timeout parameter for Bluetooth communication; it is a standard command in the Bluetooth Low Energy protocol.

[0028] Optionally, the type of target device is not further enumerated, but is a device that can be unlocked and locked using a BLE digital key.

[0029] For example, the target equipment includes at least one of the following: vehicle, home appliance, smart wearable device, smart access control device, building control terminal, park gate device, shared equipment terminal, charging pile device, smart locker, industrial intelligent control terminal, Internet of Things gateway device, self-service terminal, security monitoring device, and office equipment.

[0030] As an optional implementation, after the target device detects the Bluetooth establishment event, it immediately retrieves the locally preset target monitoring timeout parameter, fills the parameter into the specified field of the Bluetooth connection parameter request command according to the instruction format requirements of the Bluetooth Low Energy protocol, and completes the construction of the first Bluetooth connection parameter request command. No other default Bluetooth connection parameters are modified during the construction process.

[0031] As another optional implementation, after the target device detects the Bluetooth establishment event, it first verifies the validity of the target supervision timeout parameters stored locally. After confirming that the parameters meet the mathematical constraints and format requirements of the Bluetooth protocol, it combines the Bluetooth connection interval parameters that take into account both communication response speed and device power consumption, and fills them into the corresponding field of the Bluetooth connection parameter request command to complete the construction of the first Bluetooth connection parameter request command.

[0032] Optionally, in addition to the target supervision timeout parameter, the first Bluetooth connection parameter request may also include any one or any combination of parameters such as Latency, Interval_Min, and Interval_Max.

[0033] Latency is a Bluetooth connection latency parameter, indicating the number of Bluetooth connection events that the target digital key can ignore. A value of 0 indicates that the target digital key needs to respond to every Bluetooth connection event. Interval_Min is the minimum Bluetooth connection interval parameter, indicating the minimum time interval between Bluetooth connection events between the target device and the target digital key; Interval_Max is the maximum Bluetooth connection interval parameter, indicating the maximum time interval between Bluetooth connection events between the target device and the target digital key. Both parameters together limit the dynamic range of the actual Bluetooth connection interval and conform to the numerical specifications of the Bluetooth Low Energy protocol. Latency, Interval_Min, and Interval_Max are the core supporting parameters of the first Bluetooth connection parameter request command. Together with the target monitoring timeout parameter, they are filled into the corresponding fields of the command to complete the command construction.

[0034] The preset method for the target supervision timeout parameter includes pre-storing a fixed value that has been verified by engineering on the target device. This value is set in conjunction with the Bluetooth communication characteristics of the target digital key, and is accompanied by preset and adapted Latency, Interval_Min, and Interval_Max parameter values. The entire set of parameters has been tested and verified by multiple generations of terminal devices and Bluetooth platforms, which can effectively improve the stability of Bluetooth connection. The target supervision timeout parameter is calculated as follows: the target device performs real-time calculation based on the preset Latency, Interval_Min, and Interval_Max parameters, according to the mathematical constraint formula Timeout>(1+Latency)×Interval_Max×2 specified by the Bluetooth Low Energy protocol. The calculation result is rounded and used as the target supervision timeout parameter. Moreover, the base values ​​of the Latency, Interval_Min, and Interval_Max parameters used for calculation can be dynamically adjusted according to the actual communication environment of the vehicle Bluetooth to adapt to different communication scenarios.

[0035] For example, the target supervision timeout parameter can be any value within a closed interval of 2000ms to 5000ms. It can be 2000ms, 5000ms, 2500ms, 3000ms, etc.

[0036] For example, the target supervision timeout parameter is any value greater than 2000ms, such as 4000ms or 3500ms.

[0037] Step S20: Send the first Bluetooth connection parameter request instruction to the target digital key so that the target digital key establishes communication with the target device based on the target supervision timeout parameter.

[0038] In this embodiment, the target digital key is a Bluetooth target digital key mounted on a mobile smart device, used to realize functions such as unlocking, locking, and controlling the target device. Establishing communication signifies that after receiving the first Bluetooth connection parameter request instruction, the target digital key, based on the established Bluetooth communication link, updates and negotiates the Bluetooth connection parameters according to the target supervision timeout parameter, thereby entering a reliable and continuous Bluetooth data interaction state with the target device based on the target supervision timeout parameter.

[0039] As an optional implementation, the target device sends the constructed first Bluetooth connection parameter request command directly to the target digital key corresponding to the Bluetooth establishment event via its own Bluetooth communication module in the form of wireless air interface. After sending, it monitors the command reception feedback signal of the target digital key in real time to confirm whether the command has been successfully delivered.

[0040] As another optional implementation, the target device first encapsulates the constructed first Bluetooth connection parameter request command into a protocol to make it conform to the Bluetooth Low Energy air interface transmission standard, and then sends the encapsulated command to the corresponding target digital key in batches through the Bluetooth radio frequency unit. At the same time, a command retransmission mechanism is set up so that if no reception feedback is received within a preset time, the command will be automatically retransmitted.

[0041] For example, when a user approaches a target device with their mobile phone digital key, the target device's Bluetooth module continuously broadcasts a Bluetooth signal. Upon receiving this signal, the mobile phone digital key initiates a Bluetooth connection request to the target device. Upon receiving the request, the target device establishes a Bluetooth communication link with the mobile phone digital key, triggering a Bluetooth establishment event. The target device responds to this event by directly retrieving a locally preset target supervision timeout parameter. Following the standard instruction format of the Bluetooth Low Energy protocol, it fills this parameter into the supervision timeout field of the Bluetooth connection parameter request instruction, completing the construction of the first Bluetooth connection parameter request instruction. The target device then encapsulates this instruction according to the Bluetooth over-the-air transmission specification and sends it to the mobile phone digital key via its Bluetooth radio frequency unit. After successfully receiving and parsing the instruction, the mobile phone digital key adopts the target supervision timeout parameter, establishing stable Bluetooth communication with the target device based on this parameter. All subsequent Bluetooth data interactions between the two devices are executed according to this target supervision timeout parameter.

[0042] This embodiment, after establishing a Bluetooth communication link, allows the target device to actively respond to events and construct a first Bluetooth connection parameter request command carrying target supervision timeout parameters. This command is then precisely sent to the corresponding target digital key. This ensures that the target digital key and target device use robust target supervision timeout parameters from the very beginning of Bluetooth communication, avoiding the Bluetooth connection dropout problem caused by the target digital key using its own fragile supervision timeout parameters. This improves the stability of the Bluetooth connection between the target digital key and target device from the source, laying a reliable Bluetooth communication foundation for the normal implementation of subsequent functions such as contactless unlocking and remote control of the target device, and ensuring the stability of the communication link for the target digital key's related device control functions.

[0043] Based on any of the above embodiments, in the second embodiment of this application, after sending the first Bluetooth connection parameter request instruction to the target digital key corresponding to the Bluetooth establishment event, the following steps are included: Step S30: In response to the second Bluetooth connection parameter request instruction sent by the target digital key, obtain the first supervision timeout parameter corresponding to the second Bluetooth connection parameter request instruction.

[0044] In this embodiment, the second Bluetooth connection parameter request instruction is a Bluetooth connection parameter request instruction actively sent by the target digital key to the target device. This instruction is generated by the target digital key based on parameters set by its own system and is used to request the target device to accept its specified Bluetooth connection parameters. That is, both the first and second Bluetooth connection parameter request instructions belong to the category of Bluetooth connection parameter request instructions, namely LL_CONNECTION_PARAM_REQ. However, the first Bluetooth connection parameter request instruction is initiated by the target device, while the second Bluetooth connection parameter request instruction is initiated by the target digital key. The first supervision timeout parameter is a supervision timeout parameter carried by the target digital key in the second Bluetooth connection parameter request instruction, and is a supervision timeout value preset by the target digital key itself.

[0045] Optionally, in addition to the first supervision timeout parameter, the second Bluetooth connection parameter request instruction may also include any one or any combination of parameters such as Latency, Interval_Min and Interval_Max. The target device can extract the above-mentioned supporting parameters at the same time as obtaining the first supervision timeout parameter.

[0046] As an optional implementation, the target device listens to the instruction data sent by the target digital key in real time through the Bluetooth communication module. When the characteristic field of the second Bluetooth connection parameter request instruction is detected, the instruction is immediately parsed, and the value corresponding to the supervision timeout parameter field in the instruction is extracted as the first supervision timeout parameter. At the same time, the values ​​of the Latency, Interval_Min and Interval_Max parameters in the instruction are extracted and temporarily stored.

[0047] As another optional implementation, the target device sets up an instruction filtering mechanism to parse and process only Bluetooth connection parameter-type instructions sent by the target digital key. When the second Bluetooth connection parameter request instruction is captured, the format compliance of the instruction is first verified. After confirming that the instruction conforms to the Bluetooth Low Energy protocol specification, the first supervision timeout parameter is extracted. If the instruction format is abnormal, it is directly discarded and an abnormal log is recorded.

[0048] Step S40: Based on the first supervision timeout parameter or the target supervision timeout parameter, construct and send a Bluetooth connection parameter response command to the target digital key.

[0049] In this embodiment, the Bluetooth connection parameter response instruction is a response instruction constructed by the target device in response to the second Bluetooth connection parameter request instruction sent by the target digital key. It is used to provide feedback on whether to accept the parameter request of the target digital key and belongs to the standard response instruction in the Bluetooth Low Energy protocol.

[0050] Optionally, a Bluetooth connection parameter response command is constructed and sent to the target digital key based on the numerical relationship between the first supervision timeout parameter and a preset threshold. Specifically, the first supervision timeout parameter is compared with the preset threshold. If the first supervision timeout parameter is greater than or equal to the preset threshold, a Bluetooth connection parameter response command is constructed and sent to the target digital key based on the first supervision timeout parameter. If the first supervision timeout parameter is less than the preset threshold, a Bluetooth connection parameter response command is constructed and sent to the target digital key based on the target supervision timeout parameter. The preset threshold is a pre-set threshold value for the supervision timeout parameter on the target device. This value is determined based on the Bluetooth protocol specification and the communication characteristics of the target digital key, and is used to determine whether the first supervision timeout parameter possesses connection stability.

[0051] As an optional implementation, the target device compares the extracted first supervision timeout parameter with a preset threshold. If the first supervision timeout parameter is greater than or equal to the preset threshold, a Bluetooth connection parameter response command is constructed according to the parameters (including the first supervision timeout parameter, Latency, Interval_Min, and Interval_Max parameters) in the second Bluetooth connection parameter request command sent by the target digital key. If the first supervision timeout parameter is less than the preset threshold, a Bluetooth connection parameter response command is constructed based on the target supervision timeout parameter preset by the target device and the corresponding Latency, Interval_Min, and Interval_Max parameters. After construction, the response command is sent to the target digital key through the vehicle Bluetooth module.

[0052] As another optional implementation, the target device first determines the numerical relationship between the first supervision timeout parameter and the preset threshold, and then selects the corresponding parameter set to construct the Bluetooth connection parameter response command based on the determination result: if the first supervision timeout parameter meets the stability requirements (greater than or equal to the preset threshold), the parameter of the target digital key is directly reused to construct the response command; if the first supervision timeout parameter does not meet the stability requirements (less than the preset threshold), the compliance of the target supervision timeout parameter with the corresponding Latency, Interval_Min, and Interval_Max parameters is first verified according to the Bluetooth protocol mathematical constraint formula Timeout>(1+Latency)×Interval_Max×2. After the verification is passed, the Bluetooth connection parameter response command is constructed, and the command is sent to the target digital key in batches, while setting a sending timeout retransmission mechanism.

[0053] For example, the user's mobile digital key and the target device have established Bluetooth communication based on the target supervision timeout parameter. Subsequently, the target digital key actively sends a second Bluetooth connection parameter request command to the target device based on its own system logic. This command carries a first supervision timeout parameter of 2000ms, as well as parameters with Latency of 0, Interval_Min of 30ms, and Interval_Max of 50ms. After the target device listens to this second Bluetooth connection parameter request command in real time, it immediately parses the command and extracts the first supervision timeout parameter of 2000ms, and simultaneously stores the Latency, Interval_Min, and Interval_Max parameters. The target device compares the first supervision timeout parameter of 2000ms with the preset threshold of 4000ms. If the first supervision timeout parameter is less than the preset threshold, it will then retrieve the locally preset target supervision timeout parameter of 5000ms and the corresponding parameters of Latency of 0, Interval_Min of 20ms, and Interval_Max of 40ms. After verifying that the parameters conform to the mathematical constraints of the Bluetooth protocol, it will construct a Bluetooth connection parameter response command according to the standard format of the Bluetooth Low Energy protocol. The constructed command will be encapsulated and sent to the target digital key through the vehicle Bluetooth radio frequency unit. After receiving and parsing the response command, the target digital key will adopt the robust parameters therein for Bluetooth communication.

[0054] This embodiment responds to the second Bluetooth connection parameter request command actively sent by the target digital key, accurately extracts the first supervision timeout parameter, compares it with a preset threshold, and then constructs and sends a Bluetooth connection parameter response command based on the comparison result. This achieves dynamic intervention in subsequent parameter requests from the target digital key, compensating for the shortcomings of setting parameters only during the Bluetooth establishment phase. Simultaneously, compliance verification of supporting parameters such as Latency, Interval_Min, and Interval_Max is incorporated into the command construction process to ensure that the response command conforms to the Bluetooth protocol specification. This further avoids connection drops caused by the target digital key using its own vulnerable supervision timeout parameters, continuously maintaining the stability of the Bluetooth connection. This forms a two-layer protection system combining initial intervention during connection establishment with dynamic intervention for connection maintenance.

[0055] Based on any of the above embodiments, in Embodiment 3 of this application, before constructing and sending the Bluetooth connection parameter response command to the target digital key according to the first supervision timeout parameter or the target supervision timeout parameter, the method further includes: Determine that the first supervision timeout parameter is less than a preset threshold; and / or determine that the compliance check performed for the target supervision timeout parameter has passed.

[0056] Optionally, if the first supervision timeout parameter is less than the preset threshold, a Bluetooth connection parameter response command is constructed and sent to the target digital key based on the target supervision timeout parameter.

[0057] In this embodiment, this step is the core intervention action performed by the target device after it has completed the comparison of the first supervision timeout parameter with the preset threshold value, in case the parameter does not meet the Bluetooth connection stability requirements. It is a key execution step for parameter overwriting during the connection maintenance phase. During the instruction construction process, the Latency, Interval_Min and Interval_Max parameters that match the target supervision timeout parameter will be incorporated simultaneously to ensure that the parameter set in the instruction meets the overall constraints of the Bluetooth protocol.

[0058] As an optional implementation, after the target device determines that the first supervision timeout parameter is less than a preset threshold, it immediately retrieves the preset target supervision timeout parameter, as well as the corresponding Latency, Interval_Min, and Interval_Max parameters from the local parameter library. In accordance with the format requirements of the Bluetooth Low Energy protocol for Bluetooth connection parameter response instructions, the above parameters are filled into the corresponding fields of the instruction. After completing the instruction construction, the instruction is sent directly to the target digital key through the vehicle Bluetooth communication module. After sending, a short-term instruction reception confirmation monitoring is started to confirm whether the target digital key has successfully received the response instruction.

[0059] As another optional implementation, after determining that the first supervision timeout parameter is less than the preset threshold, the target device first retrieves the target supervision timeout parameter and the corresponding Latency, Interval_Min and Interval_Max parameters, performs a secondary verification of the mathematical constraints of the Bluetooth protocol on this set of parameters, and confirms that the formula requirement of Timeout>(1+Latency)×Interval_Max×2 is met. Then, it constructs a Bluetooth connection parameter response command according to the protocol specification, performs air interface transmission adaptation and encapsulation on the constructed command, and then sends it to the target digital key through the vehicle Bluetooth radio frequency unit in a directional transmission manner. At the same time, a single retransmission mechanism is set. If no instruction reception feedback is received from the target digital key within a preset time, the response command is automatically retransmitted once.

[0060] For example, in the second Bluetooth connection parameter request command sent by the mobile digital key to the target device, the first supervision timeout parameter is 2000ms, and the target device's preset supervision timeout parameter threshold is 4000ms. After numerical comparison, it is determined that 2000ms is less than 4000ms, triggering the execution action of this step. The target device then retrieves the preset target supervision timeout parameter of 5000ms from the local parameter library, as well as the corresponding parameters with Latency of 0, Interval_Min of 20ms, and Interval_Max of 40ms. It first verifies that the set of parameters meets the mathematical constraint formula of the Bluetooth protocol, and then fills these parameters into the corresponding fields of the Bluetooth connection parameter response command in sequence according to the standard format of the Bluetooth Low Energy protocol, thus completing the command construction. After the target device encapsulates the response command according to the air interface transmission standard, it sends it to the mobile phone digital key via the vehicle Bluetooth radio frequency unit. At the same time, it starts a 500ms reception confirmation monitoring. Within the monitoring time, it receives the command reception feedback from the target digital key, confirming that the response command was successfully delivered. The target digital key then adopts the target monitoring timeout parameter and supporting parameters in the response command and continues to communicate with the target device via Bluetooth.

[0061] Optionally, if the first supervision timeout parameter is greater than or equal to the preset threshold, a Bluetooth connection parameter response command is constructed and sent to the target digital key based on the first supervision timeout parameter.

[0062] As an optional implementation, after the target device determines that the first supervision timeout parameter is greater than or equal to a preset threshold, it directly retrieves the first supervision timeout parameter temporarily stored when parsing the second Bluetooth connection parameter request command, as well as the Latency, Interval_Min, and Interval_Max parameters sent by the target digital key. According to the format requirements of the Bluetooth Low Energy protocol for Bluetooth connection parameter response commands, the above parameters are filled into the corresponding fields of the command. After the command is constructed, the command is sent to the target digital key in real time through the vehicle Bluetooth communication module. After sending, the air interface transmission status of the command is simply monitored to confirm that there are no transmission errors.

[0063] As another optional implementation, after determining that the first supervision timeout parameter is greater than or equal to a preset threshold, the target device first retrieves the first supervision timeout parameter of the target digital key and the corresponding Latency, Interval_Min and Interval_Max parameters, quickly performs compliance verification of the Bluetooth protocol mathematical constraint formula, and confirms that the set of parameters meets the requirement of Timeout>(1+Latency)×Interval_Max×2. Then, it constructs a Bluetooth connection parameter response command according to the protocol specification, encapsulates the command into a lightweight air interface transmission, and sends it to the target digital key through the vehicle Bluetooth radio frequency unit. If no reception feedback is detected from the target digital key within a preset short time, only one lightweight retransmission is performed to avoid command redundancy caused by multiple retransmissions.

[0064] For example, the mobile digital key sends a second Bluetooth connection parameter request command to the target device. The command carries a first supervision timeout parameter of 5000ms. The target device's preset supervision timeout parameter threshold is 4000ms. After comparison, it is determined that 5000ms is greater than the preset threshold, triggering the execution of this step. The target device then retrieves the first supervision timeout parameter of 5000ms temporarily stored during command parsing, as well as the parameters of the target digital key with Latency of 0, Interval_Min of 20ms, and Interval_Max of 40ms. After quickly verifying that the set of parameters conforms to the mathematical constraint formula of the Bluetooth protocol, it fills these parameters into the corresponding fields of the Bluetooth connection parameter response command according to the standard format of the Bluetooth Low Energy protocol, completing the command construction. After the target device performs lightweight air interface encapsulation on the response command, it sends it to the mobile digital key through the vehicle's Bluetooth radio frequency unit. After detecting that there are no errors in the air interface transmission, the transmission is completed. After receiving and parsing the response command, the target digital key continues to use the same set of parameters it sent to communicate with the target device via Bluetooth.

[0065] This embodiment, by constructing and sending a Bluetooth connection parameter response command based on the target supervision timeout parameter when the first supervision timeout parameter is less than a preset threshold, directly intervenes in overwriting the vulnerable supervision timeout parameter of the target digital key. This fundamentally prevents the target digital key's own vulnerable parameters from taking effect, allowing the target device and the target digital key to still communicate via Bluetooth based on robust target supervision timeout parameters during the connection maintenance phase. Simultaneously, the corresponding Latency, Interval_Min, and Interval_Max parameters are integrated into the command construction and compliance checks are performed to ensure the protocol compliance of the response command, avoiding Bluetooth communication anomalies caused by parameter mismatches. This further enhances the stability of the Bluetooth connection during the connection maintenance phase, effectively implementing a two-layer protection system of initial intervention in connection establishment and precise overwriting during connection maintenance. This effectively solves the problem of disconnection caused by the target digital key actively initiating vulnerable parameter requests during the connection maintenance phase.

[0066] Based on any of the above embodiments, in Embodiment 4 of this application, a compliance check is performed on the target supervision timeout parameter, and the compliance check includes at least one of format compliance check, mathematical compliance check, and behavioral compliance check.

[0067] In this embodiment, the format compliance check verifies whether the numerical storage format and instruction field filling format of the target supervision timeout parameter conform to the format definition requirements of the Bluetooth Low Energy protocol for this parameter, ensuring that the parameter can be correctly parsed by the target digital key. The mathematical compliance check verifies whether the target supervision timeout parameter and its associated Latency, Interval_Min, and Interval_Max parameters satisfy the mathematical constraints stipulated by the Bluetooth Low Energy protocol, ensuring the logical validity of the parameter combination. The behavioral compliance check verifies whether the numerical setting of the target supervision timeout parameter is adapted to the Bluetooth communication behavior characteristics of the target digital key in the system, ensuring that the parameter will not cause communication abnormalities due to conflicts with the target digital key system policy. The compliance check in this step not only includes the target supervision timeout parameter itself but also simultaneously covers its associated Latency, Interval_Min, and Interval_Max parameters, ensuring the comprehensive compliance of the entire set of parameters.

[0068] As an optional implementation, the target device performs compliance checks in a preset order of format compliance check, mathematical compliance check, and behavioral compliance check. First, it verifies whether the field format of the target supervision timeout parameter matches the Bluetooth protocol instruction requirements. After the format check passes, it verifies whether the target supervision timeout parameter satisfies the mathematical constraint formula Timeout>(1+Latency)×Interval_Max×2. After the mathematical check passes, it verifies whether the parameter value is compatible with the Bluetooth connection behavior of the target digital key. As long as at least one of the checks passes, the compliance check process is completed. If the first check fails, it is terminated directly and a parameter anomaly log is recorded.

[0069] As another optional implementation method, the target device dynamically selects the combination of compliance check types based on the current vehicle Bluetooth communication environment. If it is in a normal communication environment, only the core check of mathematical compliance is performed; if it is in a complex and interference-prone communication environment, three checks are performed simultaneously: format compliance check, mathematical compliance check, and behavioral compliance check. The target monitoring timeout parameters and supporting parameters are fully verified. Each check type has an independent judgment standard. Meeting the judgment requirements of the selected type is considered as passing the compliance check.

[0070] If the compliance check passes, a Bluetooth connection parameter response command is constructed and sent to the target digital key based on the target supervision timeout parameter.

[0071] As an optional implementation, after confirming that the compliance check has passed, the target device directly retrieves the verified target monitoring timeout parameters and the corresponding Latency, Interval_Min, and Interval_Max parameters. In accordance with the standard format requirements of the Bluetooth Low Energy protocol for response commands, the entire set of parameters is accurately filled into the corresponding fields of the command. After the command is constructed, the command is sent to the target digital key in real time via the vehicle Bluetooth communication module in the form of wireless air interface. After sending, the parameter sending log and the compliance check results are recorded.

[0072] As another optional implementation, after the target device passes the compliance check, it first encrypts the verified target monitoring timeout parameters and supporting parameters, then fills the encrypted parameters into the specified fields of the Bluetooth connection parameter response command, completes the command construction and performs air interface transmission adaptation and encapsulation, and sends it to the target digital key through the vehicle Bluetooth radio frequency unit. At the same time, command parsing feedback monitoring is enabled. If the target digital key receives abnormal parameter parsing feedback, the unencrypted response command constructed with compliant parameters will be resent.

[0073] For example, in the second Bluetooth connection parameter request command sent by the mobile digital key, the first supervision timeout parameter is 2000ms, which is less than the target device's preset threshold of 4000ms. The target device first selects to simultaneously perform three compliance checks: format, mathematical, and behavioral. In the format compliance check, it verifies that the numerical format of the target supervision timeout parameter 5000ms conforms to the 16-bit numerical field requirements of the Bluetooth protocol; in the mathematical compliance check, it verifies that 5000ms satisfies the mathematical constraint formula Timeout>(1+0)×40×2 corresponding to the matching Latency0, Interval_Min20ms, and Interval_Max40ms; in the behavioral compliance check, it verifies that the value of 5000ms is adapted to the target digital key's system-level Bluetooth connection management strategy and will not cause parameter conflicts. After all three checks pass, the target device fills the verified target supervision timeout parameter 5000ms and the matching parameters into the corresponding fields of the Bluetooth connection parameter response command, completes the command construction, performs air interface encapsulation, and sends it to the target digital key through the vehicle's Bluetooth radio frequency unit. After the target digital key successfully parses the command, it adopts the set of compliant parameters for Bluetooth communication.

[0074] This embodiment performs multiple types of compliance checks before constructing response commands based on target supervision timeout parameters, simultaneously covering the corresponding Latency, Interval_Min, and Interval_Max parameters. This ensures the validity and compliance of parameters from three dimensions: format, mathematical logic, and device behavior adaptation. It effectively avoids Bluetooth connection anomalies or command parsing failures caused by incorrect parameter formats, logical conflicts, or incompatibility with the target digital key's behavior. Furthermore, it supports dynamic selection of check types based on scenarios, balancing the comprehensiveness of compliance verification with execution efficiency. This makes parameter overwriting intervention during the connection maintenance phase more rigorous and reliable, ensuring that Bluetooth connection parameter response commands can be normally received and parsed by the target digital key. This further strengthens the overwriting effect on vulnerable parameters of the target digital key, guaranteeing the stability of the Bluetooth connection from the source of command construction.

[0075] Based on any of the above embodiments, in Embodiment 5 of this application, after sending the first Bluetooth connection parameter request instruction to the target digital key, the process includes: Step S60: In response to the Bluetooth connection parameter update command sent by the target digital key, obtain the second supervision timeout parameter corresponding to the Bluetooth connection parameter update command.

[0076] In this embodiment, the Bluetooth connection parameter update command is a link-layer command sent by the target digital key to the target device to inform it that it has updated the Bluetooth connection parameters and will perform communication according to the new parameters. It belongs to the standard update indication command in the Bluetooth Low Energy protocol and is the core trigger command for the target digital key to achieve covert parameter degradation. The second supervision timeout parameter is a supervision timeout parameter carried in the Bluetooth connection parameter update command, indicating that the target digital key has actually taken effect. If this parameter is a fragile value, it will directly lead to a decrease in Bluetooth connection stability. The Bluetooth connection parameter update command can also simultaneously carry the Latency, Interval_Min, and Interval_Max parameters indicating that the target digital key is effective. When the target device extracts the second supervision timeout parameter, it can simultaneously obtain these supporting parameters, providing a reference for the construction of subsequent renegotiation commands.

[0077] As an optional implementation, the Bluetooth command monitoring module of the target device continuously captures all link layer commands sent by the target digital key. When the protocol feature code of the Bluetooth connection parameter update command is identified, the command is immediately parsed, and the value corresponding to the supervision timeout parameter field in the command is extracted as the second supervision timeout parameter. At the same time, the values ​​of the Latency, Interval_Min and Interval_Max parameters in the command are extracted and temporarily stored in the local cache.

[0078] As another optional implementation, the target device sets up an instruction priority processing mechanism, which lists the Bluetooth connection parameter update instruction as a high-priority instruction. When the instruction is captured, the integrity and transmission correctness of the instruction are first verified. After confirming that no data is lost or tampered with, the second supervision timeout parameter is parsed and extracted. If the instruction is abnormal, it is marked as a parameter degradation warning event and the instruction abnormality information is recorded.

[0079] Step S70: If the second supervision timeout parameter is less than a preset threshold, a safe time window is determined, wherein the safe time window does not coincide with the set request-intensive period.

[0080] In this embodiment, the designated high-demand period is a timeframe pre-defined by the target device based on the Bluetooth communication behavior patterns of the target digital key, during which the target digital key is likely to initiate parameter requests. Typical examples include the first second after Bluetooth connection establishment and within 500ms after the Bluetooth connection parameter update command is sent. The safe time window is a timeframe selected by the target device that does not overlap with the designated high-demand period. It is used to send renegotiation Bluetooth connection parameter request commands, avoiding transaction conflict errors caused by collisions with the target digital key's command sending behavior.

[0081] As an optional implementation, after the target device determines that the second supervision timeout parameter is less than the preset threshold, it directly retrieves the local preset list of dense request periods (such as [0ms, 1000ms], [update command sending time, update command sending time + 500ms]), selects a fixed-length safe time window from the time period outside the list, such as 1000ms to 1500ms after the update command is sent, records the start and end times of the window after selection, and starts timing.

[0082] As another optional implementation, after the target device determines that the second supervision timeout parameter is less than the preset threshold, it first monitors the command sending frequency of the target digital key in real time, dynamically identifies whether it is currently in a set request-intensive period, and if so, waits until the intensive period ends, and then determines a safe time window of dynamic duration based on the real-time monitoring results, such as a continuous 200ms period when the command sending frequency is lower than the preset threshold, to ensure that the target digital key does not have high-frequency parameter request behavior within the window.

[0083] Step S80: Within the security time window, construct and send a first Bluetooth connection parameter request command to the target digital key based on the target supervision timeout parameter.

[0084] In this embodiment, the core objective is to avoid the period during which the target digital key sends commands intensively, to prevent errors such as LL_STATUS_ERROR_TRANSACTION_COLLISION caused by LL_CONNECTION_PARAM_REQ command collisions, and to ensure that the renegotiation command can be effectively received by the target digital key.

[0085] As an optional implementation, after the target device starts within the safe time window, it immediately retrieves the locally preset target monitoring timeout parameters and the corresponding Latency, Interval_Min and Interval_Max parameters, constructs a first Bluetooth connection parameter request command according to the instruction format of the Bluetooth Low Energy protocol, and sends the command to the target digital key in real time through the vehicle Bluetooth communication module after construction. After sending, it monitors the command reception feedback within the remaining time of the safe time window to confirm whether the transmission was successful.

[0086] As another optional implementation, within the safe time window, the target device first performs Bluetooth protocol mathematical constraint verification on the target supervision timeout parameter and the corresponding Latency, Interval_Min and Interval_Max parameters. After the verification is successful, it constructs the first Bluetooth connection parameter request command and performs air interface transmission encapsulation. Then, it sends the command to the target digital key twice (with an interval of 50ms) to reduce the probability of single transmission failure. If no feedback is received after two transmissions, a renegotiation failure log is recorded.

[0087] Optionally, if the second supervision timeout parameter is greater than or equal to a preset threshold, Bluetooth communication is performed based on the second supervision timeout parameter.

[0088] For example, the mobile digital key does not adopt the overwrite parameters of the target device and directly sends a Bluetooth connection parameter update command. The command carries a second supervision timeout parameter of 2000ms. The target device's preset threshold is 4000ms. If 2000ms is less than the preset threshold, a fallback renegotiation process is triggered. The target device retrieves a list of set request-intensive periods and determines that 0-500ms after the target digital key sends the update command is the intensive period. Then, it selects 500ms-1000ms as a safe time window and starts timing. When the timing enters the 500ms safe time window, the target device retrieves the target supervision timeout parameter of 5000ms and the corresponding parameters of Latency of 0, Interval_Min of 20ms, and Interval_Max of 40ms. After verifying that it conforms to the mathematical constraints of the Bluetooth protocol, it constructs a first Bluetooth connection parameter request command. After encapsulating the command over the air, it sends it to the target digital key through the vehicle's Bluetooth radio frequency unit. The target digital key successfully receives and parses the command during a non-request-intensive period, adopts the target supervision timeout parameter, and resumes stable Bluetooth communication with the target device.

[0089] This embodiment responds to the covert parameter update command of the target digital key, extracts the second supervision timeout parameter and determines whether it has deteriorated, then specifically determines a safe time window to avoid peak request periods, and finally retransmits the first Bluetooth connection parameter request command carrying the target supervision timeout parameter within the window, forming a three-layer protection system of "initial intervention, overwrite intervention, and fallback renegotiation". This mechanism solves the covert degradation problem caused by the target digital key skipping the REQ-RSP process and directly updating parameters, while avoiding the risk of command collision from a time dimension, ensuring the effective delivery of the renegotiation command, and further blocking the technical vulnerability of the target digital key disconnection. In addition, the corresponding Latency, Interval_Min, and Interval_Max parameters are simultaneously verified during the renegotiation process to ensure the protocol compliance of the command, forming a closed loop for parameter adjustment throughout the entire cycle, and maximizing the stability of the Bluetooth connection.

[0090] Based on any of the above embodiments, in Embodiment Six of this application, after sending the first Bluetooth connection parameter request instruction to the target digital key corresponding to the Bluetooth establishment event, the process includes: step S91 and / or step S92.

[0091] Step S91: In response to the device control command sent by the target digital key, construct a third Bluetooth connection parameter request command to adjust the Bluetooth connection interval, and send the third Bluetooth connection parameter request command to the target digital key.

[0092] Step S92: In response to the device control command sent by the target digital key, construct a physical layer mode request command to adjust the physical layer mode, and send the physical layer mode request command to the target digital key.

[0093] In this embodiment, the device control command is a command sent by the target digital key to the target device to implement specific control functions of the target device. These commands require high Bluetooth connection stability, such as remote parking and remote unlocking. The third Bluetooth connection parameter request command is a link layer command constructed by the target device to request the target digital key to adjust the Bluetooth connection interval. Its core functionality involves modifying the Interval_Min and Interval_Max parameters to adjust the connection interval, and it is a standard command of the Bluetooth Low Energy protocol. The physical layer mode request command is a link layer command constructed by the target device to request the target digital key to switch the Bluetooth physical layer transmission mode. This is a dedicated command for adjusting the physical layer mode in the Bluetooth Low Energy protocol. The third Bluetooth connection parameter request command, the physical layer mode request command, or both types of commands can be constructed separately. The target device selects the appropriate method based on the functional requirements of the target device control command and the current Bluetooth communication status. The sending method matches the type of command constructed. If a single type of command is constructed, it is sent separately; if two types of commands are constructed, they are sent synchronously or sequentially to ensure that the target digital key can accurately receive and parse the corresponding command, enabling targeted adjustment of Bluetooth parameters.

[0094] As an optional implementation, after receiving the target device control command sent by the target digital key, the target device first identifies the function type of the command. If it is a command with extremely high requirements for Bluetooth connection reliability, such as remote parking, it simultaneously constructs a third Bluetooth connection parameter request command to adjust the Bluetooth connection interval and a physical layer mode request command to adjust the physical layer mode. If it is a regular remote control command, only the third Bluetooth connection parameter request command is constructed, with the Interval_Min and Interval_Max parameters directly set to preset short interval values ​​during construction. The physical layer mode request command is constructed according to the preset target physical layer mode parameters. The target device encapsulates the constructed third Bluetooth connection parameter request command and / or physical layer mode request command according to the Bluetooth Low Energy protocol's air interface transmission specifications and sends it to the target digital key via the vehicle's Bluetooth radio frequency unit in a directional transmission manner. After transmission, the Bluetooth air interface transmission feedback signal is monitored in real time to confirm whether the command has been successfully delivered. There is no additional retransmission mechanism; only the transmission result is recorded.

[0095] As an alternative implementation, after responding to the target device control command, the target device first checks the current Bluetooth connection interval parameters and physical layer mode parameters. If the current Bluetooth connection interval is the original normal value and the physical layer mode is high-speed mode, both types of commands are constructed simultaneously. If the current connection interval is already a short interval value, only the physical layer mode request command is constructed. If the current physical layer mode is already the target robust mode, only the third Bluetooth connection parameter request command is constructed. During the construction process, the values ​​of Interval_Min and Interval_Max are fine-tuned based on the real-time signal quality of the vehicle's Bluetooth. The target device sorts the constructed commands according to priority, setting the third Bluetooth connection parameter request command as high priority and the physical layer mode request command as low priority. The high-priority third Bluetooth connection parameter request command is sent first. After receiving the reception confirmation feedback from the target digital key, the physical layer mode request command is sent next. If no reception feedback is received within a preset time, a retransmission operation is performed on the unsuccessfully sent command. If the retransmission fails, the command transmission is marked as abnormal and logged.

[0096] For example, a user sends a remote parking control command to a target device via a mobile digital key. Upon receiving the command, the target device first identifies it as a high-reliability control command. Then, it checks the current Bluetooth connection status, finding that Interval_Min is 20ms, Interval_Max is 40ms, and the physical layer mode is LE 2M. Therefore, it simultaneously constructs a third Bluetooth connection parameter request command and a physical layer mode request command: the third Bluetooth connection parameter request command sets Interval_Min to 7.5ms and Interval_Max to 15ms, while the physical layer mode request command requests a switch to LE 1M mode. The target device encapsulates both commands according to the Bluetooth protocol specification, sending the third Bluetooth connection parameter request command with high priority first. After receiving confirmation from the target digital key, it then sends the physical layer mode request command. Both commands are successfully delivered to the mobile digital key.

[0097] This embodiment, by responding to the target device control commands of the target digital key, constructs and sends a third Bluetooth connection parameter request command to adjust the Bluetooth connection interval and / or a physical layer mode request command to adjust the physical layer mode. This achieves differentiated control of Bluetooth parameters in high-reliability target device control scenarios, compensating for the inability of conventional Bluetooth parameters to adapt to the high real-time and high-reliability target device control requirements. Furthermore, it allows the target device to flexibly adjust its strategy based on the target device control command type and the current Bluetooth communication status, balancing the targeted nature and flexibility of parameter control. Simultaneously, by constructing and sending commands based on the standard Bluetooth protocol, it ensures the compliance and resolvability of the commands, effectively improving the Bluetooth connection stability during the transmission of target device control commands, increasing the density of Bluetooth connection events per unit time, and enhancing the anti-interference capability of Bluetooth communication. This provides a stable Bluetooth communication link guarantee for the smooth implementation of key target device control functions such as remote parking.

[0098] Based on any of the above embodiments, in Embodiment 7 of this application, the construction of a third Bluetooth connection parameter request instruction for adjusting the Bluetooth connection interval includes: Step S911: Construct the third Bluetooth connection parameter request instruction based on the target Bluetooth connection interval, wherein the target Bluetooth connection interval is less than the original Bluetooth connection interval.

[0099] In this embodiment, the target Bluetooth connection interval is a short Bluetooth connection interval pre-set by the target device to adapt to high-reliability target device control scenarios. Its dynamic range is defined by the matching target Interval_Min and target Interval_Max, both of which are short values ​​verified by engineering, primarily used to increase the density of Bluetooth connection events per unit time. The original Bluetooth connection interval is the basic Bluetooth connection interval used by the target device and the target digital key in conventional Bluetooth communication scenarios. It is defined by the original Interval_Min and original Interval_Max, and is a general parameter that balances conventional communication response speed with the power consumption of the vehicle / target digital key device. Furthermore, the target Interval_Min is smaller than the original Interval_Min, and the target Interval_Max is smaller than the original Interval_Max, thus ensuring that the overall target Bluetooth connection interval is shorter than the original Bluetooth connection interval. When constructing the instruction in this step, the parameters corresponding to the target Bluetooth connection interval are accurately filled into the specified fields of the third Bluetooth connection parameter request instruction. The remaining protocol format of the instruction follows the standard requirements of the Bluetooth Low Energy protocol.

[0100] As an optional implementation, when the target device needs to construct a third Bluetooth connection parameter request command, it directly retrieves the target Interval_Min and target Interval_Max parameters corresponding to the locally preset target Bluetooth connection interval. At the same time, it uses the Latency and monitoring timeout parameters that are associated with the Bluetooth connection interval. According to the format requirements of the Bluetooth Low Energy protocol for the third Bluetooth connection parameter request command, the above parameters are filled into the corresponding fields of the command to complete the command construction without adjusting the values ​​of other parameters.

[0101] As another optional implementation, the target device first retrieves the locally preset target Bluetooth connection interval base value, and then fine-tunes the specific values ​​of target Interval_Min and target Interval_Max according to the real-time signal quality of the current vehicle Bluetooth. When the signal quality is poor, the difference between the two values ​​is appropriately reduced, and when the signal quality is good, the base value is maintained. After fine-tuning, it is verified that the target Bluetooth connection interval is still less than the original Bluetooth connection interval. Then, it is combined with compliant matching parameters to fill the corresponding fields of the third Bluetooth connection parameter request command, completes the command construction, and records the parameter fine-tuning information.

[0102] For example, a user sends a remote parking control command to the target device via a mobile phone digital key. After the target device responds, it needs to construct a third Bluetooth connection parameter request command. Its locally preset original Bluetooth connection intervals are original Interval_Min 20ms and original Interval_Max 40ms, while the target Bluetooth connection intervals are target Interval_Min 7.5ms and target Interval_Max 15ms, with all target values ​​being less than the original values. The target device directly retrieves the target Interval_Min and target Interval_Max parameters, and uses the accompanying parameters Latency0 and target monitoring timeout parameter 5000ms. According to the Bluetooth Low Energy protocol standard format, these parameters are filled into the corresponding fields of the third Bluetooth connection parameter request command, quickly completing the command construction and preparing for subsequent command sending and Bluetooth connection interval adjustment.

[0103] This embodiment constructs a third Bluetooth connection parameter request command based on a target Bluetooth connection interval smaller than the original Bluetooth connection interval. This achieves precise shortening of the Bluetooth connection interval in high-reliability target device control scenarios. By limiting the actual Bluetooth connection interval to a shorter dynamic range through dual parameters of target Interval_Min and target Interval_Max, the actual Bluetooth connection interval is confined, effectively increasing the density of Bluetooth connection events per unit time. This provides more retry opportunities for communication between the vehicle and the target digital key when signal quality fluctuates, reducing the probability of Bluetooth disconnection caused by a single communication interruption. Simultaneously, it supports fine-tuning of target parameters based on real-time signal quality, making the adjustment of the Bluetooth connection interval more adaptable to the actual communication environment. This further improves the stability of Bluetooth communication in high-reliability scenarios and enhances the real-time performance and reliability of control commands for critical target devices such as remote parking.

[0104] Based on any of the above embodiments, in Embodiment 8 of this application, the physical layer mode request instruction for adjusting the physical layer mode includes: Step S921: Construct the physical layer mode request instruction based on the target physical layer mode, wherein the level of the target physical layer mode is lower than the level of the original physical layer mode.

[0105] In this embodiment, the target physical layer mode is the Bluetooth Low Energy physical layer transmission mode selected by the target device to adapt to the high-reliability target device control scenario. It is a low-level physical layer mode with stronger resistance to multipath and obstruction, and is suitable for the complex wireless communication environment of vehicles. It is typically the LE 1M mode. The original physical layer mode is the basic physical layer transmission mode used by the target device and the target digital key in a conventional Bluetooth communication scenario. It is a high-level physical layer mode that focuses on data transmission rate, typically the LE 2M mode. The level of the physical layer mode is classified according to the transmission rate and symbol synchronization stability requirements of the physical layer in the Bluetooth Low Energy protocol. The higher the transmission rate and the more stringent the symbol synchronization requirements, the higher the mode level, and vice versa. The lower-level physical layer mode has a longer symbol period and is more robust to communication in vehicle scenarios with metal body reflections and human tissue obstruction. When constructing the instruction in this step, only the core field of the mode identifier in the physical layer mode request instruction is replaced with the value corresponding to the target physical layer mode. The remaining protocol fields follow the standard configuration requirements of the Bluetooth Low Energy protocol.

[0106] As an optional implementation, when the target device needs to construct a physical layer mode request command, it directly retrieves the protocol identifier value corresponding to the locally preset target physical layer mode, fills the identifier value into the physical layer mode specified field of the command according to the format requirements of the Bluetooth Low Energy protocol for physical layer mode request commands, and uses the default configuration of the protocol for the remaining fields, thus quickly completing the construction of the physical layer mode request command without adjusting other parameters.

[0107] As another optional implementation, the target device first detects the actual physical layer mode of the current communication with the target digital key through the vehicle Bluetooth module. After confirming that it is the original high-level physical layer mode, it then verifies the adaptability of the target low-level physical layer mode in combination with the actual environment of the current vehicle wireless channel (such as signal obstruction and interference intensity). After the verification is successful, the protocol identifier value of the target physical layer mode is extracted and filled into the corresponding field of the physical layer mode request command to complete the command construction and record the current channel environment and mode matching information.

[0108] For example, a user sends a remote parking control command to the target device via a mobile digital key. Upon response, the target device needs to construct a Physical Layer Mode Request command. Its normal communication with the target digital key uses the LE 2M high-level physical layer mode. To meet the high-reliability communication requirements of remote parking, the preset target physical layer mode is LE 1M low-level mode, with LE 1M being a lower level than LE 2M. The target device first detects that the current actual communication mode is LE 2M, then confirms the presence of a channel environment with metal obstructions from the vehicle body. After verifying that the LE 1M mode is compatible with this environment, it extracts the protocol identifier value corresponding to the LE 1M mode and fills it into the physical layer mode specified field of the physical layer mode request command according to the Bluetooth Low Energy protocol standard format. The remaining fields use the default protocol configuration, completing the construction of the physical layer mode request command.

[0109] This embodiment constructs a physical layer mode request command based on a target physical layer mode with a lower level than the original physical layer mode. This achieves targeted downgrading and adjustment of the physical layer transmission mode in high-reliability target device control scenarios, avoiding the symbol synchronization instability problem that easily occurs in the original high-level physical layer mode in complex vehicular channel environments. The lower-level target physical layer mode, with its longer symbol period and stronger resistance to multipath and obstruction, effectively improves the robustness of wireless signal transmission and reduces packet loss caused by channel interference and physical obstruction. Simultaneously, only the core mode identifier field is replaced during command construction, adhering to the Bluetooth protocol standard configuration to ensure that the command can be correctly parsed by the target digital key. This, combined with the adjustment of the target Bluetooth connection interval, strengthens the stability of Bluetooth communication in high-reliability scenarios from two dimensions: physical layer transmission mode and connection event density.

[0110] Based on any of the above embodiments, in Embodiment 9 of this application, after sending the third Bluetooth connection parameter request instruction to the target digital key, the method further includes: responding to the execution completion event or preset timeout event of the device control instruction, constructing a fourth Bluetooth connection parameter request instruction to restore the original Bluetooth connection interval, and sending the fourth Bluetooth connection parameter request instruction to the target digital key so that the target digital key and the target device can resume Bluetooth communication based on the original Bluetooth connection interval.

[0111] In this embodiment, the device control command execution completion event is triggered when the target device detects that all device control functions corresponding to the device control command sent by the target digital key have been executed. This event is triggered by the function execution completion signal fed back by the vehicle control system and is the core triggering condition for parameter recovery. The preset timeout event is an event triggered by the target device based on the normal execution time of the target device control command to avoid the parameter configuration from being effective for a long time in high-reliability scenarios. The preset timeout is determined according to the engineering measured timeout of different target device control commands. The fourth Bluetooth connection parameter request command is a link layer command constructed by the target device to request the restoration of the original Bluetooth connection interval from the target digital key. The core is to fill the original Interval_Min and original Interval_Max parameters into the corresponding fields.

[0112] As an optional implementation, after the target device detects a completion event or a preset timeout event of the target device control command, it retrieves the previously recorded parameter adjustment type locally. Based on the adjustment type, it directly retrieves the parameters of the original Bluetooth connection interval. Following the instruction format requirements of the Bluetooth Low Energy protocol, it fills the corresponding parameters into the fourth Bluetooth connection parameter request instruction, completing the instruction construction. The remaining protocol fields use the standard default configuration. The target device encapsulates the constructed fourth Bluetooth connection parameter request instruction according to the Bluetooth Low Energy protocol's air interface transmission specifications and sends it to the target digital key via the Bluetooth radio frequency unit in a directional transmission manner. After transmission, it monitors the air interface transmission feedback signal in real time to confirm whether the instruction was successfully delivered.

[0113] As an alternative implementation, after the target device triggers the parameter recovery process, it first checks whether the current Bluetooth connection interval communicating with the target digital key is the adjusted target parameter. Once it confirms that the parameter is in an adjusted state, it retrieves the original parameter and performs a basic Bluetooth protocol compliance check on it. After the check passes, it constructs a corresponding fourth Bluetooth connection parameter request command based on the actual adjustment type. After construction, it records the parameter information and trigger event type of the recovery command. The target device sorts the constructed recovery commands according to communication priority, setting the fourth Bluetooth connection parameter request command as a high priority and sending the high-priority recovery command first. After receiving the acceptance confirmation feedback from the target digital key, it then sends the next-priority recovery command.

[0114] Optionally, after sending the physical layer mode request instruction to the target digital key, the method further includes: in response to the execution completion event or preset timeout event of the device control instruction, constructing a second physical layer mode request instruction to restore the original physical layer mode, and sending the second physical layer mode request instruction to the target digital key, so that the target digital key and the target device resume Bluetooth communication based on the original physical layer mode.

[0115] In this embodiment, the second physical layer mode request instruction is a link layer instruction constructed by the target device to request the restoration of the original physical layer mode from the target digital key. The core of this instruction is to fill the corresponding field with the protocol identifier value corresponding to the original physical layer mode. The restoration instruction is constructed according to the previously sent parameter adjustment instruction type. If only the Bluetooth connection interval was adjusted, only the fourth Bluetooth connection parameter request instruction is constructed; if only the physical layer mode was adjusted, only the second physical layer mode request instruction is constructed; if both were adjusted, both types of instructions are constructed simultaneously.

[0116] As an optional implementation, after the target device detects a completion event or a preset timeout event of the target device control command, it retrieves the previously recorded parameter adjustment type locally. Based on the adjustment type, it directly retrieves the protocol identifier value of the original physical layer mode. Following the instruction format requirements of the Bluetooth Low Energy protocol, it fills the corresponding parameters into the specified fields of the second physical layer mode request command, completing the command construction. The remaining protocol fields use the standard default configuration. The target device encapsulates the constructed second physical layer mode request command according to the Bluetooth Low Energy protocol's air interface transmission specifications and sends it to the target digital key via the vehicle's Bluetooth radio frequency unit in a directional transmission manner. After transmission, it monitors the feedback signal of the air interface transmission in real time to confirm whether the command has been successfully delivered.

[0117] As an alternative implementation, after the target device triggers the parameter recovery process, it first checks whether the physical layer mode currently communicating with the target digital key is the adjusted target parameter. After confirming that the parameter is in an adjusted state, it retrieves the original parameter and performs a basic compliance check of the Bluetooth protocol on the original parameter. After the check passes, it constructs the corresponding second physical layer mode request command according to the actual adjustment type. After construction, it records the parameter information and trigger event type of the recovery command. The target device sorts the constructed recovery commands according to communication priority, setting the fourth Bluetooth connection parameter request command as high priority and the second physical layer mode request command as low priority. It sends the high-priority recovery command first, and after receiving the reception confirmation feedback from the target digital key, it sends the low-priority recovery command. If the reception feedback for a certain command is not received within a preset short period of time, a retransmission operation is performed on the command. If the retransmission fails, the parameter recovery is marked as abnormal and recorded in the log, while the current Bluetooth communication parameters are continuously maintained.

[0118] For example, after a user sends a remote parking control command to the target device via a mobile digital key, the target device constructs and sends a third Bluetooth connection parameter request command and a physical layer mode request command, adjusting the Bluetooth connection interval to 7.5ms-15ms and switching the physical layer mode to LE 1M mode. When the target device completes the remote parking action, the vehicle control system sends a parking completion signal to the target device, triggering the execution completion event of the target device's control command. The target device then retrieves the previous parameter adjustment record, confirming that both the Bluetooth connection interval and physical layer mode have been adjusted. It then retrieves the original Bluetooth connection interval (20ms-40ms) and the original physical layer mode (LE 2M) parameters, constructing a fourth Bluetooth connection parameter request command and a second physical layer mode request command respectively. The target device sends the fourth Bluetooth connection parameter request command as a high priority. After receiving confirmation from the target digital key, it then sends the second physical layer mode request command. Once both commands are successfully delivered, the target digital key adopts the original parameters, and regular Bluetooth communication with the target device resumes based on the original Bluetooth connection interval and the original physical layer mode. If the preset timeout period of more than 3 minutes is not completed during the remote parking process, the target device will trigger a preset timeout event, construct and send a recovery command according to the same process as above, and complete the parameter recovery.

[0119] This embodiment, by responding to the completion event or preset timeout event of the target device control command, constructs and sends a fourth Bluetooth connection parameter request command and / or a second physical layer mode request command, achieving accurate and dynamic recovery of Bluetooth parameters in high-reliability scenarios. This avoids the increased power consumption of the vehicle Bluetooth module and the target digital key device caused by short Bluetooth connection intervals and the long-term effectiveness of low-level physical layer modes, balancing the communication stability requirements of high-reliability target device control scenarios with the power consumption optimization requirements of conventional communication scenarios. Simultaneously, the recovery command is constructed according to the actual parameter adjustment type, making parameter recovery more targeted and avoiding Bluetooth communication fluctuations caused by unnecessary command transmissions. The priority-based transmission method improves the success rate of recovery command delivery, forming a closed-loop control logic of "high-reliability scenario triggering parameter adjustment - function completion / timeout triggering parameter recovery," thus perfecting the scenario-based Bluetooth parameter management system. This further enhances the practicality, adaptability, and rationality of the entire target digital key Bluetooth control solution, ensuring stable communication for key target device control functions while also considering the daily power consumption of the device.

[0120] Based on any of the above embodiments, in Embodiment Ten of this application, please refer to... Figures 2 to 6 In order to help understand the technical concept or technical principle of the digital key control method after combining this embodiment with the above embodiments, this embodiment describes the overall execution content.

[0121] It should be noted that during daily use, the terminal devices (including iPhones and Apple Watches) used as digital car key terminals exhibit the following three types of connection anomalies that affect functional safety and user experience: False Lock: The vehicle locks itself while the user is moving around the vehicle (e.g., getting out and walking around to the rear of the vehicle to retrieve something) and has not yet left the effective operating area. This phenomenon usually occurs shortly after the door is closed, and the underlying cause is an unexpected interruption of the BLE connection during this period, causing the system to trigger the lock according to preset logic.

[0122] Fail-to-Lock-on-Departure: The user has walked away from the vehicle, but the vehicle has not entered the locked state for an extended period. This phenomenon often occurs when the connection is interrupted before the door is fully closed or other signal strength requirements are met, resulting in the failure to simultaneously meet the necessary locking conditions of "door fully closed, reaching a certain signal strength requirement, and BLE disconnection".

[0123] Stuck-at-Gate: When a user approaches a vehicle intending to unlock it without any interaction, the vehicle does not respond, and the user must wait a while at the vehicle before the operation can be completed. One reason for this phenomenon is that the connection is interrupted at the initial stage of establishment, preventing the system from completing the authentication and command issuance process, resulting in a noticeable delay.

[0124] Although the three phenomena described above are different, they all point to the same technical root: the configuration preferences of terminal devices for key link parameters during the BLE connection lifecycle can have a certain negative impact on connection stability. The vehicle needs to perform appropriate coordinated control of various connection parameters in order to maintain a stable BLE connection between the terminal device and the vehicle.

[0125] By summarizing and analyzing the interaction behavior of multiple generations of terminal devices, including different models of iPhones and Apple Watches, with various in-vehicle platforms, it can be confirmed that they exhibit several stable and reproducible behavioral characteristics at the BLE protocol layer. These characteristics do not rely on external documentation and all originate from the parsing and identification of standard air interface PDU fields or vehicle-side BLE logs: Feature 1: A shorter supervisionTimeout value is used in the initial stage of connection establishment.

[0126] After the terminal device completes the connection process with the vehicle, the supervisionTimeout field in the vehicle's BLE LL_CONNECTION_COMPLETE_EVENT log will have a relatively small value (typically 720ms). This value is lower than the baseline reference value used by most in-vehicle systems, making the connection more likely to be judged as a permanent interruption when encountering brief communication fluctuations. The initial source of this configuration is the Timeout parameter of 720ms in the CONNECT_IND PDU initiated by the terminal device.

[0127] Feature 2: During the connection maintenance phase, a supervisionTimeout shortening request is proactively initiated.

[0128] To maintain a stable connection, the vehicle-side BLE typically initiates a connection parameter update request after a period of time following connection establishment, changing the supervisionTimeout parameter to a larger value (typically 5000ms). After the connection has been running stably for a period of time, the terminal device will proactively send the LL_CONNECTION_PARAM_REQ command to request again that the supervisionTimeout be adjusted to a smaller value (commonly 2000ms). This behavior also occurs when there is no active user interaction and is a connection management strategy at the iOS system level.

[0129] Feature 3: The ChSel field is always 0, indicating that the CSA#2 frequency hopping algorithm is not enabled.

[0130] Comparing the PDUHeader fields of the vehicle-mounted broadcast packet (ADV_IND) and the terminal device connection indication packet (CONNECT_IND), it can be confirmed that the vehicle-mounted device sets ChSel to 1 in the broadcast (declaring support for LE Channel Selection Algorithm #2), while the terminal device always sets ChSel to 0 in CONNECT_IND. According to the Bluetooth CoreSpecification, this setting indicates that the initiator (terminal device) does not support CSA#2 and will continue to use CSA#1, resulting in relatively weak robustness in environments with periodic interference.

[0131] Feature 4: Tends to switch to LE 2M PHY mode at high frequencies.

[0132] The HCI_BLE_PHY_UPDATE_COMPLETE_EVENT record frequently appears in the vehicle-side BLE logs, and the rxphy and txphy fields are often 2 (corresponding to LE 2M PHY). This indicates that after the connection is established, the terminal device actively requests and continuously maintains the LE 2M physical layer rate. While this mode is beneficial for improving data throughput, it places higher demands on symbol synchronization stability under typical automotive channel conditions such as metal body reflections and human tissue obstruction.

[0133] Based on this, this embodiment, without modifying the iOS system or adding hardware, makes the connection parameter configuration more suitable for the vehicle's physical environment and functional requirements through protocol layer collaboration.

[0134] Reference Figure 2 The execution flow of the three-layer intervention mechanism for Bluetooth connection parameters of the digital key, as shown in this flowchart, is as follows: After the target device establishes a Bluetooth communication link with the target digital key, it first constructs a first Bluetooth connection parameter request command based on the target supervision timeout parameter and sends it to the target digital key. Subsequently, when the target digital key sends a second Bluetooth connection parameter request command, the target device will determine whether the first supervision timeout parameter carried in the command is less than a preset threshold. If it is not less than the threshold, it constructs a Bluetooth connection parameter response command based on the first supervision timeout parameter, and then delays before constructing and sending the first Bluetooth connection parameter request based on the target supervision timeout parameter. If the threshold is less than the threshold, it directly constructs a Bluetooth connection parameter response command based on the target supervision timeout parameter. This achieves full-cycle protection of Bluetooth connection parameters.

[0135] This embodiment designs a phased response strategy with time constraints based on the behavioral characteristics of terminal devices at different stages of the connection lifecycle: In the first stage (triggered as soon as possible after connection establishment): proactive parameter updates seize the initiative. After the vehicle-mounted terminal completes connection establishment confirmation (e.g., connection established), and before the terminal device initiates its first LL_CONNECTION_PARAM_REQ, the specific characteristic channel of the mobile digital key is subscribed to. The controller then autonomously constructs and sends LL_CONNECTION_PARAM_REQ, requesting that the supervisionTimeout be set to a more robust reference value. This action aims to "defend before problems occur," preventing the terminal device from running for extended periods with vulnerable values ​​such as 720ms or 2000ms. In the second stage (when a request is received from the terminal device): the timeout value is overwritten in the RSP, shifting from a passive to an active approach. When the controller captures an LL_CONNECTION_PARAM_REQ sent by the terminal device and parses its timeout field to find it is less than the preset robustness threshold, it no longer simply sends LL_REJECT_EXT_IND. Instead, when constructing the LL_CONNECTION_PARAM_RSP response, it directly writes the robust value into the timeout field of the response packet. This operation strictly follows the protocol format definition, without adding fields or changing the process; it only performs engineering intervention by assigning values ​​to existing fields. In the third phase (verification after RSP takes effect): a delayed renegotiation mechanism ensures the final effect. If, within the predetermined time window, the controller observes that the connection event is still executed according to the original fragile timeout value (i.e., the RSP overwrite was not accepted by the terminal device), it starts a timer. After a reasonable delay, it re-initiates LL_CONNECTION_PARAM_REQ to repeatedly request the robust parameters. This mechanism forms a closed loop of "request—response—verification—re-request," ensuring that the policy is ultimately implemented. While related technologies stop at a binary decision of "whether to accept the request", this solution constructs a continuous control loop of "identification, intervention, verification, and re-intervention", which has both process controllability and result guarantee.

[0136] Furthermore, refer to Figure 3The digital key Bluetooth connection parameter responsive intervention process shown in this flowchart is as follows: After the target digital key sends the second Bluetooth connection parameter request command, the target device first extracts the first supervision timeout parameter carried by the command, and then determines whether the parameter is less than a preset threshold: if it is not less than the threshold, the target device directly constructs a Bluetooth connection parameter response command based on the first supervision timeout parameter; if it is less than the threshold, the target device performs a compliance check on the target supervision timeout parameter, where the target supervision timeout parameter field is a standard 2-byte field, and the protocol only defines the mode and does not limit the value; the compliance check is divided into a digital compliance check (checking whether the target supervision timeout parameter conforms to the Core Spec mathematical constraints) and a behavioral compliance check (checking whether no new commands are added, the connection is interrupted, the process is modified, and whether only the existing field assignments are changed). After the compliance check is completed, the target device constructs and sends a Bluetooth connection parameter response command based on the target supervision timeout parameter.

[0137] The strategies in this embodiment all adhere to the principle of "minimal intrusion and maximum compatibility." RSP overwrite strategy compatibility guarantee: LL_CONNECTION_PARAM_RSP is a standard protocol packet; the write value of its timeout field is fully compliant as long as it meets the mathematical constraint specified by the protocol (Timeout > (1 + Latency) × Interval_Max × 2). The robust value set in this solution has been verified by engineering and consistently meets this constraint. Anti-collision mechanism for delayed renegotiation: The start time and waiting period of the renegotiation timer are both avoided during peak periods when terminal devices may initiate requests (such as the first second after connection establishment), preventing errors such as LL_STATUS_ERROR_TRANSACTION_COLLISION caused by LL_CONNECTION_PARAM_REQ collisions. Atomicity of special scenario strategies: Connection intervals and PHY changes related to remote parking are executed through standard HCI commands and strictly follow the protocol handshake process, ensuring that operations are traceable, undone, and do not damage the connection state machine. Without modifying any behavior of the terminal device, introducing proprietary protocols, or violating MFi certification requirements, the vehicle-mounted terminal can achieve substantial optimization capabilities for connection quality.

[0138] Furthermore, refer to Figure 4The full-cycle control process of the digital key Bluetooth connection parameters shown in this flowchart starts from "Connection established" and is divided into two parallel processing paths: one path waits for Service Discovery Complete and Notify Enabled Complete, and then enters the judgment of "Service discovery and notification are ready". If the judgment result is no, it continues to wait. If the judgment result is yes, it initiates the first CONN_PARAM_REQ, that is, the first Bluetooth connection parameter request command, which is a preemptive optimization; the other path enters the judgment of "whether a second Bluetooth connection parameter request command has been received from the terminal device". If the judgment result is yes, it executes the compliance verification process of the target supervision timeout parameter in the Bluetooth connection parameter response command. Afterwards, whether it is the first Bluetooth connection parameter request command initiated through preemptive optimization or the compliance verification process of the target supervision timeout parameter in the Bluetooth connection parameter response command, it will enter the judgment of "whether the negotiation was successful": if the negotiation is successful, it will further judge that "the supervision timeout parameter after negotiation is greater than or equal to the preset threshold". If this condition is met, the process ends; if not, a delay retry is triggered and the unified delay retry interface is entered. If the negotiation fails, the unified delay retry interface is entered directly to complete the delay retry scheduling of the entire process.

[0139] Furthermore, refer to Figure 5 This embodiment addresses specific operations where users demand strong real-time performance and high reliability from vehicle functions. The solution provides enhanced parameter control capabilities, the core of which is to dynamically improve the fault tolerance margin of critical links without affecting compatibility in general scenarios. After receiving the device control command, the target device executes two operations in parallel: physical layer mode downgrading and Bluetooth connection interval compression. In the physical layer mode downgrading process, it first determines whether the current physical layer mode is the original physical layer mode. If the current physical layer mode is the original physical layer mode, a physical layer mode request command is sent to switch to the target physical layer mode; if the current physical layer mode is not the original physical layer mode, it waits to exit. In the Bluetooth connection interval compression process, a Bluetooth connection parameter request command is constructed and sent based on the target Bluetooth connection interval to reduce the Bluetooth connection interval. Afterwards, in response to the device control command execution completion event or a preset timeout event, the original Bluetooth connection interval and / or the original physical layer mode are restored.

[0140] For example, consider a remote parking scenario. When the vehicle controller notifies that "remote parking command has been activated," the onboard BLE controller immediately initiates LL_CONNECTION_PARAM_REQ, adjusting connInterval to a shorter range (e.g., 7.5ms–15ms). This increases the density of connection events per unit time, providing more retry opportunities when signal quality fluctuates, and reducing the probability of disconnection due to a single interruption. This adjustment only lasts during the validity period of the remote parking command and automatically reverts to the normal value after it ends. Secondly, there is PHY mode degradation in remote parking scenarios. In the same remote parking scenario, if the current PHY mode is LE 2M, the controller will simultaneously initiate LL_PHY_REQ, requesting a switch to LE 1M. The LE 1M mode has a longer symbol period and stronger multipath resistance, making it more suitable for remote command transmission with stringent reliability requirements. This switch is a temporary, scenario-bound operation, automatically restoring the original PHY configuration after the command ends. All special scenario strategies use the vehicle status signal as the sole trigger source, without relying on complex assessments of wireless channel quality, ensuring engineering feasibility and deployment determinism.

[0141] Furthermore, refer to Figure 6 This embodiment constructs a lightweight, low-overhead collaborative control engine within the vehicle controller. Its core consists of four modules: a continuous state monitoring module, serving as the core input source, continuously parses four types of key commands: Bluetooth connection establishment commands, Bluetooth connection parameter request commands, Bluetooth connection parameter update commands, and physical layer mode update commands. Based on these commands, it outputs structured state tags and transmits them to the policy decision module. The scene perception module subscribes to vehicle state signals, senses and outputs special scene events, directly transmitting them to the policy execution module. The policy decision module receives the structured state tags from the continuous state monitoring module, performs condition matching, identifies three key states: "establishing a Bluetooth communication link," "receiving a vulnerable supervision timeout threshold," and "device control command," and transmits the matching results to the policy execution module. The strategy execution module integrates two inputs: on the one hand, based on the matching results of the strategy decision module, it constructs and outputs the first Bluetooth connection parameter request command, the Bluetooth connection parameter response command, the third Bluetooth connection parameter request command, and the fourth Bluetooth connection parameter request command; on the other hand, based on the special scene events of the scene perception module, it constructs and outputs the physical layer mode request command and the second physical layer mode request command, thereby completing the dynamic control of Bluetooth connection parameters and physical layer mode.

[0142] For example, the connection status monitoring module registers key events such as CONNECT_IND, LL_CONNECTION_PARAM_REQ, LL_CONNECTION_UPDATE_IND, and LL_PHY_UPDATE_IND that are callbacks from the protocol stack to the application, and extracts key parameters such as timeout, connInterval, channel selection algorithm, and PHY. The policy decision module, based on the status labels output by the monitoring module, such as "connection established," "received fragile timeout request," and "remote parking activated," looks up and matches preset policy combinations to generate action instructions to be executed, such as "immediately initiate parameter update," "overwrite RSP timeout," and "retransmit CONN_PARAM_REQ after delay." The policy execution module receives the decision instructions, calls the underlying driver interface, generates and sends PDUs such as LL_CONNECTION_PARAM_REQ / RSP and LL_PHY_REQ that conform to the protocol specifications. All PDU construction is completed in the protocol stack controller unit, ensuring execution efficiency and determinism. Scene Awareness Interface Module: Subscribes to the vehicle's status signals, such as RemoteParking_Active, through an interface to provide triggering basis for special scene strategies.

[0143] Specifically, after connection establishment, the active parameter update occurs. Once the connection is established, the specific characteristic channel of the mobile digital key is subscribed to, and there is currently no ongoing LL_CONNECTION_PARAM_REQ process. The action performed is as follows: The controller immediately assembles the LL_CONNECTION_PARAM_REQ PDU, where: oInterval_Min and Interval_Max are set to intermediate values ​​balancing response speed and power consumption; oLatency is set to 0, requiring a response every cycle; and oTimeout is set to a robust reference value. The aim is to anchor the connection parameters to a better baseline before the terminal device initiates its own request, significantly reducing the probability of fragile parameters operating for extended periods.

[0144] The robust value overwriting of the timeout field in RSP is triggered when the listening module captures the LL_CONNECTION_PARAM_REQ sent by the terminal device and parses out that its Timeout field value is less than a preset robust threshold. The action performed is as follows: when constructing LL_CONNECTION_PARAM_RSP, the original value passed from the Controller layer is not used; instead, the Timeout field is written to a robust value. This writing occurs before PDU construction and is directly controlled by the firmware. This operation only changes the value of one field in the PDU payload, fully conforming to the Bluetooth Core Specification's definition of the LL_CONNECTION_PARAM_RSP format, and the set value strictly satisfies the mathematical constraint Timeout > (1 + Latency) × Interval_Max × 2.

[0145] In remote parking scenarios, dual-dimensional parameter enhancement is implemented. When the RemoteParking_Active = 1 signal is received by the vehicle-side BLE, two parallel actions are executed: Connection interval compression: Initiating LL_CONNECTION_PARAM_REQ, both Interval_Min and Interval_Max are set to shorter values ​​to increase conn event density; PHY mode degradation: If the current PHY is LE2M, LL_PHY_REQ is initiated to request a switch to LE 1M. Exit mechanism: When the RemoteParking_Active signal becomes 0, or a preset timeout is reached, the controller automatically initiates a recovery process, switching connInterval and PHY back to normal configuration.

[0146] The system provides full-cycle connection parameter protection. The monitoring module captures the LL_CONNECTION_UPDATE_IND sent by the terminal device and parses its Timeout field value, finding it to be less than a preset robustness threshold. Actions are taken in two scenarios: one where the vehicle-side BLE overrides the RSP parameters, but the terminal device still uses the original supervision timeout parameter; and another where the terminal device skips the LL_CONNECTION_PARAM_REQ process and directly uses the LL_CONNECTION_UPDATE_IND process. In either case, a unified retry interface is immediately triggered. Under the premise of meeting the safety time window, LL_CONNECTION_PARAM_REQ is initiated again to request robust parameters. This embodiment completely eliminates "hidden parameter degradation" caused by uncontrollable factors such as terminal device background processes, system scheduling, and radio frequency interference, upgrading connection stability from "probabilistic guarantee" to "deterministic guarantee."

[0147] This application embodiment also provides a control device for a digital key, the control device for the digital key comprising: The strategy decision module is used to determine Bluetooth establishment events; The strategy execution module is used to construct a first Bluetooth connection parameter request instruction based on the target supervision timeout parameter, wherein the Bluetooth establishment event indicates that the target device and the target digital key establish a Bluetooth communication link; and to send the first Bluetooth connection parameter request instruction to the target digital key so that the target digital key establishes communication with the target device based on the target supervision timeout parameter.

[0148] In one embodiment, the control device of the digital key further includes a connection status monitoring module, which is used to receive a second Bluetooth connection parameter request instruction sent by the target digital key and obtain a first supervision timeout parameter corresponding to the second Bluetooth connection parameter request instruction; The strategy execution module is also used to construct and send a Bluetooth connection parameter response instruction to the target digital key based on the first supervision timeout parameter or the target supervision timeout parameter.

[0149] In one embodiment, the strategy decision module is used to determine whether the first supervision timeout parameter is less than the preset threshold.

[0150] The strategy execution module is also used to construct and send a Bluetooth connection parameter response command to the target digital key based on the target supervision timeout parameter.

[0151] In one embodiment, the policy execution module is further configured to perform a compliance check on the target supervision timeout parameter, and determine whether the compliance check performed on the target supervision timeout parameter passes. The compliance check includes at least one of format compliance check, mathematical compliance check, and behavioral compliance check. If the compliance check passes, a Bluetooth connection parameter response instruction is constructed and sent to the target digital key based on the target supervision timeout parameter.

[0152] In one embodiment, the connection status monitoring module is used to receive the Bluetooth connection parameter update instruction sent by the target digital key, and the second supervision timeout parameter policy decision module corresponding to the Bluetooth connection parameter update instruction is used to determine whether the second supervision timeout parameter is less than a preset threshold.

[0153] The strategy execution module is also used to determine a security time window, wherein the security time window does not coincide with a set period of high request density; within the security time window, a first Bluetooth connection parameter request instruction is constructed and sent to the target digital key based on the target supervision timeout parameter.

[0154] In one embodiment, the control device for the digital key further includes a scene-aware interface module for receiving device control commands sent by the target digital key.

[0155] The policy execution module is further configured to construct a third Bluetooth connection parameter request instruction for adjusting the Bluetooth connection interval, and send the third Bluetooth connection parameter request instruction to the target digital key; and / or, construct a physical layer mode request instruction for adjusting the physical layer mode, and send the physical layer mode request instruction to the target digital key.

[0156] In one embodiment, the policy execution module is further configured to construct the third Bluetooth connection parameter request instruction based on the target Bluetooth connection interval, wherein the target Bluetooth connection interval is less than the original Bluetooth connection interval.

[0157] In one embodiment, the policy execution module is further configured to construct the physical layer mode request instruction based on the target physical layer mode, wherein the level of the target physical layer mode is lower than the level of the original physical layer mode.

[0158] In one embodiment, the scene perception interface module is further configured to receive a vehicle control command execution completion event or a preset timeout event; The strategy execution module is further configured to, in response to the execution completion event or preset timeout event of the device control command, construct a fourth Bluetooth connection parameter request command to restore the original Bluetooth connection interval, and send the fourth Bluetooth connection parameter request command to the target digital key, so that the target digital key and the target device resume Bluetooth communication based on the original Bluetooth connection interval; and / or, in response to the execution completion event or preset timeout event of the device control command, construct a second physical layer mode request command to restore the original physical layer mode, and send the second physical layer mode request command to the target digital key, so that the target digital key and the target device resume Bluetooth communication based on the original physical layer mode.

[0159] The digital key control device provided in this application, employing the digital key control method described in the above embodiments, can solve the technical problem of easy disconnection of digital keys in terminal devices. Compared with the prior art, the beneficial effects of the digital key control device provided in this application are the same as those of the digital key control method described in the above embodiments, and other technical features in the digital key control device are the same as those disclosed in the methods of the above embodiments, and will not be repeated here.

[0160] This application also provides a vehicle, the vehicle comprising: a processing unit for storing at least one executable instruction, the executable instruction causing the processing unit to execute the digital key control method as described in any of the above embodiments, generating at least one of a Bluetooth connection parameter request instruction, a Bluetooth connection parameter response instruction, and a physical layer mode request instruction; The vehicle also includes a communication component for communicating with the digital key based on at least one of a Bluetooth connection parameter request command, a Bluetooth connection parameter response command, and a physical layer mode request command.

[0161] This application provides a digital key control device, which includes: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, which are executed by the at least one processor to enable the at least one processor to perform the digital key control method in Embodiment 1 above.

[0162] The following is for reference. Figure 7 The diagram illustrates a structural schematic of a control device suitable for implementing the digital key embodiments of this application. The control device for the digital key in the embodiments of this application may include, but is not limited to, mobile terminals such as mobile phones, laptops, digital broadcast receivers, personal digital assistants (PDAs), tablets, and in-vehicle terminals, as well as fixed terminals such as digital TVs and desktop computers. Figure 7 The digital key control device shown is merely an example and should not impose any limitations on the functionality and scope of use of the embodiments of this application.

[0163] like Figure 7As shown, the control device for a digital key may include a processing unit 1001 (e.g., a central processing unit, a graphics processing unit, etc.), which can perform various appropriate actions and processes according to a program stored in a read-only memory (ROM) 1002 or a program loaded from a storage device 1003 into a random access memory (RAM) 1004. The RAM 1004 also stores various programs and data required for the operation of the control device for the digital key. The processing unit 1001, the read-only memory 1002, and the RAM 1004 are interconnected via a bus 1005. An input / output (I / O) interface 1006 is also connected to the bus. Typically, the following systems can be connected to I / O interface 1006: input devices 1007 including, for example, touchscreens, touchpads, keyboards, mice, image sensors, microphones, accelerometers, gyroscopes, etc.; output devices 1008 including, for example, liquid crystal displays (LCDs), speakers, vibrators, etc.; storage devices 1003 including, for example, magnetic tapes, hard disks, etc.; and communication devices 1009. Communication device 1009 allows the digital key control device to communicate wirelessly or wiredly with other devices to exchange data. Although the figure shows a digital key control device with various systems, it should be understood that it is not required to implement or possess all the systems shown. More or fewer systems can be implemented alternatively.

[0164] Specifically, according to the embodiments disclosed in this application, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments disclosed in this application include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via a communication device, or installed from storage device 1003, or installed from ROM 1002. When the computer program is executed by processing device 1001, it performs the functions defined in the methods of the embodiments disclosed in this application.

[0165] The digital key control device provided in this application, employing the digital key control method described in the above embodiments, can solve the technical problem of easy disconnection of the digital key in the terminal device. Compared with the prior art, the beneficial effects of the digital key control device provided in this application are the same as those of the digital key control device provided in the above embodiments, and other technical features in this digital key control device are the same as those disclosed in the method of the previous embodiment, and will not be repeated here.

[0166] It should be understood that the various parts disclosed in this application can be implemented using hardware, software, firmware, or a combination thereof. In the description of the above embodiments, specific features, structures, materials, or characteristics can be combined in any suitable manner in one or more embodiments or examples.

[0167] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

[0168] This application provides a computer-readable storage medium having computer-readable program instructions (i.e., a computer program) stored thereon, the computer-readable program instructions being used to execute the digital key control method described in the above embodiments.

[0169] The computer-readable storage medium provided in this application may be, for example, a USB flash drive, but is not limited to, electrical, magnetic, optical, electromagnetic, infrared, or semiconductor systems, devices, or any combination thereof. More specific examples of computer-readable storage media may include, but are not limited to: electrical connections having one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM), flash memory, optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof. In this embodiment, the computer-readable storage medium may be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, system, or device. The program code contained on the computer-readable storage medium may be transmitted using any suitable medium, including but not limited to: wires, optical cables, radio frequency (RF), or any suitable combination thereof.

[0170] The aforementioned computer-readable storage medium may be included in the control device of the digital key; or it may exist independently and not be installed in the control device of the digital key.

[0171] The aforementioned computer-readable storage medium carries one or more programs that, when executed by the control device of the digital key, cause the control device of the digital key to: in response to a Bluetooth establishment event, construct a first Bluetooth connection parameter request instruction based on a target supervision timeout parameter; and send the first Bluetooth connection parameter request instruction to the digital key corresponding to the Bluetooth establishment event, so that the digital key establishes communication with the vehicle controller based on the target supervision timeout parameter.

[0172] Computer program code for performing the operations of this application can be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, and C++, as well as conventional procedural programming languages ​​such as the "C" language or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including a local area network (LAN) or a wide area network (WAN)—or can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0173] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, may be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0174] The modules described in the embodiments of this application can be implemented in software or hardware. The names of the modules do not necessarily limit the functionality of the unit itself.

[0175] The readable storage medium provided in this application is a computer-readable storage medium that stores computer-readable program instructions (i.e., a computer program) for executing the above-described digital key control method, thereby solving the technical problem of easy disconnection of digital keys in terminal devices. Compared with the prior art, the beneficial effects of the computer-readable storage medium provided in this application are the same as those of the digital key control method provided in the above embodiments, and will not be repeated here.

[0176] This application provides a computer program product, including a computer program that, when executed by a processor, implements the steps of the digital key control method described above.

[0177] The computer program product provided in this application can solve the technical problem of easy disconnection of digital keys in terminal devices. Compared with the prior art, the beneficial effects of the computer program product provided in this application are the same as the beneficial effects of the digital key control method provided in the above embodiments, and will not be repeated here.

[0178] The above are merely preferred embodiments of this application and do not limit the patent scope of this application. Any equivalent structural or procedural transformations made using the content of this application's specification and drawings, or direct or indirect applications in other related technical fields, are similarly included within the patent scope of this application.

Claims

1. A method for controlling a digital key, characterized in that, The control method of the digital key, applied to the target device, includes: In response to the detection of a Bluetooth establishment event, a first Bluetooth connection parameter request instruction is constructed based on the target supervision timeout parameter, wherein the Bluetooth establishment event indicates that the target device and the target digital key have established a Bluetooth communication link; The first Bluetooth connection parameter request instruction is sent to the target digital key so that the target digital key establishes communication with the target device based on the target supervision timeout parameter.

2. The control method for a digital key as described in claim 1, characterized in that, After sending the first Bluetooth connection parameter request instruction to the target digital key, the process includes: In response to the second Bluetooth connection parameter request instruction sent by the target digital key, the first supervision timeout parameter corresponding to the second Bluetooth connection parameter request instruction is obtained; Based on the first supervision timeout parameter or the target supervision timeout parameter, construct and send a Bluetooth connection parameter response command to the target digital key.

3. The control method for a digital key as described in claim 2, characterized in that, Before constructing and sending a Bluetooth connection parameter response command to the target digital key based on the first supervision timeout parameter or the target supervision timeout parameter, the method further includes: Determine that the first supervision timeout parameter is less than a preset threshold; and / or, The compliance check performed for the target monitoring timeout parameter has been confirmed as passed.

4. The control method for a digital key as described in claim 1, characterized in that, After sending the first Bluetooth connection parameter request instruction to the target digital key, the process includes: In response to the Bluetooth connection parameter update command sent by the target digital key, the second supervision timeout parameter corresponding to the Bluetooth connection parameter update command is obtained; If the second supervision timeout parameter is less than a preset threshold, a safe time window is determined, wherein the safe time window does not coincide with the set request-intensive period. Within the security time window, a first Bluetooth connection parameter request instruction is constructed and sent to the digital key based on the target supervision timeout parameter.

5. The control method for a digital key as described in claim 1, characterized in that, After sending the first Bluetooth connection parameter request instruction to the digital key corresponding to the Bluetooth establishment event, the process includes: In response to a device control command sent by the target digital key, a third Bluetooth connection parameter request command for adjusting the Bluetooth connection interval is constructed, and the third Bluetooth connection parameter request command is sent to the target digital key; and / or, In response to the device control command sent by the target digital key, a physical layer mode request command for adjusting the physical layer mode is constructed, and the physical layer mode request command is sent to the target digital key.

6. The control method for a digital key as described in claim 5, characterized in that, The construction of the third Bluetooth connection parameter request instruction for adjusting the Bluetooth connection interval includes: constructing the third Bluetooth connection parameter request instruction based on a target Bluetooth connection interval, wherein the target Bluetooth connection interval is less than the original Bluetooth connection interval; and / or, The physical layer mode request instruction for constructing and adjusting the physical layer mode includes: constructing the physical layer mode request instruction based on the target physical layer mode, wherein the level of the target physical layer mode is lower than the level of the original physical layer mode.

7. The control method for a digital key as described in claim 6, characterized in that, After sending the third Bluetooth connection parameter request instruction to the target digital key, the method further includes: responding to the completion event of the device control instruction or a preset timeout event, constructing a fourth Bluetooth connection parameter request instruction to restore the original Bluetooth connection interval, and sending the fourth Bluetooth connection parameter request instruction to the target digital key, so that the target digital key and the target device resume Bluetooth communication based on the original Bluetooth connection interval; and / or, After sending the physical layer mode request instruction to the target digital key, the method further includes: in response to the execution completion event or preset timeout event of the device control instruction, constructing a second physical layer mode request instruction to restore the original physical layer mode, and sending the second physical layer mode request instruction to the target digital key, so that the target digital key and the target device can resume Bluetooth communication based on the original physical layer mode.

8. The control method for a digital key as described in any one of claims 1-7, characterized in that, The target equipment includes at least one of the following: vehicles, home appliances, smart wearable devices, smart access control devices, building control terminals, park gate devices, shared equipment terminals, charging pile devices, smart lockers, industrial intelligent control terminals, IoT gateway devices, self-service terminals, security monitoring devices, and office equipment.

9. A control device for a digital key, characterized in that, The control device for the digital key includes: a memory, a processor, and a computer program stored in the memory and executable on the processor, the computer program being configured to implement the steps of the control method for the digital key as described in any one of claims 1 to 8.

10. A storage medium, characterized in that, The storage medium is a computer-readable storage medium, on which a computer program is stored, and when the computer program is executed by a processor, it implements the steps of the digital key control method as described in any one of claims 1 to 8.

Images