Bluetooth® Low Energy Packet Types


The Bluetooth® Low Energy (BLE) Link Layer has only one packet format used for both advertising channel packets and data channel packets:

packet-format-top-level.png
​

BLE packet Protocol Data Unit (PDU) size in specification v4.0 and v4.1 is 2-39 bytes.

To see where/how advertising and data channel packets are used in BLE communications, please visit the Discovery and Connections pages.

Advertising Channel PDUs

Advertising channel PDUs serve two purposes:

  • Broadcast data for applications that do not require a full connection.
  • Discover Slaves and connect to them.
adv-channel-pdu.png

Advertising Channel PDU Types

There are seven advertising channel PDU types, each having a different payload format and function:

  • Advertising PDUs
    • ADV_IND, ADV_DIRECT_IND, ADV_NONCONN_IND, ADV_SCAN_IND
  • Scanning PDUs
    • SCAN_REQ, SCAN_RSP
  • Initiating PDUs
    • CONNECT_REQ
​

ADV_IND, ADV_NONCONN_IND, ADV_SCAN_IND packets are used for broadcasting data in broadcast applications (e.g., Beacons)

ADV Packet Type Type of Advertising Supported
ADV_IND Connectable Undirected Advertising
ADV_DIRECT_IND Connectable Directed Advertising
ADV_NONCONN_IND Non-Connectable Undirected Advertising
ADV_SCAN_IND Scannable Undirected Advertising

ADV_IND Packet

This packet type supports connectable, undirected advertising and is used when a Slave/Peripheral device is powered up for the first time (i.e. has never connected with a Master) and is looking to connect with any node (it's promiscuous). This typically represents a factory default state.

adv-ind-packet.png

The payload consists of:

Common AD Data Types

Typically, ADV_IND packets contain the Complete Local Name (Type id 0x09) and 128-bit Service UUID (Type id 0x07).

​

A single 128-bit UUID consumes 16/29 of the bytes available in the ADV_IND payload. If you need to send more advertising data, consider initializing and enabling SCAN_RSP packets in your application.

ADV_DIRECT_IND Packet

This packet type supports connectable, directed advertising and would typically be used after a Slave/Peripheral has connected with a Master/Central. It is not looking to be discovered, rather, it already has the device address of its peer and wishes to re-connect quickly to a specific Master/Central device.

​

Only one Master/Central device (with matching MAC address) will receive/pass ADV_IND_DIRECT messages to its application layer.

​

The advertising interval is based on whether Low Duty Cycle or High Duty Cycle mode is used:

  • Low Duty Cycle Directed Advertising
    • The time between the start of two consecutive ADV_DIRECT_PDUs is <= 10 ms.
  • High Duty Cycle Directed Advertising
    • The time between the start of two consecutive ADV_DIRECT_PDUs is <= 3.75 ms.


The Link Layer exits this advertising state after 1.28 s. If no Central responds, the Advertiser will need to re-trigger this advertising mode.

Refer to the BLE 4.2 Specification, Vol 6, Part B, Section 4.4.2.4.

adv-direct-ind-packet.png

The payload consists of:

​

The Master/Central device must be in the SCANNING state to detect ADV_DIRECT_IND advertising packets.

Data Channel PDUs

Once in a connection, devices can send data to one another. This is achieved by exchanging data channel PDUs during regularly scheduled connection events. Due to protocol overhead of the higher layers, the maximum data payload is 246 bytes as shown:

data-channel-pdu.png

Data Channel PDU Field ID Full Name
PDU He Data PDU Header
MIC Message Integrity Check
L2 He L2CAP Header
Op ATT Operation Code
Par/Pay ATT Parameters & Payload
​

In BLE v4.0 and v4.1, the maximum ATT Parameter+Payload size is 22 bytes.

  Return to Top

© 2024 Microchip Technology, Inc.
Notice: ARM and Cortex are the registered trademarks of ARM Limited in the EU and other countries.
Information contained on this site regarding device applications and the like is provided only for your convenience and may be superseded by updates. It is your responsibility to ensure that your application meets with your specifications. MICROCHIP MAKES NO REPRESENTATIONS OR WARRANTIES OF ANY KIND WHETHER EXPRESS OR IMPLIED, WRITTEN OR ORAL, STATUTORY OR OTHERWISE, RELATED TO THE INFORMATION, INCLUDING BUT NOT LIMITED TO ITS CONDITION, QUALITY, PERFORMANCE, MERCHANTABILITY OR FITNESS FOR PURPOSE. Microchip disclaims all liability arising from this information and its use. Use of Microchip devices in life support and/or safety applications is entirely at the buyer's risk, and the buyer agrees to defend, indemnify and hold harmless Microchip from any and all damages, claims, suits, or expenses resulting from such use. No licenses are conveyed, implicitly or otherwise, under any Microchip intellectual property rights.