Bluetooth dual-mode switching method, device, medium and program product

Abstract

Embodiments of the present application provide a Bluetooth dual-mode switching method, device, medium and program product, relating to the technical field of Bluetooth communication. The method comprises: establishing a dual-layer protocol stack architecture comprising a basic communication protocol layer and a dynamically loadable protocol extension layer; after a target mode switching instruction is triggered, dynamically loading a protocol corresponding to the target mode and extending to the dynamically loadable layer of the dual-layer protocol stack architecture; the dynamic loading is to load the protocol corresponding to the target mode to the dynamically loadable layer of the protocol stack on the premise that the protocol stack continues to run; and after the dynamic loading is completed, performing a protocol stack switching operation. The method is used to achieve the effects of reducing switching delay and improving communication stability.

Description

Technical Field

[0001] This application relates to the field of Bluetooth communication technology, and in particular to a Bluetooth dual-mode switching method, device, medium, and program product. Background Technology

[0002] In high-frequency interaction scenarios such as smart wearable devices, IoT terminal devices, and in-vehicle Bluetooth systems, Bluetooth technology, as a short-range wireless communication technology, requires devices to frequently switch between low-power mode (Device mode) and high-bandwidth mode (Host mode). Therefore, how to switch between these two modes via Bluetooth is crucial.

[0003] Currently, existing Bluetooth dual-mode switching methods are mainly based on dynamic switching of a single protocol stack. This method dynamically loads protocol extension modules through the software layer, but it requires restarting part of the protocol stack and re-initializing the connection management module. However, because existing Bluetooth dual-mode switching methods require restarting the protocol stack or some modules during mode switching, the switching latency is relatively high, and the communication link is prone to interruption, resulting in poor communication stability. Summary of the Invention

[0004] This application provides a Bluetooth dual-mode switching method, device, medium, and program product to reduce switching latency and improve communication stability.

[0005] In a first aspect, embodiments of this application provide a Bluetooth dual-mode switching method, device, medium, and program product, the method comprising:

[0006] Establish a two-layer protocol stack architecture that includes a basic communication protocol layer and a dynamically loadable protocol extension layer;

[0007] After the target mode switching instruction is triggered, the protocol corresponding to the target mode is dynamically loaded and extended to the dynamically loadable layer of the two-layer protocol stack architecture; the dynamic loading means loading the protocol corresponding to the target mode to the dynamically loadable layer of the protocol stack while the protocol stack is running continuously.

[0008] After dynamic loading is complete, a protocol stack switching operation is performed.

[0009] In one possible implementation, the protocol for loading the target mode includes:

[0010] The target mode protocol extension module is loaded through a dynamic link library mechanism or containerization technology; the dynamic link library mechanism is to realize the immediate loading of the protocol extension module through dynamic link library technology, and the containerization technology is to encapsulate the protocol extension module with a lightweight container.

[0011] Maintain the running state of the underlying communication protocol layer during the loading process.

[0012] In one possible implementation, loading the target pattern protocol extension module via a dynamic link library mechanism or containerization technology includes:

[0013] Load the target protocol extension module;

[0014] After the target protocol extension module is loaded, the protocol stack running mode is switched using a context switching instruction.

[0015] In one possible implementation, prior to loading the protocol corresponding to the target pattern, the following steps are included:

[0016] The current application scenario is obtained through the scene recognition module;

[0017] Adjust the loading order of protocol extensions according to the current application scenario.

[0018] In one possible implementation, after the dynamic loading is completed, the following steps are included:

[0019] Read the pre-stored communication parameters from the memory; the pre-stored communication parameters are key communication parameters stored before the mode switch.

[0020] The read communication parameters are written into the target mode protocol extension module.

[0021] In one possible implementation, reading the pre-stored communication parameters from the memory includes at least one of the following:

[0022] Predict the key parameters required for the current mode switch using machine learning models;

[0023] Communication parameters are read according to priority using a block storage strategy.

[0024] In one possible implementation, after writing the read communication parameters into the target mode protocol extension module, the process includes:

[0025] Detect the signal strength of the communication link;

[0026] Adjust the transmission power according to the signal strength.

[0027] Secondly, embodiments of this application provide a Bluetooth dual-mode switching device, the device comprising:

[0028] A module is established to create a two-layer protocol stack architecture that includes a basic communication protocol layer and a dynamically loadable protocol extension layer.

[0029] The loading module is used to dynamically load the protocol corresponding to the target mode and extend it to the dynamically loadable layer of the two-layer protocol stack architecture after the target mode switching instruction is triggered; the dynamic loading means loading the protocol corresponding to the target mode to the dynamically loadable layer of the protocol stack while the protocol stack is running continuously.

[0030] The execution module is used to perform protocol stack switching operations after dynamic loading is complete.

[0031] Thirdly, embodiments of this application provide an electronic device, including: a memory and a processor; the memory stores computer-executable instructions; the processor executes the computer-executable instructions stored in the memory, causing the processor to perform the first aspect and / or various possible implementations of the first aspect as described above.

[0032] Fourthly, embodiments of this application provide a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, are used to implement the first aspect and / or various possible implementations of the first aspect.

[0033] Fifthly, embodiments of this application provide a computer program product, including a computer program that, when executed by a processor, implements the first aspect and / or various possible implementations of the first aspect.

[0034] The Bluetooth dual-mode switching method, device, medium, and program products provided in this application establish a two-layer protocol stack architecture including a basic communication protocol layer and a dynamically loadable protocol extension layer. This decouples the basic communication protocol from the mode-specific protocol, avoiding global initialization of the protocol stack. After a target mode switching command is triggered, the protocol corresponding to the target mode is dynamically loaded and extended to the dynamically loadable layer of the two-layer protocol stack architecture. This dynamic loading ensures that the protocol corresponding to the target mode is loaded into the dynamically loadable layer of the protocol stack while the protocol stack continues to run, maintaining the continuity of the communication link during the switching process. After dynamic loading is completed, a protocol stack switching operation is performed, reducing switching latency, avoiding communication link interruption issues, and thus improving communication stability. Attached Figure Description

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

[0036] Figure 1 A flowchart illustrating a Bluetooth dual-mode switching method provided in an embodiment of this application;

[0037] Figure 2 This application provides an architectural diagram of a Bluetooth dual-mode switching system.

[0038] Figure 3 This is a schematic diagram of the structure of a Bluetooth dual-mode switching device provided in an embodiment of this application;

[0039] Figure 4 This is a schematic diagram of the structure of an electronic device provided in this application.

[0040] The accompanying drawings illustrate specific embodiments of this application, which will be described in more detail below. These drawings and descriptions are not intended to limit the scope of the concept in any way, but rather to illustrate the concept of this application to those skilled in the art through reference to particular embodiments. Detailed Implementation

[0041] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numbers in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this application as detailed in the appended claims.

[0042] In this application, the terms "exemplary" or "for example" are used to indicate that something is an example, illustration, or description. Any embodiment or design described as "exemplary" or "for example" in this application should not be construed as being more preferred or advantageous than other embodiments or designs. Specifically, the use of terms such as "exemplary" or "for example" is intended to present the relevant concepts in a specific manner.

[0043] In the embodiments of this application, the use of terms such as "first" and "second" is to distinguish between identical or similar items that have essentially the same function and effect. For example, "first electronic device" and "second electronic device" are merely used to distinguish different electronic devices and do not limit their order of execution. Those skilled in the art will understand that the terms "first" and "second" do not limit the quantity or execution order, and that "first" and "second" do not necessarily imply that they are different.

[0044] In this application embodiment, "at least one" refers to one or more, and "more than one" refers to two or more. "And / or" describes the relationship between associated objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, or B existing alone, where A and B can be singular or plural. The character " / " generally indicates that the preceding and following associated objects have an "or" relationship.

[0045] The following is an explanation of some terms used in the embodiments of this application:

[0046] Host Mode Protocol Extensions: Host mode refers to a communication mode between a central or master device (such as a server, gateway, or cloud platform) and multiple slave devices (such as sensors, actuators, etc.). In Host mode, the central device is responsible for managing connections, authentication, data forwarding, and policy enforcement. Host mode protocol extensions refer to functional extensions implemented on the central device to support more complex data processing, security mechanisms, or additional services.

[0047] Device Mode Protocol Extensions: Device Mode refers to the communication mode between a slave device (such as a sensor, actuator, etc.) and a central device. In this mode, the slave device is typically the data source, while the central device is responsible for collecting, storing, or processing this data. Device Mode protocol extensions refer to functional extensions implemented on the slave device to support more efficient data transmission, low-power operation, or specific communication protocol support.

[0048] Static Random-Access Memory (SRAM) is a type of semiconductor random access memory. It is a volatile memory and is mainly used as a high-speed cache for processors. It is also widely used in embedded systems, communication equipment and other fields.

[0049] Dynamic Random Access Memory (DRAM) is a type of semiconductor memory that primarily works by using the amount of charge stored in a capacitor to represent whether a binary bit is 1 or 0.

[0050] In high-frequency interaction scenarios such as smart wearable devices, IoT terminal devices, and in-vehicle Bluetooth systems, Bluetooth technology, as a short-range wireless communication technology, requires devices to frequently switch between low-power mode (Device mode) and high-bandwidth mode (Host mode). Therefore, how to switch between these two modes via Bluetooth is crucial.

[0051] Currently, the main methods for Bluetooth dual-mode switching are as follows:

[0052] 1. Based on dynamic switching of a single protocol stack, this method dynamically loads protocol extension modules through the software layer, but requires restarting part of the protocol stack and reinitializing the connection management module. However, this method requires restarting the protocol stack or some modules when switching modes.

[0053] 2. Parallel operation of dual protocol stacks: This method switches between two complete protocol stacks using a hardware switcher to avoid protocol stack restarts. However, this method requires twice the hardware resources, resulting in increased power consumption.

[0054] 3. Caching technology assists in switching. This method caches communication parameters in memory before switching and quickly restores the parameters after switching. However, the cached data of this method may be lost due to timing issues during the switching process.

[0055] Therefore, existing Bluetooth dual-mode switching methods require restarting the protocol stack or some modules, or running both protocol stacks simultaneously, resulting in high switching latency and easy interruption of the communication link, making it impossible to avoid packet loss and thus leading to poor communication stability.

[0056] Considering the aforementioned problems with existing Bluetooth dual-mode switching methods, this application proposes a method for achieving dual-mode switching in scenarios with limited hardware resources through modular design and real-time parameter management. This method can reduce switching latency and improve communication stability.

[0057] The technical solutions of this application will be described in detail below with reference to specific embodiments. The specific embodiments described below can be combined with each other, and the same or similar concepts or processes may not be repeated in some embodiments. The embodiments of this application will be described below with reference to the accompanying drawings.

[0058] The entity executing this Bluetooth dual-mode switching method can be, for example, a switching system. Optionally, the switching system can be any existing electronic device with processing capabilities, such as a terminal or a server. In some embodiments, the switching system can also be deployed in a server cluster or cloud environment. This application does not limit the deployment environment of the switching system.

[0059] Figure 1 This is a flowchart illustrating a Bluetooth dual-mode switching method provided in an embodiment of this application, as shown below. Figure 1 As shown, the method includes:

[0060] S101 establishes a two-layer protocol stack architecture that includes a basic communication protocol layer and a dynamically loadable protocol extension layer.

[0061] For example, a two-layer protocol stack architecture can be a layered protocol structure consisting of a basic communication protocol layer and a dynamically loadable protocol extension layer. For instance, the basic communication protocol layer could be the Bluetooth core protocol, and the dynamically loadable protocol extension layer could be a Host mode protocol extension or a Device mode protocol extension.

[0062] For example, the basic communication protocol layer can be compatible with the Bluetooth 5.3 specification and include core protocol modules such as the physical layer, link layer, and host controller interface. For instance, this basic communication protocol layer does not change when the device switches operating modes.

[0063] For example, a dynamically loadable protocol extension layer can be a collection of protocol extension modules that are dynamically loaded or unloaded according to the device's operating mode requirements. For instance, switching between dynamically loadable protocol extension layers does not affect the stability of the underlying basic communication link.

[0064] Optionally, the switching system can define the application programming interface (API) interfaces of the basic communication protocol layer and the extension layer, determine the data interaction format and instruction set, and then use modular programming technology to encapsulate the Host mode protocol extension and Device mode protocol extension into independent software modules respectively.

[0065] Optionally, the switching system can also divide the system into independent resource areas for running protocol extension layers, using hardware virtualization technology to isolate the basic communication protocol layer from the hardware resources that can dynamically load protocol extension layers.

[0066] S102, after the target mode switching instruction is triggered, the protocol corresponding to the target mode is dynamically loaded and extended to the dynamically loadable layer of the two-layer protocol stack architecture; the dynamic loading means loading the protocol corresponding to the target mode to the dynamically loadable layer of the protocol stack while the protocol stack is running continuously.

[0067] In some embodiments, the switching system can load the target mode protocol extension module through a dynamic link library mechanism or containerization technology; the dynamic link library mechanism enables on-the-fly loading of the protocol extension module, while the containerization technology encapsulates the protocol extension module in a lightweight container. Then, the running state of the underlying communication protocol layer is maintained during the loading process.

[0068] For example, the dynamic link library mechanism can encapsulate protocol extension modules into independent dynamic link library files, which can be loaded into memory and invoked by the switching system in real time when needed.

[0069] For example, containerization technology can encapsulate protocol extension modules and their required operating environments as independent container instances.

[0070] For example, the target mode protocol extension module can be an upper-layer functional module developed based on the basic communication protocol layer, corresponding to the Host working mode or Device working mode, and needs to be dynamically loaded or unloaded during the mode switching process.

[0071] Optionally, the system can encapsulate the protocol extension logic for Host and Device working modes into separate dynamic link library files. Each dynamic link library can contain standardized interface functions, module initialization functions, data interaction functions, and module unloading functions. It can also define the API interfaces between the basic communication protocol layer and the protocol extension modules, specifying the data transmission format and command interaction rules. Simultaneously, the dependency libraries required for different protocol extension modules to run are packaged into the dynamic link library directory.

[0072] Optionally, upon receiving a mode switching trigger signal, the switching system can parse the target mode type (Host or Device), then call the module unloading function of the currently running module to release the memory resources occupied by that module and close the interface connection with the basic communication protocol layer. Using the dynamic link library loading function, it loads the dynamic link library file of the target mode protocol extension module into memory. It then calls the module initialization function, passing in the interface address of the basic communication protocol layer and the hardware parameters of the current device. If module loading fails, the switching system can maintain the operation of the current basic communication protocol layer and report an error log to the system.

[0073] For example, if a device is currently in Host mode and needs to connect to an industrial gateway as a slave device (switching to Device mode), the switching system can receive a mode switching command and unload the dynamic link library file corresponding to the currently running Host mode protocol extension module. Then, it calls the dynamic link library loading interface to load the corresponding link library file of the Device mode protocol extension module into memory in real time. Simultaneously, it establishes a standardized interface connection between the Device mode extension module and the basic communication protocol layer.

[0074] Optionally, the switching system can employ a lightweight container engine to build independent container images for each mode of protocol extension module. These container images may include, for example, the protocol extension module itself, dependent libraries, configuration files, and runtime components. The switching system can leverage a local network interface or partition a separate shared memory region within the host system to enable communication between the container and the underlying communication protocol layer.

[0075] Optionally, the switching system can determine the target mode based on the received mode switching command and query the container image name and configuration information corresponding to that mode. It then stops the currently running container instance via the container orchestration engine, releases occupied resources, pulls the target mode's container image from the local image repository, and creates and starts the container instance. After the container starts, it can automatically execute initialization scripts, establish communication channels between the module and the basic communication protocol layer, and load mode-specific configuration parameters. The switching system can also monitor the container's running status; if an anomaly occurs, it can automatically restart the container or switch to a standby mode. For mode containers that have not been used for more than a preset lifespan (e.g., two months), the switching system can clear them, releasing storage and memory resources.

[0076] For example, if the device is currently in Host mode and needs to connect to the industrial gateway as a slave device (switching to Device mode), after the switching system receives the mode switching command, it can also stop and unregister the container instance corresponding to the Host mode protocol extension module. Then, the container instance of the Device mode protocol extension module is started through the container orchestration engine. This container has encapsulated all the dependencies required for Device mode operation and realizes data interaction with the basic communication protocol layer through preset interfaces.

[0077] The above method loads the target mode protocol extension module through a dynamic link library mechanism or containerization technology. The dynamic link library mechanism enables real-time loading of the protocol extension module, while containerization technology encapsulates the protocol extension module in a lightweight container, reducing latency during protocol stack switching. Maintaining the running state of the basic communication protocol layer during loading avoids communication interruptions caused by protocol stack restarts, thus improving communication continuity.

[0078] As one possible implementation, the switching system can also load a target protocol extension module. Then, after the target protocol extension module is loaded, the protocol stack operating mode can be switched via a context switching instruction.

[0079] For example, a context switching instruction can be a mode switching control instruction, which includes mode identification information, context parameters, and execution trigger conditions.

[0080] Optionally, if the Device mode protocol extension module is loaded via a dynamic link library (DLL) mechanism, the switching system can load the Device mode protocol extension module into memory using DLL technology and call the module initialization function. During module initialization, it reads the Device mode communication parameters pre-stored by the intelligent cache management system and simultaneously binds the module to the basic communication protocol layer. After loading is complete, the Device mode protocol extension module can send a successful loading signal to the switching system and report the current module's running status parameters.

[0081] Optionally, after receiving a successful load signal, the switching system can detect the operating status of the basic communication protocol layer. If it confirms that the basic communication protocol layer is in a stable operating state, it generates a context switching instruction and sends the context switching instruction to the mode control unit of the two-layer protocol stack through the API interface.

[0082] Optionally, upon receiving the instruction, the mode control unit calls the module unload function of the currently running mode protocol extension module to release the context resources occupied by that module. Based on the parameter cache address in the instruction, it reads the pre-stored target mode parameters and passes them to the loaded target mode protocol extension module, activating its functional logic. Then, the mode control unit can update the protocol stack running status flag, marking the current mode as the target mode, and sending a switching completion signal back to the switching system. Simultaneously, the basic communication protocol layer establishes a stable data interaction channel with the target mode extension module and begins data transmission according to the target mode's communication logic.

[0083] Optionally, after receiving the handover completion signal, the handover system triggers the connection quality detection module to determine the stability of the link by detecting the Received Signal Strength Indicator (RSSI) value and packet loss rate of the current communication link. If problems such as parameter verification failure or module activation anomaly occur during the handover process, the handover system can immediately issue a mode rollback command to restore the operating mode before the handover, and simultaneously report the error log.

[0084] For example, after the target protocol extension module is loaded, the switching system generates a context switching command and sends it to the mode control unit. This command calls the unload function of the currently running module to release resources and simultaneously passes pre-stored parameters to the target module, activating its functional logic. The atomic operation of the context switching command ensures reduced switching latency and avoids communication link interruptions.

[0085] By using the above method, the target protocol extension module is loaded. After the target protocol extension module is loaded, the protocol stack running mode is switched through the context switching instruction, which improves the switching efficiency and stability.

[0086] As one possible implementation, before loading the protocol corresponding to the target mode, the switching system can obtain the current application scenario through the scenario recognition module, and then adjust the loading order of protocol extensions according to the current application scenario.

[0087] For example, it could be a module that identifies the current application scenario through sensor data or user instructions, such as identifying a health detection scenario through a health detection sensor.

[0088] For example, adjusting the loading order of protocol extensions can be done by prioritizing the loading of specific protocol extension modules according to scenario requirements, such as prioritizing the loading of low-power protocol extensions in a health detection scenario.

[0089] Optionally, upon receiving a mode switching command, the switching system can use the scene recognition module to collect and determine the current scene type based on information collected from preset input sources and matched with a built-in scene feature library. For example, if continuous heart rate sensor data and low-amplitude acceleration data are collected, the switching system can determine it as a health monitoring scene; if a pairing request from the vehicle's Bluetooth is collected and the location data shows that the vehicle is in motion, the switching system can determine it as a vehicle communication scene; if the user's voice command "play music" and the Bluetooth headset connection signal are collected, the switching system can determine it as a multimedia playback scene.

[0090] Optionally, the switching system can determine the loading order of protocol extensions based on a pre-stored mapping table of application scenarios and loading rule bases. For example, in a health monitoring scenario, the loading order could be: health data transmission module, low-power scheduling module, and multi-device management module; in an in-vehicle communication scenario, the loading order could be: voice call module, data encryption module, and low-power scheduling module; and in a multimedia playback scenario, the loading order could be: audio decoding module, high-bandwidth transmission module, and multi-device management module.

[0091] Optionally, the switching system can also prioritize loading core modules based on the matched loading order, allocating more memory resources to core modules, and then starting to load non-core modules after the core modules have finished loading. For example, once the core modules have finished loading and adapted to the basic protocol layer, the switching system can issue a context switching command to switch to the target running mode, while non-core modules are silently loaded in the background.

[0092] Using the above method, before loading the protocol corresponding to the target mode, the current application scenario is obtained through the scenario recognition module, providing a basis for subsequent adjustments based on the application scenario. The loading order of protocol extensions is adjusted according to the current application scenario to avoid resource waste and improve switching efficiency and scenario adaptability.

[0093] S103 performs a protocol stack switching operation after dynamic loading is complete.

[0094] As one possible implementation, after the dynamic loading is complete, the switching system can read pre-stored communication parameters from memory; these pre-stored communication parameters are key communication parameters stored before the mode switch. The read communication parameters are then written to the target mode protocol extension module.

[0095] For example, the memory may be a storage medium used to store key communication parameters.

[0096] For example, key communication parameters can be core configuration data that maintains the stability of the communication link, such as device pairing keys, connection handles, channel mapping tables, data transmission sequence numbers, RSSI threshold configurations, and power regulation parameters.

[0097] Optionally, before the mode switching instruction is triggered, the intelligent cache management system can collect key communication parameters in the current mode, verify them, write them to the memory, and generate parameter verification codes.

[0098] Optionally, after the target module is loaded, the switching system can send a parameter read command to the memory, read the corresponding key communication parameters from the memory, and return the parameter data and checksum to the switching system. The switching system verifies the received parameters. If the verification fails, a parameter rereading mechanism is triggered; if multiple rereads (e.g., 3 times) fail, the system switches to the default parameter configuration.

[0099] Optionally, the switching system can call the parameter writing interface of the target module to write the verified key communication parameters into the parameter storage area of ​​the target module in a preset format, and can also provide real-time feedback on the writing progress based on the target module.

[0100] Optionally, after the parameters are written, the target mode protocol extension module can configure the written communication parameters to the corresponding functional unit. Based on the effective communication parameters, the target module will work with the basic communication protocol layer to establish a data transmission link. At the same time, the switching system will issue a context switching command to complete the formal switch of the protocol stack operating mode.

[0101] Using the method described above, after the dynamic loading is completed, pre-stored communication parameters are read from the memory. These pre-stored communication parameters are key communication parameters stored before the mode switch, enabling rapid recovery of communication parameters and reducing the risk of data interruption during the switchover process. The read communication parameters are then written into the target mode protocol extension module to improve the reliability and stability of data transmission.

[0102] As one possible implementation, the handover system can use machine learning models to predict the key parameters required for the current mode switch. The handover system can also use a block storage strategy to read communication parameters according to priority.

[0103] For example, a machine learning model can be a predictive model trained on historical data, such as a parameter requirement prediction model based on decision trees or neural networks.

[0104] For example, a block storage strategy could be to divide the communication parameters into storage blocks according to their priority, such as storing high-priority parameters in low-address blocks of high-speed memory.

[0105] Optionally, the switching system can collect historical mode switching data such as scene type, modes before and after switching, device operating status, switching latency, and packet loss rate. The collected raw data is then cleaned, deduplicated, and completed. Missing data is filled using interpolation, continuous data is normalized, and categorical data is encoded to form a training dataset. This dataset is then divided into training, validation, and test sets in a 7:2:1 ratio.

[0106] Optionally, the switching system can use a decision tree for training, setting the depth of the decision tree (e.g., 8 layers), node splitting threshold, logistic regression regularization coefficient (e.g., 0.05), and learning rate (e.g., 0.05). Simultaneously, the model's loss function (e.g., cross-entropy loss function) is initialized, and the termination condition for model training is determined (training iterations greater than or equal to 1000).

[0107] Optionally, the switching system can input training set data into the initialized model, calculate the model's predicted output through forward propagation, compare the predicted output with the actual value, update the model parameters through backpropagation, and minimize the loss function value. This process is repeated until the aforementioned training termination condition is met, completing the initial model training. The switching system can also use validation set data to validate the performance of the initially trained model, calculating the model's prediction accuracy. If the prediction accuracy is less than 95%, model parameters are adjusted, such as adjusting the decision tree depth. Through multiple iterative parameter adjustments, a machine learning model with a prediction accuracy greater than or equal to 99% can be obtained.

[0108] Optionally, upon receiving a mode switching command, the switching system can activate the scene recognition module to obtain the current application scene, while simultaneously collecting real-time device operating status data. The scene features, current mode, and device status data are input into the aforementioned machine learning model, outputting a list of predicted key parameters and their priority ranking. The switching system can upload the predicted parameter list to the intelligent cache management system. If the corresponding parameters are pre-stored in the memory, their priority is marked; otherwise, the intelligent cache management system prioritizes collecting the higher-priority predicted parameters and writing them into the memory.

[0109] Optionally, after the target mode protocol extension module is dynamically loaded, the switching system can send priority-based read commands to the memory based on the parameter priorities predicted by the machine learning model.

[0110] Optionally, the switching system can prioritize reading high-priority data blocks based on the aforementioned priority-based read instructions, and write these high-priority data blocks into the target mode protocol extension module via the parameter write interface. After the high-priority parameters take effect and the basic link is initially established, the system reads the medium-priority data blocks and writes them into the target module. Then, based on the current device load and communication requirements, it determines whether to read low-priority data blocks. If the device load is low, the switching system can decide to read low-priority parameters to optimize power regulation and other functions; if the device load is high, the switching system can decide not to read them temporarily and to read them after communication stabilizes.

[0111] By using the methods described above, such as predicting the key parameters required for the current mode switching through machine learning models, or reading communication parameters according to priority through a block storage strategy, parameter recovery efficiency can be improved, switching latency can be reduced, and communication stability can be enhanced.

[0112] As one possible implementation, after the read communication parameters are written into the target mode protocol extension module, the switching system can detect the signal strength of the communication link and adjust the transmission power according to the signal strength.

[0113] For example, the signal strength of a communication link can refer to the signal strength measured by indicators such as RSSI.

[0114] For example, adjusting the transmit power can be achieved by dynamically adjusting the transmit power using an RF power amplifier.

[0115] Optionally, after the read communication parameters are written into the target mode protocol extension module, the switching system can trigger the link signal strength detection unit to send a detection command to the radio frequency module, receive signal feedback from the peripheral master device through the radio frequency module, calculate the RSSI value of the current link, compare the value with a preset threshold, and output the signal strength level.

[0116] Optionally, the handover system can match the corresponding power adjustment strategy based on a pre-stored signal strength and power adjustment rule library. For example, if the RSSI value is greater than or equal to -50dBm, the handover system can determine that the signal strength level is a strong signal, reduce the transmit power by 2dB, and maintain the base power; if the RSSI value is between -70dBm and -50dBm, the handover system can determine that the signal strength level is a medium signal and maintain the current default power; if the RSSI value is less than -70dBm, the handover system can determine that the signal strength level is a weak signal and can increase the transmit power by 3dB.

[0117] Optionally, after adjustment, the switching system can continuously monitor RSSI value changes based on the link signal strength detection unit. If the adjusted RSSI rises back to the medium signal range, a secondary adjustment is triggered to reduce the power back to the default level. If the signal still does not improve after adjustment, a channel switching mechanism is triggered, and the communication channel is changed using a pre-stored channel mapping table. If it is confirmed that the link RSSI value is stable within the medium signal range and remains unchanged for 500ms, the switching system can determine that the mode switching process is complete and the protocol stack enters the stable operating state of the target mode.

[0118] By writing the read communication parameters into the target mode protocol extension module using the above method, the signal strength of the communication link is detected, laying the foundation for subsequent adjustment of the transmission power. Adjusting the transmission power based on this signal strength reduces connection drops during handover and improves communication stability.

[0119] Optionally, a layered protocol stack architecture decouples the basic communication protocol layer from the dynamically loaded protocol extension layer, eliminating the need to restart the entire protocol stack during mode switching. The dynamically loaded protocol extension layer loads the target mode protocol while the protocol stack continues to run, ensuring the basic communication protocol layer maintains data transmission functionality and preventing communication link interruptions. For example, when a smartwatch switches from low-power mode to high-bandwidth mode, the Host mode protocol extension is dynamically loaded into the dynamic loading layer, while the basic communication protocol layer maintains data synchronization with the phone, significantly reducing switching latency and improving communication continuity.

[0120] In this embodiment, a two-layer protocol stack architecture is established, comprising a basic communication protocol layer and a dynamically loadable protocol extension layer. This decouples the basic communication protocol from mode-specific protocols, avoiding global initialization of the protocol stack. Upon triggering a target mode switching command, the protocol corresponding to the target mode is dynamically loaded and extended to the dynamically loadable layer of the two-layer protocol stack architecture. This dynamic loading ensures the basic communication protocol layer continues to operate during the switching process, maintaining the continuity of the communication link. After dynamic loading is complete, a protocol stack switching operation is performed, reducing switching latency, preventing communication link interruptions, and thus improving communication stability.

[0121] Figure 2 This is a schematic diagram of the architecture of a Bluetooth dual-mode switching system provided in an embodiment of this application, as shown below. Figure 2 As shown, the Bluetooth dual-mode switching system includes a two-layer protocol stack architecture, an intelligent buffer management system, and an adaptive power adjustment algorithm. Among these,

[0122] The two-layer protocol stack architecture includes the underlying basic Bluetooth communication protocol and the upper layer dynamically loaded Host / Device-specific protocol extensions;

[0123] The intelligent cache management system includes a dedicated cache area and a parameter pre-storage module;

[0124] The adaptive power adjustment algorithm includes a connection quality detection module and a transmit power adjustment module.

[0125] Optionally, the dedicated buffer can be an SRAM memory with a capacity of 64KB; the transmit power adjustment module uses a programmable RF power amplifier to support dynamic power adjustment.

[0126] Optionally, before mode switching, the intelligent cache management system can pre-store key communication parameters in a dedicated cache area; during the switching process, the dual-layer protocol stack architecture realizes dynamic loading of the protocol stack through hot-swapping technology, without the need to restart the entire protocol stack; the adaptive power adjustment algorithm detects the connection quality in real time, automatically increases the transmit power by 3dB during the switching transition period to maintain connection stability, and restores to the optimal power level after the switching is completed.

[0127] This application also proposes a method for intelligent Bluetooth dual-mode instant switching, the method comprising:

[0128] (1) Startup mode switching command;

[0129] (2) The intelligent cache management system pre-stores key communication parameters in a dedicated cache area;

[0130] (3) Dynamic loading of target mode protocol extensions using a two-layer protocol stack architecture;

[0131] (4) The adaptive power adjustment algorithm increases the transmit power by 3dB;

