Vehicle Bluetooth connection method, computer readable storage medium and vehicle

Abstract

The invention discloses a vehicle Bluetooth connection method, a computer readable storage medium and a vehicle, and the scheme comprises the steps: in response to a connection request of a target Bluetooth audio device, determining an audio protocol type to which the target Bluetooth audio device negotiates to access, and determining a corresponding protocol weight based on the audio protocol type; a chip load parameter of each Bluetooth chip in a plurality of preset Bluetooth chips is obtained, a target Bluetooth chip is determined in the plurality of Bluetooth chips through the protocol weight and the chip load parameters of the Bluetooth chips, and the chip load parameters comprise current access load information and a load threshold value corresponding to the Bluetooth chip; and establishing a connection between the target Bluetooth audio device and the target Bluetooth chip to realize audio stream transmission. The problem that in a vehicle-mounted multi-screen scene, when multiple Bluetooth audio devices play at the same time, audio lagging exists, and user experience is affected is solved, it is ensured that new connection requests cannot be distributed blindly, load balanced distribution is achieved, and the playing effect of connected and newly connected audio devices is ensured.

Description

Technical Field

[0001] This application relates to the field of Bluetooth connectivity technology, specifically to a vehicle Bluetooth connectivity method, a computer-readable storage medium, and a vehicle. Background Technology

[0002] As vehicles become increasingly intelligent, in-vehicle infotainment systems are also becoming more sophisticated, with multi-screen configurations such as passenger-side screens, rear-seat entertainment screens, ceiling-mounted screens, and armrest screens becoming commonplace. To meet the independent audio-visual experience needs of passengers in different seats, independent audio output via Bluetooth audio devices is required, necessitating the connection of individual Bluetooth headphones to each screen. However, due to the physical limitations of Bluetooth chips, a single Bluetooth chip typically only supports a maximum of two Bluetooth headphones playing music simultaneously (A2DP protocol). When more than two headphones are connected, issues such as audio stuttering, latency, and packet loss occur, severely impacting the user experience.

[0003] In existing technologies, most systems employ a single Bluetooth chip architecture. While some advanced systems integrate dual Bluetooth chips, these chips typically operate independently or use a fixed master-slave allocation mode. For example, one chip might be dedicated to calls, while the other is dedicated to media playback. However, the lack of a coordination mechanism between the two chips prevents dynamic load allocation, leading to resource waste. Consequently, in in-vehicle multi-screen scenarios, existing technologies suffer from audio stuttering and other issues when multiple Bluetooth audio devices play simultaneously, impacting the user experience. Summary of the Invention

[0004] In view of the above problems, this application provides a vehicle Bluetooth connection control method, a computer-readable storage medium, and a vehicle that overcomes or at least partially solves the above problems. The technical solution is as follows: A vehicle Bluetooth connection method includes: responding to a connection request from a target Bluetooth audio device, determining the audio protocol type negotiated by the target Bluetooth audio device, and determining a corresponding protocol weight based on the audio protocol type; obtaining chip load parameters of each of a plurality of preset Bluetooth chips, and determining a target Bluetooth chip among the plurality of Bluetooth chips using the protocol weight and the chip load parameters of the Bluetooth chips, wherein the chip load parameters include current access load information and a load threshold corresponding to the Bluetooth chip; and establishing a connection between the target Bluetooth audio device and the target Bluetooth chip to transmit audio streams, thereby enabling audio stream transmission.

[0005] This approach transforms different types of audio connection requests into quantifiable and comparable protocol weight parameters. Audio protocol types, such as the HFP protocol for two-way real-time voice communication and the A2DP protocol for one-way media streaming, represent different service quality requirements, data processing complexity, and system resource consumption levels. By predefining corresponding protocol weights for each protocol type, the inherent resource requirements of different audio services can be quantitatively assessed. Secondly, by acquiring the chip load parameters of each of the pre-configured multiple Bluetooth chips, global real-time monitoring of all available Bluetooth chip resources within the system is achieved. This solves the technical problem of isolated chip operating status information in existing technologies. By acquiring the current access load information and load threshold of each chip, the overall resource distribution and remaining capacity can be monitored in real time. Furthermore, by combining protocol weights and Bluetooth chip load parameters... The system identifies the target Bluetooth chip from multiple Bluetooth chips, selecting the most suitable one from multiple candidate chips. This solves the problem of uneven resource utilization among multiple chips, ensuring that new connection requests are not blindly assigned to the first available or pre-specified chip, but are instead guided to a relatively idle chip with sufficient capacity. This achieves an initial balanced distribution of load, avoiding premature overloading of a single chip while other chips are underloaded or idle, thus improving overall connection capacity and stability from the source. Furthermore, based on the results of the aforementioned intelligent decision-making, precise audio stream routing is performed. Since the connection is established on the chip with the most suitable load, it is in a more stable transmission environment, reducing the probability of audio stuttering and increased latency due to intense chip resource competition, thereby improving the service quality of individual connections and the overall system.

[0006] Further, determining the target Bluetooth chip among the plurality of Bluetooth chips using the protocol weight and the chip load parameters of the Bluetooth chip specifically includes: determining the current access load weight corresponding to each Bluetooth chip using the current access load information of each Bluetooth chip, wherein the current access load information includes the access protocol type of the current access device; determining the available load weight of each Bluetooth chip based on the current access load weight and the load threshold of the Bluetooth chip; and determining the target Bluetooth chip among the plurality of Bluetooth chips based on the relationship between the protocol weight and the available load weight of the Bluetooth chip.

[0007] First, by using the current access load information of each Bluetooth chip, the current access load weight of each chip is determined, quantifying the chip's existing load. The access protocol type of each device connected to the chip is converted into a corresponding weight and summed, ensuring the uniformity of load measurement within the system. This avoids the audio stuttering and latency issues caused by using only the number of connected devices as a load indicator in existing technologies. Based on the current access load weight and the Bluetooth chip's load threshold, the available load weight of each Bluetooth chip is determined, realizing the conversion from used load to remaining capacity. This intuitively represents how many new connection requests the chip can still handle. Finally, by considering the relationship between protocol weights and the available load weights of Bluetooth chips, the target Bluetooth chip is determined from among multiple Bluetooth chips. This greatly enhances the determinism and feasibility of the solution, ensuring the accuracy and fairness of system resource assessment and allocation.

[0008] Further, determining the target Bluetooth chip from among the plurality of Bluetooth chips based on the relationship between the protocol weight and the available load weight of the Bluetooth chip specifically includes: filtering available Bluetooth chips whose available load weight is not greater than the protocol weight; when there is one available Bluetooth chip, determining the target Bluetooth chip based on the available Bluetooth chip; when there are multiple available Bluetooth chips, determining the target Bluetooth chip based on the maximum value of the available load weight.

[0009] Available Bluetooth chips with a load weight not less than the protocol weight are selected, eliminating chips whose remaining capacity is insufficient to handle new requests. This avoids invalid calculations and connection attempts that may cause overload. When only one available Bluetooth chip exists, the target Bluetooth chip is determined based on its availability. This ensures rapid connection establishment when resources are relatively abundant or when there is only one suitable option. When multiple available Bluetooth chips exist, the target Bluetooth chip is determined based on its maximum available load weight. If multiple chips can meet the current request, the chip with the maximum available load weight—that is, the one currently most idle and with the most remaining capacity—is selected as the target. This completes the task allocation for the current connection, applying new load to the chip with the lightest current burden. This helps keep the load levels (current access load weights) of each chip similar, preventing an unbalanced state where some chips accumulate excessive load while others remain idle for a long time due to accidental differences in connection sequences. Through the local optimal selection of each connection allocation, the overall global resource utilization is maximized and the load of each chip is evenly distributed.

