WO2025260847A1 - Collaborative processing method and apparatus for multiple bluetooth hosts, device, and storage medium - Google Patents

Abstract

The present application relates to the technical field of communications, and discloses a collaborative processing method and apparatus for Bluetooth hosts, a device, and a storage medium. The method comprises: before a first Bluetooth host executes a first operation instruction, acquiring first operation information of a second Bluetooth host, the first operation information indicating an operation state of the second Bluetooth host; and when the operation state of the second Bluetooth host does not conflict with the first operation instruction, interacting with a Bluetooth controller, so as to execute the first operation instruction. The second Bluetooth host and the first Bluetooth host are connected to the same Bluetooth controller, i.e., a multi-Bluetooth host coexistence scenario. The method can avoid the conflict problem of simultaneous execution of operation instructions by multiple Bluetooth hosts, realizing orderly scheduling of the operation instructions, thereby realizing parallel work of the multiple Bluetooth hosts.

Description

Methods, apparatus, devices and storage media for collaborative processing of multiple Bluetooth hosts

This application claims priority to Chinese Patent Application No. 202410807944.3, filed on June 20, 2024, entitled “Cooperative Processing Method, Apparatus, Device and Storage Medium for Multiple Bluetooth Hosts”, the entire contents of which are incorporated herein by reference.

Technical Field

This application relates to the field of communication technology, and in particular to a method, apparatus, device and storage medium for collaborative processing of multiple Bluetooth hosts.

Background Technology

In the field of communication technology, Bluetooth communication technology, with its characteristics of standardization, low power consumption, and multiple connections, has been widely used in various fields, such as smart homes, smartphones, wearable devices, and automotive infotainment systems. However, for devices with multiple Bluetooth hosts coexisting collaboratively, since all multiple Bluetooth hosts interact with the same Bluetooth controller on the device, collaborative processing is required among the multiple Bluetooth hosts to avoid conflicts arising from simultaneous interactions.

In related technologies, multiple Bluetooth hosts collaborate using a negotiated time-sharing working mode. Taking dual Bluetooth hosts as an example, when the first Bluetooth host has control of the Bluetooth controller, it interacts with the Bluetooth controller, and the second Bluetooth host is not working. After the first Bluetooth host finishes its work, it hands over control to the second Bluetooth host, and the second Bluetooth host begins to interact with the Bluetooth controller, at which point the first Bluetooth host stops working.

However, the aforementioned negotiated time-sharing working mode requires switching control of the Bluetooth controller back and forth between two Bluetooth hosts. Only one Bluetooth host can work at a time, resulting in low efficiency of the Bluetooth system and making it unsuitable for scenarios where multiple Bluetooth hosts work in parallel.

Summary of the Invention

This application provides a method, apparatus, device, and storage medium for collaborative processing of multiple Bluetooth hosts, used to enable multiple Bluetooth hosts to work in parallel.

Firstly, a collaborative processing method for multiple Bluetooth hosts is provided. This method includes: before a first Bluetooth host executes a first operation instruction, acquiring first operation information of a second Bluetooth host, the first operation information indicating the operation state of the second Bluetooth host; and, if the operation state of the second Bluetooth host does not conflict with the first operation instruction, interacting with a Bluetooth controller to execute the first operation instruction. The second Bluetooth host and the first Bluetooth host are connected to the same Bluetooth controller, meaning this method is applicable to scenarios where two Bluetooth hosts coexist. Furthermore, if the number of first or second Bluetooth hosts can be two or more, then this method is also applicable to scenarios where two or more Bluetooth hosts coexist.

In this method, taking the first Bluetooth host as an example, during operation, each time an operation command is initiated, the first Bluetooth host first obtains the operation information of the second Bluetooth host. This means the second Bluetooth host can work simultaneously with the first Bluetooth host. Only after confirming there is no conflict will the operation command be executed, rather than executing it directly. This avoids conflicts caused by multiple Bluetooth hosts executing operation commands simultaneously, achieving orderly scheduling of operation commands and thus enabling parallel operation of multiple Bluetooth hosts.

The operation status can indicate the execution status of the operation command. Optionally, the operation status includes "operating," "operation completed," or "idle." For example, the first operation information includes a first flag indicating that the operation status of the second Bluetooth host is "operation completed"; or, the first operation information includes a second flag indicating that the operation status of the second Bluetooth host is "idle." The absence of conflict between the operation status of the second Bluetooth host and the first operation command means that the execution status of the second Bluetooth host's operation command does not affect the execution of the first Bluetooth host's first operation command. For example, the second Bluetooth host does not execute operation commands that conflict with the first operation command, resulting in a higher success rate for the first Bluetooth host to execute the first operation command under these conflict-free conditions.

In one possible implementation, the method of obtaining the first operation information of the second Bluetooth host may include: sending a first query instruction to the second Bluetooth host, the first query instruction being used by the second Bluetooth host to send the first operation information of the second Bluetooth host to the first Bluetooth host; and receiving the first operation information sent by the second Bluetooth host.

By sending a query command to the other Bluetooth host, the operation information of the other Bluetooth host is obtained, realizing collaborative interaction between multiple Bluetooth hosts. Since the first operation information obtained by querying is the operation information of the other Bluetooth host's response, the accuracy of the first operation information can be guaranteed, making the reliability of the obtained first operation information higher.

Optionally, the first query command is used by the second Bluetooth host to send first operation information to the first Bluetooth host when there is no conflict between the second Bluetooth host's operating state and the first operation command. The first operation information indicates that there is no conflict between the second Bluetooth host's operating state and the first operation command. In this method, a response is only sent when there is no conflict between the second Bluetooth host's operating state and the first operation command, avoiding the need to resend the query command if a conflict arises between the response's operating state and the first operation command. That is, one query command is sent for each operation command, and the operation command can be executed only after a response to the query command, ensuring that no conflict occurs where operation commands are executed simultaneously.

In one possible implementation, after executing the first operation instruction, upon completion of the first operation instruction, a second operation message is sent to the second Bluetooth host. The second operation message instructs the first Bluetooth host to complete the execution of the first operation instruction. Thus, synchronization of operation information among multiple Bluetooth hosts is achieved through collaborative interaction.

In one possible implementation, the first Bluetooth host records collaboration information, which indicates first operation information of the second Bluetooth host. In this case, obtaining the first operation information of the second Bluetooth host can include reading the collaboration information recorded by the first Bluetooth host to obtain the first operation information of the second Bluetooth host. By recording the operation information of the other Bluetooth host, the first operation information can be obtained quickly, improving the efficiency of obtaining the first operation information.

In one possible implementation, coordination information is recorded before acquiring the first operation information of the second Bluetooth host. Optionally, a second query command is received, which is sent before the second Bluetooth host executes the second operation command; third operation information is sent to the second Bluetooth host, indicating that the operation status of the first Bluetooth host does not conflict with the second operation command; and fourth operation information is recorded on the first Bluetooth host as coordination information, indicating that the second Bluetooth host is executing the second operation command. Alternatively, a fifth operation information is received, which is sent to the first Bluetooth host after the second operation command has been executed, indicating that the second Bluetooth host has completed the second operation command; and the fifth operation information of the second Bluetooth host is recorded on the first Bluetooth host as coordination information.

In this scenario, before executing the second operation command, the second Bluetooth host also queries the first Bluetooth host for its operation information. Since the second Bluetooth host begins executing the second operation command after the first Bluetooth host responds with the third operation information, the fourth operation information indicating that the second Bluetooth host is executing the second operation command can be recorded as coordination information. Furthermore, the second Bluetooth host will also notify the first Bluetooth host after completing the second operation command; therefore, the fifth operation information indicating that the second Bluetooth host has completed the second operation command can be recorded as coordination information. This achieves real-time recording of coordination information, enabling real-time synchronization of operation information among multiple Bluetooth hosts.

In one possible implementation, the absence of conflict between the operating state of the second Bluetooth host and the first operation instruction includes: the second Bluetooth host not executing an operation instruction of the same type as the first operation instruction. This approach avoids multiple Bluetooth hosts simultaneously executing the same type of operation instruction, while allowing different types of operation instructions to be executed simultaneously without interference between them. Alternatively, the absence of conflict between the operating state of the second Bluetooth host and the first operation instruction includes: the second Bluetooth host not executing any operation instruction. This approach avoids multiple Bluetooth hosts simultaneously executing the same or different types of operation instructions, further preventing any potential conflicts.

In one possible implementation, the first operation instruction is used to update the scanning parameters of the Bluetooth controller, and the first operation information includes the first scanning parameters of the second Bluetooth host. In this case, the interaction with the Bluetooth controller may include: if the second scanning parameters of the first Bluetooth host are greater than or equal to the scanning range indicated by the first scanning parameters, sending the second scanning parameters to the Bluetooth controller, the second scanning parameters being used by the Bluetooth controller to update the scanning parameters to the second scanning parameters; or, if the second scanning parameters are less than the scanning range indicated by the first scanning parameters, sending the first scanning parameters to the Bluetooth controller, the first scanning parameters being used by the Bluetooth controller to update the scanning parameters to the first scanning parameters.

Therefore, multiple Bluetooth hosts can not only exchange scanning status but also scanning parameters. When the scanning parameters of multiple Bluetooth hosts are different, the scanning parameters of the Bluetooth controller can be uniformly updated to the scanning parameters with the largest scanning range among the multiple Bluetooth hosts. This makes the scanning range of the Bluetooth controller based on the updated scanning parameters larger than the scanning range of each Bluetooth host's scanning parameters. As a result, multiple Bluetooth hosts can reuse the scanning resources of the Bluetooth controller. That is, the scanning data of the Bluetooth controller based on the updated scanning parameters can be used by the first Bluetooth host and the second Bluetooth host at the same time.

In one possible implementation, the first operation instruction is used to establish a Bluetooth connection, and the first operation information includes a first number of Bluetooth connections established by the second Bluetooth host. The first number is used to control a second number of Bluetooth connections established by the first Bluetooth host, and the sum of the second number and the first number is less than or equal to a reference number of Bluetooth connections established by the Bluetooth controller. Thus, multiple Bluetooth hosts can not only exchange connection statuses but also exchange connection counts, achieving a reasonable allocation of connection resources among multiple Bluetooth hosts.

