The Bluetooth® Low Energy Primer

Version	Date	Author	Changes
1.0.0	22 April 2022	Martin Woolley, Bluetooth SIG	Initial version.
1.0.4	6 June 2022	Martin Woolley, Bluetooth SIG	Improvements to the Link Layer section: added information that multiple link layer state machine instances are permitted, improved language to ensure it is clear that channel classification is an optional implementation feature, differentiated channel status reports from channel map updates, and flagged that AFH may have a different meaning in a regulatory context.
1.1.0	17 January 2023	Martin Woolley, Bluetooth SIG	Updated to reflect Bluetooth^® Core Specification 5.4, adding information about Periodic Advertising with Responses.
1.2.0	15 March 2024	Ifti Anees, Bluetooth SIG	Format updates and fixed 14.2 typos related to the Observer role.
1.3.0	15 October 2024	Martin Woolley, Bluetooth SIG	Updated to include information about Bluetooth^® Channel Sounding, Decision- Based Advertising Filtering, and Monitoring Advertisers features plus the revised permitted values of the inter-frame space timing variables.

2. About this paper

The Bluetooth^® Low Energy Primer has been created to help technology professionals such as product designers and developers quickly learn about Bluetooth Low Energy (LE) before consulting the formal technical specifications and delving more deeply into the subject.

There exists a substantial collection of specifications, papers and other educational resources about Bluetooth LE available from the Bluetooth SIG. A further aim of this paper is to raise awareness of their existence, their purpose and to help the reader get orientated with the subject and its supporting material.

The greater majority of Bluetooth LE products either use a combination of connectionless communication (advertising) and point-to-point connections to exchange data or they communicate only by broadcasting advertising packets. This resource covers the Bluetooth LE stack as it is used for products that fall into these categories. In contrast, Bluetooth mesh is not covered here. Bluetooth mesh is a specialized use of Bluetooth LE about which other information resources should be consulted.

It is not the aim of this paper to reproduce or cover precisely the same ground as the formal specifications or to the same depth. From time to time, brief extracts from the specifications may be included where it makes sense to do so. You should think of this paper as serving to orientate by introducing and explaining important Bluetooth LE concepts, pointing the way to other resources and specifications and hopefully, making the learning curve that little bit less steep.

3. Introduction

Bluetooth technology has been around since the year 2000. Initially created to allow two devices to exchange data wirelessly without the need for any other intermediate networking equipment it quickly found a role in products such as wireless mice and hands-free kits for cars. The latter is an audio product and audio proved to be the killer app for this original version of Bluetooth technology. It continued to be so for many years.

This first version of Bluetooth technology, used in those very first ever Bluetooth products is known more formally as Bluetooth BR (Basic Rate). It offered a raw data rate at the physical layer of 1 million bits per second (1 mb/s).

Later, a faster version of Bluetooth technology known as Bluetooth BR/EDR (Enhanced Data Rate) was defined. It offered a raw data rate of 2 mb/s but was still designed for use cases involving two devices exchanging data directly between them.

Bluetooth Low Energy (LE) first materialized in version 4.0 of the Bluetooth Core Specification[1]. This was a new version of Bluetooth technology which rather than replace its predecessor, Bluetooth BR/EDR, sat alongside it as an alternative with capabilities and qualities that made it perfect for a new generation of products and the ability to meet new and challenging technical and functional requirements.

Bluetooth LE supports topologies other than point to point communication between two devices with a variety of broadcast-based modes which allow one device to transmit data to an unlimited number of receivers simultaneously. It is also the foundation of Bluetooth mesh networking which allows networks of tens of thousands of devices to be created, each one able to communicate with any other device in the network.

One-to-one communication between two devices is supported by both connection-oriented communication and connectionless communication. One-to-many communication is supported by connectionless broadcasting.

The direction in which application data can be communicated depends on the way in which Bluetooth LE is used. Note that the term mode may be used here as shorthand for this. Some of the modes involve connection-oriented communication and some involve connectionless communication. Some modes support the bidirectional exchange of application data but in some cases, application data can only travel in one direction.

Usually, application data does not have a critical relationship with time but there are cases where it does, and a device must maintain that relationship when it processes received data. Bluetooth LE supports isochronous communication in both a connection-oriented and connectionless mode. Isochronous communication is designed for exactly those occasions where data is time-bound. Audio is a good example where this is the case.

Bluetooth LE has a number of device positioning features that are designed to be used by location related applications.

Direction Finding defines two distinct ways in which the direction of a transmitted signal can be calculated by the receiver. The two methods are called Angle of Arrival (AoA) and Angle of Departure (AoD).
Bluetooth^® Channel Sounding allows two devices to cooperate and one of the devices to securely calculate its distance from the other device.

One of the original design goals for this new Bluetooth technology variant was to be highly efficient in its use of energy. Devices which ran off small, coin-sized batteries for days or weeks or more were envisaged and that drive for energy efficiency explains many of the defining characteristics of Bluetooth LE. In particular, the design assigns asymmetrical capabilities and responsibilities to devices, seeking to ensure that devices with a relatively plentiful source of power such as a large smartphone battery do more of the heavy lifting than peer devices running on coin cell batteries. This and other design decisions like it made Bluetooth LE the low power wireless communications technology that it is and positioned it for widespread adoption in a multitude of types of products in the years that would follow.

4. The Bluetooth LE Specifications

A deep and thorough understanding of Bluetooth LE requires intimate familiarity with the applicable specifications. The architecture, procedures and protocols of Bluetooth LE are defined in full by one key specification called the Bluetooth Core Specification. How products use Bluetooth such that they are interoperable is covered by collections of specifications of two special types known as profiles and services. Figure 1 illustrates the Bluetooth LE specification types and their relationships.

Figure 1 – The Bluetooth LE specifications

4.1 The Bluetooth Core Specification

The Bluetooth Core Specification is the primary specification for both Bluetooth LE and Bluetooth Classic. This specification:

defines the architecture of Bluetooth technology and the layers of the various stack configurations.
describes and defines key features.
defines the formal procedures underpinning supported operations.
defines the protocols with which devices communicate between relevant layers of the stack.

The Bluetooth Core Specification is a necessarily large specification.

In summary the Bluetooth Core Specification defines how Bluetooth technology works and the requirements for developers when implementing a Bluetooth stack or one or more of its features.

4.2 Profile Specifications

When two Bluetooth LE devices are communicating over a connection, it is usually the case that a client / server relationship has been formed. Servers contain state data and clients use that data in some way.

Consider a Bluetooth key fob whose purpose is to help you find your keys after you’ve put them down somewhere and temporarily lost them. A smartwatch might act as the client device and the Bluetooth key fob would act as the server. Pressing a button on the smartwatch’s display could cause the key fob’s state to be changed and it to make a loud noise in response to this change so that you can find your keys again.

Profile specifications define the roles that related devices (like the smartwatch and key fob) assume and in particular, define the behavior of the client device and the data on the connected server that it should work with.

In the key finder example, the behavior of the smartwatch or some other device assuming the same role is defined in the Find Me Profile specification.

4.3 Service Specifications

State data on servers resides in formally defined data items known as characteristics and descriptors[2]. Characteristics and descriptors are grouped inside constructs known as services. Services provide a context within which to assign meaning and behaviors to the characteristics and descriptors that they contain.

A service specification defines a single service along with the characteristics and descriptors that it contains. The behaviors to be exhibited by the device hosting the service in response to various conditions and state data values are defined in the service specification.

A service specification can be thought of as defining one aspect of a server device’s behavior.

In the smartwatch and key fob example, the key fob, is acting as a server and implements the Immediate Alert Service.

4.4 Protocol Specifications

Some standardized Bluetooth applications require their own protocols, and these protocols have their own specifications. The primary Bluetooth Mesh specification is a protocol specification.

4.5 Assigned Numbers

Various aspects of Bluetooth LE make use of unique identifiers. For example, all services, characteristics and descriptors have a universally unique identifier (UUID) which identifies the type of the service, characteristic or descriptor to which it relates rather than a particular instance on a particular device. A company may be identified by a unique company identifier, something which is required by certain profiles.

Identifiers allocated by the Bluetooth SIG are known as assigned numbers and a full list of such identifiers can be obtained from the Assigned Numbers page on the Bluetooth SIG website.

5. The Bluetooth LE Stack

5.1 High-Level Architecture

The Bluetooth LE stack consists of a number of layers and functional modules, some of which are mandatory and some of which are optional. These parts of the stack are distributed across two major architectural blocks known as the host and the controller and a standard logical interface defines a way in which these two components may communicate.

The host is often something like an operating system. The controller is often a system on a chip. This is not necessarily the case however and the Bluetooth specifications do not mandate any such implementation details. What’s important is that the host and controller act as separate logical containers in the architecture which may be implemented in physically separate components in some way, with a standard interface defined for communication between them. This allows a Bluetooth system to consist of host and controller components from different manufacturers.

Figure 2 illustrates the Bluetooth LE stack, its layers and their distribution across the host and controller components.

The Host Controller Interface (HCI) indicates the logical interface between them but is not a physical component as such. HCI can be implemented in a number of different ways in terms of the underlying physical transport, but the logical or functional interface is always the same.

LC3 is the Low Complexity Communication Codec, the default audio codec used with Bluetooth LE Audio. It is not part of the standard Bluetooth LE stack as such but will always be found in LE Audio products, with the LC3 component either implemented in the host or in the controller as shown.

Figure 3 illustrates the standard OSI reference model for communications systems. It should be noted that the Bluetooth LE stack spans all layers of the OSI reference model in contrast to many other wireless systems which span a subset of the OSI layers only, such as the physical and data link layers. One advantage that Bluetooth technology has through being a full stack communication system is that there are no external dependencies on other standards bodies. Such dependencies can constrain the evolution of a technology.

Figure 2 – The Bluetooth LE stack

Figure 3 – The OSI Reference Model

The Bluetooth mesh protocol uses the Bluetooth LE core capabilities and adds to the Core Host a collection of specialized layers that implement the Bluetooth mesh protocols and procedures. The host may include any of the layers shown in the host part of Figure 2 that are required to support other product requirements such as the ability to form connections.

This resource does not cover Bluetooth mesh any further and those looking for an educational resource on this subject should consult section 18. Additional Resources below.

Figure 4 – The Bluetooth Mesh stack

5.2 The Layers at a Glance

A summary of the key responsibilities and features of each layer of the Bluetooth LE stack as depicted in Figure 2 is as follows:

Layer	Key Responsibilities
Physical Layer	Defines all aspects of Bluetooth technology that are related to the use of radio (RF) including modulation schemes, frequency bands, channel use, transmitter and receiver characteristics.Several distinct, supported combinations of physical layer parameters are defined and are referred to as PHYs.
Link Layer	Defines air interface packet formats, bit stream processing procedures such as error checking, a state machine and protocols for over-the-air communication and link control.Defines several distinct ways of using the underlying radio for connectionless, connection-oriented and isochronous communication known as logical transports.
Channel Sounding	Provides a device with the ability to take measurements which may be used by the application layer to calculate the distance to another device. Two distinct methods are incorporated, namely phase-based ranging (PBR) and round-trip timing (RTT). These methos may be used in conjunction or separately.
Isochronous Adaptation Layer(ISOAL)	Allows different frame durations to be used by devices using isochronous communication.Performs segmentation and reassembly of framed PDUs or fragmentation and recombination of unframed PDUs.
Host Controller Interface(HCI)	Provides a well-defined functional interface for bi-directional communication of commands and data between the host component and the controller.Supported by any one of several physical transport implementations.
Logical Link Control and Adaptation Protocol(L2CAP)	Acts as a protocol multiplexer within the host, ensuring protocols are serviced by the appropriate host component.Performs segmentation and reassembly of PDUs/SDUs between the layer below and the layer above L2CAP.
Security Manager Protocol(SMP)	A protocol used during the execution of security procedures such as pairing.
Attribute Protocol(ATT)	A protocol used by an ATT client and an ATT server which allows the discovery and use of data in the server’s attribute table.
Generic Attribute Profile(GATT)	Defines high level data types known as services, characteristics and descriptors in terms of underlying attributes in the attribute table.Defines higher level procedures for using ATT to work with the attribute table.
Generic Access Profile(GAP)	Defines operational modes and procedures which may be used when in a non-connected state such as how to use advertising for connectionless communication and how to perform device discovery.Defines security levels and modes.Defines some user interface standards.

6. The Physical Layer

The physical layer of Bluetooth LE defines how the radio transmitter/receiver is used to encode and decode digital data for transmission and receipt, and other radio-related parameters and properties which apply.

6.1 Frequency Band

Bluetooth LE operates in the 2.4GHz unlicensed band in the range 2400 MHz to 2483.5 MHz which is divided into 40 channels, each with a width of 2 MHz. How channels are used is defined by the Link Layer and the data transport architecture.

Figure 5 – Bluetooth LE channels

6.2 Modulation Schemes

6.2.1 Gaussian Frequency Shift Keying

To encode digital data from higher layers of the stack before transmission and to decode radio signals received, Bluetooth LE uses a modulation scheme called Gaussian Frequency Shift Keying (GFSK). GFSK works by taking a signal with the central frequency of the selected channel (the carrier) and shifting it up by a specified amount to represent a digital value of 1 or down by the same amount to represent a binary value of 0. Gaussian filtering is applied to the signal to reduce noise which may accompany abrupt frequency changes.

Figure 6 illustrates the basic frequency shift keying process. Note that the amount by which the frequency is shifted is known as the frequency deviation and is at least +/-185 kHz or at least 370 kHz depending on the PHY variant in use (PHY is explained in section 6.3 PHY variants).

Figure 6 – Frequency Shift Keying in Bluetooth LE

6.2.2 Amplitude Shift Keying

Channel Sounding (see section 8.Bluetooth^® Channel Sounding) uses a modulation scheme called Amplitude Shift Keying (ASK) for some of its transmissions. ASK is a binary modulation scheme with two symbol states. The first is represented by the transmission of a fixed amplitude carrier-wave on a selected frequency for a specific period of time. The second is represented by the absence of a transmission on the selected frequency and during the relevant time period.

6.3 PHY variants

A number of modulation scheme variants are defined. Each variant is referred to as a PHY and has a name. Transmission speeds at the physical layer are measured in symbols per second rather than bits per second because the physical layer deals with analogue radio artefacts only, not digital concepts.

Bluetooth LE uses a binary modulation scheme meaning that a single analogue symbol represents a single digital bit higher in the stack.

Each PHY includes a property called the Bandwidth-Bit Period Product (BT). BT determines the relationship between a signal’s bandwidth and the duration of symbols.

The value of BT affects the shape and span of the radio pulses that constitute symbols. A higher BT value results in a narrower, squarer pulse and a lower value results in a wider, more rounded pulse shape.

The PHY types defined by the Bluetooth Core Specification are summarized as follows:

The LE 1M PHY uses a symbol rate of 1 Msym/s with a required frequency deviation of at least 185 kHz and uses no special coding. All devices must support the LE 1M PHY. BT=0.5 with this PHY.
The LE 2M PHY is similar to LE 1M but uses a symbol rate of 2 Msym/s and has a required frequency deviation of at least 370 kHz. Support for the LE 2M PHY is optional. BT=0.5 with this PHY.
The LE 2M 2BT PHY has a 2 Msym/s symbol rate but requires a frequency deviation of at least 420 kHz. BT=2 with this PHY.
The LE Coded PHY uses a symbol rate of 1 Msym/s but packets are subject to a coding called Forward Error Correction (FEC) which is defined in the Link Layer. FEC increases the effective range of transmissions but reduces the application data rate. Support for the LE Coded PHY is optional. BT=0.5 with this PHY.

A comparison of the PHYs follows:

	LE 1M	LE Coded S=2	LE Coded S=8	LE 2M	LE 2M 2BT
Symbol Rate	1 Ms/s	1 Ms/s	1 Ms/s	2 Ms/s	2 Ms/s
Protocol Data Rate	1 Mbit/s	500 Kbit/s	125 Kbit/s	2 Mbit/s	2 Mbit/s
Approximate Max. Application Data Rate	800 kbps	400 kbps	100 kbps	1400 kbps	N/A[3]
BT	0.5	0.5	0.5	0.5	2.0
Error Detection	CRC	CRC	CRC	CRC	N/A[4]
Error Correction	NONE	FEC	FEC	NONE	NONE
Range Multiplier (approx.)	1	2	4	0.8	0.8
Requirement	Mandatory	Optional	Optional	Optional	Optional

Definitions

Term	Definition
Symbol Rate	The rate at which analogue symbols are transmitted at the physical layer.
Protocol Data Rate	The transmission rate of bits relating to Bluetooth protocol data units (PDUs) including their application data payload but excluding FEC data which is included in packets when the LE Coded PHY is in use.
Approximate Max. Application Data Rate	An approximate maximum rate at which application data can be transferred between applications on communicating devices. Application data is transported in the payload part of various PDUs with the remainder of the protocol data rate being consumed by Bluetooth protocol data.
CRC	Cyclic Redundancy Check. A field used in the detection of transmission errors. This field and its use is defined in the Link Layer.

6.4 Time-Division

A Bluetooth LE radio is a half-duplex device, capable of transmitting and/or receiving but not both at the same time. However all PHYs are used in a Time Division Duplex (TDD) scheme so that the appearance of a full-duplex radio is given.

6.5 Transmission Power and Receiver Sensitivity

The Physical Layer defines transmitter characteristics including output power requirements for which the specification states that: the output power level at the maximum power setting shall be between 0.01 mW (-20 dBm) and 100 mW (+20 dBm).

Regulatory bodies[5] in different parts of the world may override these requirements and implementers must ensure that devices are compliant with applicable local regulations.

Receiver sensitivity is defined as the receiver input level for which a particular Bit Error Rate (BER) is experienced. The BER specified varies according to the length of a received packet because the Link Layer appends a single Cyclic Redundancy Check (CRC) field to each packet and uses this as a mechanism for detecting one or more bits in error in the decoded packet. Since packets vary in length, and there is one CRC per packet, the length of the packet affects the calculated BER.

A BER of 0.1% is typically quoted in discussions about Bluetooth LE receiver sensitivity. This is the maximum error rate that is permitted for packets up to 37 octets in length.

Other receiver characteristics defined by the Physical Layer include interference performance, out-of-band blocking, intermodulation characteristics, maximum usable input level and the required accuracy of received signal strength indications (RSSI).

6.6 Antenna Switching

6.6.1 Direction Finding

Bluetooth LE supports two methods of calculating the direction from which a received signal was transmitted. The first is called Angle of Arrival (AoA) and the second, Angle of Departure (AoD). Both methods involve one device having an array of antennae and a process of switching from one antenna to another during the transmission of direction-finding signals (AoD method) or when receiving signals (AoA method). Direction finding signals are standard Bluetooth packets which include a Constant Tone Extension (CTE) field.

Antenna arrays come in many different designs and switching from one antenna to the next can follow a range of different switching patterns. This is controlled by the host, but the physical layer also defines some generally applicable rules about the process of antenna switching, related receiver requirements and some useful definitions.

The Bluetooth Core Specification covers this topic in more detail in Volume 6, Part A, section 5. More information on the AoA and AoD direction finding feature can be found in the Bluetooth Core Specification version 5.1 Feature Overview paper.

6.6.2 Bluetooth Channel Sounding

Bluetooth Channel Sounding permits the use of more than one antenna in one or both of the two devices and has rules regarding antenna selection and use. See section 8.Bluetooth^® Channel Sounding.

7. The Link Layer

7.1 Overview of the Link Layer

The Link Layer specification is almost the largest of the Bluetooth LE sections of the Bluetooth Core Specification, second only to the Host Controller Interface Functional Specification section. Arguably though, it is the most complicated.

The Link Layer has many responsibilities. It defines several types of packet that are transmitted over the air and an associated air interface protocol. Its operation is subject to a well-defined state machine. Depending on the state, the link layer may operate in a number of quite different ways, driven by events of a number of types. Numerous control procedures which affect the state of a link or link usage parameters are defined. Radio channel selection and classification are defined in the link layer specification.

The link layer supports both connected and connectionless communication and deterministic and (slightly) randomized event timing. It supports both point-to-point communication between two devices and one-to-many communication from one device concurrently to an unlimited number of receiving devices. Depending on how the link layer it is used, the transfer of application data may be bidirectional, or it may travel in one direction only.

Much of the versatility of Bluetooth LE is rooted in the sophistication of the Link Layer.

7.2 Packets

The Link Layer defines two packet types. The first is used by the uncoded PHYs (see Figure 7), LE 1M and LE 2M and the second by the LE Coded PHY (see Figure 8). Note that other packet types are defined for use with Channel Sounding.

Figure 7 – Link layer packet format for the LE uncoded PHYs

Figure 8 – Link layer packet for the LE Coded PHY

Both packet types include the fields Preamble, Access Address, and CRC. Table 1 explains each of these common fields.

Link Layer Packet Field Name	Description
Preamble	The preamble allows the receiver to synchronize precisely on the frequency of the signal, perform automatic gain control and estimate the symbol timing.
Access Address	The access address is used by receivers to differentiate signals from background noise and to determine the relevance or otherwise of a packet to the receiving device. For example, a pair of connected devices exchange packets with the same randomly allocated access address. Devices not participating in the connection will ignore such packets since the access address is not one that is relevant to them. Similarly, all legacy advertising packets use the same access address with a value of 0x8E89BED6 which indicates that these packets may be received by all devices.
CRC	The Cyclic Redundancy Check is used for error detection. Its value is calculated by the transmitter using the value of the other bits in the packet. On receiving a packet, the receiving device also calculates a CRC value from the values of bits in the received packet apart from those making up the CRC field. The receiver’s calculated CRC is then compared with the value of the CRC field in the packet. If the two CRC values match, then the packet was received correctly. If not, it is deemed to contain one or more bits in error.

Table 1 – Common Link Layer Packet Fields

The PDU field of Link Layer packets may contain a variety of different Protocol Data Units (PDUs) depending on how Bluetooth LE is being used. The Constant Tone Extension (CTE) is only present when one of the two direction finding methods (Angle of Arrival or Angle of Departure) is in use.

The PDU and CRC fields are subjected to a process called whitening before the packet is transmitted. The purpose of whitening is to avoid long sequences of zeroes or ones in packets as this can cause the receiver’s frequency lock to drift. The whitening process is reversed by the receiver to restore the original bit stream before the CRC is checked.

The PDU field may be encrypted in which case it includes a Message Integrity Check field which protects against the PDU being tampered with[6].

When the LE Coded PHY is in use, the bit stream is subject to additional processing before transmission. The application of a Forward Error Correction (FEC) encoder followed by a Pattern Mapper generates additional data which is used by the receiver when applying these processes in reverse and where possible, correcting the value of any bits that have the incorrect value.

7.3 State Machine

The Link Layer is governed by a state machine which is shown in Figure 9.

Figure 9 – The Link Layer State Machine

Refer to the Link Layer specification for full details of each state. A summary is presented in Table 2. Note that some terminology will be explained later in this section.

State	Description
Standby	Device neither transmits nor receives packets.
Initiating	Responds to advertising packets from a particular device to request a connection.
Advertising	Transmits advertising packets and potentially processes packets sent in response to advertising packets by other devices.
Connection	In a connection with another device.
Scanning	Listening for advertising packets from other devices.
Isochronous Broadcast	Broadcasts isochronous data packets.
Synchronization	Listens for periodic advertising belonging to a specific advertising train transmitted by a particular device.

Table 2 – Link Layer states

When in the Connection state, two important device roles are defined. These are the Central role and the Peripheral role. A device which initiates a connection and transitions from the Initiating state to the Connection state assumes the Central role. A device which accepts a connection request, transitioning from the Advertising state to the Connection state assumes the Peripheral role.

Consider for example, a heart rate monitor which transmits measurements to a smartphone for use by an application. Typically, the smartphone would assume the Central role and the heart rate monitor the Peripheral role. The smartphone discovers the monitor by scanning for its advertising packets and then, usually with the involvement of the user, initiates a connection to it. Once connected, following additional procedures defined in the heart rate profile specification, the smartphone application instructs the monitor to start sending measurements over the connection.

An instance of the state machine may only be in one state at a time. A link layer implementation may support more than one state machine instance concurrently.

Not all role and state combinations are permitted. The Bluetooth Core Specification has more details on this.

7.4 Channel Selection

As described in section 6.1 Frequency Band, Bluetooth LE divides the 2.4 GHz frequency band into 40 channels. The Link Layer controls how those channels are used and this in turn depends on the overall way in which Bluetooth LE is being used for communication (more formally, the current physical channel – this is covered in section 7.7 The Data Transport Architecture).

Bluetooth LE uses spread spectrum techniques in various different ways to communicate data via multiple channels over the course of time. This reduces the chances of collisions, making communication more reliable.

One well known example of a spread spectrum technique used in Bluetooth LE is that of adaptive frequency hopping. This involves the radio channel used for packet communication changing at regular intervals. Channels are chosen using a channel selection algorithm and a table of data called the channel map which classifies each channel as either used or unused. Implementations can monitor the quality of communication on each channel and if a channel is found to be performing badly, perhaps due to interference from other sources, the channel map can be updated to set that channel’s classification to unused and this ensures that this channel is no longer selected by the algorithm. In this way, channel selection algorithm adapts to the conditions being experienced and optimizes for the most reliable performance.

How radio channels are used will be described further when discussing Bluetooth LE logical transports and their associated physical channels below.

7.5 Filter Policies

The Link Layer has the ability to filter received packets using various criteria so that higher layers of the LE stack are not encumbered with irrelevant PDUs to process. The criteria to be applied in deciding whether to filter and discard packets or select them for further processing is defined and implemented by a number of Link Layer filter policies. There are separate filter policies for each of the Link Layer advertising, scanning, initiating and periodic sync establishment states.

Filter policies operate in a mode of which a number are defined for the different Link Layer states. The default mode in all cases results in no packet filtering taking place. Other modes often make use of a list of device addresses called the Filter Accept List. In these cases, packets from devices whose address is a member of the Filter Accept List will probably not be filtered although there are other details to the conditions applied in the various modes and the Bluetooth Core Specification should be consulted for details. This however is the basic principle that is at work in most cases.

Applications can populate the Filter Accept List and configure the filter policy modes for the different Link Layer states using HCI commands.

A set of special filter policy modes called the decision scanning filter policy modes are defined, and their use is referred to as Decision-Based Advertising Filtering (DBAF). DBAF allows more sophisticated filtering conditions than simply checking for membership of the filter accept list to be formulated.

DBAF modes apply only to the scanning filter policy and only to certain types of advertising PDUs received on the primary channels. Filtering that may be brought about by a decision scanning filter mode applies to extended advertising packets only and more information on this subject can be found in section 7.7.2.3.7 Decision-Based Advertising Filtering.

7.6 Monitoring Advertisers

7.6.1 Filtering and Presence

Advertising can be used as a connectionless communication transport but probably its most common use is to enable device discovery.

Device discovery involves scanning for advertising packets. Receiving advertising packets serves as an indication that the advertising device is present and depending on the type of advertising PDU, may indicate that the device is available to be connected to.

Advertising packets are handled by the LE controller, with details defined in the Link Layer specification. The Host layers of the stack are informed of the arrival of advertising packets and their content using events sent via the Host Controller Interface.

A device can advertise anything from once every 20 milliseconds to once every 10.24 seconds and with every received packet generating an HCI event, and perhaps every event resulting in a call to a function in an application, advertising can place a lot of load on the physical HCI transport, the Bluetooth LE Host and on the application. Fortunately, there’s a way to avoid this.

When advertising is performed solely for the purpose of device discovery, the content of packets typically does not change. An application wishing to receive calls relating to advertising packets being received uses one of several HCI commands to instruct the controller accordingly. These HCI commands allow the application to indicate whether or not it wishes to receive duplicates by setting an aptly named HCI command parameter, Filter_Duplicates. With duplicate filtering specified, an HCI event and associated call to the application happens only once per advertising device.

However, there’s a potential downside to filtering duplicates. With duplicates unfiltered, an application generally knows whether a device of interest is still within range or not. If the application stops receiving advertising data for the device, it can be assumed that it is no longer in range. But with duplicate filtering enabled, the absence of HCI advertising events is no longer an indicator that the device has gone out of range. It’s just as likely that it is broadcasting duplicate packets and that these are being filtered.

This loss of awareness of the presence of a device becomes a particular problem when it comes to establishing connections. Imagine an application that scans for devices in range and presents the user with a list on a GUI from which to select. When the user makes a selection, the application requests a connection with the selected device. When a connection needs to be made, the LE controller must first perform high duty cycle scanning. This is so it can receive an advertising packet from the target device before replying to it on the same channel with a connect request. High duty cycle is an aggressive form of scanning which will receive advertising packets quickly but be costly in terms of the energy used. This is fine if the device to be connected to is still in range but if it has gone out of range in the time it took the user to make a selection, then this relatively expensive scanning operation is a waste of energy.

Sometimes it is not worth an application connecting to a device if the signal strength is low because, for example, this could be in indicator that the device is not close enough for the application’s use case to make sense. So, technically the device may still be present, but with a low signal strength, scanning to connect with it would be just as much a waste of energy as if it was actually out of range.

The Monitoring Advertisers feature allows duplicate advertising packets to be filtered but without losing the ability to keep track of whether or not a device is still present and whether or not its signal strength is sufficient to warrant connecting to it.

7.6.2 Using Advertising Monitoring

The LE controller maintains a list called the Monitored Advertisers List. Applications can use HCI commands to add a device of interest to the list together with a low RSSI (signal strength) threshold, a high RSSI threshold and a time out value. The application can also enable or disable advertiser monitoring using another command.

Table 3 explains the parameters that determine how advertiser monitoring will behave for a specified device.

Parameter(s)	Description
Address and Address Type	The address and address type of the device to be monitored. These two parameters allow the controller to identify and monitor the device.
RSSI Threshold Low	If the RSSI of all advertising packets from this monitored device stays at or below this value for the period of time indicated by the Time Out parameter then it is said that a loss-of-signal has occurred. When this happens, the controller notifies the host using an HCI LE Monitor Advertisers Report event. The state of this device is set to Awaiting RSSI High.
RSSI Threshold High	If the RSSI of an advertising packet received from this monitored device is greater than or equal to this value, and the device state is Awaiting RSSI High then the controller sends a HCI LE Monitor Advertisers Report event to the host to inform it that the device is in range. The state for this device is cleared or set to indicate that it is no longer awaiting an RSSI above the high threshold and the timer that is used to monitor for loss of signal is reset.
Time Out	A time in seconds used to monitor for signal loss. If no RSSI measurement exceeds the RSSI Threshold Low parameter in this period then loss-of-signal is said to have occurred.

Table 3 – Monitored Advertisers Parameters

The Monitoring Advertisers feature can be used irrespective of whether or not the controller has been instructed to filter duplicate advertisements but is clearly of the most benefit when it is used with duplicate filtering enabled.

Figure 10 depicts an example scenario involving the Monitoring Advertisers feature. The left-hand part of the diagram is a sequence diagram that shows advertising packets being received, HCI commands being used to configure advertising monitoring and then HCI events being used to indicate the advertising device moving in and out of range, based on the configured RSSI thresholds. The right-hand side shows the device signal strength varying and resultant state changes and HCI events.

Figure 10 – Monitoring Advertisers example

Table 4 explains the labeled points of interest in Figure 10.

Point	Explanation
A	The scanner’s host starts by asking the controller how many advertising devices it can monitor. The host then adds a device to the list along with RSSI low, RSSI high and timeout values (not shown). Finally, the host tells the controller to enable advertiser monitoring.
B	At this point the illustration starts to show advertising packets transmitted by the first device. Note that the device could have been advertising prior to this point but the packets are only shown from here. Received packets have an RSSI that is greater than the configured low threshold and so the timer for the monitored device is reset as each packet is received.
C	The next few packets received after point C have an RSSI that is lower than the low RSSI threshold and so it is at point C that the timer is last reset, and the timer runs from that point.
D	A series of low RSSI packets are now received and at point D, a timeout occurs. The controller indicates the loss of signal condition to the host by sending a LE Monitor Advertisers Report event with condition == 0x00. The device is now in the Awaiting High RSSI state in the monitoring advertisers list.
E	At point E, the first of a series of packets whose RSSI is above the low threshold is received. For each such packet, the timer is reset.
F	At point F, the RSSI value exceeds the RSSI High threshold. The host is informed that the monitored device is back in range with a sufficiently strong signal via a LE Monitor Advertisers Report event with condition == 0x01 sent by the controller. The device is no longer in the Awaiting High RSSI state.

Table 4 – Points of interest in the Monitoring Advertisers example

7.7 The Data Transport Architecture

The architecture section of the Bluetooth Core Specification defines a number of concepts which collectively constitute the Bluetooth data transport architecture. Key amongst these concepts are the Physical Channel, Physical Link, Logical Link and Logical Transport. Certain combinations are defined for use in support of different application types, each with particular requirements regarding issues such as topology, timing, reliability and channel use.

A Physical Channel defines one of several different ways of communicating using Bluetooth. For example, communication can take place between two connected devices using the LE Piconet Physical Channel, which involves adaptive frequency hopping across 37 channels. Alternatively, the LE Advertising Physical Channel can be used for broadcast, connectionless communication from one device to an unlimited number of other devices. The LE Periodic Physical Channel can be used to broadcast data too, but on a regular basis with a deterministic time schedule. Observer (receiver) devices are able to determine that time schedule and use it to synchronize their scanning schedules.

A Physical Link is based on a single physical channel and specifies certain characteristics of that link such as the use or otherwise of power control.

Logical links and transports have various parameters which are designed to provide a suitable means of supporting a particular set of data communication requirements over a physical link, using a particular physical channel type.

For example, reliable, bi-directional, point to point communication in Bluetooth LE uses the LE asynchronous connection-oriented logical (ACL) transport with either a LE-C link for control data or a LE-U link for user data, over a physical link based on the LE Piconet Physical Channel.

On the other hand, unreliable, unidirectional broadcast communication in Bluetooth LE uses the LE Advertising Broadcast (ADVB) logical transport with either an ADVB-C link for control data or an ADVB-U link for user data, over a physical link based on the LE Advertising Physical Channel.

7.8 The Logical Transports

7.8.1 LE ACL – LE Asynchronous Connection-Oriented Logical Transport

7.8.1.1 Basics

When two Bluetooth LE devices are connected they are using the asynchronous connection-oriented logical transport (LE-ACL or simply ACL). LE-ACL is one of the most commonly used Bluetooth LE logical transport types, providing for connection-oriented communication of data. In fact, ACL connections are generally referred to simply as connections.

A device may establish a connection with an advertising device by responding to a received advertising packet with a PDU that requests a connection. A number of parameters are specified in the request. Amongst these parameters are access address, connection interval, peripheral latency, supervision timeout and channel map.

The device requesting the connection transitions from the Standby state to the Initiating state and then enters the Connection state and assumes the Central role. The other device transitions from Advertising to Connection and assumes the role of Peripheral.

The connection interval parameter defines how often in milliseconds, the radio can be used for servicing this connection. Whenever the connection interval expires, a connection event is said to begin and at this point, the Central device in the connection may transmit a packet. Connection events for a given connection each have a 16-bit identifier which is a counter value, incremented at each event. At the start of each connection event, the radio channel to be used is selected using the applicable channel selection algorithm.

The supervision timeout parameter specifies the maximum time which may elapse between two Link Layer data packets having been received before the link is considered to have been lost.

The Peripheral device, possessing the same agreed connection parameters as the Central device knows when to expect transmitted packets from the Central device and over which channel and so may choose to listen on that channel at precisely the same time and therefore receive the packet from the Central. After receiving the last bit of the Central’s packet, the Peripheral waits for a short period of time (default 150 microseconds) and then may reply to the Central device. Note that the period of time between packet transmissions in called the inter-frame space time (IFS).

Central and Peripheral then take turns, alternating between transmitting and receiving packets and may exchange an implementation-defined number of packets during the connection event. The Peripheral’s behavior may be modified by a non-zero Peripheral Latency parameter value.

Figure 11 shows a basic exchange of packets, during two connection events with C>P indicating packet transmission by the Central device and P>C by the Peripheral.

Figure 11 – Basic packet exchange over an LE-ACL connection

Packets exchanged over an LE ACL connection contain either LL Data PDUs or LL Control PDUs which are associated with Link Layer control procedures.

7.8.1.2 Ordering and Acknowledgements

LE-ACL incorporates a system which ensures that data is processed in the right order, that the receipt of packets can be acknowledged, and for this to be used to decide whether to move on to the next packet or instead, to retransmit the previous one.

Data packets contain three important fields which contribute to communication being reliable. These fields are called the Sequence Number (SN), Next Expected Sequence Number (NESN), and the More Data field. All three of these fields are single bit fields and their use provides a system of acknowledgements and a method for checking for the correct ordering of received packets.

Communication starts with the Central device (Device A) sending a link layer data packet with SN and NESN both set to zero. From this point on, at each packet exchange that takes place, if all is well, the value of the SN field as set by Device A, will alternate between zero and one. The Peripheral device (Device B) always knows therefore, what the SN value of the next packet to be received should be and checks for this.

If Device B receives a packet from Device A with the expected SN value, it responds with a link layer data packet that has NESN set to the logical value NOT(SN). So for example, if the received SN value was 1 then NESN in the response will be 0.

When Device A receives a response from Device B with NESN set to the value that Device A intends to use for SN in its next packet, Device A takes this to be an acknowledgement from Device B, confirming that it received the last transmitted packet correctly. Figure 12 shows this.

Figure 12 – A successful exchange of packets at the link layer

If Device B receives a packet with the wrong SN value, it assumes that the packet is the retransmission of the previous packet received, acknowledges it but does not pass it up the stack for further processing.

If Device A receives an unexpected NESN value in a reply from Device B or does not receive a reply at all, it resends the packet with the same SN value used originally. Different controller implementations are free to implement varying algorithms regarding how many times to resend before concluding communication to have failed. See Figure 13.

Figure 13 – Link Layer retransmissions

Each packet contains a CRC field, and encrypted packets also contain an MIC field. On receiving a packet, the link layer checks the CRC and if present, the MIC. If either check fails, the packet is not acknowledged, and this generally results in the originator of the packet resending it. See Figure 14.

Figure 14 – Link Layer handling CRC failure

7.8.1.3 Peripheral Latency

The Peripheral is not required to listen for packets from the Central device during every connection event. The peripheral latency parameter defines the number of consecutive connection events during which the Peripheral does not have to be listening. This allows the Peripheral to save power.

Figure 15 shows the behavior of the Peripheral with peripheral latency = 1 and therefore listening during alternate connection events only. The Central may transmit during those events where the Peripheral is not listening, but such packets will not be received and therefore will not be acknowledged, ending the connection event.

Figure 15 – An ACL connection with Peripheral Latency = 1

7.8.1.4 Channel Use

LE-ACL employs a scheme known as adaptive frequency hopping. At the start of each connection event, frequency hopping occurs, with a radio channel being deterministically selected from the set of available channels using a channel selection algorithm. Each device in the connection will then switch to the selected channel and over time and a series of connection events, communication will take place using a frequently changing series of different channels, distributed across the 2.4 GHz band, thereby significantly reducing the probability of collisions occurring.

Of the 40 channels defined for use by Bluetooth LE, 37 of these channels (known as the general-purpose channels) are available for use by an LE-ACL connection.

In a given environment, some Bluetooth radio channels might not be functioning well, perhaps because interference is impacting them, whereas other channels are working reliably. Over time, the list of reliable channels and unreliable channels may change, as other wireless communication devices in the environment come and go.

The Central device in a connection maintains a channel map which classifies the general-purpose channels as used or otherwise as unused. This channel map is shared with the Peripheral using a link layer procedure so that they each have the same information about which channels will be used and which will not. The channel selection algorithm ensures that channels designated as unused are avoided.

By default, all general-purpose channels are designated used but Central devices may use implementation-specific techniques to monitor how well each channel is functioning. If the Central device determines that one or more channels are not working well enough, it can update their classification in the channel map to unused. Conversely, if a previously bad channel is found to be working well now, its classification can be updated in the channel map to used. Channel map updates may then be shared with the Peripheral device.

A Peripheral may also perform its own channel monitoring and at intervals, send channel status reports to the Central device, with each channel’s status classified as good, bad or unknown. The Central may then make decisions about channel classification in the channel map that take into account both its own radio conditions and those being experienced by the remote Peripheral device.

In this way, it is possible for a Bluetooth LE device to use only the optimal subset of available channels and so for example, coexist effectively with other wireless technologies that use statically allocated channels. This is the adaptive aspect of the Bluetooth adaptive frequency hopping system.

Note: Regulatory bodies may define adaptive frequency hopping and related terminology differently to the Bluetooth Core Specification. It is recommended that regulations regarding spectrum use in target markets are reviewed early in the product development lifecycle as this may inform certain implementation decisions. See section 18. Additional Resources for a link to the Bluetooth SIG’s Regulatory Aspects Document which provides guidance on regulatory matters.

Figure 16 shows the way in which channels were used by two connected devices during testing and illustrates the way in which radio use is spread across the ISM 2.4 GHz spectrum. At the bottom of the chart you can see the channel index and frequencies in MHz. The channel index is an indirect way of referencing a radio channel.

Figure 16 – Adaptive Frequency Hopping distributing communication across channels

7.8.1.5 Link Layer Control

The Link Layer specification specifies a number of control procedures. A selection of examples appear in Table 5.

Control Procedure	Description
Connection Update	Allows either the Central or Peripheral device to request changes to the connection parameters connection interval, peripheral latency and supervision timeout.
Channel Map Update	Allows the Central device to transfer its latest channel map data to the connected Peripheral.
Encryption	Allows either Central or Peripheral to enable the encryption of packets.
Feature Exchange	Allows Central or Peripheral to initiate an exchange of the Link Layer features each device supports, encoded as a bitmap field.
Periodic Advertising Sync Transfer	Allows either Central or Peripheral to transfer periodic advertising[7] synchronization information relating to a periodic advertising train that has been discovered to the other device over an LE ACL connection.
CIS Creation Procedure	Allows a Central device to create a Connected Isochronous Stream (CIS)[8] with the Peripheral.
Power Control Request	Allows one peer to request that the other peer adjust its transmit power level.
Channel Classification Reporting	Allows a Peripheral to report channel classification data to the connected Central.

Table 5 – Example Link Layer control procedures

7.8.1.6 Subrated Connections

Subrated connections are LE ACL connections which have additional properties assigned to them and behave differently in some ways. The additional properties are called the subrate factor, subrate base event, and continuation number.

The subrated connection properties provide a mechanism for indicating that only a specific subset of connection events are to be actively used by the connected devices, with the radio not being used in other connection events. A subrated connection can therefore have a short ACL connection interval but still exhibit a low duty cycle.

Figure 17 illustrates the basic concepts relating to subrated connections

Figure 17 – A basic subrated connection with subrate factor=5

Here we can see that only one in every five connection events is used. The other four are skipped and so there is no radio activity during those connection events. This ratio of used to skipped connection events is determined by the subrate factor parameter and in this example it is set to 5.

The connection event during which the radio is used to transmit and receive link layer packets is known as a subrated connection event.

Given the relationship between the underlying ACL connection parameters and those that govern connection subrating, a subrated connection can be thought of as having both a connection interval which controls the frequency at which ACL connection events occur and an effective connection interval, which determines how often those ACL connection events are actually used, after the subrating parameters have been applied.

Subrated connections use a different set of Link Layer control procedures and in particular, the procedure for updating subrated connection parameters works differently to the general Control Update procedure. Critically, changes to subrated connection parameters can be applied almost instantaneously whereas general parameter changes can take a significant amount of time to take effect. The advantage of subrated connections therefore is that persistent connections which exhibit a low duty cycle and consume little power can be established and can be switched to a high duty cycle, high bandwidth connection with no delay that any user could notice. This capability has particular applicability in some LE Audio scenarios such as those involving hearing aids and smartphones.

The Bluetooth Core Specification Version 5.3 Feature Enhancements paper has a substantial chapter dedicated to the subject of subrated connections and is recommended as a source of further information.

7.8.2 ADVB – LE Advertising Broadcast

7.8.2.1 Basics

LE Advertising Broadcast (or simply advertising) provides a connectionless communication mode. It may be used to transfer data or to indicate the availability of a Peripheral device to be connected to.

Generally, advertising packets are intended to be received by any scanning device in range and as such, advertising may be used to concurrently transfer data to multiple scanning devices in a one-to-many topology. A special form of advertising known as directed advertising is defined however and this allows the connectionless communication of data from one advertising device to one specific scanning device, identified by its Bluetooth device address.

Advertising, as it applies to the ADVB logical transport, supports the communication of application data in one direction only, from the advertising device to scanning devices but such devices may reply to advertising packets with PDUs that request further information or for a connection to be formed. When a scanning device replies to obtain further information, it is said to be performing active scanning. When it does not, it is said to be performing passive scanning.

Advertising is generally referred to as an unreliable transport since no acknowledgements are sent by receivers.

Two categories of advertising procedure are defined and are referred to in the Bluetooth Core Specification as legacy advertising and extended advertising.

7.8.2.2 Legacy Advertising

7.8.2.2.1 Channel Use and Packet Size

Legacy advertising packets using the ADV_IND PDU type (see 7.8.2.2.3 Legacy Advertising and Associated PDU Types) are 37 octets long with a 6 octet header and a payload of at most 31 octets. Identical copies of advertising packets are transmitted on up to three dedicated channels numbered 37, 38 and 39 known as the primary advertising channels, one channel at a time and in some sequence.

Figure 18 – legacy advertising and channel use

7.8.2.2.2 Scheduling

The transmission of an advertising packet takes place whenever an advertising event occurs. The scheduling of advertising events is controlled by timing parameters and in the basic case is deliberately made slightly irregular so as to avoid persistent collisions with other advertising devices. A value known as advDelay is assigned a pseudo-random value in the range 0 – 10ms at each advertising event and this is added to the regular advertising interval (advInterval) so that advertising events are perturbed in time. Figure 19 reproduces Figure 4.5 from Volume 6 Part B of the Bluetooth core specification and illustrates the effect of the advDelay parameter.

Figure 19 – Advertising events perturbed in time using advDelay

Scheduling advertising events in this way helps avoid collisions but makes it harder for receivers to efficiently receive advertising packets, requiring a higher RX duty cycle to accommodate the unpredictable timing of advertising events.

7.8.2.2.3 Legacy Advertising and Associated PDU Types

Several PDU types are defined for use with legacy advertising. Different types of PDU are used for undirected advertising, where packets are destined for any scanning device and for directed advertising, where packets are addressed to one specific device. The PDU type also indicates whether or not active scanning is allowed, with receivers replying with requests for further data and whether or not the advertising device may be connected to. All legacy advertising takes place on one or more of the primary channels numbered 37, 38 and 39 and may only use the LE 1M PHY.

Table 6 lists the legacy advertising PDUs.

PDU Name	Description	Channels	PHY(s)	Transmitted By	Scannable	Connectable
ADV_IND	Undirected advertising	primary	LE 1M	Peripheral	Y	Y
ADV_DIRECT_IND	Directed advertising	primary	LE 1M	Peripheral	N	Y
ADV_NONCONN_IND	Undirected, non-connectable, non-scannable advertising	primary	LE 1M	Peripheral	N	N
ADV_SCAN_IND	Undirected, scannable advertising	primary	LE 1M	Peripheral	Y	N
SCAN_REQ	Scan request	primary	LE 1M	Central	N/A	N/A
SCAN_RSP	Scan response	primary	LE 1M	Peripheral	N/A	N/A
CONNECT_IND	Connect request	primary	LE 1M	Central	N/A	N/A

Table 6 – Legacy Advertising PDUs

Section 4.4 of the Link Layer Specification chapter within the Bluetooth Core Specification gives full details of all advertising PDU types.

7.8.2.3 Extended Advertising

Bluetooth Core Specification version 5 introduced some major changes to how advertising can be performed. Eight new PDUs relating to advertising, scanning, and connecting were added and new procedures defined. Collectively this new set of advertising capabilities is known as extended advertising.

Extended advertising allows much larger amounts of data to be broadcast, advertising to be performed to a deterministic schedule and multiple distinct sets of advertising data governed by different configurations to be transmitted. It offers significant improvements regarding contention and duty cycle too.

Extended advertising is used by both the ADVB and the PADVB logical transports.

7.8.2.3.1 Channel Use and Packet Size

