BLE Connectivity Architecture: The Ultimate Guide

Introduction

Building your first connected product is no easy task. There are many wireless networking protocols, each with its benefits and tradeoffs. However, if you’re interested in widespread support, including iOS or Android devices in your network, the Bluetooth Low Energy (BLE) protocol is the way to go.

This Ultimate Guide to BLE Connectivity Architecture is primarily designed for engineers. Still, project managers and decision-makers can gain valuable insight as they reflect on their roles within this process. We’ll explore the foundational topics you need to understand and effectively plan and architect a BLE-connected device. Plus, you’ll get an inside look at how we at Punch Through tackle the discovery, planning, and architecture stages.

If you’re looking for more, we recommend these Ultimate Guides for an in-depth focus on BLE development for iOS and Android:

• Apple iOS Core Bluetooth
• Android Bluetooth Low Energy
• Managing your BLE Connection

What’s Inside this Guide

Feel free to jump to the sections that interest you the most or buckle up for the full ride through the world of BLE connectivity architecture.

• Our Approach to BLE Connectivity Architecture
• The Importance of User Stories
• BLE Connected Architecture Basics
• Evolutions of the BLE Protocol
• Connection Topology
• Connection-Based Architecture
• Securing a BLE Connection
• Mobile Device Considerations for BLE Connections
• BLE Chipset Considerations

---

Our Approach to BLE Connectivity

Designing a product with Bluetooth Low Energy (BLE) offers a lot of flexibility but comes with its challenges. Make sure to consider elements like secure and authenticated data exchange, real-time data streaming, and hardware selection. Making these crucial decisions before diving into the development process is vital.

At Punch Through, we guide our clients through all stages of the connected product journey. From helping make the connectivity design decisions to start the product right to developing, documenting, and helping prepare for regulatory submission.

The Punch Through Discovery Process

Our BLE connectivity architecture process begins with establishing an in-depth understanding of the product. This knowledge generally comes from three areas: 

• Conversations with client stakeholders
• Existing documentation and design schematics
• Our deep knowledge of the connected product landscape

Conversations with Clients

Product visions are rarely formed with technical feasibility in mind, so we need to discover compromises that will allow the product to exist and achieve regulatory approval. These conversations also drive an understanding of the product’s target audience, which helps inform user experience decisions. Different audience demographics vary in tech savviness, risk tolerance, and design expectations.

After documenting these conversations, we move into the documentation and user story review stage.

Documentation & User Story Review

Documentation, from User Stories to formal Software/Product Requirements to UI designs, is beneficial. These documents contain concrete information about product design that has already been completed. This input also varies the most between projects, and clients may come in with a product that is 80% complete or a product that is merely a fragment of proven concepts.

Our understanding of connected products and their underlying technologies allows us to guide clients’ product visions toward feasible connectivity that leads to a great user experience and can clear regulatory approval. Our knowledge informs all design decisions, from understanding that Wi-Fi and BLE generally share the same radio, limiting the throughput/latency, to optimizing connectivity design so that a device can transmit for years on a single charge.

Our time spent gaining an understanding of the product is only partially spent absorbing information. We wrap up this phase by delivering User Stories highlighting our understanding of the product connectivity needs.

Design & Architecting

After receiving client feedback on the user stories, we can begin architecting. Our architecture decision process leverages our years of experience in the connected medical device industry but is also guided by structured and well-iterated processes. The majority of our BLE connectivity architecture documents cover the same standard outline. However, the content of each section is written specifically for this project based on the understanding we gained via the user stories written in the previous phase.

While most of the architecture document’s structure remains the same for each project, each project has unique areas requiring more in-depth architecting and, thus, more detailed documentation. On delivery, our clients receive a document detailing all the connectivity architecture decisions needed to implement their BLE applications — explaining why we made each decision and how it relates to the product needs.

The end deliverable is a document containing detailed user stories about how the connected portions of the product will be used, followed by a guide on implementing connectivity to achieve the user experiences described in the user stories. 

---

The Importance of User Stories

It’s tempting to dive straight into the technical specs and protocols. But let’s remember the humans using these devices. That’s where User Stories step in. These narratives are our unsung heroes, vividly showing how end-users, clinicians, or factory staff interact with a connected device. At Punch Through, we lean heavily on User Stories to understand each role’s unique challenges and opportunities. And guess what? They’re foundational to crafting a stellar BLE connectivity architecture.

User Stories

User Stories, while lacking the concrete and exacting nature of formal requirements, are an excellent mechanism for capturing, sharing, and expanding a product vision. At Punch Through, we are most familiar with the actors and user stories surrounding connected medical devices, which will be the focus of the examples below.

While the initially captured user stories generally revolve around the patient or end user’s interaction with the product, they can also be expanded to cover interactions of secondary users who interact with the product to support the end user, such as clinicians or even tertiary users, who interact with the product to help the product itself, such as factory calibration/provisioning or end-of-life data gathering/analysis. All of these users and their use cases are considered in Punch Through’s connectivity architecture process.

Our user stories vary in scope and level of detail. Some user stories may cover an entire process or combination of processes at a basic level of detail. In contrast, others will cover a specific part of an essential process in much more detail.

Patient Stories for Medical IoT Devices Architecture

Patients or other End Users are the focal point of our user story process. These people choose to use your product, and an unintuitive process can range from annoying to dangerous. An example of a high-level user story for a portable electrocardiogram (ECG) reader could look like this:

Margaret has been diagnosed with a heart rhythm issue. Her doctors would like her to take ECG readings each day as part of the treatment. Margaret purchases a BLE ECG device because it advertises that it works with her phone and can integrate with her doctor’s records. Upon unboxing the ECG device, Margaret is instructed to unlock her phone and place it near the device. The phone reads NFC data from the ECG device and displays the app store page. Margaret downloads the app. When the app finishes installing and launches, the app uses metadata from the NFC reading to securely identify and pair with Margaret’s ECG device. The app then walks Margaret through taking a reading, displaying real-time feedback. Once the reading is completed, Margaret is shown the results and is prompted to set up secure sharing with her doctor.

An essential part of the above user story, such as the ECG reading process, could be worth exploring in further detail:

After the connection to the ECG reader is set up, the app displays that it is ready and instructs Margaret to press a button on the screen to start the reading. Upon pressing the button to start, the app instructs Margaret to place a finger on each pad of the ECG and displays a graphic to help describe the requested action. After placing fingers on the pads as instructed, Margaret sees a live ECG waveform displayed on the app, as well as a live heart rate value and time remaining countdown. Margaret waits, and once the countdown completes, the app informs her that the measurement is complete and that her results are ready. Margaret presses a button on the app to acknowledge and is shown the results of her ECG measurement. Margaret is happy to find that her heart rhythm currently appears normal.

Our user stories will also branch out into error scenarios:

During an ECG reading, Margaret receives a phone call. Margaret takes her hand off the ECG device to answer the phone. The app displays that the finger removal was detected and instructs the user to place their fingers back on the device to continue. Margaret ignores the instructions and answers the phone. Upon finishing the phone call, Margaret returned to the app and saw that her measurement session had timed out and needed to be redone. Margaret restarted her measurement and allowed it to complete without further interruption.

These user stories inform several product requirements, such as:

• The ECG must share authentication info over NFC
• The App must read authentication info over NFC 
• The App must walk the user through their initial measurement
• If a user removes a finger from the pad during the measurement, the App must inform the user to place the finger back on the pad
• If a finger remains off the pad for X continuous seconds during a measurement, the measurement will be canceled
• The App must display a live ECG waveform during the measurement
• The App must display the current heart rate info during the measurement
• The App must display the time remaining during the measurement
• The App must display results upon completion of the measurement

Clinician Stories for Medical IoT Devices Architecture

Some medical devices have complex procedures that are better left to a qualified individual. These procedures generally have a risk of injury if performed incorrectly. At Punch Through, we refer to these use cases as Clinician User Stories.

A hearing aid could be a medical device that requires a clinician user story. Hearing aids need to be tuned for a specific patient’s hearing needs, and improper tuning could make the hearing aid less effective, uncomfortable to use, or even cause further hearing damage. Because of this risk and the niche understanding of interpreting hearing test results, this use case would require a trained professional (clinician) to perform.

Robert has received his new BLE-enabled hearing aids. He visits an audiologist, Michael, to have them appropriately configured for his needs. Michael is certified to configure this hearing aid model and thus has access to an iOS application capable of performing the needed configuration. Michael’s application connects securely to the hearing aids and is granted a higher authorization level than Robert’s patient app. Michael runs through the configuration session, making adjustments via his app to tune the hearing aids to meet Robert’s personalized hearing needs.

This clinician’s story highlights the need for a separate application to connect to the hearing aids with a higher authorization level. It also allows the audiologist to perform their responsibilities without risking a patient making harmful adjustments through their app.

Manufacturing Stories for Medical IoT Device Architecture

Medical devices may also require that particular actions be taken as a part of the manufacturing process. These actions include adding unique identifiers to a device, securely provisioning a unique identity, performing calibrations, or verifying specific functionalities. All of these are essential steps when mass-producing devices that have the potential to cause bodily harm, either via action or inaction.

Jane is a factory technician working for a company that makes insulin pumps. Her job is to verify that a newly assembled pump passes verification tests and is appropriately calibrated. Because the pump is a sealed unit, BLE is the only way to interact with the pump. To perform verification testing, Jane uses an Android tablet that runs a special factory application. This application securely connects to the pump over BLE and has a higher authorization level than the patient-facing app. Jane uses the factory application to run the required verification tests. Once verification succeeds, Jane performs the final calibration measurements and loads calibration data onto the pump via the factory application.

This manufacturing story highlights at a high level what the post-assembly process may look like for an insulin pump. The story provides insight into the need for a factory app, as well as the existence of verification and calibration processes.

As shown in the above examples, User Stories play an important role in communicating expectations for a system. They can help directly drive formal requirements and provide unique insight into the system’s use. These insights can go on to inform design decisions at many phases, especially connectivity architecture. By writing detailed user stories, Punch Through and their client can mutually confirm that we understand the product correctly and can make informed architecture decisions. 

---

BLE Connected Architecture Basics

Evolution of the BLE Protocol

Bluetooth Low Energy (BLE) has undergone many improvements since the technology’s initial integration into the Bluetooth specification, released in 2010. Early versions of BLE included much of the core architecture central to most connected products today. Over the years, the most impactful improvements to BLE have been improvements on this same core architecture, namely packet length, throughput, and range increases.

A significant reason for the success of Bluetooth Low Energy may be that it was and still is the best way for a nearby device to interact with Apple’s iOS ecosystem. Alternatives generally either require joining Apple’s gatekept MFi program or requiring the user to jump through hoops outside of your app, leading to a poor user experience.

As a fun piece of history, one of Punch Through’s main areas of expertise before BLE was navigating Apple’s MFi program and creating wired accessories for iPods and iPhones. BLE has been a massive improvement in lowering the barrier to entry to interact with Apple’s ecosystem.

Recent additions to the BLE specification include features that increase the ways that BLE can be used, such as: 

• Mesh Networking
• AoA/AoD measurements (Angle of Arrival/Departure for direction finding)
• BLE Audio (the ability to broadcast audio)
• Periodic Advertising with Responses (the ability for a device to transmit infrequently but still receive responses as if it were in a connection)

Most of these features are currently only available on embedded chipsets but may become available on smartphones if their use cases take off.

The core BLE use case of Scan, Connect, Exchange Data, Disconnect may not require excessive connectivity architecture design by default. However, once deviations from that use case occur — such as needing multiple connections, higher throughputs, or data exchanges that are secure enough to stay out of the news — you will want a connectivity architecture early in the product development process to prevent many headaches and deliver a better end product. 

Connection Topology

The first consideration in connectivity architecture is your connection topology. Simple 1:1 or 1:Few setups might not need much thought, but 1:Many or Many:Many configurations require careful planning. This is crucial because each device takes up its slice of radio time. As you add more connections, time management becomes more stringent. Note that smartphones running iOS or Android are generally limited to about 8 BLE connections at a time, including any connections by other apps or the OS. This limitation might stem from the shared radio use for BLE, classic Bluetooth, and Wi-Fi. On the other hand, high-end embedded devices provide greater configuration flexibility and higher connection limits.

Many:Many Topology

The only dedicated solution for Many:Many topology is BLE Mesh. However, BLE mesh is not a good fit for high throughput applications, so products that need to send more than the occasional 10 bytes of application data in a true Many:Many topology may want to consider other radio protocols, such as Thread. BLE Mesh is also more energy-intensive than its name suggests, and while there are provisions in the protocol for low-power nodes, the expectation is that most nodes do not have a tight power budget.

BLE Mesh was designed for scenarios like a smart home network or higher-density areas such as warehouses, office buildings, or city streets. These mesh networks would have many fixed point nodes connected to a power grid that form the network’s infrastructure and mobile nodes that move around within the network. BLE mesh networks can carry messages for various applications while keeping the applications sandboxed for security reasons. (e.g., a rogue smart light won’t be able to unlock a door on the same mesh network.) The network is also intended for asset tracking within the areas covered by the network, which can help keep track of inventory in a warehouse or equipment in a hospital. 

At Punch Through, we have not encountered a product where BLE Mesh was the correct solution. However, the Bluetooth SIG advertises BLE Mesh as a solution for asset tracking, smart buildings, and more. Beyond the BLE Mesh solution, the potential solutions listed for 1:Many topologies can be applied for Many:Many topologies.

1:Many Topology

For 1:Many scenarios, the approach needs to get more creative. In this scenario, connections to all devices cannot occur simultaneously, which means that our main options include following a Broadcaster/Observer model, using a connected model but only connecting for a short period of time before connecting to the next device, or exploring BLE 5.4’s new Periodic Advertising with Responses (PAwR) feature.

Broadcaster-Observer Model

The Broadcaster-Observer model is a BLE GAP role, where one party advertises the data it wishes to share, and the other party listens for those advertisements. In this case, there could be one observer to multiple broadcasters or multiple observers to one broadcaster. Devices could simultaneously be both a broadcaster and observer and the Many:Many topology could be fulfilled by having multiple broadcasters and observers. 

The main drawbacks of the broadcaster-observer solution are data flow direction and latency. Except in the dual role scenario, data only flows one way, which limits the applicable use cases to only those that don’t need guaranteed delivery. Also, without a connection, there is no coordination of timing between when the broadcaster broadcasts and when the observer observes, resulting in multiple advertisements possibly needed before the observer receives the message. This can have a drastic impact on latency.

Connecting as needed / Round Robin

Another way to handle 1:Many and Many:Many topologies is to connect to a device, get the data required, and then disconnect and repeat with the next device. This allows for a pseudo Many:Many topology while technically composed of many 1:1 topologies. The drawback of this approach is that connections take time to set up, and the intended connection target may not be available if another connection is in use, both of which lead to higher latencies. Depending on the intended application, this may be a feasible solution.

Periodic Advertising with Responses

In a 1:Many topology where data is exchanged infrequently and latency is not a high-priority concern, BLE 5.4’s new Periodic Advertising with Responses (PAwR) feature may be a suitable solution. Periodic Advertising is infrequent advertising where advertisements occur on a published interval. This allows an observer to schedule a listening window when it expects the advertiser to transmit, thus being more reliable and power efficient compared to a regular broadcaster-observer model. 

PAwR also allows the observer to send a response at published times, enabling 2-way communication. PAwR can also be combined with the recent addition of encrypted advertisements, which provide security outside of a connection. 

The Bluetooth SIG’s example use case for Periodic Advertising with Response is for electronic shelf labels used in retail stores. This use case pushes the many of 1:Many, as stores can have thousands of price tags that, as electronic labels, can be updated with different prices or product names. These labels also need to be able to run off of a coin cell battery for extremely long periods (several years) and be secure, as changes in shown prices by a malicious entity could easily cause significant losses at a single store. More about PAwR and the Electronic Shelf Label can be read on the Bluetooth website.

These are just a few ways that 1:Many and Many:Many connection topologies can be handled. Other approaches may be better suited for a product’s specific needs.

Connection-Based Architectures

While the previous section discusses connected and connectionless connectivity architectures, most products will best suit the connected architecture. That is what the focus will be going forward in this blog post.

Advertising

BLE advertisements are interval-based transmissions announcing a device’s presence. An advertisement’s contents include insightful information for scanning entities. This information can include whether a device is connectable, what the device is, a unique identifier, and even small application information that can give insight into a device’s state.

Advertisements are also the gateway to further interactions with the device. After transmitting an advertisement, the device will listen for a short time in case anyone attempts to communicate with it. One such response to an advertisement that may be received is the connection request.

Advertising Interval

Advertisements have one key variable with a wide-reaching architectural impact: the Advertising Interval. The advertising interval controls how often the peripheral transmits. The more often transmissions occur, the more likely a scanning entity will receive the advertisement at any given time. On the flip side, advertising more frequently consumes more power.

A peripheral can be expected to be in a disconnected state for any length of time and should still be able to function. Some devices have physical interfaces, such as buttons, that can be used to inform the device that it is being used. These devices can stop advertising after a period of inactivity to save power. Devices that do not have other interfaces or otherwise need to always be connectable must always be advertising. These devices will advertise at an infrequent enough rate to meet their target power budget. Since advertising infrequently increases the time required to scan and connect, devices will generally advertise at a shorter interval for a couple of minutes when they expect a connection and then switch to the longer interval. Scenarios that typically trigger shorter advertising can include device boot and disconnection of a connected device. Specific applications may have other applicable scenarios as well.

Beyond choosing a general value, the specific value can significantly affect how quickly a scan result is received. Scanning devices, especially ones that share their radio with other 2.4GHz protocols, don’t scan 100% of the time. Scanners have two governing parameters: Scan Window and Scan Interval. The scan window is how long the scanner actively listens for, and the scan interval is how often the scan window repeats. Android has several default scan parameters. The balanced setting involves a 1024ms scan window and a 4096ms scan interval. This means the device listens for 1024ms, does other stuff with the radio for 3072ms, and then repeats. Apple is rumored to use a 30-ms scan window and a 40-ms scan interval. However, this is unconfirmed since iOS is closed source.

As shown in the chart above, the chances of an advertisement not occurring during a given scan window increase as the advertising interval grows. Choosing an unlucky interval could lead to a long time before an advertisement collides with a scan window. For example, a 120ms advertising interval would be considered very fast. Still, assuming the scanner uses a 30ms window and 40ms interval, the advertisement risks constantly occurring during the 10 ms that the scanner is not listening. In this case, the advertisements will be seen once the clocks drift far enough that the advertisement collides with a scan window. To mitigate this problem, Apple recommends the following advertising strategy in its Accessory Design Guidelines (Page 192):

• First, advertise at 20 ms intervals for at least 30 seconds
• If not discovered after 30 seconds, you may change to one of the following longer intervals: 152.5 ms, 211.25 ms, 318.75 ms, 417.5 ms, 546.25 ms, 760 ms, 852.5 ms, 1022.5 ms, 1285 ms

In our experience, Apple’s recommendations have worked fine for communicating with Android’s default scan settings. If the scanning central is an embedded device, then it is up to the developers to choose scan and advertising settings that complement each other.

Advertising Data

BLE supports several types of advertisement packets. These can be categorized into legacy advertisements and extended advertisements. Of interest to most applications are:

• Legacy Indirect Advertisement (31 Bytes)
  • The basic advertisement is sent out every advertising interval containing the configured advertising data.
• Legacy Scan Response (31 Bytes)
  • The Legacy Scan Response is a supplementary advertisement that a scanner can request during the peripheral’s listening period after each advertisement. This allows the peripheral to share a few more bytes of data than with the indirect advertisements alone.
• Extended Advertisement (254 Bytes)
  • Finally, we have the Extended Advertisement. Introduced in Bluetooth 5, extended advertisements work a bit differently. A special advertisement containing no advertisement data is sent instead of the Legacy Indirect Advertisement. This advertisement has the same function as the legacy indirect advertisement, which can be used to request a connection or scan response.  However, instead of containing 31 bytes of advertising data, it shares information about the time and channel that a larger advertising packet will be broadcast. This larger advertising packet contains up to 254 bytes of data and is transmitted on non-advertising channels. This approach reduces congestion on the three advertising channels.

iOS devices with BLE 5 support should support extended advertising (iPhone 8 and newer). Apple provides a method to verify support at runtime using supports(_:).

Android 8.0 and above have OS support for extended advertising. However, individual devices also need to have support from their Bluetooth controller. Flagship models from brands common in Western countries have generally had support for several years. Android provides several advertising methods that can verify support at runtime.

Advertising data is required to follow a specific format. BLE provides several types of containers for advertisement data, such as:

• Advertised Service UUIDS
• Local Name
• Service Data
• Manufacturing Data

Each piece of advertising data contains 2 bytes of overhead. The first byte represents the length of the data, and the second byte contains the type. This reduces the available space in the advertising packet.

The largest number of arbitrary bytes that can be adequately advertised is 27 for a legacy packet and 250 for an extended advertisement. This is accomplished via either the Manufacturing data or Service Data fields. Of manufacturing data’s 4 bytes of overhead, 2 are for the length and type bytes, while the other 2 are the 16-bit manufacturing ID (assigned by the SIG or 0xFFFF if no assigned ID). Service Data with a 16-bit UUID also has 4 bytes of overhead. The Local Name advertising data type only has 2 bytes of overhead. However, the Bluetooth Specification requires the Local Name data to conform to a UTF-8 string, which may not match an application’s use case. The preferred advertising data type for arbitrary application data is Manufacturing Data. Service Data should only be used if the type of data used makes sense to be represented by a service with a 16-bit UUID.

Encrypted Advertising

BLE 5.4 added an Encrypted Advertising data type. This data type is a container that can contain other advertising data types in a nested fashion. AES-CCM encrypts the data with a 128-bit key and an 8-byte IV. The Decryption Key and Nonce are available via the GATT table under a new Characteristic called Encrypted Data Key Material. This characteristic can be found in the GAP Service or within another service. The encrypted payload contains a 5-byte randomizer field and a 4-byte message integrity check (Message Authentication Code). The randomizer field is randomly generated and used as an input to the decryption (part of the Nonce). 

The randomizer field must change every time the payload value changes to be secure. The randomizer is also changed every time the address is rotated to help prevent device tracking across the address change. 

More information about Encrypted Advertising can be found in Section 2 of the Bluetooth 5.4 Technical Overview.

Addressing and Privacy

Because Bluetooth devices broadcast radio waves and are often carried around on a person, they present an avenue to track somebody’s movements. 

To mitigate this risk, BLE provides multiple addressing types for a device. 

Addresses can be Public or Random:

• Public Addresses are the 8-byte MAC addresses burned into all wireless (and Ethernet) devices during manufacturing (IEEE 802-2014’s EUI-48). 
• Random Addresses are generated in software, don’t require registration, and can be changed. 

Random Addresses fall into two categories: Static and Private.

• Random Static Addresses are either static for the life of the device or set during boot. Random Static Addresses cannot change during runtime. 
• Random Private Addresses can be changed during run time. Generally, these are rotated at regular intervals. Apple’s iOS devices rotate their addresses every 15 minutes, as the Bluetooth SIG recommends. 

There are two types of Random Private Addresses: Resolvable and Non-Resolvable.

• Non-Resolvable Private Addresses are random and cannot track a device across rotations. 
• Resolvable Private Addresses appear random but are cryptographically generated such that a key can be used to resolve the address. The key used to resolve the address is the Identity Resolving Key (IRK), one of the keys exchanged during bonding.

For privacy, using Random Private Addressing alone is not enough. Advertising data can be used to detect the address change and correlate the new address to the old one. This is not an issue for common devices, such as an Apple Watch, as there are likely several in range of a scanner at any given time. For lower volume devices, however, even an uncommonly advertised Service UUID or Manufacturer ID can be enough to correlate the old address to the new one.

BLE 5.4’s Encrypted Advertising is a step in the correct direction in that the encrypted advertising contents change with the address. However, encrypted advertising data is still new and rare enough that even seeing 17 bytes of encrypted advertising data would be enough to correlate the addresses confidently.

The best way to maintain privacy is to use a Random Private Address and include no advertising data. This approach has other drawbacks, so consideration must be given and tradeoffs made.

Connections

At its most basic, a BLE connection is an agreement between two devices that two-way communication will occur at an agreed-upon interval. At the beginning of this interval, the central transmits a message to the peripheral, even if the central has nothing else to say. In response to this message, the peripheral will send any data to communicate. Otherwise, it will send an empty packet to let the central know it’s still there.

Two main strategies are involved in connections: always connected and dynamically connected. 

• Always-connected applications attempt to maintain a connection at all times. If the connection is broken, the peripheral begins advertising, and the central begins scanning to find each other and restart the connection process. Maintaining a connection can require less power than advertising while offering a lower latency for transferring data once it becomes available. 
• In dynamically connected applications, the central and peripheral will only connect once data is available and disconnect once the data has been transferred. This can be useful if data becomes available infrequently, such as gathering usage statistics from a long-living smart device such as a water filter. Outside of the connection, a peripheral can indicate that it has data available by either only advertising when data is available or changing the advertising data to indicate that data is available. On the other hand, the central only chooses to scan/connect when it has data to share or is interested in the peripheral’s data. While this approach has a higher latency, it doesn’t occupy a connection slot on the central. It is beneficial if the central and peripheral are commonly not in range of each other.

Connection Parameters

An essential part of a connection is the Connection Parameters. The parameters are Connection Interval, Slave Latency, and Supervision Timeout. Connection Interval represents how often the devices check in, as described above. The Slave Latency parameter dictates the number of connection intervals that the peripheral is allowed to skip to save power. The Supervision Timeout is the length of time without a successful connection interval before the connection is considered broken.

The connection parameters — especially the connection interval — impact power consumption, latency, and throughput. A shorter connection interval means less latency. However, it also can mean many connection intervals occur with no data to be exchanged, wasting power. Throughput, on the other hand, is not as much of a tradeoff with power consumption and latency but is instead impacted by how much of the connection interval can be spent transmitting. 

Our Maximizing BLE Throughput for iOS and Android series goes into more depth on the topic. Still, the goal is to align the connection interval with a multiple of the packet length, such as to maximize the amount of time spent transmitting.

Slave Latency allows the peripheral to save power by skipping a limited number of connection intervals if it has no data to exchange. However, the peripheral can choose to skip any number less than the connection’s slave latency as well. This means that if the peripheral has data to send before it has skipped the allowed number of connection intervals, it can still decide to respond to the central early. Because of this, a high slave latency only impacts the latency of central-to-peripheral communication and not peripheral-to-central communication.

Supervision Timeout determines how much time needs to pass without successful communication before the connection is considered lost. A short Supervision Timeout can appear more responsive to users when a connection issue occurs. Still, it also runs the risk of abandoning a connection that could otherwise recover and incurring the increased overhead of setting the connection back up.

Application Data Transport

Application data is sent over a BLE connection via the Attribute Protocol (ATT). The ATT provides an interface for discovering, reading, and writing attributes on a connected device. The ATT protocol is combined with the Generic Attribute Profile (GATT). The GATT provides a further definition for the structure of ATT attributes into Services, Characteristics, and Descriptors. The overall structure containing concrete instances of the above elements is known as the Gatt Table.

To draw parallels to REST APIs, GATT profiles would be web endpoints, while the ATT protocol would be the GET, POST, and PUT request types.

GATT Profile Structure

The GATT Profile is made up of several types of attributes, each with different roles and functionality. Each element is a container that contains one or more instances of the child element. The order of this structure is Profile, Service, Characteristic, Descriptor.

The GATT Profile is used by all BLE devices that want to transport data. However, the GATT Profile also serves as a mechanism of interoperability, allowing clients and servers to exchange information without being specifically designed for each other. One such example could be a heart rate monitor that provides data by conforming to BLE’s Heart Rate Profile. Because the device conforms to the standard profile, any client that connects to the heart rate monitor will be able to retrieve and interpret the data of interest. 

Profiles

A Profile is simply a group of one or more services needed to fulfill a use case. The Heart Rate Profile requires that a device contains both the Heart Rate Service and the Device Information Service. Profiles are entirely conceptual. Devices do not declare that they conform to a profile, and profiles do not have concrete entries in a peripheral’s GATT Table.

Services

Services are the top level of concrete elements in a GATT table. Services are simply a collection of characteristics. The Bluetooth SIG defines standard services as having mandatory characteristics or optional characteristics. Custom services can include whatever characteristics they want, as they are not attempting to conform to an interoperability standard. Services can also have an element known as an included service, which refers to another service on the device. There is nearly no reason to use an included service object outside of what GATT Profiles requires.

Services are identified by their UUID, which can be 16, 32, or 128 bits. 16-bit and 32-bit UUIDs are assigned by the Bluetooth SIG either as a common service for interoperability or as a proprietary service whose UUID was purchased by a 3rd party. 128-bit UUIDs are unassigned and can be used by anyone. The only exception for 128-bit UUIDs is ‘XXXXXXXX-0000-1000-8000-00805F9B34FB’, which is the base UUID used for all 16-bit and 32-bit UUIDs. 32-bit UUIDs use bytes 0-4, while 16-bit UUIDs use bytes 2-4 with bytes 0-2 set to zero.

Service UUIDs can be included in advertising data to help prospective clients filter devices.

Characteristics

Characteristics are individual values within a Service. These values can be read from, written to, or subscribed to. All Characteristic instances include:

• Characteristic Properties (Read, Write, etc.)
• Characteristic Value (pointer)
• Characteristic UUID (16-bit or 128-bit)

Characteristics can share further information via descriptors.

Descriptors

Descriptors (also called Characteristic Descriptors) can be considered metadata for a characteristic and generally include information such as the unit that the characteristic’s value is in (e.g., feet vs. meters) or human-readable description strings. Descriptor UUIDs are either 16 or 128 bits and can be a standard BLE descriptor or a custom descriptor. The BLE specification states that clients can safely ignore unknown descriptor UUIDs.

ATT Operations

BLE has 6 ATT operations (referred to as Attribute PDU in the BLE Spec) that describe how attributes interact.

Type	Description
Commands	Client -> Server, does not require a response
Requests	Client -> Server, requires a response
Responses	Server -> Client, in response to a request
Notifications	Server -> Client, unsolicited message that does not require confirmation
Indications	Server -> Client, unsolicited message that requires a confirmation
Confirmations	Client -> Server, confirms receipt of an indication

Of these operations, the following are used by applications:

Read Request

Request sent by a client to request the value of a characteristic or descriptor. The server will deliver the data via a response.

Write Request/Command

A Request or Command sent by a client to write a value to a characteristic or descriptor. In the case of a write Request, the server will deliver a Response to confirm whether the write was successful.

Notification/Indication

Used by the server to deliver an updated characteristic value without being polled by the client. Allows for prompt delivery of updates from server to client. In the case of an indication, the client’s BLE stack will respond with a confirmation after the indication is received. This is more reliable but can drastically impact throughput. 

Notifications and Indications must be subscribed to by the client before the server can send them. This subscription is performed by writing to a descriptor (Client Characteristic Configuration Descriptor) of the characteristic that the client would like to subscribe to.

GATT Example

The GATT structure for the CGM profile appears as follows:

As an example of the GATT structure, the Continuous Glucose Monitoring Profile will be used due to its current relevance in the medical space.

• CGM Profile (Sensor)
  • CGM Service – Service Specification
    • Characteristics
      • CGM Measurement – Notify
        • Descriptors
          • CCCD (used to subscribe) – Read, Write
      • CGM Feature – Read
      • CGM Status – Read
      • CGM Session Start Time – Read, write
      • CGM Session Run Time – Read
      • Record Access Control Point (RACP) – Indicate, Write
        • Descriptors
          • CCCD – Read, Write
      • CGM Specific Ops Control Point – Indicate, Write
        • Descriptors
          • CCCD – Read, Write
  • Device Information Service – Service Specification
    • Must include the following beyond the base DIS Service Specification
      • Manufacturer Name
      • Model Number
      • System ID
  • Bond Management Service – Service Specification (Won’t dig further into here)
    • Mandatory if multiple bonds are supported; otherwise, optional

Beyond specifying the GATT structure, these specifications specify the exact formats required for the values of each characteristic as well as expected behavior when interacted with. Check out the Service Specifications for more information.

Data Transport Approaches

Knowing what’s possible with BLE’s GATT, let’s discuss approaches generally used in connected device development. In the case of devices that are attempting to be interoperable, conforming to declared BLE Profile Specifications is required for Bluetooth SIG certification. However, the BLE Profiles are additive requirements, not limiting ones. A device conforming to a profile can still add other services and characteristics for proprietary functionality.

Serial Approach 

The common approach for proprietary devices is to create serial channels over GATT. This is done by creating a Service that contains an RX Characteristic (write-enabled) and a TX Characteristic (notify/indicate-enabled). The client writes data to the RX Characteristic in a proprietary format, and a response is received from the TX Characteristic. BLE uses this strategy in several standardized services, such as the Records Access Control Point (RACP).

This approach is beneficial when using Application Level Security, as it causes all Application Data to flow through a single channel, making it easier to process encryption/decryption. This approach can also be more throughput efficient, as the proprietary message formats might send more data in a single packet than other approaches, which reduces the overhead added by BLE.

Data-Driven Approach

One straightforward method involves creating a distinct characteristic for each data type entering or exiting the device. This approach is generally quicker to develop because it eliminates the need for complex command-response behavior or data serialization. You have flexibility in structuring services and characteristics, and each data piece can still have a proprietary format.

However, this approach has its limitations:

1. Connection Setup: Adding more services and characteristics increases the overhead, prolonging the connection setup time by seconds.
2. Throughput: Due to the added overhead for each ATT operation, you’ll experience reduced data throughput.
3. Data Limit: The approach struggles with segmentation, restricting each characteristic to 22 or 251 bytes based on DLE support.
4. Security: Implementing application-layer security becomes overly complex, making BLE’s built-in security the only practical choice.

Hybrid Approach

Developers have the flexibility to combine various approaches within a single application. Take an environment sensor device as an example. It could utilize BLE’s standard Environmental Sensing and Battery Services for basic functionality. However, if it measures additional environmental metrics not covered by the standard service, a separate proprietary service can be introduced for that extra data.

For firmware updates, a serial pair of characteristics can be added via an Over-The-Air (OTA) service. If the device generates logs for debugging, another service with a serial pair of characteristics can be implemented for wireless offloading. Additionally, during development, it may be discovered that the device needs to be time-aware for accurate historical data recording. In such cases, BLE’s Current Time Service can be integrated.

In practice, most fully-featured devices adopt this hybrid approach. Even the most complex and security-sensitive devices often have data they wish to share quickly without the added steps of setting up a secure connection.

Securing a BLE Connection

Securing a BLE connection is generally an authentication problem. Encryption is easily handled by the BLE stack thanks to BLE 4.2’s LE Secure Connections (LESC). LESC uses an Elliptic Curve Diffie-Hellman key exchange to agree on a cipher secure from passive listening. However, LESC does nothing to prevent active attacks such as Man-in-the-Middle (MitM) or spoofing. Without LESC enabled, breaking the key exchange for a BLE connection is trivial.

BLE offers two security modes: Mode 1 and Mode 2. Security Mode 1 enforces security via encryption, while Security Mode 2 enforces security via data signing. Each security mode has several security levels:

• Security Mode 1 (encryption)
  • Security Level 1: No Security
  • Security Level 2: Unauthenticated pairing with encryption
  • Security Level 3: Authenticated pairing with encryption
  • Security Level 4: Authenticated LE Secure Connections pairing with encryption
• Security Mode 2 (data signing)
  • Security Level 1: Unauthenticated pairing with data signing
  • Security Level 2: Authenticated pairing with data signing

Only Security Mode 1, Level 4, achieves a genuinely secure connection. Security Mode 2 and all other levels of Security Mode 1 rely on legacy pairing instead of LE Secure Connections, which the Bluetooth SIG no longer recommends due to its vulnerability to MITM attacks, passive eavesdropping, and brute force attacks.

BLE provides several pairing procedures designed to cover a variety of I/O capabilities on each device and provide authentication to the connection. In order of secureness, the pairing methods are Out-of-Band, Passkey (6-digit display/entry), Numeric Comparison, and Just Works. Just Works pairing is not authenticated and cannot be used for authenticated security levels. Passkey pairing is the most commonly used authenticated pairing — however, it is only secure if the passkey changes every connection attempt. An attacker can easily recover a hardcoded passkey by entering the wrong passkey several times. Each wrong guess at a static passkey reveals another piece of the correct passkey to an attacker. 

BLE Bonding

BLE Bonding can occur as part of the pairing process. After pairing, devices that want to bond will exchange long-term and identity-resolving keys. This allows the devices in the connection to identify each other despite address rotation and enables the authentication for a new connection to build upon the previous connection’s validity.

In our experience, Bonding is mainly helpful for enabling resolvable address rotation. In older versions of BLE, Bonding also functioned to build on an insecure initial pairing by reducing the frequency that the insecure pairing needed to occur. If the initial insecure pairing were not observed and cracked, future connections would be secure if built on that same bond.

Bonding can lead to a worse user experience for iOS users because bonding is completely abstracted away from iOS applications. Creating a bond with an iOS device requires the other device to initiate the pairing process. If the connected device forgets a bond, the only way to recover is to have the user enter iOS Settings and delete that device from the bonded device list.

Application-Level Security

Many BLE devices do not have the required I/O to achieve an authenticated connection via BLE pairing but still need a secure connection. This is where application-level security comes in. Application-level security involves building a custom authentication and encryption scheme on top of the BLE connection. The BLE connection can still use LESC with Just Works pairing to increase security against passive attackers, but this isn’t required.

Application-level security achieves authentication via a pre-shared secret. This secret could be a hardcoded key or a more complex identity management structure like PKI. Either way, it depends on a trusted secret loaded onto the device outside of the BLE connection that it secures.

Punch Through’s Preferred Application-Level Security Schema

We use the following schema for securing

• A session-based authenticated key exchange, based on TLS, using the Elliptic Curve Digital Signature Algorithm (ECDSA) and Elliptic Curve Diffie Hellman (ECDH P-256)
• AES-128-GCM encryption
• Identity management that is uniquely tailored to each product’s use case
  • This might involve generating identity keys on devices and performing a CSR procedure during manufacturing or loading identities on the device during manufacturing and using a cloud application to gatekeep access to the corresponding keys via cloud accounts.

This approach has stood up to third-party security reviews and has been successfully implemented, taking advantage of hardware acceleration on iOS, Android, and nRF5x devices.

For more information on BLE Security and cryptography fundamentals, check out our post on BLE Security: Where to Begin When Creating a Connected System.

Mobile Device Considerations for BLE Connections

BLE connections involving an iOS or Android device have additional limitations compared to BLE connections between embedded devices. iOS and Android manage the radio and BLE at the OS level, limiting what third-party apps can access and what configurations the connection can accept.

BLE Connection Limit

The first significant limitation in BLE connectivity is the restriction on the number of simultaneous connections. iOS and Android typically share a radio for BLE, Bluetooth Classic, and Wi-Fi. This sharing limits the time slices available for BLE tasks. Android’s AOSP code indicates a maximum of 7 device connections, and iOS has shown a similar limit in tests.

The connection cap includes all BLE devices—and potentially Bluetooth Classic devices—the user may have connected. This could range from smartwatches and fitness monitors to IoT devices. When this limit is hit, subsequent connection attempts will fail. Therefore, when developing a connected app, handling this constraint in a user-friendly manner is crucial.

From a product standpoint, the design must account for this connection ceiling. If your product requires more than 2 or 3 simultaneous device connections, consider revising the approach. Alternatives include sequential connections, leveraging advertising data, or allowing connected devices to communicate among themselves while maintaining just a single connection to the iOS/Android device. If the iOS/Android device is dedicated solely to your product, utilizing additional connections becomes more acceptable.

Remember that increasing the number of connections also proportionally reduces the throughput for each. This throughput constraint manifests in the allowed connection parameters or during the MTU and DLE negotiations.

Connection Parameters

iOS and Android restrict connection parameters for the same reasons that they restrict the number of connections. Apple has posted the following recommendations for choosing connection intervals for iOS and Android in its Accessory Design Guidelines (Page 193):

• Interval Min ≥ 15 ms (multiples of 15 ms)
• Interval Min + 15 ms ≤ Interval Max (Interval Max == 15 ms is allowed)
• Interval Max * (Slave Latency + 1) ≤ 2 seconds
• Interval Max * (Slave Latency + 1) * 3 < connSupervisionTimeout
• Slave Latency ≤ 30
• 2 seconds ≤ connSupervisionTimeout ≤ 6 seconds

iOS allows a lower minimum connection interval for devices implementing an HID GATT profile. Android enables the BLE to spec a minimum connection interval of 7.5 ms. Android also allows a much higher supervision timeout of around 30 seconds.

Neither iOS nor Android allow apps to interact with connection parameters, so the embedded device must request any preferred values. Centrals have the final authority on what the connection parameters are, but peripherals can request preferred connection parameters, including a range of preferred connection intervals. A common workaround to allow the app to request connection parameters is to have the app send the preferred parameters via an application-level message. Upon receiving the application-level message, the firmware will request those connection parameters from its BLE stack, which will handle the negotiations with the central.

GATT Table Caching

When planning your connectivity architecture, bear in mind that both iOS and Android cache a device’s GATT table during the initial connection. This caching method means they skip real-time service discovery on future connections. While this speeds up connection setup, it locks in the GATT structure for the device’s lifespan.

iOS Considerations

In iOS, you can disable GATT caching through the Service Changed characteristic within the Generic Attribute service. This characteristic needs to have the ‘indicate’ property. If present in your GATT, iOS will rediscover services and characteristics each time a new connection is made. Moreover, if the GATT table changes during a connection, an indication sent on the Service Changed characteristic will prompt iOS to rediscover services and characteristics without requiring a reconnection. However, ensure that the handles for the Generic Attribute service and Service Changed characteristic remain constant, as any changes will cause the indication to be missed. For best practice, position these attributes at the beginning of your GATT structure to assign them the lowest value addresses.

Android Considerations

On Android, GATT caching occurs only if the Generic Attribute service exists. To notify Android of changes, the Service Changed characteristic and indications are necessary. Additionally, Android provides a private refresh() method on BluetoothGatt, accessible via reflection, to clear the cache if needed. But note that this is a temporary workaround rather than a production-level solution.

In summary, during development, always include the Service Changed characteristic if you anticipate changes in the GATT structure. For production devices without firmware updates, avoid using the Generic Attribute service. If the GATT structure might vary, include the Generic Attribute service, Service Changed characteristic, and indication functionality to mitigate risks. Position these elements as early as possible in the GATT structure and ensure their preceding structure remains static.

Note: Many OTA processes involve modifying the GATT table when launching the update server that receives the new firmware image.

Security Considerations

There are several security nuances when dealing with BLE connections to iOS and Android applications. First, BLE’s built-in security secures the connection between the OS and the BLE device. Any app on the iOS or Android device can access the BLE device using the connection’s authentication. 

The only way to truly authenticate a connection at the BLE level with an iOS or Android device is via Passkey pairing. This approach requires that the connected device has either a 6-digit display or a number keypad. The pairing passkey must change each pairing attempt. Otherwise, the passkey can be easily cracked. 

App Backgrounding and Long-Term Connections

iOS and Android support methods for keeping BLE connections and processing the received data in the background (while the app is not on screen or the phone is locked). However, these methods are not the most reliable in the long term.

iOS provides background handling and app relaunch specifically for BLE events. This approach works long-term until the user kills the app or BLE is turned off, in which case your app needs to be relaunched by the user. More information can be found in our Core Bluetooth background post: Leveraging Background Bluetooth for a Great User Experience.

Android’s approach to Bluetooth involves Foreground Services. Foreground Services grant an app the full ability to execute code while the app is backgrounded. However, many device OEMs are aggressively killing foreground services for better battery life. The only way around this involves instructing the user through several levels of the settings app to whitelist the app for background operation. Don’t Kill My App shares helpful information regarding handsets that interfere with background behavior and what steps are available to help keep the app alive in the background.

Due to these limitations, any product where real-time information transfer is critical should not depend on a background connection to iOS or Android.

For example, with the recent approval of Continuous Glucose Monitors (CGM) for closed-loop systems, many products are in development that want to use a CGM and connected insulin pump for a closed-loop insulin delivery system. In this case, the user would still need to manage such a system via a smart device, such as an iOS or Android phone. However, depending on the iOS or Android device as the intermediary for communications between the CGM and the pump would be a dangerous approach. iOS or Android may kill the application for any reason, and the user may not become aware that their system has stopped functioning until it’s too late. As such, any similar closed-loop systems should only use an iOS or Android device as an interface for managing the system. It should not be a critical component of system functionality.

OS-Specific Guides for Further Guidance

• Ultimate Guide to Android BLE
• Ultimate Guide to Apple’s Core Bluetooth

BLE Chipset Considerations

When creating a product that leverages BLE, many chipsets are available. Where BLE is concerned, here are some factors worth keeping in mind when making a selection.

BLE Chipset Security

Cryptographic Hardware Acceleration and Secure Execution

Hardware acceleration for cryptography can decrease the time and energy needed to perform cryptographic operations, resulting in significant improvements in user experience.

Secure execution environments are also crucial for secure devices. These are usually paired with hardware acceleration to provide a safe environment for cryptographic algorithms to be performed. The secure environment prevents tampering with algorithms or the extraction of keys.

Secure Key Generation and Storage

To securely provision cryptographic identities, a secure source of randomness is needed. This prevents external factors from influencing the generated key. When combined with secure key storage, the device can create secure identities that cannot be extracted from the device via any method.

Tamper Protection

Tamper protection can cover many things, but the main goal is to prevent extracting information or elevated privilege (such as arbitrary code execution) via physical attacks on the hardware.

An example of tamper protection failure would be the hacking of Apple’s AirTags. LimitedResults published a method for bypassing a debug interface lockout on the nrf52840, which allowed attackers to gain full debug capabilities on devices that were supposedly secure, including Apple’s AirTags. More on this attack can be found in nrf52 Debug Resurrection (Approtect Bypass).

Signed Executable Image Support

The ability of a device to verify executables cryptographically can help prevent attacks on the firmware upgrade process, which could allow attackers to replace an official executable image with their own. Supporting signed images would mean that only the holder of a trusted private key can issue new executable files to devices in the field.

Bluetooth Version & Supported Features

Advertising Extensions

Advertising extensions increase the amount of data that an advertisement may contain from 31 bytes to 254 bytes, vastly increasing the possible uses for advertisements.

Data Length Extension (DLE)

Data length extension increases the amount of ATT data sent in a single transmission, reducing byte overhead and overhead from transmission spacing. Throughput can be increased to around 85 KB/s between embedded devices or around 50 KB/s if an iOS or Android device is used.

PHY Support

Bluetooth 4 operated exclusively on a single PHY, known as 1M PHY. 1M PHY operates at a modulation of 1 MegaSymbol per second and an encoding of 1 symbol per bit for a data rate of 1 Mb/s.

Bluetooth 5 supported two more PHY, 2M PHY, and Coded PHY. 2M PHY operates at a modulation of 2 MegaSymbols per second to achieve a data rate of 2 Mb/s at the cost of range. Coded PHY operates at the same 1 MegaSymbols per second modulation of 1M PHY but increases the number of symbols per bit to 2 or 8. Coded PHY achieves a greatly increased range at the cost of throughput. There have even been experiments where two nRF52 dev kits could communicate at a distance of 1 km. Coded PHY has a data rate of 500 or 125 kb/s, depending on the symbol rate.

Flagship iOS and Android devices have supported 2M PHY for several years now, but support for Coded PHY is still missing from iOS and is rare at best on Android.

2M PHY, when combined with DLE, can offer a throughput of around 90 KB/s.

Dual Role & Multi-Protocol Support

Some applications require that the embedded device act as both a BLE central and a BLE peripheral simultaneously. Others may need simultaneous use of BLE and another 2.4 GHz protocol, such as Wi-Fi or Thread. Only some chipsets support true concurrent use of these roles.

NFC

NFC support can be beneficial for provisioning security between embedded devices or an embedded device and an iOS/Android device, and it excels at providing a just works user experience. NFC antennas come as external packages or can be printed directly on the PCB.

---

Wrap-Up

As you can see, many factors must be considered when designing and developing a connected product. Many of these decisions need to be made before the first line of code has been written, lest you end up needing to redo significant pieces of your product. Punch Through has extensive experience in guiding product owners through the entire connected product journey, and we look forward to helping you with yours.

More Ultimate Guides

For more expert connectivity development resources, check out our other great guides: