RFCOMM connection handover between two different stacks

Abstract

Various embodiments include a method for a computing device to manage radio frequency communication (RFCOMM) connection handover between a first Bluetooth (BT) stack and a second BT stack. Embodiments may include establishing an asynchronous connection-oriented logical transport connection with a BT device; and transmitting a synchronization message including BT context information from the first BT stack to the second BT stack. The method may also include establishing an RFCOMM session between the computing device and the BT device; receiving, by the first BT stack, a set asynchronous balance mode (SABM) command from the BT device; the SABM command is sent to the second BT stack; sending a filtering policy based on the SABM command from the second BT stack to a BT controller of the computing device; a ready message is sent from the second BT stack of when the BT controller has been configured and an unnumbered acknowledgement (UA) message is sent to the BT device.

Description

Background Art

[0001] User equipment (UE) and consumer devices for communicating data via Bluetooth (BT) / Bluetooth Low Energy (BLE) have become increasingly complex, especially in devices that implement active mode and low power mode features. In active mode, the application processor can manage the BLE connection and operation of high-performance BT applications. In order to save battery life, the device can transition from active mode to low power mode during the time when the high-performance BT application is not operating or has minimal functionality and processes that can be fully handled by a separate low-power processor. In low power mode, a second processor with limited functionality can manage the baseline operation of the high-performance application. The low-power processor can also fully manage the BT application that requires minimal processing power, thereby eliminating the need to supply operating power to the application processor. Transitioning between active mode and low power mode may require a significant amount of supervision and computing resources to ensure that the BLE context information and other BT data related to the ongoing operation of both BT and BLE applications are not lost, out of sync or redirected to an incorrect BT stack. Summary of the Invention

[0002] Various aspects include a method, executable by a computing device, for managing a radio frequency communication (RFCOMM) connection handover between a first Bluetooth (BT) stack and a second BT stack. The various aspects may include receiving a connection request message from a BT device; establishing an asynchronous connection-oriented logical transport (ACL) connection between the computing device and the BT device in response to the connection request message; and sending a synchronization message including BT context information from the first BT stack to the second BT stack. In some aspects, the BT context information may include at least one of a BT device address (BD_ADDR), a link key, or a connection handle.

[0003] Some aspects may also include receiving, by the first BT stack, a Service Discovery Protocol (SDP) search request message from the BT device; and sending, from the first BT stack to the BT device, an SDP response message in response to the SDP request message.

[0004] Some aspects may also include instantiating the first BT stack and the second BT stack when the computing device boots up; receiving, by the first BT stack, a secondary SDP database from the second BT stack; and storing the primary SDP database of the first BT stack along with the secondary SDP database.

[0005] Some aspects may also include receiving, by the first BT stack, a secondary SDP database from the second BT stack in response to transitioning from a low power mode to an active mode of the computing device; and storing a primary SDP database of the first BT stack along with the secondary SDP database.

[0006] Some aspects may also include establishing an RFCOMM session between the computing device and the BT device; receiving, by the first BT stack, a Set Asynchronous Balanced Mode (SABM) command from the BT device; sending, from the first BT stack to the second BT stack, the SABM command; sending, from the second BT stack, a filtering policy to a BT controller of the computing device, wherein the filtering policy is based on the SABM command; sending, from the second BT stack to the first BT stack, a ready message indicating that the BT controller has been configured with the filtering policy; and sending, from the first BT stack, an Unnumbered Acknowledgement (UA) message to the BT device. Some aspects may also include receiving, by the BT controller, an Unnumbered Information (UIH) frame with header inspection including a Parameter Negotiation (PN) command from the BT device; determining, by the BT controller, a destination stack for the PN command based on the filtering policy, wherein the destination stack is the first BT stack or the second BT stack; sending, from the BT controller, the PN command to the destination stack; and sending, from the destination stack to the BT device, a PN response in response to the PN command.

[0007] Some aspects may also include establishing an RFCOMM session between the computing device and the BT device; receiving, by the first BT stack, a SABM command from the BT device; sending, from the first BT stack, a UA message to the BT device; receiving, by the first BT stack, a UIH frame including a PN command from the BT device; determining, by the first BT stack, whether a data link connection identifier (DLCI) channel is implemented by an application processor that implements the first BT stack or a low power processor that implements the second BT stack; and performing one of the following: sending, from the first BT stack to the BT device, a message including a non-zero credit value (cr) in response to determining that the DLCI channel is implemented by the application processor. edit); or in response to determining that the DLCI channel is implemented by the low-power processor, sending a UA response message including a zero credit value from the first BT stack to the BT device; receiving a subsequent SABM command from the BT device by the first BT stack; sending the subsequent SABM command from the first BT stack to the second BT stack; sending a filtering policy from the second BT stack to a BT controller of the computing device, wherein the filtering policy is based on the subsequent SABM command; sending a subsequent UA message from the second BT stack to the BT device; and sending a subsequent UIH message including a non-zero credit value from the second BT stack to the BT device.

[0008] Additional aspects may include a computing device having a processor configured to perform the operations of any of the methods outlined above. Additional aspects may include a computing device having components for performing the functionality of any of the methods outlined above. Additional aspects may include a non-transitory processor-readable medium having stored thereon processor-executable instructions configured to cause a processor of the computing device to perform the operations of any of the methods outlined above. BRIEF DESCRIPTION OF THE DRAWINGS

[0009] The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate exemplary embodiments of the claims and, together with the general description and detailed description given, serve to explain the features herein.

[0010] Figure 1 is a system block diagram illustrating an example communication system suitable for implementing any of the various embodiments.

[0011] Figure 2 is a component block diagram illustrating an example computing device suitable for implementing any of the various embodiments.

[0012] Figure 3 is a component block diagram illustrating an example system for managing a radio frequency communication (RFCOMM) connection handover between two different stacks, according to some embodiments.

[0013] Figure 4 is a component block diagram illustrating an example Bluetooth (BT) / Bluetooth Low Energy (BLE) system architecture according to some embodiments.

[0014] Figures 5A to 5C is a message flow diagram illustrating operations for managing an RFCOMM connection handover between two different BT stacks according to some embodiments.

[0015] Figure 6A is a process flow diagram of an example method executable by a computing device for managing an RFCOMM connection handover between two different stacks, according to various embodiments.

[0016] Figures 6B to 6H is according to some embodiments may be used as described for managing RFCOMM connection handover between two different stacks Figure 6A A process flow diagram of example operations performed as part of the method illustrated in FIG.

[0017] Figure 7 is a component block diagram illustrating an example computing device suitable for use with various embodiments.

[0018] Figure 8is a component block diagram illustrating an example wireless communication device suitable for use with various embodiments.

[0019] Figure 9 An example wearable computing device in the form of a smartwatch is illustrated in accordance with some embodiments. DETAILED DESCRIPTION

[0020] Various embodiments will be described in detail with reference to the accompanying drawings. Wherever possible, the same reference numerals will be used throughout the drawings to refer to the same or similar parts. Reference to specific examples and specific implementations is for illustrative purposes and is not intended to limit the scope of the claims.

[0021] Various embodiments described herein include BT devices and methods that facilitate a transition of a radio frequency communication (RFCOMM) connection between a Bluetooth (BT) stack of an application processor and a BT stack of a low-power processor, and a BT processor. Various embodiments include operations for synchronizing Service Discovery Protocol (SDP) information during concurrent operation of the low-power processor and the application processor (i.e., during transitions between active mode and low-power mode, and vice versa).

[0022] The term "system on a chip" (SoC) is used herein to refer to a single integrated circuit (IC) chip that includes multiple resources and / or processors integrated on a single substrate. A single SoC may include circuits for digital, analog, mixed-signal, and radio frequency functions. A single SoC may also include any number of general-purpose and / or specialized processors (digital signal processors, modem processors, video processors, etc.), memory blocks (e.g., ROM, RAM, flash memory, etc.), and resources (e.g., timers, voltage regulators, oscillators, etc.). The SoC may also include software for controlling the integrated resources and processors, as well as for controlling peripheral devices.

[0023] The term "system-in-package" (SIP) may be used herein to refer to a single module or package that contains multiple resources, computing units, cores and / or processors on two or more IC chips, substrates, or SoCs. For example, a SIP may include a single substrate on which multiple IC chips or semiconductor dies are stacked in a vertical configuration. Similarly, a SIP may include one or more multi-chip modules (MCMs) on which multiple ICs or semiconductor dies are packaged into a unified substrate. A SIP may also include multiple independent SoCs that are coupled together via high-speed communication circuits and packaged in close proximity, such as on a single motherboard or in a single computing device. The proximity of the SoCs facilitates high-speed communication and the sharing of memory and resources.

[0024] The term "BT data" may be used herein to refer to any data received or sent across a BT / Bluetooth Low Energy (BLE) connection and any information associated with conveying data across the BT / BLE connection. Specifically, BT data may refer to any data (e.g., data packets) received or sent to an endpoint (e.g., a BT / BLE application) across a BT or BLE connection. BT data may also refer to any information used to establish and maintain a BT / BLE connection and to communicate data packets through various layers of a BT / BLE stack (e.g., a BT controller, a host, an application) of a processor (e.g., a low-power processor, a high-performance or application processor), such as packet header information, system information blocks (SIBs), system integrity information such as the number of completion packets (NoCP), service discovery protocol (SDP) information, packet identifiers, attribute handles, connection handles, and channel identifiers associated with BT data packets.

[0025] An increasing number of wireless-capable devices that require or support high-performance operation are being developed. Due to the implementation of increasingly complex processors, the power consumption within these devices has increased. The increased power consumption is particularly problematic in smaller devices (such as battery-powered wearable devices, including smart watches, virtual reality (VR) goggles, smart glasses, and medical devices that typically utilize small-form-factor rechargeable batteries due to physical design constraints). Such devices often utilize BT and / or BT low power (BLE) to convey information to another paired device. Notifications and scanning for devices, as well as establishing and maintaining BT / BLE connections, may further increase the power consumption within a given device.

[0026] To accommodate this increase in power demands, wearable devices are being designed with two processors: an application or high-performance processor that manages the operation of high-performance BT applications during active or high-performance mode; and a low-power BT processor that manages low-power BT applications and also manages baseline device operations during low-power mode when high-performance BT applications do not require advanced levels of processing capabilities.

[0027] Typically, in low-power mode, the application processor is turned off or in sleep mode, and the low-power processor takes over control of device operations. When a BT / BLE application requires a high degree and / or amount of processing, the application processor can be activated or woken up and enter active mode. Such devices frequently transfer processing of BT / BLE applications from the low-power processor back to the application processor, and vice versa, to minimize power consumption.

[0028] Transitioning between active mode and low power mode requires sharing and passing BT context information between the application processor's BT protocol stack and the low power processor's BT protocol stack. Synchronization and / or shared BT context information between the application processor and the low power processor is required to maintain existing BT / BLE connections and maintain lossless data transfer throughout those BT / BLE connections. This synchronization may require computing processes and resources, which may increase the transition time between active mode and low power mode. For example, the application processor's BT stack may receive an SDP request from a paired BT device, but may have to perform multiple operations to obtain SDP information from the low power processor's BT stack. As a result, the application processor may spend more time in active mode than is required to meet the device's processing needs, and therefore may not maximize battery power savings.

[0029] More specifically, the various RFCOMM services within the computing device (i.e., RFCOMM services on both the application processor and the low power processor) will employ different service channels, each represented by a data link connection identifier (DLCI) number (e.g., DLCI0, DLCI1, etc.). Whenever the computing device receives an SDP request from a paired external BT device (i.e., a peer device), the computing device should respond with a complete SDP record containing the RFCOMM channel numbers for both the low power processor and the application processor. Some multiplexer control commands related to a particular DLCI may be exchanged on the control channel (DLCI0) before the corresponding DLCI can be established. The creation of the DLCI0 channel must be handled by the main stack. The receive filter on the BT controller within the computing device should be registered between the creation of the Logical Link Control and Adaptation Layer Protocol (L2CAP) (i.e., the RFCOMM protocol service multiplexer) and the reception of BT data on RFCOMM.

[0030] Various embodiments include a method for managing RFCOMM connection handover between two different BT stacks (i.e., an application processor's BT stack and a low-power processor's BT stack) and a BT processor of a computing device equipped with BT. Various embodiments solve the aforementioned problem of handing over RFCOMM connections between concurrently operating BT stacks. For example, various embodiments include an application processor BT stack that manages asynchronous connection-oriented logical transport (ACL) connections. After configuring or otherwise establishing an ACL connection between an application processor BT stack and a paired BT device, the application processor BT stack may synchronize BT context information (e.g., BT device address, link key, connection handle) with the low-power processor BT stack. In some embodiments, the low-power processor BT stack may register the SDP database of the low-power processor BT stack with the application processor BT stack at startup and / or whenever a new RFCOMM channel is added. Therefore, the application processor BT stack may maintain or otherwise manage an SDP database containing SDP records for both the application processor and the low-power processor. A complete SDP database allows the application processor BT stack to immediately respond to SDP requests from paired BT devices without having to retrieve SDP information from the low-power processor BT stack, thereby reducing the number of processes required to respond to SDP requests. Fewer processors required to respond to SDP requests can reduce the time spent transitioning between active and low-power modes, thereby increasing the battery life of the computing device.

[0031] Figure 1 1 is a system block diagram illustrating an example communication system suitable for implementing any of the various embodiments. The communication system 100 may be a short-range communication network including multiple devices capable of wireless communication. For example, the communication system 100 may be a BT / BLE communication system including a first BT device 102 and a second BT device 106.

[0032] The first BT device 102 can be any type of computing device capable of BT / BLE communication, such as a wearable device (e.g., a smartwatch, smart glasses, a virtual reality system, and a medical device such as a heart monitor). The second BT device 106 can be any type of computing device capable of BT / BLE communication that is communicatively compatible with the first BT device 102. The first BT device 102 can be communicatively coupled to the second BT device 106 via a wireless connection 104 (which can be a BT / BLE wireless connection). For ease of illustration, the communication system 100 includes one communicatively connected or paired BT device 106. However, more paired BT devices 106 can be implemented within the communication system 100. For example, the first BT device 102 can be paired with multiple BT devices at the same time, including the second BT device 106 and additional BT devices of the same or different types capable of BT / BLE communication (e.g., a cellular phone, a laptop computer, a multimedia display, other wearable devices such as an audio output device, a point of sale system).

[0033] The wireless connection 104 may be a BT / BLE connection established via a handshake process between the first BT device 102 and the second BT device 106. The first BT device 102 may query or otherwise determine the preferred connection type (such as a codec type) of each discoverable BT device within communication range (including the second BT device 106), and may establish each wireless connection 104 based on each preferred connection type. For example, the wireless connection 104 may be established based at least on the preferred codec type implemented by the second BT device 106.

[0034] The first BT device 102 can send BT data to the second BT device 106 and receive BT data from the second BT device according to the specific protocol and connection type of the wireless connection 104. For example, the first BT device 102 can encode BT data (e.g., audio data) to be sent to the second BT device 106 via the wireless connection 104, and send the encoded BT data to the second BT device 106 via the wireless connection 104. After receiving the encoded BT data, the second BT device 106 can decode the encoded BT data for use in various BT / BLE applications or applications that can utilize BT data. Similarly, the second BT device 106 can encode BT data and send the encoded BT data to the first BT device 102 via the wireless connection 104. After receiving the encoded BT data, the first BT device 102 can decode the encoded BT data for use in various BLE applications or applications that can utilize BT data. The BT data may include data such as context information for both classic BT (i.e., BR / EDR data) and BLE operations. For example, BT data may refer to BR / EDR context information during an active mode of operation, and BT data may also refer to BLE context information during a low power mode of operation.

[0035] The first BT device 102 can operate in various BT / BLE modes as defined by the Bluetooth Core Specification v5.3. For example, the first BT device 102 can operate and perform operations in active mode (i.e., high-performance mode) or low-power mode (i.e., sleep mode, low-performance mode). The first BT device 102 may include two or more processors, which can be utilized according to the operating mode. For example, the first BT device 102 may include a low-power processor that can perform BLE functions during low-power mode and an application processor (i.e., performance processor) that can perform functions together with the low-power processor during active mode. Therefore, the first BT device 102 can save battery life by utilizing only the low-power processor when in low-power mode, and can perform BT operations by utilizing the application processor when in active mode.

[0036] Figure 2 is a component block diagram illustrating an example computing device 200 suitable for implementing any of the various embodiments. The various embodiments can be implemented on a number of single-processor and multi-processor computer systems, including system-on-chip (SoC) or system-in-package. The computing device 200 can be implemented as a wearable device or a device with BT / BLE capabilities (e.g., the first BT device 102, the second BT device 106).

[0037] refer to Figures 1 to 2The illustrated example computing device 200 (which in some embodiments may be a system-in-package) includes two SoCs 202, 204 coupled to a clock 206, a voltage regulator 208, at least one subscriber identity module (SIM) 268 and / or a SIM interface, and a wireless transceiver 266, which is configured to transmit and receive wireless communications to / from a wireless computing device such as a base station and / or a wireless device with BLE capabilities (e.g., the second BT device 106) via an antenna (not shown). In some embodiments, the first SoC 202 can operate as a central processing unit (CPU) of the computing device 200, which executes instructions of a software application by performing arithmetic, logic, control, and input / output (I / O) operations specified by the instructions of the software application. In some embodiments, the second SoC 204 can operate as a dedicated processing unit. For example, the second SoC 204 may operate as a dedicated 5G processing unit responsible for managing high-capacity, high-speed (e.g., 5 Gbps, etc.) and / or very high frequency shortwave length (e.g., 28 GHz millimeter wave spectrum, etc.) communications.

[0038] The first SoC 202 may include a digital signal processor (DSP) 210, a modem processor 212, a graphics processor 214, an application processor (AP) 216, one or more coprocessors 218 (e.g., vector coprocessors) connected to one or more of these processors, memory 220, custom circuitry 222, system components and resources 224, an interconnect / bus module 226, one or more sensors 230 (e.g., accelerometers, temperature sensors, pressure sensors, optical sensors, infrared sensors, analog sound sensors, etc.), a thermal management unit 232, and a thermal power envelope (TPE) component 234. The second SoC 204 may include a low-power processor 252, a power management unit 254, an interconnect / bus module 264, a BT / BLE controller 256, memory 258, and various additional processors 260, such as an application processor, a packet processor, etc.

[0039] Each processor 210, 212, 214, 216, 218, 252, 260 may include one or more cores, and each processor / core may operate independently of the other processors / cores. For example, the first SoC 202 may include a processor that executes a first type of operating system (e.g., FreeBSD, LINUX, OS X, etc.) and a processor that executes a second type of operating system (e.g., MICROSOFT WINDOWS 10). In addition, any or all of the processors 210, 212, 214, 216, 218, 252, 260 may be included as part of a processor cluster architecture (e.g., a synchronous processor cluster architecture, an asynchronous or heterogeneous processor cluster architecture, etc.).

[0040] The first SoC 202 and the second SoC 204 may include various system components, resources, and custom circuits for managing sensor data, analog-to-digital conversion, wireless data transmission, and for performing other specialized operations, such as decoding data packets and processing encoded audio and video signals for presentation in a web browser or audio / video application. For example, the system components and resources 224 of the first SoC 202 may include a power amplifier, a voltage regulator, an oscillator, a phase-locked loop, a peripheral bridge, a data controller, a memory controller, a system controller, an access port, a timer, and other similar components for supporting the processor and software client running on the computing device. The system components and resources 224 and / or the custom circuit 222 may also include circuits for interfacing with peripheral devices (such as cameras, electronic displays, wireless communication devices, external memory chips, etc.).

[0041] The first SoC 202 and the second SoC 204 can communicate via an interconnect module 250. In some embodiments, the interconnect module can be a connection established by components within both the SoC 202 and the SoC 204 that transceive (i.e., receive and send). In some embodiments, the interconnect module 250 may include a serial peripheral interface (SPI), which is an interface that enables serial (one bit at a time) data exchange between two devices operating in full-duplex mode. In some embodiments, the interconnect module 250 may be a bus architecture. In some embodiments, the low-power processor 252 may include a universal asynchronous receiver-transmitter (UART), and the application processor 216 may include a multi-signal message (MSM) UART driver that is communicatively connected to the UART of the low-power processor 252.

[0042] The various processors 210, 212, 214, 216, 218 may be interconnected to one or more memory elements 220, system components and resources 224, custom circuits 222, and thermal management unit 232 via interconnect / bus module 226. Similarly, the low-power processor 252 may be interconnected to the power management unit 254, BT / BLE controller 256, memory 258, and various additional processors 260 via interconnect / bus module 264. The interconnect / bus modules 226, 250, 264 may include an array of reconfigurable logic gates and / or implement a bus architecture (e.g., CoreConnect, AMBA, etc.). Communication may be provided by a high-level interconnect, such as a high-performance network on chip (NoC).

[0043] The first SoC 202 and / or the second SoC 204 may further include an input / output module (not shown) for communicating with resources external to the SoC, such as a clock 206, a voltage regulator 208, one or more wireless transceivers 266, and at least one SIM 268 and / or a SIM interface (i.e., an interface for receiving one or more SIM cards). The resources external to the SoC (e.g., the clock 206 and the voltage regulator 208) may be shared by two or more of the internal SoC processors / cores. The at least one SIM 268 (or one or more SIM cards coupled to one or more SIM interfaces) may store information supporting multiple subscriptions (including a first 5G NR subscription and a second 5G NR subscription, etc.).

[0044] In addition to the example computing device 200 discussed above, various embodiments may be implemented in a wide variety of computing systems that may include a single processor, multiple processors, multi-core processors, or any combination thereof.

[0045] In some embodiments, the various processors of SoC 202 and SoC 204 may be located within the same SoC. For example, the application processor 216 and the low-power processor 252 may be located within the same SoC, such as within a single SoC of a wearable device, to perform BT / BLE functionality in both low-power mode (i.e., utilizing the low-power processor 252) and active mode (i.e., activating and utilizing the application processor). As another example, a computing device such as a wearable device (e.g., the first BT device 102) may include the SoC 102 to perform BT / BLE functionality in both low-power mode and active mode, wherein the low-power processor 252 is utilized during low-power mode, and the application processor of the additional processor 260 is activated and utilized during active mode.

[0046] Figure 3is a component block diagram illustrating an example system 300 for managing RFCOMM connection handover between two different stacks according to some embodiments. Figures 1 to 3 , the system 300 may include one or more computing devices 302 (e.g., the first BT device 102, the computing device 200) and external resources 318, which can communicate via a wireless communication link 324 (e.g., the wireless connection 104). The external resources 318 may include information sources external to the system 300, external entities participating with the system 300, or other resources. For example, the external resource 318 may be a paired BT device, such as the second BT device 106. In some specific implementations, some or all of the functionality attributed herein to the external resources 318 may be provided by resources included in the system 300. The system 300 may include multiple hardware, software, and / or firmware components that operate together to provide the functionality attributed herein to the processor 322.

[0047] Computing device 302 may include electronic storage 320 that may be configured to store information related to the functionality implemented by send-receive module 330, asynchronous connection-oriented logical transport (ACL) session module 332, stack management module 334, SDP database module 336, RFCOMM session module 338, filtering policy module 340, and any other instruction modules.

[0048] Electronic storage 320 may include non-transitory storage media that electronically stores information. Electronic storage 320 may include one or both of system storage provided integrally with system 200 (i.e., substantially non-removable) and / or removable storage that is removably connected to system 200 via, for example, a port (e.g., a Universal Serial Bus (USB) port, a FireWire port, etc.) or a drive (e.g., a disk drive, etc.).

[0049] In various embodiments, electronic storage 320 may include one or more of charge-based storage media (e.g., EEPROM, RAM, etc.), solid-state storage media (e.g., flash drives, etc.), optically readable storage media (e.g., optical disks, etc.), magnetically readable storage media (e.g., magnetic tape, magnetic hard drives, floppy disk drives, etc.), and / or other electronically readable storage media. Electronic storage 320 may include one or more virtual storage resources (e.g., cloud storage, virtual private networks, and / or other virtual storage resources). Electronic storage 320 may store software algorithms, information determined by processor 322, and / or other information that enables system 300 to operate as described herein.

[0050] Computing device 302 may be configured by machine-readable instructions 306. Machine-readable instructions 306 may include one or more instruction modules. The instruction modules may include computer program modules. The instruction modules may include one or more of a send-receive module 330, an ACL session module 332, a stack management module 334, an SDP database module 336, an RFCOMM session module 338, a filtering policy module 340, and other instruction modules (not shown). Computing device 302 may include a processor 322 configured to implement machine-readable instructions 306 and corresponding modules.

[0051] Processor 322 may include one of a plurality of local processors that may be configured to provide information processing capabilities in system 300. Thus, processor 322 may include one or more of the following: a digital processor, an analog processor, a digital circuit designed to process information, an analog circuit designed to process information, a state machine, and / or other mechanisms for electronically processing information. Although processor 322 may be configured to provide information processing capabilities in system 300, processor 322 may include one or more of the following: a digital processor, an analog processor, a digital circuit designed to process information, an analog circuit designed to process information, a state machine, and / or other mechanisms for electronically processing information. Figure 3 3. In some embodiments, processor 322 may include multiple processing units. These processing units may be physically located within the same device, or processor 322 may represent processing functionality distributed across multiple devices in system 300.

[0052] In some embodiments, the processor 322 executing the send-receive module 330 may be configured to receive a connection request message from a BT device. In some embodiments, the processor 322 executing the send-receive module 330 may be configured to send a synchronization message including BT context information from the first BT stack to the second BT stack. In some embodiments, the processor 322 executing the send-receive module 330 may be configured to receive an SDP search request message from the BT device by the first BT stack. In some embodiments, the processor 322 executing the send-receive module 330 may be configured to send an SDP response message from the first BT stack to the BT device in response to the SDP request message. In some embodiments, the processor 322 executing the send-receive module 330 may be configured to receive an SDP database from the second BT stack by the first BT stack. In some embodiments, the processor 322 executing the send-receive module 330 may be configured to receive an SDP database from the second BT stack by the first BT stack in response to a transition from a low-power mode to an active mode of the computing device. In some embodiments, the processor 322 executing the transmit-receive module 330 may be configured to receive a Set Asynchronous Balance Mode (SABM) command from the BT device by the first BT stack. In some embodiments, the processor 322 executing the transmit-receive module 330 may be configured to send the SABM command from the first BT stack to the second BT stack. In some embodiments, the processor 322 executing the transmit-receive module 330 may be configured to send a filtering policy from the second BT stack to the BT controller of the computing device, wherein the filtering policy is based on the SABM command. In some embodiments, the processor 322 executing the transmit-receive module 330 may be configured to send a ready message from the second BT stack to the first BT stack indicating that the BT controller has been configured with the filtering policy. In some embodiments, the processor 322 executing the transmit-receive module 330 may be configured to send an Unnumbered Acknowledgement (UA) message from the first BT stack to the BT device. In some embodiments, the processor 322 executing the transmit-receive module 330 may be configured to receive an Unnumbered Information (UIH) frame with header checksum including a Parameter Negotiation (PN) command from the BT controller of the BT device. In some embodiments, the processor 322 executing the transmit-receive module 330 may be configured to send a PN command from the BT controller to the destination stack. In some embodiments, the processor 322 executing the transmit-receive module 330 may be configured to send a PN response from the destination stack to the BT device in response to the PN command. In some embodiments, the processor 322 executing the transmit-receive module 330 may be configured to send a UA message from the first BT stack to the BT device. In some embodiments, the processor 322 executing the transmit-receive module 330 may be configured to receive, by the first BT stack, a UIH frame including a PN command from the BT device.In some embodiments, the processor 322 executing the transmit-receive module 330 may be configured to send a UIH response message including a non-zero credit value from the first BT stack to the BT device in response to determining that the data link connection identifier (DLCI) channel is implemented by the application processor. In some embodiments, the processor 322 executing the transmit-receive module 330 may be configured to send a UA response message including a zero credit value from the first BT stack to the BT device in response to determining that the DLCI channel is implemented by the low-power processor. In some embodiments, the processor 322 executing the transmit-receive module 330 may be configured to receive subsequent SABM commands from the BT device from the first BT stack. In some embodiments, the processor 322 executing the transmit-receive module 330 may be configured to send subsequent SABM commands from the first BT stack to the second BT stack. In some embodiments, the processor 322 executing the transmit-receive module 330 may be configured to send a filtering policy from the second BT stack to the BT controller of the computing device, wherein the filtering policy is based on the SABM command. In some embodiments, the processor 322 executing the transmit-receive module 330 may be configured to send subsequent UA messages from the second BT stack to the BT device. In some embodiments, the processor 322 executing the transmit-receive module 330 may be configured to send a subsequent UIH message including a non-zero credit value from the second BT stack to the BT device.

[0053] In some embodiments, the processor 322 executing the ACL session module 332 may be configured to establish an ACL connection between the computing device and the BT device in response to the connection request message.

[0054] In some embodiments, the processor 322 executing the stack management module 334 may be configured to instantiate the first BT stack and the second BT stack when the computing device boots up. In some embodiments, the processor 322 executing the stack management module 334 may be configured to determine whether the DLCI channel is implemented by the application processor implementing the first BT stack or by the low-power processor implementing the second BT stack.

[0055] In some embodiments, the processor 322 executing the SDP database module 336 may be configured to store a primary SDP database for the first BT stack along with a secondary SDP database.

[0056] In some embodiments, the processor 322 executing the RFCOMM session module 338 may be configured to establish an RFCOMM session between the computing device and the BT device.

[0057] In some embodiments, the processor 322 executing the filter policy module 340 may be configured to determine, by the BT controller, a destination stack of the PN command based on the filter policy, wherein the destination stack is the first BT stack or the second BT stack.

[0058] Processor 322 may execute modules 330 - 340 and / or other modules via software, hardware, firmware, some combination of software, hardware, and / or firmware, and / or other mechanisms for configuring processing capabilities on processor 322 .

[0059] The description of the functionality provided by the different modules 330-340 is for illustrative purposes and is not intended to be limiting, as any of the modules 330-340 may provide more or less functionality than described. For example, one or more of the modules 330-340 may be eliminated, and some or all of their functionality may be provided by other modules in the modules 330-340. As another example, the processor 322 may execute one or more additional modules that may perform some or all of the functionality attributed below to one of the modules 330-340.

[0060] Figure 4 is a component block diagram illustrating an example BT / BLE system architecture 400 including a stack configuration according to some embodiments. Figures 1 to 4 , the BT / BLE system architecture 400 can be implemented on an application processor 402 (e.g., application processor 216, application processor of additional processor 260) and a low-power processor (e.g., low-power processor 252) of a BT device (e.g., first BT device 102, computing device 200, 302). The application processor 402 can be activated, or otherwise powered on or awakened, to perform BT-related operations during BT active mode. During BLE low-power mode, sleep mode, or a period of inactivity (e.g., when BT data transfer has not occurred within a configurable amount of time), the application processor 402 can be deactivated, powered off, or placed into a sleep (low-power) state, and the low-power processor 404 can perform BT / BLE-related operations.

[0061] The application processor 402 may include an active-mode AP BT stack 438 (e.g., Fluoride, BlueZ, FreeBSD, Mac OS X, Microsoft BT stack, BlueCode+, etc.) that supports the operation of LM / AM BT applications 462 that can execute in both low-power mode (LM) and AM. The application processor may further support the operation of AM BT applications 464 and proxy applications 480 that can execute in AM. The low-power processor 404 may include an LP BT stack 418 that supports the operation of LM BT applications 420 that run only during LM. The application processor 402 may include a BT service 458 and a BT framework 460 to support LM / AM BT applications 462 and AM BT applications 464, and may also include a BT Offload service 576 and a BT Offload framework 478 to support the proxy application 480. The BT framework 460 and the BT Offload framework 478 may be application code that can utilize a BT application programming interface (API) to interact with BT hardware. The BT service 458 may interface the BT framework 460 with the AP BT stack 438 , and the BT Offload service 476 may interface the BT Offload framework 478 with the AP BT stack 438 .

[0062] The low-power processor 404 may include a BT controller 406 for interfacing and communicating with one or more paired BT devices (e.g., the second BT device 106). The BT controller 406 may include communication interfaces such as an inter-process communication (IPC) module 408 and a universal asynchronous receiver-transmitter (UART) 432. The IPC module 408 may be configured to receive BT data (e.g., BT context information) from another BT device (e.g., the second BT device 106) during a LM of the BT / BLE system architecture 400. The UART 432 may be configured to receive BT data (e.g., BT context information) from another BT device (e.g., the second BT device 106) during an AM of the BT / BLE system architecture 400. The low-power BT stack 418 may include an IPC 410 for communicating BT data with the IPC module 408 of the BT controller 406 during any LM. The low-power BT stack 418 may include an IPC 410 for communicating BT data with the IPC module 408 of the BT controller 406 during a LM.