In one possible implementation, before the first Bluetooth host executes the first operation command, it is also necessary to determine the working state of the second Bluetooth host. That is, if the second Bluetooth host is in the "exit from sleep" state, the operation information of the second Bluetooth host is obtained. If the operating state of the second Bluetooth host does not conflict with the first operation command, it interacts with the Bluetooth controller to execute the first operation command. Here, the second Bluetooth host being in the "exit from sleep" state indicates that the second Bluetooth host is working, which is a scenario of multiple Bluetooth hosts working in parallel. The operation information of the second Bluetooth host is only obtained in a parallel working scenario to avoid conflicts caused by multiple Bluetooth hosts working in parallel.

In another possible implementation, when the second Bluetooth host is in sleep mode, it directly interacts with the Bluetooth controller to execute the first operation command, without needing to obtain the operation information of the second Bluetooth host. Here, the second Bluetooth host being in sleep mode indicates that it is not working, thus operating in a single Bluetooth host scenario, allowing for direct operation execution and saving the overhead of collaborative processing.

Secondly, a multi-Bluetooth host collaborative processing apparatus is provided for executing the method in the first aspect or any possible implementation thereof. Specifically, the multi-Bluetooth host collaborative processing apparatus includes modules for executing the method in the first aspect or any possible implementation thereof. In one possible implementation, the apparatus includes:

The acquisition module is used to acquire the first operation information of the second Bluetooth host before the first Bluetooth host executes the first operation instruction. The second Bluetooth host and the first Bluetooth host are connected to the same Bluetooth controller. The first operation information indicates the operation status of the second Bluetooth host.

The execution module is used to interact with the Bluetooth controller to execute the first operation command when there is no conflict between the operation state of the second Bluetooth host and the first operation command.

In one possible implementation, the acquisition module is configured to send a first query instruction to the second Bluetooth host, the first query instruction being used by the second Bluetooth host to send first operation information of the second Bluetooth host to the first Bluetooth host; and to receive the first operation information sent by the second Bluetooth host.

In one possible implementation, the device further includes: a first transmitting module, configured to send second operation information to a second Bluetooth host upon completion of the execution of the first operation instruction, wherein the second operation information instructs the first Bluetooth host to complete the execution of the first operation instruction.

In one possible implementation, the first Bluetooth host records coordination information that indicates first operational information of the second Bluetooth host.

In one possible implementation, the device further includes: a receiving module for receiving a second query instruction, the second query instruction being sent before the second Bluetooth host executes the second operation instruction; a second sending module for sending third operation information to the second Bluetooth host, the third operation information indicating that the operation status of the first Bluetooth host does not conflict with the second operation instruction; and a recording module for recording fourth operation information as coordination information on the first Bluetooth host, the fourth operation information indicating that the second Bluetooth host is executing the second operation instruction.

In one possible implementation, the receiving module is further configured to receive fifth operation information, which is sent to the first Bluetooth host after the second operation instruction has been completed, and the fifth operation information instructs the second Bluetooth host to complete the second operation instruction; the recording module is further configured to record the fifth operation information as coordination information in the first Bluetooth host.

In one possible implementation, the fact that the operating state of the second Bluetooth host does not conflict with the first operating instruction includes: the second Bluetooth host does not execute an operating instruction of the same type as the first operating instruction, or the second Bluetooth host does not execute any operating instruction.

In one possible implementation, the first operation instruction is used to update the scanning parameters of the Bluetooth controller, and the first operation information includes the first scanning parameters of the second Bluetooth host; the execution module is used to send the second scanning parameters to the Bluetooth controller when the second scanning parameters of the first Bluetooth host are greater than or equal to the scanning range indicated by the first scanning parameters, and the second scanning parameters are used by the Bluetooth controller to update the scanning parameters to the second scanning parameters; or, when the second scanning parameters are less than the scanning range indicated by the first scanning parameters, the first scanning parameters are sent to the Bluetooth controller, and the first scanning parameters are used by the Bluetooth controller to update the scanning parameters to the first scanning parameters.

In one possible implementation, the first operation instruction is used to establish a Bluetooth connection, and the first operation information includes a first number of Bluetooth connections established by the second Bluetooth host. The first number is used to control a second number of Bluetooth connections established by the first Bluetooth host, and the sum of the second number and the first number is less than or equal to a reference number of Bluetooth connections established by the Bluetooth controller.

In one possible implementation, the acquisition module is used to acquire the operation information of the second Bluetooth host when the second Bluetooth host is in the working state of exiting sleep.

Thirdly, a terminal device is provided, comprising: a processor coupled to a memory, the memory storing at least one program instruction or code, the at least one program instruction or code being loaded and executed by the processor to enable the terminal device to implement the multi-Bluetooth host collaborative processing method as described in the first aspect or any one of the first aspects.

Optionally, the processor may be one or more, and the memory may be one or more.

Optionally, the memory may be integrated with the processor, or the memory may be separated from the processor.

In the specific implementation process, the memory can be a non-transitory memory, such as read-only memory (ROM), which can be integrated with the processor on the same chip or set on different chips. This application does not limit the type of memory or the way the memory and processor are set.

Fourthly, a computer-readable storage medium is provided, the storage medium storing at least one instruction, the instruction being loaded and executed by a processor to enable a computer to implement the methods in the above aspects.

Fifthly, a computer program (product) is provided, the computer program (product) comprising: computer program code, which, when executed by a computer, causes the computer to perform the methods described in the above aspects.

In a sixth aspect, a chip is provided, including a processor for retrieving and executing instructions stored in a memory, causing a communication device on which the chip is mounted to perform the methods described in the preceding aspects.

In a seventh aspect, another chip is provided, comprising: an input interface, an output interface, a processor, and a memory, wherein the input interface, the output interface, the processor, and the memory are connected via an internal connection path, and the processor is used to execute code in the memory, wherein when the code is executed, the processor is used to perform the methods in the foregoing aspects.

It should be understood that the beneficial effects achieved by the technical solutions of the second to seventh aspects of this application and their corresponding possible implementations can be found in the technical effects of the first aspect and its corresponding possible implementations described above, and will not be repeated here. Furthermore, the multi-Bluetooth host collaborative processing device mentioned in the second aspect can be the chip mentioned in the sixth or seventh aspect, or the multi-Bluetooth host collaborative processing device can also be the terminal device mentioned in the third aspect.

Attached Figure Description

Figure 1 is a schematic diagram of a multi-Bluetooth application scenario provided by an embodiment of this application;

Figure 2 is a schematic diagram of a Bluetooth communication system provided in an embodiment of this application;

Figure 3 is a flowchart of a collaborative processing method for multiple Bluetooth hosts provided in an embodiment of this application;

Figure 4 is a flowchart of another collaborative processing method for multiple Bluetooth hosts provided in an embodiment of this application;

Figure 5 is an interactive schematic diagram of a collaborative processing method for multiple Bluetooth hosts provided in an embodiment of this application;

Figure 6 is an interactive schematic diagram of another collaborative processing method for multiple Bluetooth hosts provided in an embodiment of this application;

Figure 7 is a schematic diagram of the structure of a collaborative processing device for multiple Bluetooth hosts provided in an embodiment of this application;

Figure 8 is a structural schematic diagram of a terminal device provided in an embodiment of this application;

Figure 9 is a schematic diagram of the structure of another terminal device provided in an embodiment of this application;

Figure 10 is a schematic diagram of a terminal system architecture provided in an embodiment of this application.

Detailed Implementation

To make the objectives, technical solutions, and advantages of this application clearer, the embodiments of this application will be described in further detail below with reference to the accompanying drawings.

With the development of Bluetooth communication, devices with Bluetooth communication capabilities are becoming increasingly common. In practical applications, when a Bluetooth communication system runs for extended periods, the device's processor needs to process Bluetooth data for a long time, leading to a sharp increase in device power consumption. Therefore, to reduce the overall power consumption of devices, the technology of multiple Bluetooth hosts coexisting has emerged. Taking dual Bluetooth host coexistence as an example, two Bluetooth hosts are deployed on the device's main processor and coprocessor, respectively, with each Bluetooth host running its own Bluetooth application. The Bluetooth hosts can wirelessly connect to at least one Bluetooth peripheral via Bluetooth technology, thereby enabling data transmission and communication functions. Bluetooth peripherals include, but are not limited to, Bluetooth headsets, Bluetooth mice, Bluetooth keyboards, Bluetooth speakers, or Bluetooth printers. The main processor typically has a high clock speed and high power consumption, while the coprocessor typically has a low clock speed and low power consumption. Thus, long-running or high-load Bluetooth applications are offloaded from the main processor to the coprocessor, reducing the main processor's workload and thereby lowering the overall power consumption of the device and optimizing its battery life.

A Bluetooth system architecture typically consists of two parts: a Bluetooth host and a Bluetooth controller. Optionally, the Bluetooth host and controller can be deployed on two different chips. The Bluetooth host and controller interact via a Host Controller Interface (HCI) protocol, for example, by sending commands or transmitting data. The Bluetooth host is a logical entity defined as all layers below the non-core configuration file and above the HCI interface, while the Bluetooth controller is a logical entity defined as all layers below the HCI interface. For devices with multiple Bluetooth hosts coexisting, multiple Bluetooth hosts interact with the same Bluetooth controller through their respective HCI interfaces; that is, the Bluetooth controller has dual HCI interfaces. Therefore, if multiple Bluetooth hosts interact with the Bluetooth controller simultaneously, conflicts will occur.

In one related technology, two Bluetooth hosts deployed on the main processor and coprocessor negotiate time-sharing operation. For example, Bluetooth host A initially gains control of the Bluetooth controller and engages in HCI data exchange with it. After completing the HCI data exchange, Bluetooth host A sends a command to the Bluetooth controller to switch control, and the controller responds. Upon receiving the response, Bluetooth host A sends a request to Bluetooth host B to relinquish control, and B responds. Bluetooth host B then sends a command to the Bluetooth controller to acquire control, and the controller responds. Thus, Bluetooth host B gains control of the Bluetooth controller and engages in HCI data exchange with it. In other words, when Bluetooth host A on the main processor is working, Bluetooth host B on the coprocessor is not working.

In the aforementioned related technology one, the method of using dual Bluetooth hosts to control the Bluetooth controller in a time-sharing manner can solve the problem of conflict in the coexistence of dual Bluetooth hosts. However, the two Bluetooth hosts need to switch control of the Bluetooth controller back and forth. At any given time, one Bluetooth host exclusively holds control of the Bluetooth controller, while the other Bluetooth host completely loses control. Furthermore, the second Bluetooth host passively receives control from the first Bluetooth host and cannot actively acquire control. Once it gains control, since the other Bluetooth host is no longer working, it can directly execute the operation command upon initiation. Therefore, this method is only suitable for scenarios where dual Bluetooth hosts do not need to work simultaneously, such as single Bluetooth applications, and is not suitable for scenarios where dual Bluetooth hosts work in parallel, such as multi-Bluetooth applications.

In related technology two, the two Bluetooth hosts deployed on the main processor and coprocessor have a master-slave relationship. The master Bluetooth host deployed on the main processor controls the slave Bluetooth host on the coprocessor to conduct Bluetooth communication by issuing commands. This results in a clear master-slave relationship between the two Bluetooth hosts. The Bluetooth host on the coprocessor has little autonomy and can only execute the commands issued by the main processor. It does not have the ability to work independently and is still not suitable for scenarios with multiple Bluetooth applications, that is, scenarios where two Bluetooth hosts work in parallel.

This application provides a collaborative processing method for dual Bluetooth hosts, enabling parallel operation of two Bluetooth hosts. This method is applicable to communication scenarios involving multiple Bluetooth applications. Such scenarios may include multiple Bluetooth communication devices, each of which performs Bluetooth services with other Bluetooth communication devices. These services are triggered by multiple Bluetooth applications on any given Bluetooth communication device. These applications are deployed on at least two Bluetooth hosts of any given Bluetooth communication device and require parallel operation, i.e., there is a need for parallel operation of two Bluetooth hosts.

This application does not limit the type of Bluetooth communication device; it can be any terminal device with Bluetooth communication functionality. Optionally, the terminal device can be a personal computer (PC), mobile phone, anti-loss device, wireless headset, wearable device, pocket PC (PPC), tablet computer, virtual reality (VR) terminal device, augmented reality (AR) terminal device, wireless terminal in self-driving, wireless terminal in remote medical surgery, wireless terminal in smart grid, wireless terminal in transportation safety, wireless terminal in smart city, wireless terminal in smart home, or IoT terminal, etc.

For example, referring to Figure 1, which illustrates a multi-Bluetooth application scenario, the multiple Bluetooth communication devices are a mobile phone, an anti-loss device, wireless earphones, and a portable Android device (PAD). As shown in Figure 1, with the mobile phone as the center, the mobile phone's multiple Bluetooth hosts can conduct personal full-scenario services with multiple Bluetooth peripherals such as the anti-loss device, wireless earphones, and PAD. The service scenarios can include the following typical scenarios: after the mobile phone discovers the PAD, it may trigger a Bluetooth connection and Bluetooth data transmission, completing the update of information between the two ends of the data device; the wireless earphones, after being opened, are scanned and discovered by the mobile phone, requiring a Bluetooth connection; when a user uses the anti-loss device to find a lost device, the mobile phone needs to initiate a Bluetooth scan to discover the anti-loss device, and after discovery, the mobile phone connects to the anti-loss device via Bluetooth.

The aforementioned business scenarios are triggered by multiple Bluetooth applications. For example, the Bluetooth connection of the PAD is automatically triggered by the mobile phone's soft bus networking going online; the Bluetooth connection of the wireless headset is automatically triggered by the mobile phone's audio software in the background; the Bluetooth connection of the anti-loss device may be triggered by the user operating the mobile phone and by the mobile phone's network search function, or it may be automatically triggered by the mobile phone's network search function in the background. For Bluetooth applications such as soft bus, audio software, and network search, based on considerations of mobile phone power consumption, Bluetooth applications that need to run for a long time are deployed on the Bluetooth host of the low-power coprocessor, while other Bluetooth applications may be deployed on the Bluetooth host of the main processor.

The multi-Bluetooth host collaborative processing method provided in this application embodiment can be executed by a Bluetooth communication device, which can be a Bluetooth Low Energy (BLE) device, such as the mobile phone shown in Figure 1. The Bluetooth communication device can deploy a Bluetooth communication system, which includes multiple Bluetooth hosts and a Bluetooth controller. For example, Figure 2 is a schematic diagram of the structure of a Bluetooth communication system provided in this application embodiment. As shown in Figure 2, the hardware module of the Bluetooth communication system includes processor A, processor B, and a Bluetooth chip, while the software module includes Bluetooth host A, Bluetooth host B, and a Bluetooth controller. Bluetooth host A is deployed on processor A, Bluetooth host B is deployed on processor B, and the Bluetooth controller is deployed on the Bluetooth chip. For example, processor A and processor B are two different processors, not two cores of the same processor. Processor A can be an application processor (AP), belonging to the main processor; processor B can be a sensor hub (SH), belonging to the coprocessor.

In this system, Bluetooth Host A and Bluetooth Host B are the host computer components, responsible for controlling the Bluetooth controller's operating mode and processing the data reported by the Bluetooth controller. Bluetooth Host A essentially represents the Bluetooth-related components in the main architecture of the Bluetooth communication device, i.e., the Bluetooth-related components in the operating system of processor A; Bluetooth Host B represents the Bluetooth-related components in the operating system of processor B. The operating systems for Bluetooth Host A and Bluetooth Host B can be heterogeneous. As shown in Figure 2, Bluetooth Host A and Bluetooth Host B respectively include the Bluetooth application, Bluetooth protocol stack, and Bluetooth interface driver. The Bluetooth controller is the slave computer component, responsible for connecting with other Bluetooth communication devices to achieve signal transmission and data exchange. The Bluetooth controller includes the Bluetooth interface driver; other modules included in the Bluetooth controller are the same as those in related technologies and will not be described further.

Bluetooth applications broadly refer to applications that rely on the Bluetooth protocol to complete communication services. For example, distributed soft bus applications use Bluetooth discovery, Bluetooth connection, or Bluetooth transmission functions for device discovery and information synchronization, while network search applications use Bluetooth broadcasting and Bluetooth connection functions for device discovery. The Bluetooth application running on Bluetooth host A can be the same as or different from the Bluetooth application running on Bluetooth host B. The Bluetooth protocol stack contains implementations of the Bluetooth protocols defined in the Bluetooth specification. Optionally, this includes, but is not limited to, implementations and encapsulations of Bluetooth protocols such as the Logical Link Control and Adaptation Protocol (L2CAP) and the Generic Attribute Profile (GATT), providing a Bluetooth interface for Bluetooth applications. The Bluetooth interface provides a standardized way to implement Bluetooth communication, making it easier to develop Bluetooth applications and enabling interoperability between different Bluetooth communication devices.

In this embodiment, a coordination module is added to the Bluetooth protocol stack. This module implements coordination logic between different Bluetooth protocol stacks in a multi-Bluetooth host Bluetooth communication system, preventing conflicts arising from concurrent operation of different Bluetooth protocol stacks. A connection is established between the Bluetooth controller's Bluetooth interface driver and the Bluetooth host's Bluetooth interface driver, providing a pathway between the Bluetooth host and the Bluetooth controller. For example, the Bluetooth interface driver is an HCI interface driver.

Figure 3 is a flowchart of a collaborative processing method for multiple Bluetooth hosts provided in an embodiment of this application. This method is executed by a Bluetooth communication device, which can be a mobile phone as shown in Figure 1. The Bluetooth communication device is equipped with a Bluetooth communication system, which includes multiple Bluetooth hosts and at least one Bluetooth controller. The multiple Bluetooth hosts can be deployed on the same processor or on different processors. This embodiment of the application uses a first Bluetooth host and a second Bluetooth host connected to the same Bluetooth controller as an example. For example, the Bluetooth communication system can be as shown in Figure 2, where the first Bluetooth host is Bluetooth host A as shown in Figure 2, and the second Bluetooth host is Bluetooth host B as shown in Figure 2; or, the first Bluetooth host is Bluetooth host B as shown in Figure 2, and the second Bluetooth host is Bluetooth host A as shown in Figure 2. As shown in Figure 3, the collaborative processing method for multiple Bluetooth hosts includes, but is not limited to, the following steps 301 and 302.

Step 301: Before the first Bluetooth host executes the first operation instruction, the first operation information of the second Bluetooth host is obtained, and the first operation information indicates the operation status of the second Bluetooth host.

In this scenario, the second Bluetooth host and the first Bluetooth host are connected to the same Bluetooth controller, representing a multi-Bluetooth host coexistence scenario. The first Bluetooth host initiates a first operation command, indicating that its working state is "exiting sleep," meaning it is currently operating. Taking the first Bluetooth host deployed on the first processor of the Bluetooth communication device as an example, the working state of the first Bluetooth host can be determined by the working state of the first processor. For instance, if the first processor's working state is "exiting sleep," meaning it is currently operating, then the working state of the first Bluetooth host is determined to be "exiting sleep."

In one possible implementation, before the first Bluetooth host executes the first operation command, it is also necessary to determine the working state of the second Bluetooth host. That is, if the working state of the second Bluetooth host is "out of sleep," the operation information of the second Bluetooth host is obtained. Here, the working state of the second Bluetooth host being "out of sleep" indicates that the second Bluetooth host is working, which is a scenario of multiple Bluetooth hosts working in parallel. The operation information of the second Bluetooth host is only obtained in a parallel working scenario to avoid conflicts caused by multiple Bluetooth hosts working in parallel.

In another possible implementation, when the second Bluetooth host is in a sleep state, it directly interacts with the Bluetooth controller to execute the first operation command without needing to obtain the first operation information of the second Bluetooth host. Therefore, it is unnecessary to determine whether the operation state of the second Bluetooth host conflicts with the first operation command. Here, the second Bluetooth host being in a sleep state indicates that the second Bluetooth host is not working, thus it is a single Bluetooth host scenario, and the operation can be executed directly, saving the overhead of collaborative processing.

Taking the second Bluetooth host deployed in the second processor of the Bluetooth communication device as an example, the working state of the second Bluetooth host can be determined by the working state of the second processor. For example, if the working state of the second processor is "exiting sleep" (i.e., the second processor is working), then the working state of the second Bluetooth host is determined to be "exiting sleep"; if the working state of the second processor is "entering sleep" (i.e., the second processor is not working), then the working state of the second Bluetooth host is determined to be "entering sleep". The processor entering sleep mode can reduce the power consumption of the Bluetooth communication device.

In this embodiment, the acquired first operation information of the second Bluetooth host can indicate the operation state of the second Bluetooth host, and the operation state can indicate the execution status of the operation command. Optionally, the operation state includes operating, operation completed, or idle. For example, the first operation information includes a first flag, which indicates that the operation state of the second Bluetooth host is operation completed; or, the first operation information includes a second flag, which indicates that the operation state of the second Bluetooth host is idle. The type of operation state may also be different for different types of operation commands. For example, if the operation command is a scanning type, the operation state is a scanning state, which may include scanning, scanning completed, or idle; if the operation command is a connection type, the operation state is a connection establishment state, which may include connection establishment, connection establishment completed, or idle.

Optionally, this application embodiment does not limit the method of obtaining the first operation information of the second Bluetooth host, and includes, but is not limited to, the following two methods.

Method 1: Send a first query command to the second Bluetooth host. The first query command is used by the second Bluetooth host to send first operation information of the second Bluetooth host to the first Bluetooth host; and receive the first operation information sent by the second Bluetooth host.

In this first method, the operation information of the other Bluetooth host is obtained by sending a query command to the other Bluetooth host, realizing collaborative interaction between multiple Bluetooth hosts. Since the first operation information obtained through the query method is the latest operation information responded by the other Bluetooth host, the accuracy of the obtained first operation information can be guaranteed. Taking the Bluetooth host shown in Figure 2 as an example, the interaction between multiple Bluetooth hosts can be implemented by a collaborative module on the Bluetooth host. Optionally, the first Bluetooth host sends a first query command to the second Bluetooth host, and the first query command is used by the second Bluetooth host to send its first operation information to the first Bluetooth host; the first Bluetooth host receives the first operation information sent by the second Bluetooth host.

Optionally, after receiving the first query command, the second Bluetooth host may immediately send its first operation information to the first Bluetooth host. The operation status indicated by the first operation information may or may not conflict with the first operation command. Alternatively, after receiving the first query command, the second Bluetooth host may also send its first operation information to the first Bluetooth host if its operation status does not conflict with the first operation command. In this case, the first operation information will definitely indicate that the operation status of the second Bluetooth host does not conflict with the first operation command. That is, if the second Bluetooth host is executing an operation command or an operation command of the same type as the first operation command, the second Bluetooth host will not respond to the first query command and will wait for the operation command to complete before responding.

In this method, a response is only initiated when the operating state of the second Bluetooth host does not conflict with the first operation command, thus avoiding the need to resend the query command due to a conflict between the responded operating state and the first operation command. In other words, an operation command sends only one query command, and the operation command can begin execution upon receiving a response to the query command, ensuring that no conflict occurs where operation commands are executed simultaneously.

Method 2: Read the collaboration information recorded by the first Bluetooth host to obtain the first operation information of the second Bluetooth host.

In Method 2, the first Bluetooth host records collaboration information, which in turn indicates the first operation information of the second Bluetooth host. Therefore, by recording the operation information of the other Bluetooth host, the first operation information can be quickly obtained, improving the efficiency of its acquisition.

Optionally, the method by which the first Bluetooth host records the collaboration information may include: receiving a second query command, which is sent before the second Bluetooth host executes the second operation command; sending third operation information to the second Bluetooth host, the third operation information indicating that the operation status of the first Bluetooth host does not conflict with the second operation command; and recording fourth operation information as collaboration information on the first Bluetooth host, the fourth operation information indicating that the second Bluetooth host is executing the second operation command. Alternatively, receiving fifth operation information, which is sent to the first Bluetooth host after the second operation command has been executed, the fifth operation information indicating that the second Bluetooth host has completed the second operation command; and recording the fifth operation information of the second Bluetooth host as collaboration information on the first Bluetooth host.

In this scenario, before executing the second operation command, the second Bluetooth host also queries the first Bluetooth host for its operation information. Since the second Bluetooth host begins executing the second operation command after the first Bluetooth host responds with the third operation information, the fourth operation information indicating that the second Bluetooth host is executing the second operation command can be recorded as coordination information. Furthermore, the second Bluetooth host will also notify the first Bluetooth host after completing the second operation command; therefore, the fifth operation information indicating that the second Bluetooth host has completed the second operation command can be recorded as coordination information. This achieves real-time recording of coordination information, enabling real-time synchronization of operation information among multiple Bluetooth hosts.

Step 302: If there is no conflict between the operation state of the second Bluetooth host and the first operation command, interact with the Bluetooth controller to execute the first operation command.

After obtaining the first operation information of the second Bluetooth host, a conflict can be determined based on the operation status of the second Bluetooth host indicated by the first operation information. That is, if there is no conflict between the operation status of the second Bluetooth host and the first operation command, the system interacts with the Bluetooth controller to execute the first operation command; if there is a conflict between the operation status of the second Bluetooth host and the first operation command, the system obtains the operation information of the second Bluetooth host again, until the obtained operation information indicates that the operation status of the second Bluetooth host does not conflict with the first operation command, and then interacts with the Bluetooth controller to execute the first operation command. Optionally, the first Bluetooth host interacts with the Bluetooth controller to execute the first operation command. Executing the first operation command can refer to executing the operation corresponding to the first operation command.

In one possible implementation, after interacting with the Bluetooth controller to execute a first operation command, upon completion of the first operation command execution, a second operation message is sent to the second Bluetooth host. The second operation message instructs the first Bluetooth host to complete the execution of the first operation command. Thus, synchronization of operation information among multiple Bluetooth hosts is achieved through collaborative interaction.

In this embodiment, the absence of conflict between the operation state of the second Bluetooth host and the first operation instruction means that the execution of the operation instruction by the second Bluetooth host does not affect the execution of the first operation instruction by the first Bluetooth host. For example, the second Bluetooth host does not execute an operation instruction that conflicts with the first operation instruction, resulting in a higher success rate for the first Bluetooth host to execute the first operation instruction under these conflict-free conditions. Optionally, the absence of conflict between the operation state of the second Bluetooth host and the first operation instruction includes: the second Bluetooth host does not execute an operation instruction of the same type as the first operation instruction. In this approach, multiple Bluetooth hosts can avoid simultaneously executing the same type of operation instruction, while different types of operation instructions can be executed simultaneously, preventing mutual interference between different types of operation instructions. Alternatively, the absence of conflict between the operation state of the second Bluetooth host and the first operation instruction includes: the second Bluetooth host does not execute any operation instruction. In this approach, multiple Bluetooth hosts can avoid simultaneously executing the same or different types of operation instructions, better preventing any potential conflicts. The types of the first operation instruction include broadcast type, scan type, connection type, and transmission type, etc.

When the first operation instruction is used to update the scanning parameters of the Bluetooth controller, the first operation instruction is the scan type. In this case, the operation information indicates the scan parameters in addition to the scan status. The scan parameters include at least one of scan type, scan window, scan interval, timeout, scan filter, scan power, or scan mode.

The scanning types include active scanning and passive scanning. In active scanning mode, the device periodically sends scan requests to obtain broadcast data from surrounding BLE devices, while in passive scanning mode, the device can only receive broadcast data from surrounding BLE devices. The scan window refers to the duration of each scan. Generally, a larger scan window allows for more broadcast data to be received, but it increases power consumption and scan time. The scan interval is the time interval between two scans. The timeout period is the period after which the device stops scanning if no target device is found. The timeout setting should be adjusted according to the actual scenario and requirements. Scan filtering can filter scan results based on device name, device address, etc., to reduce unnecessary scan results. The scan power setting affects the signal strength of the device during scanning, thus affecting the scanning distance and power consumption. Scanning modes include low-power mode, balanced mode, and low-latency mode. Low-power mode can save power to some extent but reduces the scan success rate, while low-latency mode can improve the scan success rate but consumes more power.

In one possible implementation, the first operational information includes a first scanning parameter of the second Bluetooth host. In this case, the interaction with the Bluetooth controller may include: if the second scanning parameter of the first Bluetooth host is greater than or equal to the scanning range indicated by the first scanning parameter, sending the second scanning parameter to the Bluetooth controller, the second scanning parameter being used by the Bluetooth controller to update the scanning parameters to the second scanning parameter; or, if the second scanning parameter is less than the scanning range indicated by the first scanning parameter, sending the first scanning parameter to the Bluetooth controller, the first scanning parameter being used by the Bluetooth controller to update the scanning parameters to the first scanning parameter.

In this system, the first scanning parameters of the second Bluetooth host refer to the scanning parameters that the second Bluetooth host needs to scan using the Bluetooth controller, i.e., the scanning data that the second Bluetooth host needs to scan using the Bluetooth controller according to the first scanning parameters; the second scanning parameters of the first Bluetooth host refer to the scanning parameters that the first Bluetooth host needs to scan using the Bluetooth controller, i.e., the scanning data that the first Bluetooth host needs to scan using the Bluetooth controller according to the second scanning parameters. Therefore, multiple Bluetooth hosts can not only exchange scanning status but also scanning parameters. When the scanning parameters of multiple Bluetooth hosts differ, the scanning parameters of the Bluetooth controller can be uniformly updated to the scanning parameters with the largest scanning range among the multiple Bluetooth hosts. This ensures that the scanning range of the Bluetooth controller based on the updated scanning parameters is larger than the scanning range of each Bluetooth host's scanning parameters, thereby enabling multiple Bluetooth hosts to reuse the scanning resources of the Bluetooth controller. In other words, the scanning data scanned by the Bluetooth controller based on the updated scanning parameters can be used by both the first and second Bluetooth hosts simultaneously.

When the first operation command is used to establish a Bluetooth connection, the first operation command is a connection type. In this case, the operation information indicates not only the connection status but also the number of connections. In one possible implementation, the first operation information includes a first number of Bluetooth connections established by the second Bluetooth host, the first number being used to control a second number of Bluetooth connections established by the first Bluetooth host, and the sum of the second number and the first number being less than or equal to a reference number of Bluetooth connections established by the Bluetooth controller. The reference number may refer to the maximum number of connections supported by the Bluetooth chip in which the Bluetooth controller resides. Thus, multiple Bluetooth hosts can not only exchange connection statuses but also exchange connection numbers, achieving a reasonable allocation of connection resources among multiple Bluetooth hosts.

In addition to executing the aforementioned operation commands, the first Bluetooth host and the second Bluetooth host can also interact to achieve collaborative resource allocation. In one possible implementation, taking the collaborative resource allocation between the first and second Bluetooth hosts as an example, the number of concurrent broadcasts supported by the Bluetooth controller is obtained; a broadcast quantity is allocated to the second Bluetooth host, enabling the second Bluetooth host to broadcast based on the allocated broadcast quantity. Optionally, a first read command for broadcast resources is sent to the Bluetooth controller, whereby the Bluetooth controller sends the concurrent broadcast quantity to the first Bluetooth host, i.e., responds to the first read command; the concurrent broadcast quantity sent by the Bluetooth controller is received; a broadcast quantity is allocated to the second Bluetooth host, and the allocated broadcast quantity is sent to the second Bluetooth host, with the second Bluetooth host responding to the first Bluetooth host. Thus, collaborative allocation of broadcast resources among multiple Bluetooth hosts is achieved.

In one possible implementation, the number of transmission buffers supported by the Bluetooth controller is obtained; a number of buffers is allocated to the second Bluetooth host so that the second Bluetooth host can transmit based on the allocated number of buffers. Optionally, a second read instruction for buffer resources is sent to the Bluetooth controller, which is used by the Bluetooth controller to send the number of transmission buffers to the first Bluetooth host, i.e., to respond to the second read instruction; the number of transmission buffers sent by the Bluetooth controller is received; a number of buffers is allocated to the second Bluetooth host, and the allocated number of buffers is sent to the second Bluetooth host, with the second Bluetooth host responding to the first Bluetooth host. This achieves collaborative allocation of transmission buffer resources among multiple Bluetooth hosts.

Therefore, through steps 301 and 302 above, multiple Bluetooth hosts achieve orderly scheduling of operation commands by exchanging operation information, avoiding coexistence conflicts in scenarios where multiple Bluetooth hosts work in parallel. Taking the first Bluetooth host as an example, during operation, each time the first Bluetooth host initiates an operation command, it first obtains the operation information of the second Bluetooth host. That is, the second Bluetooth host can work simultaneously with the first Bluetooth host, and only executes the operation command after confirming there is no conflict, rather than executing the command directly. The collaborative processing method of the second Bluetooth host during operation is the same as that of the first Bluetooth host. Thus, the conflict problem of multiple Bluetooth hosts executing operation commands simultaneously can be avoided, thereby enabling multiple Bluetooth hosts to work in parallel.

In one possible implementation, the Bluetooth communication system of the Bluetooth communication device includes a third Bluetooth host in addition to a first Bluetooth host and a second Bluetooth host. In this case, besides acquiring the first operation information of the second Bluetooth host, the device also acquires sixth operation information of the third Bluetooth host, which indicates the operation state of the third Bluetooth host. Furthermore, if neither the operation state of the second nor the operation state of the third Bluetooth host conflicts with the first operation command, the device interacts with the Bluetooth controller to execute the first operation command. The implementation method for acquiring the sixth operation information of the third Bluetooth host is the same as the implementation method for acquiring the first operation information of the second Bluetooth host described above, and will not be repeated here.

The following example uses the Bluetooth communication system shown in Figure 2, where Bluetooth communication devices are deployed, and illustrates the method of multi-Bluetooth host collaboration provided in this application by taking the interaction between Bluetooth host A, Bluetooth host B, and the Bluetooth controller as an example, and referring to the flowchart shown in Figure 4. As shown in Figure 4, the Bluetooth application starts an operation command on the Bluetooth host A side. This operation command includes, but is not limited to, updating scanning parameters or establishing a Bluetooth connection. Before executing the start operation command, the Bluetooth protocol stack on the Bluetooth host A side first queries the operation status of Bluetooth host B. Then, the collaboration module on the Bluetooth host A side sends a query command to the collaboration module on the Bluetooth host B side to check the operation status.

After receiving the query command, the coordination module on Bluetooth host B first determines the operation status of Bluetooth host B. If Bluetooth host B is currently executing an operation command, it waits for Bluetooth host B to complete the currently executing operation command before returning the operation status of Bluetooth host B to Bluetooth host A; that is, the coordination module of Bluetooth host B responds to the operation status. If Bluetooth host B is not currently executing an operation command, the coordination module on Bluetooth host B immediately returns the operation status of Bluetooth host B to Bluetooth host A. Optionally, in addition to responding to the operation status, it also responds to the operation parameters, that is, it also returns the operation parameters of Bluetooth host B, such as scan parameters, to Bluetooth host A. After responding to the operation status, the coordination module on Bluetooth host B also records the operation status of Bluetooth host A as "operating".

After receiving the operation status response from Bluetooth host B, the collaboration module on Bluetooth host A continues to execute the start operation command. Once Bluetooth host A completes the operation command, its collaboration module notifies its collaboration module on Bluetooth host B that the operation is complete. Upon receiving this notification, Bluetooth host B's collaboration module records the operation status of Bluetooth host A as "operation complete."

Therefore, the collaboration module on the Bluetooth host B side records the operation status of the Bluetooth host A side. The Bluetooth application launch operation command on the Bluetooth host B side includes, but is not limited to, Bluetooth scanning or Bluetooth connection. Before executing this launch operation command, the Bluetooth protocol stack on the Bluetooth host B side first queries the operation status of the Bluetooth host A. Then, it first queries the operation status of the Bluetooth host A recorded in the collaboration module on the Bluetooth host B side; if it is in operation, the Bluetooth host B must wait for the operation status of the Bluetooth host A to change to operation completed before executing the operation command; if the operation is completed, the Bluetooth host B can execute the operation command immediately.

When the operation command is to update scan parameters, due to the constraint that the Bluetooth chip can only set one set of scan parameters, if Bluetooth host A and Bluetooth host B modify the scan parameters simultaneously, conflicts such as parameter overwriting or scan state errors will occur, which cannot meet the scanning requirements of multiple Bluetooth hosts working in parallel. Therefore, this embodiment adds dual-stack interaction at the scan conflict point. Dual-stack is short for dual Bluetooth protocol stacks, and dual-stack interaction refers to the interaction between the collaborative modules of the two stacks. Through interaction, the two stacks can mutually sense the scan state and scan parameters, realize coordinated and orderly scheduling of scans, and unify the scan parameters.

Referring to the timing flowchart of the scan coordination shown in Figure 5, the process of Bluetooth host A and Bluetooth host B simultaneously updating scan parameters is illustrated with an example. The Bluetooth application on Bluetooth host A initiates an update of the scan parameters to the Bluetooth protocol stack on Bluetooth host A; the scan parameter to be updated is scan parameter A. During the interaction between the Bluetooth protocol stack on Bluetooth host A and the Bluetooth controller, the Bluetooth application on Bluetooth host B also initiates an update of the scan parameters to the Bluetooth protocol stack on Bluetooth host B; the scan parameter to be updated is scan parameter B.

In this scenario, before executing the scan parameter update operation, the Bluetooth protocol stack on Bluetooth host A first queries the scan status and scan parameters on Bluetooth host B. For example, it can send a query command from the coordination module on Bluetooth host A to the coordination module on Bluetooth host B. Upon receiving the query command, the Bluetooth protocol stack on Bluetooth host B, being in the process of updating the scan parameters, waits for the update to complete before responding to the Bluetooth protocol stack on Bluetooth host A with the scan status and scan parameters. The scan status indicates that the operation is complete. The process of Bluetooth host B updating the scan parameters involves the Bluetooth protocol stack on Bluetooth host B setting scan parameter B to the Bluetooth controller. After updating the scan parameters to scan parameter B, the Bluetooth controller responds to the Bluetooth protocol stack on Bluetooth host B with a success message. Finally, the Bluetooth protocol stack on Bluetooth host B sends feedback to the Bluetooth application on Bluetooth host B indicating successful scan parameter update.

After receiving a response from Bluetooth host B, the Bluetooth protocol stack on host A determines that the scanning status on host B is complete, meaning that updating the scan parameters will not conflict with the operation command on host B. Therefore, the Bluetooth protocol stack on host A begins the scan parameter update operation. Specifically, the Bluetooth protocol stack on host A compares the scan parameter A to be updated with the scan parameter B returned by host B, determining the larger of the two as the normalized scan parameter (either A or B). The Bluetooth protocol stack on host A sets this normalized scan parameter to the Bluetooth controller. After updating the scan parameters to the normalized scan parameter, the Bluetooth controller acknowledges success to the Bluetooth protocol stack on host A, and the Bluetooth protocol stack on host A then reports the successful update to the Bluetooth application on host A. The Bluetooth protocol stack on Bluetooth host A also notifies the Bluetooth protocol stack on Bluetooth host B of the scan status and normalized scan parameters. The scan status indicates that the operation is complete, and the Bluetooth protocol stack on Bluetooth host B records the scan parameters as the normalized scan parameters. This achieves conflict-free scanning and normalized scan parameters for Bluetooth host A and Bluetooth host B in parallel operation scenarios.

When the operation command is to establish a Bluetooth connection, the Bluetooth chip stops processing connection requests from the Bluetooth protocol stack once it is in the connection initiating state. If both stacks execute the Bluetooth connection establishment operation simultaneously, a connection conflict will occur, causing the Bluetooth application to fail to establish a Bluetooth connection, thus failing to meet the connection requirements of multiple Bluetooth hosts working in parallel. Therefore, this embodiment adds dual-stack interaction at the connection conflict point. Through interaction, the connection states of the two stacks are mutually sensed, that is, the connection states of the two stacks are coordinated, thereby achieving orderly scheduling of connection coordination and achieving a conflict-free connection.

Referring to the timing flowchart of the connection coordination shown in Figure 6, the process of Bluetooth host A and Bluetooth host B simultaneously establishing a Bluetooth connection is illustrated with an example. The Bluetooth application on Bluetooth host A initiates the Bluetooth connection establishment operation to the Bluetooth protocol stack on Bluetooth host A. In this case, before executing the Bluetooth connection establishment operation, the Bluetooth protocol stack on Bluetooth host A first queries the connection status on Bluetooth host B, for example, by sending a query command from the coordination module on Bluetooth host A to the coordination module on Bluetooth host B. After receiving the query command, the Bluetooth protocol stack on Bluetooth host B, since not currently performing a connection operation, directly responds to the Bluetooth protocol stack on Bluetooth host A with a connection status of "idle". Optionally, based on the responded connection status, the Bluetooth protocol stack on Bluetooth host B records the connection status on Bluetooth host A as "in operation".

After receiving the connection establishment status response, the Bluetooth protocol stack on Bluetooth host A determines that the connection establishment state on Bluetooth host B is idle, meaning that performing the Bluetooth connection establishment operation now will not cause a scanning conflict with the operation command on Bluetooth host B. Therefore, the Bluetooth protocol stack on Bluetooth host A begins the Bluetooth connection establishment operation. Specifically, the Bluetooth protocol stack on Bluetooth host A sends a connection establishment request to the Bluetooth controller. The Bluetooth controller, based on the connection establishment request, enters the initiating state to establish the Bluetooth connection. After the Bluetooth connection is successfully established, the Bluetooth controller acknowledges the connection success to the Bluetooth protocol stack on Bluetooth host A, and the Bluetooth protocol stack on Bluetooth host A sends feedback on the connection success to the Bluetooth application on Bluetooth host A. The Bluetooth protocol stack on Bluetooth host A also notifies the Bluetooth protocol stack on Bluetooth host B of the connection status and normalized scan parameters. The connection status indicates that the operation is complete.

During the Bluetooth connection establishment process performed by the Bluetooth protocol stack on Bluetooth host A, the Bluetooth application on Bluetooth host B also initiates its own Bluetooth connection establishment operation. Before performing the connection establishment operation, the Bluetooth protocol stack on Bluetooth host B queries the connection status of Bluetooth host A recorded in its stack. If the connection status of Bluetooth host A is "in operation," the Bluetooth protocol stack on Bluetooth host B waits, pausing the connection establishment operation. If the connection status of Bluetooth host A is "operation completed," the Bluetooth protocol stack on Bluetooth host B begins the connection establishment operation.

The process of Bluetooth host B's Bluetooth protocol stack initiating the Bluetooth connection establishment operation is as follows: Bluetooth host B's Bluetooth protocol stack sends a connection request to the Bluetooth controller. The Bluetooth controller enters the initiating state based on the connection request to establish the Bluetooth connection. After the Bluetooth connection is successfully established, the Bluetooth controller acknowledges the successful connection to Bluetooth host B's Bluetooth protocol stack, and Bluetooth host B's Bluetooth protocol stack then sends feedback on the successful connection to Bluetooth host B's Bluetooth application. This achieves a conflict-free connection between Bluetooth host A and Bluetooth host B in a parallel working scenario.

In summary, the method provided in this application adds an operation status interaction mechanism between the Bluetooth protocol stacks of multiple Bluetooth hosts. This allows for interaction mechanisms such as operation status query, response, and notification between the two stacks at operation command conflict points, achieving mutual awareness of the operation status between the two stacks and enabling orderly scheduling of operation commands. Furthermore, a resource reuse mechanism is added between the two stacks, allowing for the exchange of scan parameters at operation command conflict points, i.e., mutual awareness of scan parameters, with the scan parameters being unified by the Bluetooth protocol stack that last performed the scan parameter update operation. A resource allocation mechanism is added between the two stacks, enabling the notification of the number of connections and the number of reassigned buffers to the peer Bluetooth protocol stack after a successful Bluetooth connection establishment. A dynamic coordination mechanism is added between the two stacks, allowing the Bluetooth protocol stack to perceive the processor status of the other Bluetooth protocol stack; entering sleep mode stops coordination, and exiting sleep mode resumes coordination.

The above describes a multi-Bluetooth host collaborative processing method according to embodiments of this application. Corresponding to the above method, embodiments of this application also provide a multi-Bluetooth host collaborative processing device. Figure 7 is a schematic diagram of the structure of a multi-Bluetooth host collaborative processing device provided in an embodiment of this application. This device is applied to a Bluetooth communication device, which is the Bluetooth communication device shown in Figure 3 above. Based on the following modules shown in Figure 7, the multi-Bluetooth host collaborative processing device shown in Figure 7 can perform all or part of the operations performed by the Bluetooth communication device. It should be understood that the device may include more additional modules than the modules shown or omit some of the modules shown. Embodiments of this application do not limit this. As shown in Figure 7, the device includes:

The acquisition module 701 is used to acquire the first operation information of the second Bluetooth host before the first Bluetooth host executes the first operation instruction. The second Bluetooth host and the first Bluetooth host are connected to the same Bluetooth controller. The first operation information indicates the operation status of the second Bluetooth host.

The execution module 702 is used to interact with the Bluetooth controller to execute the first operation command when there is no conflict between the operation state of the second Bluetooth host and the first operation command.

In one possible implementation, the acquisition module 701 is used to send a first query instruction to the second Bluetooth host, the first query instruction being used by the second Bluetooth host to send first operation information of the second Bluetooth host to the first Bluetooth host; and to receive the first operation information sent by the second Bluetooth host.

In one possible implementation, the device further includes: a first transmitting module, configured to send second operation information to a second Bluetooth host upon completion of the execution of the first operation instruction, wherein the second operation information instructs the first Bluetooth host to complete the execution of the first operation instruction.

In one possible implementation, the first Bluetooth host records coordination information that indicates first operational information of the second Bluetooth host.

In one possible implementation, the device further includes: a receiving module for receiving a second query instruction, the second query instruction being sent before the second Bluetooth host executes the second operation instruction; a second sending module for sending third operation information to the second Bluetooth host, the third operation information indicating that the operation status of the first Bluetooth host does not conflict with the second operation instruction; and a recording module for recording fourth operation information as coordination information on the first Bluetooth host, the fourth operation information indicating that the second Bluetooth host is executing the second operation instruction.

In one possible implementation, the receiving module is further configured to receive fifth operation information, which is sent to the first Bluetooth host after the second operation instruction has been completed, and the fifth operation information instructs the second Bluetooth host to complete the second operation instruction; the recording module is further configured to record the fifth operation information as coordination information in the first Bluetooth host.

In one possible implementation, the fact that the operating state of the second Bluetooth host does not conflict with the first operating instruction includes: the second Bluetooth host does not execute an operating instruction of the same type as the first operating instruction, or the second Bluetooth host does not execute any operating instruction.

In one possible implementation, the first operation instruction is used to update the scanning parameters of the Bluetooth controller, and the first operation information includes the first scanning parameters of the second Bluetooth host; the execution module 702 is used to send the second scanning parameters to the Bluetooth controller when the second scanning parameters of the first Bluetooth host are greater than or equal to the scanning range indicated by the first scanning parameters, and the second scanning parameters are used by the Bluetooth controller to update the scanning parameters to the second scanning parameters; or, when the second scanning parameters are less than the scanning range indicated by the first scanning parameters, the first scanning parameters are sent to the Bluetooth controller, and the first scanning parameters are used by the Bluetooth controller to update the scanning parameters to the first scanning parameters.

In one possible implementation, the first operation instruction is used to establish a Bluetooth connection, and the first operation information includes a first number of Bluetooth connections established by the second Bluetooth host. The first number is used to control a second number of Bluetooth connections established by the first Bluetooth host, and the sum of the second number and the first number is less than or equal to a reference number of Bluetooth connections established by the Bluetooth controller.

In one possible implementation, the acquisition module 701 is used to acquire the operation information of the second Bluetooth host when the second Bluetooth host is in the working state of exiting sleep.

It should be understood that the device shown in Figure 7 is only illustrated by the division of the above-described functional modules. In practical applications, the 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. Furthermore, the device and method embodiments provided in the above embodiments belong to the same concept, and their specific implementation process and beneficial effects are detailed in the method embodiments, and will not be repeated here.

This application provides a terminal device for performing the operations involved in the multi-Bluetooth host collaborative processing method shown in FIG3. Optionally, the structural schematic diagram of the terminal device can be as shown in FIG8. In the structural schematic diagram of the terminal device shown in FIG8, the terminal device can be, for example, a smartphone, tablet computer, vehicle terminal, laptop computer, or desktop computer. The terminal device may also be referred to as user equipment, portable terminal, laptop terminal, desktop terminal, or other names.

Typically, a terminal device includes a processor 801 and a memory 802.

Processor 801 may include one or more processing cores, such as a quad-core processor, an octa-core processor, etc. Processor 801 may be implemented using at least one hardware form selected from DSP (Digital Signal Processing), FPGA (Field-Programmable Gate Array), and PLA (Programmable Logic Array). Processor 801 may also include a main processor and a coprocessor. The main processor, also known as a CPU (Central Processing Unit), is used to process data in the wake-up state; the coprocessor is a low-power processor used to process data in the standby state. In some embodiments, processor 801 may integrate a GPU (Graphics Processing Unit), which is responsible for rendering and drawing the content to be displayed on the screen. In some embodiments, processor 801 may also include an AI (Artificial Intelligence) processor, which is used to handle computational operations related to machine learning.

The memory 802 may include one or more computer-readable storage media, which may be non-transitory. The memory 802 may also include high-speed random access memory and non-volatile memory, such as one or more disk storage devices or flash memory devices. In some embodiments, the non-transitory computer-readable storage media in the memory 802 is used to store at least one instruction, which is executed by the processor 801 to implement the electronic account opening method provided in the method embodiments of this application.

In some embodiments, the terminal may also optionally include: a peripheral device interface 803 and at least one peripheral device. The processor 801, memory 802, and peripheral device interface 803 can be connected via a bus or signal line. Each peripheral device can be connected to the peripheral device interface 803 via a bus, signal line, or circuit board. Specifically, the peripheral device includes at least one of: a radio frequency circuit 804, a display screen 805, a camera assembly 806, an audio circuit 807, and a power supply 808.

Peripheral device interface 803 can be used to connect at least one I/O (Input/Output) related peripheral device to processor 801 and memory 802. In some embodiments, processor 801, memory 802 and peripheral device interface 803 are integrated on the same chip or circuit board; in some other embodiments, any one or two of processor 801, memory 802 and peripheral device interface 803 can be implemented on separate chips or circuit boards, which is not limited in this embodiment.

The radio frequency (RF) circuit 804 is used to receive and transmit RF (Radio Frequency) signals, also known as electromagnetic signals. The RF circuit 804 communicates with communication networks and other communication devices via electromagnetic signals. The RF circuit 804 converts electrical signals into electromagnetic signals for transmission, or converts received electromagnetic signals back into electrical signals. Optionally, the RF circuit 804 includes: an antenna system, an RF transceiver, one or more amplifiers, a tuner, an oscillator, a digital signal processor, a codec chipset, a user identity module card, etc. The RF circuit 804 can communicate with other terminals through at least one wireless communication protocol. This wireless communication protocol includes, but is not limited to: metropolitan area networks (MANs), various generations of mobile communication networks (2G, 3G, 4G, and 5G), wireless local area networks (WLANs), and/or Wireless Fidelity (WiFi) networks. In some embodiments, the RF circuit 804 may also include circuitry related to NFC (Near Field Communication), which is not limited in this application.

Display screen 805 is used to display a UI (User Interface). This UI may include graphics, text, icons, videos, and any combination thereof. When display screen 805 is a touch display screen, it also has the ability to collect touch signals on or above its surface. These touch signals can be input as control signals to processor 801 for processing. In this case, display screen 805 can also be used to provide virtual buttons and/or a virtual keyboard, also known as soft buttons and/or a soft keyboard. In some embodiments, there may be one display screen 805, located on the front panel of the terminal; in other embodiments, there may be at least two display screens, respectively located on different surfaces of the terminal or in a folded design; in still other embodiments, display screen 805 may be a flexible display screen, located on a curved or folded surface of the terminal. Furthermore, display screen 805 may be configured as a non-rectangular irregular shape, i.e., a non-rectangular screen. Display screen 805 may be made of materials such as LCD (Liquid Crystal Display) or OLED (Organic Light-Emitting Diode).

The camera assembly 806 is used to acquire images or videos. Optionally, the camera assembly 806 includes a front-facing camera and a rear-facing camera. Typically, the front-facing camera is located on the front panel of the terminal, and the rear-facing camera is located on the back of the terminal. In some embodiments, there are at least two rear-facing cameras, which are any one of a main camera, a depth-sensing camera, a wide-angle camera, and a telephoto camera, to achieve background blurring by fusion of the main camera and the depth-sensing camera, panoramic shooting by fusion of the main camera and the wide-angle camera, VR (Virtual Reality) shooting, or other fusion shooting functions. In some embodiments, the camera assembly 806 may also include a flash. The flash can be a single-color temperature flash or a dual-color temperature flash. A dual-color temperature flash refers to a combination of a warm-light flash and a cool-light flash, which can be used for light compensation at different color temperatures.

The audio circuit 807 may include a microphone and a speaker. The microphone is used to collect sound waves from the user and the environment, converting the sound waves into electrical signals that are input to the processor 801 for processing, or input to the radio frequency circuit 804 for voice communication. For stereo sound acquisition or noise reduction purposes, multiple microphones may be used, each positioned at a different location on the terminal. The microphone may also be an array microphone or an omnidirectional microphone. The speaker is used to convert the electrical signals from the processor 801 or the radio frequency circuit 804 into sound waves. The speaker may be a conventional diaphragm speaker or a piezoelectric ceramic speaker. When the speaker is a piezoelectric ceramic speaker, it can convert electrical signals not only into audible sound waves but also into inaudible sound waves for purposes such as distance measurement. In some embodiments, the audio circuit 807 may also include a headphone jack.

Power supply 808 is used to power the various components in the terminal. Power supply 808 can be AC power, DC power, a disposable battery, or a rechargeable battery. When power supply 808 includes a rechargeable battery, the rechargeable battery can support wired or wireless charging. The rechargeable battery can also be used to support fast charging technology.

In some embodiments, the terminal further includes one or more sensors 809. The one or more sensors 809 include, but are not limited to: an accelerometer 810, a gyroscope 811, a pressure sensor 812, an optical sensor 813, and a proximity sensor 814.

Accelerometer 810 can detect the magnitude of acceleration along the three coordinate axes of a coordinate system established by the terminal. For example, accelerometer 810 can be used to detect the components of gravitational acceleration along the three coordinate axes. Processor 801 can control display screen 805 to display the user interface in either a landscape or portrait view based on the gravitational acceleration signal acquired by accelerometer 810. Accelerometer 810 can also be used for games or for acquiring user motion data.

The gyroscope sensor 811 can detect the terminal's orientation and rotation angle. The gyroscope sensor 811, in conjunction with the accelerometer sensor 810, can collect the user's 3D movements on the terminal. Based on the data collected by the gyroscope sensor 811, the processor 801 can perform the following functions: motion sensing (e.g., changing the UI based on the user's tilt), image stabilization during shooting, game control, and inertial navigation.

The pressure sensor 812 can be disposed on the side bezel of the terminal and/or on the lower layer of the display screen 805. When the pressure sensor 812 is disposed on the side bezel of the terminal, it can detect the user's grip signal on the terminal, and the processor 801 can perform left/right hand recognition or quick operation based on the grip signal collected by the pressure sensor 812. When the pressure sensor 812 is disposed on the lower layer of the display screen 805, the processor 801 can control the operable controls on the UI interface based on the user's pressure operation on the display screen 805. The operable controls include at least one of button controls, scroll bar controls, icon controls, and menu controls.

An optical sensor 813 is used to collect ambient light intensity. In one embodiment, the processor 801 can control the display brightness of the display screen 805 based on the ambient light intensity collected by the optical sensor 813. Specifically, when the ambient light intensity is high, the display brightness of the display screen 805 is increased; when the ambient light intensity is low, the display brightness of the display screen 805 is decreased. In another embodiment, the processor 801 can also dynamically adjust the shooting parameters of the camera assembly 806 based on the ambient light intensity collected by the optical sensor 813.

The proximity sensor 814, also known as a distance sensor, is typically installed on the front panel of the terminal. The proximity sensor 814 is used to detect the distance between the user and the front of the terminal. In one embodiment, when the proximity sensor 814 detects that the distance between the user and the front of the terminal is gradually decreasing, the processor 801 controls the display screen 805 to switch from a screen-on state to a screen-off state; when the proximity sensor 814 detects that the distance between the user and the front of the terminal is gradually increasing, the processor 801 controls the display screen 805 to switch from a screen-off state to a screen-on state.

Those skilled in the art will understand that the structure shown in Figure 8 does not constitute a limitation on the computer device and may include more or fewer components than shown, or combine certain components, or employ different component arrangements.

Optionally, the structural diagram of the terminal device can also be as shown in Figure 9. In the structural diagram of the terminal device shown in Figure 9, the terminal device can be, for example, a smartphone, tablet computer, vehicle terminal, laptop computer, or desktop computer. The terminal device may also be referred to as user equipment, portable terminal, laptop terminal, desktop terminal, or other names. As shown in Figure 9, the terminal device includes a processor 110.

The processor 110 is connected to the external memory interface 120, internal memory 121, universal serial bus (USB) interface 130, power management module 141, mobile communication module 150, wireless communication module 160, audio module 170, sensor module 180, button 190, motor 191, indicator 192, cameras 1 to N 193, display screens 1 to N 194, and SIM card interfaces 1 to N 195. Here, N is a positive integer.

The charging input is connected to the USB interface 130, which is also connected to the charging management module 140, the battery 142, and the power management module 141. The mobile communication module 150 includes various generations of mobile communication networks (2G/3G/4G/5G), and the wireless communication module 160 includes various wireless communication protocols, such as Bluetooth (BT), wireless local area networks (WLAN), global navigation satellite system (GNSS), NFC, infrared radiation (IR), or frequency modulation (FM). The mobile communication module 150 communicates via antenna 1, and the wireless communication module 160 communicates via antenna 2.

The audio module 170 is connected to the speaker 170A, receiver 170B, microphone 170C, and headphone jack 170D. The sensor module 180 includes, but is not limited to, a pressure sensor 180A, a gyroscope sensor 180B, a barometric pressure sensor 180C, a magnetic sensor 180D, an accelerometer 180E, a proximity sensor 180F, a proximity light sensor 180G, a fingerprint sensor 180H, a temperature sensor 180J, a touch sensor 180K, an ambient light sensor 180L, and a bone conduction sensor 180M. The modules shown in Figure 9 can be referred to the descriptions in Figure 8, which will not be repeated here.

For the terminal device shown in Figure 8 or Figure 9. The number of processors 801 in Figure 8 can be multiple. The connection method of any processor 801 is shown in Figure 8. Two processors 801 among the multiple processors 801 can correspond to processor A and processor B shown in Figure 2, respectively. The peripheral device interface 803 can also connect to a Bluetooth chip, corresponding to the Bluetooth chip shown in Figure 2. The number of processors 110 in Figure 9 can be multiple. The connection method of any processor 110 is shown in Figure 9. Two processors 110 among the multiple processors 110 can correspond to processor A and processor B shown in Figure 2, respectively. Where the wireless communication module 150 includes a Bluetooth chip, the wireless communication module 150 corresponds to the Bluetooth chip shown in Figure 2.

Figure 10 is a schematic diagram of a terminal system architecture provided in an embodiment of this application. As shown in Figure 10, the terminal system architecture includes an application layer, an application framework layer, system libraries, and a kernel library. The application layer includes, but is not limited to, applications for camera, calendar, music, map, WLAN, gallery, Bluetooth, video, call, live streaming, and SMS. The application framework layer includes, but is not limited to, a window manager, content provider, phone manager, notification manager, resource manager, and view system. The system library includes, but is not limited to, various libraries such as a surface manager, 3D graphics processing library, 2D graphics engine, and media library, as well as the system runtime environment. The kernel library includes, but is not limited to, display driver, camera driver, audio driver, and sensor driver.

Regarding the terminal system architecture shown in Figure 10, the Bluetooth application shown in Figure 2 can be mapped to the application layer shown in Figure 10, that is, the Bluetooth in the application layer shown in Figure 10; the Bluetooth protocol stack shown in Figure 2 can be mapped to the system library shown in Figure 10, so the system library shown in Figure 10 also includes the Bluetooth protocol stack; the Bluetooth interface driver shown in Figure 2 can be mapped to the kernel layer shown in Figure 10, so the kernel layer shown in Figure 10 also includes the Bluetooth interface driver.

It should be understood that the aforementioned processor can be a CPU, or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. General-purpose processors can be microprocessors or any conventional processor. It is worth noting that the processor can be a processor supporting Advanced Reduced Instruction Set Computing (RISC) machines (ARM) architecture.

Furthermore, in an alternative embodiment, the memory described above may include read-only memory and random access memory, and provide instructions and data to the processor. The memory may also include non-volatile random access memory. For example, the memory may also store device type information.

The memory can be volatile or non-volatile, or may include both. The non-volatile memory can be read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), or flash memory. The volatile memory can be random access memory (RAM), which serves as an external cache. Many forms of RAM are available by way of example, but not limitation. Examples include static random access memory (SRAM), dynamic random access memory (DRAM), synchronous dynamic random access memory (SDRAM), double data rate synchronous dynamic random access memory (DDR SDRAM), enhanced synchronous dynamic random access memory (ESDRAM), synchronous linked dynamic random access memory (SLDRAM), and direct rambus RAM (DR RAM).

This application also provides a computer-readable storage medium storing at least one instruction, which is loaded and executed by a processor to enable the computer to implement any of the above-described multi-Bluetooth host collaborative processing methods.

This application also provides a computer program (product) that, when executed by a computer, causes the processor or computer to perform the corresponding steps and/or processes in the above method embodiments.

This application also provides a chip, including a processor, for calling and executing instructions stored in a memory, causing a communication device equipped with the chip to perform any of the above-described multi-Bluetooth host collaborative processing methods.

This application embodiment also provides another chip, including: an input interface, an output interface, a processor, and a memory. The input interface, output interface, processor, and memory are connected through an internal connection path. The processor is used to execute code in the memory. When the code is executed, the processor is used to execute any of the above-mentioned multi-Bluetooth host collaborative processing methods.

In the above embodiments, implementation can be achieved, in whole or in part, through software, hardware, firmware, or any combination thereof. When implemented in software, it can be implemented, in whole or in part, as a computer program product. A computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, all or part of the flow or function according to this application is generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired (e.g., coaxial cable, fiber optic, digital subscriber line) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server or data center that integrates one or more available media. The available medium can be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., DVD), or a semiconductor medium (e.g., solid-state disk), etc.

Those skilled in the art will recognize that the method steps and modules described in conjunction with the embodiments disclosed herein can be implemented in software, hardware, firmware, or any combination thereof. To clearly illustrate the interchangeability of hardware and software, the steps and components of each embodiment have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

Those skilled in the art will understand that all or part of the steps of the above embodiments can be implemented by hardware or by a program instructing related hardware. The program can be stored in a computer-readable storage medium, such as a read-only memory, a disk, or an optical disk.

When implemented using software, it can be implemented wholly or partially as a computer program product. This computer program product includes one or more computer program instructions. As an example, the methods of this application embodiment can be described in the context of machine-executable instructions, such as program modules that execute on a device on a real or virtual processor of the target. Generally, program modules include routines, programs, libraries, objects, classes, components, data structures, etc., which perform specific tasks or implement specific abstract data structures. In various embodiments, the functionality of program modules can be combined or divided among the described program modules. The machine-executable instructions for the program modules can execute within a local or distributed device. In a distributed device, the program modules can reside on both local and remote storage media.

Computer program code used to implement the methods of the embodiments of this application may be written in one or more programming languages. This computer program code may be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing apparatus, such that when executed by the computer or other programmable data processing apparatus, the program code causes the functions/operations specified in the flowcharts and/or block diagrams to be implemented. The program code may be executed entirely on a computer, partially on a computer, as a standalone software package, partially on a computer and partially on a remote computer, or entirely on a remote computer or server.

In the context of the embodiments of this application, computer program code or related data may be carried by any suitable carrier to enable a device, apparatus, or processor to perform the various processes and operations described above. Examples of carriers include signals, computer-readable media, etc.

Examples of signals may include electrical, optical, radio, sound, or other forms of propagation signals, such as carrier waves, infrared signals, etc.

A machine-readable medium can be any tangible medium that contains or stores programs for or relating to an instruction execution system, apparatus, or device. A machine-readable medium can be a machine-readable signal medium or a machine-readable storage medium. Machine-readable media can include, but are not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination thereof. More detailed examples of machine-readable storage media include electrical connections with one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical storage devices, magnetic storage devices, or any suitable combination thereof.

Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and modules described above can be found in the corresponding processes in the foregoing method embodiments, and will not be repeated here.

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

The modules described as separate components may or may not be physically separate. The components shown as modules may or may not be physical modules; that is, they may be located in one place or distributed across multiple network modules. Some or all of the modules can be selected to achieve the purpose of the embodiments of this application, depending on actual needs.

Furthermore, the functional modules in the various embodiments of this application can be integrated into one processing module, or each module can exist physically separately, or two or more modules can be integrated into one module. The integrated modules described above can be implemented in hardware or as software functional modules.

If the integrated module is implemented as a software functional module and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

In this application, the terms "first," "second," etc., are used to distinguish identical or similar items that have substantially the same function and purpose. It should be understood that there is no logical or temporal dependency between "first," "second," and "nth," nor does it limit the quantity or order of execution. It should also be understood that although the following description uses the terms "first," "second," etc., to describe various elements, these elements should not be limited by the terms. These terms are merely used to distinguish one element from another. For example, without departing from the scope of various examples, a first image can be referred to as a second image, and similarly, a second image can be referred to as a first image. Both the first image and the second image can be images, and in some cases, they can be separate and distinct images.

It should also be understood that, in the various embodiments of this application, the sequence number of each process does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application.

In this application, the term "at least one" means one or more, and the term "multiple" means two or more. For example, multiple second messages refer to two or more second messages. The terms "system" and "network" are often used interchangeably in this document.

It should be understood that the terminology used in the description of the various examples herein is for the purpose of describing particular examples only and is not intended to be limiting. As used in the description of the various examples and the appended claims, the singular forms “a” and “the” are intended to include the plural forms as well, unless the context clearly indicates otherwise.

It should also be understood that the term "and/or" as used herein refers to and covers any and all possible combinations of one or more of the associated listed items. The term "and/or" describes an association between related objects, indicating that three relationships can exist; for example, A and/or B can represent: A alone, A and B simultaneously, or B alone. Additionally, the character "/" in this application generally indicates that the preceding and following related objects are in an "or" relationship.

It should also be understood that the term “comprising” (also referred to as “includes”, “including”, “comprises” and/or “comprising”) as used in this specification specifies the presence of the stated features, integers, steps, operations, elements, and/or components, but does not exclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and/or groups thereof.

It should also be understood that the terms “if” and “if” can be interpreted as meaning “when” or “upon”, or “in response to determination” or “in response to detection”. Similarly, depending on the context, the phrases “if determination…” or “if detection [the stated condition or event]” can be interpreted as meaning “when determination…”, or “in response to determination…”, or “when detection [the stated condition or event]” or “in response to detection [the stated condition or event]”.

It should be understood that determining B based on A does not mean determining B solely based on A; B can also be determined based on A and/or other information.

It should also be understood that the phrases "an embodiment," "an embodiment," and "a possible implementation" used throughout the specification mean that a specific feature, structure, or characteristic related to an embodiment or implementation is included in at least one embodiment of this application. Therefore, the phrases "in an embodiment," "an embodiment," or "a possible implementation" appearing throughout the specification do not necessarily refer to the same embodiment. Furthermore, these specific features, structures, or characteristics can be combined in any suitable manner in one or more embodiments.

The above description is only an optional embodiment of this application and is not intended to limit this application. Any modifications, equivalent substitutions, improvements, etc., made within the principles of this application should be included within the protection scope of this application.

Claims (14)

A collaborative processing method for multiple Bluetooth hosts, characterized in that the method includes: Before the first Bluetooth host executes the first operation instruction, the first operation information of the second Bluetooth host is obtained. The second Bluetooth host and the first Bluetooth host are connected to the same Bluetooth controller. The first operation information indicates the operation status of the second Bluetooth host. If there is no conflict between the operating state of the second Bluetooth host and the first operation command, it interacts with the Bluetooth controller to execute the first operation command. According to the method of claim 1, the step of obtaining the first operation information of the second Bluetooth host includes: Send a first query command to the second Bluetooth host, wherein the first query command is used by the second Bluetooth host to send the first operation information of the second Bluetooth host to the first Bluetooth host; Receive the first operation information sent by the second Bluetooth host. The method according to claim 1 or 2, characterized in that, after executing the first operation instruction, it further includes: Upon completion of the first operation instruction, a second operation message is sent to the second Bluetooth host, the second operation message instructing the first Bluetooth host to complete the first operation instruction. According to the method of claim 1, the first Bluetooth host records coordination information, and the coordination information indicates the first operation information of the second Bluetooth host. The method according to claim 4, characterized in that, before obtaining the first operation information of the second Bluetooth host, it further includes: Receive a second query instruction, which is sent before the second Bluetooth host executes the second operation instruction; Send a third operation message to the second Bluetooth host, the third operation message indicating that there is no conflict between the operation status of the first Bluetooth host and the second operation command; The fourth operation information is recorded in the first Bluetooth host as the collaboration information, and the fourth operation information indicates that the second Bluetooth host is executing the second operation instruction. The method according to claim 4 or 5, characterized in that, before obtaining the first operation information of the second Bluetooth host, it further includes: Receive fifth operation information, which is sent after the second operation instruction has been completed, and the fifth operation information instructs the second Bluetooth host to complete the second operation instruction; The fifth operation information is recorded as the collaboration information in the first Bluetooth host. The method according to any one of claims 1-6 is characterized in that the operation state of the second Bluetooth host does not conflict with the first operation instruction, including: the second Bluetooth host does not execute an operation instruction of the same type as the first operation instruction, or the second Bluetooth host does not execute any operation instruction. The method according to any one of claims 1-7, characterized in that the first operation instruction is used to update the scanning parameters of the Bluetooth controller, and the first operation information includes the first scanning parameters of the second Bluetooth host; the interaction with the Bluetooth controller includes: If the second scan parameter of the first Bluetooth host is greater than or equal to the scan range indicated by the first scan parameter, the second scan parameter is sent to the Bluetooth controller, and the second scan parameter is used by the Bluetooth controller to update the scan parameter to the second scan parameter; or... If the second scan parameter is less than the scan range indicated by the first scan parameter, the first scan parameter is sent to the Bluetooth controller, and the first scan parameter is used by the Bluetooth controller to update the scan parameter to the first scan parameter. The method according to any one of claims 1-7 is characterized in that the first operation instruction is used to establish a Bluetooth connection, the first operation information includes a first number of Bluetooth connections established by the second Bluetooth host, the first number is used to control a second number of Bluetooth connections established by the first Bluetooth host, and the sum of the second number and the first number is less than or equal to a reference number of Bluetooth connections established by the Bluetooth controller. The method according to any one of claims 1-9, wherein obtaining the first operation information of the second Bluetooth host includes: When the second Bluetooth host is in the exit sleep state, obtain the operation information of the second Bluetooth host. A collaborative processing device for multiple Bluetooth hosts, characterized in that the device comprises: The acquisition module is used to acquire first operation information of the second Bluetooth host before the first Bluetooth host executes the first operation instruction. The second Bluetooth host and the first Bluetooth host are connected to the same Bluetooth controller. The first operation information indicates the operation status of the second Bluetooth host. The execution module is used to interact with the Bluetooth controller to execute the first operation instruction when there is no conflict between the operation state of the second Bluetooth host and the first operation instruction. A terminal device, characterized in that the terminal device includes: a processor coupled to a memory, the memory storing at least one program instruction or code, the at least one program instruction or code being loaded and executed by the processor to enable the terminal device to implement the multi-Bluetooth host collaborative processing method according to any one of claims 1-10. A computer-readable storage medium, characterized in that the computer storage medium stores at least one instruction, the at least one instruction being loaded and executed by a processor to enable a computer to implement the multi-Bluetooth host collaborative processing method as described in any one of claims 1-10. A computer program product, characterized in that the computer program product comprises: computer program code, the computer program code being loaded and executed by a computer to enable the computer to implement the multi-Bluetooth host collaborative processing method as described in any one of claims 1-10.