Radio channels are used differently to the way they are used when performing legacy advertising with primary advertising channels 37, 38 and 39 carrying less data and general-purpose channels 0 – 36 carrying most of the data.

As described in 7.8.2.2 Legacy Advertising, legacy advertising transmits the same payload up to three times on three different primary advertising channels. Extended advertising transmits payload data once only, with small headers referencing it from the primary channels. The total amount of data transmitted is therefore less than in the equivalent case using legacy advertising and so the effective duty cycle is reduced.

Figure 20 – Reduced contention and duty cycle

Extended advertising allows packets to be up to 255 octets long. This is accomplished in part through offloading the payload to one of the general-purpose channels in the 0-36 channel number range.

Figure 21 – Extended advertising supports larger advertising packets and channel offload

When performing extended advertising only header data is transmitted on the primary channels numbered 37, 38 and 39. This includes a field called AuxPtr.

The AuxPtr field references an associated auxiliary packet containing the payload which will be transmitted on a general-purpose channel from the set of channels numbered 0 – 36. AuxPtr includes the general-purpose channel index indicating the channel that the auxiliary packet will be transmitted on so that receivers know where to find it. Packets transmitted on a general-purpose channel and referenced by the AuxPtr field from a packet on the primary channels are known as subordinate packets whilst the referencing packet is known as a superior packet.

Selection of channel index values in AuxPtr is implementation-specific with the Bluetooth Core Specification only recommending that “sufficient channel diversity is used to avoid collisions”.

7.8.2.3.2 Packet Chaining

For those use cases where an application needs to broadcast even more data (up to 1,650 bytes), it is possible for the controller to fragment data and chain packets together with each packet containing a subset of that data. Each chained packet can be transmitted on a different channel, with the AuxPtr header field referencing the next in the chain. Figure 22 illustrates this.

Figure 22 – Extended advertising with packet chaining

7.8.2.3.3 Advertising Sets

Legacy advertising does not make formal provision for advertising payload and parameters to vary. Extended advertising includes a standard mechanism for having multiple, distinct sets of advertising data.

Advertising sets have an ID which is used to indicate which set a given packet belongs to and each set has its own advertising parameters, such as its advertising interval and the PDU type to be used.

The task of scheduling and transmitting the different sets falls to the Link Layer in the Controller rather than it having to be driven by the Host, which would be far less power efficient. The Host needs only to inform the Controller of the advertising sets and their respective parameters initially, after which the Link Layer takes over.

7.8.2.3.4 Periodic Advertising

Extended advertising includes a method of advertising which uses deterministic scheduling, the details of which may be discovered and synchronized to by scanning devices. This is called Periodic Advertising. Periodic Advertising is defined as a distinct logical transport and so is described in section 7.8.3 PADVB – LE Periodic Advertising Broadcast.

7.8.2.3.5 Extended Advertising and Associated PDU Types

A number of PDU types are defined for use with extended advertising. Table 7 lists the extended advertising PDUs.

PDU Name	Description	Channels	PHY(s)	Transmitted By
ADV_EXT_IND	Extended advertising	primary	LE 1M, LE Coded	Peripheral
ADV_DECISION_IND	Decision PDU	primary	LE 1M, LE Coded	Peripheral
AUX_ADV_IND	Subordinate extended advertising	general-purpose	LE 1M, LE 2M, LE Coded	Peripheral
AUX_CHAIN_IND	Additional advertising data	general-purpose	LE 1M, LE 2M, LE Coded	Peripheral
AUX_SYNC_IND	Periodic advertising synchronization	periodic	LE 1M, LE 2M, LE Coded	Peripheral
AUX_SCAN_REQ	Auxiliary scan request	general-purpose	LE 1M, LE 2M, LE Coded	Central
AUX_SCAN_RSP	Auxiliary scan response	general-purpose	LE 1M, LE 2M, LE Coded	Peripheral
AUX_CONNECT_REQ	Auxiliary connect request	general-purpose	LE 1M, LE 2M, LE Coded	Central
AUX_CONNECT_RSP	Auxiliary connect response	general-purpose	LE 1M, LE 2M, LE Coded	Peripheral

Table 7 – Extended Advertising PDUs

The payload of PDUs of type ADV_EXT_IND, AUX_ADV_IND, AUX_SCAN_RSP, AUX_SYNC_IND, AUX_CHAIN_IND and AUX_CONNECT_RSP are defined by the same format known as the Common Extended Advertising Payload Format. This includes fields such as the AuxPtr field and AdvMode. AdvMode uses two bits to indicate the connectable and scannable properties of the advertising mode rather than distinct PDU types.

Section 4.4 of the Link Layer Specification chapter within the Bluetooth Core Specification gives full details of all advertising PDU types.

7.8.2.3.6 Scheduling

Extended advertising takes place in extended advertising events. An extended advertising event starts at the same time as an advertising event and includes the superior packet with an AuxPtr field and the subordinate packets related to it.

7.8.2.3.7 Decision-Based Advertising Filtering

Distractions

When an ADV_EXT_IND PDUs is received, the scanner will always follow the AuxPtr field and scan for the associated subordinate PDU (e.g. an AUX_ADV_IND PDU). For some applications this can be an inefficient behavior that negatively impacts receiver performance on the primary channels.

Consider the following scenario:

Scanner receives an ADV_EXT_PDU
Scanner uses information in the AuxPtr field to switch to scanning on the indicated secondary channel.
Scanner receives an AUX_ADV_IND PDU as expected.
Application layer receives the extended advertising PDU but checks the AdvData payload field only to find that the application data was of no relevance or interest to the application at this time.

What happened here is called a distraction. There was no way of knowing in advance whether the payload in the extended advertising PDU would be useful to the application without scanning for it and then passing it to the application for evaluation. And while scanning was taking place on the secondary channel indicated by AuxPtr, the primary channels were not being scanned and so it’s possible that other ADV_EXT_IND PDUs were missed. As can be seen, in this circumstance and for some applications, distractions can be problematic.

DBAF solves the problem of distractions.

DBAF and the Advertising Device

When DBAF is in use, the advertising device transmits ADV_DECISION_IND PDUs on the primary channels instead of ADV_EXT_IND PDUs.

Figure 23 – ADV_DECISION_IND

The Decision Data field is expanded in Figure 24.

Figure 24 – The ADV_DECISION_IND Decision Data field

The Resolvable Tag field contains an application allocated hash value that is used as a label for PDUs belonging to that application. This provides a simple way for the scanner to identify those cases where the scanner should follow AuxPtr and scan for associated auxiliary PDUs. Future profiles are expected to define ways in which key values used to create Resolvable Tag hash values can be shared between devices.

Other data upon which to make decisions can be included in the Arbitrary Data field.

DBAF and the Scanning Device

The application on the scanning device can formulate logical tests that the controller must evaluate against ADV_DECISION_PDUs to decide whether or not to scan on the secondary channel for related auxiliary PDUs. Tests can apply to the data in the Decision Data field of ADV_DECISION_IND PDUs or to other fields such as the advertising mode field, AdvMode. In addition, the received signal strength indicator (RSSI) can be included in decision tests.

Test requirements are conveyed to the controller via HCI commands that the application invokes. Tests can be grouped, and groups can form elements of relatively complicated composite conditions that involve logical AND or logical OR operations. For example:

(group 1 test 1) AND (group 1 test 2) AND (group 1 test 3)
(group 1) OR (group 2) OR (group 3) OR (group 4)

The application informs the controller of the decision scanning filter policy mode that it must use. Options are:

No decisions mode. In this mode, decision PDUs are ignored.
All-PDUs mode. All types of advertising PDU are selected. Decision PDUs are subject to checks specified by the host. Other advertising PDUs are subject to the basic filter policy.
Decisions-only mode. Only decision PDUs are selected. These are subject to checks specified by the host. Those that pass are reported to the host in HCI advertising reports. Those that fail are discarded.

7.8.2.4 Comparing Legacy Advertising and Extended Advertising

Table 8 presents a summary comparison of legacy advertising and extended advertising.

	Legacy Advertising	Extended Advertising
Max. host advertising data size	31 bytes	1,650 bytes	Extended Advertising supports fragmentation which enables a 50x larger maximum host advertising data size to be supported.
Max. host advertising data per packet	31 bytes	254 bytes	Extended Advertising PDUs use the Common Extended Advertising Payload Format which supports an 8x larger advertising data field.
TX channels	37,38,39	0-39	Extended Advertising uses the 37 general-purpose channels as secondary advertising channels. The ADV_EXT_IND PDU type may only be transmitted on the primary advertising channels (37, 38, 39) however.
PHY support	LE 1M	LE 1MLE 2M (excluding ADV_EXT_IND PDUs)LE Coded	All Extended Advertising PDUs except for ADV_EXT_IND may be transmitted using any of the three LE PHYs except for the ADV_EXT_IND PDU which may be transmitted using the LE 1M or LE Coded PHYs.
Max. active advertising configurations	1	16	Extended Advertising includes Advertising Sets which enable advertising devices to support up to 16 different advertising configurations at a time and to interleave advertising for each advertising set according to time intervals defined in the sets.
Communication types	Asynchronous	AsynchronousSynchronous	Extended Advertising includes Periodic Advertising, enabling time-synchronized communication of advertising data between transmitters and receivers.

Table 8 – Comparing legacy and extended advertising

7.8.3 PADVB – LE Periodic Advertising Broadcast

7.8.3.1 Basics

Advertising as performed by the ADVB logical transport (see 7.8.2 ADVB – LE Advertising Broadcast) includes a degree of randomness in the timing of advertising packet transmission. Random delays of between 0 and 10ms are deliberately inserted in the scheduling of advertising events to help avoid persistent packet collisions. When performing legacy advertising this is the only way in which advertising can work.

Periodic advertising involves the transmission of packets to a deterministic schedule and provides a mechanism which allows other devices to synchronize their scanning for packets with the schedule of the advertising device. Periodic advertising is always non-scannable and non-connectable.

Periodic advertising can benefit observer devices by offering a more energy-efficient way to perform scanning and is a key component in LE Audio broadcast solutions.

Advertising takes place at fixed intervals called the periodic advertising interval and the advertising data payload may change. A series of AUX_SYNC_IND and associated AUX_CHAIN_IND PDUs is said to form a periodic advertising train.

At each periodic advertising event a single AUX_SYNC_IND PDU is transmitted followed by zero or more AUX_CHAIN_IND PDUs depending on whether or not the host-provided payload requires fragmentation.

The AUX_ADV_IND PDU includes a field called SyncInfo which is part of the Common Extended Advertising Payload Format and which contains channel and timing offset information.

7.8.3.2 Channel Use

Periodic Advertising uses the 37 general-purpose advertising channels. A channel is selected at the start of each periodic advertising event using channel selection algorithm #2 with an event counter field called paEventCounter as input. This counter is incremented at each periodic advertising event. Any auxiliary AUX_CHAIN_IND PDUs related to an AUX_SYNC_IND PDU have their channel selected using an implementation-specific algorithm and specified in the AuxPtr field. See Figure 25.

7.8.3.3 Scheduling

The periodic advertising interval determines how often periodic advertising for a given advertising set can occur. It starts with the transmission of an AUX_SYNC_IND PDU and continues with a series of zero or more AUX_CHAIN_IND PDUs as shown in Figure 25.

Figure 25 – Periodic advertising events

Note that Figure 25 has been simplified with potentially multiple ADV_EXT_IND PDUs on different primary advertising channels represented by a single box.

7.8.3.4 Synchronization Establishment

A scanning device may synchronize with a periodic advertising train in either of two ways. It may either scan for AUX_ADV_IND PDUs and use the contents of the SyncInfo field to establish the periodic advertising intervals, timing offset and channel information to be used or it may receive this information over an LE-ACL connection from another device which has itself determined this information from AUX_ADV_IND PDUs. This method is known as the Periodic Advertising Sync Transfer procedure.

7.8.4 PAwR – LE Periodic Advertising with Responses

7.8.4.1 Basics

PAwR is similar to periodic advertising (PADVB) in several ways:

PADVB allows application data to be transmitted by one device (the Broadcaster) to one or more receiving devices (the Observers), forming a one-to-many communication topology. The same is true of PAwR.
PAwR and PADVB both use a connectionless communication method.
Transmission of advertising packets is periodic with a fixed interval and no random perturbation of the schedule in both cases.
Observers can establish the periodic transmission schedule used by the Broadcaster from AUX_ADV_IND PDUs or by using the Periodic Advertising Sync Transfer (PAST) procedure.

PAwR differs from PADVB as follows:

PADVB supports the unidirectional communication of data from a Broadcaster to Observers only. PAwR Observers can transmit response packets back to the Broadcaster. PAwR provides a bidirectional, connectionless communication mechanism.
Synchronization information for periodic advertising without responses (PADVB) is contained within the SyncInfo field of AUX_ADV_IND PDUs. Synchronization information for periodic advertising with responses (PAwR) is contained within the SyncInfo field and in the ACAD field of AUX_ADV_IND PDUs.
The PADVB Broadcaster schedules transmissions within advertising events. The PAwR Broadcaster schedules transmissions in a series of events and subevents, and Observers are expected to have synchronized in such a way as to listen during a specific subevent or subevents only.
The PAwR Broadcaster may use a transmission time slot to send a connection request (AUX_CONNECT_REQ PDU) to a specific device and establish an LE-ACL connection with it. PADVB does not have this capability.
With periodic advertising without responses (PADVB), application data tends to only change from time to time. PAwR is designed with the expectation that application data will change frequently.
With PADVB, the same application data is delivered to all Observer devices synchronized to the same advertising set. With PAwR, different data can be delivered to each Observer device or set of Observer devices.

Support for the Periodic Advertising Sync Transfer (PAST) procedure is optional with PADVB but mandatory with PAwR.

7.8.4.2 Channel Use

Channel selection is accomplished using Channel Selection Algorithm #2, and takes place at each periodic advertising subevent (see 7.8.4.3 Scheduling). Responses to PDUs transmitted in a subevent use the same channel. This includes AUX_SYNC_SUBEVENT_RSP PDUs sent in response to an AUX_SYNC_SUBEVENT_IND PDU and AUX_CONNECT_RSP PDUs which are sent in response to AUX_CONNECT_REQ PDUs.

7.8.4.3 Scheduling

As with other advertising modes, activity takes place in events which in the case of PAwR are known as Periodic advertising with responses events (PAwR events). These events occur at fixed intervals, with no random perturbation in scheduling. An event starts every periodic advertising interval ms.

Each PAwR event consists of several subevents, and it is during subevents that advertising packets are transmitted. The Host configures the number of subevents per event up to a maximum of 128. A subevent starts every periodic advertising subevent interval ms. The Host configures the number of subevents per event and the periodic advertising subevent interval using a Host Controller Interface (HCI) command called HCI_LE_Set_Periodic_Advertising_Parameters V2 (or later).

See Figure 26 – PAwR events and subevents.

Figure 26 – PAwR events and subevents[9]

In each subevent, the Broadcaster transmits one packet, which usually contains an AUX_SYNC_SUBEVENT_IND PDU but may instead contain an AUX_CONNECT_REQ PDU. After a delay, known as the Periodic Advertising Response Slot Delay, a series of time slots are reserved within the same subevent for receiving responses from Observer devices. Responses to AUX_SYNC_SUBEVENT_IND PDUs are sent in AUX_SYNC_SUBEVENT_RSP PDUs. The Host configures the number of response slots required by the HCI command HCI_LE_Set_Periodic_Advertising_Parameters. Figure 27 illustrates the structure of a PAwR subevent.

Figure 27 – A PAwR subevent with response slots

7.8.4.4 Synchronization Establishment

7.8.4.4.1 General

The process of synchronizing provides the Observer device with the information it needs to efficiently scan for and receive relevant packets transmitted by the advertising device. In the case of PAwR, there are three aspects to this:

The Observer needs to know how often periodic advertising with responses events will occur and when the next such event will occur. This information is provided in a parameter called the periodic advertising interval and a calculated value known as syncPacketWindowOffset.
The Observer needs information about subevents, including how often they occur and how many subevents each periodic advertising with responses event It also needs to know certain details relating to the time slots within each subevent reserved for the transmission of responses. This information is contained within parameters known as Subevent_Interval, Num_Subevents, Response_Slot_Delay, Response_Slot_Spacing, and Num_Response_Slots.
Finally, an Observer needs to know which subevent number it should scan for, which particular response slot it should use, and the access address to use in response packets transmitted.

Having acquired the event timing information described in (1) and the subevents information in (2), the Observer has a complete description of the timing parameters and structure of the events and subevents of the PAwR advertising train. But it is only when it has the information in (3) that it can schedule its scanning such that it receives only those packets that are expected to contain data of relevance and can schedule the transmission of response packets.

(1) and (2) are dealt with by the PAwR logical transport, as defined in the Bluetooth Core Specification. There is a choice of two procedures that may be used to obtain this level of synchronization information. The two procedures are covered in this paper in sections 7.8.4.4.2 Scanning for Periodic Advertising Synchronization Information and 7.8.4.4.3 Periodic Advertising Sync Transfer (PAST).

(3) must be addressed by the application layer and may be defined in an applicable Bluetooth profile specification such as the Electronic Shelf Label (ESL) profile.

7.8.4.4.2 Scanning for Periodic Advertising Synchronization Information

PAwR and PADVB each use a similar procedure for acquiring periodic advertising synchronization information by scanning.

With both PAwR and PADVB, an Observer scans for AUX_ADV_IND packets transmitted on the secondary advertising channels. AUX_ADV_IND includes the SyncInfo field, which contains the periodic advertising interval value and some data items from which to calculate a variable called syncPacketWindowOffset. Having acquired these two values, the Observer can calculate when periodic advertising with responses events will occur, per (1) in 7.8.4.4.1 General.

PAwR also requires information about subevents and response slots, per (2) in 7.8.4.4.1 General, before it can complete the synchronization procedure. This information is to be found in the same AUX_ADV_IND PDU from which the periodic advertising interval was obtained but in an advertising data type (AD type) called Periodic Advertising Response Timing Information which itself is to be found in the Additional Controller Advertising Information (ACAD) field of the PDU.

7.8.4.4.3 Periodic Advertising Sync Transfer (PAST)

When using the PAST procedure, sometimes the device passing the synchronization parameters over the connection will first acquire it by scanning on behalf of the other device. In the case of PAwR, however, support for PAST is mandatory and so the PAwR Broadcaster can pass the required synchronization data over an LE ACL connection to the Observer. If this approach is taken, no scanning for AUX_ADV_IND PDUs is necessary by either device.

7.8.4.4.4 Subevent Synchronization and Response Slot Allocation

Subevent synchronization is concerned with indicating to an Observer device the subevent it should perform scanning for. One or more Observer devices may be synchronized to the same subevent. An individual Observer may be synchronized to receive during one or more subevents.

In addition, for an Observer to be able to send a response PDU, it must have some basis for determining which subevent response slot to use.

Both of these concerns are the responsibility of the application layer.

7.8.5 LE BIS and LE CIS – Isochronous Communication

7.8.5.1 Basics

Isochronous communication provides a way of using Bluetooth LE to transfer time-bounded data between devices. It provides a mechanism that allows multiple sink devices, receiving data from the same source at different times to synchronize their processing of that data. LE Audio uses isochronous communication.

When using isochronous communication, data has a time-limited validity period, at the end of which it is said to expire. Expired data which has not yet been transmitted is discarded. This means that devices only ever receive data which is valid with respect to rules regarding its age and acceptable latency which a profile might express.

Data is transferred in isochronous streams and streams belong to isochronous groups. Devices wait for a period of time to allow all streams that are members of the same group to have the opportunity to deliver related packets before processing received packets at the same time. For example, stereo music might be delivered using two streams, one for the left stereo channel and the other for the right stereo channel. The two streams would be members of the same group and as such, rendering of packets received from the two streams takes place at the same time so that the user hears stereo music as intended.

Two logical transports which use the LE Isochronous physical channel are defined. Connected Isochronous Streams (LE CIS or simply CIS) use connection-oriented communication and support the bidirectional transfer of data. Broadcast Isochronous Streams (LE BIS or simply BIS) use connectionless, broadcast communication and provide unidirectional communication of data.

7.8.5.2 Connected Isochronous Streams

7.8.5.2.1 CIS Overview

A single CIS stream provides point-to-point isochronous communication between two connected devices and transfers data in a link layer PDU known as the CIS PDU. The LE-CIS (CIS) logical transport is depicted within the overall data transport architecture in Figure 28Figure 28.

Figure 28 – LE-CIS in the Bluetooth Data Transport Architecture

Two logical links, LE-S and LE-F are defined and provide support for both unframed (LE-S) and framed (LE-F) data. The use of LE-S vs LE-F is a concern of the Isochronous Adaptation Layer.

A CIS stream uses the LE Isochronous Physical Channel and may use any of the Bluetooth LE PHYs.

Bidirectional communication is supported by a CIS and an acknowledgement protocol is used.

CIS streams are members of groups called Connected Isochronous Groups (CIGs), each of which may contain 1 or more CISes. See Figure 29.

There may be a maximum of 31 CISes per CIG. Multiple CIGs may be created by the Central device. Available airtime and other implementation details will often reduce these limits to lower values, however.

Figure 29 – A CIG containing two CISes

7.8.5.2.2 Channel Use

Connected Isochronous Streams use adaptive frequency hopping with channel selection algorithm #2.

7.8.5.2.3 Scheduling

The scheduling of a CIG and its member CISes is governed by a system of CIG events, CIS events and subevents.

A CIG event signals the start of the scheduling of activity across the CISes that belong to the CIG, and this occurs at the anchor point of the first CIS in the group. CIG events occur at an interval specified in a parameter called ISO_Interval.

Each CIS event is divided into one or more subevents. The number of subevents in use is indicated in a stream parameter called NSE. In a connected isochronous stream, during a subevent, the Central transmits (T) once, and the Peripheral responds (R) as shown in Figure 30. Subevents are spaced apart by a duration whose value is specified in a CIS parameter called Sub_Interval. Sub_Interval is always set to zero if there is only one subevent per CIS event, otherwise it is at least 400 microseconds but less than the ISO Interval.

Note that the channel is changed at each subevent.

Each CIS may be serviced sequentially during a CIG Event or the subevents of different CISes may be interleaved. An example of a CIG which contains three CISes, each of which is serviced sequentially is shown in Figure 30.

Figure 30 – CIS events and subevents

Each CIS has a number of important parameters other than Number of Subevents (NSE) including Flush Timeout (FT) and Burst Number (BN).

Each payload (e.g. a chunk of audio data output by an audio codec such as LC3[10]) is given a maximum number of CIS events in which to be transmitted successfully (indicated by an acknowledgement) and this is specified in the FT parameter. An attempt can be made in each of the subevents of each such CIS event and if not successful within FT events, the packet is flushed (discarded). It is sometimes the case that multiple PDUs containing distinct data (i.e., payloads) are available at the same time and a CIS allows multiple different PDUs to be transmitted during the same CIS event. The number of different PDUs which may be serviced at each CIS event is specified in the Burst Number (BN) parameter.

7.8.5.2.4 Processing Synchronization

A CIG has an associated timing parameter called CIG_Sync_Delay. CISes in the same CIG each have a timing parameter called CIS_Sync_Delay and this is used in the synchronization of isochronous data processing (typically, audio rendering) by receivers across all of the streams in the group. Receivers wait for the time indicated in this parameter before rendering received data.

Figure 31 – Synchronized rendering of CIS data in a CIG

As depicted in Figure 31, each stream has a different CIS_Sync_Delay value. For the first CIS stream in the CIG, it is set to the group level parameter CIG_Sync_Delay. CIS_Sync_Delay is set to a progressively lower value for each of the other streams in the group. This means that a device receiving from a stream that was serviced earlier in the group has to wait longer before rendering the content of the received packet than devices receiving packets transmitted later in the group’s CIS event processing. Higher layer specifications such as profiles may stipulate the use of a further presentation delay to use in the calculation of the time at which data should be rendered to allow local processing delays to be accounted for. The net of this tiered delay system is that each sink device will process the received data at the same time.

7.8.5.2.5 CIS Stream Creation

Establishing a connected isochronous stream first requires an ACL connection to be created. This connection serves two purposes. First it allows link layer control PDUs to be exchanged. Secondly it provides a timing reference point against which to schedule CIS events once the stream has been established.