[0010] Furthermore, the method further includes: when no available Bluetooth chip exists, determining a first Bluetooth chip and a second Bluetooth chip in descending order of available load weights; determining the target protocol priority corresponding to the target Bluetooth audio device, and determining a currently accessed audio device with a priority lower than the target protocol priority in the first Bluetooth chip based on the target protocol priority; migrating the currently accessed audio device in the first Bluetooth chip to the second Bluetooth chip, and determining the target Bluetooth chip based on the first Bluetooth chip.

[0011] When no directly available Bluetooth chip is available, meaning the available load weight of all chips is less than the protocol weight of the new request, existing resources are adjusted to meet new high-priority or necessary connection requests. This overcomes the limitation of solely relying on the static remaining capacity of chips, enhancing the system's connection acceptance and service assurance capabilities. When no available Bluetooth chip is available, the first and second Bluetooth chips are determined sequentially according to their available load weights from highest to lowest. Chips with relatively light and second-light loads in the system are identified first and used as the main components for resource adjustment. When resource constraints necessitate migration, decisions are made based on a preset priority strategy, ensuring that resource adjustments are made to guarantee higher-priority services and ensure the service quality of critical services (such as answering calls). By migrating one or more existing low-priority connections from the first Bluetooth chip to the second Bluetooth chip, sufficient resource space is freed up on the first Bluetooth chip, which is then used as the target Bluetooth chip to establish new high-priority connections. This demonstrates the system's ability to dynamically reorganize resources and solves the problem of being unable to respond to new important connection requests when the system is fully or nearly fully loaded. By migrating, the continuity of some low-priority service connections is maintained, rather than interrupted, while prioritizing the immediate access of high-priority services. This enables dynamic and on-demand allocation of system resources among different service types, significantly improving the system's service level and emergency response capabilities.

[0012] Furthermore, after transmitting the audio stream of the target Bluetooth audio device to the target Bluetooth chip, the method further includes: monitoring the real-time access load weight of each Bluetooth chip, determining the load balancing index corresponding to each Bluetooth chip by the ratio of the real-time access load weight to the load threshold; and performing dynamic load migration on unbalanced Bluetooth chips that meet preset requirements based on the load balancing index of each Bluetooth chip.

[0013] By monitoring the real-time access load weight of each Bluetooth chip and determining the load balancing index corresponding to each Bluetooth chip based on the ratio of the real-time access load weight to the load threshold, the load balancing index is defined, eliminating the differences in absolute load thresholds between different chips and making the load pressure between chips comparable. Based on the load balancing index of each Bluetooth chip, dynamic load migration is performed on unbalanced Bluetooth chips that meet the preset requirements. This solves the problem of load imbalance caused by dynamic runtime events such as sudden increases in data flow on a certain chip or device disconnection leading to changes in the relative load of other chips after initial allocation. It ensures that even after long-term operation, it will not gradually slide into a severely unbalanced state due to small deviations in the initial allocation or disturbances during operation, thereby continuously guaranteeing the transmission quality of each connection and avoiding overall performance degradation due to local overload.

[0014] Furthermore, based on the load balancing index of each Bluetooth chip, dynamic load migration is performed on unbalanced Bluetooth chips that meet preset requirements. Specifically, this includes: calculating the difference between the load balancing indices of any two Bluetooth chips using the load balancing index of each Bluetooth chip; identifying the unbalanced Bluetooth chip whose difference exceeds a preset imbalance threshold, and triggering dynamic load migration.

[0015] By calculating the difference between the load balancing metrics of any two Bluetooth chips using the load balancing metrics of each Bluetooth chip, and employing a global comparison approach, the dispersion of load distribution across multiple chips is obtained by calculating the difference between the load balancing metrics of all chips pairwise. Bluetooth chips whose differences exceed a preset imbalance threshold are identified as imbalanced Bluetooth chips, triggering dynamic load migration. This difference-based judgment method can detect load distribution imbalances and proactively migrate loads before they affect connection performance, achieving preventative load management rather than passively waiting for issues such as stuttering to occur. This greatly improves the timeliness and foresight of system control.

[0016] Furthermore, triggering dynamic load migration specifically includes: determining the chip to be migrated and the target migration chip among the unbalanced Bluetooth chips based on the load balancing metrics; obtaining load device profiles and load priorities of multiple access loads connected to the chip to be migrated, wherein the load device profile includes the historical migration success rate and historical average audio packet loss rate corresponding to the access load; determining the switching sensitivity index of each access load through the load device profile; determining the load to be migrated according to the switching sensitivity index and the load priority, and migrating the audio stream of the load to be migrated to the target migration chip.

[0017] Based on load balancing metrics, the chips to be migrated and the target chips to be migrated are identified among the unbalanced Bluetooth chips, clarifying the migration source and destination. Typically, a portion of the load on the chip with the highest load rate (the chip to be migrated) is migrated to the chip with a lower load rate (the target chip to migrate). Load device profiles and load priorities are obtained for multiple access loads connected to the chip to be migrated. The load device profiles contain historical behavior data of the devices, and the load priorities reflect the importance of the services. Using the load device profiles, the handover sensitivity index for each access load is determined to assess the probability of failure or quality degradation during connection handover. Under the premise of meeting the migration objective (reducing the load on the source chip), devices with low handover sensitivity indexes (i.e., stable historical performance, low migration risk, and low load priority) are prioritized for migration, minimizing the potential negative impact of the migration operation itself. Prioritizing the migration of devices insensitive to handover reduces the risk of migration failure or audio quality fluctuations; prioritizing the migration of low-priority devices ensures that the connection stability of high-priority services (such as calls) is not disturbed. While resolving the load imbalance between chips, it maximizes the continuity and quality of the overall service, ensuring that the load migration operation itself is efficient and has minimal impact on the user experience, and avoiding new instability or user-perceptible interruptions caused by the migration process.

[0018] Furthermore, the method further includes: detecting the real-time chip temperature of each Bluetooth chip, comparing the real-time chip temperature with a preset safe temperature threshold; determining the temperature overshoot when the real-time chip temperature exceeds the safe temperature threshold; and applying a threshold penalty to the basic load threshold corresponding to each Bluetooth chip based on the temperature overshoot to determine the load threshold of each Bluetooth chip.

[0019] When evaluating the chip load capacity, the physical operating state (temperature) of the Bluetooth chip was considered. This enabled dynamic, secure, and accurate modeling of the chip's maximum available resources, allowing system scheduling to adapt to real-time changes in the hardware environment and preventing performance degradation or failures due to overheating, fundamentally improving the system's robustness and reliability. Real-time chip temperature monitoring of each Bluetooth chip established a continuous monitoring channel for key hardware status parameters, comparing the real-time chip temperature with preset safe temperature thresholds. When the real-time chip temperature exceeds the safe temperature threshold, the temperature overscalar value is determined, enabling the identification and quantification of abnormal states. The temperature overscalar value reflects the degree of chip overheating. A threshold penalty is applied to the basic load threshold corresponding to each Bluetooth chip based on the temperature overscalar value, determining the load threshold for each Bluetooth chip. As the chip temperature rises, its safety margin for stable operation decreases, and continuous high-load operation will exacerbate temperature rise and even trigger thermal protection. Therefore, by dynamically reducing the chip's load threshold through threshold penalties, the scheduling logic proactively reduces the chip's load, avoiding or reducing the allocation of new connections to the overheated chip. It may also trigger migration to transfer some of its existing load to a chip with a normal operating temperature, thereby helping the chip reduce its load and alleviate temperature rise. This solves the problem of traditional scheduling schemes treating chip capabilities as a fixed value and ignoring changes in its actual physical operating environment. It avoids sudden performance degradation or connection interruptions caused by overheating and can extend chip lifespan through intelligent load transfer, improving the long-term operational stability and safety of the entire in-vehicle audio system in complex thermal environments.

[0020] A vehicle comprising: At least one processor; and, A memory communicatively connected to the at least one processor; wherein, The memory stores instructions that can be executed by the at least one processor to enable the at least one processor to: the vehicle Bluetooth connection method described in any of the preceding claims.

[0021] A computer-readable storage medium storing computer-executable instructions, wherein the computer-executable instructions are configured as the vehicle Bluetooth connection method described in any of the preceding claims.

