Bluetooth LE offers various methods and features that enable devices to communicate with each other, meeting different use cases and application needs.

In this topic, we will explore these methods and features, because minimizing power consumption requires selecting the right Bluetooth communication method and parameters for each specific use case. In many cases, communication does not always require a Bluetooth connection to be established, as we will see in this topic.

Communication methods overview

Bluetooth LE communication method

1 – Connectionless communication

Method 1.a – Broadcasting using legacy advertising (one-many)

A key consideration in the design of a Bluetooth LE device is whether it should support connections or operate exclusively through advertising (broadcasting). While the answer is sometimes straightforward, in many cases it requires a deeper analysis of the application’s needs.

This choice is not necessarily all-or-nothing. A large class of devices can function perfectly well by simply advertising data, without ever needing connections. Devices that only need to broadcast information, without receiving commands or configuration, can take advantage of this method. For example, simple sensors, asset tracking tags, and similar products are prime examples, as an advertising-only operation enables extremely low power consumption.

This method uses legacy Bluetooth advertising. Legacy advertisements can carry up to 31 bytes of data and are transmitted at configurable intervals. The two main types of advertisements are connectable (leads to a connection) and non-connectable advertisement. You can also enable scan request to extend the payload with additional 31 bytes at the cost of turning on RX and increased radio time

Power-saving tips

For optimal power efficiency, advertising intervals should be as long as the application allows, and the device should remain in deep sleep between transmissions. Non-connectable advertising consumes less power than connectable modes, and additional savings can be achieved by disabling scan requests (TX only) and by using only the transmit power necessary to cover the intended area(This is covered in-depth in Lesson 4).

Method 1.b – Broadcasting using extended advertising (one-many)

Similar to Method 1.a use cases where the device wants to broadcast information but requires larger payloads, Bluetooth LE supports extended advertising with payloads up to 1650 bytes to broadcast more data.

Extended advertising was introduced with Bluetooth 5. This feature allows extended advertising packets to be transmitted on the data channels (channels 0–36), thereby reducing congestion on the traditional advertising channels (channels 37, 38, and 39). In this method, the data channels are referred to as secondary advertising channels, while the traditional advertising channels are known as primary advertising channels.

An extended advertising begins with a packet sent on a primary advertising channel. This initial packet does not contain the full advertising data; instead, it indicates the timing and the specific secondary advertising channel on which the actual data will be transmitted. Because traffic on the secondary channels can be efficiently distributed, the 31-byte payload limitation no longer applies. Each packet may carry up to 255 bytes of payload and can be extended through a chain of additional packets. In total, an extended advertising chain can carry up to 1650 bytes of data, enabling the broadcast of substantially larger data sets. If even more capacity is required, multiple advertising sets can be used simultaneously, or the advertising data can be updated periodically.

Power-saving tips

Different PHYs with varying data rates can be used on secondary advertising channels. When guaranteed to be supported by the scanner side, the 2M PHY is preferred, as it doubles the data rate compared to the 1M PHY and significantly reduces power consumption by shortening radio time. Power-saving tips of basic advertising apply here also. We will also take a deeper look at this in Lesson 4

Method 1.c – Broadcasting using periodic advertising

The primary use case here is to broadcast data where both the broadcaster and observer(scanner) need to minimize energy consumption. Periodic advertising builds on top of extended advertising and add sync capabilities between the scanner and the broadcaster.

The scanners in method 1.a. and 1.b need to have sufficient power supply to continuously scan because there is no time synchronization between the scanner and the broadcaster. In addition, there is a 0-10 ms random delay added to the advertising interval to avoid timing collision between advertisers on the primary advertising channel. This requires a large RX window on the scanner and, as a result, draws more current consumption.

Different from method 1.a and 1.b, periodic advertising does regular and precise timing broadcasting. There is a time synchronization between the scanner and the advertiser. The 0-10ms random delay of legacy advertising and extended advertising is not used in periodic advertising. Because of this, the scanner only needs to listen for a very short, predictable period of time. It is possible to build a large one-to-many low-power network with periodic advertising, for example, data broadcasting, direction finding, IoT networks, etc. However, what is not possible with periodic advertising is that the low-power scanners can only receive data and are not able to send data back to the advertiser.

Power-saving tips

Power-saving tips of extended advertising and basic advertising apply.

Method 1.d- Broadcasting using Periodic Advertising with Responses (PAwR) – (one-many)

The primary use case here is when you have many devices (100s or 1000s) that have very strict power efficiency requirements that need to communicate to one single (usually mains-powered) device (gateway/access point). An example of this is Electronic Shelf Labels (ESL), sensor networks, warehouse management, etc.

PAwR supports the bidirectional exchange of application data using connectionless communication. It offers a more scalable way to create a one-to-many topology capable of bidirectional application data communication than Bluetooth LE connections. It is common for around 20 concurrent Bluetooth LE connections to be supported by a Central device, whereas bidirectional communication with thousands of devices is possible using PAwR. Keep in mind the throughput is limited compared to Bluetooth LE connections.

PAwR operates on an interval called periodic advertising interval. This occurs precisely at the exact interval with no random delay. At each PAwR event, there will be multiple subevents. This is different from the other types of Bluetooth LE advertising, where there is only one periodic advertising packet per event. Importantly, a scanner, when synced to PAwR, will not listen to all subevents but only select subevent(s) that it is subscribed/synced to. Multiple scanners can be subscribed to the same subevent. This means a scanner can subscribe to multiple subevents. There can be up to 128 subevents per advertising event.

PAwR also allows an advertiser to initiate a Bluetooth LE connection with a selected scanner when higher data throughput is needed (e.g., transferring large images to ESL labels). Unlike standard LE connections, the advertiser controls when and with whom the connection is established, reducing channel congestion and avoiding interference with ongoing PAwR activity.

Finally, PAwR supports ultra-low-power operation with relatively low latency. Scanners can achieve multi-year coin-cell battery life while maintaining latency tied to the periodic advertising interval, comparable to the power usage of a standard Bluetooth LE connection.

Power-saving tips 

PAwR is similar to periodic advertising, except scanners can now communicate back to the advertiser (gateway/access point). How scanners are assigned to PAwR subevents strongly influences the network timing configuration and how often scanners need to wake up for PAwR activity. Since this depends on the application’s requirements, the optimal setup is use-case specific. As a general rule, it is always recommended to listen only to assigned subevents. Do not wake up for all subevents, and only send responses when needed, using only the assigned slot(s), and keeping response payloads as small as possible to reduce radio time and only the necessary TX power to reach the gateway/access point.

Method 1.e – Broadcasting using Encrypted Advertising (one-one or one-many)

Encryption securely encodes information so unauthorized parties cannot access the original data. It ensures confidentiality against eavesdropping. Encrypted advertising could be used in situations where the confidentiality of the content of the advertising is important. This means that encrypted advertising can be used as a secure application data delivery mechanism in one-to-many or one-to-one topologies.

Another use of encrypted advertising is controlling a mains-powered device from a low-power broadcaster. Bluetooth LE is commonly used to control nearby devices such as lamps, smart ceiling fans, or garage doors. Typically, this is done by creating a Bluetooth LE connection between a battery-powered controller and a mains-powered device (controlled device), and then sending commands over that connection. However, creating and maintaining a connection consumes power on the battery-powered controller and there are use cases where it can be avoided.

For a battery-powered controller, a more power-efficient method is to send commands using encrypted advertising instead of maintaining a connection.

• The controlled device (for example, a lamp) has a constant power supply and continuously scans for advertisements.
• The two devices establish a Bluetooth connection only once during setup to exchange an encryption key.
• After setup, the controller stays in sleep mode and sends a short encrypted advertisement only when a button is pressed.
• Because the controlled device is always scanning, it receives the command immediately, resulting in very low latency and minimal power consumption on the controller (longer battery life for the controller).

Encrypted Advertising can be used with extended advertising, periodic advertising, or PAwR.

Power-saving tips

Power-saving tips of periodic and extended advertising apply.

Method 1.f Broadcasting using Broadcast Isochronous Streams (BIS)

BIS enables one-to-many audio broadcasting using an isochronous channels. A single broadcaster transmits data stream (usually audio streams) to an unlimited number of receivers without requiring pairing or connections. It uses extended and periodic advertising for discovery and synchronization, with audio data delivered over isochronous channels at fixed intervals (typically 4-10ms for Audio). BIS is ideal for public audio sharing scenarios such as airport announcements, silent discos, assistive listening in theaters, tour guide systems, and personal audio sharing where multiple people want to listen to the same audio source simultaneously. The unidirectional, broadcast nature makes it power-efficient for applications where low latency and synchronized playback across multiple devices are more important than bidirectional communication or guaranteed delivery.

Usually, the BIS broadcaster is a main-powered device or uses large batteries (e.g., a smartphone) due to the power requirements of broadcasting audio stream. BISes can be grouped into Broadcast Isochronous Groups (BIG), where, for example, a BIG could contain two BISes: one for the right earbud and one for the left earbud.

On the other hand, BIS receivers can be small battery-powered devices (for example, an earbud or a hearing aid device)

Power-saving tips

Delegate scanning to a Broadcast Assistant. Offload the power-intensive task of searching for available Broadcast Sources to a separate device, such as a smartphone or dedicated remote control.

2 – Connection-oriented communication

Now let’s discuss connection-oriented communication in Bluetooth LE

Method 2.a – Bluetooth LE Connections

This is the most common communication method in Bluetooth LE. It provides a bidirectional communication channel between two devices or more with higher data bandwidth capabilities than broadcasting. It is technically referred to as Bluetooth LE Asynchronous Connection-oriented Logical Transport – ACL Connections.

Typical use cases include collecting data from a low-power device and controlling a device in near real-time.

In an ACL connection, the peripheral (usually a low-power device) advertises and listens for connection requests, while the central initiates the connection and decides the timing. Both devices exchange packets at connection events that have defined intervals, sending empty packets if no data is available to maintain the link. Connections are reliable, support security features, and can be configured to be energy-efficient because devices can sleep between connection events. A central device can connect to several peripheral devices simultaneously (up to 20*), and a peripheral device can also connect to multiple central devices simultaneously (up to 20*).

Power-saving tips

We will dive into these tips in Lesson 4, however, here is a high level overview of the connection parameters and features that have high impact on power consumption.

• Peripheral advertising interval: The advertising interval for a peripheral significantly impacts its power consumption. A short advertising interval causes unnecessary high power consumption, while a long interval increases discovery time, affecting user experience. Carefully choose the advertising interval that matches your application requirements. Tips covered in Method 1.a apply here, do not include unnecessary data in the advertising, and use only the transmit power necessary to cover the intended area.
  • Trigger advertising only when necessary. For example, if the product has a user interface (for example, a button), start advertising on button press and stop after a timeout. Alternatively, consider advertising profiles, an example is to advertise at 20 ms interval for the first 30 seconds after trigger, then switch to a longer interval if not connected.
• Connection interval: The periodic time interval when two connected devices turn on their radio and exchange data. Short intervals (7.5-30 ms): Higher power consumption, lower latency, better throughput. Long intervals (1-4 seconds): Lower power consumption, higher latency, potential throughput reduction. Keep in mind that its possible to go lower than 7.5 ms through the recently introduced Shorter Connection Intervals (SCI) feature in Bluetooth core specification 6.2.
• Peripheral latency: Number of consecutive connection events the peripheral can skip without responding if it has no data to send. As discussed earlier, both devices must wake up at connection events (connection interval) and send empty packets if no application data is available to maintain the connection. The good news is that on the peripheral side this can be mitigated through peripheral latency to optimize for low power consumption. Configuring the peripheral latency to N allows the peripheral device to skip up to N connection intervals and transmit a response to the central device once every (N+1) connection intervals. This setting is optional, the peripheral may still choose to respond sooner if needed. As a result, the peripheral can balance low latency with reduced energy consumption.

Keep in mind that both connection interval and peripheral latency can be changed dynamically to meet the device’s requirements in terms of data throughput and power. A high duty cycle connection achieves higher data throughput at the expense of increased power consumption, while a low duty cycle connection saves power at the expense of data throughput. This is done through what is knows as connection parameter updates procedure. A connection parameter update procedure can be initiated by the peripheral, but the central always has the final say in the negotiated parameters. The procedure has a latency of at least six connection events.

• PHY Mode Selection: the base of the Bluetooth LE stack is the physical layer (PHY), which defines the radio’s modulation and coding schemes. These settings determine data rate, range, and power consumption. The 2M PHY is the best for power efficiency (Transmits faster → returns to sleep quicker). However 2M PHY has slightly less range than 1M PHY. 1M PHY – gives you balanced throughput, power consumption and it has the highest compatibility with old devices. Coded PHY provides longer range, lower throughput, and higher power consumption.
• Data Length Extension (DLE) and ATT MTU Optimization: these two work together to maximize power efficiency during data transmission by reducing protocol overhead (headers) sent over the air. DLE extends the link layer packet size from 27 to 251 bytes, while increasing ATT MTU from the default 23 bytes to 247 bytes (244 bytes usable payload) allows larger application-layer messages. When combined, these features eliminate packet segmentation and dramatically reduce protocol overhead. Fewer packets mean fewer headers and shorter radio-on time. This synergy enables sending complete messages in single packets rather than fragmenting across multiple connection events, resulting in significant power savings and higher throughput. The maximum usable payload of 244 bytes accounts for the 4-byte L2CAP header and 3-byte ATT header within the 251-byte DLE packet.
• Connection Subrating: Connection Subrating enables faster switching between low and high duty cycles of Bluetooth LE connections compared to the traditional connection parameter update procedure. It allows quicker transitions from high to low duty cycles, enabling devices to return to power-saving states faster. Subrated connections also handle variable packet rates or bursty traffic more efficiently
• LE Power Control: This feature enables devices to dynamically adjust their transmission power. Applications can configure settings, after which the local and remote devices exchange information, including local measurements like path loss, and request changes to the remote device’s transmission power. Adapting transmission power to local conditions can, in some cases, reduces power consumption.

Method 2.b L2CAP Connection Oriented Channels (L2CAP CoC)

CoC are specific logical links established over L2CAP that use a credit-based flow control mechanism. In this method, one channel endpoint grants “credits” to the peer, which represents the number of packets the peer is allowed to send. This ensures that data is only transmitted when the receiving end has the resources to process it. Keep in mind that an ACL connection is required to grant a channel.

With CoC, data is transferred directly to the application without the overhead of the GATT (Generic Attribute Profile) layer. It is ideal for device-to-device applications requiring high-throughput streaming, bulk data transfers, or custom protocols outside GATT’s request-response model. Typical scenarios include firmware updates, file transfers, sensor data logging, and proprietary protocol implementations where ATT overhead is undesirable.

Power-saving tips

Consider using L2CAP CoC for applications that require transferring large amounts of data, which is inherently not power-friendly operation. However, CoC eliminates the overhead of GATT. Both iOS and Android support L2CAP CoC, but it is less common than GATT. If your setup is a device-to-device (without mobile device) communication with large amount of data, do consider using CoC to remove the overhead of GATT when transferring large amount of data.

Method 2.c Connected Isochronous Stream (CIS)

The primary use case for CIS is time-sensitive audio applications requiring synchronized audio on multiple devices, such as left and right earbuds or an audio system with multiple devices that requires all devices to be synchronized. With CIS, since it is connection-oriented, it is possible to have bidirectional audio with predictable latency (for example, voice calls)

Each CIS has an associated ACL connection (Method 2.1). The ACL link must always be present to set up and control the CIS. Multiple CISes between an Initiator and an Acceptor can share the same ACL. If the ACL connection is lost, all CISes associated with it terminate.

Method 3 Bluetooth Mesh

Bluetooth Mesh is a networking topology that enables many-to-many (m:m) device communications over Bluetooth LE. The primary use case of Bluetooth Mesh is smart lighting systems, and building automation.

The protocol defines multiple nodes roles (relay, proxy, friend, low power) and uses managed flooding to relay messages to extend the range of the network. Most node types in Mesh require continuous scanning and/or retransmitting, making them power-intensive and dependent on mains power(or very large battery). The exception here is low power nodes where they rely on a friend node to store their messages a wake periodically to poll their friend node for messages