[0063] The LP BT stack 418 may include any number of known BT profiles 428 or specifications that may define how BT data is passed from one device (e.g., the first BT device 102, the system architecture 400) to another connected device (e.g., the second BT device 106). The BT profiles 428 within the LP BT stack 418 may include, but are not limited to, profiles that may be used under LM, such as Advanced Audio Distribution Profile Source (A2DP Src) 428a, Audio / Video Distribution Transport Profile (AVDTP) 428b, Audio / Video Remote Control Profile (AVRCP) 428c, Audio / Video Control Transport Profile (AVCTP) 428d, Hands-Free Profile - Hands-Free Unit (HFP-HF) 428e, and LM Service Discovery Protocol (SDP) 428f. The LP BT stack 418 may also include the LM Attribute (ATT) 426 protocol, the LM Generic ATT (GATT) 424, the LM RFCOMM (Radio Frequency Communication) 422, the LM Logical Link Control and Adaptation Layer Protocol (L2CAP) 416, and the LM Host Controller Interface (HCI) 414. The LM GATT 424 and the LM L2CAP 416 may use one of the BT profiles 428 to configure a wireless connection via the LM HCI 414. The LM RFCOMM 422 is a set of transport protocols built on top of the LM L2CAP 416 that provides an emulated RS-232 serial port. The LM GATT 424 may define how two BT devices (e.g., the first BT device 102, the second BT device 106) communicate BT data back and forth during low power mode using profiles (e.g., the BT profile 428), services, and characteristics. LM GATT 424 may utilize LM ATT 426 to store profiles, services, characteristics, and other BT context information related to the functionality and operation of LM BT application 420 during low power mode of system architecture 400. In other words, LM GATT 424 may configure how BT data is communicated across wireless connections based on LM ATT 426.

[0064] The AP BT stack 438 may include any number of known BT profiles 456 or specifications that may define how BT data is passed from one device (e.g., the first BT device 102, the system architecture 400) to another connected device (e.g., the second BT device 106). The BT profiles 456 within the AP BT stack 438 may include, but are not limited to, profiles that may be used in both LM and AM (such as A2DP Src 456b, AVDTP 456c, AVRCP 456d, AVCTP 456e, HFP-HF 456g, and AMSDP 456h) and profiles that may only be used in active mode (such as A2DP Sink 456a, Hands-Free Profile Audio Gateway (HFP-AG) 456f, Human Interface Device Profile (HID) 456h, and BT Offload Profile 456i).

[0065] The AP BT stack 438 may also include the AM ATT / Enhanced ATT (EATT) 454 protocol, AM GATT 452, AM RFCOMM 448, AM L2CAP 444, and AM HCI 442. AM GATT 452 and AM L2CAP 444 may use one of the BT profiles 456 to configure a wireless connection via the AM HCI 442. AM RFCOMM 448 is a set of transport protocols built on top of AM L2CAP 444 that provides an emulated RS-232 serial port. AM GATT 452 may define how two BT devices (e.g., the first BT device 102, the second BT device 106) communicate BT data back and forth during low power mode using profiles (e.g., BT profile 456), services, and characteristics. AM GATT 452 may utilize AM ATT / EATT 454 to store profiles, services, characteristics, and other BT context information related to the functionality and operation of LM / AM BT applications 462 and AM BT applications 464 during active power mode of system architecture 400. In other words, AM GATT 452 may configure how BT data is communicated across wireless connections based on AM ATT / EATT 454.

[0066] The application processor 402 may include one or more drivers and / or interfaces to communicate BT data with the UART 432 of the BT controller 406. For example, the application processor 402 may include a kernel space including a multi-signal message (MSM) UART driver 434 communicatively connected to the UART 432, and a teletypewriter (TTY) driver 436 communicatively connected to the MSM UART driver 434. The AP BT stack 438 may include a BT hardware abstraction layer (HAL) 440 configured to communicate BT data with the TTY driver and the AM HCI 442.

[0067] The low-power processor 404 may include middleware 470 that communicates BT data from the LP BT stack 418 to the LM BT application during LM and communicates the BT data from the LP BT stack to the LM driver 472 during active mode. The LM driver 472 may communicate the BT data to the application processor 402 via a Glink 474. The Glink 474 may be in the kernel space of the application processor 402 and may communicate the BT data to a BTOffload HAL 475 in the user space of the application processor 402. The BTOffload HAL 475 may relay the BT data to a BTOffload service 476 and / or a BT offload profile 456i.

[0068] Figures 5A to 5C are message flow diagrams 500a, 500b, and 500c illustrating various operations for managing an RFCOMM connection handover between two different BT stacks according to some embodiments. Figures 1 to 5C , the application processor 402 and the low power processor 404 are illustrated as communicating with an external BT device 501 (e.g., with a second BT device 106 via the wireless connection 104). The application processor 402 and the low power processor 404 may include a BT controller 406 that interfaces with the external BT device 501, an application processor (AP) BT stack 438 of the application processor 402, and a low power processor (LP) BT stack 418 of the low power processor 404. In some embodiments, the BT controller may be a component of the low power processor 404 and may be communicatively connected to the AP BT stack 438 and the LP BT stack 418. In some embodiments, the application processor 402 and the low power processor 404 may be located within a single computing device (such as a SoC).

[0069] refer to Figure 5A , illustrating various operations S502 - S516 for establishing an ACL session (ie, operations S502 - S508 ) and performing SDP-related operations (ie, operations S510 - S516 ).

[0070] In operation S502 , the BT controller 406 may receive an ACL connection request (REQ) message from the external BT device 501 .

[0071] In operation S504, the BT controller 406 may transmit the ACL connection request message received from the external BT device 501 to the AP BT stack 438. By default, the AP BT stack 438 may manage and maintain an ACL connection with any paired BT device.

[0072] In operation S506 , the AP BT stack 438 may initialize an ACL connection establishment with the external BT device 501 and may maintain the ACL connection until the ACL connection is terminated.

[0073] In operation S508, the AP BT stack 438 may send a synchronization message to the LP BT stack 418. In some implementations, the synchronization message may include at least one of a BT device address (eg, BD_ADDR), a link key, or a connection handle (eg, Conn Hndl).

[0074] In operation S510, the BT controller 406 may receive an SDP search request from the external BT device 501. By querying the SDP record, the external BT device 501 may determine any information needed to connect to a service via RFCOMM.

[0075] In operation S512, the BT controller 406 may transmit the SDP search request received from the external BT device to the AP BT stack 438. The AP BT stack 438 may manage all SDP search requests received from paired BT devices.

[0076] In operation S514, the AP BT stack 438 may send an SDP response (RSP) message to the BT controller 406 in response to the SDP search request message previously received in operation S512. The SDP response message may include any information required for the external BT device 501 to establish an RFCOMM session with the computing device including the application processor 402 and the low power processor 404.

[0077] In operation S516 , the BT controller 406 may transmit an SDP response message to the external BT device 501 .

[0078] After operation S516 , the external device may transmit an RFCOMM message for establishing and maintaining an RFCOMM connection to the BT controller 406 . Figure 5B and Figure 5C1 illustrates some embodiments of message flow diagrams for managing RFCOMM connections and handling RFCOMM data between the AP BT stack 438 and the LP BT stack 418. The operations of the message flow diagrams of some embodiments may be performed in Figure 5A Operation S516 is then performed.

[0079] refer to Figure 5B , illustrating various operations S518-S542 for establishing an RFCOMM connection (ie, operations S518-S532) and communicating RFCOMM data across the established RFCOMM channel (ie, operations S534-S542). Operations S518-S542 may be performed in Figure 5A Operation S516 is then performed.

[0080] In operation S518, the BT controller 406 may receive an initialization message for establishing an RFCOMM connection from the external BT device 501. The initialization message may be an L2CAP_Conn_REQ message.

[0081] In operation S520 , the BT controller 406 may send an initialization message (eg, L2CAP_Conn_Req) ​​to the AP BT stack 438 .

[0082] In operation S522 , the AP BT stack 438 may perform RFCOMM connection establishment with the external BT device 501 in response to receiving the initialization message in operation S520 .

[0083] In operation S524, the BT controller 406 may receive a Set Asynchronous Balance Mode (SABM) command from the external BT device 501. The SABM command may be received on a data link connection identifier (DLCI) channel 0 (e.g., DLCI0). SABM is a "low level" control frame. RFCOMM uses channels, each of which has a DLCI. An Unnumbered Information (UIH) frame with header check on DLCI0 (i.e., DLCI=0) may be used to transmit RFCOMM control messages (e.g., SABM commands). UIH frames on a DLCI other than DLCI0 may be used to transmit RFCOMM data.

[0084] In operation S526, the BT controller 406 may send a SABM command on DLCI0 to the AP BT stack 438. The AP BT stack 438 may read the SABM command from the DLCI0 channel or otherwise identify the SABM command from the sequence of control messages within the DLCI0 channel. The AP BT stack 438 may handle any and all additional messages received on the DLCI0 channel.

[0085] In operation 528 , the AP BT stack 438 may send a SABM command to the LP BT stack 418 .

[0086] In operation 530 , the LP BT stack 418 may prepare or otherwise generate a filtering policy based on the SABM command received from the AP BT stack 438 , and may send a command message to the BT controller 406 causing the BT controller 406 to enable the DLCI filter based on the generated filtering policy.

[0087] In operation S531 , the LP BT stack 418 may send a notification message to the AP BT stack 438 , the notification message indicating that the filtering policy created by the LP BT stack 418 has been enabled on the BT controller 406 .

[0088] In operation S532, the AP BT stack 438 may send an Unnumbered Acknowledgement (UA) message to the external BT device 501 in response to receiving the Notify message from the LP BT stack 418 in operation S531. The UA message may indicate that the BT controller 406 is ready to receive data from the external BT device 501, and the external BT device 501 may begin sending data to the BT controller 406. The UA message may be withheld until the AP BT stack 438 is notified that the filtering policy has been enabled on the BT controller 406.

[0089] In operation S534, the external BT device 501 may transmit a data frame to the BT controller 406. For example, the BT controller 406 may receive a UIH frame including one or more parameter negotiation (PN) commands from the external BT device 501.

[0090] The filtering policy implemented by the BT controller 406 can enable the BT controller 406 to relay data to the appropriate BT stack, i.e., the LP BT stack 418 or the AP BT stack 438. Based on the filtering policy, the BT controller 406 can know where the server channel is implemented (i.e., within the low-power processor 404 or the application processor 402). For example, if the server channel is being implemented on the low-power processor 404, the BT controller 406 can send a PN command to the low-power processor 404 in operation S536, and the low-power processor 404 can send a PN response to the external BT device 501 in operation S538 in response to receiving the PN command from the BT controller 406. Alternatively, if the server channel is being implemented on the application processor 402, the BT controller 406 can send a PN command to the application processor 402 in operation S540, and the application processor 402 can send a PN response to the external BT device 501 in operation S542 in response to receiving the PN command from the BT controller 406.

[0091] RFCOMM data may be continuously transported between the external BT device 501 and the LP BT stack 418 or the AP BT stack 438 based on the filter policies enabled within the BT controller 406. In some embodiments, the LP BT stack 418 may generate a new filter policy and may enable the new filter policy on the BT controller 406, overwriting any existing filter policy.

[0092] refer to Figure 5C , illustrating various operations S544-S578 for establishing an RFCOMM connection (ie, operations S5544-S566) and enabling a filter based on a SABM command (ie, operations S576-S578). Operations S544-S578 may be performed in Figure 5A Operation S516 is then performed.

[0093] Operations S544-S552 can be performed with Figure 5B For example, operations S544-S548 may be performed in a similar manner to operations S518-S522 to establish an RFCOMM connection between the AP BT stack 438 and the external BT device 501. Operations S550 and S552 may be performed in a similar manner to operations S524 and S526 to transmit a SABM command on DLCI0 from the external BT device 501 to the AP BT stack 438.

[0094] In operation S554 , the AP BT stack 438 may transmit a UA message to the external BT device 501 . The UA message may indicate that the BT controller 406 is ready to receive data from the external BT device 501 , and the external BT device 501 may start transmitting data to the BT controller 406 .

[0095] In operation S556, the external BT device 501 may transmit a data frame to the BT controller 406. For example, the BT controller 406 may receive a UIH frame including one or more PN commands from the external BT device 501.

[0096] In operation S558, the BT controller 406 may transmit the UIH frame including the PN command to the AP BT stack 438. The AP BT stack 438 may manage all UIH data frames received from the external BT device 501.

[0097] In response to the UIH frame received in operation S558, the AP BT stack 438 may send a UIH response message to the external BT device 501 via the BT controller 406. The AP BT stack 438 may know where each DLCI channel is implemented (i.e., within the low power processor 404 or the application processor 402). For example, if DLCI channel "m" is being implemented on the low power processor 404, the AP BT stack 438 may send a UIH response message including a PN command and a credit value of 0 to the BT controller 406 in operation S560, and the BT controller 406 may send a UIH including a PN command and a credit value of 0 to the external BT device 501 in operation S562. The UIH including the PN command and the credit value of 0 may indicate to the external BT device 501 that the UIH frame is a data frame from DLCI m on the low power processor 404. Alternatively, if the DLCI channel “n” is being implemented on the application processor 402, the AP BT stack 438 may transmit a UIH response message including a PN command and an “x” credit value (i.e., a non-zero credit value) to the BT controller 406 in operation S564, and the BT controller 406 may transmit a UIH including the PN command and the “x” credit value to the external BT device 501 in operation S566. The UIH including the PN command and the “x” credit value may indicate to the external BT device 501 that the UIH frame is a data frame from the DLC In on the application processor 402.

[0098] In some embodiments, a SABM command may be received for a DLCI implemented on the low power processor 404 and operations S568 - S578 may be performed.

[0099] In operation S568, the BT controller 406 may receive a SABM command from the external BT device 501. The SABM command may be received on a DLCI channel m (eg, DLCI m).

[0100] In operation S570, the BT controller 406 may send a SABM command on DLCI m to the AP BT stack 438. The AP BT stack 438 may read the SABM command from the DLCI m channel or otherwise identify the SABM command from the sequence of control messages within the DLCI m channel. The AP BT stack 438 may handle any and all additional messages received on the DLCI m channel.

[0101] In operation 572 , the AP BT stack 438 may send a SABM command to the LP BT stack 418 .

[0102] In operation 574 , the LP BT stack 418 may prepare or otherwise generate a filtering policy based on the SABM command received from the AP BT stack 438 , and may send a command message to the BT controller 406 causing the BT controller 406 to enable the DLCI filter based on the generated filtering policy.

[0103] In operation S576 , the LP BT stack 418 may send a UA message to the external BT device 501 . The UA message may indicate that the BT controller 406 is ready to receive data from the external BT device 501 , and the external BT device 501 may start sending data to the BT controller 406 .

[0104] In operation S578, the LP BT stack 418 may transmit a data frame to the external BT device 501. For example, the LP BT stack 418 may transmit a UIH frame including a given credit value (ie, a non-zero credit value) to the external BT device 501.

[0105] Figure 6A is a process flow diagram of an example method 600a for managing RFCOMM connection handover between two different stacks, according to various embodiments. Figures 6B to 6H is a process flow diagram of example operations 600b-600f that may be performed as part of the method 600a as described for managing RFCOMM connection handover between two different stacks, according to some embodiments. Figures 1 to 6H , the method 600a and operations 600b-600h may be performed by a computing device (e.g., 102, 200, 302, 400). In some embodiments, the computing device may be configured to perform the operations via processor-executable instructions stored in a non-transitory processor-readable medium (e.g., 220, 258, 320). The means for performing the operations of the method 600a and each of the operations 600b-600h may be a processor of the systems 100, 200, 300, and 400, such as those described in reference to FIG. Figures 1 to 6H Processors 252, 322, 404, etc. are described.

[0106] In block 602, the computing device may perform operations including receiving a connection request message from a BT device (e.g., 106, 501). The computing device may receive the connection request message as described in operations S502 and S504. Means for performing the operations of block 602 may include a computing device (e.g., 102, 200, 302, 400) executing the transmit-receive module 330.

[0107] In block 604, the computing device may perform operations including establishing an ACL connection between the computing device and the BT device (e.g., 106, 501) in response to the connection request message. The computing device may receive the connection request message as described in operation S506. Means for performing the operations of block 604 may include the computing device (e.g., 102, 200, 302, 400) executing the ACL session module 332.

[0108] In block 606, the computing device may perform operations including sending a synchronization message including BT context information from a first BT stack (e.g., AP BT stack 438) to a second BT stack (e.g., LP BT stack 418). The computing device may send the synchronization message as described in operation S506. In some embodiments, the BT context information may include at least one of a BT device address (BD_ADDR), a link key, or a connection handle. Means for performing the operations of block 606 may include a computing device (e.g., 102, 200, 302, 400) executing the transmit-receive module 330.

[0109] Figure 6B Illustrated are operations 600b that may be performed as part of a method 600a for managing an RFCOMM connection handover between two different stacks, according to some embodiments. Figures 1 to 6B After the operation in block 606, the computing device may perform operations including: In block 608, a first BT stack (e.g., AP BT stack 438) receives an SDP search request message from a BT device (e.g., 106, 501). The computing device may receive the SDP search request message as described in operations S510 and S512. The means for performing the operations in block 608 may include a computing device (e.g., 102, 200, 302, 400) executing the transmit-receive module 330.

[0110] In block 610, the computing device may perform operations including sending an SDP response message from the first BT stack to the BT device (e.g., 106, 501) in response to the SDP request message. The computing device may send the SDP response message as described in operations S514 and S516. Means for performing the operations of block 610 may include a computing device (e.g., 102, 200, 302, 400) executing the transmit-receive module 330.

[0111] Figure 6C Illustrated are operations 600c that may be performed as part of the method 600a for managing RFCOMM connection handover between two different stacks, in accordance with some embodiments.

[0112] In block 612, the computing device may perform operations including instantiating a first BT stack (e.g., the AP BT stack 438) and a second BT stack (e.g., the LP BT stack 418) upon startup of the computing device. Means for performing the operations of block 612 may include the computing device (e.g., 102, 200, 302, 400) executing the stack management module 334.

[0113] In block 614, the computing device may perform operations including receiving, by a first BT stack (e.g., the AP BT stack 438), an SDP database from a second BT stack (the LP BT stack 418). In some embodiments, by providing the AP BT stack 438 with the SDP database for the low-power processor 404, the AP BT stack 438 may respond to any SDP request received from the BT device with full knowledge of the SDP databases for both the application processor 402 and the low-power processor 404. Thus, depending on which processor the received SDP request identifies, the AP BT stack 438 may respond to the SDP request message using either the application processor 402 SDP information or the low-power processor SDP information. Means for performing the operations of block 614 may include a computing device (e.g., 102, 200, 302, 400) executing the transmit-receive module 330.

[0114] In block 616, the computing device may perform operations including storing a primary SDP database for the first BT stack (e.g., the AP BT stack 438) along with a secondary SDP database. Means for performing the operations of block 614 may include a computing device (e.g., 102, 200, 302, 400) executing the SDP database module 336.

[0115] After the operations in block 616 , the computing device may perform the operations in block 602 .

[0116] Figure 6D Illustrated are operations 600d that may be performed as part of the method 600a for managing an RFCOMM connection handover between two different stacks, according to some embodiments.

[0117] In block 618, the computing device may perform operations including receiving an SDP database from a second BT stack (e.g., LP BT stack 418) by a first BT stack (e.g., AP BT stack 438) in response to transitioning from a low-power mode to an active mode of the computing device. In some embodiments, by providing the AP BT stack 438 with the SDP database of the low-power processor 404, the AP BT stack 438 may respond to any SDP request received from the BT device with full knowledge of the SDP databases of both the application processor 402 and the low-power processor 404. Thus, depending on which processor the received SDP request identifies, the AP BT stack 438 may respond to the SDP request message using either the application processor 402 SDP information or the low-power processor SDP information. Means for performing the operations of block 618 may include a computing device (e.g., 102, 200, 302, 400) executing the transmit-receive module 330.

[0118] In block 620, the computing device may perform operations including storing a primary SDP database for the first BT stack (e.g., the AP BT stack 438) along with a secondary SDP database. Means for performing the operations of block 620 may include a computing device (e.g., 102, 200, 302, 400) executing the SDP database module 336.

[0119] After the operations in block 620 , the computing device may perform the operations in block 602 .

[0120] Figure 6E Illustrated are operations 600e that may be performed as part of a method 600a for managing an RFCOMM connection handover between two different stacks, according to some embodiments. Figures 1 to 6E After the operation in block 606, the computing device may perform operations including establishing an RFCOMM session between the computing device and the BT device (e.g., 106, 501) in block 622. The computing device may establish the RFCOMM session as described in operations S518-S522. The means for performing the operations of block 622 may include a computing device (e.g., 102, 200, 302, 400) executing the RFCOMM session module 338.

[0121] In block 624, the computing device may perform operations including receiving, by a first BT stack (e.g., AP BT stack 438), a SABM command from a BT device (e.g., 106, 501). The computing device may receive the SABM command as described in operations S524 and S526. Means for performing the operations of block 624 may include a computing device (e.g., 102, 200, 302, 400) executing the transmit-receive module 330.

[0122] In block 626, the computing device may perform operations including sending a SABM command from the first BT stack (e.g., the AP BT stack 438) to the second BT stack (e.g., the LP BT stack 418). The computing device may send the SABM command as described in operation S528. Means for performing the operations of block 626 may include a computing device (e.g., 102, 200, 302, 400) executing the transmit-receive module 330.

[0123] In block 628, the computing device may perform operations including sending a filter policy from a second BT stack (e.g., LP BT stack 418) to the BT controller 406 of the computing device, wherein the filter policy is based on a SABM command. The computing device may send the filter policy as described in operation S530. Means for performing the operations of block 628 may include a computing device (e.g., 102, 200, 302, 400) executing the filter policy module 340 and the send-receive module 330.

[0124] In block 630, the computing device may perform operations including sending a ready message from the second BT stack (e.g., LP BT stack 418) to the first BT stack (AP BT stack 438) indicating that the BT controller 406 has been configured with a filtering policy. The filtering policy may allow the BT controller 406 to route the UIH message including the PN to the appropriate BT stack. The computing device may send the ready message as described in operation S531. Means for performing the operations of block 630 may include a computing device (e.g., 102, 200, 302, 400) executing the transmit-receive module 330.

[0125] In block 632, the computing device may perform operations including sending a UA message from a first BT stack (e.g., AP BT stack 438) to a BT device (e.g., 106, 501). The computing device may send the UA as described in operation S532. Means for performing the operations of block 632 may include a computing device (e.g., 102, 200, 302, 400) executing the transmit-receive module 330.