[0022] The above description is only an overview of the technical solution of this application. In order to better understand the technical means of this application and to implement it in accordance with the contents of the specification, and to make the above and other objects, features and advantages of this application more obvious and understandable, the following are specific embodiments of this application. Attached Figure Description

[0023] Various other advantages and benefits will become apparent to those skilled in the art upon reading the following detailed description of preferred embodiments. The accompanying drawings are for illustrative purposes only and are not intended to limit the scope of this application.

[0024] Figure 1 A flowchart illustrating a vehicle Bluetooth connection method provided in an embodiment of this application; Figure 2 This is a schematic diagram of the vehicle structure in an embodiment of this application. Detailed Implementation

[0025] Exemplary embodiments of the present application will now be described in more detail with reference to the accompanying drawings. While exemplary embodiments of the present application are shown in the drawings, it should be understood that the present application may be implemented in various forms and should not be limited to the embodiments set forth herein. Rather, these embodiments are provided so that this application will be thorough and complete, and will fully convey the scope of the present application to those skilled in the art.

[0026] This application provides a vehicle Bluetooth connection method. It should be noted that the execution subject in this application embodiment can be a vehicle system or a cockpit domain controller, etc. Figure 1 This is a flowchart illustrating a vehicle Bluetooth connection method provided in an embodiment of this application, as shown below. Figure 1 As shown, the main steps include the following: Step S101: In response to the connection request of the target Bluetooth audio device, determine the audio protocol type that the target Bluetooth audio device negotiates access to, and determine the corresponding protocol weight based on the audio protocol type.

[0027] A target Bluetooth audio device refers to a terminal device capable of establishing a wireless Bluetooth connection with the vehicle's infotainment system and transmitting one-way or two-way audio data. Specifically, target Bluetooth audio devices include, but are not limited to, audio output devices and audio input / output devices. Audio output devices, such as Bluetooth headsets and Bluetooth speakers, primarily function to receive and play audio streams from the vehicle's infotainment system. For example, they may receive entertainment audio output from specific screens such as the passenger-side screen or rear-seat screens, or receive navigation prompts or system sounds from the vehicle's infotainment system. Audio input / output devices, such as a user's smartphone, involve two-way audio interaction. In smartphone audio playback scenarios, the vehicle's infotainment system acts as the audio receiver, playing media audio from the phone. In Bluetooth call scenarios, a two-way voice channel is established between the vehicle's infotainment system and the phone to capture and play call audio. A connection request from a target Bluetooth audio device is a wireless communication event initiated by the device itself or triggered by scanning by the vehicle's infotainment system. This event is transmitted to the vehicle's main control processor via the Bluetooth protocol stack, and its core data packet contains device information used for identification and negotiation of connection parameters.

[0028] Audio protocol types refer to the standardized communication protocols defined in the Bluetooth specification for different types of audio data transmission. These mainly include the Advanced Audio Distribution Specification (A2DP) for high-quality unidirectional media streaming and the Hands-Free Specification (HFP) for bidirectional, low-latency voice communication. During the service discovery or protocol negotiation phase of Bluetooth connection establishment, the vehicle's Bluetooth protocol stack parses the service category in the target device's connection request or negotiates with it to determine whether the connection the device is currently requesting is an A2DP stream for music playback or an HFP link for calls.

[0029] Protocol weights are dimensionless values ​​pre-calibrated and stored within the vehicle infotainment system to quantify the computational and RF resource consumption of different audio protocol types on the Bluetooth chip. In other words, protocol weights are values ​​determined and stored in advance within the vehicle infotainment system through calibration tests, used to quantify the typical resource consumption levels of different audio protocol types on the Bluetooth chip system. Computational resource consumption is primarily assessed through the average load rate of the chip processor when processing a typical audio stream of the protocol and the required memory bandwidth. For example, the computational load required for processing high-bitrate A2DP audio decoding is significantly higher than that for processing narrowband voice HFP encoding. RF resource consumption is primarily assessed through the proportion of radio channel occupancy time required to maintain a stable connection for the protocol. For example, a bidirectional, low-latency HFP call link requires periodic, high-priority occupancy of RF time slots, and its channel occupancy pattern differs from that of intermittent A2DP streams. Calibration tests can be conducted in a laboratory environment using monitoring tools to measure parameters such as the core processor load rate, memory access rate, and RF front-end activity time proportion when the Bluetooth chip is processing a typical load of a single protocol, and then these parameters are normalized into dimensionless weight values.

[0030] After identifying the protocol type, a pre-defined protocol type-weight mapping table is queried. This mapping table is generated and stored in the storage medium during the system development phase based on the technical characteristics of various protocols (such as data bandwidth, real-time requirements, and encoding / decoding complexity). For example, when the protocol type is identified as HFP, the corresponding first weight value is retrieved from the mapping table; when the protocol type is identified as A2DP, the corresponding second weight value is retrieved, with the first weight value being greater than the second. This process is a deterministic lookup operation, and the output protocol weight is used in subsequent chip selection decisions to characterize the estimated resource requirement level of this connection request. In one example, the A2DP music protocol weight is 5, the HFP call protocol weight is 6, and the Bluetooth chip supports Bluetooth 5.2, capable of handling two A2DP connections and one HFP connection simultaneously.

[0031] In the actual operation of an in-vehicle multi-screen audio system, when a user operates a screen and selects to output audio via Bluetooth headphones, the corresponding application software module initiates an output path switching request to the audio management framework of the vehicle's operating system. This path switching request triggers the Bluetooth service management layer to attempt to establish a connection with the target Bluetooth audio device. The Bluetooth service management layer sends a device connection command to the physical Bluetooth chip through the underlying Bluetooth Host Controller Interface (HCI). Simultaneously, a server or processor with data processing capabilities (referred to as the central control unit) determines the audio protocol type negotiated by the target Bluetooth audio device by querying the Bluetooth protocol stack's status interface or listening to specific system events.

[0032] During link establishment, the Bluetooth chip exchanges feature data packets with the remote device, which clearly list the services and protocols the device is currently negotiating to access. By parsing these feature data packets, it can be accurately determined whether an A2DP or HFP connection is being negotiated. After identifying the protocol type, the corresponding protocol weight is determined based on the audio protocol type. Because the HFP protocol involves bidirectional, real-time voice communication, it is extremely sensitive to latency and interruptions, and is typically considered a highest-priority task in automotive scenarios (such as answering calls). Therefore, it is assigned a relatively high weight value to reflect its importance during resource scheduling and to reserve processing capacity for it. While the A2DP protocol may have higher bandwidth requirements, its tolerance for real-time performance is relatively better, and therefore it is assigned a relatively lower weight value.

[0033] Based on the identified protocol type, the system uses it as an index key to query the configuration database and obtain the protocol weight. This process is entirely automated by the in-vehicle processor, requiring no manual intervention and is extremely fast. It is typically completed during the physical and link layer negotiation process of establishing a Bluetooth connection, without causing any additional delay to the user-perceived connection speed.

[0034] Conventional methods for handling Bluetooth device connections typically only perform simple device authentication and link establishment, without in-depth analysis and quantitative evaluation of the service type represented by the connection request itself. This results in the system being unable to predict how many core Bluetooth chip resources the connection will consume. This technical solution, by determining the audio protocol type and mapping it to specific protocol weights, enables the system to distinguish between resource-sensitive real-time calls and relatively relaxed media playback. This solves the problem of blind resource allocation caused by the inability to differentiate service importance in traditional solutions, providing a data foundation for overcoming the physical limitations of a single chip and stably supporting concurrent transmission of multiple high-quality audio streams in multi-screen scenarios.

[0035] Step S102: Obtain the chip load parameters of each of the preset multiple Bluetooth chips, so as to determine the target Bluetooth chip among the multiple Bluetooth chips by means of the protocol weight and the chip load parameters of the Bluetooth chips.

