Designing BLE Advertising Packets

Multiple Bluetooth Low Energy (LE) Chipsets


In our previous guide, we went over BLE advertising and how advertising works in general. But we’ve still gotten many questions about how to do the Bluetooth LE advertising right for many use cases. This guide will cover creating BLE advertising packet in depth, to help you create better products.


BLE Advertising and scan response packets serve primarily to allow a Central device to find a Peripheral. The way to do this properly depends greatly on the product, but we’ll cover a lot of techniques and rules of thumb we’ve used at Argenox to help develop it, and they've worked out great for millions of devices.

It's important to know that aside from connecting, advertising packets also allow a product to communicate information in status. There's limitations in the amount of data and some other considerations like power consumption and security, but many applications that use connections don't necessarily need them and would be better off done mostly with smart advertising.

We’re not going to cover beacons here specifically because Beacons, both iBeacons, EddyStone and others have a fixed structure already defined and other articles already cover them.

Advertising and Power Consumption

Perhaps the first thing to take into account when building a BLE advertising scheme is that accepting Scan Response packet adds extra power consumption to the peripheral. Also, longer advertising packets with more bytes of data means extra power consumption since the radio has to stay on the air longer to transmit. How relevant this is depends on your use case, battery, etc.

For use cases where operational lifetime is extreme or the battery very small and advertising is significant part of the lifetime, optimizing these aspects can be critical. But in reality, most devices don't require such an approach. The different is usually a few uA of current, but can be more or less depending on output power.

We mention all of this because the discussion below needs to be taken into account as far as power consumption.

Things to Consider

We mentioned Power consumption, but there are plenty of factors to consider when building a Bluetooth LE advertising scheme. Here's a few you should keep in mind:

  • Limited Space - unless you're using advertising length extensions , the number of bytes available in advertising packets. Using length extensions also can cause issues with backwards compatibility
  • As device name changes, it may take more/less space and cause issues. For example, a Complete local name that is "Sensor 9032" may work initially. But, later the name may get shortened to "Sensor 90". At this point, one may run into issues matching the device if both Sensor 9032 and Sensor 90 are nearby.
  • The Device Information Service (DIS) can provide more device information than just a name

Advertising Elements

The elements that can be placed in each BLE advertising and scan response packets are defined by the Bluetooth Specification. Below we cover the most important and common ones (we include all the rest for reference in case it fits your use case)

Element Description
16BIT_SERVICE_UUID_MORE_AVAILABLE Provides 16-bit services and indicates more 16-bit services are available
16BIT_SERVICE_UUID_COMPLETE Provides a complete list of 16-bit service
32BIT_SERVICE_UUID_MORE_AVAILABLE Provides 32-bit services and indicates more 32-bit services are available
32BIT_SERVICE_UUID_COMPLETE Provides a complete list of 32-bit service
128BIT_SERVICE_UUID_MORE_AVAILABLE Provides 128-bit services and indicates more 128-bit services are available in the device
128BIT_SERVICE_UUID_COMPLETE Provides a complete list of 128-bit service
SHORT_LOCAL_NAME Shortened Local (Device) Name
COMPLETE_LOCAL_NAME Complete Local (Device) Name
TX_POWER_LEVEL Device TX Output Power
CLASS_OF_DEVICE Class of Device
SERVICE_DATA Allows you to include data that belongs to a standard Bluetooth Service
ADVERTISING_INTERVAL Provides details of the advertising interval used by the device
Indoor Positioning Used by the Indoor positioning profile
Channel Map Update Indication Used by the Mesh Profile for provisioning
PB-ADV Used by the Mesh Profile for provisioning
Mesh Message Used by the Mesh Profile
Mesh Beacon Used by the Mesh Profile
MANUFACTURER_SPECIFIC_DATA Manufacturer Specific data bytes


One of the most common items included by developers in their products is the Complete local name, or, if no space is available, the shortened form. This local name is then used for a wide range of tasks. The device name is useful for humans to find the device during development. But, for product production use, using the device name is not the best approach:

  • Including the Device name takes significant space in the advertising packet
  • Scalability - As device name changes, it may take more/less space and cause other issue. For example, a Complete local name that is "Sensor 9032" may work initially. But, later the name may get shortened to "Sensor 90". At this point, one may run into issues matching the device if both Sensor 9032 and Sensor 90 are nearby.
  • The Device Information Service (DIS) can provide more device information than just a name

We recommend using the device name for debug only, in the scan response with low priority items and ideally remove it during production. There's little advantage in including a device name overall, and a better system can be designed without it.

In most cases, an app does not need a human friendly string to connect and neither does a gateway. The possibility of collision of strings is also possible. The same applies to custom BLE devices.


Same as COMPLETE_LOCAL_NAME, except the name is cut to fit inside the packet.


The TX Power level is useful in specific scenarios involving ranging and calibration or dynamic power control. if you need to know the TX power level of a device without connecting, you should use this element. But in practice, there's been little use for it aside from debug.


Whether you use this element or the 16BIT_SERVICE_UUID_COMPLETE variant depends only on whether you have more services. This element has the advantage of having the most compact unique representation of a UUID that you can give your device. But, there's a big catch. 16-bit UUIDs are all reserved by the Bluetooth SIG. If you remember services such as the Device Information Service, Battery Information Service, etc. These are all standard Bluetooth services and they all have 16-bit UUID. The other 96-bits of the UUID are the standard Bluetooth UUID bits.

If you decide you want to advertise just a 16-bit UUID due to power or other considerations, you will have to use a Bluetooth UUID or request a custom UUID for you. The Bluetooth SIG charges for these UUID. Without this, you're limited to the standard Bluetooth UUIDs, but these are of limited use: any device can advertise the same UUIDs and if your app or gateway are looking to connect to the device, it won't be able to identify it uniquely unless you use the unique 16-bit UUID. You can't get your product certified if you try to invent your own 16-bit UUID that was not assigned by the BT-SIG.

The main use of these UUIDs are for devices that provide standardized behavior. For example, any Weight Scale that uses standard the standard Weight Scale Service and advertises it should provide standard behavior. This could allow any app with the functionality to use it. The benefit is that your product can work in a large ecosystem of existing apps.

The 16-bit manufacturer UUID is assigned by the Bluetooth SIG and is available to any company. For example, Argenox has the company identifier 0x0240


This element and 32BIT_SERVICE_UUID_COMPLETE element are both similar to the 16-bit except that they use 32-bit. Like the 16-bit, the UUID has to be assigned by the Bluetooth SIG and has limited value. We have rarely seen this element being used since 16-bit UUIDs are still available from the BT-SIG.


This element and its related 128BIT_SERVICE_UUID_COMPLETE are perhaps some of the most useful UUID elements to use. The main reason is that they don't require any registration with the BT-SIG. You can use any 128-bit UUID and Random UUID generators will almost always guarantee uniqueness. The downside is of course that instead of using 2 bytes, you will need 16 bytes, which means additional power consumption and difficulty fitting more information in advertisements that don't have advertising length extensions.

In products we develop we have used 128-bit UUIDs significantly. Their flexibility allows unique identification of a device or multiple devices. We don't recommend using the UUID as a serial for the devices, though it is possible.

Central devices can easily filter devices based on the 128-bit UUID, and many implementations are low level firmware filtering, so that the power consumption on the Central device is reduced.


Manufacturer specific data is another very useful element to include in advertising. This field allows for custom data, which means endless possibilities. Some of the most common used manufacturer data formats are iBeacon and Eddystone

The format of this element is: Length <16-bit Manufacturer UUID> Data

The data in this field that's common to use includes sensor data, device state and anything else that's specific to your product. Obviously the amount of data is limited unless you're using advertising length extensions, so there's some tradeoffs to consider.

Using the Manufacturer Specific Data field in an scan response packet instead of the advertising packet, but this means the device has to now listen to scan request packets, which causes a small but sometimes significant increase in the power consumption of the.


This element is very useful for devices providing standard services. You can use it to advertise the data of any Bluetooth Standard Service. For example, want to advertise the battery value of the Battery Information Service or the temperature of the Thermometer Service? This is the element to use.


We’ve covered some of the most popular BLE and Bluetooth devices, their specifications and some of the key aspects to keep in mind when making a decision.

As always, there are many details and concerns that come into play when creating a BLE product. We’re committed to help you get it done right, so feel free to get in touch with us to discuss.

Photos courtesy of Nordic Semiconductor, Texas Instruments, Cypress Semiconductor, Qualcomm, Dialog Semiconductor and Silicon Labs.


Enter your email address to subscribe to this blog and receive notifications of new posts by email.

Related Articles