5
\$\begingroup\$

I'm facing some problems understanding how Bluetooth LE works.

First: How is a connection established?

  • Peripheral (e.g. sensor) sends advertisements
  • Central (e.g. tablet) has to scan actively (generally it does not scan)
  • Central discovers advertisement and decides to connect to Peripheral
  • Central sends connection request to Peripheral
  • How does the Peripheral receives the request. Is the antenna in receiving mode, while sending advertisements? If so, is this receiving mode always on, reacting to any connection request (even without sending advertisements)?

Second: After connection loss/disconnection, is the above procedure mandatory to reconnect again or are there other ways? What about bonding/pairing? What if I know the MAC address of the peripheral?

Third: How could they reconnect (as fast and energy saving as possible) if the connection is lost.

Fourth: Is it possible to send/receive data from outside a connection (others then advertisements)? Or is a connection mandatory to register for notifications/indications etc?

Fifth: What is the best solution to establish an encrypted communication? Usually pairing/bonding allows for encryption. But how get the passkeys exchanged.

Sixth: While receiving advertisements. How do I know if the device is interesting for me? Does I need to connect and discover services? Is there a mechanism to determine the device class or type?

\$\endgroup\$
2
\$\begingroup\$

I know its very late to answer this, but I think I can add some more weight to the good answers here and complete them for someone else who is at a stage where you were last year, when you asked this question. I hope that it is acceptable to the community.


Lets talk about them in the real terms of a generic practical use case:

  • BLE Peripheral = GATT Server = (Mostly) A Slave of the communication, e.g. Sensor
  • BLE Central = GATT Client = (Mostly) The Master of the communication, e.g. a Smartphone

First: How is a connection established?

The GATT Server (Sensor/Peripheral) broadcasts advertisement packets at a defined interval. The GATT Client (Smartphone/Central) does a scan for nearby devices. Central discovers advertisement and decides to connect to Peripheral. The operating modes of antenna are never distinguished as sending and receiving. The Link Layer (L2CAP) has the ability to send advertisement packets and check for connection requests from the Central at the same time.


Second: After connection loss/disconnection, is the above procedure mandatory to reconnect again or are there other ways? What about bonding/pairing? What if I know the MAC address of the peripheral?

To reduce the connection latency, there is a really robust structure (not syntactically a struct) of Events provided. Whenever the Peripheral is disconnected from Central, the BLE stack generates an event. As a service routine to this event, if you have a handler written, you can parse the received event packet and determine the reason of disconnection, either deliberate or accidental/unexpected. Depending upon that, you can decide upon whether you want to put it back in advertising mode or not. FWIK, and for the modules I have worked on, after a disconnect it doesn't automatically goes into advertising mode. It has to be done manually.
On the Central side (considering android), there is a method: connectGatt();, It takes 3 arguments, first and third is not of out interests right now (Context and Callback), the second argument is a boolean variable (I guess, please confirm), which decides whether to attempt a reconnection or not. I believe that, deep down at grass-root level, it must have been implemented using MAC Address only, because that is what makes a device unique and hence uniquely identifiable.


Third: How could they reconnect (as fast and energy saving as possible) if the connection is lost.

Again, I would say. "it depends". It depends majorly on the event handling implementation on the Peripheral side. The connection latency shall increase with event handler execution latency. The reason I am saying this, is that while developing on BLE112/BLE113 and BL600SA (Manufacturers: Bluegiga and Laird respectively) I have keenly observed the events that are invoked after a DISCONNECT event. The DISCONNECT event is actually the last to receive. It first generates events for each of the service for which the Central had enabled Notifications/Indications. Though you don't have much a time-consuming operations for those events, that would definitely introduce some latency in execution of the actual disconnect event handler.


Fourth: Is it possible to send/receive data from outside a connection (others then advertisements)? Or is a connection mandatory to register for notifications/indications etc?

