In a couple of previous posts (here and here), we covered the basics of Bluetooth Low Energy (BLE) advertising and advertisement packets.
In this post, we’ll go into more depth on Bluetooth advertisements and specifically the advertising packet payload and the maximum amount of data you can send out in the payload.
Bluetooth beacons are the most prominent devices that take full advantage of Bluetooth advertising packets. This is due to the reason that most beacons stay in the advertising state throughout their lifetime (do not allow connections), so they rely completely on advertising for relaying the relevant information to the scanning devices.
TLDR: want to skip right to the answer to the question: “How many bytes can I send in a Bluetooth advertising packet?” Click Here!
Bluetooth Advertising Packet Format
To fully understand how much data we can advertise as BLE application developers, we need to understand the format of the advertising packet format, but before we dive into the advertising packet format, let’s cover an important feature of Bluetooth Low Energy: the different PHY options available.
The Three PHYs
In Bluetooth Low Energy (BLE), we have two main packet formats (which apply to both advertising and data packets – which are exchanged during a connection). They are the Coded PHY packet format and the Uncoded PHYs packet format.
The Uncoded PHY includes the original LE 1M PHY (which is the default PHY that has existed since the first version of BLE in version 4.0 of the Bluetooth specification) and the optional LE 2M PHY (which was introduced in version 5.0 of the Bluetooth specification providing the option to double the data throughput rate).
The LE Coded PHY was introduced in version 5.0 of the Bluetooth specification. It is intended to be used for:
- Long-range applications (achieving up to 1+ kilometer line-of-sight)
- or for achieving more robust communication through obstacles, walls, and noisy RF environments
The LE 1M PHY utilizes a 1 megasymbol/second modulation scheme where each symbol represents 1 bit. The resulting raw transmission rate, in this case, is 1 Mbps.
The LE 2M PHY utilizes a 2 megasymbol/second modulation scheme where also each symbol represents 1 bit. The resulting raw transmission rate, in this case, is 2 Mbps.
The LE Coded PHY utilizes a 1 megasymbol/second modulation scheme but differs from the other two PHYs in that it utilizes either: 2 symbols per bit (S=2), or 8 symbols per bit (S=8). This “redundancy” is utilized by an algorithm that can allow the receiver to recover data in the case of corruption in the received packets. The resulting raw transmission rate, in this case, is 500 Kbps (in the case of S=2) and 125 Kbps (in the case of S=8).
In this post, we will focus on the Uncoded PHY packets since they are the most common. For more detailed information on the LE Coded PHY, see my previous post on the subject.
Advertising PDU Types
For Uncoded PHY packets, there are two main types of advertising PDUs (Protocol Data Unit) that can be utilized: Legacy Advertising PDUs and Extended Advertising PDUs.
Before we dive into the different types of legacy and extended advertising PDUs, it’s important to note that they share the same packet format:
The PDU portion is the field that contains the payload which you can utilize for sending out data in the advertising packet.
Legacy Advertising Packets
The legacy advertising PDUs are:
- ADV_IND:
This is used for connectable and scannable undirected advertising events.
So when advertising this type, the advertiser is telling the scanner that they can connect to the device, they can also send a scan request which will trigger a scan response from the advertiser, and it is “undirected”, meaning any scanner will be able to receive this advertising.
This is probably the most commonly used advertising PDU (especially for connectable devices).
It allows for up to 31 bytes of advertising data in the main packet payload.
It also allows an additional 31 bytes of advertising data in the scan response packet payload. - ADV_DIRECT_IND:
This is used for directing advertising to a specific target scanner.
It is less common.
It does not allow any advertising data in the packet payload. - ADV_NONCONN_IND:
This is used for nonconnectable and nonscannable advertising events.
When using this type, the advertiser is telling the scanner that it is nonconnectable and nonscannable (does not respond to scan requests).
It allows for up to 31 bytes of advertising data in the packet payload. - ADV_SCAN_IND:
This is used for nonconnectable but scannable advertising events.
When using this type, the advertiser responds to scan requests, but it does not allow connections from scanner devices.
It allows for up to 31 bytes of advertising data in the packet payload.
It also allows an additional 31 bytes of advertising data in the scan response packet payload.
Here’s a look at what a legacy advertising PDU format looks like:
The legacy advertising PDUs are sent only on the primary advertising channels (37, 38, and 39). This means they are supported by all Bluetooth Low Energy scanners.
You can refer to my previous post on Bluetooth Advertisements to learn more about the different types of advertising channels.
Extended Advertising Packets
The extended advertising PDUs are:
- ADV_EXT_IND:
This type of PDU is the only extended advertising PDU that is sent on the primary advertising channels (37, 38, and 39).
They do not contain any advertising data in their payload and they act as a simple relayer of information to the scanner on where to find the advertising packets that are sent on the secondary advertising channels (0-36).
Depending on the information contained within the header portion of the PDU, there are different even types (similar to those described in the legacy advertising types) such as connectable vs. nonconnectable, scannable vs. nonscannable, directed vs. undirected, etc. - AUX_ADV_IND:
This behaves as the primary type that you would use for sending out advertising data (specifically on the secondary advertising channels).
For the scanner to be able to locate and receive this packet, it will have to first discover and receive the ADV_EXT_IND packet that points to this one.
Depending on the type of event (defined in the header in both the ADV_EXT_IND packet and this one), you will be able to include advertising data in this packet.
This type allows up to 254 bytes of advertising data in the packet payload. - AUX_SYNC_IND:
This type is used for implementing a feature called Periodic Advertising, which allows a scanner to (eventually) sync to a chain of advertising packets (sent on the secondary advertising channels) that are sent out on a regular and deterministic point in time.
This type is used to relay to the scanner the information needed to locate the periodic advertising packets that actually contain the data (these are the AUX_CHAIN_IND packets described in the next bullet point).
Examples of applications that utilize this are for continuously sending out sensor data that potentially changes periodically to multiple scanners.
It is also one of the main features utilized in the recent LE Audio standard.
It allows up to 254 bytes of advertising data in the packet payload. - AUX_CHAIN_IND:
This type contains the Periodic Advertising data that the ADV_EXT_IND -> AUX_ADV_IND -> AUX_SYNC_IND point to.
It allows up to 254 bytes of advertising data in the packet payload.
Here’s a look at what an extended advertising PDU format looks like:
Notice that extended advertising packets utilize just two PDU types (ADV_EXT_IND + AUX_ADV_IND) to support the many types of advertising events by utilizing a field included in the PDU header.
Note that extended advertising is an optional feature (introduced in Bluetooth 5.0). So, they are not necessarily supported by any Bluetooth Low Energy scanner, even if it is listed to support Bluetooth 5.0. In fact, as of the writing of this post, most BLE-enabled smartphones do not support them.
Advertising Packet Payload Format
Whether you are using legacy or extended advertising packets, the format of the payload is the same.
It is structured in the following manner:
LTV stands for “Length-Type-Value”. You can have as many of these as can fit within an advertising packet payload.
The Length and Type fields are mandatory and each takes up one byte.
- Length: This defines the length of the Type + Value fields.
- Type: The different types are defined in the Core Specification Supplement document which you can download here. Examples include Device Name, Service UUID, Tx Power Level, etc.
- Value: This includes the actual data that is meaningful to the scanner. For example, it can be the actual device name, the sensor reading, etc.
The Maximum Length of Data you can Include in a BLE Advertising Packet
So, we can already see that if we want to follow the Bluetooth specification, we will be losing two bytes to Length + Type. This leaves us with either 31 – 2 = 29 bytes (in the case of legacy advertising packets) or 254 – 2 = 252 bytes (in the case of extended advertising packets).
If you are looking to maximize the amount of payload that you want to include in the advertising packet then you can:
- Use the Manufacturer Specific Data type, which is the only type that allows you to send custom data (for generic use) per the Bluetooth specification. Unfortunately, this requires the use of an additional piece of data called Company ID which takes up an additional 2 bytes (you can find all assigned Company IDs here). Using this will allow any generic BLE scanner to discover and parse the data.
- Use the remaining 29 or 252 bytes as raw data, but rely on a custom BLE scanner (that maybe you build) to discover and parse this non-standard data.
- You can use a “scannable” advertising PDU to potentially double the amount of advertising data that you send out.
- Utilize a data compression algorithm to compress the data you include in the advertising packet, and decompress it on the scanner side.
So, in summary, here’s the answer to this very common question:
- If you are using legacy advertising packets, you can include up to 27 bytes of actual data (using the Manufacturer Specific Data type) or 29 bytes of actual data (using a custom non-standard advertising data type).
- If you are using the extended advertising packets, you can include up to 250 bytes of actual data (using the Manufacturer Specific Data type) or 252 bytes of actual data (using a custom non-standard advertising data type).
But again, consider utilizing scan responses and/or data compression to increase the size of user data that you want to include in the advertising data packets.
Note: keep in mind that some BLE scanners will require you to include other advertising data types (such as Flags) in your advertising data, so this will impact the total amount of user data that you can truly advertise.
I hope you found this post useful and that it provided the information needed to really understand the background behind the answer to this common question about BLE advertising data capacity.