The Central device always initiates the procedure to create a CIS. It does so by sending a link layer control PDU called the LL_CIS_REQ PDU. All being well, the Peripheral replies with a LL_CIS_RSP PDU and the stream is said to have been established when the Central then sends a LL_CIS_IND PDU. This PDU contains important parameters which determine the timing of CIS events and the delay to apply before rendering. Specifically, CIS_Offset provides an offset in microseconds between the ACL anchor point (the time at which the first packet is sent in a connection event) and the first CIS event for the stream. CIG_Sync_Delay contains the overall CIG synchronization delay value in microseconds and CIS_Sync_Delay contains the synchronization delay value to be used by this stream.

After the stream has been created, it runs independently of and alongside the ACL connection which was used to create it. If however the ACL connection is closed, the associated CIS must also be terminated.

7.8.5.2.6 CIS Encryption

A link used by a CIS may be encrypted if the two peer devices have been paired.

7.8.5.3 Broadcast Isochronous Streams

7.8.5.3.1 BIS Overview

A BIS stream provides broadcast isochronous communication between one transmitter and many receiver devices. Data is transmitted in link layer PDUs known as the BIS Data PDU. Control information is transmitted in BIS Control PDUs.

The LE-BIS (BIS) logical transport is depicted within the overall data transport architecture in Figure 32.

Figure 32 – LE-BIS in the Bluetooth Data Transport Architecture

Data broadcast over a BIS may be framed or unframed with logical link types of LE-S and LE-F defined accordingly. The LEB-C logical link carries control information.

A BIS stream uses the LE Isochronous Physical Channel and may use any of the Bluetooth LE PHYs.

BIS streams are members of groups called Broadcast Isochronous Groups (BIG), each of which may contain 1 or more BISes. See Figure 33.

Figure 33 – A BIG containing two BISes

There may be a maximum of 31 BISes per BIG. Multiple BIGs may be created by the Central device. Available airtime and other implementation details will often reduce these limits to lower values, however.

Unidirectional communication only is supported by a BIS.

In contrast to a CIS, a BIS does not incorporate an acknowledgement protocol. This makes the BIS transport inherently unreliable. However, to counter this a system of unconditional packet retransmission is used. A BIS has no requirement to reserve slots for Peripheral responses (as is the case with CIS) since communication is unidirectional. Therefore, twice as many subevents may be scheduled for transmissions during a given amount of airtime so there is a greater opportunity for these reliability-enhancing retransmissions. Furthermore, since retransmissions are sent in distinct subevents they are transmitted on different channels. Selected channels must be at least 6 MHz from the last transmission, and this helps mitigate potential packet loss due to interference on a particular channel.

7.8.5.3.2 Channel Use

Broadcast Isochronous Streams use adaptive frequency hopping with channel selection algorithm #2.

7.8.5.3.3 Scheduling

The scheduling of a BIG and its member BISes is governed by a system of BIG events, BIS events and subevents. In addition, a special control subevent is defined for the transmission of control PDUs relating to the entire BIG.

A BIG event signals the start of the scheduling of activity across the BISes that belong to the BIG. BIS events start at intervals which are a multiple of the value specified in a BIG a parameter called BIS_Spacing from the start of the BIG (known as the BIG anchor point).

Each BIS event is divided into one or more subevents. The number of subevents in use is indicated in a stream parameter called NSE. During a subevent, the broadcaster transmits a single packet. Communication is unidirectional and there is no requirement to receive packets. Subevents are spaced apart by a duration whose value is specified in a BIG parameter called Sub_Interval.

Per connected isochronous groups, the scheduling of BIS events within a BIG may either be sequential or interleaved.

A BIG event may include a control subevent which is always scheduled as the final subevent in the BIG.

Note that the channel is changed at each subevent.

Figure 28 shows an example of the BIG and BIS events and subevents, scheduled in the sequential arrangement. Note that a BIG control subevent (designated Tc) is transmitted at the end of BIG event #1.

Figure 34 – BIG/BIS event scheduling

7.8.5.3.4 Processing Synchronization

Synchronized processing of data across broadcast isochronous streams in a BIG is achieved in a similar manner to the approach used in connected isochronous communication. Receivers possess information about the BIG and its overall parameters and know which stream(s) they have opted to receive. The timing parameters of a BIG apply uniformly to all streams. Using the overall BIG_Sync_Delay value and the BIS_Spacing parameter, receivers are able to calculate how long to wait for before processing received data such that this occurs in sync with other streams.

7.8.5.3.5 BIS Stream Creation

For a device to be able to receive packets broadcast within a BIS and to render or process the content of such packets at the same time as other devices receiving other streams that are members of the same BIG, the device must first discover the BIG and parameters which define it such as the number of streams it contains, the spacing between events relating to each stream and between subevents and timing offset information from which to calculate timing anchor points. In support of this, broadcasters use periodic advertising to communicate the required parameters. A composite field known as BIGInfo is broadcast in AUX_SYNC_IND PDUs within the ACAD (Additional Controller Advertising Data) field and contains the data required.

There are two ways in which BIGInfo may be received. In the first case, the receiver must synchronize directly to the periodic advertising train (see 7.8.3.1 Basics) using the defined procedure, receive the AUX_SYNC_IND PDU and extract BIGInfo from within ACAD. Scanning for and synchronizing with a periodic advertising train can be an expensive procedure in terms of power consumption however. So in the second case, a device may delegate the act of discovering and synchronizing with the periodic advertising train to another device, typically one which has greater power resources. Having acquired BIGInfo, the device to which scanning was delegated then passes this information over a more efficient ACL connection to the device wishing to receive the broadcast isochronous stream. This is accomplished using a procedure called Periodic Advertising Sync Transfer (PAST).

7.8.5.3.6 BIG Encryption

A BIG may be encrypted. This does not require devices receiving its BISes to have been paired with the broadcasting device. Instead, a Broadcast Code parameter which is used in the derivation of an encryption key must be distributed. This may be performed out of band or by following procedures described in higher level profiles.

7.8.5.4 Retransmissions and Reliability

Reliability may be enhanced using retransmissions of identical packets within successions of subevents on either BIS or CIS streams. In the case of BIS, retransmissions are unconditional whereas with CIS they occur when the Peripheral has not acknowledged a transmission.

In the case of BIS, because there is no requirement to reserve slots for Peripheral responses (as is the case with CIS), twice as many subevents may be scheduled for transmissions during a given amount of airtime so there is a greater opportunity for reliability-enhancing retransmissions.

Retransmissions, due to their occupying distinct subevents, are transmitted on different channels and selected channels must be at least 6 MHz from the last transmission. This helps mitigate potential packet loss due to interference on a particular channel.

8. Bluetooth^® Channel Sounding

8.1 Introduction to Bluetooth Channel Sounding

Bluetooth Channel Sounding is an optional feature of a Bluetooth LE controller. When used, it generates data with which an application can calculate its current distance from a remote device. The remote device also uses channel sounding and participates in a series of radio signal exchanges with the first device.

Bluetooth Channel Sounding is more accurate, more reliable, and significantly more secure than methods which use signal strength (Received Signal Strength Indicator or RSSI) as a proxy for distance. Early implementations of Bluetooth Channel Sounding have been demonstrated to achieve an accuracy of +/- 20 cm at distances of up to 100 meters. RSSI-based distance estimation is particularly poor and unreliable at distances beyond say, a couple of meters. It is also has no inherent security and so great care must be exercised in how it is used.

It should be noted that the Bluetooth Core Specification does not provide an algorithm with which to calculate distances using the data generated by Bluetooth Channel Sounding. This is the responsibility of the application layer (see section 8.14 Distance Measurement Applications).

Bluetooth Channel Sounding was designed to enable the secure calculation of distance for applications such as keyless entry and ignition systems where the security needs to be strong enough to protect a valuable item such as a car.

8.2 Device Roles

Bluetooth Channel Sounding defines two device roles. The Initiator is the device which starts the channel sounding procedure and ultimately, passes the data that it generates to its application layer where a distance value can be calculated. The other device is called the Reflector. In all cases, channel sounding involves the Initiator transmitting a signal and the Reflector replying to it with a transmission of its own.

Figure 35 – An exchange of signals between Initiator and Reflector during CS

In fact, as we shall see, a series of transmissions of different types and in various sequences are involved in a full channel sounding procedure.

8.3 Bluetooth Channel Sounding in the Data Transport Architecture

The Bluetooth LE data transport architecture was introduced in section 7.7 The Data Transport Architecture. Bluetooth Channel Sounding consists of a Physical Channel and Physical Link as shown in Figure 36 alongside examples of other transports.

Figure 36 – Bluetooth Channel Sounding in the data transport architecture

8.4 Two Bluetooth Channel Sounding Methods

Bluetooth Channel Sounding is interesting for many reasons. But one distinguishing feature is that two quite different methods of distance measurement are defined by the Bluetooth Core Specification and an application may use either one of the two methods or, for the utmost security, both methods in combination. The two methods are called Phase-Based Ranging (PBR) and Round-Trip Timing (RTT) and the basic theory of each will be described next. More will be said on the subject of security in section 8.13 Security.

8.4.1 Phase-Based Ranging

PBR exploits the fact that radio transmissions are made up of a series of waves and that each complete wave, known as a wave cycle, has a physical length which is a constant provided that the frequency of the transmission does not vary.

Figure 37 – Two wave cycles, each with the indicated wavelength

Ein Bruchteil einer Wellenlänge wird durch eine Größe namens Phase dargestellt. Die Phase wird als Winkel in Grad oder Radiant ausgedrückt. Die Wellenlänge und die Phase eines Signals stehen im Mittelpunkt der Funktionsweise von PBR.

In Abbildung 38 wird eine Reihe von Punkten innerhalb eines Wellenzyklus markiert und der dieser Position entsprechende Phasenwert in Radiant angegeben.

Abbildung 38 - Beispiel für Phasenwerte

Es ist nicht möglich, die Entfernung zwischen zwei Geräten nur anhand der Wellenlänge eines Signals und eines vom Empfänger im Initiatorgerät gemessenen Phasenwertes zu berechnen. PBR funktioniert also durch den Austausch von zwei verschiedenen Signalen, jedes mit einer anderen Frequenz (f1 und f2) und daher mit einer anderen Wellenlänge.

Der Initiator sendet auf der Frequenz f1. Das Reflektorgerät empfängt diese Übertragung und sendet sie mit derselben Frequenz an den Initiator zurück. Der Initiator misst die Phase (p1) der Antwortübertragung und notiert sie. Dann sendet der Initiator ein weiteres channel sounding mit der Frequenz f2. Wiederum antwortet der Reflektor mit einer ähnlichen Übertragung auf der gleichen Frequenz f2, und der Initiator misst die Phase (p2) an dem Punkt, an dem die Antwort empfangen wird.

Abbildung 39 - erster Austausch von Züchterrechtssignalen bei der Frequenz f1

Abbildung 40 - zweiter PBR-Signalaustausch bei Frequenz f2

Aus der Differenz zwischen den gemessenen Phasenwerten der beiden channel sounding (p2 - p1) lässt sich mit Hilfe einfacher Mathematik der Abstand zwischen den beiden Geräten ableiten.

In der Praxis ist die Art und Weise, wie Bluetooth PBR verwendet, etwas komplizierter als die hier gegebene Beschreibung, aber im Kern ist es diese grundlegende Methodik.

Es gibt jedoch eine Komplikation bei der Verwendung von Phasenwerten zur Berechnung der Entfernung. Der Phasenwert ist, wenn er entlang mehrerer Wellenzyklen eines Signals gemessen wird, zyklisch. Gemessen für einen Wellenzyklus durchläuft er alle Werte von 0 Radiant bis 2π Radiant (0 - 360 Grad). Beim nächsten Wellenzyklus des Signals beginnt die Phase jedoch wieder bei 0 Radiant und durchläuft erneut alle Werte bis 2π Radiant. Dies wiederholt sich bei jedem Wellenzyklus. In Abbildung 41 ist dieses zyklische Muster dargestellt.

Abbildung 41 - die zyklische Natur der Phasenwerte

Im Zusammenhang mit dem Züchterrecht hat dies Konsequenzen. Der Phasenwert ändert sich mit dem Abstand zwischen den Geräten. Ab einem bestimmten physischen Abstand beginnen sich die Phasenwerte zu wiederholen. Folglich kann derselbe Phasendifferenzwert mehr als eine Entfernung implizieren. Dies wird als Entfernungsambiguität bezeichnet. Glücklicherweise stellt das design von Bluetooth Channel Sounding sicher, dass dies in der Praxis kein Problem darstellt, wie in 8.10 Kanäle und Kanalauswahl erläutert.

8.4.2 Hin- und Rückreisezeitpunkt

Funksignale bewegen sich mit Lichtgeschwindigkeit. Bei der RTT-Methode wird die Zeit gemessen, die ein Signal benötigt, um vom Initiator zum Reflektor und wieder zurück zu gelangen, wobei die Zeit berücksichtigt wird, die der Reflektor benötigt, um das empfangene Signal zu verarbeiten und seine Antwort zu formulieren und zu senden. Die Entfernung kann dann berechnet werden, indem die gemessene Zeit für den Hin- und Rückweg zwischen den Geräten mit der Lichtgeschwindigkeit multipliziert und das Ergebnis dann durch zwei geteilt wird.

Abbildung 42 - RTT-Übertragungen und Zeitpunkte

In Abbildung 42 ist ein Austausch von RTT-Paketen dargestellt. Die grün gestrichelten Linien ( ---- ) stellen die verstrichene Zeit dar, in der keines der beiden Signale in der Luft ist. Auf der Zeitachse sind vier Punkte markiert, die in Tabelle 9 erläutert werden.

Augenblick in der Zeit	Erläuterung
_ToDA	Zeitpunkt des Verlassens von Gerät A. Dies ist der Zeitpunkt, zu dem das Signal von Gerät A über die Luft übertragen wird.
_ToAB	Zeitpunkt des Eintreffens bei Gerät B. Dies ist der Zeitpunkt, zu dem das Signal an der Antenne von Gerät B angekommen ist.
_ToDB	Time of Departure from Device B. Dies ist die Zeit, zu der Device B über die Luft sendet.
_ToAA	Zeitpunkt des Eintreffens bei Gerät A: Dies ist der Zeitpunkt, zu dem das Signal von Gerät B an der Antenne von Gerät A empfangen wird.

Tabelle 9 - RTT-Zeitpunkte

Die Round-Trip-Time (RTT) kann durch die in Abbildung 42 dargestellten Zeitpunkte wie folgt ausgedrückt werden:

RTT = 2 * ToF = (_ToAA - _ToDA) - (_ToDB - _ToAB)

Der Begriff ist die Durchlaufzeit beim Reflektor. Der Initiator subtrahiert diesen Wert von der Zeit, die zwischen seiner Übertragung und dem Empfang einer Antwort vom Reflektor vergeht. Aber woher weiß der Initiator, wie lange der Reflektor gebraucht hat, um das Signal des Initiators zu verarbeiten und mit seiner Antwort zu antworten?

Die Antwort ist einfach. Die Zeit, die der Reflektor benötigt, ist ein fester Zeitraum, der zwischen den beiden Geräten vereinbart wird, bevor das Channel Sounding beginnt.

Tatsächlich muss eine Reihe von Prozeduren ausgeführt werden, bevor Channel Sounding beginnen kann. Die Spezifikation der Verbindungsschicht definiert eine Reihe von Kontrollverfahren, von denen sich einige mit der Konfiguration und dem Start des Channel Sounding befassen.

8.5 Bluetooth Channel Sounding Kontrollverfahren der Verbindungsschicht

Um die channel sounding einzuleiten, müssen die beiden Geräte zunächst eine LE-ACL-Verbindung herstellen (siehe 7.8.1 LE ACL - LE Asynchronous Connection-Oriented Logical Transport). Die Verschlüsselung muss auf der Verbindung aktiviert sein, bevor die Kontrollverfahren für channel sounding die Verbindung nutzen können, und daher müssen die beiden channel sounding gepaart sein.

Sobald eine verschlüsselte Verbindung zwischen den beiden Geräten hergestellt ist, werden die folgenden Kontrollverfahren der Verbindungsschicht ausgeführt:

Channel Sounding Sicherheit Start
Channel Sounding Austausch von Fähigkeiten
Channel Sounding Konfiguration
Modus-0 FAE-Tabellenabfrage
Channel Sounding Start

8.5.1 Channel Sounding Sicherheit Start

Bluetooth Channel Sounding hat eine Reihe einzigartiger Sicherheitsmerkmale, die in anderen Aspekten von Bluetooth LE nicht zu finden sind. Einige von ihnen hängen von drei numerischen Parametern ab, dem Initialisierungsvektor (CS_IV), der Instantiation Nonce (CS_IN) und dem Personalisierungsvektor (CS_PV).

Während des Channel Sounding Security Start-Verfahrens generiert jedes der beiden Geräte einen Wert für jeden der drei Sicherheitsparametertypen und übergibt sie über die verschlüsselte LE-ACL-Verbindung an das andere Gerät. Jedes Wertepaar für jeden der drei Typen wird dann von jedem Gerät verkettet, so dass am Ende des Prozesses jedes Gerät im Besitz der gleichen 128-Bit-CS_IV-, 64-Bit-CS_IN- und 128-Bit-CS_PV-Werte ist.

8.5.2 Channel Sounding Austausch von Fähigkeiten

Nicht alle channel sounding haben die gleichen Möglichkeiten. So können beispielsweise die unterstützten channel sounding (siehe Abschnitt 8.4 Zwei Channel Sounding ) unterschiedlich sein. Insgesamt sind 22 Parameter für die channel sounding definiert.

Damit die beiden Geräte zu einer channel sounding gelangen können, die beide unterstützen können, müssen sie zunächst Informationen über ihre Fähigkeiten austauschen. Zu diesem Zweck definiert die Verbindungsschicht die PDUs LL_CS_CAPABILITIES_REQ und LL_CS_CAPABILITIES_RSP.

8.5.3 Channel Sounding Konfiguration

Auf der Grundlage der Informationen über die channel sounding jedes Geräts wird eine ausgewählte Konfiguration, die beide Geräte unterstützen können, unter Verwendung der PDUs LL_CS_CONFIG_REQ und LL_CS_CONFIG_RSP der Verbindungsschicht ausgetauscht.

Die Rolle des Initiators oder des Reflektors bei channel sounding wird während dieses Verfahrens festgelegt, wobei die Anwendung, die den Prozess steuert, ihre Wahl in der PDU LL_CS_CONFIG_REQ sendet, auf die das andere Gerät antwortet.

8.5.4 Mode-0 FAE-Tabellenabfrage

Alle Geräte weisen eine gewisse Ungenauigkeit bei der Einstellung der Sendefrequenz auf, die je nach dem HF-Kanal, in dem sich die gewünschte Frequenz befindet, variieren kann.

Fractional Frequency Offset Actuation Error (FAE) ist ein Maß für die Ungenauigkeit, mit der ein Gerät die Frequenz seiner Übertragungen einstellen kann. Er wird als Differenz zwischen der beabsichtigten und der tatsächlich erzeugten Frequenz in Teilen pro Million (ppm) ausgedrückt.

Ein channel sounding muss eine Kalibrierung durchführen, die die FAE des Reflektors berücksichtigt, und benötigt dazu eine Tabelle mit FAE-Daten vom Reflektor. Er erhält diese Daten über das Kontrollverfahren Link Layer Mode-0 FAE Table Request. Dazu sendet der Initiator eine LL_CS_FAE_REQ-PDU, auf die der Reflektor mit einer LL_CS_FAE_RSP-PDU antwortet, die seine FAE-Tabelle enthält. Beachten Sie, dass die FAE-Tabelle eines Geräts während der Herstellung eingerichtet wird.

Der Modus 0 wird in Abschnitt 8.8 Schritte und Modi erläutert.

8.5.5 Channel Sounding Start

Nach dem Austausch von Sicherheitsmaterial, der Vereinbarung einer Konfiguration und der gemeinsamen Nutzung von FAE-Daten, sofern vorhanden, kann der Initiator nun den controller anweisen, mit der channel sounding zu beginnen. Dies beinhaltet den Austausch der Link Layer Control PDUs LL_CS_REQ, LL_CS_RSP und LL_CS_IND.

Das Channel sounding erfolgt in einer Abfolge von verschiedenen Vorgängen, die als CS-Schritte bezeichnet werden, und unterliegt einer Reihe von Zeitparametern. Diese werden während des Channel Sounding Start ausgetauscht.

8.6 Zeiteinteilung

Die logischen Transporte, die in 7.8 Die logischen Transporte erläutert wurden, strukturieren alle die Zeitachse, entlang derer Aktivitäten in Form von Ereignissen und manchmal Unterereignissen stattfinden. Die Abfolge und Zeitplanung von channel sounding ist anspruchsvoller und variabel, und um dem Rechnung zu tragen, werden vier Ebenen der Zeiteinteilung definiert.

Wenn channel sounding ausgeführt wird, geschieht dies in einer Reihe von einer oder mehreren CS-Prozeduren. Ein CS-Verfahren ist in CS-Ereignisse unterteilt, und jedes CS-Ereignis ist in CS-Unterereignisse unterteilt. Innerhalb jedes CS-Subereignisses ist eine Reihe von zwei oder mehr CS-Schritten geplant, und innerhalb dieser CS-Schritte finden die HF-Sende- und Empfangsaktivitäten statt. Abbildung 43 zeigt diese Konzepte, wie sie in einer Beispielkonfiguration verwendet werden könnten.

Abbildung 43 - CS Zeitteilungskonzepte

8.7 Pakete und Töne

Die RF-Aktivität, die innerhalb der CS-Schritte stattfindet, hat eine von zwei Formen:

Pakete - diese enthalten binäre Daten, die mit GFSK (Gaussian Frequency Shift Keying) für die Übertragung über Funk moduliert werden.
Töne - das sind Funkübertragungen, die keine Daten enthalten. Die Eigenschaften des Funksignals selbst werden von der PBR-Methode verwendet, die keine Daten aus dem digitalen Bereich benötigt.

Channel sounding werden als CS_Sync-Pakete bezeichnet, und es sind eine Reihe von Varianten definiert. CS_Sync-Pakete werden während der Kalibrierungsschritte und bei Verwendung der RTT-Methode übertragen. Die Töne, die bei der channel sounding verwendet werden, sind als CS-Töne bekannt und werden verwendet, wenn die PBR-Methode angewandt wird.

8.8 Schritte und Modi

CS-Schritte sind die unterste Ebene des Zeiteinteilungs- und Zeitplanungsschemas, das beim Bluetooth Channel Sounding verwendet wird. Die Schritte haben einen zugehörigen Modus, von denen vier definiert sind.

Modus	Beschreibung
0	Modus-0 wird für Kalibrierungszwecke verwendet.
1	mode-1 bezieht sich auf die RTT-Methode.
2	mode-2 bezieht sich auf die Züchterrechtsmethode.
3	mode-3 unterstützt sowohl RTT als auch PBR in einem einzigen Schritt mit zwei Methoden.

8.8.1 Modus-0

Der Zweck des Schrittmodus-0 besteht darin, dem Initiator die Berechnung eines Wertes zu ermöglichen, der als Fractional Frequency Offset (FFO) bezeichnet wird.

Die Frequenz von Signalen, die von channel sounding erzeugt werden, ist aufgrund der Beziehung zwischen Frequenz, Wellenlänge und Phase eine entscheidende Komponente für die Funktionsweise derChannel Sounding . Wie genau die Frequenz eines erzeugten Signals mit der beabsichtigten Frequenz übereinstimmt, ist jedoch unterschiedlich, und ein gewisses Maß an Ungenauigkeit ist immer zu erwarten.

Der FFO ist ein Maß für das Ausmaß, in dem sich der Reflektor bei der Erzeugung einer bestimmten Zielfrequenz vom Initiator unterscheidet. Zur Berechnung des FFO werden die Frequenz des vom Reflector empfangenen CS-Tons und die Mode-0-FAE-Tabelle des Reflectors herangezogen, die der Initiator während des Kontrollverfahrens 8.5.4 Mode-0-FAE-Tabellenanforderung erhalten hat.

FFO wird in Berechnungen verwendet, um Unterschiede zwischen Initiator und Reflektor auszugleichen und letztlich die Genauigkeit der Ergebnisse zu verbessern.

Abbildung 44 zeigt die von Initiator und Reflektor in einem Mode-0-Schritt übertragenen Pakete und Töne.

Abbildung 44 - Paket- und Tonübertragungen im Modus 0

Die Bluetooth-Kernspezifikation definiert die im Diagramm dargestellten und gekennzeichneten Zeitschlitze. Die Bezeichnungen und ihre Bedeutung sind in Tabelle 10 aufgeführt.

T_SY	Zeit für die Synchronisationssequenz.
T_RD	Zeit für die Abwärtsrampe der Übertragung. Diese Zeit beträgt 5 μs und wird vom Sender verwendet, um Energie aus dem HF-Kanal zu entfernen.
T_IP1	Zeit für das Intermezzo zwischen dem Ende der Übertragung des Initiators und dem Beginn der Übertragung durch den Reflektor. Die Dauer variiert zwischen 10 μs und 145 μs und wird im Verfahren zum Austausch von Fähigkeiten festgelegt.
T_GD	Überwachungszeit. Immer 10 μs lang.
T_FM	Zeit für die Frequenzmessung. Immer 80 μs Dauer für Schrittmodus-0.

Tabelle 10 - CS-Schritt-Zeitschlitze

Jedes CS-Unterereignis beginnt mit mindestens einem Modus-0-Schritt.

8.8.2 Modus-1

Modus-1-Schritte beinhalten den Austausch von CS_Sync-Paketen zur Messung einer Umlaufzeit. Abbildung 45 zeigt den Paketaustausch und die für diesen Schrittmodus definierten Zeitschlitze.

Abbildung 45 - Paketaustausch in Modus-1 (RTT)

Um die Berechnung einer Round-Trip-Zeit zu ermöglichen, erfasst der Initiator einen Zeitstempel beim Senden des CS_Sync-Pakets und einen weiteren beim Empfang eines CS_Sync-Pakets vom Reflektor. In der Bluetooth Core Specification sind mehrere Zeitstempelverfahren definiert, die jeweils unterschiedliche Genauigkeitsgrade bieten.

8.8.3 Modus-2

Modus-2-Schritte beziehen sich auf die Verwendung der PBR-Methode zur Entfernungsmessung. Initiator und Reflektor tauschen CS-Töne aus, wobei jedes Gerät auf der gleichen Frequenz sendet. Bei Verwendung der PBR-Methode können mehrere Antennen beteiligt sein, was sich in der Bedeutung der in Abbildung 46 dargestellten Zeitschlitze widerspiegelt.

Abbildung 46 - Austausch von CS-Tönen im Modus 2 (PBR)

In Abbildung 46 sind einige zusätzliche Zeitschlitzbezeichnungen dargestellt, die in Tabelle 11 erläutert werden.

T_SW	Für die Antennenumschaltung reservierte Zeitspanne.
T_PM	Zeit für die Übertragung eines Phasenmesstons.
T_IP2	Zeit für das Intermezzo zwischen den CS-Tönen.
N_AP	Anzahl der Antennenpfade.

Tabelle 11 - Zusätzliche PBR-Zeitschlitzbezeichnungen

8.8.4 Modus-3

Modus-3-Schritte bieten dem Initiator die Grundlage sowohl für eine RTT- als auch für eine KBR-Berechnung in einem einzigen Schritt. Abbildung 47 zeigt den Austausch von CS_Sync-Paketen und CS-Tönen, der in diesem Schrittmodus stattfindet.

Abbildung 47 - In einem Mode-3-Schritt ausgetauschte Pakete und Töne

8.9 Betriebsart Sequenzierung

Ein CS-Verfahren besteht immer aus mehreren CS-Schritten mit einer Mischung aus zwei oder drei verschiedenen Modi. Im Allgemeinen gilt: Je mehr Schritte ausgeführt werden, desto mehr Daten werden für die Entfernungsberechnung erfasst und desto besser sind die Ergebnisse. Die Anzahl der CS-Prozeduren, CS-Ereignisse, CS-Unterereignisse und CS-Schritte, die ausgeführt werden, sowie die Mischung der verwendeten Schrittmodi wird von den Anwendungen konfiguriert. Dies wird als Mode Sequencing bezeichnet.

Modus 0 ist immer beteiligt, und alle CS-Unterereignisse müssen mit einem, zwei oder drei aufeinanderfolgenden Modus-0-Schritten beginnen. Mindestens ein und höchstens zwei andere Modi müssen in einer Schrittfolge vorhanden sein. Es sind jedoch nicht alle Kombinationen zulässig, und die Bluetooth-Kernspezifikation legt fest, welche Kombinationen zulässig sind. In einer bestimmten Konfiguration wird einer der ausgewählten Nicht-Modus-0-Modi als Main_Mode und der andere (falls vorhanden) als Sub_Mode bezeichnet. Die Bluetooth Core Specification enthält weitere Informationen über die Bedeutung dieser Begriffe und ihre Auswirkungen auf die Modusreihenfolge.

Tabelle 12 zeigt die zulässigen Nicht-Mode-0-Kombinationen.

Haupt_Modus	Unter_Modus
Modus-1	Keine
Modus-2	Keine
Modus-3	Keine
Modus-2	Modus-1
Modus-2	Modus-3
Modus-3	Modus-2

Tabelle 12 - Zulässige Kombinationen von Betriebsarten, die nicht dem Modus 0 entsprechen.

Im Allgemeinen folgt die Abfolge im Schrittbetrieb diesem Muster:

Ein oder mehrere Mode-0-Schritte starten ein Unterereignis.
Es folgt eine Folge von n Hauptmodusschritten, wobei n zufällig ausgewählt wird und in einem Bereich liegt, der während der Konfiguration der channel sounding festgelegt wird.
Ein einzelner sub_mode-Schritt folgt auf die Abfolge von n main_mode-Schritten.

Abbildung 48 zeigt ein Beispiel.

Abbildung 48 - Beispiel einer Schrittmodussequenz mit Konfigurationsparametern

8.10 Kanäle und Kanalauswahl

In Abschnitt 6.1 Frequenzband wird erläutert, wie Bluetooth LE das 2,4-GHz-Frequenzband in 40 Kanäle mit einer Breite von jeweils 2 MHz unterteilt. Abschnitt 7.8 Die logischen Transporte erklärt, wie die verschiedenen logischen Transporte, die durch die Link-Layer-Spezifikation definiert sind, bei der Auswahl der Kanäle vorgehen. Bluetooth Channel Sounding verfolgt in beiderlei Hinsicht einen anderen Ansatz.

8.10.1 RF-Kanäle

Channel Sounding wird im unlizenzierten 2,4-GHz-Band betrieben, wie dies auch bei der Verwendung der logischen Übertragungsschicht der Fall ist. Das Band ist jedoch in 79 Kanäle von 1 MHz Breite unterteilt, von denen 72 für das channel sounding zur Verfügung stehen. Die Anordnung dieser Kanäle gewährleistet, dass die primären LE-Werbekanäle vermieden werden.

In Tabelle 13 sind die Kanäle channel sounding , ihre Kanalindexwerte und die Angabe, ob jeder Kanal während der channel sounding verfügbar ist oder nicht, dargestellt.

CS-Kanal-Index	RF-Mittenfrequenz	Erlaubt
0	2402 MHz	Nein
1	2403 MHz	Nein
2	2404 MHz	Ja
...	...	...
22	2424 MHz	Ja
23	2425 MHz	Nein
24	2426 MHz	Nein
25	2427 MHz	Nein
26	2428 MHz	Ja
...	...	...
76	2478 MHz	Ja
77	2479 MHz	Nein
78	2480 MHz	Nein

Tabelle 13 - CS-Kanal-Indizes und physikalische HF-Kanäle

Die Verwendung einer Kanalbreite von 1 MHz anstelle der üblichen 2 MHz stellt sicher, dass Entfernungsmehrdeutigkeit (wie in 8.4.1 Phasenbasiertes Ranging erläutert) erst bei etwa 150 Metern auftritt. Dies ist mehr als ausreichend für die Arten von Anwendungen, für die Bluetooth Channel Sounding konzipiert ist.

8.10.2 Kanalfilterung

Das adaptive Frequenzsprungverfahren (AFH) wurde in Abschnitt 7.4 Kanalauswahl erläutert. Der adaptive Aspekt von AFH besteht darin, dass die Geräte die Leistung der einzelnen HF-Kanäle messen und Informationen darüber, ob ein bestimmter Kanal verwendet werden sollte oder nicht, zwischen den kommunizierenden Geräten austauschen. Auf diese Weise können sich die Geräte an die HF-Umgebung anpassen, in der sie arbeiten, und Kanäle mit übermäßigen Störungen vermeiden.

Bluetooth Channel Sounding unterhält aus den gleichen Gründen eine Kanalindexfilter-Bitmap. Jeder Kanal in der Karte ist entweder als eingeschlossen oder ausgeschlossen gekennzeichnet. Der Kanalauswahlprozess stellt sicher, dass als ausgeschlossen markierte Kanäle niemals ausgewählt werden. Der Initiator und der Reflektor tauschen Informationen über die HF-Kanalleistung untereinander aus, indem sie das Verfahren zur Aktualisierung der Channel Sounding für das Link Layer Channel Sounding verwenden.

8.10.3 Kanalwahl und Frequenzsprungverfahren

Ein Kanal wird direkt vor der Ausführung jedes CS-Schrittes ausgewählt, wie in Abbildung 49 dargestellt.

Abbildung 49 - Frequenzsprung vor der Schrittausführung

In der Bluetooth sind drei Kanalauswahlalgorithmen definiert, die ausschließlich für das Bluetooth Channel Sounding verwendet werden. Sie sind bekannt als CSA #3a, CSA #3b und CSA #3c.

CSA #3a dient ausschließlich zur Auswahl des Kanals, der in Modus-0-Schritten verwendet werden soll.

CSA #3b und CSA #3c sind beide für die Verwendung mit Nicht-Mode-0-Stufen ausgelegt, aber nur eine der beiden darf während eines CS-Verfahrens verwendet werden.

CSA #3a und CSA #3b funktionieren auf sehr ähnliche Weise. Beide verwenden eine Kanalliste, die die Indizes aller Kanäle enthält, die als in der Kanalkarte enthalten markiert sind. Die Kanallisten werden gemischt, wenn die channel sounding beginnt, und die Kanalauswahl umfasst dann einfach die Verwendung jedes Kanals in der gemischten Liste, einen nach dem anderen, wobei jeder Kanal immer nur einmal verwendet wird. Die Regel für CSA #3a ist, dass, wenn alle Kanalindizes in der gemischten Liste verwendet wurden, die zugehörige Kanalliste neu generiert und neu gemischt wird und die Verwendung erneut beginnt. Bei CSA #3b kann die gemischte Liste mehrere Male durchlaufen werden, bevor sie neu generiert wird.

CSA #3c unterscheidet sich deutlich von CSA #3b und ist komplizierter, kann aber unter bestimmten Umständen Vorteile bei der Erkennung reflektierter Signalwege bieten. Weitere Einzelheiten finden Sie in der Bluetooth . Die Unterstützung für CSA #3c ist optional.

8.11 Antennenumschaltung und Antennenwege

Die Geräte können über eine Gruppe von bis zu vier Antennen für die phasenbasierte Entfernungsmessung verfügen. Die Übertragung von einer Antenne in einem der Geräte zu einer der Antennen im anderen Gerät bildet einen Antennenpfad. Es sind maximal 4 Antennenpfade zulässig, was die Permutationen der Antennengruppengröße in Initiator und Reflektor auf eine Liste von 8 beschränkt (siehe Tabelle 14).

Antennenkonfigurationsindex (ACI)	Gerät Eine Anzahl von Antennen	Gerät B Anzahl der Antennen	Anzahl der Antennenwege (N_AP)
0	1	1	1
1	2	1	2
2	3	1	3
3	4	1	4
4	1	2	2
5	1	3	3
6	1	4	4
7	2	2	4

Tabelle 14 - Kombinationen von Antennengruppengrößen und Antennenpfaden

Die folgenden Abbildungen zeigen Beispiele für zwei verschiedene Antennenkonfigurationen und die dazugehörigen Antennenwege.

Abbildung 50 - 3:1-Antennenkonfiguration (ACI=2, N_AP=3)

Abbildung 51 - 2:2-Antennenkonfiguration (ACI=7, N_AP=4)

Die Antennenumschaltung erfolgt während der Übertragung von CS-Tönen in Mode-2- und Mode-3-Schritten. Dies spiegelt sich in dem Begriff N_AP (Anzahl der Antennenwege) in den Formeln für die Zeitschlitzdauer in Abbildung 46 und Abbildung 47 wider.

8.12 RTT und Genauigkeit

Die Lichtgeschwindigkeit in einem Vakuum beträgt 299.792.458 Meter pro Sekunde. Das bedeutet, dass das Licht in nur einer Mikrosekunde fast 300 Meter zurücklegt. Und natürlich bewegen sich auch Radiowellen mit Lichtgeschwindigkeit.

Daher ist die Genauigkeit, mit der die ToD- und ToA-Zeitstempel des Initiators bei der RTT-Methode erfasst werden, entscheidend. Ein sehr kleiner Fehler in den erfassten Zeitstempeln kann zu einem erheblichen Fehler in der resultierenden Entfernungsberechnung führen.

Die Erfassung von Zeitstempeln mit ausreichender Genauigkeit für Entfernungsschätzungen stellt die Ingenieure vor große Herausforderungen. Die Bluetooth Core Specification beschreibt mehrere Ansätze.

Zugriffsadresse: Die Zugriffsadresse ist das erste Feld in CS_Sync-Paketen und hat eine Länge von 32 Bit. Eine Zeitstempel-Methode besteht darin, die Zeit zu erfassen, zu der die Zugriffsadresse empfangen wird, obwohl einige Details, wie genau dies geschehen soll, der Implementierung überlassen werden.
Fractional Timing-Schätzungen: Es gibt zwei Möglichkeiten, zu einer fraktionierten Zeitschätzung zu gelangen, von denen eine wahrscheinlich genauer ist als die Verwendung der Zugangsadresse. Im Allgemeinen beinhalten die fraktionierten Methoden die Analyse eines Feldes, das am Ende von CS_Sync-Paketen platziert werden kann, um sehr kleine Zeitfehler zu bestimmen. Zu diesem Zweck kann eines von zwei Feldern an CS_Sync-Pakete angehängt werden.
- Zufällige Sequenz: Es ist unwahrscheinlich, dass die Abtastung eines empfangenen Signals mit der Phase des empfangenen Signals übereinstimmt, und dies kann die Ursache für kleine Zeitfehler sein. Die Analyse des Zufallssequenzfeldes kann den Unterschied zwischen den tatsächlichen Abtastpunkten und denen, die optimal gewesen wären, aufzeigen. Dies kann dann genutzt werden, um die Genauigkeit der Zeitstempelwerte zu verbessern.
- Klingende Sequenz: Dies ist eine abwechselnde Folge von 1en und 0en. Wenn sie mit GFSK moduliert und übertragen wird, haben die Symbole, die 1en und 0en darstellen, unterschiedliche Frequenzen und können als zwei verschiedene Töne betrachtet werden. Die Analyse der Phasendifferenz zwischen den beiden Tönen ermöglicht die Messung von Zeitfehlern, was zur Verbesserung von Zeitstempeln genutzt werden kann.

Im Allgemeinen können Messungen über eine Reihe von Schritten dazu beitragen, die Genauigkeit von Zeitstempeln durch eine Analyse der Verteilung der Werte zu verbessern.

8.13 Sicherheit

Die Sicherheit von Systemen zur Entfernungsmessung birgt einige neue Herausforderungen. Im Allgemeinen besteht die Bedrohung, gegen die es sich zu schützen gilt, darin, dass ein bösartiges Gerät einem der beiden vertrauenswürdigen Geräte (insbesondere dem Initiator im Fall von Bluetooth Channel Sounding) vorgaukelt, das andere vertrauenswürdige Gerät sei näher als es tatsächlich ist, was offensichtliche Folgen haben kann, z. B. den Diebstahl eines Autos.

In den nächsten beiden Abschnitten werden zwei Arten von Angriffen kurz erläutert. In Abschnitt 8.13.3 Sicherheitsmerkmale des Bluetooth Channel Sounding werden die Merkmale des Bluetooth Channel Sounding zusammengefasst, die vor Angriffen dieser Art (und anderen) schützen.

8.13.1 Spoofing

Eine Klasse von Angriffen besteht darin, dass eines der vertrauenswürdigen Geräte durch das angreifende Gerät imitiert wird. Ein Beispiel hierfür ist ein Replay-Angriff, bei dem das böswillige Gerät die zwischen vertrauenswürdigen Geräten ausgetauschten Pakete während eines normalen, erfolgreichen Dialogs aufzeichnet. Später verwendet es dann einige der aufgezeichneten Pakete, um Antworten zu senden, die ein vertrauenswürdiges Gerät dazu bringen, sich so zu verhalten, als befände es sich in einem Dialog mit seinem legitimen Gegenstück.

In Abbildung 52 stellen Alice und Bob die beiden vertrauenswürdigen Geräte in einem proprietären drahtlosen Entfernungsmessungssystem dar, das nur unzureichend gesichert ist. Der Angreifer ist ein bösartiges Gerät, das in dieser ersten Phase des Angriffs einfach den Austausch zwischen Alice und Bob abhört und die Pakete aufzeichnet.

In Abbildung 53 werden in Phase 2 des Angriffs die in Phase 1 aufgezeichneten Pakete verwendet, um Alice vorzugaukeln, dass der Austausch mit dem vertrauenswürdigen Gerät Bob erfolgt.

Abbildung 52 - Replay-Angriff Teil 1

Abbildung 53 - Replay-Angriff Teil 2

Bluetooth Channel Sounding verfügt über mehrere Schutzmechanismen gegen Angriffe dieser Art.

8.13.2 Relay-Angriffe

Eine andere Art von potenziellem Angriff ist der sogenannte Relay-Angriff. Dabei handelt es sich um einen Man-in-the-Middle-Angriff (MITM), der auf der physikalischen Ebene arbeitet und Signale von einem vertrauenswürdigen Gerät an ein anderes weiterleitet, das Signal aber in Echtzeit auf irgendeine Weise manipuliert, um den Eindruck zu erwecken, dass die Geräte näher beieinander sind, als sie es tatsächlich sind.

Abbildung 54 - Relay-Angriff

Bluetooth Channel Sounding verfügt über mehrere Schutzmechanismen gegen Angriffe dieser Art.

8.13.3 Bluetooth Channel Sounding Sicherheitseigenschaften

Bluetooth Channel Sounding umfasst eine umfangreiche Reihe von Sicherheitsfunktionen, und das Generic Access Profile definiert vier Sicherheitsstufen, die für channel sounding gelten.

Die vollständige Liste der Sicherheitsmerkmale, die für Bluetooth Channel Sounding definiert sind, kann in vier Kategorien unterteilt werden.

8.13.3.1 Verwendung von PBR- und RTT-Methoden in Kombination

Bluetooth Channel Sounding unterstützt sowohl die phasenbasierte Methode der Entfernungsmessung als auch die Round-Trip-Timing-Methode. Die Flexibilität der Step-Mode-Sequenzierung bedeutet, dass Anwendungen beide Methoden gleichzeitig verwenden können. Auf diese Weise können die von diesen beiden recht unterschiedlichen Methoden erzeugten Daten miteinander abgeglichen werden.

Die Komplexität, beide Methoden gleichzeitig anzugreifen, so dass sowohl die Phase der channel sounding als auch die berechneten Umlaufzeiten manipuliert werden, um irreführende und konsistente Ergebnisse zu erzielen, wird von Sicherheitsexperten als sehr hoch angesehen. Dies allein ist ein leistungsfähiger Mechanismus zur Aufdeckung von Angriffen.

8.13.3.2 Randomisierung des Bitstroms und der Übertragungsmuster

Die Sicherheit derChannel Sounding umfasst die Spezifikation einer Funktion namens Deterministic Random Bit Generator (DRBG). Durch wiederholte Aufrufe dieser Funktion wird eine Folge von Werten erzeugt, die für den zufälligen Beobachter zufällig und unvorhersehbar ist.

DRBG verwendet jedoch die Werte für den Initialisierungsvektor (CS_IV), die Instanziierungs-Nonce (CS_IN) und den Personalisierungsvektor (CS_PV), die von beiden Geräten während der Channel Sounding Security Start-Prozedur festgelegt wurden, und zwei Geräte, die dieselben Werte für diese DRBG-Parameter verwenden, werden bei einer Reihe von Aufrufen der Funktion genau die gleiche Abfolge von Ausgaben erzeugen. Daher ist die Abfolge für Geräte, die über die drei DRBG-Parameter verfügen, deterministisch, für andere (wie einen Angreifer) jedoch unvorhersehbar. CS_IV, CS_IN und CS_PV haben jedes Mal, wenn eine channel sounding durchgeführt wird, andere Werte, und da sie aus einem Austausch von Teilwerten über eine verschlüsselte LE-ACL-Verbindung erzeugt werden, kann man sicher davon ausgehen, dass ein Angreifer die verwendeten DRBG-Parameterwerte nicht kennt.

DRBG wird verwendet, um sowohl den Inhalt des Bitstroms als auch das gesamte Übertragungsmuster zu randomisieren. In der Bluetooth-Kernspezifikation ist festgelegt, dass Bereiche des channel sounding Bitstroms zufällig ausgewählt und dann auf ein zufällig generiertes Bitmuster gesetzt werden, wobei in beiden Fällen DRBG verwendet wird. Darüber hinaus sind für Modus-2- und Modus-3-Schritte Zeitschlitze definiert, die als Tonerweiterungsschlitze bezeichnet werden, und ob während dieser Schlitze eine Übertragung erfolgt oder nicht, hängt von DRBG-Aufrufen ab.

Die Verwendung von DRBG auf diese beiden Arten bedeutet, dass sowohl der Initiator als auch der Reflektor den Inhalt ihrer Übertragungen und das Vorhandensein bzw. Nichtvorhandensein der übertragenen Töne in den Tonerweiterungsschlitzen zufällig festlegen können. Da DRBG per Definition deterministisch ist, wissen sowohl Initiator als auch Reflector (jeweils im Besitz von CS_IV, CS_IN und CS_PV), was sie zu erwarten haben, während ein Angreifer dies nicht weiß. Wenn eine der beiden channel sounding unerwartete Bitwerte oder unerwartete Übertragungen (oder ein unerwartetes Ausbleiben von Übertragungen) feststellt, wird dies als potenzieller Angriff gewertet.

Replay-Angriffe können nicht erfolgreich sein, da sich die Abfolge der übertragenen Pakete und Töne jedes Mal ändert, wenn die beiden Geräte eine channel sounding durchführen, und eine einfache Wiedergabe einer aufgezeichneten früheren Reihe von Austauschvorgängen leicht zu erkennen wäre.

8.13.3.3 Schutz vor Symbolmanipulation

Es gibt eine Reihe bekannter Angriffe auf der physikalischen Schicht, bei denen ein Man-in-the-Middle (MITM) den Wert teilweise empfangener Funksymbole von einem rechtmäßigen Sendegerät vorwegnimmt und die vollständigen Versionen dieser Symbole frühzeitig weiterleitet und so das Timing so manipuliert, dass der rechtmäßige Empfänger die Umlaufzeit und damit die Entfernung falsch berechnet. Das Signal des Angreifers wird in der Regel verstärkt, so dass das Zielgerät das manipulierte Signal als primäres Signal ansieht und nicht das schwächere Originalsignal, das aufgrund der Mehrwegeausbreitung als Reflexion angesehen und nicht beachtet werden kann. Dieser Angriff nutzt die übliche, volle Dauer eines Symbols aus, um einen zeitlichen Vorsprung zu erzielen, und Symbole mit einer längeren Dauer sind für diese Art von Angriff anfälliger als solche mit einer kürzeren Dauer.

Der LE 2M 2BT PHY mit seinem product von 2,0 führt zu Symbolimpulsen, die kürzer sind als die mit den anderen PHYs verbundenen Impulse, was das Risiko dieser Arten von Angriffen verringert.

Eine weitere Funktion, die zum Schutz vor Relais-Angriffen eingesetzt werden kann, ist die SNR-Kontrolle.

