0

I would like to have a discussion about modifying Bluetooth stack and thinking about what are the important factors that should be considered in general. I have proposed some solutions related to the IP for Bluetooth and now I am in the step to decide which one is more suitable to implement. My different solutions could be implemented on top of GATT or as an adaptation layer on top of L2CAP or on top of Link Layer. My questions are

  1. is there any difference in the energy consumption if the solution is implemented on the top of the Link layer or on top of, for example, L2CAP?

  2. is the Bluetooth stack implementation open source? is the firmware of LL open source?

  3. what else should I consider for the selection of the layer positions?

  4. Is operating system important? why?

Talia
  • 2,947
  • 4
  • 17
  • 28
  • As a side note: If you want to propose a change to the Bluetooth specification it might be best to join the Bluetooth SIG and a working group https://www.bluetooth.com/specifications/working-groups/ They are the ones changing the standard – Michael Kotzjan May 04 '21 at 04:48

1 Answers1

0

The Bluetooth HCI Commands and Events are interoperable; Only the vendor defined(proprietary) HCI commands and Events are not. Top of the HCI layer is called Host. Bottom of the HCI is called Controller.

For Example: BlueZ (Initated by Qualcomm and maintained by Intel now) stack is usually present on Linux. But the Bluetooth Controller might be from Broadcom. They are interoperable until the HCI commands follow the Bluetooth Specifications.

Both L2CAP and GATT are layers above HCI. The Power Consumption always is dependent on Application. Radio Modem and the CPU Core are the most power consuming part of the Bluetooth Communication. The CPU core needs to put the Radio IP to sleep whenever it is not needed. There needs to be an Idle Thread which monitors the application activity and put the Radio to sleep and wakeup.

Most of the Bluetooth Protocol are Finite State Machines and can be implemented using State (Event-driven) design pattern.

Do not give the memory management overhead to applications; it needs to be taken care by the Bluetooth stack.

There are couple of Open source BLE stacks as mentioned by @Youssif here.

I dont understand your 4th Question though.

Ranjith Kumar
  • 68
  • 1
  • 9