METHOD AND SYSTEM FOR A DISTRIBUTED BLUETOOTH® HOST ARCHITECTURE

Abstract

Aspects of a method and system for a distributed Bluetooth® Host Architecture may include combining a single main Bluetooth® host with subsidiary Bluetooth® hosts to form a distributed Bluetooth® processing entity that operates as a single Bluetooth® host for a Bluetooth® host controller. An active data connection may be handed over between the main Bluetooth® host and the subsidiary Bluetooth® hosts, where the active data connection may be between the Bluetooth® host controller and the distributed Bluetooth® entity. The active data connection may be an Asynchronous connection-less (ACL) link or a Synchronous Connection-Oriented (SCO) link. Layers of a protocol stack of the main Bluetooth® host may be synchronized with one or more of the subsidiary Bluetooth® hosts to achieve hand over.

Description

CROSS-REFERENCE TO RELATED APPLICATIONS/INCORPORATION BY REFERENCE

This application makes reference to:

U.S. application Ser. No. ______ (Attorney Docket No. 18004US01), filed on even date herewith.

The above referenced application is hereby incorporated herein by reference in its entirety.

FIELD OF THE INVENTION

Certain embodiments of the invention relate to wireless communication systems. More specifically, certain embodiments of the invention relate to a method and system for a distributed Bluetooth® Host Architecture.

BACKGROUND OF THE INVENTION

Bluetooth® wireless technology offers personal connectivity and provides freedom from wired connections. Bluetooth® is a specification for a small form-factor, low-cost radio solution providing links between mobile computers, mobile phones and other portable, handheld devices.

Bluetooth® wireless technology is an international, open standard for allowing intelligent devices to communicate with each other through wireless, short-range radio links. This technology allows Bluetooth® compliant devices such as computers, cell phones, keyboards and/or headphones to establish connections, without wires, cables or any direct action from a user. Bluetooth® is currently incorporated into numerous commercial products including laptops, Personal Digital Assistants (PDAs), cell phones, and printers, with more products being released every day.

Modern portable devices increasingly provide converged functionality of many devices that used to be separate entities. For example, it is now common to find PDA, cell phone and portable music player converged into a single device. Such multi-modal devices often comprise a variety of functional blocks to fulfill various tasks and several functional blocks and/or chipsets may access Bluetooth® functionality.

A Bluetooth® system normally comprises a Bluetooth® host that may be part of a functional block, and a Bluetooth® host controller. The Bluetooth® host may, for example, be a GSM (Global System for Mobile Communications) chipset or functional block. The Bluetooth® host provides a high level interface between a Bluetooth® command set and a core application furnished by the Bluetooth® host. A Bluetooth® host may be coupled to a Bluetooth® host controller via a host controller interface (HCI). The Bluetooth® host controller comprises the baseband and RF portion of the Bluetooth® system, that is, the actual radio part that may be connected to the Bluetooth® antenna. If, for example, the Bluetooth® host is a GSM block and there is also a multimedia decoder block that may need to stream music to a pair of Bluetooth® headphones, the multimedia decoder will send the audio data to the Bluetooth® Host in the GSM block to be forwarded to the Bluetooth® Host controller. The disadvantage of such a structure is that the functional block comprising the Bluetooth® host is always required to be active whenever Bluetooth® functionality is required, even if its core functionality may not be required. In this example, when the GSM phone functionality is switched off but the user is playing music over Bluetooth® headphones, the GSM block may need to remain active. Such a configuration is, however, power inefficient.

Further limitations and disadvantages of conventional and traditional approaches will become apparent to one of skill in the art, through comparison of such systems with some aspects of the present invention as set forth in the remainder of the present application with reference to the drawings.

BRIEF SUMMARY OF THE INVENTION

A method and/or system for a distributed Bluetooth® Host Architecture, substantially as shown in and/or described in connection with at least one of the figures, as set forth more completely in the claims.

These and other advantages, aspects and novel features of the present invention, as well as details of an illustrated embodiment thereof, will be more fully understood from the following description and drawings.

BRIEF DESCRIPTION OF SEVERAL VIEWS OF THE DRAWINGS

FIG. 1A is a diagram illustrating an exemplary communications system utilizing Bluetooth®, in connection with an embodiment of the invention.

FIG. 1B is a block diagram illustrating an exemplary GSM handset with a Bluetooth® host, in accordance with an embodiment of the invention.

FIG. 2 is a flow diagram illustrating an exemplary Bluetooth® data flow from a special purpose processor to a Bluetooth® host controller in a Bluetooth® system, in accordance with an embodiment of the invention.

FIG. 3 is a block diagram illustrating an exemplary GSM handset with a distributed Bluetooth® host architecture, in accordance with an embodiment of the invention.

FIG. 4 is a flow diagram illustrating an exemplary Bluetooth® data flow in a distributed Bluetooth® system, in accordance with an embodiment of the invention.

FIG. 5 is a block diagram, illustrating an exemplary distributed Bluetooth® host architecture, in accordance with an embodiment of the invention.

DETAILED DESCRIPTION OF THE INVENTION

Certain embodiments of the invention may be found in a method and system for a distributed Bluetooth® Host Architecture. Aspects of a method and system for a distributed Bluetooth® Host Architecture may include combining a single main Bluetooth® host with subsidiary Bluetooth® hosts to form a distributed Bluetooth® processing entity that operates as a single Bluetooth® host for a Bluetooth® host controller. An active data connection may be handed over between the main Bluetooth® host and the subsidiary Bluetooth® hosts, where the active data connection may be between the Bluetooth® host controller and the distributed Bluetooth® entity. The active data connection may be an Asynchronous connection-less (ACL) link or a Synchronous Connection-Oriented (SCO) link. Layers of a protocol stack of the main Bluetooth® host may be synchronized with one or more of the subsidiary Bluetooth® hosts to achieve hand over. The main Bluetooth® host and the subsidiary Bluetooth® hosts comprise a Host Controller Interface (HCI) layer that may route data to at least the subsidiary Bluetooth® hosts or the main Bluetooth® host. The main Bluetooth® host may comprise an augmented feature set to perform the synchronizing of the layers and to achieve hand over. The subsidiary Bluetooth® hosts may comprise a limited feature set that only maintains the active data connection.

FIG. 1A is a diagram illustrating an exemplary communications system utilizing Bluetooth®, in connection with an embodiment of the invention. Referring to FIG. 1A, there is shown a GSM handset 150, a GSM base station 152 and Bluetooth® headphones 154. There is also shown a GSM wireless connection and a Bluetooth® wireless connection.

Many modern portable devices may comprise Bluetooth® functionality. For example, Global System for Mobile Communications (GSM) handsets may comprise Bluetooth® blocks to connect to a large variety of peripheral devices. In FIG. 1A, an exemplary GSM headset 150 may be utilizing a Bluetooth® wireless connection to connect to the Bluetooth® headphones 154.

In addition to its core telephone functionality, the GSM handset 150 may comprise further functional blocks and/or chipsets to provide additional functionality. For example, the GSM handset 150 may comprise an audio decoder block that may efficiently decode a number of music formats. In order for the user of the GSM handset 150 to listen to audio decoded by the audio block on the Bluetooth® headphones 154, the GSM handset 150 may forward audio data from the audio block over its Bluetooth® stack to the Bluetooth® headphones 154.

FIG. 1B is a block diagram illustrating an exemplary GSM handset with a Bluetooth® host, in accordance with an embodiment of the invention. Referring to FIG. 1B, there is shown a GSM handset 160, comprising a processor 162, system memory 168, a GSM block 166, a multimedia block 164, a Bluetooth® host controller 170, a GSM antenna 174 and a Bluetooth® antenna 172. The GSM block 166 may comprise a GSM core functionality block 176 and a GSM Bluetooth® Host 178. The multimedia block 164 may comprise a multimedia core functionality block 180. There is also shown a GSM-processor interface 182, a multimedia (MM)-processor interface 184, a memory interface 184, a data interface 190, and host controller interface (HCI) transport 1 interface 186. The processor 162 may be a main processor or a baseband processor, for example.

The GSM handset 160 may be controlled by the processor 162, utilizing system memory 168 via the memory interface. The processor 162 may control the high-level functionality of the GSM handset 160, for example, the user interface and access to the GSM block 166 and the multimedia block 164. Access to the GSM block 166 and the multimedia block 164 may occur via the GSM-processor interface 182 and the MM-processor interface 184, respectively. In one embodiment of the invention, the GSM block 166, the system memory 168, the multimedia block 164, processor 162, Bluetooth® host controller 170, the GSM antenna 174 and the Bluetooth® antenna 172 may be functional blocks of a single chipset. In another embodiment of the invention, the functional blocks may each be a chip or some functional blocks may be combined into a chip.

The GSM block 166 may provide the core mobile telephone functionality of the GSM handset 160 in the GSM core functionality block 176. The GSM block 166 may also be communicatively coupled to the GSM antenna 174. In addition, the GSM block 166 may comprise a GSM Bluetooth® host 178 that may be used, for example, to connect to peripheral devices like headsets. The GSM Bluetooth® host 178 in the GSM block 166 may communicate directly with the Bluetooth® host controller 170 via HCI transport 1 interface 186. The Bluetooth® host controller 170 may comprise the radio portion of the Bluetooth® radio and hence may be communicatively coupled to the Bluetooth® antenna 172. The multimedia block 164 may provide, for example, audio and video decoding for the GSM handset 160. To forward, for example, audio data from the multimedia block 164 to a peripheral device communicatively coupled to the GSM handset 160 via a Bluetooth® interface that may be controlled by the GSM Bluetooth® host 178, the multimedia block 164 may send the appropriate audio data to the GSM Bluetooth® host 178. The data may be sent via the MM-processor interface, the processor 162 and the GSM-processor interface 182, or by using a dedicated interface, the data interface 190, directly linking the GSM block 166 and the multimedia block 164.

While FIG. 1B depicts an exemplary GSM handset 160, in various embodiments of the invention, the wireless system in FIG. 1B may comprise any number of functional block combinations with a Bluetooth® host. For example, an IEEE 802.11 WLAN block, a CDMA block or a WIMAX block may replace the GSM block 166 and a video block, an FM radio block, a keyboard controller block or a photo camera block may replace the multimedia block 164. These functional blocks may be integrated in one or more chipsets.

FIG. 2 is a flow diagram illustrating an exemplary Bluetooth® data flow from a special purpose processor to a Bluetooth® host controller in a Bluetooth® system, in accordance with an embodiment of the invention. Referring to FIG. 2, there is shown a special purpose processor 202, a Bluetooth® main host 204 and a Bluetooth® host controller 206 and protocol steps 208, 210, 212, 214, 216, 218, 220, 222, 224, 226, 228, 230 and 232.

The communicating entities, the special purpose processor 202, the Bluetooth® main host 204 and the Bluetooth® host controller 206 may be horizontally aligned in FIG. 2. Time may be increasing in the direction indicated by the arrow labeled ‘time’. Protocol communications may take place between the entities that may be connected by the protocol steps and, if applicable, may be directional as indicated by the protocol step arrow. The special purpose processor 202, the Bluetooth® main host 204, and the Bluetooth® host controller 206 may correspond to the multimedia block 164, the GSM Bluetooth® host 178 and the Bluetooth® host controller 170, respectively, as shown in FIG. 1B.

In step 208, a Bluetooth® data connection may be set up between the Bluetooth® main host 204 and the Bluetooth® host controller 206. The Bluetooth® host controller 206 may in turn relay the setup data to a receiving entity, for example, a headset 154, as shown in FIG. 1A. Such a Bluetooth® setup phase may comprise, for example, user authentication, exchange of security credentials and/or various connection parameters like queue memory allocation, flow control and so on.

The Bluetooth® host controller 206 may initiate an exchange of data with the special purpose processor 202 in step 210. Since Bluetooth® traffic may go via the Bluetooth® main host 204, the Bluetooth® main host 204 may acknowledge in step 212 receipt of the ‘commence data transfer command’ of step 210 and forward a ‘send data’ command to the special purpose processor 202 in step 214. The special purpose processor 202 may acknowledge the ‘send data’ command in step 216. Step 216 may complete the main setup of the Bluetooth® connection from the special purpose processor 202 to the Bluetooth® host controller 206 via the Bluetooth® main host 204 and normal payload data exchange may occur as shown in steps 218 and 220. For example, such a connection may be an Asynchronous Connection-Less link (ACL) or a Synchronous Connection-Oriented link (SCO). The data connection may be maintained for a long period of time, illustrated by the width of the arrows for protocol steps 218 and 220. The data exchange may pass via the Bluetooth® main host 204 since the Bluetooth® functionality may be handled by the Bluetooth® main host 204, even though the signal processing associated with the data payload may be performed at the special purpose processor 202.

Eventually, it may be desirable for the Bluetooth® host controller 206 to terminate the data exchange with the special purpose processor 202. The Bluetooth® host controller 206 may send a ‘stop data’ command in step 222 to the Bluetooth® main host 204. The Bluetooth® main host may acknowledge receipt of the ‘stop data’ command in step 224 and may forward the ‘stop data’ command to the special purpose processor 202. In step 228, the special purpose processor 202 may acknowledge receipt of the ‘stop data’ command and terminate the exchange of data. In step 230, the Bluetooth® main host 204 may commence to release the connection with the Bluetooth® host controller 206, which is no longer required. The Bluetooth® host controller 206 may acknowledge the ‘release connection’ command in step 232.

A disadvantage of the above illustrated exemplary data flow may be that the exchange of data between the special purpose processor 202 and the Bluetooth® host controller 206 in steps 218 and 220 may pass via the Bluetooth® main host 204. If, for example, the special purpose processor 202 and the Bluetooth® main host 204 may correspond to a multimedia block 164 and a GSM block 166, respectively, as shown in FIG. 1B, the GSM block 166 may remain active due to the data transfer from the multimedia block 164, even if the GSM core functionality 176 may not be desired. This may result in higher power consumption since both blocks 164 and 166 may remain active. One approach to improve power consumption may be to implement a smaller Bluetooth® stack, a Bluetooth® Light host, in the multimedia block 164 that may support data transfer directly from the multimedia block 164 to the Bluetooth® host controller 170 during data transfer steps 218 and 220, thereby allowing the GSM block 166 to enter a sleep state.

FIG. 3 is a block diagram illustrating an exemplary GSM handset with a distributed Bluetooth® host architecture, in accordance with an embodiment of the invention. Referring to FIG. 3, there is shown a GSM handset 360, comprising a processor 362, system memory 368, a GSM block 366, a multimedia block 364, a Bluetooth® host controller 370, a GSM antenna 374 and a Bluetooth® antenna 372. The GSM block 366 may comprise a GSM core functionality block 376 and a GSM Bluetooth® main host 378. The multimedia block 364 may comprise a multimedia core functionality block 380 and a multimedia Bluetooth® light host 382. There is also shown a GSM-processor interface 394, a multimedia (MM)-processor interface 384, a memory interface 388, a Bluetooth® (BT) interface 390, and host controller interface (HCI) transport 1 interface 386 and HCI transport 2 interface 392.

The GSM handset 360 may be controlled by the processor 362, utilizing system memory 368 via the memory interface 388. The processor 362 may control the high-level functionality of the GSM handset 360, for example, a user interface and access to the GSM block 366 and the multimedia block 364. Access to the GSM block 366 and the multimedia block 364 may occur via the GSM-processor interface 394 and the MM-processor interface 384, respectively. In one embodiment of the invention, the GSM block 366, the system memory 368, the multimedia block 364, processor 362, Bluetooth® host controller 370, the GSM antenna 374 and the Bluetooth® antenna 372 may be functional blocks of a single chipset. The processor 362 may be a main processor or a baseband processor, for example. In another implementation, the functional blocks may each be a chip or some functional blocks may be combined into a chip.

The GSM block 366 may provide the core mobile telephone functionality of the GSM handset 360 in the GSM core functionality block 376. The GSM block 366 may also be communicatively coupled to the GSM antenna 374. In addition, the GSM block 366 may comprise a GSM Bluetooth® main host 378 that may be used, for example, to connect to peripheral devices like headsets via Bluetooth®. The multimedia block 364 may provide, for example, audio and video decoding for the GSM handset 360. The multimedia block 364 may comprise a multimedia Bluetooth® light host 382 that may communicate directly with the Bluetooth® host controller 370 via the HCI transport 2 interface 392 and the GSM Bluetooth® host 378 via the Bluetooth® interface 390. The GSM Bluetooth® main host 378 in the GSM block 366 may also communicate directly with the Bluetooth® host controller 370 via HCI transport 1 interface 386. The Bluetooth® host controller 370 may comprise the radio portion of the Bluetooth® radio and hence may be communicatively coupled to the Bluetooth® antenna 372.

The Bluetooth® light host 382 may form part of the GSM Bluetooth® main host 378 and may replicate a small set of the functionality by the GSM Bluetooth® main host 378, thence the name of distributed Bluetooth® host. The Bluetooth® light host 382 may not offer stand-alone Bluetooth® host functionality, instead, it may be designed to be handed over certain specific tasks from the GSM Bluetooth® main host 378. Notwithstanding, the invention may not be so limited. Since the multimedia Bluetooth® light host 382 may communicate directly with the Bluetooth® host controller 370 via, for example, HCI transport 2 interface 392, the GSM Bluetooth® main host 378 may hand over Bluetooth® traffic to multimedia Bluetooth® light host 382. This process may be transparent to the Bluetooth® host controller 370, that is, the Bluetooth® host controller 370 may not be aware that there are more than one Bluetooth® host entities active. Communications between the multimedia Bluetooth® light host 382 and the GSM Bluetooth® main host 378 may occur over the Bluetooth® interface. An advantage of the distributed Bluetooth® host architecture illustrated in FIG. 3 is that the GSM Bluetooth® main host 378 may hand over certain Bluetooth® functionality to the multimedia Bluetooth® light host. In instances where the GSM core functionality block 376 may be inactive, handing over the Bluetooth® functionality may permit the GSM block 366 to enter a sleep mode, thereby reducing power consumption that may lead to improved battery life of the GSM handset 360. Another advantage of using a multimedia Bluetooth® light host 382 may be the small footprint required on the multimedia block 364 due to its limited functionality, in comparison to a complete Bluetooth® host.

While FIG. 3 depicts an exemplary GSM handset 360, the wireless system in FIG. 3 may comprise any number of functional block combinations with multiple Bluetooth® hosts. For example, an IEEE 802.11 WLAN block, a CDMA block or a WIMAX block may replace the GSM block 366 and a video block, an FM radio block, a keyboard controller block or a photo camera block may replace the multimedia block 364. These functional blocks may or may not be comprised in separate chipsets.

FIG. 4 is a flow diagram illustrating an exemplary Bluetooth® data flow in a distributed Bluetooth® system, in accordance with an embodiment of the invention. Referring to FIG. 4, there is shown a special purpose processor with a Bluetooth® light host (SPP-BLH) 402, a Bluetooth® main host 404 and a Bluetooth® host controller 406, protocol steps 408, 410, 412, 414, 416, 418, 420, 422, 424, 426, 428, 430, 432, 436, 440 and 446, and events 434, 438, 442, 446 and 448

The communicating entities, SPP-BLH 402, Bluetooth® main host 404 and Bluetooth® host controller 406 may be horizontally aligned in FIG. 4. Time may be increasing in the direction indicated by the arrow labeled ‘time’. Protocol communications may take place between the entities that may be connected by the protocol steps and, if applicable, may be directional as indicated by the protocol step arrow. The PBL-BLH 402, the Bluetooth® main host 404, and the Bluetooth® host controller 406 may correspond to the multimedia Bluetooth® light host 382, GSM Bluetooth® main host 378 and Bluetooth® host controller 370, respectively, as shown in FIG. 3.

In step 408, a Bluetooth® data connection may be set up between the Bluetooth® main host 404 and the Bluetooth® host controller 406. The Bluetooth® host controller may in turn relay the setup data to a receiving entity, for example, a headset 154, as shown in FIG. 1A. Such a Bluetooth® setup phase may comprise user authentication, exchange of security credentials and/or various connection parameters like queue memory allocation, flow control and so on.

The Bluetooth® host controller 406 may initiate an exchange of data with the SPP-BLH 402 in step 410. Since Bluetooth® traffic may be communicated via the Bluetooth® main host 404, the Bluetooth® main host 404 may acknowledge, in step 412, receipt of the ‘commence data transfer command’ of step 410 and forward a ‘send data’ command to the SPP-BLH 402 in step 414. The SPP-BLH 402 may acknowledge the ‘send data’ command in step 416. Step 416 may complete the main setup of the Bluetooth® connection from the SPP-BLH 402 to the Bluetooth® host controller 406 via the Bluetooth® main host 404 and normal payload data exchange may occur as shown in steps 418 and 420. For example, such a connection may be an Asynchronous Connection-less link (ACL) or a Synchronous Connection-Oriented link (SCO). The data connection may be maintained for a long period of time as illustrated by the width of the arrows for protocol steps 418 and 420. The data exchange may pass via the Bluetooth® main host 404 and the Bluetooth® functionality may be handled by the Bluetooth® main host 404, even though the signal processing associated with the data payload may be performed at the special purpose processor 402.