[0126] Figure 6F Illustrated are operations 600f that may be performed as part of the method 600a for managing RFCOMM connection handover between two different stacks in accordance with some embodiments. Figures 1 to 6FAfter the operation in block 632, the computing device may perform operations including receiving a UIH frame including a PN command from a BT device (e.g., 106, 501) by the BT controller 406 in block 634. The computing device may receive the UIH frame as described in operation S534. Means for performing the operation in block 634 may include a computing device (e.g., 102, 200, 302, 400) executing the transmit-receive module 330.

[0127] In block 636, the computing device may perform operations including determining, by the BT controller 106, a destination stack for the PN command based on the filter policy, where the destination stack is the first BT stack (e.g., the AP BT stack 438) or the second BT stack (e.g., the LPBT stack 418). Means for performing the operations of block 636 may include a computing device (e.g., 102, 200, 302, 400) executing the filter policy module 340.

[0128] In block 638, the computing device may perform operations including sending a PN command from the BT controller 106 to the destination stack (i.e., the AP BT stack 438 or the LP BT stack 418). The computing device may send the PN command as described in operations S536 or S540. Means for performing the operations of block 638 may include a computing device (e.g., 102, 200, 302, 400) executing the transmit-receive module 330.

[0129] In block 640, the computing device may perform operations including sending a PN response from the destination stack (e.g., AP BT stack 438 or LP BT stack 418) to the BT device (e.g., 106, 501) in response to the PN command. The computing device may send the PN as described in operations S538 or 542. Means for performing the operations of block 640 may include a computing device (e.g., 102, 200, 302, 400) executing the filter policy module 340 and the transmit-receive module 330.

[0130] Figure 6G Illustrated are operations 600g that may be performed as part of the method 600a for managing RFCOMM connection handover between two different stacks in accordance with some embodiments. Figures 1 to 6G After the operation in block 606, the computing device may perform operations including establishing an RFCOMM session between the computing device and the BT device (e.g., 106, 501) in block 642. The computing device may establish the RFCOMM session as described in operations S544-S548. The means for performing the operations of block 642 may include a computing device (e.g., 102, 200, 302, 400) executing the RFCOMM session module 338.

[0131] In block 644, the computing device may perform operations including receiving, by a first BT stack (e.g., AP BT stack 438), a SABM command from a BT device (e.g., 106, 501). The computing device may receive the SABM command as described in operations S550 and S552. Means for performing the operations of block 644 may include a computing device (e.g., 102, 200, 302, 400) executing the transmit-receive module 330.

[0132] In block 646, the computing device may perform operations including sending a UA message from the first BT stack (e.g., AP BT stack 438) to the BT device (e.g., 106, 501). The computing device may send the UA message as described in operation S554. Means for performing the operations of block 646 may include a computing device (e.g., 102, 200, 302, 400) executing the transmit-receive module 330.

[0133] In block 648, the computing device may perform operations including receiving, by a first BT stack (e.g., AP BT stack 438), a UIH frame including a PN command from a BT device (e.g., 106, 501). The computing device may receive the UIH frame as described in operations S556 and S558. Means for performing the operations of block 648 may include a computing device (e.g., 102, 200, 302, 400) executing the transmit-receive module 330.

[0134] In block 650, the computing device may perform operations including determining whether the DLCI channel is implemented by the application processor 402 implementing the first BT stack (e.g., the AP BT stack 438) or by the low power processor 404 implementing the second BT stack (e.g., the LP BT stack 418). Means for performing the operations of block 650 may include the computing device (e.g., 102, 200, 302, 400) executing the stack management module 334.

[0135] In block 652, the computing device may perform operations including:

[0136] The computing device may transmit the UIH response message as described in operation S531. Means for performing block 652 operations may include a computing device (e.g., 102, 200, 302, 400) executing a transmit-receive module 330.

[0137] Figure 6H 6 illustrates operations 600h that may be performed as part of a method 600a for managing an RFCOMM connection handover between two different stacks, according to some embodiments. Figures 1 to 6H After the operations in block 652, the computing device may perform operations including receiving a subsequent SABM command from the BT device (e.g., 106, 501) by the first BT stack (e.g., AP BT stack 438) in block 654. The computing device may receive the subsequent SABM command as described in operations S568 and S570. Means for performing the operations in block 652 may include a computing device (e.g., 102, 200, 302, 400) executing the transmit-receive module 330.

[0138] In block 656, the computing device may perform operations including sending a subsequent SABM command from the first BT stack (e.g., AP BT stack 438) to the second BT stack (e.g., LP BT stack 418). The computing device may send the subsequent SABM command as described in operation S572. Means for performing the operations of block 656 may include a computing device (e.g., 102, 200, 302, 400) executing the filter policy module 340.

[0139] In block 658, the computing device may perform operations including sending a filter policy from the second BT stack (e.g., LP BT stack 418) to the BT controller 406 of the computing device, wherein the filter policy is based on the subsequent SABM command. The computing device may send a PN command as described in operation S574. Means for performing the operations of block 658 may include a computing device (e.g., 102, 200, 302, 400) executing the filter policy module 340 and the transmit-receive module 330.

[0140] In block 660, the computing device may perform operations including sending a subsequent UA message from the second BT stack (e.g., LP BT stack 418) to the BT device (e.g., 106, 501). The computing device may send the subsequent UA message as described in operation S576. Means for performing the operations of block 660 may include a computing device (e.g., 102, 200, 302, 400) executing the transmit-receive module 330.

[0141] In block 662, the computing device may perform operations including sending a subsequent UIH message including a non-zero credit value from the second BT stack (e.g., LP BT stack 418) to the BT device (e.g., 106, 501). The computing device may send the subsequent UIH message as described in operation S578. Means for performing the operations of block 662 may include a computing device (e.g., 102, 200, 302, 400) executing the transmit-receive module 330.

[0142] Various embodiments (including but not limited to the above reference Figure 1 5E) can be implemented in a variety of computing systems including a laptop computer 700, an example of which is shown in FIG. Figure 7 Example in. refer to Figures 1 to 7 , the laptop computer may include a touchpad touch surface 717 that serves as a pointing device for the computer and, therefore, can receive drag, scroll, and tap gestures similar to those implemented on computing devices equipped with touch screen displays and as described above. The laptop computer 700 will typically include a processor 702 coupled to a volatile memory 712 and a disk drive 713 for large-capacity non-volatile memory, such as flash memory. In addition, the computer 700 may have one or more antennas 708 for transmitting and receiving electromagnetic radiation, which may be connected to a wireless data link, and / or a cellular telephone transceiver 716 coupled to the processor 702. The computer 700 may also include a BT transceiver 714 and a compact disk (CD) drive 715 coupled to the processor 702. The laptop computer 700 may include a touchpad 717, a keyboard 718, and a display 719, all coupled to the processor 702. Other configurations of computing devices may include a computer mouse or trackball coupled to the processor (e.g., via a USB input), as is well known, which may also be used in conjunction with various embodiments.

[0143] Figure 8 is a component block diagram of a computing device 800 suitable for use with various embodiments. Figures 1 to 8 , various embodiments may be implemented on a variety of computing devices 800 (e.g., 102, 200, 302, 400), examples of which are Figure 88 is illustrated in the form of a smartphone. The computing device 800 may include a first SoC 202 (e.g., a SoC-CPU) coupled to a second SoC 204 (e.g., a 5G-capable SoC). The first SoC 202 and the second SoC 204 may be coupled to an internal memory 816, a display 812, and a speaker 814. The first SoC 202 and the second SoC 204 may also be coupled to at least one SIM 268 and / or a SIM interface, which may store information supporting a first 5G NR subscription and a second 5G NR subscription, the first 5G NR subscription and the second 5G NR subscription supporting services on a 5G non-standalone (NSA) network.

[0144] The computing device 800 may include an antenna 804 for transmitting and receiving electromagnetic radiation, which may be connected to a wireless transceiver 266 coupled to one or more processors in the first SoC 202 and / or the second SoC 204. The computing device 800 may also include a menu selection button or rocker switch 820 for receiving user input.

[0145] The computing device 800 also includes a sound coding / decoding (CODEC) circuit 810 that digitizes the sound received from the microphone into data packets suitable for wireless transmission and decodes the received sound data packets to generate analog signals that are provided to the speakers to generate sound. In addition, one or more of the processors in the first SoC 202 and the second SoC 204, the wireless transceiver 266, and the CODEC 810 may include a digital signal processor (DSP) circuit (not separately shown).

[0146] Various embodiments may be implemented within various computing devices, such as wearable computing devices. Figure 9 An example wearable computing device in the form of a smartwatch 900 is illustrated in accordance with some embodiments. Figures 1 to 9 , the smart watch 900 may include a SoC 902 that includes two or more processors (e.g., application processors, low-power processors) coupled to internal memories 904 and 906. The internal memories 904, 906 may be volatile memories or non-volatile memories, and may also be secure and / or encrypted memories, or non-secure and / or non-encrypted memories, or any combination thereof. The SoC 902 may also be coupled to a touch screen display 920, such as a resistive sensing touch screen, a capacitive sensing touch screen, an infrared sensing touch screen, etc. In addition, the smart watch 900 may have one or more antennas 908 for transmitting and receiving electromagnetic radiation, which may be connected to one or more wireless data links 912, such as one or more antennas that may be coupled to the SoC 902. transceiver, peanut transceiver, Wi-Fi transceiver, ANT+ transceiver, etc. The smart watch 900 may also include physical virtual buttons 922 and 910 for receiving user input and a slide sensor 916 for receiving user input.

[0147] The touch screen display 920 may be coupled to a touch screen interface module that is configured to receive a signal from the touch screen display 920 indicating the location on the screen where a user's fingertip or stylus is touching the surface, and output information regarding the coordinates of the touch event to the SoC 902. Furthermore, the SoC 902 may be configured with processor-executable instructions to correlate an image presented on the touch screen display 920 with the location of the touch event received from the touch screen interface module in order to detect when a user has interacted with a graphical interface icon (such as a virtual button).

[0148] SoC 902 can be any programmable microprocessor, microcomputer or one or more multi-processor chips that can be configured to perform a variety of functions including the functions of various embodiments by software instructions (applications). In some devices, multiple processors can be provided, such as one processor dedicated to wireless communication functions and one processor dedicated to running other applications. Typically, software applications can be stored in internal memory, which is then accessed and loaded into SoC 902. SoC 902 may include internal memory sufficient to store application software instructions. In many devices, internal memory can be volatile or non-volatile memory (e.g., flash memory) or a mixture of the two. For the purposes of this description, a general reference to memory refers to memory accessible by SoC 902, including internal memory or removable memory inserted into a mobile device and memory within SoC 902 itself.

[0149] The processors of the computer 700, computing device 800, and smartwatch 900 may be any programmable microprocessor, microcomputer, or one or more multi-processor chips that can be configured by software instructions (applications) to perform a variety of functions, including the functions of the various embodiments described. In some mobile devices, multiple processors may be provided, such as one processor within the SoC 204 dedicated to wireless communication functions and one processor within the SoC 202 dedicated to running other applications. Software applications may be stored in the memory 220, 258, 320, 816, which are then accessed and loaded into the processor. The processor may include internal memory sufficient to store application software instructions.

[0150] Specific implementation examples are described in the following paragraphs. Although some of the following specific implementation examples are described in terms of example methods, further example implementations may include: the example methods discussed in the following paragraphs implemented by a computing device including a processor configured with processor-executable instructions for performing the operations of the methods of the following specific implementation examples; the example methods discussed in the following paragraphs implemented by a computing device including components for performing the functions of the methods of the following specific implementation examples; and the example methods discussed in the following paragraphs may be implemented on a non-transitory processor-readable storage medium having processor-executable instructions stored thereon, the processor-executable instructions being configured to cause the processor of the computing device to perform the operations of the methods of the following specific implementation examples.

[0151] Embodiment 1. A method for managing radio frequency communication (RFCOMM) connection handover between a first Bluetooth (BT) stack and a second BT stack, performed by a computing device, the method comprising: receiving a connection request message from a BT device; establishing an asynchronous connection-oriented logical transport (ACL) connection between the computing device and the BT device in response to the connection request message; and sending a synchronization message including BT context information from the first BT stack to the second BT stack.

[0152] Embodiment 2. The method of method 1, wherein the BT context information comprises at least one of a BT device address (BD_ADDR), a link key, or a connection handle.

[0153] Example 3. According to any one of Method 1 or Method 2, the method further includes: receiving a Service Discovery Protocol (SDP) search request message from the BT device by the first BT stack; and sending an SDP response message from the first BT stack to the BT device in response to the SDP request message.

[0154] Example 4. According to any one of methods 1 to 3, the method further includes: instantiating the first BT stack and the second BT stack when the computing device is started; receiving a secondary service discovery protocol (SDP) database from the second BT stack by the first BT stack; and storing the main SDP database of the first BT stack together with the secondary SDP database.

[0155] Example 5. A method according to any one of methods 1 to 4, the method further comprising: receiving a secondary service discovery protocol (SDP) database from the second BT stack by the first BT stack in response to a transition from a low power mode to an active mode of the computing device; and storing a primary SDP database of the first BT stack together with the secondary SDP database.

[0156] Example 6. The method according to any one of methods 1 to 5, further comprising: establishing an RFCOMM session between the computing device and the BT device; receiving a set asynchronous balancing mode (SABM) command from the BT device by the first BT stack; sending the SABM command from the first BT stack to the second BT stack; sending a filtering policy from the second BT stack to the BT controller of the computing device, wherein the filtering policy is based on the SABM command; sending a ready message from the second BT stack to the first BT stack indicating that the BT controller has been configured with the filtering policy; and sending an unnumbered acknowledgment (UA) message from the first BT stack to the BT device.

[0157] Example 7. The method according to method 6 further includes: receiving, by the BT controller, an unnumbered information (UIH) frame with header check including a parameter negotiation (PN) command from the BT device; determining, by the BT controller, a destination stack for the PN command based on the filtering policy, wherein the destination stack is the first BT stack or the second BT stack; sending the PN command from the BT controller to the destination stack; and sending a PN response from the destination stack to the BT device in response to the PN command.

[0158] Example 8. The method according to method 1 further includes: establishing an RFCOMM session between the computing device and the BT device; receiving a set asynchronous balanced mode (SABM) command from the BT device by the first BT stack; sending an unnumbered acknowledgment (UA) message from the first BT stack to the BT device; receiving an unnumbered information (UIH) frame with header check including a parameter negotiation (PN) command from the BT device by the first BT stack; determining whether a data link connection identifier (DLCI) channel is implemented by an application processor that implements the first BT stack or by a low-power processor that implements the second BT stack; and implementing one of the following: sending a UIH response message including a non-zero credit value from the first BT stack to the BT device in response to determining that the DLCI channel is implemented by the application processor; or sending a UA response message including a zero credit value from the first BT stack to the BT device in response to determining that the DLCI channel is implemented by the low-power processor.

[0159] Example 9. The method according to method 8 further includes: receiving a subsequent SABM command from the BT device by the first BT stack; sending the subsequent SABM command from the first BT stack to the second BT stack; sending a filtering policy from the second BT stack to the BT controller of the computing device, wherein the filtering policy is based on the subsequent SABM command; sending a subsequent UA message from the second BT stack to the BT device; and sending a subsequent UIH message including a non-zero credit value from the second BT stack to the BT device.

[0160] As used in this application, the terms "component", "module", "system", etc. are intended to include computer-related entities, such as but not limited to hardware, firmware, a combination of hardware and software, software or software being executed, which are configured to perform specific operations or functions. For example, a component can be but not limited to a process, processor, object, executable file, execution thread, program and / or computer running on a processor. By way of example, both an application running on a computing device and a computing device can be referred to as a component. One or more components may reside within a process and / or execution thread, and a component may be located on a processor or core and / or distributed between two or more processors or cores. In addition, these components can be executed from various non-transient computer-readable media having various instructions and / or data structures stored thereon. Components can communicate via local and / or remote processes, function or procedure calls, electronic signals, data packets, memory read / write and other known network, computer, processor and / or process-related communication methods.

[0161] Many different cellular and mobile communication services and standards will be available or under consideration in the future, all of which can be implemented and benefit from various implementation schemes. Such services and standards include, for example, the Third Generation Partnership Project (3GPP), Long Term Evolution (LTE) systems, third generation wireless mobile communication technology (3G), fourth generation wireless mobile communication technology (4G), fifth generation wireless mobile communication technology (5G) and subsequent generations of 3GPP technologies, Global System for Mobile Communications (GSM), Universal Mobile Telecommunications System (UMTS), 3GSM, General Packet Radio Service (GPRS), Code Division Multiple Access (CDMA) systems (e.g., cdmaOne, CDMA1020™), Enhanced Data Rates for GSM Evolution (EDGE), Advanced Mobile Phone System (AMPS), Digital AMPS (IS-136 / TDMA), Evolution-Data Optimized (EV-DO), Digital Enhanced Cordless Telecommunications (DECT), Worldwide Interoperability for Microwave Access (WiMAX), Wireless Local Area Networks (WLAN), Wi-Fi Protected Access I and II (WPA, WPA2), and Integrated Digital Enhanced Network (iDEN). Each of these technologies involves, for example, the transmission and reception of voice, data, signaling, and / or content messages. It should be understood that any reference to terminology and / or technical details related to individual telecommunication standards or technologies is for illustrative purposes only and is not intended to limit the scope of the claims to a particular communication system or technology unless specifically recited in the claim language.

[0162] The various embodiments illustrated and described are provided merely as examples illustrating various features of the claims. However, the features shown and described with respect to any given embodiment are not necessarily limited to that associated embodiment and may be used or combined with other embodiments shown and described. Furthermore, the claims are not intended to be limited to any one exemplary embodiment. For example, one or more operations of a method may be substituted for or combined with one or more operations of a method.

[0163] The foregoing method descriptions and process flow diagrams are provided as illustrative examples only and are not intended to require or imply that the operations of the various embodiments must be performed in the order given. As will be appreciated by those skilled in the art, the order of operations in the foregoing embodiments may be performed in any order. Words such as "thereafter," "then," "next," etc. are not intended to limit the order of operations; these words are merely used to guide the reader in reading the description of the method. In addition, any reference to a claim element in the singular (e.g., a reference using the article "a," "an," or "the") should not be construed as limiting the element to the singular.

[0164] The various illustrative logical blocks, modules, circuits, and algorithmic operations described in conjunction with the embodiments disclosed herein may be implemented as electronic hardware, computer software, or a combination of both. To clearly illustrate this interchangeability of hardware and software, various illustrative components, blocks, modules, circuits, and operations have been generally described above in terms of their functionality. Whether such functionality is implemented as hardware or software depends on the specific application and the design constraints imposed on the overall system. Although a skilled person may implement the described functionality in different ways for each specific application, such specific implementation decisions should not be interpreted as causing a departure from the scope of the claims.

[0165] The hardware for implementing the various exemplary logics, logic blocks, modules, and circuits described in conjunction with the embodiments disclosed herein can be implemented or executed with a general-purpose processor, digital signal processor (DSP), application-specific integrated circuit (ASIC), field programmable gate array (FPGA) or other programmable logic device, discrete gate or transistor logic component, discrete hardware component, or any combination thereof designed to perform the functions described herein. Although a general-purpose processor can be a microprocessor, in an alternative, the processor can be any conventional processor, controller, microcontroller, or state machine. The processor can also be implemented as a combination of computing devices, such as a combination of a DSP and a microprocessor, multiple microprocessors, one or more microprocessors combined with a DSP core, or any other such configuration. Alternatively, some operations or methods can be performed by circuits specific to a given function.

[0166] In one or more embodiments, the functions described can be implemented in hardware, software, firmware, or any combination thereof. If implemented in software, these functions can be stored as one or more instructions or codes on a non-transient computer-readable medium or a non-transient processor-readable medium. The operation of the method or algorithm disclosed herein can be specifically embodied in a processor-executable software module, which can reside on a non-transient computer-readable or processor-readable storage medium. A non-transient computer-readable or processor-readable storage medium can be any storage medium that can be accessed by a computer or processor. By way of example and not limitation, such non-transient computer-readable or processor-readable media can include RAM, ROM, EEPROM, flash memory, CD-ROM or other optical disk storage, disk storage or other magnetic storage devices, or any other medium that can be used to store desired program codes in the form of instructions or data structures and that can be accessed by a computer. Disks and optical disks as used herein include compact discs (CDs), laser discs, optical discs, digital versatile discs (DVDs), floppy disks, and Blu-ray discs, wherein disks typically reproduce data magnetically, while optical discs reproduce data optically with lasers. The above combinations are also included within the scope of non-transient computer-readable and processor-readable media. Additionally, the operations of a method or algorithm may reside as one or any combination or set of codes and / or instructions on a non-transitory processor-readable medium and / or computer-readable medium, which may be incorporated into a computer program product.

[0167] The above description of the disclosed embodiments is provided to enable any person skilled in the art to make or use the claims. Various modifications to these embodiments will be apparent to those skilled in the art, and the general principles defined herein may be applied to other embodiments without departing from the scope of the claims. Thus, the present disclosure is not intended to be limited to the embodiments shown herein, but should be accorded the broadest scope consistent with the following claims and the principles and novel features disclosed herein.

Claims

1. A method, performed by a computing device, for managing a radio frequency communication (RFCOMM) connection handover between a first Bluetooth (BT) stack and a second BT stack, the method comprising: Receive a connection request message from a BT device; establishing an asynchronous connection-oriented logical transport (ACL) connection between the computing device and the BT device in response to the connection request message; and A synchronization message including BT context information is sent from the first BT stack to the second BT stack. 2 . The method of claim 1 , wherein the BT context information comprises at least one of a BT device address (BD_ADDR), a link key, or a connection handle.

3. The method according to claim 1, further comprising: Receiving, by the first BT stack, a service discovery protocol (SDP) search request message from the BT device; as well as An SDP response message is sent from the first BT stack to the BT device in response to the SDP request message.

4. The method according to claim 1, further comprising: instantiating the first BT stack and the second BT stack when the computing device is started; Receiving, by the first BT stack, a secondary service discovery protocol (SDP) database from the second BT stack; as well as A primary SDP database of the first BT stack is stored together with the secondary SDP database.

5. The method according to claim 1, further comprising: receiving, by the first BT stack from the second BT stack, a secondary service discovery protocol (SDP) database in response to transitioning from a low power mode to an active mode of the computing device; as well as A primary SDP database of the first BT stack is stored together with the secondary SDP database.

6. The method according to claim 1, further comprising: Establishing an RFCOMM session between the computing device and the BT device; Receiving, by the first BT stack, a Set Asynchronous Balanced Mode (SABM) command from the BT device; Sending the SABM command from the first BT stack to the second BT stack; sending a filtering policy from the second BT stack to a BT controller of the computing device, wherein the filtering policy is based on the SABM command; sending, from the second BT stack to the first BT stack, a ready message indicating that the BT controller has been configured with the filtering policy; as well as An Unnumbered Acknowledgement (UA) message is sent from the first BT stack to the BT device.

7. The method according to claim 6, further comprising: receiving, by the BT controller from the BT device, an Unnumbered Information (UIH) frame with header inspection including a Parameter Negotiation (PN) command; determining, by the BT controller, a destination stack of the PN command based on the filtering policy, wherein the destination stack is the first BT stack or the second BT stack; sending the PN command from the BT controller to the destination stack; as well as A PN response is sent from the destination stack to the BT device in response to the PN command.

8. The method according to claim 1, further comprising: Establishing an RFCOMM session between the computing device and the BT device; Receiving, by the first BT stack, a Set Asynchronous Balanced Mode (SABM) command from the BT device; sending an Unnumbered Acknowledgement (UA) message from the first BT stack to the BT device; receiving, by the first BT stack from the BT device, an Unnumbered Information with Header Check (UIH) frame including a Parameter Negotiation (PN) command; determining whether a data link connection identifier (DLCI) channel is implemented by an application processor implementing the first BT stack or a low power processor implementing the second BT stack; and Implement one of the following: In response to determining that the DLCI channel is implemented by the application processor, sending a UIH response message including a non-zero credit value from the first BT stack to the BT device; or A UA response message including a zero credit value is sent from the first BT stack to the BT device in response to determining that the DLCI channel is implemented by the low power processor.

9. The method according to claim 8, further comprising: Receiving, by the first BT stack, a subsequent SABM command from the BT device; sending the subsequent SABM command from the first BT stack to the second BT stack; sending a filtering policy from the second BT stack to a BT controller of the computing device, wherein the filtering policy is based on the subsequent SABM command; sending a subsequent UA message from the second BT stack to the BT device; as well as A subsequent UIH message including a non-zero credit value is sent from the second BT stack to the BT device.

10. A computing device, comprising: Bluetooth (BT) devices; an application processor coupled to the BT device and comprising a first Bluetooth (BT) stack; and a low-power processor coupled to the BT device and the application processor and comprising a second BT stack, The computing device is configured to: receiving a connection request message from the BT device; establishing an asynchronous connection-oriented logical transport (ACL) connection between the computing device and the BT device in response to the connection request message; and As part of a radio frequency communication (RFCOMM) connection handover between the first Bluetooth (BT) stack and the second BT stack, a synchronization message including BT context information is sent from the first BT stack to the second BT stack. 11 . The computing device of claim 10 , wherein the BT context information comprises at least one of a BT device address (BD_ADDR), a link key, or a connection handle.

12. The computing device of claim 10, wherein the computing device is further configured to: receiving, by the first BT stack, a Service Discovery Protocol (SDP) search request message from the BT device; and An SDP response message is sent from the first BT stack to the BT device in response to the SDP request message.

13. The computing device of claim 10, wherein the computing device is further configured to: instantiating the first BT stack and the second BT stack when the computing device is started; Receiving, by the first BT stack, a secondary service discovery protocol (SDP) database from the second BT stack; and A primary SDP database of the first BT stack is stored together with the secondary SDP database.

14. The computing device of claim 10, wherein the computing device is further configured to: receiving, by the first BT stack from the second BT stack, a secondary service discovery protocol (SDP) database in response to transitioning from a low power mode to an active mode of the computing device; and A primary SDP database of the first BT stack is stored together with the secondary SDP database.

15. The computing device of claim 10, wherein the computing device is further configured to: Establishing an RFCOMM session between the computing device and the BT device; Receiving, by the first BT stack, a Set Asynchronous Balanced Mode (SABM) command from the BT device; Sending the SABM command from the first BT stack to the second BT stack; sending a filtering policy from the second BT stack to a BT controller of the computing device, wherein the filtering policy is based on the SABM command; sending, from the second BT stack to the first BT stack, a ready message indicating that the BT controller has been configured with the filtering policy; as well as An Unnumbered Acknowledgement (UA) message is sent from the first BT stack to the BT device.

16. The computing device of claim 15, wherein the computing device is further configured to: receiving, by the BT controller from the BT device, an Unnumbered Information (UIH) frame with header inspection including a Parameter Negotiation (PN) command; determining, by the BT controller, a destination stack of the PN command based on the filtering policy, wherein the destination stack is the first BT stack or the second BT stack; Sending the PN command from the BT controller to the destination stack; and A PN response is sent from the destination stack to the BT device in response to the PN command.

17. The computing device of claim 10, wherein the computing device is further configured to: Establishing an RFCOMM session between the computing device and the BT device; Receiving, by the first BT stack, a Set Asynchronous Balanced Mode (SABM) command from the BT device; sending an Unnumbered Acknowledgement (UA) message from the first BT stack to the BT device; receiving, by the first BT stack from the BT device, an Unnumbered Information with Header Check (UIH) frame including a Parameter Negotiation (PN) command; determining whether a data link connection identifier (DLCI) channel is implemented by the application processor implementing the first BT stack or by the low power processor implementing the second BT stack; and Any of the following: In response to determining that the DLCI channel is implemented by the application processor, sending a UIH response message including a non-zero credit value from the first BT stack to the BT device; or A UA response message including a zero credit value is sent from the first BT stack to the BT device in response to determining that the DLCI channel is implemented by the low power processor.

18. The computing device of claim 17, wherein the computing device is further configured to: Receiving, by the first BT stack, a subsequent SABM command from the BT device; sending the subsequent SABM command from the first BT stack to the second BT stack; sending a filtering policy from the second BT stack to a BT controller of the computing device, wherein the filtering policy is based on the subsequent SABM command; sending a subsequent UA message from the second BT stack to the BT device; as well as A subsequent UIH message including a non-zero credit value is sent from the second BT stack to the BT device.

19. A computing device, comprising: Bluetooth (BT) devices; an application processor coupled to the BT device and comprising a first Bluetooth (BT) stack; a low-power processor coupled to the BT device and the application processor and comprising a second BT stack; A component for receiving a connection request message from the BT device; means for establishing an asynchronous connection-oriented logical transport (ACL) connection between the computing device and the BT device in response to the connection request message; and Means for sending a synchronization message including BT context information from the first Bluetooth (BT) stack to the second BT stack as part of a Radio Frequency Communication (RFCOMM) connection handover between the first BT stack and the second BT stack.

20. The computing device of claim 19, wherein the BT context information comprises at least one of a BT device address (BD_ADDR), a link key, or a connection handle.

21. The computing device of claim 19, further comprising: means for receiving, by the first BT stack, a Service Discovery Protocol (SDP) search request message from the BT device; and Means for sending an SDP response message from the first BT stack to the BT device in response to the SDP request message.

22. The computing device of claim 19, further comprising: means for instantiating the first BT stack and the second BT stack when the computing device boots up; means for receiving, by the first BT stack, a secondary service discovery protocol (SDP) database from the second BT stack; and Means for storing a primary SDP database of said first BT stack along with said secondary SDP database.

23. The computing device of claim 19, further comprising: means for receiving, by the first BT stack, a secondary service discovery protocol (SDP) database from the second BT stack in response to transitioning from a low power mode to an active mode of the computing device; and Means for storing a primary SDP database of said first BT stack along with said secondary SDP database.

24. The computing device of claim 19, further comprising: means for establishing an RFCOMM session between the computing device and the BT device; means for receiving, by the first BT stack, a Set Asynchronous Balanced Mode (SABM) command from the BT device; means for sending the SABM command from the first BT stack to the second BT stack; means for sending a filter policy from the second BT stack to a BT controller of the computing device, wherein the filter policy is based on the SABM command; means for sending, from the second BT stack to the first BT stack, a ready message indicating that the BT controller has been configured with the filtering policy; and Means for sending an Unnumbered Acknowledgement (UA) message from the first BT stack to the BT device.

25. The computing device of claim 24, further comprising: means for receiving, by the BT controller from the BT device, an Unnumbered Information (UIH) frame with header inspection including a Parameter Negotiation (PN) command; means for determining, by the BT controller, a destination stack of the PN command based on the filter policy, wherein the destination stack is the first BT stack or the second BT stack; means for sending the PN command from the BT controller to the destination stack; and Means for sending a PN response from the destination stack to the BT device in response to the PN command.

26. The computing device of claim 19, further comprising: means for establishing an RFCOMM session between the computing device and the BT device; means for receiving, by the first BT stack, a Set Asynchronous Balanced Mode (SABM) command from the BT device; means for sending an Unnumbered Acknowledgement (UA) message from the first BT stack to the BT device; means for receiving, by the first BT stack from the BT device, an Unnumbered Information (UIH) frame with header inspection including a Parameter Negotiation (PN) command; means for determining whether a data link connection identifier (DLCI) channel is implemented by the application processor implementing the first BT stack or by the low power processor implementing the second BT stack; and One of the following: means for sending, from the first BT stack to the BT device, a UIH response message including a non-zero credit value in response to determining that the DLCI channel is implemented by the application processor; or Means for sending, from the first BT stack to the BT device, a UA response message including a zero credit value in response to determining that the DLCI channel is implemented by the low power processor.

27. The computing device of claim 26, further comprising: means for receiving, by the first BT stack, a subsequent SABM command from the BT device; means for sending the subsequent SABM command from the first BT stack to the second BT stack; means for sending a filter policy from the second BT stack to a BT controller of the computing device, wherein the filter policy is based on the subsequent SABM command; means for sending a subsequent UA message from the second BT stack to the BT device; and Means for sending, from the second BT stack to the BT device, a subsequent UIH message including a non-zero credit value.

28. A non-transitory processor-readable medium having stored thereon processor-executable instructions configured to cause a processor of a computing device to perform operations comprising: Receive a connection request message from a Bluetooth (BT) device; establishing an asynchronous connection-oriented logical transport (ACL) connection between the computing device and the BT device in response to the connection request message; and As part of managing a radio frequency communication (RFCOMM) connection handover between a first Bluetooth (BT) stack and a second BT stack, a synchronization message including BT context information is sent from the first BT stack to the second BT stack.

29. The non-transitory processor-readable medium of claim 28, wherein the stored processor-executable instructions are further configured to cause the processor of the computing device to perform operations comprising: receiving, by the first BT stack, a Service Discovery Protocol (SDP) search request message from the BT device; and An SDP response message is sent from the first BT stack to the BT device in response to the SDP request message.

30. The non-transitory processor-readable medium of claim 28, wherein the stored processor-executable instructions are further configured to cause the processor of the computing device to perform operations comprising: Establishing an RFCOMM session between the computing device and the BT device; Receiving, by the first BT stack, a Set Asynchronous Balanced Mode (SABM) command from the BT device; Sending the SABM command from the first BT stack to the second BT stack; sending a filtering policy from the second BT stack to a BT controller of the computing device, wherein the filtering policy is based on the SABM command; sending, from the second BT stack to the first BT stack, a ready message indicating that the BT controller has been configured with the filtering policy; as well as An Unnumbered Acknowledgement (UA) message is sent from the first BT stack to the BT device.

Images