[0132] (5) Complete the mode switch and restore the optimal power level.

[0133] Optionally, the dedicated buffer can be replaced with DRAM memory, and a power management module can be added; the transmit power adjustment module can also be replaced with a fixed gain amplifier.

[0134] Optionally, the switching system can also employ a three-protocol stack architecture, further improving switching speed by adding redundant protocol stacks. For example, the switching system can be designed with a two-layer protocol stack architecture, where the bottom layer retains the basic Bluetooth communication protocol, and the upper layer dynamically loads Host / Device-specific protocol extensions. Hot-swappable protocol stack technology can be used to ensure that the entire protocol stack does not restart during mode switching. An intelligent cache management system can be developed to pre-store key communication parameters in a dedicated cache area before mode switching.

[0135] Optionally, communication can be restored immediately after handover to ensure data transmission continuity and reduce packet loss during the handover process. An adaptive power adjustment algorithm is employed to dynamically adjust the transmit power in real time based on connection quality. During the mode handover transition, the transmit power is automatically increased by 3dB to maintain connection stability, and then restored to the optimal power level after the handover is complete.

[0136] Figure 3 This is a schematic diagram of the structure of a Bluetooth dual-mode switching device provided in an embodiment of this application, as shown below. Figure 3 As shown, the Bluetooth dual-mode switching device 300 includes:

[0137] Module 301 is used to establish a two-layer protocol stack architecture that includes a basic communication protocol layer and a dynamically loadable protocol extension layer.

[0138] The loading module 302 is used to dynamically load the protocol corresponding to the target mode and extend it to the dynamically loadable layer of the two-layer protocol stack architecture after the target mode switching instruction is triggered; the dynamic loading means loading the protocol corresponding to the target mode to the dynamically loadable layer of the protocol stack while the protocol stack is running continuously.

[0139] Execution module 303 is used to perform protocol stack switching operations after dynamic loading is completed.

[0140] Optionally, loading module 302 is also used to load the target mode protocol extension module through a dynamic link library mechanism or containerization technology; the dynamic link library mechanism is to realize the immediate loading of the protocol extension module through dynamic link library technology, and the containerization technology is to encapsulate the protocol extension module through a lightweight container.

[0141] Maintain the running state of the underlying communication protocol layer during the loading process.

[0142] Optionally, loading module 302 is also used to load the target protocol extension module;

[0143] After the target protocol extension module is loaded, the protocol stack running mode is switched using a context switching instruction.

[0144] Optionally, the loading module 302 is also used to obtain the current application scenario through the scene recognition module before loading the protocol corresponding to the target mode; and to adjust the loading order of protocol extensions according to the current application scenario.

[0145] Optionally, the execution module 303 is further configured to read pre-stored communication parameters from the memory after the dynamic loading is completed; the pre-stored communication parameters are key communication parameters stored before the mode switch; and write the read communication parameters into the target mode protocol extension module.

[0146] Optionally, the execution module 303 is also used to predict the key parameters required for the current mode switching through a machine learning model;

[0147] Communication parameters are read according to priority using a block storage strategy.

[0148] Optionally, the execution module 303 is further configured to, after writing the read communication parameters into the target mode protocol extension module, detect the signal strength of the communication link and adjust the transmission power according to the signal strength.

[0149] The Bluetooth dual-mode switching device provided in this application can be used to execute the technical solutions of any of the above embodiments of this application. Its implementation principle and technical effect are similar, and will not be described again here.

[0150] Figure 4 This is a schematic diagram of the structure of an electronic device provided in this application. Figure 4 As shown, the electronic device 400 provided in this embodiment includes at least one processor 401 and a memory 402. Optionally, the device 400 further includes a communication component 403. The processor 401, memory 402, and communication component 403 are connected via a bus 404.

[0151] In a specific implementation, at least one processor 401 executes computer execution instructions stored in memory 402, causing at least one processor 401 to perform the above-described method.

[0152] Optionally, the memory 402 can be either standalone or integrated with the processor 401.

[0153] The implementation principle and technical effects of the electronic device provided in this embodiment can be found in the foregoing embodiments, and will not be repeated here.

[0154] This application also provides a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, implement the method of any of the foregoing embodiments.

[0155] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the method of any of the foregoing embodiments.

[0156] In the several embodiments provided in this application, it should be understood that the disclosed 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 there may be other division methods in actual implementation. For example, multiple modules may be combined or integrated into another system, or some features may be ignored or not executed.

[0157] The integrated modules described above, implemented as software functional modules, can be stored in a computer-readable storage medium. These software functional modules, stored in a storage medium, include several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) or processor to execute some steps of the methods of the various embodiments of this application.

[0158] It should be understood that the aforementioned processor can be a Central Processing Unit (CPU) or other general-purpose processors. The processor can also be a Digital Signal Processor (DSP) or an Application Specific Integrated Circuit (ASIC), etc. A general-purpose processor can be a microprocessor or any conventional processor. The steps of the method disclosed in the application can be directly manifested as being executed by a hardware processor, or executed by a combination of hardware and software modules within the processor.

[0159] The memory may include random access memory (RAM) and may also include non-volatile memory (NVM), such as at least one disk storage device, and may also be various media that can store program code, such as USB flash drives, portable hard drives, read-only memory (ROM), disks or optical discs.

[0160] The aforementioned storage medium can be implemented by any type of volatile or non-volatile storage device or a combination thereof. Examples of storage media include Static Random-Access Memory (SRAM) or Electrically Erasable Programmable Read Only Memory (EEPROM).

[0161] Storage media can be, for example, erasable programmable read-only memory (EPROM) or programmable read-only memory (PROM). Storage media can also be read-only memory (ROM), magnetic storage, flash memory, magnetic disks, or optical disks. Storage media can be any available medium accessible to general-purpose or special-purpose computers.

[0162] An exemplary storage medium is coupled to a processor, enabling the processor to read information from and write information to the storage medium. Alternatively, the storage medium can be an integral part of the processor. The processor and storage medium can reside within an application-specific integrated circuit (ASIC). Alternatively, the processor and storage medium can exist as discrete components within an electronic device or host device.

[0163] It should be noted that, in this document, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Unless otherwise specified, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes that element.

[0164] The sequence numbers of the embodiments in this application are merely for description and do not represent the superiority or inferiority of the embodiments. Through the above description of the embodiments, those skilled in the art can clearly understand that the methods of the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method.

[0165] Based on this understanding, the technical solution of this application, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk) and includes several instructions to cause a terminal device (which may be a mobile phone, computer, server, or network device, etc.) to execute the methods of the various embodiments of this application.

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

[0167] It should be noted that, for the sake of simplicity, the foregoing method embodiments are all described as a series of actions. However, those skilled in the art should understand that this application is not limited to the described order of actions, as some steps may be performed in other orders or simultaneously according to this application. Furthermore, those skilled in the art should also understand that the embodiments described in the specification are all optional embodiments, and the actions and modules involved are not necessarily essential to this application.

[0168] It should be further noted that although the steps in the flowchart are shown sequentially as indicated by the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless otherwise explicitly stated in this document, there is no strict order requirement for the execution of these steps, and they can be executed in other orders.

[0169] Furthermore, at least some steps in the flowchart may include multiple sub-steps or multiple stages. These sub-steps or stages are not necessarily completed at the same time, but may be executed at different times. The execution order of these sub-steps or stages is not necessarily sequential, but may be executed in turn or alternately with other steps or at least some of the sub-steps or stages of other steps.

[0170] In the above embodiments, the descriptions of each embodiment have their own emphasis. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions of other embodiments. The technical features of the above embodiments can be combined arbitrarily. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as the combination of these technical features does not contradict each other, it should be considered within the scope of this specification.

[0171] Other embodiments of this application will readily occur to those skilled in the art upon consideration of the specification and practice of the invention disclosed herein. This application is intended to cover any variations, uses, or adaptations of this application that follow the general principles of this application and include common knowledge or customary techniques in the art not disclosed herein. The specification and examples are to be considered exemplary only, and the true scope and spirit of this application are indicated by the following claims.

[0172] It should be understood that this application is not limited to the precise structure described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of this application is limited only by the appended claims.

Claims

1. A Bluetooth dual-mode switching method, characterized in that, The method includes: Establish a two-layer protocol stack architecture that includes a basic communication protocol layer and a dynamically loadable protocol extension layer; After the target mode switching instruction is triggered, the protocol corresponding to the target mode is dynamically loaded and extended to the dynamically loadable layer of the two-layer protocol stack architecture; the dynamic loading means loading the protocol corresponding to the target mode to the dynamically loadable layer of the protocol stack while the protocol stack is running continuously. After dynamic loading is complete, a protocol stack switching operation is performed.

2. The method according to claim 1, characterized in that, The protocol for loading the target mode includes: The target mode protocol extension module is loaded through a dynamic link library mechanism or containerization technology; the dynamic link library mechanism is to realize the immediate loading of the protocol extension module through dynamic link library technology, and the containerization technology is to encapsulate the protocol extension module with a lightweight container. Maintain the running state of the underlying communication protocol layer during the loading process.

3. The method according to claim 2, characterized in that, The loading of the target mode protocol extension module through dynamic link library mechanism or containerization technology includes: Load the target protocol extension module; After the target protocol extension module is loaded, the protocol stack running mode is switched using a context switching instruction.

4. The method according to any one of claims 2-3, characterized in that, Before loading the protocol corresponding to the target mode, the following steps are included: The current application scenario is obtained through the scene recognition module; Adjust the loading order of protocol extensions according to the current application scenario.

5. The method according to claim 1, characterized in that, After the dynamic loading is completed, the following is included: Read the pre-stored communication parameters from the memory; the pre-stored communication parameters are key communication parameters stored before the mode switch. The read communication parameters are written into the target mode protocol extension module.

6. The method according to claim 5, characterized in that, The reading of pre-stored communication parameters from the memory includes at least one of the following: Predict the key parameters required for the current mode switch using machine learning models; Communication parameters are read according to priority using a block storage strategy.

7. The method according to claim 5, characterized in that, After writing the read communication parameters into the target mode protocol extension module, the process includes: Detect the signal strength of the communication link; Adjust the transmission power according to the signal strength.

8. An electronic device, characterized in that, include: Memory and processor; The memory stores computer-executed instructions; The processor executes computer execution instructions stored in the memory, causing the processor to perform the method as described in any one of claims 1-7.

9. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer-executable instructions, which, when executed by a processor, are used to implement the method as described in any one of claims 1-7.

10. A computer program product, characterized in that, Includes a computer program that, when executed by a processor, implements the method according to any one of claims 1-7.

Images