It may be desirable for the Bluetooth® main host 404 to hand over the established data connection shown in steps 418 and 420 to the SPP-BLH 402. For example, this case may occur in instances where the core functionality of the functional block comprising the Bluetooth® main host 404 is no longer required or suspended. In these instances, the Bluetooth® main host 404 may handover the connection established in 418 and 420 to the SPP-BLH 402 without tearing down the connection.

In step 434, the Bluetooth® main host 404 may initiate a handover to the SPP-BLH 402 by sending a ‘handover data transport’ command in step 436. This may wake the Bluetooth® Light host component of the SPP-BLH in event 438. If the SPP-BLH is ready to take over the data connection, it may acknowledge the ‘handover data transport’ command in step 440 to the Bluetooth® main host 404. Since the SPP-BLH 402 may take over the Bluetooth® connection with the Bluetooth® host controller 406, the Bluetooth® main host 404 may enter a sleep state in event 442. The SPP-BLH 402 may now use its Bluetooth® light host to send data directly to the Bluetooth® host controller 406, thereby bypassing the Bluetooth® main host 404. The handover may be such that the data connection may be temporarily suspended but may not be dropped, to ensure continuity and transparence to the Bluetooth® host controller 406.

Eventually, it may be desirable to stop the data exchange of the SPP-BLH 402 with the Bluetooth® host controller 406, for example, in response to a command from an application. The SPP-BLH 402 may send a ‘stop data’ command in step 422 to the Bluetooth® host controller 406. The Bluetooth® host controller 406 may acknowledge receipt of the ‘stop data’ command in step 424. The SPP-BLH 402 may send a ‘handover and stop’ command to the Bluetooth® main host 404 in step 426. This may allow the Bluetooth® main host 404 to wake from its sleep state in event 446, and to initiate a connection release. In step 428, the Bluetooth® main host 404 may acknowledge receipt of the ‘handover and stop’ command and terminate the exchange of data. The SPP-BLH 402 may go to sleep in event 448. In step 430, the Bluetooth® main host 404 may commence to release the connection with the Bluetooth® host controller 406, which is no longer required. The Bluetooth® host controller 406 may acknowledge the ‘release connection’ command in step 432.

In another embodiment of the invention it may be desirable to release the connection between the SPP-BLH 402 and the Bluetooth® host controller 406 directly from the SPP-BLH 402. In these instances, the ‘handover and stop’ and ‘handover and stop ACK’ commands in steps 426 and 428 may not be sent and the ‘release connection’ and ‘release connection ACK’ commands in steps 430 and 432 may be sent directly between the SPP-BLH 402 and the Bluetooth® host controller 406. In these instances, a connection release may be possible without handing the connection back to the Bluetooth® main host 404.

The flow diagram in FIG. 4 may illustrate an exemplary data flow for handover of a Bluetooth® connection control from a Bluetooth® main host 404 to a SPP-BLH 402 or vice versa. In some instances, it may also be the case that several Bluetooth® connections may be maintained active in parallel. In these instances, any of these parallel connections may be handed over and each connection may be controlled by a different Bluetooth® host.

FIG. 5 is a block diagram illustrating an exemplary distributed Bluetooth® host architecture, in accordance with an embodiment of the invention. Referring to FIG. 5, there is shown a Bluetooth® system 500 comprising a Bluetooth® main host 502, a Bluetooth® light host 504, a synchronization traffic interface 506, an HCI traffic interface 508, an HCI transport 1 interface 510, an HCI transport 2 interface 512 and a Bluetooth® host controller 514. The Bluetooth® main host 502 may comprise an augmented protocol stack 516, comprising an application layer 518, a middleware layer 520, a logical link and adaptation protocol (L2CAP) layer 522, an HCI Layer 524, an HCI transport layer 526 and a synchronization stack 528. The Bluetooth® light host 504 may comprise a light protocol stack 536, comprising an application layer 538, a middleware light layer 540, a logical link and adaptation protocol (L2CAP) light layer 542, an HCI light layer 544, an HCI transport layer 546 and a synchronization stack 548.

In FIG. 5, an exemplary implementation of a distributed Bluetooth® host system 500 is illustrated. Although comprising one Bluetooth® main host 502 and one Bluetooth® light host 504, a system may be envisaged with a larger number of Bluetooth® light hosts. The Bluetooth® main host 502 may offer similar functionality to a non-distributed Bluetooth® host. The Bluetooth® main host 502 may comprise an augmented protocol stack 516 compared to a non-distributed Bluetooth® host. This may be due primarily to the extra functionality to manage the Bluetooth® light host and associated functions, like handover. The application layer 518, the middleware layer 520, the L2CAP layer 522 and the HCI transport layer 526 may be similar to those entities in a non-distributed Bluetooth® host. The HCI layer 524, however, may be significantly different because it may comprise a number of extra functionalities. For example, the HCI layer may enable transparent switching between the HCI transport 1 interface 510 and the HCI transport 2 interface 512.

In another embodiment of the invention, HCI transport 2 interface 512 and HCI transport 1 interface 510 may be physically connected into a single HCI bus. Communications between the HCI layer 524 and the HCI layer light 544 may be significant and a dedicated HCI traffic interface 508 may be provided. The synchronization stack 528 may be used to synchronize the middleware layer 520, the L2CAP layer 522, the HCI layer 524 and the HCI transport layer 526 with the middleware light layer 540, the L2CAP light layer 542, the HCI light layer 544 and the HCI transport layer 546, respectively. A dedicated synchronization traffic interface 506 may be provided.

The Application layer 538, middleware light layer 540, L2CAP light layer 542 and HCI light layer 544 comprised in the light protocol stack 536 may be of limited functionality and may support maintaining an established connection. Connection establishment and release may be handled by the Bluetooth® main host 502.

The synchronization stacks 528 and 548 may be particularly important because these stacks may permit seamless handover between the Bluetooth® main host 502 and the Bluetooth® light host 504. The synchronization stacks 528 and 548 may synchronize the layers in the Bluetooth® main host 502 with the Bluetooth® light host 504 in a manner that may allow switching an active connection between the Bluetooth® main host 502 and the Bluetooth® light host 504. For example, the Bluetooth® light host 504 may be able to start its Bluetooth® light protocol stack 536 in an operations state that may correspond to it having established a connection, authenticated a user and allocated queue memory, although the Bluetooth® light protocol stack 536 may neither have performed these operations nor may it be able to perform these operations that may have been performed at the Bluetooth® main host 502.

Since the handover between the Bluetooth main host 502 and the Bluetooth® light host 504 may be transparent to the Bluetooth® host controller 514, the HCI light layer 544 may need to closely observe any packets arriving over the active HCI interface, for example, HCI transport 2 interface 512. In instances where a packet arrives that may require an action that the Bluetooth® light host 504 may not be able to perform, the HCI light layer 544 may forward the packet to the Bluetooth® main host 502 via the HCI traffic interface 508 and the HCI layer 524 for processing. Therefore, the HCI light layer 544 may perform the function of a router that may forward packets to the correct part of the distributed Bluetooth® stack. One feasible approach may be to parse packet headers and use a channel identification number to forward packets to the correct destination. A connection may be assigned the channel identification number upon establishment.

In accordance with an embodiment of the invention, a method and system for a distributed Bluetooth® Host Architecture may include combining a single main Bluetooth® host 502 with subsidiary Bluetooth® hosts 504 to form a distributed Bluetooth® processing entity that operates as a single Bluetooth® host for a Bluetooth® host controller, shown in FIG. 5. An active data connection may be handed over between the main Bluetooth® host 502 and the subsidiary Bluetooth® hosts 504, where the active data connection may be between the Bluetooth® host controller and the distributed Bluetooth® entity. This may also be seen in FIG. 3 and FIG. 4. The active data connection may be an Asynchronous connection-less (ACL) link or a Synchronous Connection-Oriented (SCO) link. The layers of a protocol stack of the main Bluetooth® host 502 may be synchronized with one or more of the subsidiary Bluetooth® hosts 504 to achieve hand over, as explained for FIG. 4 and FIG. 5. The main Bluetooth® host 502 and the subsidiary Bluetooth® hosts 504 may comprise a Host Controller Interface (HCI) layer, 544 and 524, which may route data to at least the subsidiary Bluetooth® hosts 504 or the main Bluetooth® host 502, shown in FIG. 5. The main Bluetooth® host 502, shown in FIG. 5, may comprise an augmented feature set to perform the synchronizing of the layers and achieve handing over, as explained in FIG. 6. The subsidiary Bluetooth® hosts 504, shown in FIG. 5, may comprise a limited feature set that only maintains the active data connection.

Another embodiment of the invention may provide a machine-readable storage, having stored thereon, a computer program having at least one code section executable by a machine, thereby causing the machine to perform the steps as described above for a distributed Bluetooth® Host Architecture.

Accordingly, the present invention may be realized in hardware, software, or a combination of hardware and software. The present invention may be realized in a centralized fashion in at least one computer system, or in a distributed fashion where different elements are spread across several interconnected computer systems. Any kind of computer system or other apparatus adapted for carrying out the methods described herein is suited. A typical combination of hardware and software may be a general-purpose computer system with a computer program that, when being loaded and executed, controls the computer system such that it carries out the methods described herein.

The present invention may also be embedded in a computer program product, which comprises all the features enabling the implementation of the methods described herein, and which when loaded in a computer system is able to carry out these methods. Computer program in the present context means any expression, in any language, code or notation, of a set of instructions intended to cause a system having an information processing capability to perform a particular function either directly or after either or both of the following: a) conversion to another language, code or notation; b) reproduction in a different material form.

While the present invention has been described with reference to certain embodiments, it will be understood by those skilled in the art that various changes may be made and equivalents may be substituted without departing from the scope of the present invention. In addition, many modifications may be made to adapt a particular situation or material to the teachings of the present invention without departing from its scope. Therefore, it is intended that the present invention not be limited to the particular embodiment disclosed, but that the present invention will include all embodiments falling within the scope of the appended claims.

Claims

1. A method for processing signals in a wireless communication system, the method comprising: combining a single main Bluetooth® host with a plurality of subsidiary Bluetooth® hosts to form a distributed Bluetooth® processing entity that operates as a single Bluetooth® host for a Bluetooth® host controller.

2. The method according to claim 1, comprising handing over an active data connection between said main Bluetooth® host and one of said plurality of subsidiary Bluetooth® hosts.

3. The method according to claim 2, wherein said active data connection is between said Bluetooth® host controller and said distributed Bluetooth® entity.

4. The method according to claim 2, wherein said active data connection comprises an Asynchronous connection-less (ACL) link.

5. The method according to claim 2, wherein said active data connection comprises a Synchronous Connection-Oriented (SCO) link.

6. The method according to claim 2, comprising synchronizing layers of a protocol stack of said main Bluetooth® host with one or more of said plurality of subsidiary Bluetooth® hosts to achieve said handing over.

7. The method according to claim 1, wherein said main Bluetooth® host and said plurality of subsidiary Bluetooth® hosts comprise a Host Controller Interface (HCI) layer.

8. The method according to claim 7, comprising routing data arriving at said HCI layer to at least one of: said plurality of subsidiary Bluetooth® hosts and said main Bluetooth® host.

9. The method according to claim 6, wherein said single main Bluetooth® host comprises an augmented feature set to perform said synchronizing of said layers to achieve said handing over.

10. The method according to claim 2, wherein said plurality of subsidiary Bluetooth® hosts comprise a limited feature set that only maintains said active data connection.

11. A system for processing signals in a wireless communication system, the system comprising: one or more circuits that enable the combination of a single main Bluetooth® host with a plurality of subsidiary Bluetooth® hosts to form a distributed Bluetooth® processing entity that operates as a single Bluetooth® host for a Bluetooth® host controller.

12. The system according to claim 11, wherein said one or more circuits hand over an active data connection between said main Bluetooth® host and one of said plurality of subsidiary Bluetooth® hosts.

13. The system according to claim 12, wherein said active data connection is between said Bluetooth® host controller and said distributed Bluetooth® entity.

14. The system according to claim 12, wherein said active data connection comprises an Asynchronous connection-less (ACL) link.

15. The system according to claim 12, wherein said active data connection comprises a Synchronous Connection-Oriented (SCO) link.

16. The system according to claim 12, wherein said one or more circuits synchronize layers of a protocol stack of said main Bluetooth® host with one or more of said plurality of subsidiary Bluetooth® hosts to achieve said handing over.

17. The system according to claim 11, wherein said main Bluetooth® host and said plurality of subsidiary Bluetooth® hosts comprise a Host Controller Interface (HCI) layer.

18. The system according to claim 17, wherein said one or more circuits route data arriving at said HCI layer to at least one of: said plurality of subsidiary Bluetooth® hosts and said main Bluetooth® host.

19. The method according to claim 16, wherein said single main Bluetooth® host comprises an augmented feature set to perform said synchronizing of said layers to achieve said handing over.

20. The method according to claim 12, wherein said plurality of subsidiary Bluetooth® hosts comprise a limited feature set that only maintains said active data connection.