WO2019051087A1

WO2019051087A1 - Bluetooth data forwarding

Info

Publication number: WO2019051087A1
Application number: PCT/US2018/049748
Authority: WO
Inventors: Ram Malovany; Chen Loewy; Dotan Ziv; Lior Gersi; Liran Cohen
Original assignee: Texas Instruments Japan Ltd; Texas Instruments Inc
Current assignee: Texas Instruments Japan Ltd; Texas Instruments Inc
Priority date: 2017-09-06
Filing date: 2018-09-06
Publication date: 2019-03-14
Anticipated expiration: 2020-03-06
Also published as: US20250168611A1; JP7318949B2; CN118018993A; US10051450B1; EP3679763A4; JP2020533852A; US20240048951A1; US11832156B2; CN111052854B; CN111052854A; EP3679763A1; US10841771B2; US20190075440A1; US12267759B2; US20210029525A1; EP3679763B1

Abstract

A Bluetooth (BT) device (400) includes a host processor (425a) and a BT controller (425b) coupled by a Host Controller Interface (HCI) (430) including a Host Controller Transport Layer and a HCI Driver. The host processor (425a) implements an applications layer and includes HCI firmware for communicating via the Host Controller Transport Layer with the BT controller (425b). The BT controller (425b) includes a processor (423) coupled to a memory (422) and to a transceiver (424), and a RF driver (424a). The HCI firmware also includes HCI command code for a user to define a topology of a BT network including configuring the BT device (400) in a current chain including BT devices, including configuring from which BT device it receives data and to which BT device it forwards data. For communicating data across the BT network, the BT device (400) forwards the data without host processor (425a) involvement in at least resending the data back to its BT controller (425b).

Description

BLUETOOTH DATA FORWARDING

[0001] This relates generally to Bluetooth devices in Bluetooth network communications, and more particularly to data forwarding between such Bluetooth devices.

BACKGROUND

[0002] Bluetooth (BT) is an example ad-hoc networking technology. BT technology is a wireless communication standard generally used when transferring information between two or more wireless devices that are near to one another when speed is not a consideration, including telephones, printers, modems and headsets. BT is well-suited for low-bandwidth applications including transferring sound data with telephones (e.g., with a BT headset) or byte data with hand-held computers (transferring files), or keyboards and mice. The BT Special Interest Group (SIG) specification may be used for these BT communications.

[0003] BT is useful for scatternets, which include independent and unsynchronized piconets, where piconets are a basic unit of BT networking. A piconet has a master device and one or more slave devices, where the devices each generally include a host processor (or "application processor") and a controller (or "firmware (FW) processor"). The master device determines the channel and phase for the slave device(s). A scatternet is a type of adhoc computer network comprising two or more piconets. In a scatternet, a slave device can communicate with more than one piconet. In connection with operation of a scatternet, the BT master devices may relay the identity of mobile slave devices that are within their individual piconets to its host processor for purposes of tracking the location of a mobile slave device, or the location of a person carrying a mobile slave device.

[0004] As shown in FIG. 1, in order to forward data using BT over a BT network such as a scatternet where the BT devices shown as BT devices 101, 102 and 103 are each not in the same piconet and hence each have a different master, each BT device in the communication chain needs to perform several steps. The BT devices are shown including a host processor 125a and a BT controller 125b that are coupled together by a Host Controller Interface (HCI). HCI provides a uniform command method for accessing the BT hardware capabilities by providing a command interface to the baseband controller and link manager of the BT controller 125b, and access to hardware status and control registers.

[0005] Upon reception of the data, the BT devices other than the first BT device 101 shown as BT devices 102 and 103 in FIG. 1 each send this data to its host processor 125a. The host processor 125a parses the data, acts upon the received data (such as adds a timestamp, manipulates (changes the data), plays the data, or performs other data functionality), and then resends the data back to the BT controller 125b, which only then transmits the data to the next BT device in the chain. In forwarding the data BT devices 102 and 103 thus each execute three (3) steps as shown in FIG. 1 including two (2) steps just looping through the host processor 125a, while the first BT device 101 in the chain executes 2 total steps.

SUMMARY

[0006] For BT applications where each BT device includes a host processor and a BT controller coupled together by a HCI, conventional data forwarding for BT devices wakes up the host processor for looping with respect to its BT controller for every packet received, including resending the data back to its BT controller, which wastes battery power and also increases latency. For BT applications (e.g., scatternet applications), it is desirable to send data to the next BT device in the chain without involving the host processor, at least not looping through the host processor. This reduces the system power consumption dramatically in the Advanced Audio Distribution Profile (A2DP) use case.

[0007] All known BT-based communication systems involve the host processor of the BT devices participating in data forwarding by looping the data through the host processor before being forwarded to the next BT device in the chain including parsing, acting on, and resending the data to the BT controller. Advantages of described data forwarding include enabling data such as A2DP data to be transferred from one BT device to several other BT devices without waking up the host, or at least not looping through its host processor.

[0008] A new mechanism generally in the FW layer of the BT device allows the user to forward Asynchronous Connection-Less (ACL) data without the host processor involvement in at least resending the data received back to its BT controller, which minimizes data latency and device power consumption. A described set of new HCI commands between the host processor and BT controller enables a user to define the network topology to configure each BT device in the chain, including configuring from which one of the BT devices the BT device receives data, and to which one of the BT devices the BT device forwards the received data. Described HCI also optionally configures for each BT device whether to send the received data to its host processor, and if sent to its host processor, whether to add a time stamp to each packet (e.g., in order to time synchronize between the respective BT devices in the chain).

BRIEF DESCRIPTION OF THE DRAWINGS

[0010] FIG. 1 depicts data forwarding over BT in a conventional BT network.

[0011] FIG. 2 is a flowchart showing steps in an example method of BT ACL communications in a BT network, according to an example embodiment.

[0012] FIG. 3 depicts data forwarding over BT in a described BT network arrangement that uses described BT ACL data forwarding.

[0013] FIG. 4A is a block diagram schematic of an example BT device that uses described BT ACL data forwarding.

[0014] FIG. 4B is a block diagram schematic of a described BT device including a separate host processor and BT controller coupled to one another by a HCI, where the HCI includes HCI firmware including stored HCI command code which allows a user to define a topology of the BT network including for configuring for each BT device in a current chain, according to an example embodiment.

[0015] FIG. 5A shows video data forwarding in a stadium using described BT ACL data forwarding and FIG. 5B shows audio data forwarding using described BT ACL data forwarding which comprises A2DP data.

DETAILED DESCRIPTION OF EXAMPLE EMB ODEVIENT S

[0016] The drawings are not necessarily drawn to scale. In the drawings, like reference numerals designate similar or equivalent elements. Illustrated ordering of acts or events is not limiting, as some acts or events may occur in different order and/or concurrently with other acts or events. Furthermore, some illustrated acts or events may be optional to implement a methodology in accordance with this description.

[0017] In this description, the terms "coupled to" or "couples with" (and the like) as used herein without further qualification describe either an indirect or direct electrical connection. Thus, if a first device "couples" to a second device, that connection can be through a direct electrical connection where only parasitics are in the pathway, or through an indirect electrical connection via intervening items including other devices and connections. For indirect coupling, the intervening item generally does not modify the information of a signal, but may adjust its current level, voltage level and/or power level.

[0018] FIG. 2 is a flowchart showing steps for an example method 200 of BT ACL communications in a BT network, according to an example embodiment. The communications network can comprise a Bluetooth Special Interest Group (SIG) compliant network and the data can comprise audio data (e.g., A2DP data). However, described BT data forwarding can also be applied to non-audio data, such as to a line of lights to decide which lights to turn on and which lights to keep off.

[0019] Step 201 comprises providing BT devices at respective nodes in a BT network, where the BT devices (see the BT device shown in FIGs. 4A and 4B described below) comprise a host processor and a BT controller coupled to one another by an HCI including a Host Controller Transport Layer and a HCI Driver. The host processor implements an applications layer and includes HCI Firmware for communicating via the Host Controller Transport Layer with its BT controller.