[0036] The chip load parameters include the current access load information and the load threshold corresponding to the Bluetooth chip. It should be noted that the current access load information refers to the access protocol type of the currently connected devices to the Bluetooth chip, and refers to the set of information of all Bluetooth audio devices that have successfully established and maintained an audio connection on the Bluetooth chip at the current moment. The load threshold corresponding to the Bluetooth chip is used to represent the theoretical physical chip carrying capacity of each Bluetooth chip in the current state, which is the maximum load that can be carried in the corresponding operating environment.

[0037] In one example, the load threshold can be a static base load threshold or a dynamic load threshold that characterizes the theoretically maximum load a single Bluetooth chip can handle under the current operating environment and state. The base load threshold is a static calibration value, determined through systematic stress calibration tests in an ideal laboratory environment. It represents a normalized value indicating the upper limit of the Bluetooth chip's computational and RF resource physical capacity. Essentially, it represents the chip's load capacity model for stably handling specific audio protocol combinations, such as two high-quality A2DP channels or one HFP and one A2DP channel, without performance degradation under conditions of no external interference and normal operating temperature. The dynamic load threshold is a real-time adjusted value, obtained by dynamically compensating the base load threshold based on real-time acquired environmental parameters during actual system operation. It reflects the chip's true load-bearing capacity under the current state. In this embodiment, the load threshold is preferably a dynamic load threshold.

[0038] In one embodiment of this application, the chip load parameters of each of a plurality of pre-set Bluetooth chips are obtained. The number of Bluetooth chips is no less than two, depending on the design of the vehicle hardware phase. Based on the protocol weight of the target Bluetooth audio device and the chip load parameters of each Bluetooth chip, a target Bluetooth chip is determined from among the plurality of Bluetooth chips. The most suitable target Bluetooth chip is selected from multiple candidate chips, solving the problem of uneven resource utilization among multiple chips. This ensures that new connection requests are not blindly assigned to the first available or pre-specified chip, but are instead guided to a currently relatively idle chip with sufficient capacity. This achieves an initial balanced distribution of load, avoiding premature overloading of a single chip while other chips are in a lightly loaded or idle state, thus improving the overall connection capacity and stability from the source.

[0039] Before step S102, the method further includes determining the load threshold of each Bluetooth chip, specifically implemented in the following way: First, the real-time chip temperature of each Bluetooth chip is detected and compared with a preset safe temperature threshold; when the real-time chip temperature exceeds the safe temperature threshold, the temperature overshoot is determined; based on the temperature overshoot, a threshold penalty is applied to the basic load threshold corresponding to each Bluetooth chip to determine the load threshold of each Bluetooth chip.

[0040] Specifically, real-time chip temperature refers to the actual operating temperature value of the Bluetooth chip's internal or core area at the current moment. It is usually measured in degrees Celsius and is a continuously changing physical quantity that directly reflects the chip's power consumption, heat dissipation efficiency, and the combined effect of ambient temperature rise. Modern Bluetooth chips typically integrate an internal temperature sensor, which periodically (e.g., every 100 milliseconds) reads the digital output value of the temperature sensor through a dedicated digital interface (such as I2C, SPI) or register provided by the chip.

[0041] First, the real-time chip temperature of each Bluetooth chip is detected. A temperature query command is sent to the controller of each Bluetooth chip, and the internal sensor of the chip converts the physical temperature into a digital signal and returns it. After obtaining these raw digital signals, the raw digital signals are converted into accurate temperature values ​​in degrees Celsius according to the calibration parameters provided by the chip manufacturer. Then, the real-time chip temperature is compared with the preset safe temperature threshold. The safe temperature threshold, which is pre-calibrated according to the chip specifications and the vehicle's thermal management objectives, is read from the pre-stored configuration file. The safe temperature threshold represents the critical point for the long-term reliable operation of the chip. The safe temperature threshold is a temperature threshold value that is pre-determined and fixed in the system configuration file during the system design stage according to the chip specifications, reliability testing, and thermal design. It represents the highest allowable temperature at which the chip can work stably for a long time without triggering hardware protection (such as frequency reduction or shutdown) or significantly affecting radio frequency performance or connection stability.

[0042] The real-time chip temperature of each chip is compared with a safe temperature threshold one by one to quickly identify chips at potential overheating risk. When the real-time chip temperature exceeds the safe temperature threshold, it indicates that the chip's heat dissipation may not be able to keep up with the heat generated by the current load. Continuing to operate at the current load poses a risk of performance degradation, unstable connections, or even hardware damage. In this case, the difference between the real-time chip temperature and the safe temperature threshold is used to determine the degree of temperature exceedance.

[0043] A threshold penalty is applied to the baseline load threshold corresponding to each Bluetooth chip based on the amount of temperature overrun, thus determining the load threshold for each chip. The baseline load threshold is the static maximum capacity value assigned to each chip during system design, related to the theoretical load capacity of the physical chip. For example, a weight of 11 can be calibrated based on the chip's theoretical maximum load capacity at standard operating temperatures; this is expressed in weight units. The threshold penalty is a penalty value calculated proportionally based on the amount of temperature overrun. The initial penalty value is obtained by multiplying the amount of temperature overrun by a preset temperature penalty coefficient. The temperature penalty coefficient defines the load weight value to be deducted for each unit of temperature overrun, and its calibration takes into account the chip's heat dissipation characteristics and performance degradation curve; for example, the temperature penalty coefficient can be set to 0.05.

[0044] The initial real-time load threshold is obtained by subtracting the calculated penalty value from the base load threshold using a subtraction operation. To prevent the chip's capabilities from being excessively restricted and losing basic service capabilities, the initial real-time load threshold is compared with a preset minimum protection load threshold, which can be the minimum load weight corresponding to the protocol type. If the initial real-time load threshold is greater than or equal to the minimum protection load threshold, it is determined as the chip's final real-time load threshold. If it is less than the minimum protection load threshold, the minimum protection load threshold is used as the chip's final real-time load threshold. The determined real-time load threshold is updated to the corresponding parameter item in the chip's system resource scheduling table. In subsequent new connection allocation, available load weight calculation, and load balancing decisions, this load threshold adjusted based on real-time thermal status will be used as the decision basis, rather than the original base load threshold. This process is executed cyclically in the system background, realizing adaptive, smooth, and safe dynamic adjustment of the chip's load capacity according to its physical temperature state.

[0045] When evaluating the chip load capacity, the physical operating state (temperature) of the Bluetooth chip was considered. This enabled dynamic, secure, and accurate modeling of the chip's maximum available resources, allowing system scheduling to adapt to real-time changes in the hardware environment and preventing performance degradation or failures due to overheating, fundamentally improving the system's robustness and reliability. Real-time chip temperature monitoring of each Bluetooth chip established a continuous monitoring channel for key hardware status parameters, comparing the real-time chip temperature with preset safe temperature thresholds. When the real-time chip temperature exceeds the safe temperature threshold, the temperature overscalar value is determined, enabling the identification and quantification of abnormal states. The temperature overscalar value reflects the degree of chip overheating. A threshold penalty is applied to the basic load threshold corresponding to each Bluetooth chip based on the temperature overscalar value, determining the load threshold for each Bluetooth chip. As the chip temperature rises, its safety margin for stable operation decreases, and continuous high-load operation will exacerbate temperature rise and even trigger thermal protection.

[0046] Therefore, by dynamically reducing the chip's load threshold through threshold penalties, the scheduling logic proactively reduces the chip's load, avoiding or reducing the allocation of new connections to the overheated chip. It may also trigger migration to transfer some of its existing load to a chip with a normal operating temperature, thereby helping the chip reduce its load and alleviate temperature rise. This solves the problem of traditional scheduling schemes treating chip capabilities as a fixed value and ignoring changes in its actual physical operating environment. It avoids sudden performance degradation or connection interruptions caused by overheating and can extend chip lifespan through intelligent load transfer, improving the long-term operational stability and safety of the entire in-vehicle audio system in complex thermal environments.

[0047] In step S102, the target Bluetooth chip is determined from among the multiple Bluetooth chips using the protocol weight and the chip load parameters of the Bluetooth chip. This is specifically achieved in the following way: The current access load weight of each Bluetooth chip is determined by using the current access load information of each Bluetooth chip, which includes the access protocol type of the current access device. Based on the current access load weight and the load threshold of the Bluetooth chip, the available load weight of each Bluetooth chip is determined. The target Bluetooth chip is determined from among the multiple Bluetooth chips by the relationship between the protocol weight and the available load weight of the Bluetooth chip.

[0048] It should be noted that the current access load information refers to the collection of information on all Bluetooth audio devices that have successfully established and maintained audio connections on each Bluetooth chip at the current moment, which can be a dynamic data list. The currently accessed device is each connected Bluetooth audio device in the list. The access protocol type refers to the Bluetooth audio protocol being used by each currently accessed device, synonymous with the aforementioned audio protocol type, such as HFP or A2DP. The current access load weight is the sum of chip resources consumed by all currently accessed devices, representing the amount of load occupied by the chip. The load threshold refers to the maximum load weight that the chip is allowed to bear in the current state. In one example, the load threshold here is a dynamic load threshold adjusted for temperature penalties.

[0049] Specifically, the first step is to determine the current access load weight for each Bluetooth chip by analyzing its current access load information. A dynamic list for each Bluetooth chip is obtained, which explicitly lists the unique identifier of each Bluetooth audio device connected to that chip, as well as the access protocol type used by the device's currently active audio connections. For example, device "Headphone_1" might be playing music using the A2DP protocol, while device "Mobile_Driver" might be making calls using the HFP protocol. For each Bluetooth chip's dynamic list, a protocol weight mapping table is consulted based on the access protocol type of each device in the list, thus mapping each device to a specific load weight value. For example, an HFP connection might be mapped to a higher weight value, while an A2DP connection might be mapped to a lower weight value. The weight values ​​of all devices in the chip's list are then summed, and the resulting cumulative sum represents the current access load weight of that Bluetooth chip, reflecting the differences in resource consumption across different service types.

[0050] Based on the current access load weight and the load threshold of the Bluetooth chip, the available load weight of each Bluetooth chip is determined. The load threshold of each Bluetooth chip is read; preferably, this load threshold is a dynamic load threshold based on temperature compensation. For each Bluetooth chip, the calculated current access load weight is subtracted from its load threshold to obtain the available load weight. The chip with the higher the available load weight is the most idle resource provider in the current system. The target Bluetooth chip is determined from among multiple Bluetooth chips based on the relationship between the protocol weight of the target Bluetooth audio device and the available load weight of the Bluetooth chips.

[0051] The target Bluetooth chip is determined from among multiple Bluetooth chips based on the relationship between protocol weights and the available payload weights of the Bluetooth chips. Specifically, this includes: First, filter available Bluetooth chips whose available payload weight is no greater than the protocol weight. That is, check whether the remaining capacity of each Bluetooth chip, i.e., its available payload weight, is sufficient to cover the protocol weight of the new connection request.

[0052] When an available Bluetooth chip exists, the target Bluetooth chip is determined based on that available Bluetooth chip; if the resources are just sufficient or only one chip is capable of receiving, the target Bluetooth chip is determined directly based on the available Bluetooth chip, and that single candidate is designated as the final target.

[0053] When multiple available Bluetooth chips exist, an optimization process is performed. The remaining capacity values ​​of the available Bluetooth chips are compared, and the target Bluetooth chip is determined by the maximum available load weight. That is, the chip with the largest remaining load space is selected as the target. New load is applied to the currently least idle chip to promote a long-term consistency in the load levels of all chips, achieving the optimal initial load distribution.

[0054] Available Bluetooth chips with a load weight not less than the protocol weight are selected, eliminating chips whose remaining capacity is insufficient to handle new requests. This avoids invalid calculations and connection attempts that may cause overload. When only one available Bluetooth chip exists, the target Bluetooth chip is determined based on its availability. This ensures rapid connection establishment when resources are relatively abundant or when there is only one suitable option. When multiple available Bluetooth chips exist, the target Bluetooth chip is determined based on its maximum available load weight. If multiple chips can meet the current request, the chip with the maximum available load weight—that is, the one currently most idle and with the most remaining capacity—is selected as the target. This completes the task allocation for the current connection, applying new load to the chip with the lightest current burden. This helps keep the load levels (current access load weights) of each chip similar, preventing an unbalanced state where some chips accumulate excessive load while others remain idle for a long time due to accidental differences in connection sequences. Through the local optimal selection of each connection allocation, the overall global resource utilization is maximized and the load of each chip is evenly distributed.

[0055] When no available Bluetooth chip is available, it indicates that the current remaining space on all chips is insufficient to directly accommodate the new request. In this case, resource reorganization is required to ensure the normal operation of the target Bluetooth audio device. When no available Bluetooth chip is available, all chips are first sorted according to their available load weight from largest to smallest. The first and second Bluetooth chips are then determined sequentially, with the chip having the largest available load weight designated as the first Bluetooth chip, and the next least available chip designated as the second Bluetooth chip. The first Bluetooth chip serves as a candidate for both the source and target chip for resource release, as it is most likely to meet the new demand by releasing a small amount of load. The second Bluetooth chip is designated as the target to receive the released load. To determine which existing connection to migrate from the first Bluetooth chip, the priority of the target protocol corresponding to the target Bluetooth audio device needs to be determined. The determination of the target protocol priority is based on the audio protocol type and further combined with at least one of the following: audio stream source information, content type information, or associated user identity information. Generally, the higher the protocol weight corresponding to a protocol type, the higher the priority of the corresponding target protocol. Under the same protocol type, the priority can be determined based on the video stream source corresponding to the target Bluetooth audio device. For example, for audio streams of the A2DP protocol type, if the source is identified as a vehicle navigation system, it is assigned a first priority level; if the source is identified as a rear-seat entertainment system, it is assigned a second priority level, which is lower than the first priority level.

[0056] The following is an example of target protocol priority for HFP and A2DP protocols provided in this application: Firstly, the HFP protocol has a higher priority than the A2DP protocol. In the HFP protocol, the highest priority level 1 is for emergency calls or active safety-related calls, such as vehicle-triggered emergency calls (eCall) and calls answered by the driver via voice commands. The higher priority level 2 is for ordinary in-vehicle phone calls, such as regular voice calls made or received by the driver or passengers through the vehicle's infotainment system. As real-time two-way voice communication, it is extremely sensitive to latency and interruptions and is a core communication function in the in-vehicle environment, with a priority second only to emergency services.

[0057] In the A2DP protocol, the medium-high priority level 3 is for driving safety-related audio prompts, such as turn prompts, lane departure warnings, and collision warnings from the navigation system. Although these are one-way media streams, their information content is directly related to driving safety and is an important part of driver assistance functions. In the event of resource conflicts, their continuity should take precedence over entertainment audio.

[0058] Priority level 4 is for key infotainment audio for the driver or front-seat passengers, such as music or podcasts selected by the driver, or audio-visual content played for front-seat passengers. It serves the core entertainment needs of the driver and front-seat passengers and is directly related to the driving experience. Its quality is guaranteed when resources are sufficient, and its priority is lower than safety warning sounds but higher than rear-seat entertainment when resources are limited.

[0059] The low-to-medium priority level 5 is for audio on the back row or secondary entertainment screens, such as movie and game audio played on the independent entertainment screens in the back row. It is an additional function to enhance comfort. When system resources are under global pressure, it can become the primary candidate for load adjustment (such as migration) to ensure the stability of higher priority services.

[0060] Low priority level 6 system status prompts and notification sounds, such as low battery alerts, key feedback sounds, and general application notification sounds. These audio streams are short, discontinuous, and have the lowest information importance. Under extreme resource contention, slight delays, quality degradation, or even temporary suppression can be allowed in exchange for the absolute unobstructed flow of critical audio channels.