Die SNR-Kontrolle ermöglicht es dem Initiator und dem Empfänger, einigen Signalen eine vorher vereinbarte Menge an Zufallsrauschen beizumischen. Symbolmanipulations-Relaisangriffe beruhen darauf, dass der Angreifer in der Lage ist, das legitime Signal sehr schnell zu isolieren und zu manipulieren, und zwar in viel weniger Zeit als der vollen Dauer eines Symbols. Durch das Einbringen von Rauschen in das Signal wird die Analyse des Angreifers erschwert und verlangsamt, so dass die Wahrscheinlichkeit, dass solche Angriffe erfolgreich sind, sinkt. Andererseits sind die Initiator- und Reflektorgeräte, die den SNR im Voraus vereinbart haben, in der Lage, das künstlich hinzugefügte Rauschen leicht zu filtern.

8.13.3.4 RF-Signalanalysetechniken und Angriffserkennung

Die Spezifikation von Bluetooth Channel Sounding enthält eine Beschreibung eines Angriffserkennungssystems und eine standardisierte Metrik zur Angabe der Wahrscheinlichkeit, dass ein Angriff im Gange ist, die so genannte Normalized Attack Detector Metric (NADM). NADM verwendet eine gleitende Skala mit zugehörigen adjektivischen Begriffen, wie in Tabelle 15 dargestellt.

NADM-Wert	Beschreibung
0x00	Ein Angriff ist extrem unwahrscheinlich
0x01	Ein Angriff ist sehr unwahrscheinlich
0x02	Ein Angriff ist unwahrscheinlich
0x03	Ein Angriff ist möglich
0x04	Ein Angriff ist wahrscheinlich
0x05	Ein Angriff ist sehr wahrscheinlich
0x06	Ein Angriff ist sehr wahrscheinlich
0xFF	Unbekannter NADM.Standardwert für RTT-Typen, die keine Zufallsfolge oder klingende Folge haben.

Tabelle 15 - NADM-Werte

Zu den Indikatoren für einen möglichen Angriff gehören unerwartete Bitwerte oder Phasenanpassungen. Die Eigenschaften eines Referenzsignals, mit dem Vergleiche angestellt werden können, sind in der Bluetooth festgelegt.

8.14 Anwendungen zur Entfernungsmessung

Bluetooth Channel Sounding selbst berechnet keine Entfernungswerte. Stattdessen stellt es Anwendungen das Rohmaterial zur Verfügung, einschließlich Zeitinformationen sowie Amplituden- und Phasenwerte(IQ-Samples), die in proprietären Entfernungsberechnungsalgorithmen verwendet werden können. Ein Standardalgorithmus ist nicht definiert, da dies keinen Einfluss auf die Interoperabilität hat und es den Herstellern freisteht, sich durch die Qualität der Ergebnisse, die ihre Algorithmen erzielen können, zu unterscheiden.

Anwendungen, die Bluetooth Channel Sounding verwenden, haben eine Reihe von Aufgaben zu erfüllen, unter anderem:

Implementierung eines Algorithmus, der die von Bluetooth Channel Sounding gelieferten Daten zur Berechnung von Entfernungsmessungen verwendet.
Auswahl einer Konfiguration, einschließlich der zu verwendenden Schrittmodi und ihrer Sequenzierungs- und Zeitparameter, die den Anforderungen und Prioritäten der Anwendung entspricht. Dazu gehört auch die Abwägung von Aspekten wie der Latenz gegen die Menge der zu erzeugenden channel sounding .
Verwendung von HCI-Befehlen ( Host Controller Interface) zur Einleitung und Durchführung der in Abschnitt 5 "Bluetooth Channel Sounding Link Layer Control Procedures" beschriebenen Steuerungsverfahren.
Auswahl einer der in GAP definierten Sicherheitsstufen für channel sounding und Konfiguration des channel sounding unter Berücksichtigung der Sicherheitsanforderungen.
Verarbeitung der durch NADM-Werte ausgedrückten Informationen zur Angriffserkennung in einer für die Anwendung geeigneten Weise.

Die Bluetooth Channel Sounding dient als strenger, standardisierter und interoperabler Rahmen für genaue und sichere Entfernungsmessungsanwendungen und bietet den Entwicklern gleichzeitig die Flexibilität, ihre Anwendungen entsprechend ihren jeweiligen Prioritäten zu optimieren.

9. Die isochrone Anpassungsschicht

9.1 Grundsätzliches

Der Zweck des Isochronous Adaptation Layer (ISOAL) besteht im Wesentlichen darin, ein potenzielles Problem zu lösen, das sowohl bei der isochronen Kommunikation mit angeschlossenen als auch bei der Rundfunkkommunikation mit Audiogeräten auftreten kann. Sie kann auch in anderen Bereichen der isochronen Kommunikation Anwendung finden.

9.1.1 Audio-Sampling 101

Digitales Audio funktioniert, indem ein analoges Audiosignal abgetastet und ein Codec auf das abgetastete Audiosignal angewendet wird, um die digitalen Abtastdaten zu komprimieren und anderweitig zu verarbeiten, bevor sie gespeichert oder - im Falle von Bluetooth LE - übertragen werden. Beim Lesen oder Empfangen kodierter digitaler Audiodaten wird der Prozess umgekehrt, wobei ein Codec verwendet wird, um die Daten zu dekodieren und eine Reihe digitaler Abtastwerte zu erzeugen, die dann verwendet werden, um die ursprünglichen analogen Audiodaten (ungefähr) wiederherzustellen. Abbildung 55 veranschaulicht die Schritte der Abtastung, Kodierung und Übertragung eines Audiosignals und die umgekehrten Schritte des Empfangs kodierter Audiodaten, ihrer Dekodierung und schließlich ihrer Wiedergabe.

Abbildung 55 - Schritte der Audioverarbeitung

Eines der Hauptziele eines Audiocodecs ist es, die Größe der Audiodaten zu reduzieren, damit sie effizient über eine Verbindung mit begrenzter (und kostbarer!) Bandbreite übertragen werden können. Bei der Abtastung wird die Amplitude eines Signals in regelmäßigen Abständen gemessen und aufgezeichnet. Die Häufigkeit, mit der ein Abtastwert aufgezeichnet wird, wird als Abtastrate bezeichnet. Die vertikalen Linien in Abbildung 56 stellen Abtastwerte des kontinuierlich variablen Audiosignals dar, das durch die Kurve repräsentiert wird. Diese Reihe von Abtastwerten stellt eine ungefähre Darstellung des ursprünglichen analogen Signals dar. Je häufiger Abtastungen vorgenommen werden (d. h. je höher die Abtastrate), desto näher kommt diese Annäherung an das Original, und wenn man den Prozess umkehrt, um das ursprüngliche Audiosignal wiederherzustellen, sind die Ergebnisse und die wahrgenommene Qualität umso besser.

Eine weitere Dimension der Abtastung ist die Bittiefe. Die Amplitude des Signals muss bei der Abtastung durch einen ganzzahligen Wert dargestellt werden. Ein Ansatz besteht darin, den Bereich der möglichen Amplitudenwerte in 256 diskrete Amplitudenbänder zu unterteilen und jedes durch eine Zahl zwischen 0 und 255 darzustellen. Bei diesem Schema benötigt ein einzelnes Sample nur ein Byte (8 Bits), um das Band aufzuzeichnen, in das der abgetastete Amplitudenwert fällt, und die Bittiefe wird daher als 8 Bits bezeichnet. Die Unterteilung des möglichen Amplitudenbereichs in mehrere diskrete Bänder bietet ein feinkörnigeres System zur Darstellung von Abtastwerten und damit potenziell qualitativ bessere Ergebnisse. Bei einer Bittiefe von 24 Bits beispielsweise kann der Bereich der möglichen Amplitudenwerte durch eine ganze Zahl im Bereich von 0 bis 16.777.215 dargestellt werden. Für jede Abtastung werden jedoch 3 Byte benötigt, so dass bei einer Abtastung mit dieser höheren Bittiefe dreimal so viele Daten erzeugt werden.

Die digitale Abtastung kann große Datenmengen erzeugen. Nehmen wir einen dreiminütigen Song, der mit einer Rate von 44,1 kHz (CD-Qualität) und einer Bittiefe von 24 gesampelt wird. Wenn wir nachrechnen, ergibt sich, dass die Menge an Rohdaten, die benötigt wird, um den gesamten Song in digitaler Form darzustellen, fast 24 Megabyte beträgt. Darüber würden wir uns keine Gedanken machen, wenn wir die Daten nur auf der 4-Terabyte-Festplatte eines Computers speichern wollten, aber bei der Übertragung dieser Daten über eine Kommunikationsverbindung mit begrenzter Bandbreite ist das ein Problem. Hier kommen Codecs ins Spiel.

Abbildung 56 - Diskrete Abtastwerte, die ein kontinuierliches analoges Signal darstellen

9.1.2 Codecs und Frames

Ein Codec wie LC3, der von Bluetooth LE Audio verwendet wird, kann digitale Rohdaten auf weniger als 25 % der ursprünglichen Größe komprimieren (beachten Sie jedoch, dass die tatsächlichen Ergebnisse stark vom ursprünglichen Audioinhalt abhängen). Dies ist eine erhebliche Einsparung.

Codecs arbeiten im Allgemeinen durch Erkennung und Ausnutzung von Mustern, die in einer Reihe von aufeinanderfolgenden Abtastwerten gefunden werden. Um ein sehr einfaches Beispiel zu geben und nur dieses Prinzip zu veranschaulichen: Wenn der Datensatz eine Reihe von 100 aufeinanderfolgenden Abtastwerten enthält, die alle den gleichen Wert von, sagen wir, 50 haben, dann könnte ein Codec unter der Annahme einer Bittiefe von 8 Bit dies als zwei Bytes darstellen, die [100,50] enthalten, anstatt die ursprüngliche Reihe von 100 Bytes, die die Liste der einzelnen Abtastwerte [50,50,50...,50] enthalten. Damit ein Codec funktioniert, braucht er natürlich eine ganze Reihe von Samples, die er analysieren und kodieren kann, und nicht nur ein Sample auf einmal (in einem einzelnen Sample sind nicht viele Muster zu finden!).

Eine Sammlung von Samples, die gleichzeitig von einem Codec analysiert werden, wird als Frame bezeichnet. Frames haben eine feste Dauer, die normalerweise in Millisekunden gemessen wird, und enthalten eine durch die Abtastrate bestimmte Anzahl von Samples. Zum Beispiel enthält ein 10ms-Frame 4410 Samples, wenn die Samplerate 44,1 KHz beträgt.

Verschiedene Audioprodukte können unterschiedliche Frame-Dauern verwenden. 10 ms und 7,5 ms sind üblich. Wenn ein Gerät (die Quelle) Audio mit einer bestimmten Rahmendauer produziert und ein anderes Gerät (die Senke) es konsumiert, aber eine andere Rahmendauer verwendet, gibt es ein Problem, das gelöst werden muss. Hier kommt ISOAL ins Spiel.

9.2 Gerahmt vs. ungerahmt

Wenn Geräte eine isochrone Kommunikation verwenden, müssen die vom sendenden Gerät und einem empfangenden Gerät verwendeten Rahmendauern nicht gleich sein. Dies führt zu zwei möglichen Situationen:

Die vom ersten Gerät verwendete Bilddauer ist ein exaktes Vielfaches der vom anderen Gerät verwendeten Bilddauer.
Die vom ersten Gerät verwendete Rahmendauer ist nicht ein exaktes Vielfaches der vom anderen Gerät verwendeten Rahmendauer.

In der ersten Situation ist die Beziehung zwischen der größeren und der kleineren Rahmendauer einfach, und die Umwandlung von Daten zwischen den beiden ist ein unkomplizierter Vorgang. Daten, die in der Nutzlast einer oder mehrerer erforderlicher Link-Layer-PDUs gesendet werden, gelten als rahmenlos und enthalten keine zusätzlichen Daten zur Unterstützung der Anpassung der Rahmendauer zwischen den beiden Anforderungen.

Im zweiten Fall können Link-Layer-PDUs Teile der größeren Nutzlast zusammen mit kurzen Header-Feldern enthalten, die anzeigen, ob ein Teil der Beginn eines Rahmens, eine Fortsetzung oder das Ende eines Rahmens ist. Auf diese Weise formatierte Daten werden als Frames bezeichnet.

Sowohl Connected Isochronous PDUs als auch Broadcast Isochronous PDUs (definiert durch die Verbindungsschicht) enthalten ein Feld namens LLID. LLID zeigt an, ob die Nutzlast der Link-Layer-PDU gerahmte oder ungerahmte Daten enthält. Je nachdem, ob die Daten gerahmt oder ungerahmt sind, wendet ISOAL auf die Daten, die es von der Sicherungsschicht erhält, unterschiedliche Verfahren an. In ähnlicher Weise wirkt sich die Frage, ob Framing erforderlich ist oder nicht, auf die ISOAL-Verarbeitung von Daten aus, die es in SDUs der oberen Schicht empfängt und zur Übertragung in ISO-PDUs der Sicherungsschicht an die Sicherungsschicht weitergibt.

9.3 Fragmentierung und Rekombination

Sind die Daten rahmenlos, wird durch Rekombination eine einzelne Dienstdateneinheit (SDU) aus einer Reihe von einem oder mehreren Fragmenten erstellt, die in der Nutzlast einer oder mehrerer PDUs der Verbindungsschicht enthalten sind. Der ISOAL leitet dann die SDU an die obere Schicht weiter. Dies ist in Abbildung 57 dargestellt.

Abbildung 57 - Rekombination von ungerahmten ISO-PDUs

Wenn SDUs der oberen Schicht für die Übertragung in PDUs der Verbindungsschicht in kleinere Nutzdaten aufgeteilt werden müssen und kein Framing erforderlich ist, wird dieser Vorgang als Fragmentierung bezeichnet. Dies ist in Abbildung 58 dargestellt.

Abbildung 58 - Fragmentierung erzeugt ungerahmte ISO-PDUs

Unframed PDUs haben einen Header, der Felder enthält, die anzeigen, dass die folgenden Daten entweder der Beginn einer SDU, die Fortsetzung der vorherigen SDU oder das Ende dieser SDU sind. PDUs enthalten immer nur ein einziges Fragment einer ungerahmten SDU.

9.4 Segmentierung und Wiederzusammenbau

Wenn die Daten gerahmt sind, wird durch die Neuzusammensetzung eine einzelne Dienstdateneinheit (SDU) aus einer Reihe von einem oder mehreren Segmenten in der Nutzlast einer oder mehrerer PDUs der Verbindungsschicht erstellt. Der ISOAL übergibt dann die SDU an die obere Schicht. Dies ist in Abbildung 59 dargestellt.

Abbildung 59 - Wiederzusammenbau von gerahmten ISO-PDUs

Wenn SDUs der oberen Schicht in kleinere Nutzdaten für die Übertragung in PDUs der Verbindungsschicht aufgeteilt werden müssen und ein Framing erforderlich ist, wird dieser Vorgang als Segmentierung bezeichnet. Dies ist in Abbildung 60 dargestellt.

Abbildung 60 - Segmentierung zur Erstellung von gerahmten ISO-PDUs

Segmente in gerahmten PDUs haben einen Header, der Felder enthält, die anzeigen, dass die folgenden Daten entweder der Beginn einer SDU, die Fortsetzung der vorherigen SDU oder das Ende dieser SDU sind, sowie Zeitversatzinformationen. PDUs können mehrere Fragmente einer gerahmten SDU enthalten.

10. DieController

10.1 Grundsätzliches

DieController (HCI) definiert eine standardisierte Schnittstelle, über die ein host Befehle an den controller erteilen kann und ein controller mit dem host kommunizieren kann. Die Spezifikation ist in mehrere Teile aufgeteilt, wobei der erste Teil die Schnittstelle nur in funktionaler Hinsicht definiert, ohne Rücksicht auf spezifische Implementierungsmechanismen, und die anderen Teile definieren, wie HCI bei Verwendung einer der vier möglichen physikalischen Transportarten implementiert werden kann.

HCI wird sowohl von Bluetooth LE als auch von Bluetooth BR/EDR verwendet.

10.2 Die HCI-Funktionsspezifikation

Die funktionale Schnittstelle wird in Form von Befehlen und Ereignissen definiert . Dabei handelt es sich im Wesentlichen um Nachrichten, die zwischen host und Steuerung ausgetauscht werden können. Befehle werden vom host an die Steuerung gesendet und Ereignisse von der Steuerung an den host. Ein Ereignis kann eine Antwort auf einen Befehl sein oder durch eine unaufgeforderte Nachricht gesendet werden. Siehe Abbildung 61.

Abbildung 61 - HCI-Befehle und Ereignisse

10.3 HCI-Transporte

Die vier HCI-Transportarten sind:

UART
USB
Sicher Digital (SD)
Dreidraht-UART

10.3.1 UART-Transport

Der HCI-UART-Transport kann zur Implementierung der HCI-Kommunikation über UART verwendet werden, wenn sowohl der host als auch der controller über UART auf derselben Leiterplatte angeschlossen sind. Es wird ein Protokoll definiert, das auf 5 Pakettypen basiert. Dabei handelt es sich um das HCI-Befehlspaket, das HCI-ACL-Datenpaket, das HCI-Synchrondatenpaket, das HCI-Ereignispaket und das HCI-ISO-Datenpaket.

Die Anforderungen an die RS232-Konfiguration sind festgelegt. Zusammenfassend lässt sich sagen, dass der UART-Transport 8 Datenbits, keine Parität, 1 Stoppbit und RTS/CTS-Flusskontrolle verwendet.

10.3.2 USB-Transport

USB kann auf zwei Arten als HCI-Transportmittel verwendet werden. Dercontroller kann in einem USB-Dongle implementiert werden. Alternativ kann USB auch intern in einem product verwendet werden, um host und controller zu verbinden.

Der USB-Standard definiert Puffer, in die Daten gesendet oder von denen sie empfangen werden können, sogenannte Endpunkte. Die HCI-USB-Transport-Spezifikation gibt die erwarteten Endpunkte und ihre erforderlichen oder vorgeschlagenen Eigenschaften an.

10.3.3 Sicher digital

Ein Protokoll zur Verwendung mit dem HCI-SD-Transport wird von der Secure Digital Association (SDA) definiert und verwaltet. Der Abschnitt der Bluetooth über den HCI-SD-Transport besteht größtenteils aus Verweisen auf externe Spezifikationen der SDA sowie aus einem Überblick über die Kommunikationsarchitektur.

10.3.4 Dreidraht-UART

Die Spezifikation für den Dreidraht-UART-HCI-Transport beschreibt eine Architektur und ein Protokoll für die Kommunikation von HCI-Befehlen und -Ereignissen zwischen zwei dreidrahtverbundenen UARTs. Sie befasst sich mit Zuverlässigkeit, Datenintegrität, Verbindungsaufbau, Energieverwaltung und Hardwarekonfiguration.

10.4 HCI-Beispiele

Es folgen eine Reihe von Beispielen, die die funktionale HCI-Schnittstelle in Aktion zeigen.

10.4.1 Verbindungslose AoA/AoD

Abbildung 62 zeigt den Austausch von HCI-Befehlen und -Ereignissen während der Konfiguration des Controllers durch den host , um die Übertragung von Paketen vorzubereiten, die die Peilung entweder nach dem Ankunftswinkel (AoA) oder dem Abfahrtswinkel (AoD) unterstützen.

Abbildung 62 - Verbindungslose controller

10.4.2 LE-Pfadverlust-Überwachung

Die Überwachung des LE-Pfadverlustes ist Teil der LE-Leistungssteuerung. Ein Gerät, das die von einem angeschlossenen Peer-Gerät verwendete Sendeleistung verwalten möchte, um sie innerhalb des optimalen Leistungsbereichs für den Empfänger zu halten, könnte diese Funktion nutzen.

Abbildung 63 zeigt einen host , der die HCI-Befehle sendet, die zur Konfiguration und anschließenden Aktivierung der LE-Pfadverlustüberwachung erforderlich sind. Nachdem die Überwachung aktiviert wurde, sendet der Controller LE Path Loss Threshold-Ereignisse mit Pfadverlustdaten an den host.

Abbildung 63 - LE-Pfadverlustüberwachung

10.4.3 Aktives Scannen

Aktives Scannen wird von Peripheriegeräten unterstützt, die Legacy-Werbung verwenden und mehr Daten übermitteln müssen, als in einem einzigen Werbepaket enthalten sein können. Weitere Informationen zu diesem Thema finden Sie in Abschnitt 14.3 Discovery.

Abbildung 64 zeigt die host in einem Gerät(Gerät A), das seinen Controller für aktives Scanning konfiguriert und dann mit einem separaten Befehl das Scanning durch Aktivierung einleitet. Wenn abfragbare Werbepakete wie ADV_IND von einem anderen Gerät durch die Verbindungsschicht von Gerät A empfangen werden, antwortet es, weil es für aktives Scannen konfiguriert wurde, indem es eine SCAN_REQ PDU sendet und eine SCAN_RSP PDU vom anderen Gerät zurückerhält. Der Inhalt des ursprünglichen Werbepakets und die Scan-Antwort werden dann in einer Reihe von HCI LE Advertising Report-Ereignissen an den Host von Gerät A weitergeleitet.

Abbildung 64 - Aktives Scannen

11. Das Logical Link Control and Adaptation Protocol

11.1 Grundsätzliches

Das Logical Link Control and Adaptation Protocol (L2CAP) ist für das Protokollmultiplexing, die Flusskontrolle sowie die Segmentierung und den Wiederzusammenbau von Dienstdateneinheiten (SDUs) zuständig.

L2CAP verwendet das Konzept des Kanals, um Sequenzen von Paketen zu trennen, die zwischen den Schichten des Stacks übertragen werden. Feste Kanäle erfordern keine Einrichtung, sind sofort verfügbar und werden einem bestimmten Protokoll der höheren Schicht zugeordnet. Kanäle können auch dynamisch erstellt und über einen bestimmten PSM-Wert (Protocol Service Multiplexer) mit einem Protokoll verbunden werden.

In Abbildung 65 sind die primären L2CAP-Funktionen dargestellt.

Abbildung 65 - L2CAP-Primärfunktionen

11.2 L2CAP und Protokoll-Multiplexing

Oberhalb von L2CAP im Stack befinden sich Schichten, die unterschiedliche Protokolle wie das Attributprotokoll (ATT) und das Sicherheitsmanagerprotokoll (SMP) verwenden. Das L2CAP-Protokollmultiplexing stellt sicher, dass SDUs im Stack an die entsprechende Schicht zur Verarbeitung weitergeleitet werden.

Wenn ein L2CAP-Kanal das Attributprotokoll abwickelt, verwendet er entweder einen festen Kanal, der für ATT reserviert ist und in diesem Fall als nicht erweiterter ATT-Träger fungiert, oder er verwendet eine Reihe von einem oder mehreren dynamischen Kanälen, die jeweils als erweiterter ATT-Träger fungieren. Der nicht erweiterte ATT-Träger unterstützt ATT-Transaktionen, die nacheinander ausgeführt werden, eine nach der anderen. Der erweiterte ATT-Träger unterstützt parallele ATT-Transaktionen, die sequentiell innerhalb paralleler L2CAP-Kanäle ausgeführt werden. Siehe 12. Das Attributprotokoll für weitere Einzelheiten hierzu.

11.3 L2CAP und Flusskontrolle

Bei der Flusskontrolle geht es darum, sicherzustellen, dass die Geschwindigkeit, mit der Pakete von einer Schicht eines Stapels erzeugt werden, nicht die Geschwindigkeit übersteigt, mit der eine Schicht im selben Stapel oder auf einem entfernten Gerät diese Pakete verarbeitet. Ohne Flusskontrolle besteht die Gefahr von Problemen wie Pufferüberläufen.

Die kreditbasierte Flusskontrolle ist einer von vielen möglichen Ansätzen zur Flusskontrolle. In groben Zügen funktioniert sie wie folgt:

Das sendende Gerät kennt die Kapazität des empfangenden Geräts, d. h. die Anzahl der PDUs, die es verarbeiten kann, ohne dass Daten verloren gehen (z. B. weil der Puffer überläuft). Es erhält diese Kapazitätsinformationen durch die Konfiguration oder durch einen Austausch zwischen den beiden Geräten, bevor die Datenübertragung beginnt.
Der Sender setzt einen Zähler auf die Kapazitätsgrenze des Empfängers. Jedes Mal, wenn eine PDU vom Sender gesendet wird, wird der Zähler dekrementiert. Wenn der Zählerwert Null erreicht, weiß der Sender, dass die Kapazität des Empfängers ausgeschöpft ist, und stoppt daher vorübergehend das Senden weiterer PDUs, während der Empfänger seinen Rückstand abarbeitet.
Nachdem der Empfänger eine oder mehrere PDUs aus seinem Puffer gelesen und verarbeitet hat, sendet er eine entsprechende Anzahl von Credits an den Sender zurück, der damit seinen Zähler inkrementiert. Wenn der Zähler einen Wert ungleich Null hat, kann der Sender weitere PDUs senden.

L2CAP definiert mehrere Betriebsmodi, die sich hauptsächlich auf die Flusskontrolle beziehen.

ATT über einen nicht erweiterten L2CAP-Träger verwendet beispielsweise den einfachen L2CAP-Modus, der keine Flusskontrolle bietet. Dies macht ATT unzuverlässig, und die Anwendungen müssen die Möglichkeit in Betracht ziehen, dass übertragene ATT-PDUs vom empfangenden Gerät verloren gehen können. Im Falle von unbestätigten PDUs, wie z. B. Benachrichtigungen, weiß das sendende Gerät dank der Bestätigungen auf der Verbindungsschicht, ob die PDU vom Stack auf dem entfernten Gerät empfangen wurde oder nicht, hat aber keine Möglichkeit zu erfahren, ob die PDU erfolgreich an die empfangende Anwendung am oberen Ende des Stacks übermittelt wurde.

ATT über einen L2CAP-erweiterten ATT-Träger verwendet den Enhanced Credit Based Flow Control Mode, der eine Flusskontrolle bietet. EATT kann daher als zuverlässig angesehen werden.

11.4 L2CAP-Segmentierung und Neuzusammensetzung

Für Schichten oberhalb und unterhalb von L2CAP gilt eine MTU-Größe (Maximum Transmission Unit), die angibt, wie groß eine PDU des Typs sein darf, der von dieser Schicht erstellt wird. Der ATT_MTU-Parameter definiert beispielsweise die maximale Größe, die eine ATT-PDU haben darf.

L2CAP selbst und die darüber oder darunter liegenden Schichten können unterschiedliche MTU-Größen haben, so dass es erforderlich sein kann, einige PDUs/SDUs in eine Reihe kleinerer Teile aufzuteilen, die die benachbarte Schicht verarbeiten kann, oder umgekehrt eine Reihe zusammengehöriger kleinerer Teile wieder zu vollständigen PDUs/SDUs zusammenzufügen. Diese Prozesse, wie sie von L2CAP in Bezug auf die oberen Schichten angewandt werden, werden als Segmentierung und Reassemblierung bezeichnet, während die entsprechenden Prozesse, wie sie sich auf L2CAP und seine Beziehung zu den unteren Schichten beziehen, als Fragmentierung und Rekombination bezeichnet werden.

12. Das Attributprotokoll

12.1 Grundsätzliches

Das Attributprotokoll (ATT) wird von zwei Geräten verwendet, von denen eines die Rolle des Clients und das andere die des Servers übernimmt. Der Server stellt eine Reihe von zusammengesetzten Datenelementen zur Verfügung, die als Attribute bezeichnet werden. Die Attribute werden vom Server in einer indizierten Liste, der Attributtabelle, organisiert.

Jedes Attribut enthält einen Handle, einen Universally Unique Identifier (UUID), einen Wert und eine Reihe von Berechtigungen.

Der Handle ist ein eindeutiger Indexwert, mit dem ein ATT-Client auf einen bestimmten Eintrag in der Attributtabelle verweisen kann.
Die UUID identifiziert den Typ des Attributs.
Das Berechtigungsfeld besteht aus einer Reihe von Flags, die angeben, ob der Zugriff lesend, schreibend oder in beiden Formen erlaubt ist, sowie aus anderen Sicherheitsbedingungen, die erfüllt sein müssen, damit der Zugriff erlaubt ist.
Das Studienhandbuch von Bluetooth SIG Verstehen der Sicherheit in Bluetooth LE enthält weitere Informationen über Attributberechtigungen.
Das Attributwertfeld ist ein Byte-Array, das den Wert des Attributs enthält. Die Interpretation des Byte-Arrays sowohl in Bezug auf die Datentypen als auch auf die Semantik ist Sache der höheren Schichten des Stacks.

Das Generic Attribute Profile (GATT) definiert, wie Attribute Konstrukte höherer Ebene, bekannt als Dienste, Merkmale und Deskriptoren, darstellen können. Typischerweise wird eine Gruppe von Attributen in einem zusammenhängenden Handle-Wertebereich benötigt, um komplexere Typen wie diese zu repräsentieren, und das Attributprotokoll unterstützt aus diesem Grund die Arbeit mit Gruppen von Attributen, die durch einen Handle-Wertebereich identifiziert werden. Siehe Abschnitt 13. Das generische Attributprofil für weitere Informationen hierzu.

ATT wird von einem ATT-Client verwendet, um Einzelheiten der Attributtabelle in einem ATT-Server zu ermitteln, einschließlich der Handle-Werte von Attributen oder Attributtypen von Interesse. Wenn die Handle-Werte bekannt sind, können sie mit einigen PDU-Typen verwendet werden, um bestimmte Attribute in der Tabelle zu identifizieren und dann auf sie einzuwirken. Zum Beispiel kann das ATT_READ_BY_GROUP_TYPE_REQ PDU verwendet werden, um das Handle und die UUID aller Attribute zu finden, die Teil der Definition eines Primärdienstes sind. Eine kürzere Formulierung ist, dass die ATT_READ_BY_GROUP_TYPE_REQ PDU verwendet werden kann, um alle GATT-Primärdienste zu finden, die z.B. durch die Attributtabelle definiert sind.

Bei der Verwendung von PDUs wie ATT_READ_BY_GROUP_TYPE_REQ, die Discovery-Operationen unterstützen, wird ein Handle-Bereich angegeben, der die Teilmenge der zu durchsuchenden Einträge in der Attributtabelle (und das kann die gesamte Tabelle sein) und einen Attributtyp angibt, nach dem gesucht werden soll. Abbildung 66 veranschaulicht diesen Vorgang, wobei alle Primärdienste gesucht werden und die Antwort den Bereich der Handle-Werte angibt, der Attribute enthält, die sich auf den gefundenen Primärdienst beziehen.

Abbildung 66 - Anfrage und Antwort zum Lesen nach Gruppentyp

ATT ist einer der primären Mechanismen, über den Anwendungen in verbundenen Bluetooth LE miteinander interagieren. Dabei werden die vom Protokoll definierten PDUs und Verfahren verwendet, die in Spezifikationen auf höherer Ebene, wie dem Generic Attribute Profile (GATT), festgelegt sind.

Zwei Varianten des ATT sind definiert, das Basis-ATT und das neuere Enhanced Attribute Protocol (EATT).

ATT kann sowohl von Bluetooth LE als auch von Bluetooth BR/EDR verwendet werden. In diesem Dokument wird nur ATT in Verbindung mit Bluetooth LE betrachtet.

12.2 ATT PDUs

Das Attributprotokoll definiert 31 verschiedene PDUs, die jeweils auf einer von sechs allgemeinen Methoden beruhen.

12.2.1 Befehle

Eine ATT-Befehls-PDU wird von einem Client an einen Server gesendet, ohne dass eine Antwort vom Server angefordert wird. Ein Beispiel für einen Befehl ist der in Abbildung 67 dargestellte ATT_WRITE_CMD.

Abbildung 67 - ATT_WRITE_CMD

12.2.2 Ersuchen und Antworten

Eine ATT-Anfrage-PDU wird von einem Client an einen Server gesendet. Vom Server wird erwartet, dass er innerhalb von 30 Sekunden mit einer Antwort-PDU des entsprechenden Typs oder mit einer Fehlerantwort-PDU (ATT_ERROR_RSP) antwortet. Wird nicht innerhalb von 30 Sekunden geantwortet, gilt dies als Zeitüberschreitung.

Ein Beispiel für ein PDU-Paar aus Anfrage und Antwort sind die in Abbildung 68 dargestellten PDUs ATT_WRITE_REQ und ATT_WRITE_RSP.

Abbildung 68 - ATT_WRITE_REQ

12.2.3 Benachrichtigungen

Benachrichtigungen sind unaufgeforderte PDUs vom Typ ATT_HANDLE_VALUE_NTF, die von einem Server an einen Client gesendet werden. Es ist keine Antwort-PDU definiert. Siehe Abbildung 69.

Abbildung 69 - ATT_HANDLE_VALUE_NTF

12.2.4 Hinweise und Bestätigungen

Eine ATT Indication PDU wird von einem Server an einen Client gesendet. Vom Client wird erwartet, dass er innerhalb von 30 Sekunden mit einer Bestätigungs-PDU eines entsprechenden Typs oder mit einer Fehlerantwort-PDU (ATT_ERROR_RSP) antwortet. Erfolgt die Antwort nicht innerhalb von 30 Sekunden, gilt dies als Zeitüberschreitung.

Ein Beispiel für ein PDU-Paar aus Anzeige und Bestätigung sind die PDUs ATT_HANDLE_VALUE_IND und ATT_HANDLE_VALUE_CFM, die in Abbildung 70 - Anzeigen und Bestätigungen dargestellt sind.

Abbildung 70 - Anzeigen und Bestätigungen

12.2.5 PDU-Format

Alle ATT-PDUs haben die gleiche Struktur, bestehend aus einem Opcode, der den PDU-Typ identifiziert, einer Reihe von Parametern und einer optionalen Authentifizierungssignatur. Es ist zu beachten, dass das Signaturfeld nur selten verwendet wird und überflüssig ist, wenn das Attributprotokoll über eine verschlüsselte Verbindung läuft, da alle verschlüsselten Pakete auf der Verbindungsschicht Authentifizierungsdaten enthalten.

12.2.6 Maximale Übertragungseinheit

Die maximale Länge einer ATT-PDU hängt von dem festgelegten MTU-Wert (Maximum Transmission Unit) ab. Je nachdem, welcher Träger[11] für ATT verwendet wird, kann einer von zwei Mechanismen zur Festlegung der MTU verwendet werden.

12.3 Vorgänge

ATT definiert das Konzept einer Transaktion. Von einem Client angeforderte PDUs werden vom Server innerhalb von 30 Sekunden mit einer Antwort-PDU beantwortet. Von einem Server gesendete Indikationen müssen vom Client innerhalb von 30 Sekunden mit einer Bestätigungs-PDU beantwortet werden. Jedes Anfrage/Antwort-Paar oder Anzeige/Bestätigung-Paar bildet eine Transaktion. Wenn eine Transaktion eine Zeitüberschreitung aufweist, gilt sie als gescheitert und es dürfen keine weiteren PDUs irgendeiner Art über den aktuellen Träger gesendet werden.

ATT verwendet ein sequentielles Transaktionsmodell. Das bedeutet, dass, wenn eine ATT-Transaktion gestartet wurde, keine weiteren ATT-PDUs durch dieselbe Trägerinstanz verarbeitet werden dürfen, bis die aktuelle Transaktion abgeschlossen ist. Die Transaktion gilt als abgeschlossen, wenn die erwartete Antwort- oder Bestätigungs-PDU von dem entfernten Gerät empfangen wurde oder wenn die Transaktion nach einer Wartezeit von 30 Sekunden abgelaufen ist.

12.4 Träger

ATT wird von der darunter liegenden L2CAP-Schicht auf eine von zwei Arten gehandhabt, die jeweils als Bearer bezeichnet werden. Die beiden ATT-Bearer sind der Unenhanced ATT-Bearer und der Enhanced ATT-Bearer. Welcher Träger verwendet wird, hat Auswirkungen auf die Art und Weise, in der ATT verwendet werden kann, und in einigen Fällen auf die Zuverlässigkeit des Protokolls. Das generische Attributprofil befasst sich mit der Verwendung von ATT und besagt zum Beispiel, dass:

Der unverbesserliche ATT-Träger

Verwendet einen festen L2CAP-Kanal, daher darf es nur eine Instanz dieses Trägers geben.
Transaktionen sind streng sequentiell, unabhängig davon, wie viele Clients auf der Anwendungsschicht ATT verwenden. Dies kann bedeuten, dass eine von einer Anwendung eingeleitete Transaktion Transaktionen verzögern kann, die eine andere Anwendung starten möchte.
Die PDUs ATT_EXCHANGE_MTU_REQ und ATT_EXCHANGE_MTU_RSP können ausgetauscht werden, um die Wahl der ATT-MTU zu beeinflussen, die über den unverstärkten ATT-Träger verwendet werden soll.
Alle von einem Client empfangenen Meldungen, die aufgrund von Problemen wie Pufferüberlauf nicht verarbeitet werden können, werden verworfen. Daher gilt die ATT_HANDLE_VALUE_NTF-PDU als unzuverlässig, wenn sie über den Unenhanced ATT-Bearer verwendet wird.
Die Unterstützung einiger PDU-Typen wie ATT_MULTIPLE_HANDLE_VALUE_NTF, ATT_READ_MULTIPLE_VARIABLE_REQ und ATT_READ_MULTIPLE_VARIABLE_RSP ist bei Verwendung des Unenhanced ATT bearer optional.
Der L2CAP-Kanal, der den Unenhanced ATT-Träger unterstützt, kann unverschlüsselt oder verschlüsselt sein.

Der Enhanced ATT-Träger

Verwendet dynamische L2CAP-Kanäle und mehrere Kanäle und damit mehrere Trägerinstanzen sind zulässig.
Die Transaktionen werden sequentiell, aber pro Träger, abgewickelt. Daher sind innerhalb eines Stapels parallele Transaktionen möglich, die jeweils von einer separaten Enhanced ATT-Trägerinstanz abgewickelt werden. Dies hat offensichtliche Vorteile, da die Möglichkeit vermieden wird, dass die Nutzung von ATT durch eine Anwendung von einer anderen blockiert wird.
ATT MTU wird automatisch auf den MTU-Wert gesetzt, der auf der L2CAP-Schicht verwendet wird, und die ATT_EXCHANGE_MTU_REQ- und ATT_EXCHANGE_MTU_RSP-PDUs sind über einen Enhanced ATT-Träger nicht zulässig.
Eine L2CAP-Flusskontrollmethode namens Enhanced Credit Based Flow Control Mode wird mit dem Enhanced ATT-Bearer verwendet. Dies hat zur Folge, dass PDUs, die bei der Verwendung über den Unenhanced ATT-Bearer unzuverlässig sind, bei der Verwendung eines Enhanced ATT-Bearer als zuverlässig angesehen werden können.
Die Unterstützung einiger PDUs wie ATT_MULTIPLE_HANDLE_VALUE_NTF, ATT_READ_MULTIPLE_VARIABLE_REQ und ATT_READ_MULTIPLE_VARIABLE_RSP ist bei Verwendung des erweiterten ATT-Trägers obligatorisch.
Der L2CAP-Kanal, der den Enhanced ATT-Träger unterstützt, muss ein verschlüsselter Kanal sein.

12.5 Entdeckung der Unterstützung für EATT

Der definierte generische Attributprofildienst ermöglicht es einem Client, festzustellen, ob ein verbundener Server EATT unterstützt oder nicht, und umgekehrt dem Client zu ermöglichen, den Server darüber zu informieren, dass er EATT unterstützt.

Ein Merkmal namens Server Supported Features muss in den Dienst Generic Attribute Profile aufgenommen werden, wenn EATT vom Server unterstützt wird. Bit 0 des ersten Oktetts des Wertes dieses Merkmals auf 1 gesetzt bedeutet, dass EATT unterstützt wird. Ein GATT/ATT-Client kann durch Auslesen dieses Merkmals feststellen, ob der Server EATT unterstützt oder nicht.

Der Merkmalswert Client Supported Features besteht aus Bits, die anzeigen, ob bestimmte Merkmale unterstützt werden oder nicht. Bit 1 zeigt an, ob der Enhanced ATT Bearer vom Client unterstützt wird oder nicht. Bit 2 zeigt an, ob die ATT_MULTIPLE_HANDLE_VALUE_NTF PDU unterstützt wird oder nicht. Der Client muss einen entsprechenden Wert in dieses Merkmal schreiben, um dem Server mitzuteilen, welche Merkmale er unterstützt.

Abbildung 71 - Erkennung der EATT-Funktionsunterstützung

13. Das generische Attributprofil

13.1 Grundsätzliches

Das generische Attributprofil (GATT) definiert Datentypen höherer Ebene, die auf den in der Attributtabelle enthaltenen Attributen basieren (siehe 12. Das Attributprotokoll). Diese Datentypen werden als Dienste, Merkmale und Deskriptoren bezeichnet. Es definiert auch eine Reihe von Verfahren zur Verwendung dieser Datentypen über das Attributprotokoll (ATT). Anwendungen verwenden in der Regel Plattform-APIs, die auf diese Prozeduren abgebildet werden.

Dienste sind Gruppierungsmechanismen, die einen Kontext für die Nutzung der in ihnen enthaltenen Merkmale bieten und einen definierten Typ haben. Häufig entsprechen Dienste einem primären Merkmal oder einer Fähigkeit eines Geräts.

Merkmale sind einzelne Elemente von Zustandsdaten und haben einen Typ, einen zugehörigen Wert und eine Reihe von Eigenschaften, die angeben, wie die Daten in Bezug auf Gruppen von verwandten GATT-Verfahren verwendet werden können. So kann beispielsweise festgelegt werden, dass ein angeschlossenes Peer-Gerät den Wert eines bestimmten Merkmals lesen, aber nicht in dieses Merkmal schreiben kann.

Merkmale gehören zu einer Dienstleistung. Ein und derselbe Merkmalstyp kann Mitglied von mehr als einem Dienst sein, und je nach den verschiedenen Kontexten, die diese Dienste bieten, können die Regeln für die Verwendung des Merkmals variieren. Eine Leistungsbeschreibung enthält diese Details.

Deskriptoren gehören zu einigen Merkmalen und können Metadaten wie eine textliche Beschreibung des Merkmals enthalten oder ein Mittel zur Steuerung des Verhaltens eines Merkmals darstellen. Merkmale haben null oder mehr Deskriptoren, die ihnen zugeordnet sind. Zum Beispiel definiert GATT eine Operation namens Merkmalswert-Benachrichtigung, die beinhaltet, dass ein Gerät eine ATT PDU mit einem Merkmalswert asynchron an den verbundenen Peer sendet, ohne eine Antwort vom anderen Gerät zu verlangen. Wenn ein Merkmal Benachrichtigungen unterstützt, werden diese typischerweise entweder bei Änderung des Merkmalswertes oder periodisch, gesteuert durch einen Timer, gesendet. Dies geschieht durch das Setzen einer Markierung in einem bestimmten Deskriptortyp, dem Client Characteristic Configuration Deskriptor, den das Merkmal haben muss, wenn es Meldungen unterstützt.

Die hierarchische Struktur der Dienste, Merkmale und Deskriptoren ist in Abbildung 72 dargestellt.

Abbildung 72 - Dienstleistungen, Merkmale und Deskriptoren

GATT definiert zwei Rollen. Der GATT-Client sendet ATT-Befehle und -Anfragen an den GATT-Server. Der GATT-Server akzeptiert und verarbeitet die von einem GATT-Client empfangenen Befehle und Anfragen und sendet dem GATT-Client ATT-Benachrichtigungen, Hinweise und Antworten.

Zwei spezielle Dienste sind in allen GATT-Servern obligatorisch. Dies sind der generische Zugriffsdienst und der generische Attributdienst.

13.2 Bluetooth SIG vs. Benutzerdefiniert

Einige Dienste, Merkmale und Deskriptoren werden von der Bluetooth SIG definiert und haben 16-Bit-UUID-Werte, die ihren Typ identifizieren. Die Bluetooth SIG der einzelnen definierten Typen ist unter specifications/assigned-numbers verfügbar. Implementierer können 16-Bit-UUIDs und andere Arten von zugewiesenen Nummern erwerben, wie unter https://support.bluetooth.com/hc/en-us/articles/360062030092-Requesting-Assigned-Numbers beschrieben .

Ein Implementierer kann benutzerdefinierte Dienste, Merkmale und Deskriptoren definieren. Benutzerdefinierte Dienste, Merkmale und Deskriptoren können entweder durch vom Implementierer zugewiesene 128-Bit-UUID-Werte identifiziert werden oder der Implementierer kann 16-Bit-UUID-Werte von der Bluetooth SIG erwerben. 16-Bit-UUIDs haben auch einen entsprechenden 128-Bit-Wert in der Form 0000XXXX-0000-1000-8000-00805F9B34FB, wobei XXXX der 16-Bit-UUID-Wert ist. Implementierer dürfen keine UUIDs in diesem Bereich verwenden, es sei denn, eine UUID wurde von der Bluetooth SIG erworben.

Ein GATT-Server kann nur von Bluetooth SIG definierte Dienste, Merkmale und Deskriptoren (Attribute) oder eine Mischung aus von Bluetooth SIG definierten Attributen und eigenen Attributen enthalten.

13.3 Verfahren

GATT-Prozeduren, die u.a. die Entdeckung von Diensten, die Entdeckung von Merkmalen, die Entdeckung von Deskriptoren, das Lesen und Schreiben von Merkmalswerten und die Benachrichtigung und Anzeige von Merkmalswerten abdecken, sind definiert. Die GATT-Spezifikation bietet eine klare Zuordnung zwischen ihren Prozeduren und dem zugrunde liegenden ATT-Protokoll, das diese Prozeduren verwenden müssen.

13.4 Beispiele

13.4.1 Bluetooth SIG nur definierte Attribute

Abbildung 73 zeigt ein Beispiel für einen Satz von Diensten mit ihren Merkmalen. Ein Merkmal hat einen zugehörigen Deskriptor. Jedes Attribut in diesem Beispiel wird von der Bluetooth SIG definiert.

Abbildung 73 - Ein Beispielsatz von Diensten, Merkmalen und Deskriptoren

Die dargestellten Dienste sind diejenigen, die ein Gerät, das das Standard-Näherungsprofil implementiert, wahrscheinlich haben würde (die Dienste Sofortalarm und Sendeleistung sind nicht obligatorisch). Beachten Sie, dass das Merkmal " Alarmstufe" zweimal vorkommt, einmal im Dienst " Verlust der Verbindung" und einmal im Dienst " Sofortige Alarmierung ". Die UUID ist in beiden Fällen die gleiche. Dadurch wird das Merkmal als Alarmstufenmerkmal identifiziert. Der Dienst, in dem das Merkmal gruppiert ist, bietet jedoch einen anderen Kontext, und die Regeln und das Verhalten in Bezug auf das Merkmal " Alarmstufe" unterscheiden sich in den beiden Diensten.

Das Merkmal " Service geändert" hat einen zugehörigen Konfigurationsdeskriptor für das Merkmal "Kunde", da das Merkmal Meldungen unterstützt. Jedes Merkmal, das Benachrichtigungen oder Hinweise unterstützt, muss einen Konfigurationsdeskriptor für das Kundenmerkmal haben, da sein Wert (in den die Kunden schreiben können) steuert, ob Benachrichtigungen oder Hinweise derzeit aktiviert sind oder nicht.

13.4.2 Mischung aus Bluetooth SIG und benutzerdefinierten Attributen

Abbildung 74 zeigt einen GATT-Server mit einer Mischung aus GATT-Attributen, die von der Bluetooth SIG definiert wurden, und einem einzigen benutzerdefinierten Dienst, der ein einziges benutzerdefiniertes Merkmal enthält. Der benutzerdefinierte Dienst heißt Proximity Monitoring Service und hat einen UUID-Type Identifier Wert von 0x 3E099910-293F-11E4-93BD-AFD0FE6D1DFD. Sein Merkmal heißt Client Proximity characteristic und hat den UUID-Wert 0x 3E099911-293F-11E4-93BD-AFD0FE6D1DFD. Beachten Sie, dass dieser Dienst und dieses Merkmal in der Projektarbeit in der pädagogischen Entwicklerressource An Introduction to Bluetooth Low Energy Development verwendet werden. Siehe 18. Zusätzliche Ressourcen für weitere Details.

Abbildung 74 - Eine Mischung aus von Bluetooth SIG definierten und benutzerdefinierten Attributen

14. Das allgemeine Zugangsprofil

14.1 Grundsätzliches