[0020] The BT controller includes a processor coupled to a memory and to a transceiver, and a RF driver for driving the transceiver that is adapted to be coupled to an antenna. The HCI firmware includes described HCI command code which allows a user to define a topology of the BT network, including configuring each BT device in a current chain, including from which one of the BT devices it receives data and to which one of BT devices it should forward data. Step 202 comprises configuring the BT network, comprising configuring each BT device in a current chain, comprising configuring from which of the BT devices it receives data including at least one packet, and to which one of the BT devices it forwards the data. Step 203 comprises communicating the data across the BT network with the BT devices forwarding the data between the BT devices without the device's host processor's involvement in at least resending the data back to its BT controller.

[0021] FIG. 3 depicts data forwarding over BT in a described BT network arrangement that uses described BT ACL data forwarding that can be compared to FIG. 1 described above. Each BT device 301, 302 and 303 in the chain includes a host processor 425a and a BT controller 425b coupled together by a HCI 430. As described above, this BT network arrangement can be a scatternet including independent and unsynchronized piconets, with each BT device further comprising a sensor for implementing a BT-based wireless sensor network.

[0022] Upon reception of the data, the BT devices other than the first BT device 301 shown as BT devices 302 and 303 in FIG. 3 each send this data to the next BT device without their host processor's 425a involvement in at least resending the data back to their BT controller 425b. BT device 302 forwards the data without any involvement by its host processor 425a and is thus as shown only executing 1 step in forwarding the data. BT device 303 parses the data received, acts upon the received data (such as adds a timestamp), but without the host processor's 425a involvement resending the data back to its BT controller 425b thus shown executing 2 total steps in forwarding the data.

[0023] FIG. 4A shows a system block diagram representation for an example BT device 400 that generally conforms to the BT communications standard. The BT device 400 generally comprises at least one integrated circuit (IC) shown formed on a substrate 405a having a semiconductor surface for the BT controller 425b, and on another substrate 405b having a semiconductor surface for the host processor 425a. The BT device 400 may be any device that can engage in BT communications. Such BT devices may be, may include, or may be a part of, mobile phones such as smartphone, tablets, computers, personal digital assistants, and household items with communication capabilities such as speakers, window blinds, and motion sensors. The BT device 400 in operation communicates in a BT network along with other BT devices.

[0024] The BT device 400 comprises a host processor 425a and a BT controller 425b that communicate with one another over the HCI 430. The host processor 425a includes a memory 432 that stores described HCI FW including described HCI command code, which allows a user to define a topology of the BT network, including configuring each BT device in a current chain, including configuring from which one of the BT devices it receives data including at least one packet, and to which one of the BT devices it should forward the data. The BT controller 425b includes a processor 423, a memory 422 including software source code 422a for parsing, understanding and acting on commands received from the host processor 425a for implementing described ACL data forwarding for the BT device 400. BT device 400 also includes a transceiver 424 including a RF driver 424a that is adapted to be coupled to an antenna 418 which is generally off chip. The processors can comprise a digital signal processor (DSP) or microcontroller. The processors collectively implement a BT protocol stack for BT operations (see FIG. 4B described below).

[0025] The transceiver 424 is also shown including hardware comprising digital logic 424b that can be used as an alternative to software 422a for implementing described ACL forwarding. The transceiver 424 includes a transmitter and a receiver. The transmitter generally comprises a media access control (MAC) module, an encoder, a modulator, an inverse fast Fourier transform (IFFT) unit, a digital to analog conversion (DAC)/filter module, and a RF/antenna module. The receiver generally comprises a RF/antenna unit, an analog to digital conversion (ADC)/filter unit, a FFT unit, a demodulator, a decoder, and a MAC module.

[0026] The memory 422 is more generally configured to store information including data, instructions, or both. The memory 422 may be any storage medium accessible by the processor 423, such as a read only memory (ROM), a random access memory (RAM), a register, cache memory, or magnetic media device such as internal hard disks and removable disks. A phase lock loop (PLL) 432 is also provided for purposes including mixing and frequency synthesis.

[0027] The processor 423 is coupled to the memory 422 and to the transceiver 424. In some implementations, the transceiver 424 comprises baseband units (not shown in FIG. 4A, but see FIG. 4B) and analog units (not shown) to transmit and receive RF signals. The baseband unit may comprise hardware to perform baseband signal processing including digital signal processing, coding and decoding, modulation, and demodulation. The analog unit may comprise hardware to perform analog-to-digital conversion (an ADC), digital to analog conversion (a DAC), filtering, gain adjusting, up-conversion, and down-conversion. The analog unit may receive RF signals from an access point and down-convert the received RF signals to baseband signals to be processed by the baseband unit, or receive baseband signals from the baseband unit and up-convert the received baseband signals to RF wireless signals for uplink transmission. The analog unit comprises a mixer to up-convert the baseband signals and down-convert the RF signals with a carrier signal oscillated at the radio frequencies of the BT network. The data rate used by the BT device 400 may be in the current BT frequency band of 2.472 GHz to 2.479 GHz, or any future BT frequency band used.

[0028] FIG. 4B is a functional layer depiction of the BT device 400 shown in FIG. 4A now shown as 400' showing the host processor 425a including an application layer 440 including BT applications and a Logical Link Control and Adaptation Layer Protocol (L2CAP) layer 448. The BT protocol RFCOMM block 441 is a simple set of transport protocols, made on top of the L2CAP layer 448. The Telephony Control Protocol Specification (TCS) 442 defines ways to send audio calls between BT devices. The Service Discovery Protocol (SDP) 443 is a specification that defines a way to represent a range of UUTDs (which are nominally 128 bits) in a shorter form. The Point-to-Point Protocol (PPP 444) is a data link (layer 2) protocol used to establish a direct connection between two device nodes. The Transmission Control Protocol/Internet Protocol (TCP/IP) 445 enables the BT device to carry TCP/IP traffic, the OBEX 446 is a communications protocol that facilitates the exchange of binary objects between BT devices, and the AT 447 is a commands interface comprising a series of machine instructions used to activate features on the analog modem.

[0029] The BT controller 425b is shown including link manager protocol (LMP) 426, a baseband section and a RF section that are part of the transceiver 424 shown in FIG. 4A. The BT controller 425b is also shown including baseband circuitry 427 and RF circuitry 428. LMP 426 controls and negotiates all aspects of the operation of the BT connection between two adjacent BT devices.

EXAMPLES

[0030] Described embodiments are further illustrated by the following examples, which are not limiting the scope or content of this description in any way.

[0031] FIG. 5A shows video data forwarding in a stadium 500 using described BT ACL data forwarding. Camera 1 and camera 2 each have described BT devices such as BT device 400 shown in FIG. 4 A which communicate with another using a repeater 510 in between due to their separation distance being beyond the BT communication range. The cameras 1 and 2 both implement described data forwarding which enables the video data to be transferred from one camera to the other without waking up their host processor, or at least not looping through their host processor, which reduces latency and saves power compared to conventional data forwarding.

[0032] FIG. 5B shows audio data forwarding using described BT ACL data forwarding which comprises A2DP data. BT speaker 1 and BT speaker 2 comprise described BT devices such as shown in FIG. 4A which communicate with a repeater shown as repeater 560 in between due to their separation distance. An audio source 540 shown as a smart phone provides audio data to BT speaker 1, and another repeater shown as repeater 565 is between BT speaker 1 and the audio source 540 again due to their separation distance. As described above, the described BT device in BT speaker 1 sends ACL data to BT speaker 2 without involving their host processor, at least not looping through its host processor which reduces the system power consumption, particularly in this A2DP use case. [0033] Although BT communications are generally described herein using ACL, described BT communications may also use other link types, such as a Synchronous Connection Oriented (SCO) link which comprises a set of reserved timeslots on an existing ACL transport.

[0034] Modifications are possible in the described embodiments, and other embodiments are possible, within the scope of the claims.

Claims

CLAIMS What is claimed is:

1. A method of Bluetooth (BT) asynchronous connection-less (ACL) communications, the method comprising:

providing BT devices at respective nodes in a BT network, the BT devices each comprising a host processor and a BT controller coupled to one another by a Host Controller Interface (HCI) including a Host Controller Transport Layer and a HCI Driver, the host processor implementing an applications layer and including HCI Firmware for communicating via the Host Controller Transport Layer with the BT controller, the BT controller including a processor coupled to a memory and to a transceiver, and a RF driver for driving the transceiver which is adapted to be coupled to an antenna;

the HCI firmware including HCI command code which allow a user to define a topology of the BT network, including configuring for each the BT device in a current chain, including configuring from which one of the BT devices it receives data including at least one packet, and to which one of the BT devices it should forward the data;

configuring the BT network, including configuring each the BT device in the current chain except a first of the BT devices, including configuring from which one of the BT devices it receives the data and to which one of the BT devices it forwards the data, and

communicating the data across the BT network, wherein the BT devices forward the data across the BT network without the host processor's involvement in at least resending the data back to their the BT controller.

2. The method of claim 1, wherein the HCI command code further comprises code which allows the user to define whether to send the data to the host processor.

3. The method of claim 2, wherein the HCI command code further allows the user to define whether to add a time stamp to each the packet.

4. The method of claim 1, wherein the data comprises audio data.

5. The method of claim 1, wherein for at least one of the BT devices its the host processor sleeps during the communicating.

6. The method of claim 1, wherein the BT network comprises a scatternet including independent and unsynchronized piconets.

7. The method of claim 1, wherein the BT controller is formed on an integrated circuit (IC) comprising a substrate having at least a semiconductor surface, and wherein the processor of the BT controller comprises a digital signal processor (DSP).

8. A Bluetooth (BT) controller, comprising:

a processor coupled to a memory and to a transceiver, a RF driver for driving the transceiver which is adapted to be coupled to an antenna, the memory including software for parsing, understanding and acting on commands received from a host processor coupled to by a Host Controller Interface (HCI) including a Host Controller Transport Layer and a HCI Driver, and HCI command code firmware which defines a topology of a BT network of BT devices including the BT controller and the host processor, including receiving configuring information from the host processor regarding which one of the BT devices it receives data including at least one packet from, and to which one of the BT devices it should forward the data to;

the BT controller for communicating the data for the BT device across the BT network including for forwarding the data across the BT network without the host processor's involvement in at least resending the data back to its the BT controller.

9. The BT controller of claim 8, wherein the BT controller formed on an integrated circuit (IC) comprising a substrate having at least a semiconductor surface, and wherein the processor of the BT controller comprises a digital signal processor (DSP).

10. The BT controller of claim 8, wherein the HCI command code further comprises code which allows a user to define whether to send the data to the host processor.

11. The BT controller of claim 10, wherein the HCI command code further allow the user to define whether to add a time stamp to each the packet.

12. The BT controller of claim 8, wherein the data comprises audio data.

13. A Bluetooth (BT) device, comprising:

a host processor and a BT controller coupled to one another by a Host Controller Interface (HCI) including a Host Controller Transport Layer and a HCI Driver, the host processor implementing an applications layer and including HCI Firmware for communicating via the Host Controller Transport Layer with the BT controller;

the BT controller including a processor coupled to a memory and to a transceiver, a RF driver for driving the transceiver which is adapted to be coupled to an antenna;

the HCI firmware also including HCI command code which allows a user to:

define a topology of a BT network, including configuring for each the BT device in a current chain, including configuring from which one of the BT devices it receives data including at least one packet, and to which one of the BT devices it should forward the data, and

configure the BT device in the current chain within the BT network including BT devices, including configuring from which one of the BT devices it receives the data and to which one of the BT devices it forwards the data,

wherein for communicating the data across the BT network the BT device forwards the data without the host processor's involvement in at least resending the data back to its the BT controller.

14. The BT device of claim 13, wherein the HCI command code further comprises code which allow the user to define whether to send the data to the host processor.

15. The BT device of claim 13, wherein the HCI command code further allows the user to define whether to add a time stamp to each the packet.

16. The BT device of claim 13, the data comprises audio data.

17. The BT device of claim 13, wherein the host processor is configured to sleep during the communicating.

18. The BT device of claim 13, wherein the BT controller is formed on an integrated circuit (IC) comprising a substrate having at least a semiconductor surface, and wherein the processor of the BT controller comprises a digital signal processor (DSP).