[0061] The target protocol priority of the target Bluetooth audio device and the protocol priority corresponding to each currently accessed audio device in the first Bluetooth chip are determined using the above method. Based on the target protocol priority, currently accessed audio devices with a lower priority than the target protocol priority are identified in the first Bluetooth chip. All existing connections on the first chip are scanned to identify devices with a lower service priority than the newly requested device. For example, if the target Bluetooth audio device of the newly requested device uses the HFP protocol, and all existing connections on the first chip are A2DP devices playing music, which have a lower priority than the target Bluetooth audio device, these A2DP devices playing music are added to the migration candidate list to ensure that the migration operation does not interrupt more important existing services (such as another ongoing call). The currently accessed audio devices in the first Bluetooth chip are migrated to the second Bluetooth chip, with the first Bluetooth chip determining the target Bluetooth chip. If there is not enough capacity in the second Bluetooth chip, the currently accessed audio devices are paused, and audio playback on the currently accessed audio devices is resumed after the call on the target Bluetooth audio device ends.

[0062] During this process, the following scenarios may occur: First, if the first Bluetooth chip does not have any currently accessed audio devices with a priority lower than the target protocol priority, then the second Bluetooth chip will search for accessed audio devices, using the second Bluetooth chip as the outgoing chip and the first Bluetooth chip as the incoming chip. If the second Bluetooth chip still does not have any currently accessed audio devices with a priority lower than the target protocol priority, then the third Bluetooth chip will be checked for any available accessed audio devices to be migrated out, in descending order of available load weight. This process continues. In an extremely rare but generally uncommon situation, where none of the Bluetooth chips have any currently accessed audio devices with a priority lower than the target protocol priority, the process will wait for the first Bluetooth chip to release an audio device, and then use that chip as the target Bluetooth chip for the target Bluetooth audio device.

[0063] The second scenario is that there are multiple currently accessed audio devices in the first Bluetooth chip with a priority lower than the target protocol priority. In this case, when filtering out audio devices, the device with a lower switching sensitivity can be selected as the outgoing device based on the switching sensitivity of each currently accessed audio device.

[0064] When no directly available Bluetooth chip is available, meaning the available load weight of all chips is less than the protocol weight of the new request, existing resources are adjusted to meet new high-priority or necessary connection requests. This overcomes the limitation of solely relying on the static remaining capacity of chips, enhancing the system's connection acceptance and service assurance capabilities. When no available Bluetooth chip is available, the first and second Bluetooth chips are determined sequentially according to their available load weights from highest to lowest. Chips with relatively light and second-light loads in the system are identified first and used as the main components for resource adjustment. When resource constraints necessitate migration, decisions are made based on a preset priority strategy, ensuring that resource adjustments are made to guarantee higher-priority services and ensure the service quality of critical services (such as answering calls). By migrating one or more existing low-priority connections from the first Bluetooth chip to the second Bluetooth chip, sufficient resource space is freed up on the first Bluetooth chip, which is then used as the target Bluetooth chip to establish new high-priority connections. This demonstrates the system's ability to dynamically reorganize resources and solves the problem of being unable to respond to new important connection requests when the system is fully or nearly fully loaded. By migrating, the continuity of some low-priority service connections is maintained, rather than interrupted, while prioritizing the immediate access of high-priority services. This enables dynamic and on-demand allocation of system resources among different service types, significantly improving the system's service level and emergency response capabilities.

[0065] Step S103: Establish a connection between the target Bluetooth audio device and the target Bluetooth chip to enable audio stream transmission.

[0066] An audio stream refers to a sequence of encoded digital audio data packets transmitted over a Bluetooth audio connection. Its specific content, format, and transmission direction are determined by the type of Bluetooth audio protocol used and its defined role. Establishing a connection between the target Bluetooth audio device and the target Bluetooth chip essentially involves the vehicle's infotainment system commanding the target Bluetooth chip to connect according to the protocols and roles supported by the target Bluetooth audio device, and constructing the corresponding protocol stack data channel to provide a logical path for audio stream transmission. Once the connection is established, the target Bluetooth chip will be responsible for processing all audio data related to the target Bluetooth audio device.

[0067] The following section details the technical process of establishing a connection to enable audio streaming, using specific application scenarios as examples: Scenario 1: In-car multi-screen entertainment system connected to independent Bluetooth headsets. In this scenario, the target Bluetooth audio device is the passenger's Bluetooth headset (A2DP). The audio stream source is the in-car entertainment system (such as the player application on the passenger side screen or rear screen). After the central dispatcher identifies the target Bluetooth chip, it controls the target Bluetooth chip to establish an A2DP connection with the target Bluetooth headset. After the connection is established, the audio rendering engine of the corresponding screen in the in-car system sends PCM audio data into the audio frame to direct the data to the driver interface of the target Bluetooth chip. The protocol stack of the target Bluetooth chip encodes and encapsulates the audio data and sends it to the paired Bluetooth headset through its RF antenna. Audio stream direction: from the target Bluetooth chip to the target Bluetooth headset.

[0068] Scenario 2: Music from a mobile phone is played through the car's audio system. In this scenario, the target Bluetooth audio device is the user's smartphone (A2DP); the audio stream source is the music playback application on the phone. After identifying the target Bluetooth chip, an A2DP connection is established between the target Bluetooth chip and the phone. The target Bluetooth chip receives the audio data packets initiated by the phone, performs decoding, clock synchronization, and other processing, and then sends them to the car's physical speakers for playback. The audio stream originates from the phone, is received by the target Bluetooth chip, and ultimately reaches the car's audio system. The car's audio system acts as a relay and processing node for the audio stream.

[0069] Scenario 3: Bluetooth phone call. In this scenario, the target device is the user's smartphone (HFP). The audio stream consists of two real-time bidirectional audio streams: downlink (other party's voice) and uplink (your own voice). Upon requesting a call, an HFP connection is established between the target Bluetooth chip and the phone. In the downlink stream, the phone sends the other party's voice data packets from the cellular network to the target Bluetooth chip, which decodes and outputs them to the vehicle's speakers. In the uplink stream, the vehicle's microphone captures the user's voice input, which is then encoded by the target Bluetooth chip and sent to the phone. The entire process requires the chip to process the bidirectional audio in real-time with low latency and maintain a high-priority RF link. The audio stream is transmitted bidirectionally between the target Bluetooth chip and the phone. The vehicle's infotainment system uses this chip to capture and play the audio.

[0070] Based on the results of the aforementioned intelligent decision-making, precise audio stream routing operations are performed. Since the connection is established on the chip with the most suitable load, it is in a more stable transmission environment, reducing the probability of audio stuttering and increased latency caused by intense competition for chip resources, thereby improving the service quality of individual connections and the overall system.

[0071] After transmitting the audio stream from the target Bluetooth audio device to the target Bluetooth chip, it's crucial to ensure a consistently high-quality audio playback experience once the connection is established. Finding a suitable target chip with the appropriate capacity based on available load weights for a new device and enabling the connection primarily ensures the feasibility of the connection (i.e., the chip's current capacity allows for connection). However, this doesn't guarantee that after the connection is established, the chip's overall resource status will continue to adequately support the audio playback of all connected devices while handling the increased load. For example, a new A2DP device might be assigned to a chip whose current available load weight is slightly greater than the device's protocol weight. In this case, although all devices are logically connected, the chip's actual processing resources are already strained or on the verge of oversaturation. During actual playback, this resource strain directly translates into increased audio stream processing latency and insufficient buffering, causing noticeable stuttering, audio dropouts, or increased latency for all audio devices (both new and existing) on ​​the chip, severely impacting the user experience.

[0072] After step S103, after establishing a connection between the target Bluetooth audio device and the target Bluetooth chip to achieve audio stream transmission, the method further includes: monitoring the real-time access load weight of each Bluetooth chip, determining the load balancing index corresponding to each Bluetooth chip by the ratio of the real-time access load weight to the load threshold; and performing dynamic load migration on unbalanced Bluetooth chips that meet preset requirements based on the load balancing index of each Bluetooth chip.