Der Abschnitt Generic Access Profile (GAP) der Bluetooth-Kernspezifikation definiert Verfahren zur Geräteerkennung und zum Verbindungsaufbau zwischen zwei Geräten. Die Durchführung der verbindungslosen Datenkommunikation im Allgemeinen, die Verwendung periodischer Werbung (siehe 7.8.3 PADVB - LE Periodic Advertising Broadcast) und die Einrichtung isochroner Kommunikation (siehe 7.8.5 LE BIS und LE CIS - Isochronous Communication) sind ebenfalls Themen, die von GAP abgedeckt werden.

Darüber hinaus werden in diesem Abschnitt der Kernspezifikation auch einige wichtige Standards für die Benutzeroberfläche und bestimmte Aspekte der Bluetooth LE behandelt.

Die Übertragung von Werbepaketen(Advertising) und deren Empfang durch Scanning ist der Kern der Funktionsweise von GAP. Es gibt verschiedene Arten von Werbe- und Scanning-Paketen, die von der Verbindungsschicht definiert werden. Es ist zu beachten, dass das Nutzdatenfeld AdvData heißt und nicht in allen PDU-Typen vorhanden ist. Wenn es vorhanden ist, werden die darin enthaltenen Daten als eine Reihe von einem oder mehreren Längen/Tag/Wert-Konstrukten kodiert, die als AD-Typen bekannt sind. AD-Typen sind im Dokument Core Specification Supplement (CSS) definiert, das auf der Spezifikationsseite unter bluetooth.com verfügbar ist.

GAP ist sowohl für Bluetooth LE als auch für Bluetooth BR/EDR von Bedeutung. Im weiteren Verlauf dieses Abschnitts wird nur GAP im Zusammenhang mit Bluetooth LE behandelt. Darüber hinaus ist anzumerken, dass Aktivitäten wie Werbung und Scanning zwar von zentraler Bedeutung für GAP sind, diese Verfahren jedoch tatsächlich von der Verbindungsschicht durchgeführt werden, ebenso wie die beteiligten PDU-Typen.

14.2 Rollen

GAP definiert vier Geräterollen. Diese sind in Tabelle 16 aufgeführt und erläutert.

Rolle	Beschreibung
Rundfunkveranstalter	Ein Gerät, das eine Form von Werbung verwendet, um Daten verbindungslos zu übertragen. Dazu gehören Legacy-Werbung, erweiterte Werbung und periodische Werbung. Ein Broadcaster kann auch einen isochronen Rundfunkstrom übertragen. Ein Broadcaster hat einen Sender, der Besitz eines Empfängers ist jedoch optional. Ein Broadcaster akzeptiert keine Verbindungen von zentralen Geräten (es sei denn, er agiert auch in der Rolle des Peripheriegeräts).
Beobachter	Ein Observer empfängt Werbepakete oder isochrone Broadcast-Datenpakete. Er stellt keine Verbindung zu anderen Geräten her, enthält einen Empfänger und kann, muss aber nicht, einen Sender enthalten. Der Observer ist in der Lage, Broadcast-Daten verbindungslos zu empfangen.
Peripherie	Ein Peripheriegerät kann mit einem Zentralgerät verbunden werden. Es enthält einen Sender und einen Empfänger.
Zentrale	Eine Zentrale ist in der Lage, den Aufbau einer Verbindung mit einem Peripheriegerät zu initiieren. Sie enthält sowohl einen Sender als auch einen Empfänger.

Tabelle 16 - GAP-Rollen

Beachten Sie, dass die Rollenbezeichnungen Central und Peripheral auch von der Verbindungsschicht verwendet werden. Die Begriffe in diesen beiden unterschiedlichen Kontexten bedeuten nicht dasselbe.

14.3 Entdeckung

Ein Broadcaster- oder Peripheriegerät befindet sich entweder im nicht auffindbaren Modus oder in einem der beiden auffindbaren Modi, die GAP definiert. Bei Werbung im nicht auffindbaren Modus sind die übertragenen Pakete über die Luft sichtbar (dies ist kein Sicherheitsmerkmal), aber Scan-Geräte, die entweder das allgemeine auffindbare Verfahren oder das begrenzte auffindbare Verfahren durchführen, ignorieren diese Pakete.

Ein auffindbares Gerät kann sich entweder im allgemeinen auffindbaren Modus oder im begrenzten auffindbaren Modus befinden. Im Modus der allgemeinen Auffindbarkeit ist ein Gerät für unbestimmte Zeit auffindbar, im Modus der eingeschränkten Auffindbarkeit für maximal drei Minuten.

Erkennende Geräte sind in der Lage zu erkennen, in welchem der erkennbaren Modi sich ein werbendes Gerät befindet, indem sie einen AD-Typ im AdvData-Feld namens Flags untersuchen. Der eingeschränkte Erkennungsmodus wird häufig verwendet, um Geräten Vorrang zu geben, mit denen der Benutzer kürzlich interagiert hat, z. B. durch Drücken einer Taste oder durch einfaches Aufnehmen und Bewegen des Geräts.

Wenn ein Zentral- oder Beobachtergerät versucht, andere Geräte zu finden, kann es entweder passives Scannen oder aktives Scannen verwenden. Welches der beiden Verfahren zulässig ist, hängt davon ab, ob das Gerät versucht, Geräte im allgemeinen Erkennungsmodus oder im eingeschränkten Erkennungsmodus zu erkennen.

Beim passiven Scanning werden Werbe-PDUs empfangen, ohne Scanning-PDUs zu senden. Beim aktiven Scanning werden Werbe-PDUs empfangen und als Antwort darauf weitere Informationen angefordert, indem Scanning-PDUs gesendet werden. Die verschiedenen PDU-Typen werden von der Verbindungsschicht definiert und sind in 7.8.2 ADVB - LE Advertising Broadcast zusammengefasst.

In der Bluetooth Core Spezifikation wird darauf hingewiesen, dass einige Geräte nur die herkömmliche Werbung verwenden, während andere die erweiterte Werbung nutzen oder beide Formen der Werbung miteinander verschachteln können. Es wird empfohlen, dass Geräte, die eine der Erkennungsprozeduren durchführen, das Scannen nach beiden Arten von Werbung verschachteln. Es wird auch empfohlen, dass ein Gerät auf allen von ihm unterstützten PHYs scannt.

Abbildung 75 zeigt die GAP-Erkennungsmodi in Verbindung mit anderen relevanten Variablen.

14.4 Verbindungsmodi

Ein werbendes Gerät kann entweder durch die verwendete PDU (Legacy-Advertising) oder durch den Wert des AdvMode-Feldes (Extended-Advertising) angeben, ob es für eine Verbindung zur Verfügung steht oder nicht.

Abbildung 75 zeigt die GAP-Verbindungsarten in Verbindung mit anderen relevanten Variablen.

Ein Gerät kann eine Verbindung mit einem anderen Gerät anfordern, indem es eine der von GAP definierten verbindungsbezogenen Prozeduren durchführt. Dazu wird im Allgemeinen entweder eine CONNECT_IND-PDU (Legacy Advertising) oder eine AUX_CONNEXT_REQ-PDU (Extended Advertising) als Antwort auf eine empfangene PDU eines von mehreren Typen, die dies erlauben, gesendet. Die Verbindungsschicht definiert die PDU-Typen für Werbung und Verbindungsanforderung sowie die Regeln für die PDU-Typen, auf die eine Verbindungsanforderung als Antwort gesendet werden kann. Siehe 7.8.2.2.3 Legacy Advertising und zugehörige PDU-Typen und 7.8.2.3.5 Extended Advertising und zugehörige PDU-Typen.

14.5 Gerichtet und ungerichtet

Werbung, wie sie von GAP verwendet wird, kann entweder ungerichtet sein, was bedeutet, dass PDUs für jedes Beobachter- oder Zentralgerät gelten, das sie empfängt, oder gerichtet, was bedeutet, dass nur ein bestimmtes Gerät solche PDUs verarbeiten sollte. PDUs mit gerichteter Werbung enthalten das Feld TargetA mit der Bluetooth-Adresse des vorgesehenen Empfängergeräts. Bei ungerichteter Werbung fehlt das TargetA-Feld.

Abbildung 75 zeigt gerichtete und ungerichtete Werbung im Zusammenhang mit der GAP-Erkennung und den Verbindungsmodi.

Abbildung 75 - GAP-Erkennung und Verbindungsmodi

Beachten Sie, dass die AD Type Flags in Legacy-Advertising-Paketen erscheinen, die auf dem primären Werbekanal empfangen werden. Wenn jedoch erweiterte Werbung verwendet wird, ist das AdvData-Feld in ADV_EXT_IND-PDUs, die auf den primären Kanälen empfangen werden, nicht vorhanden. Wenn Flags bei erweiterter Werbung verwendet wird, erscheint es in AUX_EXT_IND-PDUs auf den Allzweckkanälen.

14.6 Durchsuchbar vs. nicht durchsuchbar

Bestimmte Werbe-PDU-Typen gelten als abfragbar. Das bedeutet, dass ein Gerät, das eine solche PDU empfängt, mit einer Scan-Request-PDU eines geeigneten Typs antworten darf, um weitere Werbedaten anzufordern. Werbe-PDUs werden von der Verbindungsschicht definiert. Siehe 7.8.2.2.3 Legacy Advertising and Associated PDU Types und 7.8.2.3.5 Extended Advertising and Associated PDU Types für weitere Einzelheiten.

14.7 GAP und LE Sicherheit

Die GAP-Spezifikation definiert eine Reihe von Sicherheitsbegriffen, Modi und Verfahren. Im Allgemeinen beziehen die GAP-Sicherheitsverfahren andere Schichten des Stacks wie das Security Manager Protocol (SMP) und die Verbindungsschicht mit ein, aber das übergeordnete Verfahren für die Verwendung dieser Schichten zur Erzielung bestimmter Ergebnisse ist in Band 3 Teil C (Generic Access Profile) der Bluetooth Core Specification definiert, die für Einzelheiten konsultiert werden sollte.

14.8 Regelmäßige Werbung

Periodic Advertising (sowohl mit als auch ohne Antworten) wird von der Verbindungsschicht durchgeführt (siehe 7.8.3 PADVB - LE Periodic Advertising Broadcast), aber GAP spezifiziert das Verfahren für einen Broadcaster, um in den periodischen Werbemodus zu gelangen und für einen Observer, um sich mit einem periodischen Werbezug zu synchronisieren. Darüber hinaus ist in GAP das PAST-Verfahren (Periodic Advertising Synchronization Transfer) definiert, das es einem Beobachter ermöglicht, Parameter für die periodische Werbesynchronisation von einem Broadcaster zu erwerben und sie über eine ACL-Verbindung an ein anderes Gerät weiterzugeben.

14.9 Isochroner Rundfunk

Isochrone Kommunikation unter Verwendung von isochronen Broadcast-Streams und verbundenen isochronen Streams wird von der Verbindungsschicht durchgeführt (siehe 7.8.5 LE BIS und LE CIS - Isochrone Kommunikation), aber GAP spezifiziert die Verfahren, die ein Broadcaster und Observer befolgen müssen, um diese Form der Kommunikation durchzuführen.

15. Das Sicherheitsmanager-Protokoll

15.1 Grundsätzliches

Das Sicherheitsmanager-Protokoll (SMP) ist Teil der Sicherheitsmanager-Komponente des Stacks. Es unterstützt die Ausführung von sicherheitsrelevanten Prozeduren wie Pairing, Bonding und Schlüsselverteilung.

Die Komponente Sicherheitsmanager stellt eine kryptografische Toolbox für Sicherheitsfunktionen bereit, die andere Schichten nutzen können, und definiert Paarungsalgorithmen.

Abschnitt 16. Sicherheit in Bluetooth LE hat mehr über Sicherheit im Allgemeinen zu sagen.

15.2 Beispiel

Abbildung 76 zeigt die Verwendung von SMP bei der Kopplung zweier Geräte. Beachten Sie den Austausch von Eingangs-/Ausgangsfähigkeiten und anderen Flags während des SMP Pairing Feature Exchange. Dies ist ein wichtiger Schritt, der bestimmt, welcher Pairing-Algorithmus ausgewählt wird und wie Schritte wie die Authentifizierung und die Einbindung in das Verfahren erfolgen.

Abbildung 76 - SMP im Einsatz während der Kopplung

16. Sicherheit in Bluetooth LE

Sicherheit ist ein kritisches Thema, das sorgfältig bedacht und verstanden werden muss.

Bluetooth LE bietet eine Reihe von Sicherheitsfunktionen und -merkmalen, von denen die meisten optional sind. Sie sollten dies als einen Werkzeugkasten betrachten, der Sicherheitswerkzeuge enthält, mit denen bestimmte Sicherheitsprobleme angegangen und bestimmte Sicherheitsanforderungen erfüllt werden können. Es liegt in der Verantwortung des Produktteams, nachdem es die Sicherheitsanforderungen für ein Produkt ermittelt hat, diese Anforderungen zu erfüllen. Gegebenenfalls sollte dies durch die Verwendung ausgewählter Bluetooth LE Sicherheitsfunktionen erreicht werden.

Angesichts der Bedeutung dieses Themas wurde von der Bluetooth SIG eine Bildungsressource zu diesem Thema erstellt, deren Inhalt hier nicht wiederholt werden soll. Weitere Informationen finden Sie in Abschnitt 18. Zusätzliche Ressourcen für weitere Informationen.

17. Anwendungen

Die in den anderen Abschnitten beschriebenen Funktionen von Bluetooth LE werden letztendlich durch Anwendungen genutzt. Aber nicht alle Funktionen der neuesten Bluetooth Core Spezifikation werden notwendigerweise für Anwendungen verfügbar sein. Die Hauptgründe, warum dies der Fall ist, sind:

Es dauert seine Zeit, bis neue Funktionen der Bluetooth in Komponenten implementiert sind und in allgemein erhältlichen Produkten wie Computern, Smartphones usw. erscheinen.
Viele Bluetooth LE sind optional, und es liegt in der Entscheidung des Implementierers, welche Funktionen er einbezieht und welche er weglässt. Der Implementierer kann der Hersteller des Controller-Chips oder der Entwickler des Betriebssystems sein, das z. B. die Host enthält. Nur weil ein Gerät, für das eine Anwendung entwickelt werden soll, angibt, dass es eine bestimmte Version der Bluetooth-Kernspezifikation unterstützt, heißt das nicht unbedingt, dass es alle Funktionen dieser Version unterstützt.
Selbst wenn der Bluetooth eines Geräts eine bestimmte Funktion unterstützt, bedeutet dies nicht, dass sie den Anwendungsentwicklern zur Verfügung steht. Anwendungsentwickler arbeiten mit APIs und nicht direkt mit dem Stack. Wenn es keine API für eine Bluetooth gibt, kann sie von einer Anwendung nicht genutzt werden, selbst wenn dercontroller die Funktion unterstützt.

Die Lehre hieraus ist, dass man einige Nachforschungen anstellen sollte, bevor man sich an die Entwicklung einer Anwendung macht. Überprüfen Sie insbesondere die API-Dokumentation, um sicherzustellen, dass die benötigten Funktionen unterstützt werden, und überprüfen Sie die Spezifikation der Bluetooth der Hardware und des Betriebssystems, auf denen die Anwendung laufen soll.

18. Zusätzliche Ressourcen

In diesem Abschnitt werden weitere Ressourcen aufgeführt, die das Lernen über Bluetooth LE aus verschiedenen Perspektiven unterstützen.

Ressource	Beschreibung	Standort
Bluetooth Kernspezifikation	Die wichtigste technische Spezifikation. Definiert alle Schichten des Bluetooth-Stacks und die zugehörigen Protokolle und Verfahren. Deckt sowohl Bluetooth LE als auch Bluetooth BR/EDR ab.	Spezifikationen/specs/
Profil und Leistungsbeschreibung	Eine Dienstspezifikation definiert einen einzelnen GATT-Dienst zusammen mit den darin enthaltenen Merkmalen und Deskriptoren. Die Profilspezifikationen definieren die Rollen, die verbundene Geräte einnehmen, und legen insbesondere das Verhalten des Client-Geräts und die Daten auf dem verbundenen Server fest, mit denen es arbeiten soll.	Spezifikationen/specs/
LC3	Definiert den von LE Audio verwendeten Low Complexity Communication Codec.	Spezifikationen/specs/
Studienführer - Einführung in die Bluetooth Low Energy Entwicklung	Eine Bildungsressource für Entwickler, die etwas über Softwareentwicklung für verbindungsorientierte Szenarien mit Smartphones und Peripheriegeräten lernen möchten. Enthält eine Reihe praktischer Projekte mit Lösungen.	bluetooth-resources/bluetooth-le-developer-starter-kit/
Studienführer - Eine Einführung in die Entwicklung von Bluetooth Mesh Software	Eine Bildungsressource für Entwickler, die etwas über Bluetooth-Mesh und die Implementierung von Mesh-Modellen in Mikrocontrollern lernen möchten. Enthält eine Reihe praktischer Projekte mit Lösungen.	bluetooth-resources/bluetooth-mesh-developer-study-guide/
Studienführer - Einführung in die Bluetooth Mesh Proxy-Funktion	Ein Lehrmittel für Entwickler, die lernen möchten, wie man GUI-Anwendungen für Geräte wie Smartphones erstellt, die eine Interaktion mit Knoten in einem Bluetooth-Mesh-Netzwerk ermöglichen. Enthält eine Reihe praktischer Projekte mit Lösungen.	bluetooth-resources/bluetooth-mesh-proxy-kit/
Papier - Bluetooth Mesh Networking - Eine Einführung für Entwickler	Eine Bildungsressource für alle, die sich für die wichtigsten Konzepte und Funktionen von Bluetooth Mesh interessieren.	bluetooth-resources/bluetooth-mesh-networking-an-introduction-for-developers/
Papier - Bluetooth-Mesh-Modelle - ein technischer Überblick	Eine lehrreiche Ressource für alle, die sich für ein besseres Verständnis der Standardmodelle interessieren, die für die Verwendung in Bluetooth-Mesh-Produkten verfügbar sind.	bluetooth-resources/bluetooth-mesh-models/
Studienführer - Verständnis der Bluetooth LE	Ein Lehrmittel, das alle Aspekte der Sicherheit in Bluetooth LE (außer Bluetooth Mesh) erklärt und veranschaulicht. Es ist sowohl für absolute Neulinge im Bereich der Sicherheit als auch für Personen mit Vorkenntnissen geeignet. Enthält eine Reihe praktischer Projekte mit Lösungen.	bluetooth-resources/le-security-study-guide/
Papier - Leitfaden für bewährte Praktiken zu Bluetooth-Sicherheit und Datenschutz	Ein Leitfaden, der Implementierern helfen soll, besser zu verstehen, warum bestimmte verfügbare Sicherheits- und Datenschutzoptionen für bestimmte Anwendungen besser oder schlechter sind als andere und welche Risiken und Fallstricke in den Spezifikationen verbleiben.	bluetooth-resources/bluetooth-security-and-privacy-best-practices-guide/
Studienführer - Bluetooth-Technologie für Linux-Entwickler	Eine Bildungsressource für Linux-Entwickler, die etwas über die Entwicklung von Software lernen möchten, die den Linux-Bluetooth-Stack, BlueZ, verwendet. Enthält eine Reihe praktischer Projekte mit Lösungen.	bluetooth-resources/bluetooth-for-linux/
Studienführer - Entwurf und Entwicklung von Bluetooth Internet Gateways	Eine pädagogische Ressource, die Bluetooth-Internet-Gateways erklärt, die verwendet werden, um den Zugang zu Bluetooth LE und Bluetooth-Mesh-Geräten vom Internet aus zu ermöglichen. Veranschaulicht mögliche Architekturen und Implementierungsansätze. Enthält eine Reihe praktischer Projekte mit Lösungen.	bluetooth-resources/bluetooth-internet-gateways/
Studienführer - Eine Einführung in Web-Bluetooth	Ein Lehrmittel für Entwickler, die etwas über die Entwicklung von Webanwendungen lernen möchten, die die JavaScript Web Bluetooth APIs verwenden. Enthält eine Reihe praktischer Projekte mit Lösungen.	bluetooth-resources/web-bluetooth-tutorial/
Studienführer - Eine Einführung in Bluetooth Beacons	Eine Bildungsressource für Entwickler, die mehr über Bluetooth Beacons erfahren möchten. Enthält eine Reihe praktischer Projekte mit Lösungen.	bluetooth-resources/beacon-smart-starter-kit/
Papier - Bluetooth Core Spezifikation Version 5.0 Funktionserweiterungen	Erläutert die neuen Funktionen und andere Änderungen, die in Version 5.0 der Bluetooth Core Spezifikation veröffentlicht wurden. Beinhaltet den LE 2M PHY, LE Coded PHY und erweiterte Werbung.	bluetooth-resources/bluetooth-5-go-faster-go-further/
Papier - Bluetooth Core Spezifikation Version 5.1 Funktionsübersicht	Erläutert die neuen Funktionen und andere Änderungen, die in Version 5.1 der Bluetooth Core Spezifikation veröffentlicht wurden. Beinhaltet AoA und AoD Peilung.	bluetooth-resources/bluetooth-core-specification-v5-1-feature-overview/
Papier - Bluetooth Core Spezifikation Version 5.2 Funktionsübersicht	Erläutert die neuen Funktionen und andere Änderungen, die in Version 5.2 der Bluetooth Core Spezifikation veröffentlicht wurden. Beinhaltet das Enhanced Attribute Protocol, LE Power Control und LE Isochronous Channels.	bluetooth-resources/bluetooth-core-specification-version-5-2-feature-overview/
Papier - Bluetooth Core Spezifikation Version 5.3 Funktionsübersicht	Erläutert die neuen Funktionen und andere Änderungen, die in Version 5.3 der Bluetooth Core Spezifikation veröffentlicht wurden. Beinhaltet LE Enhanced Connection Update mit Subrating und LE Channel Classification.	bluetooth-resources/bluetooth-core-specification-version-5-3-feature-enhancements/
^Bluetooth® Core Spezifikation Version 5.4 - Technischer Überblick	Erläutert die neuen Funktionen und andere Änderungen, die in Version 5.4 der Bluetooth Core Spezifikation veröffentlicht wurden. Beinhaltet periodische Werbung mit Antworten und verschlüsselte Werbedaten.	bluetooth-resources/bluetooth-core-specification-version-5-4-technical-overview/
^Bluetooth® Core Specification v6.0 Funktionsübersicht	Erläutert die neuen Funktionen und andere Änderungen, die in Version 6.0 der Bluetooth Core Spezifikation veröffentlicht wurden. Enthält Bluetooth Channel Sounding, entscheidungsbasierte Werbefilterung und die Überwachung von Werbeträgern.	kernspezifikation-6-feature-overview/
Bluetooth Channel Sounding Technischer Überblick	Bietet einen detaillierten technischen Überblick über Bluetooth Channel Sounding.	bluetooth-resources/bluetooth-channel-sounding-a-technical-overview/
eBook - Einführung in Bluetooth LE Audio	Ein Buch von Nick Hunn, das eine klare Einführung in die Funktionen und technischen Details von Bluetooth LE Audio bietet.	bluetooth-resources/le-audio-book/
Dokument über regulatorische Aspekte	Enthält Anleitungen und unterstützende Informationen zur Bluetooth LE und zum Verständnis der Bluetooth SIGfür die in verschiedenen geografischen Regionen geltenden HF-Vorschriften.	bluetooth-resources/bluetooth-low-energy-regulatory-aspects-document-rad/

[1] Die Bluetooth-Spezifikationen werden in Abschnitt 4 vorgestellt.

[2] Dienste, Merkmale und Deskriptoren werden im Abschnitt Generisches Attributprofil erläutert.

[3] LE 2M 2BT wird nur für Bluetooth Channel Sounding und nicht für die allgemeine Datenkommunikation verwendet.

[4] Bluetooth Channel Sounding ist ein Sonderfall und wird in 8.^Bluetooth® Channel Sounding behandelt.

[5] Weitere Informationen zu Bluetooth LE und RF-Vorschriften finden Sie unter 18. Zusätzliche Ressourcen für das Dokument zu den rechtlichen Aspekten

[6] Abschnitt 15 behandelt die Sicherheit von Bluetooth LE im Detail.

[7] [8]Periodische Werbung und isochrone Streams werden in 7.8 Die logischen Transporte erklärt

[9] #nse - 1 bedeutet Anzahl der Unterereignisse minus eins

[10] Der von LE Audio verwendete Low Complexity Communications Codec

[11] Siehe 12.4 Träger