To directly answer your sub-question here, "is a connection mandatory to register for notifications/indications etc?". To receive indications and notifications you have to be connected.
Now, "Is it possible to send/receive data from outside a connection (others then advertisements)?", while we can say that it is possible to send some data into the advertisement packet, it comes with its own disadvantages. Your data is broadcasted in the open. Any Application can parse your advertisement packet and play with your data. So, to overcome that you will decide upon a custom protocol known only to firmware on Peripheral and the app on Central. That would again cost its overheads since you don't have the liberty to send chunk of data over BLE. Again, overheads for splitting data and sending it over? At the application side, parsing it using some sort of protocol that you have agreed upon. Not a good idea.


Fifth: What is the best solution to establish an encrypted communication? Usually pairing/bonding allows for encryption. But how get the passkeys exchanged.

First question, do you really need to implement it (on your own)? No you don't. BLE has a layer, Security Manager dedicated for Security and Data integrity. I hope you know that when we say that we can send maximum of 20 bytes in a packet over BLE, its not actually a packet of 20 bytes which is sent over. 20 Bytes is Payload length limit and not the actual Packet length limit. Starting from a Preamble, it has many a things that are put around your Payload. BLE implements 128-bit AES for security and encryption, without you asking for it. I think that is good enough. If you need more encryption, it can be done at customized level, again overheads?


Sixth: While receiving advertisements, How do I know if the device is interesting for me? Does I need to connect and discover services? Is there a mechanism to determine the device class or type?

The advertisement packet does it for you. On a broader picture, I can think of one reason to make advertisement packets so informative by means of GAP, is as following. In the GAP service, you have something called Appearance which decides what that device is. If I am an application developer and I am interested in getting connected over a specific kind of a device like say, Generic Clock, I can do that using this Appearance value (256 for Generic Clock) set.

\$\endgroup\$
2
\$\begingroup\$

How does the Peripheral receives the request. Is the antenna in receiving mode, while sending advertisements? If so, is this receiving mode always on, reacting to any connection request (even without sending advertisements)?

Advertising, scanning and establishing connection all happens in the Link Layer. There are three advertisement channels in BLE. The advertiser will send advertisements on all three channels. The scanner will check these channels for advertisements and reply with a connection request if needed. The advertiser is sending advertisements and checking for connection requests from the scanner at the same time.

Depending on the GAP role (advertiser, scanner) the device will react to advertisements/connection requests.

Something about your questions:

Third: As soon as connection is lost unintentionally both roles will go in disconnect state. It depends on your application what should happen after that (reconnection?). When a connection is properly terminated (by sending a disconnect message), the connection is lost. One advantage of BLE is that a connection can be re-established very fast from scratch because it requires fewer messages to establish a connection (compared to BT Classic).

Fourth: It is possible to send some data with the advertisement message or send data as a response to a scan request.

Sixth: Advertisements contain an advertiser address and other information about the device which is sending the advertisements (name, address, which profiles are enabled). With this information you can determine if a device is interesting for you.

\$\endgroup\$
0
\$\begingroup\$

It looks I have to read the full BLUETOOTH SPECIFICATION Version 4.1 [Vol 0].

Well, I try to further investigate my questions with the help of the specification. So this answer will be improved over time.

To the questions:

First:

While the peripheral is in advertising mode it sends advertisement packets at some interval. Between these intervals it will scan the advertisement channels for SCAN_REQ or CONNECTION_REQ packets.

See page 2529, paragraph 2:

The Link Layer shall listen on the same advertising channel index for requests from scanners or initiators.

In the idle/standby state nothing is mentioned about scanning or listening for anything. That implies: Advertisements (and so a scanning phase in this advertisement stage) are necessary in order to establish a connection.

Second:

This should also be answered by the First question. An advertisement procedure is mandatory in order to connect.

Third:

To reconnect to a lost device a advertisment/scanning phase must be entered. So it is up to the central/peripheral to adjust the parameters for scanning and advertisement (interval, duration).

\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.