[0073] After transmitting the audio stream from the target Bluetooth audio device to the target Bluetooth chip, the real-time access load weight of each Bluetooth chip is monitored. The load weight value is obtained by identifying all currently accessing audio devices and their corresponding protocol types on each Bluetooth chip. The weight values ​​of all connections belonging to the same Bluetooth chip are summed. This summation is performed once per monitoring cycle to obtain the real-time access load weight reflecting the latest load status. After obtaining the real-time load data for each chip, the load balancing index for each Bluetooth chip is determined by the ratio of the real-time access load weight to the load threshold. The currently effective load threshold for each chip is read; this load threshold is preferably a dynamic load threshold after temperature dynamic compensation. Then, for each chip, the real-time access load weight is divided by its load threshold to obtain the load balancing index. The absolute load values ​​of different chips are normalized to their own capability range. For example, a chip with a load weight of 8 and a dynamic load threshold of 10 has a load balancing index of 0.8; another chip with a load weight of 6 and a load balancing index of 8 has a load balancing index of 0.75. By comparing 0.8 and 0.75, we can more scientifically determine which chip is relatively more overloaded, rather than assuming that a chip with a load of 8 is necessarily under more stress than a chip with a load of 6.

[0074] Based on the load balancing metrics of each Bluetooth chip, dynamic load migration is performed on unbalanced Bluetooth chips that meet preset requirements. This is specifically achieved through the following methods: Calculate the difference between the load balancing metrics of any two Bluetooth chips using the load balancing metric for each chip. Read the load balancing metric array of all N Bluetooth chips and iterate through all possible chip pairs (e.g., chip i and chip j, where i ≠ j) using a double loop. For each pair (i, j), calculate the absolute difference in their load balancing metrics. Identify the Bluetooth chip whose difference exceeds a preset imbalance threshold (this threshold can be set according to actual needs). Compare each calculated difference with the preset imbalance threshold. If one or more differences exceed the threshold, an imbalance is identified, triggering dynamic load migration. Based on the load balancing metrics, determine the chip to be migrated and the target chip to be migrated among the imbalanced Bluetooth chips. For each difference exceeding the threshold, record the corresponding chip indices i and j. Typically, the chip with the larger load balancing metric value between chip i and chip j is marked as the chip to be migrated (overloaded side), and the chip with the smaller value is marked as the target chip to be migrated (lightly loaded side).

[0075] The system retrieves the load device profiles and load priorities of multiple access loads connected to the chip to be migrated, queries the global connection table, and lists all active Bluetooth devices on the chip. For each listed device, it retrieves historical data from its continuously maintained device profile database, including the historical migration success rate of the device in previous migrations and the historical average audio packet loss rate of audio transmission in each connection. Simultaneously, it determines the load priority based on preset rules according to the type of audio currently being played by the device (e.g., movie sound effects from the rear screen).

[0076] To extract risk predictions directly useful for current decision-making from historical data, a handover sensitivity index is determined for each access load through load device profiling. The handover sensitivity index is calculated by combining the historical migration success rate and historical average audio packet loss rate for each device. The calculation principle here is that the higher the historical migration success rate and the lower the historical packet loss rate of a device, the lower the calculated index value, meaning a lower risk of problems during this migration; conversely, a high index value indicates a higher migration risk. The historical migration success rate is defined as the ratio of the number of successful migration attempts to the total number of attempts, ranging from [0, 1]. The historical average audio packet loss rate is defined as the ratio of the average number of audio data packets lost per unit time to the total number of packets sent in each audio connection session. This ratio reflects the link quality and anti-interference capability of the device under typical connection conditions, typically ranging from [0, 1].

[0077] First, the raw historical data undergoes a risk-based transformation, generating two intermediate risk factors. The first risk factor is derived from the historical migration success rate, calculated by subtracting the historical migration success rate from a value of 1. Therefore, a device with a high historical migration success rate will have a lower first risk factor value, indicating a lower risk of migration failure. The second risk factor directly uses the historical average audio packet loss rate; a device with a low historical packet loss rate will also have a lower second risk factor value, indicating a lower connection quality risk. These two risk factors are then combined using a pre-defined weighted fusion formula to form the final handover sensitivity index. This formula is expressed as: Handover Sensitivity Index = (First Weighting Coefficient × First Risk Factor) + (Second Weighting Coefficient × Second Risk Factor). The first and second weighting coefficients are pre-configured positive parameters that determine the contribution ratio of migration failure risk and connection quality risk to the final index, respectively. The specific values ​​of the weighting coefficients can be calibrated based on the Bluetooth environment stability of the actual vehicle model and the user experience focus. Through the above calculations, for a device, the higher its historical migration success rate and the lower its historical average audio packet loss rate, the smaller the calculated first and second risk factors will be, and the lower the weighted sum of the resulting handover sensitivity index value will also be. This result clearly indicates that the device is predicted to be insensitive to connection switching, and the risk of problems occurring in the upcoming migration operation is relatively small. Conversely, the handover sensitivity index value increases, indicating a higher migration risk. The handover sensitivity index obtained from this calculation will be used, along with the device's load priority, as a key quantitative basis for screening and determining the load to be migrated in subsequent steps, thereby realizing data-driven, risk-aware intelligent migration decision-making at the system level. For new devices that do not yet have sufficient historical data, the system can assign them neutral default historical values ​​for calculation, and then conduct accurate evaluation after they have accumulated sufficient behavioral data.

[0078] Based on switching sensitivity indicators and load priority, the loads to be migrated are determined, and their audio streams are migrated to the target migration chip. The switching sensitivity indicators and load priority of each candidate device are comprehensively considered. Following the principles of minimizing risk and impact, devices with low switching sensitivity values, low migration risk, and low load priority are prioritized as the loads to be migrated. After selecting the target device, a new connection is first established on the target migration chip through the underlying Bluetooth protocol stack. Then, the audio data stream is smoothly switched from the old chip's link to the new chip's link in a very short time. After a successful switch, the old link is cleaned up. For the user, the entire process may only manifest as a barely perceptible, minute audio fluctuation. After the migration is complete, the load on the chip to be migrated decreases, while the load on the target migration chip increases, reducing the load pressure difference between the two. This restores the device from a detected imbalance to a more balanced and stable operating point, ensuring that all connected devices, especially those previously on resource-constrained chips, can continue to enjoy a smooth and clear audio playback experience.

[0079] The above-described technical solutions adopted in the embodiments of this application can achieve the following beneficial effects: This approach transforms different types of audio connection requests into quantifiable and comparable protocol weight parameters. Audio protocol types, such as the HFP protocol for two-way real-time voice communication and the A2DP protocol for one-way media streaming, represent different service quality requirements, data processing complexity, and system resource consumption levels. By predefining corresponding protocol weights for each protocol type, the inherent resource requirements of different audio services can be quantitatively assessed. Secondly, by acquiring the chip load parameters of each of the pre-configured multiple Bluetooth chips, global real-time monitoring of all available Bluetooth chip resources within the system is achieved. This solves the technical problem of isolated chip operating status information in existing technologies. By acquiring the current access load information and load threshold of each chip, the overall resource distribution and remaining capacity can be monitored in real time. Furthermore, by combining protocol weights and Bluetooth chip load parameters... The system identifies the target Bluetooth chip from multiple Bluetooth chips, selecting the most suitable one from multiple candidate chips. This solves the problem of uneven resource utilization among multiple chips, ensuring that new connection requests are not blindly assigned to the first available or pre-specified chip, but are instead guided to a relatively idle chip with sufficient capacity. This achieves an initial balanced distribution of load, avoiding premature overloading of a single chip while other chips are underloaded or idle, thus improving overall connection capacity and stability from the source. Furthermore, based on the results of the aforementioned intelligent decision-making, precise audio stream routing is performed. Since the connection is established on the chip with the most suitable load, it is in a more stable transmission environment, reducing the probability of audio stuttering and increased latency due to intense chip resource competition, thereby improving the service quality of individual connections and the overall system.

[0080] Figure 2 This is a schematic diagram of the structure of a vehicle provided in an embodiment of this application. For example, as shown... Figure 2 As shown, the vehicle includes a memory 201 and a processor 202. The memory 201 stores executable program code 2011, and the processor 202 is used to call and execute the executable program code 2011 to perform the vehicle Bluetooth connection method.

[0081] This embodiment can divide the vehicle into functional modules according to the above method example. For example, each function can be assigned to a separate module, or two or more functions can be integrated into one processing module. The integrated module can be implemented in hardware. It should be noted that the module division in this embodiment is illustrative and only represents one logical functional division. In actual implementation, there may be other division methods.

[0082] It should be noted that all relevant content of each step involved in the above method embodiments can be referenced from the functional description of the corresponding functional module, and will not be repeated here.

[0083] The vehicle provided in this embodiment is used to execute the above-described vehicle Bluetooth connection method, and therefore can achieve the same effect as the above implementation method.

[0084] When using integrated units, the vehicle may include a processing module and a storage module. The processing module is used to control and manage the vehicle's actions. The storage module supports the vehicle in executing program code and data.

[0085] The processing module may be a processor or a controller, which can implement or execute various exemplary logic blocks, modules, and circuits as disclosed in this application. The processor may also be a combination of computing functions, such as a combination of one or more microprocessors, a combination of digital signal processing (DSP) and a microprocessor, etc., and the storage module may be a memory.

[0086] This embodiment also provides a computer-readable storage medium (including but not limited to disk storage, CD-ROM, optical storage, etc.) storing computer program code. When the computer program code is run on a computer, the computer executes the above-mentioned related method steps to implement the vehicle Bluetooth connection method provided in the above embodiment.

[0087] This embodiment also provides a computer program product that, when run on a computer, causes the computer to perform the aforementioned steps to implement the vehicle Bluetooth connection method provided in the above embodiment.

[0088] The beneficial effects of the above embodiments can be referred to the beneficial effects of the corresponding methods provided above, and will not be repeated here.

[0089] Through the above description of the embodiments, those skilled in the art will understand that, for the sake of convenience and brevity, only the division of the above functional modules is used as an example. In actual applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above.

[0090] In the embodiments provided in this application, it should be understood that the disclosed apparatus and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of modules or units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another device, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between devices or units may be electrical, mechanical, or other forms.

[0091] In the description of this application, it should be understood that if the terms "upper", "lower", "front", "rear", "left" and "right" are used to indicate the orientation or positional relationship based on the orientation or positional relationship shown in the drawings, they are only for the convenience of describing the present invention and simplifying the description, and do not indicate or imply that the position or element referred to must have a specific orientation, or be constructed and operated in a specific orientation, and therefore should not be construed as a limitation of this application.

[0092] It should be noted that, in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. It should also be noted that the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such process, method, article, or apparatus. Unless otherwise specified, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes the element.

[0093] The above are merely embodiments of this application and are not intended to limit the scope of this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of the claims of this application.

Claims

1. A vehicle Bluetooth connection method, characterized in that, include: In response to a connection request from a target Bluetooth audio device, the type of audio protocol that the target Bluetooth audio device negotiates access with is determined, and the corresponding protocol weight is determined based on the audio protocol type. The chip load parameters of each of the multiple preset Bluetooth chips are obtained, so as to determine the target Bluetooth chip among the multiple Bluetooth chips by means of the protocol weight and the chip load parameters of the Bluetooth chip, wherein the chip load parameters include the current access load information and the load threshold corresponding to the Bluetooth chip; Establish a connection between the target Bluetooth audio device and the target Bluetooth chip to enable audio stream transmission.

2. The vehicle Bluetooth connection method according to claim 1, characterized in that, The target Bluetooth chip is determined from among the plurality of Bluetooth chips using the protocol weights and the chip load parameters of the Bluetooth chip, specifically including: The current access load weight corresponding to each Bluetooth chip is determined by the current access load information of each Bluetooth chip, wherein the current access load information includes the access protocol type of the current access device; Based on the current access load weight and the load threshold of the Bluetooth chip, determine the available load weight of each Bluetooth chip; The target Bluetooth chip is determined from among the plurality of Bluetooth chips based on the relationship between the protocol weight and the available payload weight of the Bluetooth chip.

3. The vehicle Bluetooth connection method according to claim 2, characterized in that, Based on the relationship between the protocol weights and the available payload weights of the Bluetooth chips, the target Bluetooth chip is determined from among the plurality of Bluetooth chips, specifically including: Filter available Bluetooth chips whose available payload weight is not greater than the protocol weight; When one of the available Bluetooth chips exists, the target Bluetooth chip is determined based on the available Bluetooth chip; When multiple available Bluetooth chips exist, the target Bluetooth chip is determined by the maximum available load weight.

4. The vehicle Bluetooth connection method according to claim 3, characterized in that, The method further includes: When no available Bluetooth chip is available, the first Bluetooth chip and the second Bluetooth chip are determined in descending order of available load weights. Determine the target protocol priority corresponding to the target Bluetooth audio device, and based on the target protocol priority, determine the currently accessed audio device with a priority lower than the target protocol priority in the first Bluetooth chip; The currently accessed audio device in the first Bluetooth chip is migrated to the second Bluetooth chip, and the target Bluetooth chip is determined by the first Bluetooth chip.

5. A vehicle Bluetooth connection method according to claim 1, characterized in that, After transmitting the audio stream from the target Bluetooth audio device to the target Bluetooth chip, the method further includes: Monitor the real-time access load weight of each Bluetooth chip, and determine the load balancing index corresponding to each Bluetooth chip by the ratio of the real-time access load weight to the load threshold. Based on the load balancing metrics of each Bluetooth chip, dynamic load migration is performed on unbalanced Bluetooth chips that meet preset requirements.

6. A vehicle Bluetooth connection method according to claim 5, characterized in that, Based on the load balancing metrics of each Bluetooth chip, dynamic load migration is performed on unbalanced Bluetooth chips that meet preset requirements, specifically including: Calculate the difference between the load balancing metrics of any two Bluetooth chips using the load balancing metrics of each Bluetooth chip. Bluetooth chips with a difference exceeding a preset imbalance threshold are identified as imbalanced Bluetooth chips, and dynamic load migration is triggered.

7. A vehicle Bluetooth connection method according to claim 6, characterized in that, Triggering dynamic load migration specifically includes: Based on the load balancing metrics, the chip to be migrated and the target chip to be migrated are determined among the unbalanced Bluetooth chips. Obtain the load device profile and load priority of multiple access loads connected to the chip to be migrated, wherein the load device profile includes the historical migration success rate and historical average audio packet loss rate corresponding to the access load; Based on the load device profile, the switching sensitivity indicators for each access load are determined; Based on the switching sensitivity index and the load priority, the load to be migrated is determined, and the audio stream of the load to be migrated is migrated to the target migration chip.

8. A vehicle Bluetooth connection method according to claim 1, characterized in that, The method further includes: The real-time chip temperature of each Bluetooth chip is detected and compared with a preset safe temperature threshold. When the real-time chip temperature exceeds the safe temperature threshold, the temperature exceedance is determined. The load threshold of each Bluetooth chip is determined by applying a threshold penalty to the basic load threshold corresponding to each Bluetooth chip based on the temperature exceedance.

9. A vehicle, characterized in that, include: At least one processor; as well as, A memory communicatively connected to the at least one processor; wherein, The memory stores instructions that can be executed by the at least one processor to implement the vehicle Bluetooth connection method as described in any one of claims 1 to 8.

10. A computer-readable storage medium storing computer-executable instructions, characterized in that, When the computer-executable instructions are executed by the processor, they implement the vehicle Bluetooth connection method as described in any one of claims 1 to 8.

Images