Because BLE 4.0 does not support scatternet, the following rules apply to every BLE 4.0 device:

Note: BLE 4.1 relaxed rule 3 and allowed multi-piconet participation. But the 4.0 restrictions are what the current section covers.

Standby is where the link layer lives when it is not actively doing anything. No packets are sent and no packets are received. The radio is effectively idle. This is the lowest-power non-sleeping state for the link layer.

Two important rules about Standby:

• From Standby, you can go to: Advertising, Scanning, or Initiating — but not directly to Connection. To get to Connection you must go through Advertising (to be connected to as Slave) or Initiating (to connect as Master).
• Any state can return to Standby. This makes Standby a universal hub in the state machine — to change between any two non-Standby states (e.g. Scanning to Initiating), the link layer passes through Standby as an intermediate step.

This design choice — routing all transitions through Standby — keeps the state machine simple. Without Standby as a hub, you would need direct transitions between every pair of states, which creates many more combinations to implement and test.

In the Advertising state, the link layer broadcasts advertising PDUs on the advertising channels. The device in this state is called an Advertiser. The host tells the link layer which channels to use — it can use all three (37, 38, 39) or just a subset.

There are four types of advertising events, each suited to a different scenario. The table below shows which PDU each type uses and what responses it accepts from remote devices:

This is the most general advertising type. The device broadcasts to everyone within range and is willing to accept a connection from any device that responds. Two things a remote device can do after receiving ADV_IND:

• If it is in Scanning state — it may send a SCAN_REQ to ask for more data, and then decide whether to connect.
• If it is in Initiating state — it may send a CONNECT_REQ to start a connection right away.

It can also do the first step and then the second — query for more information first, then decide to connect. Or just receive the ADV_IND and ignore it without any response.

Payload fields:

/* Setting up connectable undirected advertising (ADV_IND) with BlueZ */
/* This is the default mode for most sensors */

#include <bluetooth/hci.h>
#include <bluetooth/hci_lib.h>

int start_connectable_advertising(int sock)
{
    le_set_advertising_parameters_cp params;
    memset(&params, 0, sizeof(params));

    params.min_interval = htobs(0x00A0); /* 100 ms */
    params.max_interval = htobs(0x00A0);
    params.advtype      = 0x00;  /* ADV_IND = connectable undirected */
    params.own_bdaddr_type = 0x00; /* use public address */
    params.chan_map     = 0x07;  /* use channels 37, 38, and 39 */
    params.filter_policy = 0x00; /* accept all scan/connect requests */

    return hci_send_cmd(sock, OGF_LE_CTL,
                        OCF_LE_SET_ADVERTISING_PARAMETERS,
                        LE_SET_ADVERTISING_PARAMETERS_CP_SIZE,
                        &params);
}

This type is used when the Advertiser wants to reconnect to one specific known device. Unlike ADV_IND where any device in range can connect, ADV_DIRECT_IND names a specific target. Only that one named device is allowed to respond with a CONNECT_REQ.

The key difference from connectable undirected: no SCAN_REQ is permitted. The session goes straight to connection, no back-and-forth querying. This makes the reconnection process very fast.

Payload fields: