How can we use HTTP over Bluetooth Low Energy (BLE)?

Question

Is there a way to send HTTP messages (GET, POST, etc) from BLE central(client) to BLE Peripheral(Server)? Currently, I am sending plain text using GATT protocol. Since an HTTP server already running inside my Peripheral, I would rather utilize HTTP protocol. Somebody suggested me to use HPS(HTTP Proxy Service) over BLE to do this job. But I really don't have any idea about HPS.

Is there any other way to send HTTP messages from Client to Server over BLE? Can anybody tell me how this can be done? or Is there any other way to send HTTP over BLE.

Any help would be appreciated

Answer 1

I disagree with Emil's statement that IPv6 over Bluetooth is the only standardised option. I work for the Bluetooth SIG btw. The HTTP Proxy Service is a standard GATT service. You can download the specification here: https://www.bluetooth.com/specifications/gatt/

There are comments here to the effect that "HTTP over Bluetooth" is a bad idea but no elaboration as to what it is that is "bad". I think there may be some confusion about what's involved though and what the intended use of the HTTP Proxy Service is.

This GATT HTTP Proxy service must run on a device that has both a Bluetooth Low Energy (LE) stack and a TCP/IP stack. It has GATT characteristics that allow HTTP requests to be configured, by writing values to those characteristics. This includes HTTP header values. The expectation is that most such parameters will not change or at least not change frequently after they have initially been set. Devices acting as a client to the GATT HTTP Proxy Service then send data over HTTP and TCP/IP indirectly, via the GATT server. They do this by writing to the HTTP Entity Body characteristic.... typically a small value such as a sensor reading. An HTTP operation is then triggered by the GATT client device by writing a single byte to the HTTP control point characteristic (e.g. 1 to trigger an HTTP GET).

It's perhaps a misnomer to talk about HTTP over Bluetooth. That's not what's happening here. This is a three tier architecture, with very lightweight Bluetooth LE communication between (1) a Bluetooth device and a (2) dual technology Bluetooth and TCP/IP device, acting as a proxy, which then communicates the Bluetooth encoded request that it has configured within it, to a (3) remote HTTP server over TCP/IP.

As for the comments about using the serial port profile and the suggestion that this would offer performance advantages, this too is questionable. There's no detail on what is envisaged here but I assume the idea is that entire HTTP operations be formulated and sent over a Bluetooth BR/EDR connection using the serial port profile. Bluetooth BR/EDR runs at 2 mega symbols per second at the physical layer and by default, Bluetooth LE runs at 1 mega symbol per second. But since Bluetooth 5, released several years ago, Bluetooth LE also supports 2 mega symbols per second. Furthermore, due to the design of the HTTP Proxy Service, with fixed or rarely varying component parts of an HTTP request only needing to be configured once, you will probably find you're transferring less data when using HPS vs SPP. It all depends, of course but I think this is likely....

Hope this helps.

Answer 2

<edit> You asked if there were any other way than the standardised HPS to send HTTP messages over Bluetooth. From what I know you have one more standardised option. </edit> The only thing standardised is IPv6 over BLE, but it's far from well-supported. The problem with http is that it will be pretty inefficient due to long strings that need to be sent as headers.

<edit>

You can find the HPS service here: https://www.bluetooth.org/docman/handlers/downloaddoc.ashx?doc_id=308344.

If you really want to use HTTP over BLE but don't want to use any of the standardised ways, you could for example open up an L2CAP CoC and simply send the HTTP request in one direction and send back the HTTP response in one direction. That way you just replace TCP with L2CAP CoC.

</edit>